headers
Randy Hron | 1 Apr 2002 01:11
Picon
Favicon

Re: Linux 2.4.19-pre5

> the problem.  You said it makes the box look like it's halted in your
> tests, I saw no such thing.  

I haven't directly observed any box tightening up for
more than a few seconds.  There have been a few reports
on lkml of things like that happening.  Based on tiotest
results, I can see if the I/O request you are waiting for 
is one of those few that isn't serviced for dozens or
hundreds of seconds, you'll be annoyed.  

The number of requests that takes over 10 seconds is 
often just 3 in 10,000.  There may be only 1 request in 
500,000 that takes 500 seconds to service.  The chance 
of your interactive i/o being the "longest" is small, unless
your interactive work is producing enough I/O to compete
with tiotest.  

What I like about read_latency2 is that most latencies
are less, and the highest latency is much less.

> Heh, maybe i'm confused on your definition of the wall. 

Sorry if that wasn't clear.  "The wall" is the point where
the highest latency in the test skyrockets.

For instance, in recent ac kernels, the _highest_ latency for 
sequential reads is less than 5 seconds at 64 threads in all 
the ac's I've tested.  At 128 threads, the _lowest_ max
latency figure is 200 seconds.   So, I used the "wall" term 
for 128 in the ac series.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Cox | 1 Apr 2002 02:11
Picon

Re: Linux 2.4.19-pre5: hotplug config

> No, the IBM driver will not work without apic.  Or at least that's what
> the original authors of the driver told me :)

Aha ok
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Liyang Hu | 1 Apr 2002 02:00

[PATCH] Bug in NLS UTF-8 code

Hi,

I've recently (actually, last month, but I had been a bit too busy
since then) come across a wee problem, in what I originally thought
was the VFAT code -- having `utf8' as one of the options, creating
UTF-8 file names on a VFAT partition mysteriously gains a couple of
(random) characters just after the UTF-8 escaped character: eg.
touch "fooCbar" where C is an UTF-8 escape sequence ends up creating
a file named "fooCRbar". (R being some random character.)

I eventually tracked it down to one line in fs/nls/nls_base.c -- the
UCS-2 (wchar_t) string pointer was being incremented too fast. After
consulting Ogawa Hirofumi-san on the subject, he mentioned that
include/linux/nls.h also needs to be changed for proper UTF-8
support in the NLS code.

Patch enclosed below.

/Liyang

----8<----snip----8<----

--- kernel-source-2.4.18/fs/nls/nls_base.c.orig	Mon Apr  1 00:26:37 2002
+++ kernel-source-2.4.18-nls/fs/nls/nls_base.c	Mon Apr  1 00:26:57 2002
 <at>  <at>  -1,5 +1,5  <at>  <at> 
 /*
- * linux/fs/nls.c
+ * linux/fs/nls_base.c
  *
  * Native language support--charsets and unicode translations.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Cobb | 1 Apr 2002 02:02

[PATCH] PCI fixup for old NCR 53C810 SCSI chips, kernel 2.4.18

This patch fixes a problem which prevents any version of the 2.4 kernel 
running on DECpc XL systems (from c. 1993).  On that system, the NCR 
53C810 SCSI subsystem integrated on the motherboard does not have a PCI 
class code, which breaks PCI resource allocation in all 2.4 kernels. 
 The symptom is "resource collisions" reported for the SCSI device:

PCI: Device 00:01.0 not available because of resource collisions

These systems typically only have SCSI disks so the 2.4 kernel cannot be 
booted.

If you are running an earlier kernel and want to know if you will have 
this problem when upgrading, use lspci -vvv and look for output similar 
to this:

00:01.0 Non-VGA unclassified device: Symbios Logic Inc. (formerly NCR) 
53c810 (rev 01)
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
    Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 4 set
    Interrupt: pin A routed to IRQ 11
    Region 0: I/O ports at d000

If the listing says "Non-VGA unclassified device" for the 53c810, it 
will not work with the 2.4 kernel.

The workround is to add fixup code for this device in 
arch/i386/kernel/pci-pc.c.  The patch is small and is included below.  I
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrea Arcangeli | 1 Apr 2002 02:04
Picon

Re: 2.4.19pre5aa1 and splitted vm-33

On Sun, Mar 31, 2002 at 08:00:38PM +0100, Christoph Hellwig wrote:
> On Sun, Mar 31, 2002 at 08:38:30PM +0200, Andrea Arcangeli wrote:
> > Hmm that's a problem. BTW, is there any valid reason xfs isn't
> > implementing O_DIRECT via the direct_IO address space operation like the
> > other filesystems ext2/reiserfs/nfs? (of course I'm talking long term, I
> > don't pretend to change that in one day, for the short term we should
> > still allow xfs to use its own internal methods of doing O_DIRECT)
> 
> For definitve answers you have to ask Steve or some else from the XFS crow,
> but if you look at the XFS data I/O path is is completly different from
> the generic Linux filesystems due to the IRIX history/compatiblity and the
> 'need' for features not present in the core kernel.  Before 2.4.10 one
> of those was O_DIRECT, btw..

Yep I understand that, it was more a request for comments on the API, to
learn if they've any design limitation with that generic API, I know it
would be tricky to convert xfs, not something I'd expect in a minor
release, I was talking a bit longer term, not necessairly for 2.4. XFS
doesn't journal data so my point was it should be just fine in theory
with the current aops direct_IO API.

For 2.5 we also need a generic library function that puts anchors into
the pagecache hash too, simulating locked pages, to serialize the I/O on
the data too during O_DIRECT to allow cleanly O_DIRECT with _data_
journaling.

> > Fixing that should be a one liner setting a_ops->direct_IO to
> > ERR_PTR(-1L) within xfs. Comments?
> 
> Looks good to me.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dale Amon | 1 Apr 2002 02:30
Gravatar

Number of loopback devices

Loopbacks are so damned useful that I'm certain I'll
soon run out of them, and I doubt I'm the only person
in that position, particularly with some of the 
improvements in the crypto patches making it possible
to run an all crypto system.

I note that the number is set in loop.c

	static int max_loop = 8;

and I wonder what the safe upper limit for this is, 
and if there is some reason for not making it larger
or perhaps making it a CONFIGurable item?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 2 comments |
headers
Andrea Arcangeli | 1 Apr 2002 02:36
Picon

Re: Linux 2.4.19-pre5

On Sat, Mar 30, 2002 at 10:52:00PM -0800, Andrew Morton wrote:
> False alarm.  My test app was not handling SIGBUS inside its SIGBUS
> handler. 

Good :). BTW, sigbus should never indicate an oom failure, SIGKILL is
always sent in such a case. If it would came out of a pagefault it would
mean it was a MAP_SHARED access beyond the end of the file.

thanks,

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
niklas | 1 Apr 2002 01:47

2.4.18-xfs and the preemptive patch

I just installed the preemptive ( http://www.tech9.net/rml/linux/ ----  preempt-kernel-rml-2.4.18-4
)  patch on my 2.4.18-xfs tree and when i run this kernel, every process ends with "exited with
preempt_count 1" ( for example "rc.2[35] exited with preempt_count 1" )
The number varies from 1 to 41 so far.
Is this a known issue that there is a fix to, or is it just a misconfigured syslog?

Please CC the answer to me as i don't subscribe to the mailing list.

//niklas
niklas <at> bumby.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 1 comment |
headers
Jörg Prante | 1 Apr 2002 03:53
Picon
Picon

[ANNOUNCE] Patch set 2.4.19-pre5-jp9

Kernel patch set jp9 of the Linux kernel 2.4.19pre5

http://infolinux.de/jp9

Jörg Prante, joerg <at> infolinux.de

Status: 01 Apr 2002 01:00

Changes from jp8 to jp9

Note: XFS can now be mounted as root filesystem. Thanks to Jared H. Hudson 
for the fix of the file system build procedure. Please compile XFS as 
built-in file system, not as a module. Otherwise there will be undefined 
symbols. Realtime clock support for ALSA Sequencer has been fixed.

Known Issues

Cdfs throws a segfault when accessing a CD.

Security note: The one-liner in 72_linux-2.4.18.secfix is not enough to fix 
the security problem in 2.4 kernels. It is only a forward port of the fix 
that can be found in older kernels. Currently as of 11 March 2002, a better 
solution is unknown. If you want to keep high security, you are requested to 
stay tuned for a new version of jp which will appear after a proven fix has 
been found

What is it?

The -jp kernels are development kernels for testing purpose only. They will 
appear regularly two or three times a month. Their purpose is to provide a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Michael Wanka | 1 Apr 2002 03:01
Picon

2.4.18 highmem smp freeze

Hi,

here are some people (including me) with smp and more than 1GB Ram 
(most Serverworks chipsets, have not jet seen it with AMDs MPX) where 
after some time (from hours to weeks probably load dependent) it 
seems there is nothing written to disk anymore and in the end the 
system completely freezes. This with several 2.4.x kernels (2.4.4, 
2.4.10, 2.4.16, 2.4.17 and 2.4.18).

I think this has been discussed here, but I am too stupid to 
understand it and/or find the solution.

I browsed the archives of the last year, and I think it was suggested 
to use 2.4.17rc2aa1 or aa2. Is this correct and will it solve the 
problem (IIRC there was no success message)? Will the later 2.2 
kernels show this behavior too (like 2.2.20)?

Thank you in advance and please cc me,

Thomas Michael Wanka
1080 Vienna, Austria
Please treat my personal data confidential

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
(Continue reading)

Permalink | Reply | 1 comment |

Gmane