Re: [PATCH] fix for VM test9-pre7
Rik van Riel <[EMAIL PROTECTED]> writes: > On 2 Oct 2000, Christoph Rohland wrote: > > > the shm swapping still kills the machine(8GB mem) the machine > > with somthing like '__alloc_pages failed order 0'. > > > > When I do the same stresstest with mmaped file in ext2 the > > machine runs fine but the processes do not do anything and > > vmstat/ps lock up on these processes. > > This may be a highmem bounce-buffer creation deadlock. Do > your tests work if you use only 800 MB of RAM ? > > Shared memory swapping on my 64 MB test machine seems to > work fine (albeit a bit slow). Yupp, with mem=850M it seems to work. Greetings Christoph -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
Rik van Riel [EMAIL PROTECTED] writes: On 2 Oct 2000, Christoph Rohland wrote: the shm swapping still kills the machine(8GB mem) the machine with somthing like '__alloc_pages failed order 0'. When I do the same stresstest with mmaped file in ext2 the machine runs fine but the processes do not do anything and vmstat/ps lock up on these processes. This may be a highmem bounce-buffer creation deadlock. Do your tests work if you use only 800 MB of RAM ? Shared memory swapping on my 64 MB test machine seems to work fine (albeit a bit slow). Yupp, with mem=850M it seems to work. Greetings Christoph -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
On 2 Oct 2000, Christoph Rohland wrote: > the shm swapping still kills the machine(8GB mem) the machine > with somthing like '__alloc_pages failed order 0'. > > When I do the same stresstest with mmaped file in ext2 the > machine runs fine but the processes do not do anything and > vmstat/ps lock up on these processes. This may be a highmem bounce-buffer creation deadlock. Do your tests work if you use only 800 MB of RAM ? Shared memory swapping on my 64 MB test machine seems to work fine (albeit a bit slow). regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7 doesn't recognize HiSax ISDN card
On Mon, Oct 02, 2000 at 12:08:10AM +0200, Pierfrancesco Caci wrote: > > The subject tells everything: > ... > > 28x481 23:49:14 penny kernel: fb0: MATROX VGA frame buffer device > Oct 1 23:49:14 penny kernel: pty: 512 Unix98 ptys configured > Oct 1 23:49:14 penny kernel: ISDN subsystem Rev: 1.111/1.93/1.135/1.77/1.21/1.5 > Oct 1 23:49:14 penny kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31 > > Is there something that is changed and that I should know ? > Nothing so far I know, seems HiSax was not selected or compiled as module. -- Karsten Keil SuSE Labs ISDN development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
Hi Rik, the shm swapping still kills the machine(8GB mem) the machine with somthing like '__alloc_pages failed order 0'. When I do the same stresstest with mmaped file in ext2 the machine runs fine but the processes do not do anything and vmstat/ps lock up on these processes. Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
On Mon, 2 Oct 2000 [EMAIL PROTECTED] wrote:
> On Mon, Oct 02, 2000 at 12:42:47AM -0300, Rik van Riel wrote:
> > --- linux-2.4.0-test9-pre7/fs/buffer.c.orig Sat Sep 30 18:09:18 2000
> > +++ linux-2.4.0-test9-pre7/fs/buffer.c Mon Oct 2 00:19:41 2000
> > @@ -706,7 +706,9 @@
> > static void refill_freelist(int size)
> > {
> > if (!grow_buffers(size)) {
> > - try_to_free_pages(GFP_BUFFER);
> > + wakeup_bdflush(1);
> > + current->policy |= SCHED_YIELD;
> > + schedule();
> > }
> > }
>
> This part looks strange! wakeup_bdflush will sleep if the
> parameter is not zero, i.e. we'll schedule twice. I doubt that
> this the intended behaviour?
Heh...
I copied back the old code because I saw some failures in
the try_to_free_pages() in this situation.
Maybe the person who wrote this code originally can comment
on this one ?
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
Hi,
On Mon, Oct 02, 2000 at 12:42:47AM -0300, Rik van Riel wrote:
> --- linux-2.4.0-test9-pre7/fs/buffer.c.orig Sat Sep 30 18:09:18 2000
> +++ linux-2.4.0-test9-pre7/fs/buffer.cMon Oct 2 00:19:41 2000
> @@ -706,7 +706,9 @@
> static void refill_freelist(int size)
> {
> if (!grow_buffers(size)) {
> - try_to_free_pages(GFP_BUFFER);
> + wakeup_bdflush(1);
> + current->policy |= SCHED_YIELD;
> + schedule();
> }
> }
This part looks strange! wakeup_bdflush will sleep if the parameter
is not zero, i.e. we'll schedule twice. I doubt that this the intended
behaviour?
regardsChristian
--
THAT'S ALL FOLKS!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
test9-pre7 still truncate/ext2 corruption/system hang bugs
I've had reproduceable and repeatable problems with test9 -most of them- that always leave my laptop stuck. Only sysrq-o seems to respond. It seems it is related to the truncate proble that arised in test7 series. When I'm reading my email in an xterm with pine and I expunge a mailbox, if I'm too fast with my fingers and click several keys in advance -like the down arrow to check for new email- the system stop working. No oops, now working keybord, only rebooting through magic key. I've reproduced it like 20 times, every time I boot with test9-pre7 or less. test8 doesn't seem to have the same problem. I'm going to compile test9-pre8, but I haven't seen any change that seems related to this bug. If someone needs debugging, please provide me with the proper patch or instructions as I cannot get any oops. I'll carry on the necessary tests. Pau - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
BUG in buffer.c (2.4.0-test9-pre7); fsck problem
I got the following OOPSen running 2.4.0-test9-pre7; I hope it can be of
use for someone.
Also, this kernel has an odd problem: fsck sometimes gets stuck when
rebooting after crash. The drive light occationally flashes (not on
solid as it usually is!) but nothing seems to happen in the end. Booting
into a 2.2 kernel, fsck can make forward progress (usually nothing is
seriously wrong with the filesystem).
Anyway, the first and second oops are included with ksymoops; also a full
serial console transcript is included.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
ksymoops 2.3.3 on i686 2.4.0-test9-pre7. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9-pre7/ (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 resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Error (regular_file): read_system_map stat /usr/src/linux/System.map failed
invalid operand:
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 001c ebx: e94e3e60 ecx: c02f7408 edx: 0027
esi: f7c6deac edi: f7c6de00 ebp: esp: c5315eb0
ds: 0018 es: 0018 ss: 0018
Process cc1plus (pid: 6520, stackpage=c5315000)
Stack: c0291c9e c029207a 02da c01cb915 e94e3e60 0001 f7c6de00 c6d12000
c6d12000 c01cbc14 f7c6de00 0001 0002 0001 0001
0001 f7c6de00 0002 f7c6de00 0242 35ae8000 f7dc0498
Call Trace: [] [] [] [] []
[] []
[] [] []
Code: 0f 0b 83 c4 0c c3 8d 76 00 57 56 53 8b 74 24 10 8b 54 24 14
>>EIP; c013504b<=
Trace; c0291c9e <__br_write_unlock+18e5a/41936>
Trace; c029207a <__br_write_unlock+19236/41936>
Trace; c01cb915
Trace; c01cbc14
Trace; c0205ed2
Trace; c01caedc
Trace; c0204948
Trace; c010c566 <__global_restore_flags+92/bc>
Trace; c010c759
Trace; c010ae7c <__read_lock_failed+114c/25d0>
Code; c013504b
<_EIP>:
Code; c013504b<=
0: 0f 0b ud2a <=
Code; c013504d
2: 83 c4 0c addl $0xc,%esp
Code; c0135050
5: c3ret
Code; c0135051
6: 8d 76 00 leal 0x0(%esi),%esi
Code; c0135054
9: 57pushl %edi
Code; c0135055
a: 56pushl %esi
Code; c0135056
b: 53pushl %ebx
Code; c0135057
c: 8b 74 24 10 movl 0x10(%esp,1),%esi
Code; c013505b
10: 8b 54 24 14 movl 0x14(%esp,1),%edx
Aiee, killing interrupt handler
1 warning and 1 error issued. Results may not be reliable.
ksymoops 2.3.3 on i686 2.4.0-test9-pre7. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9-pre7/ (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 resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Error (regular_file): read_system_map stat /usr/src/linux/System.map failed
invalid operand:
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 001b ebx: 0020 ecx: c02f7408 edx:
esi: edi: c5314000 ebp: c5315db8 esp: c5315d60
ds: 0018 es: 0018 ss: 0018
Process cc1plus (pid: 6520, stackpage=c5315000)
Stack: c028b61e c028b836 02ba c5314000 f0e25320 c5314000 c01330a0 0001
f48aebc0 0020 f48aece0 0020 0082 c5314000 c5314000 c011cc3a
c5314000 c5314000 c5314000 0001 c5314000 000b 000b c011cff8
Call Trace: [] [] [] [] []
[] []
[] [] [] [] [] []
[] []
[] [] [] [] [] []
Code: 0f 0b 8d 65 b4 5b 5e 5f 89 ec 5d c3 89 f6 55 89 e5 83 ec 24
>>EIP; c0117c62<=
Trace; c028b61e <__br_write_unlock+127da/41936>
Trace; c028b836 <__br_write_unlock+129f2/41936>
Trace; c01330a0
Trace; c011cc3a
Trace; c011cff8
Trace; c010b2a6 <__read_lock_failed+1576/25d0>
Trace; c010b53e <__read_lock_failed+180e/25d0>
Trace; c0283bbc
test9-pre7 still truncate/ext2 corruption/system hang bugs
I've had reproduceable and repeatable problems with test9 -most of them- that always leave my laptop stuck. Only sysrq-o seems to respond. It seems it is related to the truncate proble that arised in test7 series. When I'm reading my email in an xterm with pine and I expunge a mailbox, if I'm too fast with my fingers and click several keys in advance -like the down arrow to check for new email- the system stop working. No oops, now working keybord, only rebooting through magic key. I've reproduced it like 20 times, every time I boot with test9-pre7 or less. test8 doesn't seem to have the same problem. I'm going to compile test9-pre8, but I haven't seen any change that seems related to this bug. If someone needs debugging, please provide me with the proper patch or instructions as I cannot get any oops. I'll carry on the necessary tests. Pau - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
Hi,
On Mon, Oct 02, 2000 at 12:42:47AM -0300, Rik van Riel wrote:
--- linux-2.4.0-test9-pre7/fs/buffer.c.orig Sat Sep 30 18:09:18 2000
+++ linux-2.4.0-test9-pre7/fs/buffer.cMon Oct 2 00:19:41 2000
@@ -706,7 +706,9 @@
static void refill_freelist(int size)
{
if (!grow_buffers(size)) {
- try_to_free_pages(GFP_BUFFER);
+ wakeup_bdflush(1);
+ current-policy |= SCHED_YIELD;
+ schedule();
}
}
This part looks strange! wakeup_bdflush will sleep if the parameter
is not zero, i.e. we'll schedule twice. I doubt that this the intended
behaviour?
regardsChristian
--
THAT'S ALL FOLKS!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
On Mon, 2 Oct 2000 [EMAIL PROTECTED] wrote:
On Mon, Oct 02, 2000 at 12:42:47AM -0300, Rik van Riel wrote:
--- linux-2.4.0-test9-pre7/fs/buffer.c.orig Sat Sep 30 18:09:18 2000
+++ linux-2.4.0-test9-pre7/fs/buffer.c Mon Oct 2 00:19:41 2000
@@ -706,7 +706,9 @@
static void refill_freelist(int size)
{
if (!grow_buffers(size)) {
- try_to_free_pages(GFP_BUFFER);
+ wakeup_bdflush(1);
+ current-policy |= SCHED_YIELD;
+ schedule();
}
}
This part looks strange! wakeup_bdflush will sleep if the
parameter is not zero, i.e. we'll schedule twice. I doubt that
this the intended behaviour?
Heh...
I copied back the old code because I saw some failures in
the try_to_free_pages() in this situation.
Maybe the person who wrote this code originally can comment
on this one ?
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
Hi Rik, the shm swapping still kills the machine(8GB mem) the machine with somthing like '__alloc_pages failed order 0'. When I do the same stresstest with mmaped file in ext2 the machine runs fine but the processes do not do anything and vmstat/ps lock up on these processes. Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7 doesn't recognize HiSax ISDN card
On Mon, Oct 02, 2000 at 12:08:10AM +0200, Pierfrancesco Caci wrote: The subject tells everything: ... 28x481 23:49:14 penny kernel: fb0: MATROX VGA frame buffer device Oct 1 23:49:14 penny kernel: pty: 512 Unix98 ptys configured Oct 1 23:49:14 penny kernel: ISDN subsystem Rev: 1.111/1.93/1.135/1.77/1.21/1.5 Oct 1 23:49:14 penny kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31 Is there something that is changed and that I should know ? Nothing so far I know, seems HiSax was not selected or compiled as module. -- Karsten Keil SuSE Labs ISDN development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
On 2 Oct 2000, Christoph Rohland wrote: the shm swapping still kills the machine(8GB mem) the machine with somthing like '__alloc_pages failed order 0'. When I do the same stresstest with mmaped file in ext2 the machine runs fine but the processes do not do anything and vmstat/ps lock up on these processes. This may be a highmem bounce-buffer creation deadlock. Do your tests work if you use only 800 MB of RAM ? Shared memory swapping on my 64 MB test machine seems to work fine (albeit a bit slow). regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7 doesn't recognize HiSax ISDN card
:-> "Pierfrancesco" == Pierfrancesco Caci <[EMAIL PROTECTED]> writes: > The subject tells everything: disregard... the subject tells that I shouldn't compile kernels past midnight :-) Sorry for the noise. Pf -- --- Pierfrancesco Caci | ik5pvx | mailto:[EMAIL PROTECTED] - http://gusp.dyndns.org Firenze - Italia | Office for the Complication of Otherwise Simple Affairs Linux penny 2.4.0-test8 #1 Sun Oct 1 20:23:27 CEST 2000 i686 unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix for VM test9-pre7
Hi,
The attached patch seems to fix all the reported deadlock
problems with the new VM. Basically they could be grouped
into 2 categories:
1) __GFP_IO related locking issues
2) something sleeps on a free/clean/inactive page goal
that isn't worked towards
The patch has survived some heavy stresstesting on both
SMP and UP machines. I hope nobody will be able to find
a way to still crash this one ;)
A second change is a more dynamic free memory target
(now freepages.high + inactive_target / 3), this seems
to help a little bit in some loads.
If your mailer messes up the patch, you can grab it from
http://www.surriel.com/patches/2.4.0-t9p7-vmpatch
Linus, if this patch turns out to work fine for the people
testing it, could you please apply it to your tree?
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
--- linux-2.4.0-test9-pre7/fs/buffer.c.orig Sat Sep 30 18:09:18 2000
+++ linux-2.4.0-test9-pre7/fs/buffer.c Mon Oct 2 00:19:41 2000
@@ -706,7 +706,9 @@
static void refill_freelist(int size)
{
if (!grow_buffers(size)) {
- try_to_free_pages(GFP_BUFFER);
+ wakeup_bdflush(1);
+ current->policy |= SCHED_YIELD;
+ schedule();
}
}
@@ -859,6 +861,7 @@
int balance_dirty_state(kdev_t dev)
{
unsigned long dirty, tot, hard_dirty_limit, soft_dirty_limit;
+ int shortage;
dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
tot = nr_free_buffer_pages();
@@ -869,21 +872,20 @@
/* First, check for the "real" dirty limit. */
if (dirty > soft_dirty_limit) {
- if (dirty > hard_dirty_limit || inactive_shortage())
+ if (dirty > hard_dirty_limit)
return 1;
return 0;
}
/*
-* Then, make sure the number of inactive pages won't overwhelm
-* page replacement ... this should avoid stalls.
+* If we are about to get low on free pages and
+* cleaning the inactive_dirty pages would help
+* fix this, wake up bdflush.
*/
- if (nr_inactive_dirty_pages >
- nr_free_pages() + nr_inactive_clean_pages()) {
- if (free_shortage() > freepages.min)
- return 1;
+ if (free_shortage() && nr_inactive_dirty_pages > free_shortage() &&
+ nr_inactive_dirty_pages > freepages.high)
return 0;
- }
+
return -1;
}
@@ -2663,9 +2665,8 @@
CHECK_EMERGENCY_SYNC
flushed = flush_dirty_buffers(0);
- if (nr_inactive_dirty_pages > nr_free_pages() +
- nr_inactive_clean_pages())
- flushed += page_launder(GFP_KSWAPD, 0);
+ if (free_shortage())
+ flushed += page_launder(GFP_BUFFER, 0);
/* If wakeup_bdflush will wakeup us
after our bdflush_done wakeup, then
--- linux-2.4.0-test9-pre7/mm/filemap.c.origSat Sep 30 18:16:28 2000
+++ linux-2.4.0-test9-pre7/mm/filemap.c Mon Oct 2 00:11:45 2000
@@ -44,7 +44,6 @@
atomic_t page_cache_size = ATOMIC_INIT(0);
unsigned int page_hash_bits;
struct page **page_hash_table;
-struct list_head lru_cache;
spinlock_t pagecache_lock = SPIN_LOCK_UNLOCKED;
/*
--- linux-2.4.0-test9-pre7/mm/page_alloc.c.orig Sat Sep 30 18:16:28 2000
+++ linux-2.4.0-test9-pre7/mm/page_alloc.c Mon Oct 2 00:31:15 2000
@@ -258,13 +258,13 @@
*/
switch (limit) {
default:
- case 0:
+ case PAGES_MIN:
water_mark = z->pages_min;
break;
- case 1:
+ case PAGES_LOW:
water_mark = z->pages_low;
break;
- case 2:
+ case PAGES_HIGH:
water_mark = z->pages_high;
}
@@ -318,10 +318,19 @@
direct_reclaim = 1;
/*
-* Are we low on inactive pages?
+* If we are about to get low on free pages and we also have
+* an inactive page shortage, wake up kswapd.
*/
if (inactive_shortage() > inactive_target / 2 && free_shortage())
wakeup_kswapd(0);
+ /*
+* If we are about to get low on free pages and cleaning
+* the inactive_dirty pages would fix the situation,
+* wake up bdflush.
+*/
+ else if (free_shortage() && nr_inactive_dirty_pages > free_shortage()
+ && nr_inactive
sound related OOPS (2.4.0-test9-pre7)
Hi! I got the following oopses while issuing the module-load triggering (no modules loaded before, but sound-core compiled into the kernel): richard> aumix See below for decoded oops and config/versions - also for a second, but probably "ghost" oops on a # cat /proc/ioports (I checked completely compiled in sound and this works just fine - machine is a Pentium100, non-pnp AWE32, isa-pnp ne2k (but not activated)) No modules in ksyms, skipping objects Sep 30 21:43:37 localhost kernel: isapnp: Scanning for Pnp cards... Sep 30 21:43:37 localhost kernel: isapnp: Card 'PLUG & PLAY ETHERNET CARD' Sep 30 21:43:37 localhost kernel: isapnp: 1 Plug & Play card detected total Sep 30 21:43:37 localhost kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 Sep 30 21:43:37 localhost kernel: sb: No ISAPnP cards found, trying standard ones... Sep 30 21:43:37 localhost kernel: SB 4.13 detected OK (220) Sep 30 21:43:37 localhost kernel: at 0x220 irq 5 dma 1,5 Sep 30 21:43:37 localhost kernel: at 0x330 irq 5 dma 0,0 Sound: Hmm, DMA1 was left allocated - fixed Sound: Hmm, DMA5 was left allocated - fixed Sep 30 21:43:37 localhost kernel: sb: I/O region in use. Sep 30 21:43:37 localhost kernel: printing eip: Sep 30 21:43:37 localhost kernel: c0187903 Sep 30 21:43:37 localhost kernel: Oops: Sep 30 21:43:37 localhost kernel: CPU:0 Sep 30 21:43:37 localhost kernel: EIP:0010:[soundcore_open+191/396] Sep 30 21:43:37 localhost kernel: EFLAGS: 00010282 Sep 30 21:43:37 localhost kernel: eax: c28260e0 ebx: c1e20ea0 ecx: edx: Sep 30 21:43:37 localhost kernel: esi: c0cb3f1c edi: ebp: esp: c0cb3f08 Sep 30 21:43:37 localhost kernel: ds: 0018 es: 0018 ss: 0018 Sep 30 21:43:37 localhost kernel: Process aumix (pid: 312, stackpage=c0cb3000) Sep 30 21:43:37 localhost kernel: Stack: c0300e60 c0c8fb40 c10c71a0 6e756f73 65732d64 63697672 Sep 30 21:43:37 localhost kernel:2d302d65 c0130030 001d c0c8fb40 ffeb c012b195 c0c8fb40 c0300e60 Sep 30 21:43:37 localhost kernel:c0300e60 c0c8fb40 c012a3b0 c0c8fb40 c0300e60 0002 Sep 30 21:43:37 localhost kernel: Call Trace: [copy_mount_options+12/160] [chrdev_open+65/84] [dentry_open+192/332] [filp_open+74/84] [sys_open+56/180] [system_call+51/64] Sep 30 21:43:37 localhost kernel: Code: 8b 10 85 d2 74 17 52 e8 79 dd f8 ff 83 c4 04 85 c0 74 0e 8b Code: Before first symbol <_IP>: <=== Code: Before first symbol 0:8b 10 mov (%eax),%edx <=== Code: 0002 Before first symbol 2:85 d2 test %edx,%edx Code: 0004 Before first symbol 4:74 17 je 001d Before first symbol Code: 0006 Before first symbol 6:52 push %edx Code: 0007 Before first symbol 7:e8 79 dd f8 ff call fff8dd85 Code: 000c Before first symbol c:83 c4 04add $0x4,%esp Code: 000f Before first symbol f:85 c0 test %eax,%eax Code: 0011 Before first symbol 11:74 0e je 0021 Before first symbol Code: 0013 Before first symbol 13:8b 00 mov (%eax),%eax Now trying to figure out what is going on: # cat /proc/ioports Sep 30 21:54:28 localhost kernel: c01ba395 Sep 30 21:54:28 localhost kernel: Oops: Sep 30 21:54:28 localhost kernel: CPU:0 Sep 30 21:54:28 localhost kernel: EIP:0010:[vsprintf+425/844] Sep 30 21:54:28 localhost kernel: EFLAGS: 00010297 Sep 30 21:54:28 localhost kernel: eax: c2830f94 ebx: c07ee0ea ecx: c2830f94 edx: fffe Sep 30 21:54:28 localhost kernel: esi: edi: c123df18 ebp: esp: c123ded4 Sep 30 21:54:28 localhost kernel: ds: 0018 es: 0018 ss: 0018 Sep 30 21:54:28 localhost kernel: Process cat (pid: 459, stackpage=c123d000) Sep 30 21:54:28 localhost kernel: Stack: c07ee0de c1e20e80 0008 c07ef000 fffd 000a c01ba54c Sep 30 21:54:28 localhost kernel:c07ee0de c01c3638 c123df0c c01183da c07ee0de c01c3629 0220 022f Sep 30 21:54:28 localhost kernel:c2830f94 c07ee000 c07ee000 1000 c011843c c01f7900 c01c3621 Sep 30 21:54:28 localhost kernel: Call Trace: [sprintf+20/5592] [IRQ0x0f_interrupt+19144/21320] [do_resource_list+74/124] [IRQ0x0f_interrupt+19129/21320] [] [get_resource_list+48/56] [IRQ0x0f_interrupt+19121/21320] Sep 30 21:54:28 localhost kernel: Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 8b 54 24 14 89 c6 Code: Before first symbol <_IP>: <=== Code: Before first symbol 0:80 38 00cmpb $0x0,(%eax) <=== Code: 0003 Before first symbol 3:
sound related OOPS (2.4.0-test9-pre7)
Hi! I got the following oopses while issuing the module-load triggering (no modules loaded before, but sound-core compiled into the kernel): richard aumix See below for decoded oops and config/versions - also for a second, but probably "ghost" oops on a # cat /proc/ioports (I checked completely compiled in sound and this works just fine - machine is a Pentium100, non-pnp AWE32, isa-pnp ne2k (but not activated)) No modules in ksyms, skipping objects Sep 30 21:43:37 localhost kernel: isapnp: Scanning for Pnp cards... Sep 30 21:43:37 localhost kernel: isapnp: Card 'PLUG PLAY ETHERNET CARD' Sep 30 21:43:37 localhost kernel: isapnp: 1 Plug Play card detected total Sep 30 21:43:37 localhost kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 Sep 30 21:43:37 localhost kernel: sb: No ISAPnP cards found, trying standard ones... Sep 30 21:43:37 localhost kernel: SB 4.13 detected OK (220) Sep 30 21:43:37 localhost kernel: Sound Blaster 16 (4.13) at 0x220 irq 5 dma 1,5 Sep 30 21:43:37 localhost kernel: Sound Blaster 16 at 0x330 irq 5 dma 0,0 Sound: Hmm, DMA1 was left allocated - fixed Sound: Hmm, DMA5 was left allocated - fixed Sep 30 21:43:37 localhost kernel: sb: I/O region in use. Sep 30 21:43:37 localhost kernel: printing eip: Sep 30 21:43:37 localhost kernel: c0187903 Sep 30 21:43:37 localhost kernel: Oops: Sep 30 21:43:37 localhost kernel: CPU:0 Sep 30 21:43:37 localhost kernel: EIP:0010:[soundcore_open+191/396] Sep 30 21:43:37 localhost kernel: EFLAGS: 00010282 Sep 30 21:43:37 localhost kernel: eax: c28260e0 ebx: c1e20ea0 ecx: edx: Sep 30 21:43:37 localhost kernel: esi: c0cb3f1c edi: ebp: esp: c0cb3f08 Sep 30 21:43:37 localhost kernel: ds: 0018 es: 0018 ss: 0018 Sep 30 21:43:37 localhost kernel: Process aumix (pid: 312, stackpage=c0cb3000) Sep 30 21:43:37 localhost kernel: Stack: c0300e60 c0c8fb40 c10c71a0 6e756f73 65732d64 63697672 Sep 30 21:43:37 localhost kernel:2d302d65 c0130030 001d c0c8fb40 ffeb c012b195 c0c8fb40 c0300e60 Sep 30 21:43:37 localhost kernel:c0300e60 c0c8fb40 c012a3b0 c0c8fb40 c0300e60 0002 Sep 30 21:43:37 localhost kernel: Call Trace: [copy_mount_options+12/160] [chrdev_open+65/84] [dentry_open+192/332] [filp_open+74/84] [sys_open+56/180] [system_call+51/64] Sep 30 21:43:37 localhost kernel: Code: 8b 10 85 d2 74 17 52 e8 79 dd f8 ff 83 c4 04 85 c0 74 0e 8b Code: Before first symbol _IP: === Code: Before first symbol 0:8b 10 mov (%eax),%edx === Code: 0002 Before first symbol 2:85 d2 test %edx,%edx Code: 0004 Before first symbol 4:74 17 je 001d Before first symbol Code: 0006 Before first symbol 6:52 push %edx Code: 0007 Before first symbol 7:e8 79 dd f8 ff call fff8dd85 END_OF_CODE+3fd2f535/ Code: 000c Before first symbol c:83 c4 04add $0x4,%esp Code: 000f Before first symbol f:85 c0 test %eax,%eax Code: 0011 Before first symbol 11:74 0e je 0021 Before first symbol Code: 0013 Before first symbol 13:8b 00 mov (%eax),%eax Now trying to figure out what is going on: # cat /proc/ioports Sep 30 21:54:28 localhost kernel: c01ba395 Sep 30 21:54:28 localhost kernel: Oops: Sep 30 21:54:28 localhost kernel: CPU:0 Sep 30 21:54:28 localhost kernel: EIP:0010:[vsprintf+425/844] Sep 30 21:54:28 localhost kernel: EFLAGS: 00010297 Sep 30 21:54:28 localhost kernel: eax: c2830f94 ebx: c07ee0ea ecx: c2830f94 edx: fffe Sep 30 21:54:28 localhost kernel: esi: edi: c123df18 ebp: esp: c123ded4 Sep 30 21:54:28 localhost kernel: ds: 0018 es: 0018 ss: 0018 Sep 30 21:54:28 localhost kernel: Process cat (pid: 459, stackpage=c123d000) Sep 30 21:54:28 localhost kernel: Stack: c07ee0de c1e20e80 0008 c07ef000 fffd 000a c01ba54c Sep 30 21:54:28 localhost kernel:c07ee0de c01c3638 c123df0c c01183da c07ee0de c01c3629 0220 022f Sep 30 21:54:28 localhost kernel:c2830f94 c07ee000 c07ee000 1000 c011843c c01f7900 c01c3621 Sep 30 21:54:28 localhost kernel: Call Trace: [sprintf+20/5592] [IRQ0x0f_interrupt+19144/21320] [do_resource_list+74/124] [IRQ0x0f_interrupt+19129/21320] [c2830f94] [get_resource_list+48/56] [IRQ0x0f_interrupt+19121/21320] Sep 30 21:54:28 localhost kernel: Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 8b 54 24 14 89 c6 Code: Before first symbol _IP: === Code: Before first symbol 0:80 38 00cmpb $0x0,(%eax)
[PATCH] fix for VM test9-pre7
Hi,
The attached patch seems to fix all the reported deadlock
problems with the new VM. Basically they could be grouped
into 2 categories:
1) __GFP_IO related locking issues
2) something sleeps on a free/clean/inactive page goal
that isn't worked towards
The patch has survived some heavy stresstesting on both
SMP and UP machines. I hope nobody will be able to find
a way to still crash this one ;)
A second change is a more dynamic free memory target
(now freepages.high + inactive_target / 3), this seems
to help a little bit in some loads.
If your mailer messes up the patch, you can grab it from
http://www.surriel.com/patches/2.4.0-t9p7-vmpatch
Linus, if this patch turns out to work fine for the people
testing it, could you please apply it to your tree?
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
--- linux-2.4.0-test9-pre7/fs/buffer.c.orig Sat Sep 30 18:09:18 2000
+++ linux-2.4.0-test9-pre7/fs/buffer.c Mon Oct 2 00:19:41 2000
@@ -706,7 +706,9 @@
static void refill_freelist(int size)
{
if (!grow_buffers(size)) {
- try_to_free_pages(GFP_BUFFER);
+ wakeup_bdflush(1);
+ current-policy |= SCHED_YIELD;
+ schedule();
}
}
@@ -859,6 +861,7 @@
int balance_dirty_state(kdev_t dev)
{
unsigned long dirty, tot, hard_dirty_limit, soft_dirty_limit;
+ int shortage;
dirty = size_buffers_type[BUF_DIRTY] PAGE_SHIFT;
tot = nr_free_buffer_pages();
@@ -869,21 +872,20 @@
/* First, check for the "real" dirty limit. */
if (dirty soft_dirty_limit) {
- if (dirty hard_dirty_limit || inactive_shortage())
+ if (dirty hard_dirty_limit)
return 1;
return 0;
}
/*
-* Then, make sure the number of inactive pages won't overwhelm
-* page replacement ... this should avoid stalls.
+* If we are about to get low on free pages and
+* cleaning the inactive_dirty pages would help
+* fix this, wake up bdflush.
*/
- if (nr_inactive_dirty_pages
- nr_free_pages() + nr_inactive_clean_pages()) {
- if (free_shortage() freepages.min)
- return 1;
+ if (free_shortage() nr_inactive_dirty_pages free_shortage()
+ nr_inactive_dirty_pages freepages.high)
return 0;
- }
+
return -1;
}
@@ -2663,9 +2665,8 @@
CHECK_EMERGENCY_SYNC
flushed = flush_dirty_buffers(0);
- if (nr_inactive_dirty_pages nr_free_pages() +
- nr_inactive_clean_pages())
- flushed += page_launder(GFP_KSWAPD, 0);
+ if (free_shortage())
+ flushed += page_launder(GFP_BUFFER, 0);
/* If wakeup_bdflush will wakeup us
after our bdflush_done wakeup, then
--- linux-2.4.0-test9-pre7/mm/filemap.c.origSat Sep 30 18:16:28 2000
+++ linux-2.4.0-test9-pre7/mm/filemap.c Mon Oct 2 00:11:45 2000
@@ -44,7 +44,6 @@
atomic_t page_cache_size = ATOMIC_INIT(0);
unsigned int page_hash_bits;
struct page **page_hash_table;
-struct list_head lru_cache;
spinlock_t pagecache_lock = SPIN_LOCK_UNLOCKED;
/*
--- linux-2.4.0-test9-pre7/mm/page_alloc.c.orig Sat Sep 30 18:16:28 2000
+++ linux-2.4.0-test9-pre7/mm/page_alloc.c Mon Oct 2 00:31:15 2000
@@ -258,13 +258,13 @@
*/
switch (limit) {
default:
- case 0:
+ case PAGES_MIN:
water_mark = z-pages_min;
break;
- case 1:
+ case PAGES_LOW:
water_mark = z-pages_low;
break;
- case 2:
+ case PAGES_HIGH:
water_mark = z-pages_high;
}
@@ -318,10 +318,19 @@
direct_reclaim = 1;
/*
-* Are we low on inactive pages?
+* If we are about to get low on free pages and we also have
+* an inactive page shortage, wake up kswapd.
*/
if (inactive_shortage() inactive_target / 2 free_shortage())
wakeup_kswapd(0);
+ /*
+* If we are about to get low on free pages and cleaning
+* the inactive_dirty pages would fix the situation,
+* wake up bdflush.
+*/
+ else if (free_shortage() nr_inactive_dirty_pages free_shortage()
+nr_inactive_dirty_pages freepages.high)
+ wakeup_bdflush(0);
try_again:
/*
@@ -378,8 +387,23 @@
Re: test9-pre7 doesn't recognize HiSax ISDN card
:- "Pierfrancesco" == Pierfrancesco Caci [EMAIL PROTECTED] writes: The subject tells everything: disregard... the subject tells that I shouldn't compile kernels past midnight :-) Sorry for the noise. Pf -- --- Pierfrancesco Caci | ik5pvx | mailto:[EMAIL PROTECTED] - http://gusp.dyndns.org Firenze - Italia | Office for the Complication of Otherwise Simple Affairs Linux penny 2.4.0-test8 #1 Sun Oct 1 20:23:27 CEST 2000 i686 unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
uhci bad, usb-uhci good in test9-pre7
In 2.4.0-test9-pre7, uhci module does not reliably. I have a Logitech N48 wheel mouse attached, it's the only USB device. I can use the mouse fine in X via /dev/input interface (except that input moule's reference count is still zero). But when I switch to text console (and maybe move the mouse) and switch back to X, the mouse is dead. Unplug+plug cures it until the next console switch. I have also a PS/2 mouse attached and I'm using it via gpm on text consoles (if this is of any importance). usb-uhci module seems to be OK. In 2.2.18pre12 backport, uhci seems to work also, it's only 2.4 that's broken at the first glance. USB controller is VIA KT133 onboard USB: 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) 00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) --- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
uhci bad, usb-uhci good in test9-pre7
In 2.4.0-test9-pre7, uhci module does not reliably. I have a Logitech N48 wheel mouse attached, it's the only USB device. I can use the mouse fine in X via /dev/input interface (except that input moule's reference count is still zero). But when I switch to text console (and maybe move the mouse) and switch back to X, the mouse is dead. Unplug+plug cures it until the next console switch. I have also a PS/2 mouse attached and I'm using it via gpm on text consoles (if this is of any importance). usb-uhci module seems to be OK. In 2.2.18pre12 backport, uhci seems to work also, it's only 2.4 that's broken at the first glance. USB controller is VIA KT133 onboard USB: 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) 00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) --- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
success: can boot 2.4.0-test9-pre7
Now I can boot it. I've compiled as Pentium MMX without MTRR support. The PC is a PIII IDE. Kernel test9-pre5 could'nt boot, compiled as PIII and with MTTR support. The kernel run fine here :) (and fast!) :-) Yuri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
BUG in sched.c: 698 / Oops in test9-pre7
Amazing quantity of oopsen in test9-pre7. Acres of addresses are printk-ed to my serial terminal, while one oops after another happens. Usually, it happens when Netscape tries talking to our NNTP server over the Tulip (Linux Tulip driver version 0.9.10 (September 6, 2000)) card. It takes about 2/3 of a day for the system to die in this way. We have 192MB ram, and very little (if any) of the 512MB swap is used when it falls over. Seti@home is running constantly. However, scrolling past, one can make out: BUG in sched.c: 698 ...Invalid operand time and time again. The final oops printed nothing but a stack trace (at 9600 baud) for twenty minutes, so I hit the big button. 2.4.0-test7 did not do this. JHW - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre7 oops
I tried to add a new mail filter in pine, but when pressing 'x' (eXtrahdr) in "AllText pattern" field, it dies segfaulting. On the next try it oopsed. The box went all dead (no sysrq, no ping). All disks IDE, ext2. /home is NFS mounted from 2.2.15 machine. This happened on console, while X wasn't running. While X is running it locks up on average once per day (but I can't determine whether it is the new kernel or the new XFree). I tried to reproduce this, but only managed to crash pine over and over again. test7 and test4 have worked flawlessly for many days, test4 was up for maybe 1 month without a glitch. Technical info: 2xPII-233, 288M memory, 500M swap, ALSA modules compiled, but not necessarily loaded and definetely not used. fbcon with matroxfb compiled in and in use. uptime was on the order of 20-30 hours. Very light load. OOPS message copied from screen to paper and back, so there _may_ be typos. More info available on request. ksymoops 2.3.4 on i686 2.4.0-test9. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9/ (default) -m /boot/System.map-2.4.0t9p7-1 (specified) Warning (compare_maps): snd symbol pm_register not found in /lib/modules/2.4.0-test9/misc/snd.o. Ignoring /lib/modules/2.4.0-test9/misc/snd.o entry Warning (compare_maps): snd symbol pm_send not found in /lib/modules/2.4.0-test9/misc/snd.o. Ignoring /lib/modules/2.4.0-test9/misc/snd.o entry Warning (compare_maps): snd symbol pm_unregister not found in /lib/modules/2.4.0-test9/misc/snd.o. Ignoring /lib/modules/2.4.0-test9/misc/snd.o entry invalid operand: CPU: 1 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: 001c ebx: cf2b6180 ecx: 0020 edx: 0001 esi: c15e8900 edi: 0002 ebp: 0001 esp: d1fe5eb4 ds: 0018 es: 0018 ss: 0018 Stack: c025c643 c025c97a 02da c01770d1 cf2b6180 0001 c15e8900 0046 c14ead80 c034fbc0 c01a828a c15e8900 0001 c034f7e4 c15e8900 c034f700 c01ae4c4 0001 c14ead80 c034f700 c14ead80 0286 c01a9b37 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c c3 57 56 53 8b 74 24 10 8b 54 24 14 85 d2 74 >>EIP; c013412a<= Trace; c025c645 Trace; c025c97a Trace; c01770d1 Trace; c01a828a Trace; c01ae4c4 Trace; c01a9b33 Trace; c01ae460 Trace; c010c331 Trace; c010c516 Trace; c0108e00 Trace; c0108e00 Trace; c010ac64 Trace; c0108e00 Trace; c0100018 Trace; c0108e2d Trace; c0108e92 Trace; c01ee1a7 Trace; c018979f Code; c013412a <_EIP>: Code; c013412a<= 0: 0f 0b ud2a <= Code; c013412c 2: 83 c4 0c add$0xc,%esp Code; c013412f 5: c3ret Code; c0134130 6: 57push %edi Code; c0134131 7: 56push %esi Code; c0134132 8: 53push %ebx Code; c0134133 9: 8b 74 24 10 mov0x10(%esp,1),%esi Code; c0134137 d: 8b 54 24 14 mov0x14(%esp,1),%edx Code; c013413b 11: 85 d2 test %edx,%edx Code; c013413d 13: 74 00 je 15 <_EIP+0x15> c013413f Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! 3 warnings issued. Results may not be reliable. Taneli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre7 oops
I tried to add a new mail filter in pine, but when pressing 'x' (eXtrahdr) in "AllText pattern" field, it dies segfaulting. On the next try it oopsed. The box went all dead (no sysrq, no ping). All disks IDE, ext2. /home is NFS mounted from 2.2.15 machine. This happened on console, while X wasn't running. While X is running it locks up on average once per day (but I can't determine whether it is the new kernel or the new XFree). I tried to reproduce this, but only managed to crash pine over and over again. test7 and test4 have worked flawlessly for many days, test4 was up for maybe 1 month without a glitch. Technical info: 2xPII-233, 288M memory, 500M swap, ALSA modules compiled, but not necessarily loaded and definetely not used. fbcon with matroxfb compiled in and in use. uptime was on the order of 20-30 hours. Very light load. OOPS message copied from screen to paper and back, so there _may_ be typos. More info available on request. ksymoops 2.3.4 on i686 2.4.0-test9. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9/ (default) -m /boot/System.map-2.4.0t9p7-1 (specified) Warning (compare_maps): snd symbol pm_register not found in /lib/modules/2.4.0-test9/misc/snd.o. Ignoring /lib/modules/2.4.0-test9/misc/snd.o entry Warning (compare_maps): snd symbol pm_send not found in /lib/modules/2.4.0-test9/misc/snd.o. Ignoring /lib/modules/2.4.0-test9/misc/snd.o entry Warning (compare_maps): snd symbol pm_unregister not found in /lib/modules/2.4.0-test9/misc/snd.o. Ignoring /lib/modules/2.4.0-test9/misc/snd.o entry invalid operand: CPU: 1 EIP: 0010:[c013412a] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: 001c ebx: cf2b6180 ecx: 0020 edx: 0001 esi: c15e8900 edi: 0002 ebp: 0001 esp: d1fe5eb4 ds: 0018 es: 0018 ss: 0018 Stack: c025c643 c025c97a 02da c01770d1 cf2b6180 0001 c15e8900 0046 c14ead80 c034fbc0 c01a828a c15e8900 0001 c034f7e4 c15e8900 c034f700 c01ae4c4 0001 c14ead80 c034f700 c14ead80 0286 c01a9b37 Call Trace: [c025c645] [c025c97a] [c01770d1] [c01a828a] [c01ae4c4] [c01a9b33] [c01ae460] [c010c331] [c010c516] [c0108e00] [c0108e00] [c010ac64] [c0108e00] [c0100018] [c0108e2d] [c0108e92] [c01ee1a7] [c018979f] Code: 0f 0b 83 c4 0c c3 57 56 53 8b 74 24 10 8b 54 24 14 85 d2 74 EIP; c013412a end_buffer_io_bad+52/58 = Trace; c025c645 tvecs+377d/18eb8 Trace; c025c97a tvecs+3ab2/18eb8 Trace; c01770d1 end_that_request_first+61/b8 Trace; c01a828a ide_end_request+32/84 Trace; c01ae4c4 ide_dma_intr+64/9c Trace; c01a9b33 ide_intr+12f/198 Trace; c01ae460 ide_dma_intr+0/9c Trace; c010c331 handle_IRQ_event+4d/78 Trace; c010c516 do_IRQ+a6/f4 Trace; c0108e00 default_idle+0/34 Trace; c0108e00 default_idle+0/34 Trace; c010ac64 ret_from_intr+0/20 Trace; c0108e00 default_idle+0/34 Trace; c0100018 startup_32+18/cc Trace; c0108e2d default_idle+2d/34 Trace; c0108e92 cpu_idle+3e/54 Trace; c01ee1a7 vgacon_cursor+197/1a0 Trace; c018979f poke_blanked_console+57/5c Code; c013412a end_buffer_io_bad+52/58 _EIP: Code; c013412a end_buffer_io_bad+52/58 = 0: 0f 0b ud2a = Code; c013412c end_buffer_io_bad+54/58 2: 83 c4 0c add$0xc,%esp Code; c013412f end_buffer_io_bad+57/58 5: c3ret Code; c0134130 end_buffer_io_async+0/e4 6: 57push %edi Code; c0134131 end_buffer_io_async+1/e4 7: 56push %esi Code; c0134132 end_buffer_io_async+2/e4 8: 53push %ebx Code; c0134133 end_buffer_io_async+3/e4 9: 8b 74 24 10 mov0x10(%esp,1),%esi Code; c0134137 end_buffer_io_async+7/e4 d: 8b 54 24 14 mov0x14(%esp,1),%edx Code; c013413b end_buffer_io_async+b/e4 11: 85 d2 test %edx,%edx Code; c013413d end_buffer_io_async+d/e4 13: 74 00 je 15 _EIP+0x15 c013413f end_buffer_io_async+f/e4 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! 3 warnings issued. Results may not be reliable. Taneli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
BUG in sched.c: 698 / Oops in test9-pre7
Amazing quantity of oopsen in test9-pre7. Acres of addresses are printk-ed to my serial terminal, while one oops after another happens. Usually, it happens when Netscape tries talking to our NNTP server over the Tulip (Linux Tulip driver version 0.9.10 (September 6, 2000)) card. It takes about 2/3 of a day for the system to die in this way. We have 192MB ram, and very little (if any) of the 512MB swap is used when it falls over. Seti@home is running constantly. However, scrolling past, one can make out: BUG in sched.c: 698 ...Invalid operand time and time again. The final oops printed nothing but a stack trace (at 9600 baud) for twenty minutes, so I hit the big button. 2.4.0-test7 did not do this. JHW - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
success: can boot 2.4.0-test9-pre7
Now I can boot it. I've compiled as Pentium MMX without MTRR support. The PC is a PIII IDE. Kernel test9-pre5 could'nt boot, compiled as PIII and with MTTR support. The kernel run fine here :) (and fast!) :-) Yuri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH: Fix to slab.c for SMP (test9-pre7) (v2)
Hi
After some rethought over the patch (and feedback from Linus)
I have made another version that should work also on SMP
Sparc.
As always, any comment/feedback/Bug reports/... are welcome.
Later, Juan.
ChangeLog:
v2.0:
- shrink_[id]_caches don't return the number of freed pages, and then
I change the code to reflect that. Just now with per-CPU caches, it
is difficult to make the bookkeeping, with NUMA, things will get only
worse.
- Now, we call smp_call_function with single functions (i.e. don't use
spinlocks). That last point was the problem with Sparcs.
- slab_cache_all_sync changes name to smp_call_function_all_cpus (it
could be a good idea to make that function in a library).
- For freeing the slabs, we now use the same _trick_ that
kmem_tune_cpucache(). The only difference is that, as we are low on
memory, we can't allocate a new cpucache_t*new[] to do the swap. To
resolve that, we change the previous one for NULLs (with an
smp_call_function), we free the slabs (now we are in normal kernel
space, spinlocks/waits/... are safe). And once finished, we assign:
->avail = 0 and set that arrays again with smp_call_function.
Notice that we are serialising that operations with cache_chain_sem,
that means that we can't never mesh the state.
- This last change allowed us to share (indeed) more code with the
case of create the cache.
v1.0:
- shrink_[id]_caches return the count of the freed pages (from ingo
and marelo patch)
- removes the ret variable in smp_call_function (it was unused)
- removes the slab_cache_drain_mask/slab_drain_local_cache and its
references for the timer interrupt code. That calls are now done
with smp_call_function, that lets us to simplify a lot the code (we
don't need the cache_drain_wait queue anymore.
- Change the cache_drain_sem semaphore to cache_all_lock spinlock, as
now we never sleep/schedule while holding it. The name is changed
because it is not only used by the drain rutines it is also used by
the update ones.
- slab_drain_local_cache is divided in the functions:
slab_drain_local_cache
do_ccupdate_local
as we known a compile time _which_ part of the function we want to
call.
- pass the spinlock calls inside slab_cache_all_sync, as they are
needed only when calling that function. The wait queue is not
needed anymore. This function used global variables to pass
arguments to slab_drain_local_cache, that has been changed to use
global arguments.
- do_ccupdate & drain_cpu_caches code has been refunded inside
slab_cache_all_sync, as the same code except for one line.
- In the proccess, the net result are ~40 less lines of code
Thanks to Phillip Rumpf, Stephen Tweedie, Alan Cox, Ingo & the rest of the
people that explained me the SMP/cross CPU mysteries.
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude
base/arch/i386/kernel/smp.c working/arch/i386/kernel/smp.c
--- base/arch/i386/kernel/smp.c Tue Sep 26 03:46:03 2000
+++ working/arch/i386/kernel/smp.c Wed Sep 27 23:45:30 2000
@@ -464,7 +464,7 @@
*/
{
struct call_data_struct data;
- int ret, cpus = smp_num_cpus-1;
+ int cpus = smp_num_cpus-1;
if (!cpus)
return 0;
@@ -485,7 +485,6 @@
while (atomic_read() != cpus)
barrier();
- ret = 0;
if (wait)
while (atomic_read() != cpus)
barrier();
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/dcache.c
working/fs/dcache.c
--- base/fs/dcache.cTue Sep 26 03:34:00 2000
+++ working/fs/dcache.c Thu Sep 28 17:15:28 2000
@@ -551,7 +551,7 @@
* ...
* 6 - base-level: try to shrink a bit.
*/
-int shrink_dcache_memory(int priority, unsigned int gfp_mask)
+void shrink_dcache_memory(int priority, unsigned int gfp_mask)
{
int count = 0;
@@ -567,19 +567,13 @@
* block allocations, but for now:
*/
if (!(gfp_mask & __GFP_IO))
- return 0;
+ return;
if (priority)
count = dentry_stat.nr_unused / priority;
+
prune_dcache(count);
- /* FIXME: kmem_cache_shrink here should tell us
- the number of pages freed, and it should
- work in a __GFP_DMA/__GFP_HIGHMEM behaviour
- to free only the interesting pages in
- function of the needs of the current allocation. */
kmem_cache_shrink(dentry_cache);
-
- return 0;
}
#define NAME_ALLOC_LEN(len)((len+16) & ~15)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/inode.c
working/fs/inode.c
--- base/fs/inode.c Tue Sep 26 03:34:00 2000
+++ working/fs/inode.c Thu Sep 28 17:15:40 2000
@@ -454,7 +454,7 @@
dispose_list(freeable);
}
-int shrink_icache_memory(int priority, int gfp_mask)
+void shrink_icache_memory(int priority, int gfp_mask)
{
int count = 0;
@@ -466,19 +466,13 @@
linux-2.4.0-test9-pre7 Oops
ksymoops 2.3.4 on i686 2.4.0-test9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9/ (default)
-m /boot/System.map-2.4.0-test9 (specified)
Unable to handle kernel paging request at virtual address 0010
c012eca1
*pde =
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210246
eax: ebx: c3135920 ecx: c3135920 edx: 0010
esi: c31358c0 edi: c31359e0 ebp: c10549f4 esp: c1127f70
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 2, stackpage=c1127000)
Stack: c01310d4 c3135920 c10549f4 c1054a10 02ac 01a3 0001
c01292a3 c10549f4 0004
c0129a7c 0004 c01d80d1
Call Trace: [] [] [] [] []
[]
Code: 89 02 c7 41 30 00 00 00 00 0f b7 41 0a 50 51 e8 0f ff ff ff
>>EIP; c012eca1 <__remove_from_queues+19/34> <=
Trace; c01310d4
Trace; c01292a3
Trace; c0129a7c
Trace; c01d80d1
Trace; c0129b49
Trace; c01089e4
Code; c012eca1 <__remove_from_queues+19/34>
<_EIP>:
Code; c012eca1 <__remove_from_queues+19/34> <=
0: 89 02 mov%eax,(%edx) <=
Code; c012eca3 <__remove_from_queues+1b/34>
2: c7 41 30 00 00 00 00 movl $0x0,0x30(%ecx)
Code; c012ecaa <__remove_from_queues+22/34>
9: 0f b7 41 0a movzwl 0xa(%ecx),%eax
Code; c012ecae <__remove_from_queues+26/34>
d: 50push %eax
Code; c012ecaf <__remove_from_queues+27/34>
e: 51push %ecx
Code; c012ecb0 <__remove_from_queues+28/34>
f: e8 0f ff ff ffcall ff23 <_EIP+0xff23> c012ebc4
<__remove_from_lru_list+0/68>
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping: 2
cpu MHz : 350.000802
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36
mmx fxsr
bogomips: 699.60
cat /proc/meminfo
total:used:free: shared: buffers: cached:
Mem: 64135168 60022784 41123840 4259840 33619968
Swap: 131600384 2924544 128675840
MemTotal:62632 kB
MemFree: 4016 kB
MemShared: 0 kB
Buffers: 4160 kB
Cached: 32832 kB
Active: 36852 kB
Inact_dirty: 136 kB
Inact_clean: 0 kB
Inact_target:14040 kB
HighTotal: 0 kB
HighFree:0 kB
LowTotal:62632 kB
LowFree: 4016 kB
SwapTotal: 128516 kB
SwapFree: 125660 kB
If you need any more information let me know.
--
L1: khromy ;[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre7 oops (Unable to handle kernel paging request)
I tried booting 2.4.0-test9-pre7 today on my work machine for the first time, and it hung up when one of my user programs was started. The process "receiver_d" uses sockets and shared memory and has worked without problems for years with many kernel versions up through 2.4.0-test9-pre5. I did manage to get this program running after several attempts, so the oops doesn't occur every time. Here is a snippet from /var/log/messages: kernel: Unable to handle kernel paging request at virtual address d0b88ffc kernel: printing eip: kernel: c0190c30 kernel: *pde = 01454063 kernel: *pte = kernel: Oops: kernel: CPU:0 kernel: EIP:0010:[sys_shmat+204/636] kernel: EFLAGS: 00010246 kernel: eax: d0b89000 ebx: ecx: 01b6 edx: kernel: esi: edi: ebp: 0002 esp: cb50ff64 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process receiver_d (pid: 824, stackpage=cb50f000) kernel: Stack: b90c 0003 0001 3800 kernel: c010f65d cb50ffb4 cb50e000 kernel:b90c b910 0003 0022 c010a818 cb50ffc4 c010a6ef kernel: Call Trace: [sys_ipc+361/524] [error_code+44/52] [system_call+51/56] kernel: Code: 8b 04 90 85 c0 75 07 c6 05 64 49 2f c0 01 85 c0 0f 84 8a 01 kernel: NET: 32 messages suppressed. I won't be at my work email until Monday, but can be reached at [EMAIL PROTECTED] if anyone wants to cc any further questions. Thanks, Steven Cole - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre7: partitioning code broken?
On Thu, Sep 28, 2000 at 04:18:00PM +0100, Tigran Aivazian wrote:
> Hi Andries,
>
> I just noticed that this boot message looks very strange:
>
> SCSI device sda: 1039329 512-byte hdwr sectors (532 MB)
> sda: sda1 sda1
Yes, no doubt because of the fragment of a patch for fs/partitions/check.c:
@@ -181,6 +191,10 @@
printk(" p%d", (minor & ((1 << hd->minor_shift) - 1)));
else
printk(" %s", disk_name(hd, minor, buf));
+ if (hd->major >= COMPAQ_CISS_MAJOR+0 && hd->major <= COMPAQ_CISS_MAJOR+7)
+printk(" p%d", (minor & ((1 << hd->minor_shift) - 1)));
+else
+printk(" %s", disk_name(hd, minor, buf));
#endif
}
that someone added for COMPAQ_CISS stuff. As you can see it causes
an additional printk() in the non-COMPAQ_CISS case.
(But this bug has been discussed here already; if it is not fixed
in test9-pre8 or so I'll resubmit the fix.)
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test9-pre7] misc fixes
Hi Linus,
Here is large patch with two small fixes:
a) now that you have rejected my suggestion to remove 'mm' argument from
swapout functions in vmscan.c, it makes sense to, at the _very_ least,
change their code to refer to the passed argument 'mm' instead of
vma->vm_mm as they currently do. On architectures where arguments can be
passed via registers this is an optimization.
b) using Keith' wonderful perl script which analyzes a vmlinux and
suggests what can be moved from data into bss I fixed a few most obvious
"offenders". This is not negligible - we are talking many kilobytes
here... I used "common sense" in addition to the perl script, i.e. I did
_not_ touch things like ATOMIC_INIT(0) or SOME_DEFINE_WITH_ZERO_VALUE
etc...
Regards,
Tigran
diff -urN -X dontdiff linux/arch/i386/kernel/apic.c fixes/arch/i386/kernel/apic.c
--- linux/arch/i386/kernel/apic.c Mon Sep 11 13:34:22 2000
+++ fixes/arch/i386/kernel/apic.c Thu Sep 28 15:24:19 2000
@@ -695,7 +695,7 @@
* [ if a single-CPU system runs an SMP kernel then we call the local
* interrupt as well. Thus we cannot inline the local irq ... ]
*/
-unsigned int apic_timer_irqs [NR_CPUS] = { 0, };
+unsigned int apic_timer_irqs [NR_CPUS];
void smp_apic_timer_interrupt(struct pt_regs * regs)
{
diff -urN -X dontdiff linux/arch/i386/kernel/io_apic.c fixes/arch/i386/kernel/io_apic.c
--- linux/arch/i386/kernel/io_apic.cTue Sep 26 10:38:02 2000
+++ fixes/arch/i386/kernel/io_apic.cThu Sep 28 15:51:45 2000
@@ -38,7 +38,7 @@
/*
* # of IO-APICs and # of IRQ routing registers
*/
-int nr_ioapics = 0;
+int nr_ioapics;
int nr_ioapic_registers[MAX_IO_APICS];
/* I/O APIC entries */
@@ -48,7 +48,7 @@
struct mpc_config_intsrc mp_irqs[MAX_IRQ_SOURCES];
/* MP IRQ source entries */
-int mp_irq_entries = 0;
+int mp_irq_entries;
#if CONFIG_SMP
# define TARGET_CPUS cpu_online_map
@@ -172,8 +172,8 @@
#define MAX_PIRQS 8
int pirq_entries [MAX_PIRQS];
-int pirqs_enabled = 0;
-int skip_ioapic_setup = 0;
+int pirqs_enabled;
+int skip_ioapic_setup;
static int __init ioapic_setup(char *str)
{
diff -urN -X dontdiff linux/arch/i386/kernel/mpparse.c fixes/arch/i386/kernel/mpparse.c
--- linux/arch/i386/kernel/mpparse.cMon Sep 11 13:34:22 2000
+++ fixes/arch/i386/kernel/mpparse.cThu Sep 28 15:52:25 2000
@@ -28,7 +28,7 @@
#include
/* Have we found an MP table */
-int smp_found_config = 0;
+int smp_found_config;
/*
* Various Linux-internal data structures created from the
@@ -37,17 +37,17 @@
int apic_version [MAX_APICS];
int mp_bus_id_to_type [MAX_MP_BUSSES];
int mp_bus_id_to_pci_bus [MAX_MP_BUSSES] = { -1, };
-int mp_current_pci_id = 0;
+int mp_current_pci_id;
int pic_mode;
-unsigned long mp_lapic_addr = 0;
+unsigned long mp_lapic_addr;
/* Processor that is doing the boot up */
unsigned int boot_cpu_id = -1U;
/* Internal processor count */
-static unsigned int num_processors = 0;
+static unsigned int num_processors;
/* Bitmask of physically existing CPUs */
-unsigned long phys_cpu_present_map = 0;
+unsigned long phys_cpu_present_map;
/*
* Intel MP BIOS table parsing routines:
diff -urN -X dontdiff linux/arch/i386/kernel/mtrr.c fixes/arch/i386/kernel/mtrr.c
--- linux/arch/i386/kernel/mtrr.c Tue Sep 26 10:38:02 2000
+++ fixes/arch/i386/kernel/mtrr.c Thu Sep 28 15:19:59 2000
@@ -319,10 +319,10 @@
#endif
#ifdef USERSPACE_INTERFACE
-static char *ascii_buffer = NULL;
-static unsigned int ascii_buf_bytes = 0;
+static char *ascii_buffer;
+static unsigned int ascii_buf_bytes;
#endif
-static unsigned int *usage_table = NULL;
+static unsigned int *usage_table;
static DECLARE_MUTEX(main_lock);
/* Private functions */
@@ -639,7 +639,7 @@
} /* End Function centaur_get_mcr */
static void (*get_mtrr) (unsigned int reg, unsigned long *base,
-unsigned long *size, mtrr_type *type) = NULL;
+unsigned long *size, mtrr_type *type);
static void intel_set_mtrr_up (unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type, int do_safe)
@@ -782,7 +782,7 @@
static void (*set_mtrr_up) (unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type,
- int do_safe) = NULL;
+ int do_safe);
#ifdef CONFIG_SMP
diff -urN -X dontdiff linux/arch/i386/kernel/process.c fixes/arch/i386/kernel/process.c
--- linux/arch/i386/kernel/process.cMon Sep 11 13:34:22 2000
+++ fixes/arch/i386/kernel/process.cThu Sep 28 15:21:01 2000
@@ -50,17 +50,17 @@
asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");
-int hlt_counter=0;
+int hlt_counter;
/*
* Powermanagement idle function, if any..
*/
-void (*pm_idle)(void) = NULL;
+void (*pm_idle)(void);
/*
* Power off function, if any
*/
-void (*pm_power_off)(void) = NULL;
+void (*pm_power_off)(void);
void disable_hlt(void)
{
@@ -149,9 +149,9 @@
2.4.0-test9-pre7: partitioning code broken?
Hi Andries, I just noticed that this boot message looks very strange: SCSI device sda: 1039329 512-byte hdwr sectors (532 MB) sda: sda1 sda1 SCSI device sdb: 196608 512-byte hdwr sectors (101 MB) sdb: Write Protect is off sdb: sdb1 sdb1 information is true: $ grep sd /proc/partitions 8 0 519664 sda 8 1 519152 sda1 816 98304 sdb 817 98288 sdb1 but surely repeating sda1 and sdb1 does look strange? Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre7
On Wed, 27 Sep 2000, Chris Porter wrote: > I am having problems with lockups on an SMP box running > 2.4.0-test9-pre7 for weeks now. I am using it as a network > monitoring machine and I am using the same software on a box > running kernel 2.2.17 with no problems. The error I am > receiveing on the 2.4.0-test9-pre7 box is as follows: > > Unable to handle kernel NULL pointer dereference. > NMI Watchdog detected lockup on CPU1. Could you give us the - decoded - backtrace the NMI oopser prints out just after this message ? regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Performance problems (test9-pre7)
Hi, Just found a particular workload that yields a terrible performance. Running two simultaneous diff like this: diff -uNr linux-2.2.18-pre11 linux-2.2.18-pre11.new diff -uNr linux-2.4.0-test9-pre7 linux-2.4.0-test9-pre7.new And then trying, for example, to open a terminal only succeeded after one of the diff ended (a couple of minutes later). Attached is the 'vmstat 1' output. The file starts after the two diff are running and I'm waiting for the terminal to come up. When the number of blocked processes drops to 0/1 is when one of the diffs ended. This is an UP machine using ext2 on IDE. Rui Sousa r b w swpd free buff cache si sobibo incs us sy id 3 4 0164 1028728 15832 0 0 116 0 172 375 98 2 0 1 5 0164 1060768 15840 0 0 136 0 217 420 97 3 0 1 5 0164948800 15836 0 0 124 0 207 395 95 5 0 2 4 1164948816 15800 0 0 108 0 180 456 96 4 0 2 4 0164 1064624 15888 0 0 15243 198 469 98 2 0 1 5 0164 1100672 15832 0 0 166 0 176 377 98 2 0 2 4 0164 1004696 15836 0 0 138 0 166 364 97 3 0 2 4 0164 1004728 15748 0 0 151 0 181 394 98 2 0 1 5 0164948760 15744 0 0 114 0 179 398 97 3 0 3 4 0164948768 15716 0 0 113 0 190 423 98 2 0 3 4 0164 1084832 15584 0 0 167 0 183 387 95 5 0 2 4 0164952820 15632 0 0 130 0 188 486 96 4 0 2 3 0164 1104876 15380 0 0 212 0 192 474 92 8 0 2 4 0164948928 15444 0 0 125 0 172 382 98 2 0 3 3 0164948856 15500 0 0 12033 196 383 97 3 0 2 4 0164960892 15488 0 0 131 0 177 394 97 3 0 2 3 0164964884 15444 0 0 136 0 170 451 97 3 0 3 2 0164 1084720 15724 0 0 29453 276 519 95 5 0 2 2 0164948732 15056 0 0 1004 0 356 722 92 8 0 1 3 0164 1028648 15916 0 0 631 3 223 494 96 4 0 1 3 0164948664 15884 0 0 932 0 393 802 94 6 0 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 3 0164948672 15868 0 0 835 0 198 407 98 2 0 2 2 0164952644 15884 0 0 366 0 332 730 95 5 0 1 3 0164952644 15872 0 0 186 0 355 711 96 4 0 1 3 0164 1008532 15924 0 0 27439 327 643 96 4 0 2 2 0164948544 15960 0 0 217 0 205 412 99 1 0 2 2 0164 1104560 15788 0 0 283 0 228 436 93 7 0 2 2 0164 1156588 15772 0 0 256 0 192 375 99 1 0 3 2 0164 1456532 15488 0 0 369 0 260 530 94 6 0 2 2 0164 1376552 15552 0 0 225 0 181 367 98 2 0 2 2 0164948564 15940 0 0 264 0 183 394 97 3 0 1 3 0164964588 15936 0 0 239 0 172 364 97 3 0 1 3 0164948608 16096 0 0 185 0 168 338 95 5 0 2 1 0164948660 16140 0 0 109 0 179 453 99 1 0 1 2 0192 1356748 16368 0 28 18153 218 460 95 5 0 2 1 0216 1672820 16632 0 24 132 6 173 363 95 5 0 1 2 0216 1252832 17004 0 0 100 0 175 439 98 2 0 1 4 1212 1556920 17056 8 0 314 0 273 1561 91 9 0 2 2 0212 1148948 17448 0 0 137 0 326 664 96 4 0 3 0 0212 1180988 18076 0 0 427 0 368 1804 94 6 0 3 1 0220 1028 1024 18912 0 8 234 2 365 713 91 9 0 2 0 0220948 1060 18872 0 0 175 0 315 2105 94 6 0 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 1 0220 1852896 18144 0 0 330 100 338 605 95 5 0 2 0 0220 1432920 18516 0 0 243 0 215 404 96 4 0 2 1 0220 1432944 18416 0 0 45739 219 430 98 2 0 3 0 0212 1048980 18976 0 0 452 0 283 550 93 7 0 2 1 0212948 1028 18952 0 0 134 0 299 612 97 3 0 2 1 0212948 1048 18908 0 0 165 0 401 1587 85 15 0 2 0 0208 1028 1100 18868 0 0 377 0 287 607 97 3 0 2 0
Re: 2.4.0-test9-pre7
>>>>> "chris" == Chris Porter <[EMAIL PROTECTED]> writes: chris> I am having problems with lockups on an SMP box running 2.4.0-test9-pre7 for chris> weeks now. I am using it as a network monitoring machine and I am using the chris> same software on a box running kernel 2.2.17 with no problems. The error I am chris> receiveing on the 2.4.0-test9-pre7 box is as follows: chris> Unable to handle kernel NULL pointer dereference. chris> NMI Watchdog detected lockup on CPU1. chris> The System I am using is : chris> Dual Pentium III 800 chris> Super Micro P6DGU chris> Slackware 7.1 Any Oops info, any syslog info ?? With only that information, it is difficult to know what is happening. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre7
"chris" == Chris Porter [EMAIL PROTECTED] writes: chris I am having problems with lockups on an SMP box running 2.4.0-test9-pre7 for chris weeks now. I am using it as a network monitoring machine and I am using the chris same software on a box running kernel 2.2.17 with no problems. The error I am chris receiveing on the 2.4.0-test9-pre7 box is as follows: chris Unable to handle kernel NULL pointer dereference. chris NMI Watchdog detected lockup on CPU1. chris The System I am using is : chris Dual Pentium III 800 chris Super Micro P6DGU chris Slackware 7.1 Any Oops info, any syslog info ?? With only that information, it is difficult to know what is happening. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Performance problems (test9-pre7)
Hi, Just found a particular workload that yields a terrible performance. Running two simultaneous diff like this: diff -uNr linux-2.2.18-pre11 linux-2.2.18-pre11.new diff -uNr linux-2.4.0-test9-pre7 linux-2.4.0-test9-pre7.new And then trying, for example, to open a terminal only succeeded after one of the diff ended (a couple of minutes later). Attached is the 'vmstat 1' output. The file starts after the two diff are running and I'm waiting for the terminal to come up. When the number of blocked processes drops to 0/1 is when one of the diffs ended. This is an UP machine using ext2 on IDE. Rui Sousa r b w swpd free buff cache si sobibo incs us sy id 3 4 0164 1028728 15832 0 0 116 0 172 375 98 2 0 1 5 0164 1060768 15840 0 0 136 0 217 420 97 3 0 1 5 0164948800 15836 0 0 124 0 207 395 95 5 0 2 4 1164948816 15800 0 0 108 0 180 456 96 4 0 2 4 0164 1064624 15888 0 0 15243 198 469 98 2 0 1 5 0164 1100672 15832 0 0 166 0 176 377 98 2 0 2 4 0164 1004696 15836 0 0 138 0 166 364 97 3 0 2 4 0164 1004728 15748 0 0 151 0 181 394 98 2 0 1 5 0164948760 15744 0 0 114 0 179 398 97 3 0 3 4 0164948768 15716 0 0 113 0 190 423 98 2 0 3 4 0164 1084832 15584 0 0 167 0 183 387 95 5 0 2 4 0164952820 15632 0 0 130 0 188 486 96 4 0 2 3 0164 1104876 15380 0 0 212 0 192 474 92 8 0 2 4 0164948928 15444 0 0 125 0 172 382 98 2 0 3 3 0164948856 15500 0 0 12033 196 383 97 3 0 2 4 0164960892 15488 0 0 131 0 177 394 97 3 0 2 3 0164964884 15444 0 0 136 0 170 451 97 3 0 3 2 0164 1084720 15724 0 0 29453 276 519 95 5 0 2 2 0164948732 15056 0 0 1004 0 356 722 92 8 0 1 3 0164 1028648 15916 0 0 631 3 223 494 96 4 0 1 3 0164948664 15884 0 0 932 0 393 802 94 6 0 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 3 0164948672 15868 0 0 835 0 198 407 98 2 0 2 2 0164952644 15884 0 0 366 0 332 730 95 5 0 1 3 0164952644 15872 0 0 186 0 355 711 96 4 0 1 3 0164 1008532 15924 0 0 27439 327 643 96 4 0 2 2 0164948544 15960 0 0 217 0 205 412 99 1 0 2 2 0164 1104560 15788 0 0 283 0 228 436 93 7 0 2 2 0164 1156588 15772 0 0 256 0 192 375 99 1 0 3 2 0164 1456532 15488 0 0 369 0 260 530 94 6 0 2 2 0164 1376552 15552 0 0 225 0 181 367 98 2 0 2 2 0164948564 15940 0 0 264 0 183 394 97 3 0 1 3 0164964588 15936 0 0 239 0 172 364 97 3 0 1 3 0164948608 16096 0 0 185 0 168 338 95 5 0 2 1 0164948660 16140 0 0 109 0 179 453 99 1 0 1 2 0192 1356748 16368 0 28 18153 218 460 95 5 0 2 1 0216 1672820 16632 0 24 132 6 173 363 95 5 0 1 2 0216 1252832 17004 0 0 100 0 175 439 98 2 0 1 4 1212 1556920 17056 8 0 314 0 273 1561 91 9 0 2 2 0212 1148948 17448 0 0 137 0 326 664 96 4 0 3 0 0212 1180988 18076 0 0 427 0 368 1804 94 6 0 3 1 0220 1028 1024 18912 0 8 234 2 365 713 91 9 0 2 0 0220948 1060 18872 0 0 175 0 315 2105 94 6 0 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 1 0220 1852896 18144 0 0 330 100 338 605 95 5 0 2 0 0220 1432920 18516 0 0 243 0 215 404 96 4 0 2 1 0220 1432944 18416 0 0 45739 219 430 98 2 0 3 0 0212 1048980 18976 0 0 452 0 283 550 93 7 0 2 1 0212948 1028 18952 0 0 134 0 299 612 97 3 0 2 1 0212948 1048 18908 0 0 165 0 401 1587 85 15 0 2 0 0208 1028 1100 18868 0 0 377 0 287 607 97 3 0 2 0
Re: 2.4.0-test9-pre7
On Wed, 27 Sep 2000, Chris Porter wrote: I am having problems with lockups on an SMP box running 2.4.0-test9-pre7 for weeks now. I am using it as a network monitoring machine and I am using the same software on a box running kernel 2.2.17 with no problems. The error I am receiveing on the 2.4.0-test9-pre7 box is as follows: Unable to handle kernel NULL pointer dereference. NMI Watchdog detected lockup on CPU1. Could you give us the - decoded - backtrace the NMI oopser prints out just after this message ? regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre7: partitioning code broken?
On Thu, Sep 28, 2000 at 04:18:00PM +0100, Tigran Aivazian wrote:
Hi Andries,
I just noticed that this boot message looks very strange:
SCSI device sda: 1039329 512-byte hdwr sectors (532 MB)
sda: sda1 sda1
Yes, no doubt because of the fragment of a patch for fs/partitions/check.c:
@@ -181,6 +191,10 @@
printk(" p%d", (minor ((1 hd-minor_shift) - 1)));
else
printk(" %s", disk_name(hd, minor, buf));
+ if (hd-major = COMPAQ_CISS_MAJOR+0 hd-major = COMPAQ_CISS_MAJOR+7)
+printk(" p%d", (minor ((1 hd-minor_shift) - 1)));
+else
+printk(" %s", disk_name(hd, minor, buf));
#endif
}
that someone added for COMPAQ_CISS stuff. As you can see it causes
an additional printk() in the non-COMPAQ_CISS case.
(But this bug has been discussed here already; if it is not fixed
in test9-pre8 or so I'll resubmit the fix.)
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre7 oops (Unable to handle kernel paging request)
I tried booting 2.4.0-test9-pre7 today on my work machine for the first time, and it hung up when one of my user programs was started. The process "receiver_d" uses sockets and shared memory and has worked without problems for years with many kernel versions up through 2.4.0-test9-pre5. I did manage to get this program running after several attempts, so the oops doesn't occur every time. Here is a snippet from /var/log/messages: kernel: Unable to handle kernel paging request at virtual address d0b88ffc kernel: printing eip: kernel: c0190c30 kernel: *pde = 01454063 kernel: *pte = kernel: Oops: kernel: CPU:0 kernel: EIP:0010:[sys_shmat+204/636] kernel: EFLAGS: 00010246 kernel: eax: d0b89000 ebx: ecx: 01b6 edx: kernel: esi: edi: ebp: 0002 esp: cb50ff64 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process receiver_d (pid: 824, stackpage=cb50f000) kernel: Stack: b90c 0003 0001 3800 kernel: c010f65d cb50ffb4 cb50e000 kernel:b90c b910 0003 0022 c010a818 cb50ffc4 c010a6ef kernel: Call Trace: [sys_ipc+361/524] [error_code+44/52] [system_call+51/56] kernel: Code: 8b 04 90 85 c0 75 07 c6 05 64 49 2f c0 01 85 c0 0f 84 8a 01 kernel: NET: 32 messages suppressed. I won't be at my work email until Monday, but can be reached at [EMAIL PROTECTED] if anyone wants to cc any further questions. Thanks, Steven Cole - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
linux-2.4.0-test9-pre7 Oops
ksymoops 2.3.4 on i686 2.4.0-test9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9/ (default)
-m /boot/System.map-2.4.0-test9 (specified)
Unable to handle kernel paging request at virtual address 0010
c012eca1
*pde =
Oops: 0002
CPU:0
EIP:0010:[c012eca1]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210246
eax: ebx: c3135920 ecx: c3135920 edx: 0010
esi: c31358c0 edi: c31359e0 ebp: c10549f4 esp: c1127f70
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 2, stackpage=c1127000)
Stack: c01310d4 c3135920 c10549f4 c1054a10 02ac 01a3 0001
c01292a3 c10549f4 0004
c0129a7c 0004 c01d80d1
Call Trace: [c01310d4] [c01292a3] [c0129a7c] [c01d80d1] [c0129b49]
[c01089e4]
Code: 89 02 c7 41 30 00 00 00 00 0f b7 41 0a 50 51 e8 0f ff ff ff
EIP; c012eca1 __remove_from_queues+19/34 =
Trace; c01310d4 try_to_free_buffers+60/138
Trace; c01292a3 page_launder+28b/724
Trace; c0129a7c do_try_to_free_pages+34/84
Trace; c01d80d1 tvecs+1d29/12f18
Trace; c0129b49 kswapd+7d/130
Trace; c01089e4 kernel_thread+28/38
Code; c012eca1 __remove_from_queues+19/34
_EIP:
Code; c012eca1 __remove_from_queues+19/34 =
0: 89 02 mov%eax,(%edx) =
Code; c012eca3 __remove_from_queues+1b/34
2: c7 41 30 00 00 00 00 movl $0x0,0x30(%ecx)
Code; c012ecaa __remove_from_queues+22/34
9: 0f b7 41 0a movzwl 0xa(%ecx),%eax
Code; c012ecae __remove_from_queues+26/34
d: 50push %eax
Code; c012ecaf __remove_from_queues+27/34
e: 51push %ecx
Code; c012ecb0 __remove_from_queues+28/34
f: e8 0f ff ff ffcall ff23 _EIP+0xff23 c012ebc4
__remove_from_lru_list+0/68
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping: 2
cpu MHz : 350.000802
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36
mmx fxsr
bogomips: 699.60
cat /proc/meminfo
total:used:free: shared: buffers: cached:
Mem: 64135168 60022784 41123840 4259840 33619968
Swap: 131600384 2924544 128675840
MemTotal:62632 kB
MemFree: 4016 kB
MemShared: 0 kB
Buffers: 4160 kB
Cached: 32832 kB
Active: 36852 kB
Inact_dirty: 136 kB
Inact_clean: 0 kB
Inact_target:14040 kB
HighTotal: 0 kB
HighFree:0 kB
LowTotal:62632 kB
LowFree: 4016 kB
SwapTotal: 128516 kB
SwapFree: 125660 kB
If you need any more information let me know.
--
L1: khromy ;[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
PATCH: Fix to slab.c for SMP (test9-pre7) (v2)
Hi
After some rethought over the patch (and feedback from Linus)
I have made another version that should work also on SMP
Sparc.
As always, any comment/feedback/Bug reports/... are welcome.
Later, Juan.
ChangeLog:
v2.0:
- shrink_[id]_caches don't return the number of freed pages, and then
I change the code to reflect that. Just now with per-CPU caches, it
is difficult to make the bookkeeping, with NUMA, things will get only
worse.
- Now, we call smp_call_function with single functions (i.e. don't use
spinlocks). That last point was the problem with Sparcs.
- slab_cache_all_sync changes name to smp_call_function_all_cpus (it
could be a good idea to make that function in a library).
- For freeing the slabs, we now use the same _trick_ that
kmem_tune_cpucache(). The only difference is that, as we are low on
memory, we can't allocate a new cpucache_t*new[] to do the swap. To
resolve that, we change the previous one for NULLs (with an
smp_call_function), we free the slabs (now we are in normal kernel
space, spinlocks/waits/... are safe). And once finished, we assign:
-avail = 0 and set that arrays again with smp_call_function.
Notice that we are serialising that operations with cache_chain_sem,
that means that we can't never mesh the state.
- This last change allowed us to share (indeed) more code with the
case of create the cache.
v1.0:
- shrink_[id]_caches return the count of the freed pages (from ingo
and marelo patch)
- removes the ret variable in smp_call_function (it was unused)
- removes the slab_cache_drain_mask/slab_drain_local_cache and its
references for the timer interrupt code. That calls are now done
with smp_call_function, that lets us to simplify a lot the code (we
don't need the cache_drain_wait queue anymore.
- Change the cache_drain_sem semaphore to cache_all_lock spinlock, as
now we never sleep/schedule while holding it. The name is changed
because it is not only used by the drain rutines it is also used by
the update ones.
- slab_drain_local_cache is divided in the functions:
slab_drain_local_cache
do_ccupdate_local
as we known a compile time _which_ part of the function we want to
call.
- pass the spinlock calls inside slab_cache_all_sync, as they are
needed only when calling that function. The wait queue is not
needed anymore. This function used global variables to pass
arguments to slab_drain_local_cache, that has been changed to use
global arguments.
- do_ccupdate drain_cpu_caches code has been refunded inside
slab_cache_all_sync, as the same code except for one line.
- In the proccess, the net result are ~40 less lines of code
Thanks to Phillip Rumpf, Stephen Tweedie, Alan Cox, Ingo the rest of the
people that explained me the SMP/cross CPU mysteries.
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude
base/arch/i386/kernel/smp.c working/arch/i386/kernel/smp.c
--- base/arch/i386/kernel/smp.c Tue Sep 26 03:46:03 2000
+++ working/arch/i386/kernel/smp.c Wed Sep 27 23:45:30 2000
@@ -464,7 +464,7 @@
*/
{
struct call_data_struct data;
- int ret, cpus = smp_num_cpus-1;
+ int cpus = smp_num_cpus-1;
if (!cpus)
return 0;
@@ -485,7 +485,6 @@
while (atomic_read(data.started) != cpus)
barrier();
- ret = 0;
if (wait)
while (atomic_read(data.finished) != cpus)
barrier();
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/dcache.c
working/fs/dcache.c
--- base/fs/dcache.cTue Sep 26 03:34:00 2000
+++ working/fs/dcache.c Thu Sep 28 17:15:28 2000
@@ -551,7 +551,7 @@
* ...
* 6 - base-level: try to shrink a bit.
*/
-int shrink_dcache_memory(int priority, unsigned int gfp_mask)
+void shrink_dcache_memory(int priority, unsigned int gfp_mask)
{
int count = 0;
@@ -567,19 +567,13 @@
* block allocations, but for now:
*/
if (!(gfp_mask __GFP_IO))
- return 0;
+ return;
if (priority)
count = dentry_stat.nr_unused / priority;
+
prune_dcache(count);
- /* FIXME: kmem_cache_shrink here should tell us
- the number of pages freed, and it should
- work in a __GFP_DMA/__GFP_HIGHMEM behaviour
- to free only the interesting pages in
- function of the needs of the current allocation. */
kmem_cache_shrink(dentry_cache);
-
- return 0;
}
#define NAME_ALLOC_LEN(len)((len+16) ~15)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/inode.c
working/fs/inode.c
--- base/fs/inode.c Tue Sep 26 03:34:00 2000
+++ working/fs/inode.c Thu Sep 28 17:15:40 2000
@@ -454,7 +454,7 @@
dispose_list(freeable);
}
-int shrink_icache_memory(int priority, int gfp_mask)
+void shrink_icache_memory(int priority, int gfp_mask)
{
int count = 0;
@@
2.4.0-test9-pre7
I am having problems with lockups on an SMP box running 2.4.0-test9-pre7 for weeks now. I am using it as a network monitoring machine and I am using the same software on a box running kernel 2.2.17 with no problems. The error I am receiveing on the 2.4.0-test9-pre7 box is as follows: Unable to handle kernel NULL pointer dereference. NMI Watchdog detected lockup on CPU1. The System I am using is : Dual Pentium III 800 Super Micro P6DGU Slackware 7.1 Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH: Fix to slab.c for SMP (test9-pre7)
Hi
In previous mails I reported that test9-preX (X>=3) freezes
when running in SMP mmap001. I have found that the problem
was in how was handing the slab cache by cpu. With this patch
mmap001 returns to work (i.e. it loops a lot in the VM layer,
but the same loops than in UP).
Linus, if you see no problems, please apply. (If you want the patch
without the shrink_[id]_caches part, please, let me know).
This patch does:
- shrink_[id]_caches return the count of the freed pages (from ingo
and marcelo patch)
- removes the ret variable in smp_call_function (it was unused)
- removes the slab_cache_drain_mask/slab_drain_local_cache and its
references for the timer interrupt code. That calls are now done
with smp_call_function, that lets us to simplify a lot the code (we
don't need the cache_drain_wait queue anymore.
- Change the cache_drain_sem semaphore to cache_all_lock spinlock, as
now we never sleep/schedule while holding it. The name is changed
because it is not only used by the drain routines it is also used by
the update ones.
- slab_drain_local_cache is divided in the functions:
slab_drain_local_cache
do_ccupdate_local
as we known a compile time _which_ part of the function we want to
call.
- pass the spinlock calls inside slab_cache_all_sync, as they are
needed only when calling that function. The wait queue is not
needed anymore. This function used global variables to pass
arguments to slab_drain_local_cache, that has been changed to use
global arguments.
- do_ccupdate & drain_cpu_caches code has been refunded inside
slab_cache_all_sync, as the same code except for one line.
- In the process, the net result are ~40 less lines of code
Thanks to Phillip Rumpf, Stephen Tweedie, Alan Cox, Ingo & the rest of the
people that explained me the SMP/cross CPU mysteries.
Any comments, suggestions are welcome
Later, Juan.
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude
base/arch/i386/kernel/smp.c working/arch/i386/kernel/smp.c
--- base/arch/i386/kernel/smp.c Tue Sep 26 03:46:03 2000
+++ working/arch/i386/kernel/smp.c Wed Sep 27 23:45:30 2000
@@ -464,7 +464,7 @@
*/
{
struct call_data_struct data;
- int ret, cpus = smp_num_cpus-1;
+ int cpus = smp_num_cpus-1;
if (!cpus)
return 0;
@@ -485,7 +485,6 @@
while (atomic_read() != cpus)
barrier();
- ret = 0;
if (wait)
while (atomic_read() != cpus)
barrier();
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/dcache.c
working/fs/dcache.c
--- base/fs/dcache.cTue Sep 26 03:34:00 2000
+++ working/fs/dcache.c Wed Sep 27 00:34:13 2000
@@ -572,14 +572,8 @@
if (priority)
count = dentry_stat.nr_unused / priority;
prune_dcache(count);
- /* FIXME: kmem_cache_shrink here should tell us
- the number of pages freed, and it should
- work in a __GFP_DMA/__GFP_HIGHMEM behaviour
- to free only the interesting pages in
- function of the needs of the current allocation. */
- kmem_cache_shrink(dentry_cache);
- return 0;
+ return kmem_cache_shrink(dentry_cache);
}
#define NAME_ALLOC_LEN(len)((len+16) & ~15)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/inode.c
working/fs/inode.c
--- base/fs/inode.c Tue Sep 26 03:34:00 2000
+++ working/fs/inode.c Wed Sep 27 00:34:13 2000
@@ -471,14 +471,8 @@
if (priority)
count = inodes_stat.nr_unused / priority;
prune_icache(count);
- /* FIXME: kmem_cache_shrink here should tell us
- the number of pages freed, and it should
- work in a __GFP_DMA/__GFP_HIGHMEM behaviour
- to free only the interesting pages in
- function of the needs of the current allocation. */
- kmem_cache_shrink(inode_cachep);
- return 0;
+ return kmem_cache_shrink(inode_cachep);
}
/*
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude
base/include/linux/slab.h working/include/linux/slab.h
--- base/include/linux/slab.h Wed Sep 27 00:16:36 2000
+++ working/include/linux/slab.hWed Sep 27 16:23:51 2000
@@ -76,14 +76,6 @@
extern kmem_cache_t*fs_cachep;
extern kmem_cache_t*sigact_cachep;
-#ifdef CONFIG_SMP
-extern unsigned long slab_cache_drain_mask;
-extern void slab_drain_local_cache(void);
-#else
-#define slab_cache_drain_mask 0
-#define slab_drain_local_cache() do { } while (0)
-#endif
-
#endif /* __KERNEL__ */
#endif /* _LINUX_SLAB_H */
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/kernel/timer.c
working/kernel/timer.c
--- base/kernel/timer.c Mon Aug 28 23:28:27 2000
+++ working/kernel/timer.c Wed Sep 27 23:38:09 2000
@@ -22,7 +22,6 @@
#include
#include
#include
-#include
#include
@@ -596,9 +595,6 @@
test9-pre7 lockup
This has happened three times now, when dd'ing a boot image to a floppy. The screen goes blank, Alt+SysRq don't seem to have any effect. System: Athlon 800 KA7-100 RedHat 7.0 The first time there was a data CRC error listed in /var/log/messages, so I tried with a different floppy, but the same thing happened, this time with no syslog output. Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtrr.c for linux-2.4.0-test9-pre7
> On mtrr.c, it assume that CPU is CyrixIII when cpuid is 0x06XX, and > try to use intel compatible MTRR, so Cyrix MII with MTRR can't work. Oops it shouldnt fall through any more. My fault > Here is the ad hoc patch. And here is a non AdHoc one (the Cyrix III reports itself as CENTAUR which makes sense since they built it and are now like Cyrix part of VIA) Fixed in my 2.2 tree as well --- arch/i386/kernel/mtrr.c~Fri Sep 15 12:42:22 2000 +++ arch/i386/kernel/mtrr.c Wed Sep 27 21:05:41 2000 @@ -440,6 +440,7 @@ /*break;*/ case X86_VENDOR_CYRIX: /* Cyrix have 8 ARRs */ + return 8; case X86_VENDOR_CENTAUR: /* and Centaur has 8 MCR's */ if(boot_cpu_data.x86==5) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtrr.c for linux-2.4.0-test9-pre7
Hi. I found a bug on test9-pre7 mtrr.c about Cyrix MII. When I use linux-2.4.0-test9-pre4 with MTRR enable, it works fine. But when I try to boot linux-2.4.0-test9-pre7, GPF occur after "mtrr: v1.36" message, and kernel freeze. My Cyrix MII's cpuid is 0x0628, and CyrixIII's cpuid seems to be 0x0660. On mtrr.c, it assume that CPU is CyrixIII when cpuid is 0x06XX, and try to use intel compatible MTRR, so Cyrix MII with MTRR can't work. Here is the ad hoc patch. --- linux-2.4.0-test9-pre7/arch/i386/kernel/mtrr.c.dist Thu Sep 28 03:15:11 2000 +++ linux-2.4.0-test9-pre7/arch/i386/kernel/mtrr.c Thu Sep 28 03:53:30 2000 @@ -461,7 +461,8 @@ /* Cyrix have 8 ARRs */ case X86_VENDOR_CENTAUR: /* and Centaur has 8 MCR's */ - if(boot_cpu_data.x86==5) + if(boot_cpu_data.x86==5 + || (boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model < 6)) return 8; /* the cyrix III has intel compatible MTRR */ if(boot_cpu_data.x86==6) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtrr.c for linux-2.4.0-test9-pre7
Hi. I found a bug on test9-pre7 mtrr.c about Cyrix MII. When I use linux-2.4.0-test9-pre4 with MTRR enable, it works fine. But when I try to boot linux-2.4.0-test9-pre7, GPF occur after "mtrr: v1.36" message, and kernel freeze. My Cyrix MII's cpuid is 0x0628, and CyrixIII's cpuid seems to be 0x0660. On mtrr.c, it assume that CPU is CyrixIII when cpuid is 0x06XX, and try to use intel compatible MTRR, so Cyrix MII with MTRR can't work. Here is the ad hoc patch. --- linux-2.4.0-test9-pre7/arch/i386/kernel/mtrr.c.dist Thu Sep 28 03:15:11 2000 +++ linux-2.4.0-test9-pre7/arch/i386/kernel/mtrr.c Thu Sep 28 03:53:30 2000 @@ -461,7 +461,8 @@ /* Cyrix have 8 ARRs */ case X86_VENDOR_CENTAUR: /* and Centaur has 8 MCR's */ - if(boot_cpu_data.x86==5) + if(boot_cpu_data.x86==5 + || (boot_cpu_data.x86 == 6 boot_cpu_data.x86_model 6)) return 8; /* the cyrix III has intel compatible MTRR */ if(boot_cpu_data.x86==6) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtrr.c for linux-2.4.0-test9-pre7
On mtrr.c, it assume that CPU is CyrixIII when cpuid is 0x06XX, and try to use intel compatible MTRR, so Cyrix MII with MTRR can't work. Oops it shouldnt fall through any more. My fault Here is the ad hoc patch. And here is a non AdHoc one (the Cyrix III reports itself as CENTAUR which makes sense since they built it and are now like Cyrix part of VIA) Fixed in my 2.2 tree as well --- arch/i386/kernel/mtrr.c~Fri Sep 15 12:42:22 2000 +++ arch/i386/kernel/mtrr.c Wed Sep 27 21:05:41 2000 @@ -440,6 +440,7 @@ /*break;*/ case X86_VENDOR_CYRIX: /* Cyrix have 8 ARRs */ + return 8; case X86_VENDOR_CENTAUR: /* and Centaur has 8 MCR's */ if(boot_cpu_data.x86==5) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre7 lockup
This has happened three times now, when dd'ing a boot image to a floppy. The screen goes blank, Alt+SysRq don't seem to have any effect. System: Athlon 800 KA7-100 RedHat 7.0 The first time there was a data CRC error listed in /var/log/messages, so I tried with a different floppy, but the same thing happened, this time with no syslog output. Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH: Fix to slab.c for SMP (test9-pre7)
Hi
In previous mails I reported that test9-preX (X=3) freezes
when running in SMP mmap001. I have found that the problem
was in how was handing the slab cache by cpu. With this patch
mmap001 returns to work (i.e. it loops a lot in the VM layer,
but the same loops than in UP).
Linus, if you see no problems, please apply. (If you want the patch
without the shrink_[id]_caches part, please, let me know).
This patch does:
- shrink_[id]_caches return the count of the freed pages (from ingo
and marcelo patch)
- removes the ret variable in smp_call_function (it was unused)
- removes the slab_cache_drain_mask/slab_drain_local_cache and its
references for the timer interrupt code. That calls are now done
with smp_call_function, that lets us to simplify a lot the code (we
don't need the cache_drain_wait queue anymore.
- Change the cache_drain_sem semaphore to cache_all_lock spinlock, as
now we never sleep/schedule while holding it. The name is changed
because it is not only used by the drain routines it is also used by
the update ones.
- slab_drain_local_cache is divided in the functions:
slab_drain_local_cache
do_ccupdate_local
as we known a compile time _which_ part of the function we want to
call.
- pass the spinlock calls inside slab_cache_all_sync, as they are
needed only when calling that function. The wait queue is not
needed anymore. This function used global variables to pass
arguments to slab_drain_local_cache, that has been changed to use
global arguments.
- do_ccupdate drain_cpu_caches code has been refunded inside
slab_cache_all_sync, as the same code except for one line.
- In the process, the net result are ~40 less lines of code
Thanks to Phillip Rumpf, Stephen Tweedie, Alan Cox, Ingo the rest of the
people that explained me the SMP/cross CPU mysteries.
Any comments, suggestions are welcome
Later, Juan.
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude
base/arch/i386/kernel/smp.c working/arch/i386/kernel/smp.c
--- base/arch/i386/kernel/smp.c Tue Sep 26 03:46:03 2000
+++ working/arch/i386/kernel/smp.c Wed Sep 27 23:45:30 2000
@@ -464,7 +464,7 @@
*/
{
struct call_data_struct data;
- int ret, cpus = smp_num_cpus-1;
+ int cpus = smp_num_cpus-1;
if (!cpus)
return 0;
@@ -485,7 +485,6 @@
while (atomic_read(data.started) != cpus)
barrier();
- ret = 0;
if (wait)
while (atomic_read(data.finished) != cpus)
barrier();
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/dcache.c
working/fs/dcache.c
--- base/fs/dcache.cTue Sep 26 03:34:00 2000
+++ working/fs/dcache.c Wed Sep 27 00:34:13 2000
@@ -572,14 +572,8 @@
if (priority)
count = dentry_stat.nr_unused / priority;
prune_dcache(count);
- /* FIXME: kmem_cache_shrink here should tell us
- the number of pages freed, and it should
- work in a __GFP_DMA/__GFP_HIGHMEM behaviour
- to free only the interesting pages in
- function of the needs of the current allocation. */
- kmem_cache_shrink(dentry_cache);
- return 0;
+ return kmem_cache_shrink(dentry_cache);
}
#define NAME_ALLOC_LEN(len)((len+16) ~15)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/inode.c
working/fs/inode.c
--- base/fs/inode.c Tue Sep 26 03:34:00 2000
+++ working/fs/inode.c Wed Sep 27 00:34:13 2000
@@ -471,14 +471,8 @@
if (priority)
count = inodes_stat.nr_unused / priority;
prune_icache(count);
- /* FIXME: kmem_cache_shrink here should tell us
- the number of pages freed, and it should
- work in a __GFP_DMA/__GFP_HIGHMEM behaviour
- to free only the interesting pages in
- function of the needs of the current allocation. */
- kmem_cache_shrink(inode_cachep);
- return 0;
+ return kmem_cache_shrink(inode_cachep);
}
/*
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude
base/include/linux/slab.h working/include/linux/slab.h
--- base/include/linux/slab.h Wed Sep 27 00:16:36 2000
+++ working/include/linux/slab.hWed Sep 27 16:23:51 2000
@@ -76,14 +76,6 @@
extern kmem_cache_t*fs_cachep;
extern kmem_cache_t*sigact_cachep;
-#ifdef CONFIG_SMP
-extern unsigned long slab_cache_drain_mask;
-extern void slab_drain_local_cache(void);
-#else
-#define slab_cache_drain_mask 0
-#define slab_drain_local_cache() do { } while (0)
-#endif
-
#endif /* __KERNEL__ */
#endif /* _LINUX_SLAB_H */
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/kernel/timer.c
working/kernel/timer.c
--- base/kernel/timer.c Mon Aug 28 23:28:27 2000
+++ working/kernel/timer.c Wed Sep 27 23:38:09 2000
@@ -22,7 +22,6 @@
#include linux/smp_lock.h
#include linux/interrupt.h
test9-pre7 crash
Hi Folks, Sorry if already known. Here is oops I've got on test9-pre7. Not sure what triggered this. As usual when I install new test kernel I do silly simple stress stuff : hdparm -t /dev/sdaX or /dev/hdaX (couple of times) memspeed 150(megs) 10(times) (swaper and mem stress) tcpspeed and udpspeed on loopback (net code stress) And then after a while (1-5 mins) I've started getting crashes, they all looked the same. That's Compaq PIII/124/Adaptec2940/EEpro100(module)/USB (module). 2.4.0-test8 works just fine. So, one of the crashes: Unable to handle kernel NULL pointer dereference at virtual address 0009 c0139902 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 0009 ebx: ecx: 000d edx: 0001 esi: edi: ebp: 0009 esp: c73ebf08 ds: 0018 es: 0018 ss: 0018 Process login (pid: 655, stackpage=c73eb000) Stack: c73ea000 0001 000d 000f c0139a33 0001 0009 c73ebf48 c73ebf4c c73ea000 0001 0001 c73ea000 c0139ca3 0001 0001 c7dd4660 c73ebfb8 Call Trace: [] [] [] [] Code: 8b 45 00 85 c0 7c 59 e8 9a 25 ff ff 89 c6 bb 20 00 00 00 85 >>EIP; c0139902<= Trace; c0139a33 Trace; c0139ca3 Trace; c0118a6e Trace; c0108d3f Code; c0139902 <_EIP>: Code; c0139902<= 0: 8b 45 00 mov0x0(%ebp),%eax <= Code; c0139905 3: 85 c0 test %eax,%eax Code; c0139907 5: 7c 59 jl 60 <_EIP+0x60> c0139962 Code; c0139909 7: e8 9a 25 ff ffcall 25a6 <_EIP+0x25a6> c012bea8 Code; c013990e c: 89 c6 mov%eax,%esi Code; c0139910 e: bb 20 00 00 00mov$0x20,%ebx Code; c0139915 13: 85 00 test %eax,(%eax) Max P.S. CC replies please I'm not on the list. Maksim Krasnyanskiy Senior Kernel Engineer Qualcomm Incorporated [EMAIL PROTECTED] (408) 557-1092 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
On Tue, Sep 26, 2000 at 08:23:04PM +0100, Adam Sampson wrote: > However, I'm probably not a useful datapoint, as I'm running 2.4.0-test8 + > reiserfs-3.9.16 + 2.4.0-t8-sched + 2.4.0-t8-vmpatch4. Just happened again with test9-pre7; looked like it was caused by gcc eating lots of memory and going into swap. -- Adam Sampson [EMAIL PROTECTED], [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
On Tue, Sep 26, 2000 at 03:29:40PM +0200, Helge Hafting wrote: > Unfortunately it still dies occationally. sysrq-Boot is the only thing > that work, > I have no more data as it happened in X and console switching didn't > work. > > Exactly the same behavior as VM crashes in test9-pre5 and earlier. > This is a UP machine with an ide drive, 128M ram and 96M swap. > The (memory) load was light when it crashed during a disk write, > although there were perhaps 20k in swap from some mozilla use > earlier. Exactly the same here. I've seen the same crash three times today (not having suffered from mysterious crashes here): - I do something (typically starting a program; the one I've just seen started this behaviour just as icecast started its extra threads) - The hard disk starts grinding (as if I were going deeply into swap), and my X session freezes - Hitting alt-sysrq-u might work if I'm lucky, but normally only alt-sysrq-b is available However, I'm probably not a useful datapoint, as I'm running 2.4.0-test8 + reiserfs-3.9.16 + 2.4.0-t8-sched + 2.4.0-t8-vmpatch4. The machine's a K6-2 450MHz with 160Mb of RAM, a few IDE disks and an NE2000 card, running XFree86 v4.0.1. Previous 2.4.0-test kernels have been rock solid for me, which is probably a good sign. -- Adam Sampson [EMAIL PROTECTED], [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
On Tue, 26 Sep 2000, Jeff Garzik wrote: > On Mon, 25 Sep 2000, Linus Torvalds wrote: > > - pre7: > > - official Compaq CISS driver. > > He may be the maintainer, but he needs a good spanking... No, the breakage is probably mine. The problem was that you sent me the forward-port of Alan's backport of basically this driver, and then sent me updates on top of that. When I got the original thing, I decided that it was better to start off from that, just in case. And I probably broke stuff when I did the very nasty merge, which was definitely not incremental.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ip6 in up4 tunnel still broken in test9-pre7
[root@innerfire /root]# ifconfig sit0 tunnel ::206.123.31.102 SIOCSIFDSTADDR: No buffer space available This is with net-tools 1.57 Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
Linus Torvalds wrote: > > VM balacing fixes, sound should work again, and a lot of small details. > Unfortunately it still dies occationally. sysrq-Boot is the only thing that work, I have no more data as it happened in X and console switching didn't work. Exactly the same behavior as VM crashes in test9-pre5 and earlier. This is a UP machine with an ide drive, 128M ram and 96M swap. The (memory) load was light when it crashed during a disk write, although there were perhaps 20k in swap from some mozilla use earlier. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
On Mon, 25 Sep 2000, Linus Torvalds wrote: > - pre7: > - official Compaq CISS driver. He may be the maintainer, but he needs a good spanking... This patch breaks the compile, breaks the driver, and reverts all the recent PCI changes and struct type corrections. Argh! I may not have the hardware, but at least I compile the fucking driver, and analyze my own changes before sending them in... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.0-test9-pre7: fix up docs stuff
Hi Linus,
Here is a patch to fix up the {html,ps,sgml,...}docs Makefile targets,
which have been broken ever since videodev.c moved house.
Tim.
*/
Index: linux/Documentation/DocBook/Makefile
diff -u linux/Documentation/DocBook/Makefile:1.1.1.24
linux/Documentation/DocBook/Makefile:1.32
--- linux/Documentation/DocBook/Makefile:1.1.1.24 Mon Sep 25 18:39:15 2000
+++ linux/Documentation/DocBook/MakefileMon Sep 25 18:46:39 2000
@@ -55,11 +55,11 @@
$(TOPDIR)/scripts/docgen $(TOPDIR)/arch/i386/kernel/mca.c \
mcabook.sgml
-videobook.sgml: videobook.tmpl $(TOPDIR)/drivers/char/videodev.c
- $(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/char/videodev.c \
+videobook.sgml: videobook.tmpl $(TOPDIR)/drivers/media/video/videodev.c
+ $(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/media/video/videodev.c \
videobook.sgml
-APISOURCES := $(TOPDIR)/drivers/char/videodev.c \
+APISOURCES := $(TOPDIR)/drivers/media/video/videodev.c \
$(TOPDIR)/arch/i386/kernel/mca.c \
$(TOPDIR)/arch/i386/kernel/mtrr.c \
$(TOPDIR)/drivers/char/misc.c \
Index: linux/Documentation/DocBook/kernel-api.tmpl
diff -u linux/Documentation/DocBook/kernel-api.tmpl:1.1.1.11
linux/Documentation/DocBook/kernel-api.tmpl:1.3
--- linux/Documentation/DocBook/kernel-api.tmpl:1.1.1.11Mon Sep 25 18:39:15
2000
+++ linux/Documentation/DocBook/kernel-api.tmpl Mon Sep 25 18:46:39 2000
@@ -141,7 +141,7 @@
Video4Linux
-!Edrivers/char/videodev.c
+!Edrivers/media/video/videodev.c
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.0-test9-pre7: fix up PCI IDs
Hi Linus, Here is a short patch to fix the ordering in pci_ids.h. Tim. */ --- linux/include/linux/pci_ids.h.fixidsTue Sep 26 13:50:17 2000 +++ linux/include/linux/pci_ids.h Tue Sep 26 13:51:43 2000 @@ -1084,11 +1084,6 @@ #define PCI_DEVICE_ID_LAVA_QUAD_B 0x0202 /* 2x 16650, half of 4 port */ #define PCI_DEVICE_ID_LAVA_SSERIAL 0x0500 /* 1x 16550 */ #define PCI_DEVICE_ID_LAVA_PORT_6500x0600 /* 1x 16650 */ - -#define PCI_VENDOR_ID_SYBA 0x1592 -#define PCI_DEVICE_ID_SYBA_2P_EPP 0x0782 -#define PCI_DEVICE_ID_SYBA_1P_ECP 0x0783 - #define PCI_DEVICE_ID_LAVA_PARALLEL0x8000 #define PCI_DEVICE_ID_LAVA_DUAL_PAR_A 0x8002 /* The Lava Dual Parallel is */ #define PCI_DEVICE_ID_LAVA_DUAL_PAR_B 0x8003 /* two PCI devices on a card */ @@ -1114,6 +1109,10 @@ #define PCI_VENDOR_ID_AFAVLAB 0x14db #define PCI_DEVICE_ID_AFAVLAB_TK9902 0x2120 + +#define PCI_VENDOR_ID_SYBA 0x1592 +#define PCI_DEVICE_ID_SYBA_2P_EPP 0x0782 +#define PCI_DEVICE_ID_SYBA_1P_ECP 0x0783 #define PCI_VENDOR_ID_MORETON 0x15aa #define PCI_DEVICE_ID_RASTEL_2PORT 0x2000 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.0-test9-pre7: ppdev fixes
Hi Linus,
Here is a patch that fixes some missing copy_to/from_user things, as
well as fixing the pp_write logic.
Tim.
*/
Index: linux/drivers/char/ppdev.c
diff -u linux/drivers/char/ppdev.c:1.1.1.23 linux/drivers/char/ppdev.c:1.29
--- linux/drivers/char/ppdev.c:1.1.1.23 Fri Jul 14 11:05:38 2000
+++ linux/drivers/char/ppdev.c Wed Aug 30 12:09:00 2000
@@ -39,7 +39,13 @@
* read/write read or write in current IEEE 1284 protocol
* select wait for interrupt (in readfds)
*
+ * Changes:
* Added SETTIME/GETTIME ioctl, Fred Barnes 1999.
+ *
+ * Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 2000/08/25
+ * - On error, copy_from_user and copy_to_user do not return -EFAULT,
+ * They return the positive number of bytes *not* copied due to address
+ * space errors.
*/
#include
@@ -179,7 +185,7 @@
wrote = parport_write (pp->pdev->port, kbuffer, n);
- if (wrote < 0) {
+ if (wrote <= 0) {
if (!bytes_written)
bytes_written = wrote;
break;
@@ -369,19 +375,19 @@
case PPRSTATUS:
reg = parport_read_status (port);
- return copy_to_user ((unsigned char *) arg, ,
-sizeof (reg));
-
+ if (copy_to_user ((unsigned char *) arg, , sizeof (reg)))
+ return -EFAULT;
+ return 0;
case PPRDATA:
reg = parport_read_data (port);
- return copy_to_user ((unsigned char *) arg, ,
-sizeof (reg));
-
+ if (copy_to_user ((unsigned char *) arg, , sizeof (reg)))
+ return -EFAULT;
+ return 0;
case PPRCONTROL:
reg = parport_read_control (port);
- return copy_to_user ((unsigned char *) arg, ,
-sizeof (reg));
-
+ if (copy_to_user ((unsigned char *) arg, , sizeof (reg)))
+ return -EFAULT;
+ return 0;
case PPYIELD:
parport_yield_blocking (pp->pdev);
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[upatch] Compaq CISS driver - 2.4.0-test9-pre7
The following patch seems help to compile. diff -u --recursive linux-2.4.0-test9-pre7.orig/drivers/block/cciss.c linux-2.4.0-test9-pre7/drivers/block/cciss.c --- linux-2.4.0-test9-pre7.orig/drivers/block/cciss.c Tue Sep 26 10:42:18 2000 +++ linux-2.4.0-test9-pre7/drivers/block/cciss.cTue Sep 26 11:48:13 2000 @@ -407,7 +407,7 @@ pciinfo.bus = hba[ctlr]->pci_bus; pciinfo.dev_fn = hba[ctlr]->pci_dev_fn; pciinfo.board_id = hba[ctlr]->board_id; - if (copy_to_user((void *) arg, , sizeof( cciss_pci_info_struct )) + if (copy_to_user((void *) arg, , +sizeof(cciss_pci_info_struct))) return -EFAULT; return(0); } @@ -419,7 +419,7 @@ if (!arg) return -EINVAL; intinfo.delay = readl(>cfgtable->HostWrite.CoalIntDelay); intinfo.count = readl(>cfgtable->HostWrite.CoalIntCount); - if (copy_to_user((void *) arg, , sizeof( cciss_coalint_struct )) + if (copy_to_user((void *) arg, , sizeof(cciss_coalint_struct))) return -EFAULT; return(0); } @@ -432,7 +432,7 @@ if (!arg) return -EINVAL; if (!capable(CAP_SYS_ADMIN)) return -EPERM; - if (copy_from_user(, (void *) arg, sizeof( cciss_coalint_struct)) + if (copy_from_user(, (void *) arg, +sizeof(cciss_coalint_struct))) return -EFAULT; if ( (intinfo.delay == 0 ) && (intinfo.count == 0)) @@ -479,7 +479,7 @@ if (!arg) return -EINVAL; for(i=0;i<16;i++) NodeName[i] = readb(>cfgtable->ServerName[i]); -if (copy_to_user((void *) arg, NodeName, sizeof( NodeName_type)) +if (copy_to_user((void *) arg, NodeName, sizeof(NodeName_type))) return -EFAULT; return(0); } @@ -493,7 +493,7 @@ if (!arg) return -EINVAL; if (!capable(CAP_SYS_ADMIN)) return -EPERM; - if (copy_from_user(NodeName, (void *) arg, sizeof( NodeName_type)) + if (copy_from_user(NodeName, (void *) arg, sizeof(NodeName_type))) return -EFAULT; spin_lock_irqsave(_request_lock, flags); @@ -525,7 +525,7 @@ if (!arg) return -EINVAL; heartbeat = readl(>cfgtable->HeartBeat); -if (copy_to_user((void *) arg, , sizeof( Heartbeat_type)) +if (copy_to_user((void *) arg, , sizeof(Heartbeat_type))) return -EFAULT; return(0); } @@ -536,7 +536,7 @@ if (!arg) return -EINVAL; BusTypes = readl(>cfgtable->BusTypes); -if (copy_to_user((void *) arg, , sizeof( BusTypes_type) ) +if (copy_to_user((void *) arg, , sizeof(BusTypes_type))) return -EFAULT; return(0); } @@ -547,7 +547,7 @@ if (!arg) return -EINVAL; memcpy(firmware, hba[ctlr]->firm_ver, 4); -if (copy_to_user((void *) arg, firmware, sizeof( FirmwareVer_type)) +if (copy_to_user((void *) arg, firmware, sizeof(FirmwareVer_type))) return -EFAULT; return(0); } @@ -557,7 +557,7 @@ if (!arg) return -EINVAL; -if (copy_to_user((void *) arg, , sizeof( DriverVer_type) ) +if (copy_to_user((void *) arg, , sizeof(DriverVer_type))) return -EFAULT; return(0); } @@ -578,7 +578,7 @@ if (!capable(CAP_SYS_RAWIO)) return -EPERM; - if (copy_from_user(, (void *) arg, sizeof( IOCTL_Command_struct) ) + if (copy_from_user(, (void *) arg, +sizeof(IOCTL_Command_struct))) return -EFAULT; if((iocommand.buf_size < 1) && (iocommand.Request.Type.Direction != XFER_NONE)) -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] test9-pre7: Alpha compile fixes
Following problems fixed here:
- barrier() undefined for UP kernel
- file locking #defines update
- remove addressless weak symbols ("w")
from System.map (depmod -F breaks on these)
Ivan.
diff -urp 2.4.0t9p7/Makefile linux/Makefile
--- 2.4.0t9p7/Makefile Tue Sep 26 12:13:02 2000
+++ linux/Makefile Tue Sep 26 13:23:10 2000
@@ -209,7 +209,7 @@ vmlinux: $(CONFIGURATION) init/main.o in
$(LIBS) \
--end-group \
-o vmlinux
- $(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aU]
\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
+ $(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [awU]
+\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
symlinks:
rm -f include/asm
diff -urp 2.4.0t9p7/include/asm-alpha/bitops.h linux/include/asm-alpha/bitops.h
--- 2.4.0t9p7/include/asm-alpha/bitops.hTue Sep 26 12:10:50 2000
+++ linux/include/asm-alpha/bitops.hTue Sep 26 13:02:51 2000
@@ -2,6 +2,7 @@
#define _ALPHA_BITOPS_H
#include
+#include
/*
* Copyright 1994, Linus Torvalds.
diff -urp 2.4.0t9p7/include/asm-alpha/fcntl.h linux/include/asm-alpha/fcntl.h
--- 2.4.0t9p7/include/asm-alpha/fcntl.h Sat Aug 12 01:37:49 2000
+++ linux/include/asm-alpha/fcntl.h Tue Sep 26 12:40:08 2000
@@ -48,6 +48,9 @@
#define F_EXLCK16 /* or 3 */
#define F_SHLCK32 /* or 4 */
+/* for leases */
+#define F_INPROGRESS 64
+
/* operations for bsd flock(), also used by the kernel implementation */
#define LOCK_SH1 /* shared lock */
#define LOCK_EX2 /* exclusive lock */
@@ -55,6 +58,11 @@
blocking */
#define LOCK_UN8 /* remove lock */
+#define LOCK_MAND 32 /* This is a mandatory flock */
+#define LOCK_READ 64 /* ... Which allows concurrent read operations */
+#define LOCK_WRITE 128 /* ... Which allows concurrent write operations */
+#define LOCK_RW192 /* ... Which allows concurrent read & write
+ops */
+
struct flock {
short l_type;
short l_whence;
@@ -66,5 +74,7 @@ struct flock {
#ifdef __KERNEL__
#define flock64flock
#endif
+
+#define F_LINUX_SPECIFIC_BASE 1024
#endif
diff -urp 2.4.0t9p7/include/asm-alpha/resource.h linux/include/asm-alpha/resource.h
--- 2.4.0t9p7/include/asm-alpha/resource.h Thu Feb 17 20:35:07 2000
+++ linux/include/asm-alpha/resource.h Tue Sep 26 12:25:11 2000
@@ -15,8 +15,9 @@
#define RLIMIT_AS 7 /* address space limit(?) */
#define RLIMIT_NPROC 8 /* max number of processes */
#define RLIMIT_MEMLOCK 9 /* max locked-in-memory address space */
+#define RLIMIT_LOCKS 10 /* maximum file locks held */
-#define RLIM_NLIMITS 10
+#define RLIM_NLIMITS 11
/*
* SuS says limits have to be unsigned. Fine, it's unsigned, but
@@ -39,6 +40,7 @@
{LONG_MAX, LONG_MAX}, /* RLIMIT_AS */ \
{LONG_MAX, LONG_MAX}, /* RLIMIT_NPROC */ \
{LONG_MAX, LONG_MAX}, /* RLIMIT_MEMLOCK */\
+{LONG_MAX, LONG_MAX}, /* RLIMIT_LOCKS */ \
}
#endif /* __KERNEL__ */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch] test9-pre7: Alpha compile fixes
Following problems fixed here:
- barrier() undefined for UP kernel
- file locking #defines update
- remove addressless weak symbols ("w")
from System.map (depmod -F breaks on these)
Ivan.
diff -urp 2.4.0t9p7/Makefile linux/Makefile
--- 2.4.0t9p7/Makefile Tue Sep 26 12:13:02 2000
+++ linux/Makefile Tue Sep 26 13:23:10 2000
@@ -209,7 +209,7 @@ vmlinux: $(CONFIGURATION) init/main.o in
$(LIBS) \
--end-group \
-o vmlinux
- $(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aU]
\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort System.map
+ $(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [awU]
+\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort System.map
symlinks:
rm -f include/asm
diff -urp 2.4.0t9p7/include/asm-alpha/bitops.h linux/include/asm-alpha/bitops.h
--- 2.4.0t9p7/include/asm-alpha/bitops.hTue Sep 26 12:10:50 2000
+++ linux/include/asm-alpha/bitops.hTue Sep 26 13:02:51 2000
@@ -2,6 +2,7 @@
#define _ALPHA_BITOPS_H
#include linux/config.h
+#include linux/kernel.h
/*
* Copyright 1994, Linus Torvalds.
diff -urp 2.4.0t9p7/include/asm-alpha/fcntl.h linux/include/asm-alpha/fcntl.h
--- 2.4.0t9p7/include/asm-alpha/fcntl.h Sat Aug 12 01:37:49 2000
+++ linux/include/asm-alpha/fcntl.h Tue Sep 26 12:40:08 2000
@@ -48,6 +48,9 @@
#define F_EXLCK16 /* or 3 */
#define F_SHLCK32 /* or 4 */
+/* for leases */
+#define F_INPROGRESS 64
+
/* operations for bsd flock(), also used by the kernel implementation */
#define LOCK_SH1 /* shared lock */
#define LOCK_EX2 /* exclusive lock */
@@ -55,6 +58,11 @@
blocking */
#define LOCK_UN8 /* remove lock */
+#define LOCK_MAND 32 /* This is a mandatory flock */
+#define LOCK_READ 64 /* ... Which allows concurrent read operations */
+#define LOCK_WRITE 128 /* ... Which allows concurrent write operations */
+#define LOCK_RW192 /* ... Which allows concurrent read write
+ops */
+
struct flock {
short l_type;
short l_whence;
@@ -66,5 +74,7 @@ struct flock {
#ifdef __KERNEL__
#define flock64flock
#endif
+
+#define F_LINUX_SPECIFIC_BASE 1024
#endif
diff -urp 2.4.0t9p7/include/asm-alpha/resource.h linux/include/asm-alpha/resource.h
--- 2.4.0t9p7/include/asm-alpha/resource.h Thu Feb 17 20:35:07 2000
+++ linux/include/asm-alpha/resource.h Tue Sep 26 12:25:11 2000
@@ -15,8 +15,9 @@
#define RLIMIT_AS 7 /* address space limit(?) */
#define RLIMIT_NPROC 8 /* max number of processes */
#define RLIMIT_MEMLOCK 9 /* max locked-in-memory address space */
+#define RLIMIT_LOCKS 10 /* maximum file locks held */
-#define RLIM_NLIMITS 10
+#define RLIM_NLIMITS 11
/*
* SuS says limits have to be unsigned. Fine, it's unsigned, but
@@ -39,6 +40,7 @@
{LONG_MAX, LONG_MAX}, /* RLIMIT_AS */ \
{LONG_MAX, LONG_MAX}, /* RLIMIT_NPROC */ \
{LONG_MAX, LONG_MAX}, /* RLIMIT_MEMLOCK */\
+{LONG_MAX, LONG_MAX}, /* RLIMIT_LOCKS */ \
}
#endif /* __KERNEL__ */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[upatch] Compaq CISS driver - 2.4.0-test9-pre7
The following patch seems help to compile. diff -u --recursive linux-2.4.0-test9-pre7.orig/drivers/block/cciss.c linux-2.4.0-test9-pre7/drivers/block/cciss.c --- linux-2.4.0-test9-pre7.orig/drivers/block/cciss.c Tue Sep 26 10:42:18 2000 +++ linux-2.4.0-test9-pre7/drivers/block/cciss.cTue Sep 26 11:48:13 2000 @@ -407,7 +407,7 @@ pciinfo.bus = hba[ctlr]-pci_bus; pciinfo.dev_fn = hba[ctlr]-pci_dev_fn; pciinfo.board_id = hba[ctlr]-board_id; - if (copy_to_user((void *) arg, pciinfo, sizeof( cciss_pci_info_struct )) + if (copy_to_user((void *) arg, pciinfo, +sizeof(cciss_pci_info_struct))) return -EFAULT; return(0); } @@ -419,7 +419,7 @@ if (!arg) return -EINVAL; intinfo.delay = readl(c-cfgtable-HostWrite.CoalIntDelay); intinfo.count = readl(c-cfgtable-HostWrite.CoalIntCount); - if (copy_to_user((void *) arg, intinfo, sizeof( cciss_coalint_struct )) + if (copy_to_user((void *) arg, intinfo, sizeof(cciss_coalint_struct))) return -EFAULT; return(0); } @@ -432,7 +432,7 @@ if (!arg) return -EINVAL; if (!capable(CAP_SYS_ADMIN)) return -EPERM; - if (copy_from_user(intinfo, (void *) arg, sizeof( cciss_coalint_struct)) + if (copy_from_user(intinfo, (void *) arg, +sizeof(cciss_coalint_struct))) return -EFAULT; if ( (intinfo.delay == 0 ) (intinfo.count == 0)) @@ -479,7 +479,7 @@ if (!arg) return -EINVAL; for(i=0;i16;i++) NodeName[i] = readb(c-cfgtable-ServerName[i]); -if (copy_to_user((void *) arg, NodeName, sizeof( NodeName_type)) +if (copy_to_user((void *) arg, NodeName, sizeof(NodeName_type))) return -EFAULT; return(0); } @@ -493,7 +493,7 @@ if (!arg) return -EINVAL; if (!capable(CAP_SYS_ADMIN)) return -EPERM; - if (copy_from_user(NodeName, (void *) arg, sizeof( NodeName_type)) + if (copy_from_user(NodeName, (void *) arg, sizeof(NodeName_type))) return -EFAULT; spin_lock_irqsave(io_request_lock, flags); @@ -525,7 +525,7 @@ if (!arg) return -EINVAL; heartbeat = readl(c-cfgtable-HeartBeat); -if (copy_to_user((void *) arg, heartbeat, sizeof( Heartbeat_type)) +if (copy_to_user((void *) arg, heartbeat, sizeof(Heartbeat_type))) return -EFAULT; return(0); } @@ -536,7 +536,7 @@ if (!arg) return -EINVAL; BusTypes = readl(c-cfgtable-BusTypes); -if (copy_to_user((void *) arg, BusTypes, sizeof( BusTypes_type) ) +if (copy_to_user((void *) arg, BusTypes, sizeof(BusTypes_type))) return -EFAULT; return(0); } @@ -547,7 +547,7 @@ if (!arg) return -EINVAL; memcpy(firmware, hba[ctlr]-firm_ver, 4); -if (copy_to_user((void *) arg, firmware, sizeof( FirmwareVer_type)) +if (copy_to_user((void *) arg, firmware, sizeof(FirmwareVer_type))) return -EFAULT; return(0); } @@ -557,7 +557,7 @@ if (!arg) return -EINVAL; -if (copy_to_user((void *) arg, DriverVer, sizeof( DriverVer_type) ) +if (copy_to_user((void *) arg, DriverVer, sizeof(DriverVer_type))) return -EFAULT; return(0); } @@ -578,7 +578,7 @@ if (!capable(CAP_SYS_RAWIO)) return -EPERM; - if (copy_from_user(iocommand, (void *) arg, sizeof( IOCTL_Command_struct) ) + if (copy_from_user(iocommand, (void *) arg, +sizeof(IOCTL_Command_struct))) return -EFAULT; if((iocommand.buf_size 1) (iocommand.Request.Type.Direction != XFER_NONE)) -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.0-test9-pre7: ppdev fixes
Hi Linus,
Here is a patch that fixes some missing copy_to/from_user things, as
well as fixing the pp_write logic.
Tim.
*/
Index: linux/drivers/char/ppdev.c
diff -u linux/drivers/char/ppdev.c:1.1.1.23 linux/drivers/char/ppdev.c:1.29
--- linux/drivers/char/ppdev.c:1.1.1.23 Fri Jul 14 11:05:38 2000
+++ linux/drivers/char/ppdev.c Wed Aug 30 12:09:00 2000
@@ -39,7 +39,13 @@
* read/write read or write in current IEEE 1284 protocol
* select wait for interrupt (in readfds)
*
+ * Changes:
* Added SETTIME/GETTIME ioctl, Fred Barnes 1999.
+ *
+ * Arnaldo Carvalho de Melo [EMAIL PROTECTED] 2000/08/25
+ * - On error, copy_from_user and copy_to_user do not return -EFAULT,
+ * They return the positive number of bytes *not* copied due to address
+ * space errors.
*/
#include linux/module.h
@@ -179,7 +185,7 @@
wrote = parport_write (pp-pdev-port, kbuffer, n);
- if (wrote 0) {
+ if (wrote = 0) {
if (!bytes_written)
bytes_written = wrote;
break;
@@ -369,19 +375,19 @@
case PPRSTATUS:
reg = parport_read_status (port);
- return copy_to_user ((unsigned char *) arg, reg,
-sizeof (reg));
-
+ if (copy_to_user ((unsigned char *) arg, reg, sizeof (reg)))
+ return -EFAULT;
+ return 0;
case PPRDATA:
reg = parport_read_data (port);
- return copy_to_user ((unsigned char *) arg, reg,
-sizeof (reg));
-
+ if (copy_to_user ((unsigned char *) arg, reg, sizeof (reg)))
+ return -EFAULT;
+ return 0;
case PPRCONTROL:
reg = parport_read_control (port);
- return copy_to_user ((unsigned char *) arg, reg,
-sizeof (reg));
-
+ if (copy_to_user ((unsigned char *) arg, reg, sizeof (reg)))
+ return -EFAULT;
+ return 0;
case PPYIELD:
parport_yield_blocking (pp-pdev);
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.0-test9-pre7: fix up PCI IDs
Hi Linus, Here is a short patch to fix the ordering in pci_ids.h. Tim. */ --- linux/include/linux/pci_ids.h.fixidsTue Sep 26 13:50:17 2000 +++ linux/include/linux/pci_ids.h Tue Sep 26 13:51:43 2000 @@ -1084,11 +1084,6 @@ #define PCI_DEVICE_ID_LAVA_QUAD_B 0x0202 /* 2x 16650, half of 4 port */ #define PCI_DEVICE_ID_LAVA_SSERIAL 0x0500 /* 1x 16550 */ #define PCI_DEVICE_ID_LAVA_PORT_6500x0600 /* 1x 16650 */ - -#define PCI_VENDOR_ID_SYBA 0x1592 -#define PCI_DEVICE_ID_SYBA_2P_EPP 0x0782 -#define PCI_DEVICE_ID_SYBA_1P_ECP 0x0783 - #define PCI_DEVICE_ID_LAVA_PARALLEL0x8000 #define PCI_DEVICE_ID_LAVA_DUAL_PAR_A 0x8002 /* The Lava Dual Parallel is */ #define PCI_DEVICE_ID_LAVA_DUAL_PAR_B 0x8003 /* two PCI devices on a card */ @@ -1114,6 +1109,10 @@ #define PCI_VENDOR_ID_AFAVLAB 0x14db #define PCI_DEVICE_ID_AFAVLAB_TK9902 0x2120 + +#define PCI_VENDOR_ID_SYBA 0x1592 +#define PCI_DEVICE_ID_SYBA_2P_EPP 0x0782 +#define PCI_DEVICE_ID_SYBA_1P_ECP 0x0783 #define PCI_VENDOR_ID_MORETON 0x15aa #define PCI_DEVICE_ID_RASTEL_2PORT 0x2000 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.0-test9-pre7: fix up docs stuff
Hi Linus,
Here is a patch to fix up the {html,ps,sgml,...}docs Makefile targets,
which have been broken ever since videodev.c moved house.
Tim.
*/
Index: linux/Documentation/DocBook/Makefile
diff -u linux/Documentation/DocBook/Makefile:1.1.1.24
linux/Documentation/DocBook/Makefile:1.32
--- linux/Documentation/DocBook/Makefile:1.1.1.24 Mon Sep 25 18:39:15 2000
+++ linux/Documentation/DocBook/MakefileMon Sep 25 18:46:39 2000
@@ -55,11 +55,11 @@
$(TOPDIR)/scripts/docgen $(TOPDIR)/arch/i386/kernel/mca.c \
mcabook.tmpl mcabook.sgml
-videobook.sgml: videobook.tmpl $(TOPDIR)/drivers/char/videodev.c
- $(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/char/videodev.c \
+videobook.sgml: videobook.tmpl $(TOPDIR)/drivers/media/video/videodev.c
+ $(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/media/video/videodev.c \
videobook.tmpl videobook.sgml
-APISOURCES := $(TOPDIR)/drivers/char/videodev.c \
+APISOURCES := $(TOPDIR)/drivers/media/video/videodev.c \
$(TOPDIR)/arch/i386/kernel/mca.c \
$(TOPDIR)/arch/i386/kernel/mtrr.c \
$(TOPDIR)/drivers/char/misc.c \
Index: linux/Documentation/DocBook/kernel-api.tmpl
diff -u linux/Documentation/DocBook/kernel-api.tmpl:1.1.1.11
linux/Documentation/DocBook/kernel-api.tmpl:1.3
--- linux/Documentation/DocBook/kernel-api.tmpl:1.1.1.11Mon Sep 25 18:39:15
2000
+++ linux/Documentation/DocBook/kernel-api.tmpl Mon Sep 25 18:46:39 2000
@@ -141,7 +141,7 @@
chapter id="viddev"
titleVideo4Linux/title
-!Edrivers/char/videodev.c
+!Edrivers/media/video/videodev.c
/chapter
chapter id="snddev"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
Linus Torvalds wrote: VM balacing fixes, sound should work again, and a lot of small details. Unfortunately it still dies occationally. sysrq-Boot is the only thing that work, I have no more data as it happened in X and console switching didn't work. Exactly the same behavior as VM crashes in test9-pre5 and earlier. This is a UP machine with an ide drive, 128M ram and 96M swap. The (memory) load was light when it crashed during a disk write, although there were perhaps 20k in swap from some mozilla use earlier. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ip6 in up4 tunnel still broken in test9-pre7
[root@innerfire /root]# ifconfig sit0 tunnel ::206.123.31.102 SIOCSIFDSTADDR: No buffer space available This is with net-tools 1.57 Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
On Tue, 26 Sep 2000, Jeff Garzik wrote: On Mon, 25 Sep 2000, Linus Torvalds wrote: - pre7: - official Compaq CISS driver. He may be the maintainer, but he needs a good spanking... No, the breakage is probably mine. The problem was that you sent me the forward-port of Alan's backport of basically this driver, and then sent me updates on top of that. When I got the original thing, I decided that it was better to start off from that, just in case. And I probably broke stuff when I did the very nasty merge, which was definitely not incremental.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
On Tue, Sep 26, 2000 at 03:29:40PM +0200, Helge Hafting wrote: Unfortunately it still dies occationally. sysrq-Boot is the only thing that work, I have no more data as it happened in X and console switching didn't work. Exactly the same behavior as VM crashes in test9-pre5 and earlier. This is a UP machine with an ide drive, 128M ram and 96M swap. The (memory) load was light when it crashed during a disk write, although there were perhaps 20k in swap from some mozilla use earlier. Exactly the same here. I've seen the same crash three times today (not having suffered from mysterious crashes here): - I do something (typically starting a program; the one I've just seen started this behaviour just as icecast started its extra threads) - The hard disk starts grinding (as if I were going deeply into swap), and my X session freezes - Hitting alt-sysrq-u might work if I'm lucky, but normally only alt-sysrq-b is available However, I'm probably not a useful datapoint, as I'm running 2.4.0-test8 + reiserfs-3.9.16 + 2.4.0-t8-sched + 2.4.0-t8-vmpatch4. The machine's a K6-2 450MHz with 160Mb of RAM, a few IDE disks and an NE2000 card, running XFree86 v4.0.1. Previous 2.4.0-test kernels have been rock solid for me, which is probably a good sign. -- Adam Sampson [EMAIL PROTECTED], [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
On Tue, Sep 26, 2000 at 08:23:04PM +0100, Adam Sampson wrote: However, I'm probably not a useful datapoint, as I'm running 2.4.0-test8 + reiserfs-3.9.16 + 2.4.0-t8-sched + 2.4.0-t8-vmpatch4. Just happened again with test9-pre7; looked like it was caused by gcc eating lots of memory and going into swap. -- Adam Sampson [EMAIL PROTECTED], [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre7 crash
Hi Folks, Sorry if already known. Here is oops I've got on test9-pre7. Not sure what triggered this. As usual when I install new test kernel I do silly simple stress stuff : hdparm -t /dev/sdaX or /dev/hdaX (couple of times) memspeed 150(megs) 10(times) (swaper and mem stress) tcpspeed and udpspeed on loopback (net code stress) And then after a while (1-5 mins) I've started getting crashes, they all looked the same. That's Compaq PIII/124/Adaptec2940/EEpro100(module)/USB (module). 2.4.0-test8 works just fine. So, one of the crashes: Unable to handle kernel NULL pointer dereference at virtual address 0009 c0139902 *pde = Oops: CPU:0 EIP:0010:[c0139902] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 0009 ebx: ecx: 000d edx: 0001 esi: edi: ebp: 0009 esp: c73ebf08 ds: 0018 es: 0018 ss: 0018 Process login (pid: 655, stackpage=c73eb000) Stack: c73ea000 0001 000d 000f c0139a33 0001 0009 c73ebf48 c73ebf4c c73ea000 0001 0001 c73ea000 c0139ca3 0001 0001 c7dd4660 c73ebfb8 Call Trace: [c0139a33] [c0139ca3] [c0118a6e] [c0108d3f] Code: 8b 45 00 85 c0 7c 59 e8 9a 25 ff ff 89 c6 bb 20 00 00 00 85 EIP; c0139902 do_pollfd+2e/b4 = Trace; c0139a33 do_poll+ab/e8 Trace; c0139ca3 sys_poll+233/350 Trace; c0118a6e do_softirq+4e/74 Trace; c0108d3f system_call+33/38 Code; c0139902 do_pollfd+2e/b4 _EIP: Code; c0139902 do_pollfd+2e/b4 = 0: 8b 45 00 mov0x0(%ebp),%eax = Code; c0139905 do_pollfd+31/b4 3: 85 c0 test %eax,%eax Code; c0139907 do_pollfd+33/b4 5: 7c 59 jl 60 _EIP+0x60 c0139962 do_pollfd+8e/b4 Code; c0139909 do_pollfd+35/b4 7: e8 9a 25 ff ffcall 25a6 _EIP+0x25a6 c012bea8 fget+0/28 Code; c013990e do_pollfd+3a/b4 c: 89 c6 mov%eax,%esi Code; c0139910 do_pollfd+3c/b4 e: bb 20 00 00 00mov$0x20,%ebx Code; c0139915 do_pollfd+41/b4 13: 85 00 test %eax,(%eax) Max P.S. CC replies please I'm not on the list. Maksim Krasnyanskiy Senior Kernel Engineer Qualcomm Incorporated [EMAIL PROTECTED] (408) 557-1092 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
> Udo A Steinberg wrote: > There's a little annoying bug with printing partitions upon bootup. before the patch: kernel: <6>Partition check: kernel: <6> hda: hda1 hda1 hda2 hda2 < hda5 hda5 hda6 hda6 hda7 hda7 hda8 hda8 hda9 hda9 > kernel: <6> hdb: hdb1 hdb1 hdb2 hdb2 hdb3 hdb3 hdb4 hdb4 after the patch: kernel: <6>Partition check: kernel: <6> hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 > kernel: <6> hdb: hdb1 hdb2 hdb3 hdb4 Looks like the patch worked. Running this version of 2.4.0-test9-pre7 now. Regards, Steven Cole - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
> "udo" == Udo A Steinberg <[EMAIL PROTECTED]> writes: udo> There's a little annoying bug with printing partitions upon bootup. udo> Specifically my dmesg now looks like: udo> Partition check: udo> hda: hda1 hda1 udo> hdb: hdb1 hdb1 hdb2 hdb2 hdb3 hdb3 < hdb5 hdb5 hdb6 hdb6 hdb7 hdb7 hdb8 hdb8 hd udo> b9 hdb9 hdb10 hdb10 > udo> The following attached patch should fix this. udo> I'd be happy if someone could verify that it's correct udo> (seeing that it's past 3am here). It works nicely here. Thanks, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
Linus Torvalds wrote:
>
> VM balacing fixes, sound should work again, and a lot of small details.
>
> Linus
> - pre7:
> - official Compaq CISS driver.
There's a little annoying bug with printing partitions upon bootup.
Specifically my dmesg now looks like:
Partition check:
hda: hda1 hda1
hdb: hdb1 hdb1 hdb2 hdb2 hdb3 hdb3 < hdb5 hdb5 hdb6 hdb6 hdb7 hdb7 hdb8 hdb8 hd
b9 hdb9 hdb10 hdb10 >
The following attached patch should fix this.
I'd be happy if someone could verify that it's correct
(seeing that it's past 3am here).
Cheers,
Udo
--- linux/fs/partitions/check.c Tue Sep 26 03:32:45 2000
+++ patched/fs/partitions/check.c Tue Sep 26 03:31:47 2000
@@ -187,14 +187,11 @@
#ifdef CONFIG_DEVFS_FS
printk(" p%d", (minor & ((1 << hd->minor_shift) - 1)));
#else
- if (hd->major >= COMPAQ_SMART2_MAJOR+0 && hd->major <= COMPAQ_SMART2_MAJOR+7)
+ if ((hd->major >= COMPAQ_SMART2_MAJOR+0 && hd->major <= COMPAQ_SMART2_MAJOR+7)
+||
+ (hd->major >= COMPAQ_CISS_MAJOR+0 && hd->major <= COMPAQ_CISS_MAJOR+7))
printk(" p%d", (minor & ((1 << hd->minor_shift) - 1)));
else
printk(" %s", disk_name(hd, minor, buf));
- if (hd->major >= COMPAQ_CISS_MAJOR+0 && hd->major <= COMPAQ_CISS_MAJOR+7)
-printk(" p%d", (minor & ((1 << hd->minor_shift) - 1)));
-else
-printk(" %s", disk_name(hd, minor, buf));
#endif
}
test9-pre7
VM balacing fixes, sound should work again, and a lot of small details. Linus - - pre1: - USB: OHCI controller unlink and bandwidth reclamation fixes - USB: storage update - sparc64: register window race. Non-deadlock rwlocks. - name clash in hamradio/pi2.c and hamradio/pt.c - epic100 credits, 8139too driver update, sr.c initcalls - acenic update - NFS sillyrename fixups - mktime(). Do it just once - not 16 times. - misc small fixes to random drivers by Tigran - IDE driver picks up master/slave relationships on its own. - truncate unmapped/uptodate case handled correctly - don't do notifier locking at low level: higher levels do (or should do) this already. - ACPI interpreter updates (and file renames - making this part big) - SysKonnect gigabit driver update - 3c59x driver update - pcmcia debounce logic. Ugh. - MM balancing (Rik Riel) - pre2: - "extern inline" -> "static inline". It doesn't matter right now, but it's proactive for future gcc versions. - various net drvr updates and fixes - more initcall updates - PPC updates (including PPC-related drivers etc) - disallow re-mounting same filesystem in same place multiple times. Too confusing. And /etc/mtab gets strange. - Riel VM update - sparc updates - PCI bridge scanning fix: assign numbers properly - network updates - scsi fixes - pre3: - uninitialized == zero. Remove extra initializers. - block_prepare_write and block_truncate_page: if the page is up-to-date, then so are the buffer heads inside it once they are mapped.. - SCSI initialization - move over to the modular case. No more double initialization. - Sync up with Alans 2.2.x driver changes - networking updates (iipv6 works non-modular etc) - netfilter update - adfs correct dentry operations - ARM update (including ARM drivers) - acenic driver update - floppy: we'd better hold the io_request_lock when playing with "CURRENT". - NFS cache coherency across file locking fix - NFS over TCP - handle TCP socket writability right.. - USB updates - pre4: - more USB updates - continued SCSI cleanup - pre5: - more drivers synced to Alan's 2.2.x changes - sis900 driver update - Andries: net device name allocation as in 2.2.x - pmac SCSI driver init update - ixj telephony driver fixes - _fput/__fput are no longer used. - more USB updates - codafs update - byteorder: use statement expressions instead of macros, to avoid argument re-use. - don't disallow Onstream ide-scsi devices - fix cardbus bridge resources.. - Make SCSI initialization order be same as before. - pre6: - Add Camino chipset ID to eepro100 driver. - VM UP deadlock fix - codafs fixups - networking updates - USB uhci updates - makefile documentation update - emu10k stereo sound fix. - new PCI ids - more linux-2.2 driver sync-ups - VIA IDE driver bugfixes - update atp ISA net driver - file locking fixes - make the scsi-generic module work properly again. - careful memory ordering by Andrea.. - alpha RTC year magic again.. - broadcast I/O APIC interrupt MP-tables are legal.. - samba 2.2 needs leases for efficient file sharing. They are kind of like file locks with async IO notification. - teach st.c about some SCSI tapes that really aren't SCSI tapes (OnStream) - TUN/TAP driver: use proper device number (misc device, minor=200). - pre7: - official Compaq CISS driver. - cs4281 sound driver - export the new lock copy/init functions - add SGI PCI ID's. - Ingo: clean up VM handling, improve balancing. - fix up ac97 codec initialization - nfsd: mark us as a O_LARGEFILE case, so that the VFS allows the full 64-bit access.. - shm statistics bugfix. - sound init cleanups - alpha cross-compile fixes.. - don't raise privileges when re-trying a failed NFS RPM request - NFSv3 is not really really experimental any more. - file locking deadlock detection bugfix.. - recognize the k6 model 13: it's a K6-2+ mobile processor. - USB: remember to release the kernel lock and other updates.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre7
VM balacing fixes, sound should work again, and a lot of small details. Linus - - pre1: - USB: OHCI controller unlink and bandwidth reclamation fixes - USB: storage update - sparc64: register window race. Non-deadlock rwlocks. - name clash in hamradio/pi2.c and hamradio/pt.c - epic100 credits, 8139too driver update, sr.c initcalls - acenic update - NFS sillyrename fixups - mktime(). Do it just once - not 16 times. - misc small fixes to random drivers by Tigran - IDE driver picks up master/slave relationships on its own. - truncate unmapped/uptodate case handled correctly - don't do notifier locking at low level: higher levels do (or should do) this already. - ACPI interpreter updates (and file renames - making this part big) - SysKonnect gigabit driver update - 3c59x driver update - pcmcia debounce logic. Ugh. - MM balancing (Rik Riel) - pre2: - "extern inline" - "static inline". It doesn't matter right now, but it's proactive for future gcc versions. - various net drvr updates and fixes - more initcall updates - PPC updates (including PPC-related drivers etc) - disallow re-mounting same filesystem in same place multiple times. Too confusing. And /etc/mtab gets strange. - Riel VM update - sparc updates - PCI bridge scanning fix: assign numbers properly - network updates - scsi fixes - pre3: - uninitialized == zero. Remove extra initializers. - block_prepare_write and block_truncate_page: if the page is up-to-date, then so are the buffer heads inside it once they are mapped.. - SCSI initialization - move over to the modular case. No more double initialization. - Sync up with Alans 2.2.x driver changes - networking updates (iipv6 works non-modular etc) - netfilter update - adfs correct dentry operations - ARM update (including ARM drivers) - acenic driver update - floppy: we'd better hold the io_request_lock when playing with "CURRENT". - NFS cache coherency across file locking fix - NFS over TCP - handle TCP socket writability right.. - USB updates - pre4: - more USB updates - continued SCSI cleanup - pre5: - more drivers synced to Alan's 2.2.x changes - sis900 driver update - Andries: net device name allocation as in 2.2.x - pmac SCSI driver init update - ixj telephony driver fixes - _fput/__fput are no longer used. - more USB updates - codafs update - byteorder: use statement expressions instead of macros, to avoid argument re-use. - don't disallow Onstream ide-scsi devices - fix cardbus bridge resources.. - Make SCSI initialization order be same as before. - pre6: - Add Camino chipset ID to eepro100 driver. - VM UP deadlock fix - codafs fixups - networking updates - USB uhci updates - makefile documentation update - emu10k stereo sound fix. - new PCI ids - more linux-2.2 driver sync-ups - VIA IDE driver bugfixes - update atp ISA net driver - file locking fixes - make the scsi-generic module work properly again. - careful memory ordering by Andrea.. - alpha RTC year magic again.. - broadcast I/O APIC interrupt MP-tables are legal.. - samba 2.2 needs leases for efficient file sharing. They are kind of like file locks with async IO notification. - teach st.c about some SCSI tapes that really aren't SCSI tapes (OnStream) - TUN/TAP driver: use proper device number (misc device, minor=200). - pre7: - official Compaq CISS driver. - cs4281 sound driver - export the new lock copy/init functions - add SGI PCI ID's. - Ingo: clean up VM handling, improve balancing. - fix up ac97 codec initialization - nfsd: mark us as a O_LARGEFILE case, so that the VFS allows the full 64-bit access.. - shm statistics bugfix. - sound init cleanups - alpha cross-compile fixes.. - don't raise privileges when re-trying a failed NFS RPM request - NFSv3 is not really really experimental any more. - file locking deadlock detection bugfix.. - recognize the k6 model 13: it's a K6-2+ mobile processor. - USB: remember to release the kernel lock and other updates.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
Linus Torvalds wrote:
VM balacing fixes, sound should work again, and a lot of small details.
Linus
- pre7:
- official Compaq CISS driver.
There's a little annoying bug with printing partitions upon bootup.
Specifically my dmesg now looks like:
Partition check:
hda: hda1 hda1
hdb: hdb1 hdb1 hdb2 hdb2 hdb3 hdb3 hdb5 hdb5 hdb6 hdb6 hdb7 hdb7 hdb8 hdb8 hd
b9 hdb9 hdb10 hdb10
The following attached patch should fix this.
I'd be happy if someone could verify that it's correct
(seeing that it's past 3am here).
Cheers,
Udo
--- linux/fs/partitions/check.c Tue Sep 26 03:32:45 2000
+++ patched/fs/partitions/check.c Tue Sep 26 03:31:47 2000
@@ -187,14 +187,11 @@
#ifdef CONFIG_DEVFS_FS
printk(" p%d", (minor ((1 hd-minor_shift) - 1)));
#else
- if (hd-major = COMPAQ_SMART2_MAJOR+0 hd-major = COMPAQ_SMART2_MAJOR+7)
+ if ((hd-major = COMPAQ_SMART2_MAJOR+0 hd-major = COMPAQ_SMART2_MAJOR+7)
+||
+ (hd-major = COMPAQ_CISS_MAJOR+0 hd-major = COMPAQ_CISS_MAJOR+7))
printk(" p%d", (minor ((1 hd-minor_shift) - 1)));
else
printk(" %s", disk_name(hd, minor, buf));
- if (hd-major = COMPAQ_CISS_MAJOR+0 hd-major = COMPAQ_CISS_MAJOR+7)
-printk(" p%d", (minor ((1 hd-minor_shift) - 1)));
-else
-printk(" %s", disk_name(hd, minor, buf));
#endif
}
Re: test9-pre7
Udo A Steinberg wrote: There's a little annoying bug with printing partitions upon bootup. before the patch: kernel: 6Partition check: kernel: 6 hda: hda1 hda1 hda2 hda2 hda5 hda5 hda6 hda6 hda7 hda7 hda8 hda8 hda9 hda9 kernel: 6 hdb: hdb1 hdb1 hdb2 hdb2 hdb3 hdb3 hdb4 hdb4 after the patch: kernel: 6Partition check: kernel: 6 hda: hda1 hda2 hda5 hda6 hda7 hda8 hda9 kernel: 6 hdb: hdb1 hdb2 hdb3 hdb4 Looks like the patch worked. Running this version of 2.4.0-test9-pre7 now. Regards, Steven Cole - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
