>, [EMAIL PROTECTED],
|> Jeff Garzik <[EMAIL PROTECTED]>
|> Subject: Re: Loopback filesystem still hangs on 2.4.0-test13-pre7
|>
|> Good day, all,
|>
|> On Thu, 4 Jan 2001, Jens Axboe wrote:
|>
|> > On Wed, Jan 03 2001, William Stearns wrote
Good day, all,
On Thu, 4 Jan 2001, Jens Axboe wrote:
> On Wed, Jan 03 2001, William Stearns wrote:
> > This is just meant as an informational message, not a complaint.
> > Ted, could you note that this still exists on 2.4.0-test13-pre7 in the
> > todo page? Many tha
On Wed, Jan 03 2001, William Stearns wrote:
> Good day, all,
> This is just meant as an informational message, not a complaint.
> Ted, could you note that this still exists on 2.4.0-test13-pre7 in the
> todo page? Many thanks.
>
> [1.] One line summary of the problem
Good day, all,
This is just meant as an informational message, not a complaint.
Ted, could you note that this still exists on 2.4.0-test13-pre7 in the
todo page? Many thanks.
[1.] One line summary of the problem:
Loopback filesystem writes still hang on 2.4.0-test13-pre7.
[2
effects."
The problem is still present in test13-pre7 and in prerelease; X
blanks like crazy sometimes here, and applying the patch solves the
problem nicely here. This is a VIA Apollo Pro 133 system
(VIA 693/596B)
Not sure why it didn't go into the main tree, and since there's
prerelease
[Saw your reply on the web archive: I'm not subscribed to linux-kernel.
Cc-ing the list for archive -- I've faked an In-Reply-To for correct
threading].
A "cat /proc/sys/dev/cdrom/info" says
(I have 2 CD-ROMs, but the one with ioctl() errors is the SCSI one)
CD-ROM information, Id: cdrom.c
When I boot a version of test13-pre7 that was compiled with the
20001225 snapshot of gcc I get the following oops:
ksymoops 2.3.5 on i586 2.4.0-test11. Options used
-V (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.4.0-test13-pre7/ (specified)
-m /boot
On Mon, 1 Jan 2001, Tony Hoyle wrote:
> I'm intrigued... how did you resolve the 'mem_map_inc_count' and
> 'mem_map_dec_count',
> 'put_module_symbol' and 'get_module_symbol' references?
>
> It's only of academic interest for me now as I've ditched the nvidia -
> not worth the hassle.
>
> Amusingl
e system has been
an Achilles heal of our swap code.
Comments?
Eric
diff -uNrX linux-ignore-files linux-2.4.0-test13-pre7/arch/ia64/ia32/binfmt_elf32.c
linux-2.4.0-test13-pre7.rss-dirty-count/arch/ia64/ia32/binfmt_elf32.c
--- linux-2.4.0-test13-pre7/arch/ia64/ia32/binfmt_elf32.c Tue Dec 5 23:3
Tony Spinillo wrote:
>
> The nvidia kernel module (from www.nvidia.com) has compiled and loaded
> correctly with all test13-pre series up to pre6. I just tried to
> compile and load under pre7.
I'm intrigued... how did you resolve the 'mem_map_inc_count' and
'mem_map_dec_count',
'put_module_symb
Chris Evans wrote:
> On Sat, 30 Dec 2000, Linus Torvalds wrote:
>
> > On Sat, 30 Dec 2000, Steven Cole wrote:
> > >
> > > It looks like 2.4.0-test13-pre7 is a clear winner when running dbench
> > > 48 on my somewhat slow test machine (450 Mhz P-III, 192MB,
and xmcd reports:
>
> CD audio: ioctl error on /dev/scd0: cmd=CDROMVOLCTRL errno=95
>
> This was working fine with 2.4.0 test12-pre5, which was the previous
> kernel I was using.
> -----
>
> Well, I installed 2.4.0 test13-pre7 and I still have t
On Sat, 30 Dec 2000, Linus Torvalds wrote:
> On Sat, 30 Dec 2000, Steven Cole wrote:
> >
> > It looks like 2.4.0-test13-pre7 is a clear winner when running dbench 48
> > on my somewhat slow test machine (450 Mhz P-III, 192MB, IDE).
>
> This is almost certainly purely
no=95
This was working fine with 2.4.0 test12-pre5, which was the previous
kernel I was using.
-
Well, I installed 2.4.0 test13-pre7 and I still have the same error.
My CDROM driver is SCSI, connected to a Tekram DC390. I use
the am53c974 driver.
Something must have chang
On Sun, 31 Dec 2000, Matti Aarnio wrote:
> On Sun, Dec 31, 2000 at 10:42:26AM +0100, Mike Galbraith wrote:
> > Hi,
> >
> > While running iozone, I notice severe stalls of vmstat output
> > despite vmstat running SCHED_RR and mlockall().
>
>Lets eliminate the obvious:
>
>- Are you runni
On Sun, Dec 31, 2000 at 10:42:26AM +0100, Mike Galbraith wrote:
> Hi,
>
> While running iozone, I notice severe stalls of vmstat output
> despite vmstat running SCHED_RR and mlockall().
Lets eliminate the obvious:
- Are you running with IDE disk ?
- Does hdparm /dev/hda(whatever)
Thanks for the prompt response.
Regards
Sid.
Alan Cox wrote:
>
> > The problem showed up on the stroke of test13-pre4-ac2 and stuff from
> > Alan has been merged in. I went from pre4-ac2 to pre5 (AOK) and now
> > attempting pre7...
>
> Its definitely coming from the AX.25 rela
Hi,
While running iozone, I notice severe stalls of vmstat output
despite vmstat running SCHED_RR and mlockall().
With IKD, I ran a million line ktrace of such a stall, and find
no occurance of vmstat's pid. (trace covers a ~full second of
kernel time) The only user process which was scheduled
Linus Torvalds wrote:
> On Sat, 30 Dec 2000, Steven Cole wrote:
> >
> > It looks like 2.4.0-test13-pre7 is a clear winner when running dbench 48
> > on my somewhat slow test machine (450 Mhz P-III, 192MB, IDE).
>
> This is almost certainly purely due to changing (som
On Sat, 30 Dec 2000, Steven Cole wrote:
>
> It looks like 2.4.0-test13-pre7 is a clear winner when running dbench 48
> on my somewhat slow test machine (450 Mhz P-III, 192MB, IDE).
This is almost certainly purely due to changing (some would say "fixing")
the bdflush synchron
It looks like 2.4.0-test13-pre7 is a clear winner when running dbench 48
on my somewhat slow test machine (450 Mhz P-III, 192MB, IDE).
2.2.183.53307 MB/sec (NB=4.41633 MB/sec 35.3307 MBit/sec)
2.2.19-pre3 3.81213 MB/sec (NB=4.76516 MB/sec 38.1213 MBit/sec)
2.4.0
>The LDT fixes in particular fix some potentially random strange behaviour.
>And the alpha memmove() thing was a showstopper bug on alphas.
And the network lockup bug...
--Ray
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
> The problem showed up on the stroke of test13-pre4-ac2 and stuff from
> Alan has been merged in. I went from pre4-ac2 to pre5 (AOK) and now
> attempting pre7...
Its definitely coming from the AX.25 related changes. Please send me your
.config and I'll go squash this one
> drivers/net
The problem showed up on the stroke of test13-pre4-ac2 and stuff from
Alan has been merged in. I went from pre4-ac2 to pre5 (AOK) and now
attempting pre7...
ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel
/head.o arch/i386/kernel/init_task.o init/main.
r. If my system hits the 'ZERO swap wall' the currently running
process (render) abort immediately and restart. With test13-pre7 it runs
several times longer (render generates some more frames) but then load goes
up to 10 and render would be killed.
SunWave1>cat /proc/version
Linux ver
As I wrote in the subject line I get an oops with 2.4.0-test13-pre7.
Board: Gigabyte BXD with newest BIOS, Dual processor
Previous kernels ( <=-test12) just printed
ACPI: support found
ACPI: PBLK 0 @ 0x:0
ACPI: PBLK 1 @ 0x:0
-0196: *** Error: Sleep State package elements
On Sat, Dec 30, 2000 at 07:54:21PM +, Tony Spinillo wrote:
> The nvidia kernel module (from www.nvidia.com) has compiled and loaded
> correctly with all test13-pre series up to pre6. I just tried to
> compile and load under pre7.
> I got the following:
> nv.c:860:unknown field `unmap
The nvidia kernel module (from www.nvidia.com) has compiled and loaded
correctly with all test13-pre series up to pre6. I just tried to
compile and load under pre7.
I got the following:
nv.c:860:unknown field `unmap' specified in initializer
nv.c:860:warning: initialization from incompatible point
On Sat, Dec 30, 2000 at 11:24:40PM +, [EMAIL PROTECTED] wrote:
> Problems with Creative Webcam III. This worked fine
> in test13-pre4, haven't tried pre5 & 6.
[snip]
> USB controller is:
>
> 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if
> 00 [UHCI])
> Su
Hi,
Problems with Creative Webcam III. This worked fine
in test13-pre4, haven't tried pre5 & 6.
On boot:
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb.c: couldn't get all of config descriptors
usb.c: unable to get device 2 configuration (error=-110)
hub.c: USB new devic
The LDT fixes in particular fix some potentially random strange behaviour.
And the alpha memmove() thing was a showstopper bug on alphas.
Linus
- pre7:
- x86 LDT handling fixes: revert some cleanups (the LDT really
doesn't act like a TLB context)
- Richard Hend
31 matches
Mail list logo
