* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-13 22:53 UTC (permalink / raw)
To: Terje Eggestad
Cc: Ville Herva, J.A. Magallon, Mark Mielke, linux-kernel, Dave Jones
In-Reply-To: <1039816682.10496.13.camel@eggis1>
Terje Eggestad wrote:
> I haven't tried the vsyscall patch, but there was a sysenter patch
> floating around that I tried. It reduced the syscall overhead with 1/3
> to 1/4, but I never tried it on P4.
>
> FYI: Just note that I say overhead, which I assume to be the time it
> take to do someting like getpid(), write(-1,...), select(-1, ...) (etc
> that is immediatlely returned with -EINVAL by the kernel).
> Since the kernel do execute a quite afew instructions beside the
> int/iret sysenter/sysexit, it's an assumption that the int 80 is the
> culprit.
>
IRET in particular is a very slow instruction.
As far as I know, though, the SYSENTER patch didn't deal with several of
the corner cases introduced by the generally weird SYSENTER instruction
(such as the fact that V86 tasks can execute it despite the fact there
is in general no way to resume execution of the V86 task afterwards.)
In practice this means that vsyscalls is pretty much the only sensible
way to do this. Also note that INT 80h will need to be supported
indefinitely.
Personally, I wonder if it's worth the trouble, when x86-64 takes care
of the issue anyway :)
-hpa
^ permalink raw reply
* [BK PATCH] ACPI updates
From: Grover, Andrew @ 2002-12-13 22:39 UTC (permalink / raw)
To: 'Linus Torvalds'; +Cc: acpi-devel-pyega4qmqnRoyOMFzWx49A
Hi Linus, please do a
bk pull http://linux-acpi.bkbits.net/linux-acpi
Summary: Bugfixes, and the beginning of an effort to make the code look more
Linux-like.
This will update the following files:
drivers/acpi/dispatcher/dsfield.c | 6 -
drivers/acpi/dispatcher/dsmthdat.c | 2
drivers/acpi/dispatcher/dsobject.c | 26 ++---
drivers/acpi/dispatcher/dsutils.c | 4
drivers/acpi/dispatcher/dswexec.c | 9 +
drivers/acpi/dispatcher/dswload.c | 8 -
drivers/acpi/dispatcher/dswstate.c | 4
drivers/acpi/events/evgpe.c | 20 ++--
drivers/acpi/events/evmisc.c | 2
drivers/acpi/executer/exconvrt.c | 25 +++--
drivers/acpi/executer/excreate.c | 2
drivers/acpi/executer/exdump.c | 8 -
drivers/acpi/executer/exfield.c | 2
drivers/acpi/executer/exfldio.c | 2
drivers/acpi/executer/exmisc.c | 12 +-
drivers/acpi/executer/exmutex.c | 2
drivers/acpi/executer/exnames.c | 14 +-
drivers/acpi/executer/exoparg2.c | 2
drivers/acpi/executer/exresolv.c | 2
drivers/acpi/executer/exstoren.c | 4
drivers/acpi/executer/exstorob.c | 14 +-
drivers/acpi/executer/exutils.c | 8 -
drivers/acpi/hardware/hwacpi.c | 2
drivers/acpi/hardware/hwregs.c | 40 ++++----
drivers/acpi/include/acconfig.h | 4
drivers/acpi/include/acdebug.h | 96 ++++++++++----------
drivers/acpi/include/acexcep.h | 12 +-
drivers/acpi/include/acglobal.h | 22 ++--
drivers/acpi/include/acinterp.h | 21 ++--
drivers/acpi/include/aclocal.h | 36 +++----
drivers/acpi/include/acmacros.h | 8 -
drivers/acpi/include/acnamesp.h | 38 +++----
drivers/acpi/include/acobject.h | 4
drivers/acpi/include/acparser.h | 12 +-
drivers/acpi/include/acpiosxf.h | 12 +-
drivers/acpi/include/acpixf.h | 2
drivers/acpi/include/acstruct.h | 4
drivers/acpi/include/actables.h | 10 +-
drivers/acpi/include/actbl.h | 20 ++--
drivers/acpi/include/actbl1.h | 4
drivers/acpi/include/actbl2.h | 4
drivers/acpi/include/actypes.h | 12 +-
drivers/acpi/include/acutils.h | 96 ++++++++++----------
drivers/acpi/include/platform/aclinux.h | 16 +--
drivers/acpi/namespace/nsaccess.c | 6 -
drivers/acpi/namespace/nsalloc.c | 2
drivers/acpi/namespace/nsdump.c | 4
drivers/acpi/namespace/nseval.c | 10 +-
drivers/acpi/namespace/nsinit.c | 4
drivers/acpi/namespace/nsnames.c | 8 -
drivers/acpi/namespace/nsobject.c | 2
drivers/acpi/namespace/nsparse.c | 2
drivers/acpi/namespace/nssearch.c | 4
drivers/acpi/namespace/nsutils.c | 30 +++---
drivers/acpi/namespace/nsxfeval.c | 4
drivers/acpi/namespace/nsxfname.c | 4
drivers/acpi/parser/psargs.c | 8 -
drivers/acpi/parser/psopcode.c | 4
drivers/acpi/parser/psparse.c | 2
drivers/acpi/resources/rsaddr.c | 20 ++--
drivers/acpi/resources/rscreate.c | 2
drivers/acpi/resources/rsirq.c | 8 -
drivers/acpi/sleep.c | 12 +-
drivers/acpi/tables/tbconvrt.c | 22 ++--
drivers/acpi/tables/tbget.c | 2
drivers/acpi/tables/tbgetall.c | 8 -
drivers/acpi/tables/tbinstal.c | 4
drivers/acpi/tables/tbrsdt.c | 6 -
drivers/acpi/tables/tbxfroot.c | 16 +--
drivers/acpi/utilities/utalloc.c | 22 +---
drivers/acpi/utilities/utcopy.c | 4
drivers/acpi/utilities/utdebug.c | 4
drivers/acpi/utilities/utdelete.c | 10 +-
drivers/acpi/utilities/uteval.c | 6 -
drivers/acpi/utilities/utglobal.c | 32 +++---
drivers/acpi/utilities/utinit.c | 16 +--
drivers/acpi/utilities/utmisc.c | 20 ++--
drivers/acpi/utilities/utobject.c | 6 -
78 files changed, 494 insertions(+), 473 deletions(-)
through these ChangeSets:
<agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org> (02/12/13 1.868)
ACPI: Fix write-related /proc entry functionality
<agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org> (02/12/12 1.867)
ACPI: update to 20021212
- remove NATIVE_CHAR typedef
- remove ACPI_{GET,VALID}_ADDRESS macros
- fix memory corruption in deletion of a static AML buffer
- fix fault caused by 0-length AML
- fix user-buffer overwrite/corruption of buffer is too small
- fix buffer-to-string conversion
-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [parisc-linux] 2.4.20-pa14 64bit crash on boot - A500-5X
From: Thibaut VARENE @ 2002-12-13 22:35 UTC (permalink / raw)
To: parisc-linux
In-Reply-To: <20021213132838.F044D49C55@mail.esiee.fr>
I strike again, now being able to provide a first analysis of the reg dump:
IAOQ = 0000000010143c48
AOUT: 0x10143c48 mod_timer+b0
Func: mod_timer, Off: b0, Addr: 0x10143c48
10143c40: 0e 70 10 d3 ldd 8(sr0,r19),r19
10143c44: 0e 60 10 d4 ldd 0(sr0,r19),r20
10143c48: 0e 83 12 d0 std r3,8(sr0,r20)
10143c4c: 0c 74 12 c0 std r20,0(sr0,r3)
10143d2c: e8 1f 1e 1d b,l 10143c40 <mod_timer+0xa8>,r0
10143d60: e8 1f 1d b5 b,l 10143c40 <mod_timer+0xa8>,r0
GR2 = 0000000010143bd4
AOUT: 0x10143bd4 mod_timer+3c
Func: mod_timer, Off: 3c, Addr: 0x10143bd4
10143bd0: 08 01 02 5a copy r1,r26
10143bd4: 08 06 02 5b copy r6,dp
10143bd8: 70 64 00 20 std r4,10(r3)
10143bdc: 0c 60 10 d4 ldd 0(sr0,r3),r20
GR3 = 0000000010538b48
AOUT: 0x10538b48 hp_diva_timer+0
Func: hp_diva_timer, Off: 0, Addr: 0x10538b48
GR20 = 0000000000000000
Kernel addresses on the stack:
[<0000000010143bd4>] mod_timer+3c
[<000000001014bf2c>] dev_probe_lock+54
[<0000000010281a94>] pci_announce_device+7c
[<000000001014018c>] __request_region+134
[<0000000010281b98>] pci_register_driver+b8
[<00000000101003c0>] init+30
[<0000000010108460>] ret_from_kernel_thread+1c
[<0000000010108518>] _switch_to_ret+0
[<00000000101317dc>] __wake_up+13c
[<0000000010137c98>] release_console_sem+1a0
[<0000000010326804>] __umoddi3+1c
[<0000000010100390>] init+0
[<0000000010137960>] printk+230
spin_unlock(000000001039a8d0): no lock cpu 0 curr PC 00000000101101a4
0x1039a8d0 pdc_lock+0
0x101101a4 pdc_emergency_unlock+24
HTH,
Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/
^ permalink raw reply
* [parisc-linux] gcc-snapshot (3.3) and linux-2.4.20-pa13
From: M. Grabert @ 2002-12-13 22:35 UTC (permalink / raw)
To: parisc-linux
Debian's gcc snapshot won't compile the kernel, (probably) due to the
same reason as here:
====
Changes since 1.46: +1 -1 lines
Diff to previous 1.46
2.5.47-pa8: remove reference to $$mulU millicode function for gcc 3.3
=====
at least it's the same error message ('undefined reference ...').
greetings max
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: Andrew McGregor @ 2002-12-13 22:25 UTC (permalink / raw)
To: Nivedita Singhvi
Cc: Bogdan Costescu, David S. Miller, dlstevens, matti.aarnio, alan,
stefano.andreani.ap, linux-kernel, linux-net
In-Reply-To: <3DFA21C5.867C6320@us.ibm.com>
--On Friday, December 13, 2002 10:07:01 -0800 Nivedita Singhvi
<niv@us.ibm.com> wrote:
> Andrew McGregor wrote:
>
>> In a closed network, why not have SOCK_STREAM map to something faster
>> than TCP anyway? That is, if I connect(address matching localnet),
>> SOCK_STREAM maps to (eg) SCTP. That would be a far more dramatic
>> performance hack!
>>
>> Andrew
>
> Not that simple. SCTP (if that is what Matti was referring to) is
> a SOCK_STREAM socket, with a protocol of IPPROTO_SCTP. I'm just
> getting done implementing a testsuite against the SCTP API.
>
> i.e. You have to know you want an SCTP socket at the time you
> open the socket. You certainly have no idea whether youre on
> a closed network or not, for that matter, the app may want to talk
> on multiple interfaces etc. (Most hosts will have one interface
> on a public net)..
Things are never that simple. But I was basically talking about a local
policy to change the (semantics of the) API in certain cases. It's
probably a bad idea and would cause all kinds of breakage, but it is
interesting to think about.
>
> Currently, Linux SCTP doesn't yet support TCP style i.e SOCK_STREAM
> sockets, we only do udp-style sockets (SOCK_SEQPACKET). We will be
> putting in SOCK_STREAM support next, but understand that performance
> is not something that has been addressed yet, and a performant SCTP
> is still some ways away (though I'm sure Jon and Sridhar will be
> working their tails off to do so ;)).
I wasn't aware of the current status. Ok, that's just where it's at.
>
> But dont expect SCTP to be the surreptitious underlying layer
> carrying TCP traffic, if thats an expectation that anyone has :)
That's my particular kind of crazy idea.
>
> Solving this problem without application involvement is a
> more limited scenario..
Indeed.
>
> thanks,
> Nivedita
>
>
Andrew
^ permalink raw reply
* new Debian packages
From: Russell Coker @ 2002-12-13 22:31 UTC (permalink / raw)
To: selinux
I have packaged the new kernel patch and the selinux-small code and uploaded
them to my web site and to Debian.
Please make sure that you install the "selinux" and "selinux-policy-default"
packages BEFORE booting a kernel compiled with the latest kernel patch.
The new kernel patch has a new type that is used in the boot phase and
will be unhappy if you have an old policy (it still seems to work
though - you can get your machine to the stage of installing the new
policy and rebooting when it's in such a state).
Russell Coker
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* RE: [PATCH] Add CONFIG_ACPI_RELAXED_AML option
From: Grover, Andrew @ 2002-12-13 22:31 UTC (permalink / raw)
To: 'Craig Whitmore', Matthew Tippett, chbm-tNiY1ywYjSU
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
> From: Craig Whitmore [mailto:lennon-q3Ck4f9/EBK9koe0gwxAeg@public.gmane.org]
> > > distributed in windows drivers.
> >
> > Continuing with this thread, would it make sense to be ACPI
> compliant
> > but allow 'custom' dsdts to be passed to the acpi subsystem to allow
> > users to work around less than perfect implementations from
> > manufacturers.
> >
>
> Just 1 question. What do the manufacturer's say when you tell
> them they have
> a "broken" dsdt? Do they normally fix it? or give some excuse
> in a reason
> why they won't fix it?
It varies. BIOS bugs exposed by Linux may be prioritized lower due to
Linux's market position in laptops. They also may not get attention if they
are on end-of-lifed machines, or rolled into a BIOS update only when enough
other bugs are fixed to justify a new BIOS's validation and release. (We may
*say* to them it is a trivial fix, but the only way to know if it breaks
Windows is for them to test it!)
There also isn't always a clear way to report BIOS bugs from end users.
On the upside, the things we're seeing are almost always obviously wrong and
easy to fix - it's just getting them to make the trivial change.
Regards -- Andy
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: RAM and swap partition
From: Chuck Gelm @ 2002-12-13 22:31 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <200212130451.gBD4pNUg019999@pegasus.wanadoo.be>
Dear Heimo:
If you will tell the list:
EXACTLY which distribution and version of linux and
EXACTLY which kernel and
EXACTLY which applications you will be using concurrently and
EXACTLY what your system's bogo MIPS is and
EXACTLY how fast your hard drive is and
EXACTLY how much RAM you have and
EXACTLY how much data your applications will be processing,
it may be suggested EXACTLY how much swap space you will need.
Until then, IMHO, the answer to this topic is,
it depends.
Tell us what you have and what you want to do with it,
and probably several fellows will suggest how much.
;-)
HTH, Chuck
Heimo Claasen wrote:
>
> It's still not really clear for my when and if, how much swap space is
> needed.
>
> There had been two opinions in this thread which clearly pointed to
> none at all - surely qualified, one from own experience re
> "workstations", the other (and that was the first time I heard about
> this at all) that swap is (only?) needed when compiling and in order
> to save a crash log.
>
> The definition of "total (virtual) memory needed" for a/one programm
> appears logical (and "natural"); but then, there should be some means
> of measurement of precisely this, in order to do some reasonable -
> and economic - decision on that workspace indeed needed.
>
> Furthermore, it seems rational to approach this in function of the
> actual use of (or installed) applications - i.e., to define, or even
> to resize if necessary (when a memory hog is added), the swap partition
> _after_ the otherwise complete installation of the "system".
>
> // Heimo Claasen // <hammer at revobild dot net> // Brussels 2002-12-12
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* updated BadRAM-patch for linux-2.4.20
From: Kristian Peters @ 2002-12-13 22:37 UTC (permalink / raw)
To: lkml
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
Hello.
Since Rick van Rein doesn't seem to update (and answer my mails) the BadRAM patch, I've done it myself.
Attached you can find a version which applies against linux-2.4.20.
Please use this patch only if you have broken RAM and thus encounter problems with it. The utility memtest86 will give you the addresses.
For further information refer Documentation/badram.txt which will be created by the patch.
*Kristian
:... [snd.science] ...:
:: _o)
:: http://www.korseby.net /\\
:: _\_V
:.........................:
[-- Attachment #2: linux-2.4.20-BadRAM-kristian-2.patch --]
[-- Type: application/octet-stream, Size: 27469 bytes --]
diff -rauN linux-2.4.20_orig/CREDITS linux-2.4.20_BadRAM/CREDITS
--- linux-2.4.20_orig/CREDITS Fri Nov 29 00:53:08 2002
+++ linux-2.4.20_BadRAM/CREDITS Fri Dec 13 16:54:15 2002
@@ -2339,6 +2339,12 @@
S: Tempe, Arizona 85282
S: USA
+N: Kristian Peters
+E: kristian.peters@korseby.net
+D: updated BadRAM patch (originally from Rick van Rein) to linux 2.4.20
+S: Rostock, Germany
+S: Germany
+
N: Kirk Petersen
E: kirk@speakeasy.org
W: http://www.speakeasy.org/~kirk/
@@ -2476,6 +2482,14 @@
S: Malvern, Pennsylvania 19355
S: USA
+N: Rick van Rein
+E: vanrein@cs.utwente.nl
+W: http://www.cs.utwente.nl/~vanrein
+D: Memory, the BadRAM subsystem dealing with statically challanged RAM modules.
+S: Binnenes 67
+S: 9407 CX Assen
+S: The Netherlands
+
N: Stefan Reinauer
E: stepan@linux.de
W: http://www.freiburg.linux.de/~stepan/
@@ -2674,6 +2688,13 @@
N: Michael Schmitz
E:
D: Macintosh IDE Driver
+
+N: Nico Schmoigl
+E: nico@writemail.com
+W: http://webrum.uni-mannheim.de/math/schmoigl/linux/
+D: Migration of BadRAM patch to 2.4.4 series (with Rick van Rein)
+S: Mannheim, BW, Germany
+P: 2047/38FC9E03 5D DB 09 E4 3F F3 CD 09 75 59 - 11 17 9C 03 46 E3 38 FC 9E 03
N: Peter De Schrijver
E: stud11@cc4.kuleuven.ac.be
diff -rauN linux-2.4.20_orig/Documentation/Configure.help linux-2.4.20_BadRAM/Documentation/Configure.help
--- linux-2.4.20_orig/Documentation/Configure.help Fri Nov 29 00:53:08 2002
+++ linux-2.4.20_BadRAM/Documentation/Configure.help Fri Dec 13 16:52:49 2002
@@ -21432,6 +21432,21 @@
This option allows you to run the kernel with data cache disabled.
Say Y if you experience CPM lock-ups.
+Work around bad spots in RAM
+CONFIG_BADRAM
+ This small kernel extension makes it possible to use memory chips
+ which are not entirely correct. It works by never allocating the
+ places that are wrong. Those places are specified with the badram
+ boot option to LILO. Read /usr/src/linux/Documentation/badram.txt
+ and/or visit http://home.zonnet.nl/vanrein/badram for information.
+
+ This option co-operates well with a second boot option from LILO
+ that starts memtest86, which is able to automatically produce the
+ patterns for the commandline in case of memory trouble.
+
+ It is safe to say 'Y' here, and it is advised because there is no
+ performance impact.
+
#
# m68k-specific kernel options
# Documented by Chris Lawrence <mailto:quango@themall.net> et al.
@@ -26557,7 +26572,7 @@
# LocalWords: CramFs Cramfs uid cramfs AVM's kernelcapi PCIV cdrdao Cdparanoia
# LocalWords: DMX Domex dmx wellington ftdi sio Accton Billington Corega FEter
# LocalWords: MELCO LUA PNA Linksys SNC chkdsk AWACS Webcam RAMFS Ramfs ramfs
-# LocalWords: ramfiles MAKEDEV pty WDTPCI APA apa
+# LocalWords: ramfiles MAKEDEV pty WDTPCI APA apa BadRAM badram vanrein zonnet
#
# The following sets edit modes for GNU EMACS
# Local Variables:
diff -rauN linux-2.4.20_orig/Documentation/badram.txt linux-2.4.20_BadRAM/Documentation/badram.txt
--- linux-2.4.20_orig/Documentation/badram.txt Thu Jan 1 01:00:00 1970
+++ linux-2.4.20_BadRAM/Documentation/badram.txt Fri Dec 13 16:52:49 2002
@@ -0,0 +1,266 @@
+INFORMATION ON USING BAD RAM MODULES
+====================================
+
+Introduction
+ RAM is getting smaller and smaller, and as a result, also more and more
+ vulnerable. This makes the manufacturing of hardware more expensive,
+ since an excessive amount of RAM chips must be discarded on account of
+ a single cell that is wrong. Similarly, static discharge may damage a
+ RAM module forever, which is usually remedied by replacing it
+ entirely.
+
+ This is not necessary, as the BadRAM code shows: By informing the Linux
+ kernel which addresses in a RAM are damaged, the kernel simply avoids
+ ever allocating such addresses but makes all the rest available.
+
+Reasons for this feature
+ There are many reasons why this kernel feature is useful:
+ - Chip manufacture is resource intensive; waste less and sleep better
+ - It's another chance to promote Linux as "the flexible OS"
+ - Some laptops have their RAM soldered in... and then it fails!
+ - It's plain cool ;-)
+
+Running example
+ To run this project, I was given two DIMMs, 32 MB each. One, that we
+ shall use as a running example in this text, contained 512 faulty bits,
+ spread over 1/4 of the address range in a regular pattern. Some tricks
+ with a RAM tester and a few binary calculations were sufficient to
+ write these faults down in 2 longword numbers.
+
+ The kernel recognised the correct number of pages with faults and did
+ not give them out for allocation. The allocation routines could
+ therefore progress as normally, without any adaption.
+ So, I gained 30 MB of DIMM which would otherwise have been thrown
+ away. After booting the kernel, the kernel behaved exactly as it
+ always had.
+
+Initial checks
+ If you experience RAM trouble, first read /usr/src/linux/memory.txt
+ and try out the mem=4M trick to see if at least some initial parts
+ of your RAM work well. The BadRAM routines halt the kernel in panic
+ if the reserved area of memory (containing kernel stuff) contains
+ a faulty address.
+
+Running a RAM checker
+ The memory checker is not built into the kernel, to avoid delays at
+ runtime. If you experience problems that may be caused by RAM, run
+ a good RAM checker, such as
+ http://reality.sgi.com/cbrady_denver/memtest86
+ The output of a RAM checker provides addresses that went wrong. In
+ the 32 MB chip with 512 faulty bits mentioned above, the errors were
+ found in the 8MB-16MB range (the DIMM was in slot #0) at addresses
+ xxx42f4
+ xxx62f4
+ xxxc2f4
+ xxxe2f4
+ and the error was a "sticky 1 bit", a memory bit that stayed "1" no
+ matter what was written to it. The regularity of this pattern
+ suggests the death of a buffer at the output stages of a row on one of
+ the chips. I expect such regularity to be commonplace. Finding this
+ regularity currently is human effort, but it should not be hard to
+ alter a RAM checker to capture it in some sort of pattern, possibly
+ the BadRAM patterns described below.
+
+ By the way, if you manage to get hold of memtest86 version 2.3 or
+ beyond, you can configure the printing mode to produce BadRAM patterns,
+ which find out exactly what you must enter on the LILO: commandline,
+ except that you shouldn't mention the added spacing. That means that
+ you can skip the following step, which saves you a *lot* of work.
+
+ Also by the way, if your machine has the ISA memory gap in the 15M-16M
+ range unstoppable, Linux can get in trouble. One way of handling that
+ situation is by specifying the total memory size to Linux with a boot
+ parameter mem=... and then to tell it to treat the 15M-16M range as
+ faulty with an additional boot parameter, for instance:
+ mem=24M badram=0x00f00000,0xfff00000
+ if you installed 24MB of RAM in total.
+
+Capturing errors in a pattern
+ Instead of manually providing all 512 errors to the kernel, it's nicer
+ to generate a pattern. Since the regularity is based on address decoding
+ software, which generally takes certain bits into account and ignores
+ others, we shall provide a faulty address F, together with a bit mask M
+ that specifies which bits must be equal to F. In C code, an address A
+ is faulty if and only if
+ (F & M) == (A & M)
+ or alternately (closer to a hardware implementation):
+ ~((F ^ A) & M)
+ In the example 32 MB chip, we had the faulty addresses in 8MB-16MB:
+ xxx42f4 ....0100....
+ xxx62f4 ....0110....
+ xxxc2f4 ....1100....
+ xxxe2f4 ....1110....
+ The second column represents the alternating hex digit in binary form.
+ Apperantly, the first and one-but last binary digit can be anything,
+ so the binary mask for that part is 0101. The mask for the part after
+ this is 0xfff, and the part before should select anything in the range
+ 8MB-16MB, or 0x00800000-0x01000000; this is done with a bitmask
+ 0xff80xxxx. Combining these partial masks, we get:
+ F=0x008042f4 M=0xff805fff
+ That covers everything for this DIMM; for more complicated failing
+ DIMMs, or for a combination of multiple failing DIMMs, it can be
+ necessary to set up a number of such F/M pairs.
+
+Rebooting Linux
+ Now that these patterns are known (and double-checked, the calculations
+ are highly error-prone... it would be neat to test them in the RAM
+ checker...) we simply restart Linux with these F/M pairs as a parameter.
+ If you normally boot as follows:
+ LILO: linux
+ you should now boot with
+ LILO: linux badram=0x008042f4,0xff805fff
+ or perhaps by mentioning more F/M pairs in an order F0,M0,F1,M1,...
+ When you provide an odd number of arguments to badram, the default mask
+ 0xffffffff (only one address matched) is applied to the pattern.
+
+ Beware of the commandline length. At least up to LILO version 0.21,
+ the commandline is cut off after the 78th character; later versions
+ may go as far as the kernel goes, namely 255 characters. In no way is
+ it possible to enter more than 10 numbers to the badram boot option.
+
+ When the kernel now boots, it should not give any trouble with RAM.
+ Mind you, this is under the assumption that the kernel and its data
+ storage do not overlap an erroneous part. If this happens, and the
+ kernel does not choke on it right away, it will stop with a panic.
+ You will need to provide a RAM where the initial, say 2MB, is faultless.
+
+ Now look up your memory status with
+ dmesg | grep ^Memory:
+ which prints a single line with information like
+ Memory: 158524k/163840k available
+ (940k kernel code,
+ 412k reserved,
+ 1856k data,
+ 60k init,
+ 0k highmem,
+ 2048k BadRAM)
+ The latter entry, the badram, is 2048k to represent the loss of 2MB
+ of general purpose RAM due to the errors. Or, positively rephrased,
+ instead of throwing out 32MB as useless, you only throw out 2MB.
+
+ If the system is stable (try compiling a few kernels, and do a few
+ finds in / or so) you may add the boot parameter to /etc/lilo.conf
+ as a line to _all_ the kernels that handle this trouble with a line
+ append="badram=0x008042f4,0xff805fff"
+ after which you run "lilo".
+ Warning: Don't experiment with these settings on your only boot image.
+ If the BadRAM overlays kernel code, data, init, or other reserved
+ memory, the kernel will halt in panic. Try settings on a test boot
+ image first, and if you get a panic you should change the order of
+ your DIMMs [which may involve buying a new one just to be able to
+ change the order].
+
+ You are allowed to enter any number of BadRAM patterns in all the
+ places documented in this file. They will all apply. It is even
+ possible to mention several BadRAM patterns in a single place. The
+ completion of an odd number of arguments with the default mask is
+ done separately for each badram=... option.
+
+Kernel Customisation
+ Some people prefer to enter their badram patterns in the kernel, and
+ this is also possible. In mm/page_alloc.c there is an array of unsigned
+ long integers into which the parameters can be entered, prefixed with
+ the number of integers (twice the number of patterns). The array is
+ named badram_custom and it will be added to the BadRAM list whenever an
+ option 'badram' is provided on the commandline when booting, either
+ with or without additional patterns.
+
+ For the previous example, the code would become
+
+ static unsigned long __init badram_custom[] = {
+ 2, // Number of longwords that follow, as F/M pairs
+ 0x008042f4L, 0xff805fffL,
+ };
+
+ Even on this place you may assume the default mask to be filled in
+ when you enter an odd number of longwords. Specify the number of
+ longwords to be 0 to avoid influence of this custom BadRAM list.
+
+BadRAM classification
+ This technique may start a lively market for "dead" RAM. It is important
+ to realise that some RAMs are more dead than others. So, instead of
+ just providing a RAM size, it is also important to know the BadRAM
+ class, which is defined as follows:
+
+ A BadRAM class N means that at most 2^N bytes have a problem,
+ and that all problems with the RAMs are persistent: They
+ are predictable and always show up.
+
+ The DIMM that serves as an example here was of class 9, since 512=2^9
+ errors were found. Higher classes are worse, "correct" RAM is of class
+ -1 (or even less, at your choice).
+ Class N also means that the bitmask for your chip (if there's just one,
+ that is) counts N bits "0" and it means that (if no faults fall in the
+ same page) an amount of 2^N*PAGESIZE memory is lost, in the example on
+ an i386 architecture that would be 2^9*4k=2MB, which accounts for the
+ initial claim of 30MB RAM gained with this DIMM.
+
+ Note that this scheme has deliberately been defined to be independent
+ of memory technology and of computer architecture.
+
+Known Bugs
+ LILO is known to cut off commandlines which are too long. For the
+ lilo-0.21 distribution, a commandline may not exceed 78 characters,
+ while actually, 255 would be possible [on i386, kernel 2.2.16].
+ LILO does _not_ report too-long commandlines, but the error will
+ show up as either a panic at boot time, stating
+ panic: BadRAM page in initial area
+ or the dmesg line starting with Memory: will mention an unpredicted
+ number of kilobytes. (Note that the latter number only includes
+ errors in accessed memory.)
+
+Future Possibilities
+ It would be possible to use even more of the faulty RAMs by employing
+ them for slabs. The smaller allocation granularity of slabs makes it
+ possible to throw out just, say, 32 bytes surrounding an error. This
+ would mean that the example DIMM only looses 16kB instead of 2MB.
+ It might even be possible to allocate the slabs in such a way that,
+ where possible, the remaining bytes in a slab structure are allocated
+ around the error, reducing the RAM loss to 0 in the optimal situation!
+
+ However, this yield is somewhat faked: It is possible to provide 512
+ pages of 32-byte slabs, but it is not certain that anyone would use
+ that many 32-byte slabs at any time.
+
+ A better solution might be to alter the page allocation for a slab to
+ have a preference for BadRAM pages, and given those a special treatment.
+ This way, the BadRAM would be spread over all the slabs, which seems
+ more likely to be a `true' pay-off. This would yield more overhead at
+ slab allocation time, but on the other hand, by the nature of slabs,
+ such allocations are made as rare as possible, so it might not matter
+ that much. I am uncertain where to go.
+
+ Many suggestions have been made to insert a RAM checker at boot time;
+ since this would leave the time to do only very meager checking, it
+ is not a reasonable option; we already have a BIOS doing that in most
+ systems!
+
+ It would be interesting to integrate this functionality with the
+ self-verifying nature of ECC RAM. These memories can even distinguish
+ between recorable and unrecoverable errors! Such memory has been
+ handled in older operating systems by `testing' once-failed memory
+ blocks for a while, by placing only (reloadable) program code in it.
+ Unfortunately, I possess no faulty ECC modules to work this out.
+
+Names and Places
+ The home page of this project is on
+ http://rick.vanrein.org/linux/badram
+ This page also links to Nico Schmoigl's experimental extensions to
+ this patch (with debugging and a few other fancy things).
+
+ In case you have experiences with the BadRAM software which differ from
+ the test reportings on that site, I hope you will mail me with that
+ new information.
+
+ The BadRAM project is an idea and implementation by
+ Rick van Rein
+ Binnenes 67
+ 9407 CX Assen
+ The Netherlands
+ vanrein@cs.utwente.nl
+ If you like it, a postcard would be much appreciated ;-)
+
+
+ Enjoy,
+ -Rick.
+
diff -rauN linux-2.4.20_orig/Documentation/kernel-parameters.txt linux-2.4.20_BadRAM/Documentation/kernel-parameters.txt
--- linux-2.4.20_orig/Documentation/kernel-parameters.txt Fri Nov 29 00:53:08 2002
+++ linux-2.4.20_BadRAM/Documentation/kernel-parameters.txt Fri Dec 13 16:52:49 2002
@@ -14,6 +14,7 @@
APIC APIC support is enabled.
APM Advanced Power Management support is enabled.
AX25 Appropriate AX.25 support is enabled.
+ BADRAM Support for faulty RAM chips is enabled.
CD Appropriate CD support is enabled.
DEVFS devfs support is enabled.
DRM Direct Rendering Management support is enabled.
@@ -109,6 +110,9 @@
awe= [HW,SOUND]
aztcd= [HW,CD] Aztec CD driver.
+
+ badram= [BADRAM] Avoid allocating faulty RAM addresses.
+
baycom_epp= [HW,AX25]
diff -rauN linux-2.4.20_orig/Documentation/memory.txt linux-2.4.20_BadRAM/Documentation/memory.txt
--- linux-2.4.20_orig/Documentation/memory.txt Fri Nov 9 22:58:02 2001
+++ linux-2.4.20_BadRAM/Documentation/memory.txt Fri Dec 13 16:52:49 2002
@@ -18,6 +18,14 @@
as you add more memory. Consider exchanging your
motherboard.
+ 4) A static discharge or production fault causes a RAM module
+ to have (predictable) errors, usually meaning that certain
+ bits cannot be set or reset. Instead of throwing away your
+ RAM module, you may read /usr/src/linux/Documentation/badram.txt
+ to learn how to detect, locate and circuimvent such errors
+ in your RAM module.
+
+
All of these problems can be addressed with the "mem=XXXM" boot option
(where XXX is the size of RAM to use in megabytes).
It can also tell Linux to use less memory than is actually installed.
@@ -45,6 +53,8 @@
* Try passing the "mem=4M" option to the kernel to limit
Linux to using a very small amount of memory.
+ If this helps, read /usr/src/linux/Documentation/badram.txt
+ to learn how to find and circuimvent memory errors.
Other tricks:
diff -rauN linux-2.4.20_orig/arch/i386/config.in linux-2.4.20_BadRAM/arch/i386/config.in
--- linux-2.4.20_orig/arch/i386/config.in Fri Nov 29 00:53:09 2002
+++ linux-2.4.20_BadRAM/arch/i386/config.in Fri Dec 13 16:52:49 2002
@@ -316,6 +316,8 @@
bool ' Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
fi
+bool 'Work around bad spots in RAM' CONFIG_BADRAM
+
endmenu
source drivers/mtd/Config.in
diff -rauN linux-2.4.20_orig/arch/i386/defconfig linux-2.4.20_BadRAM/arch/i386/defconfig
--- linux-2.4.20_orig/arch/i386/defconfig Fri Nov 29 00:53:09 2002
+++ linux-2.4.20_BadRAM/arch/i386/defconfig Fri Dec 13 16:52:49 2002
@@ -81,6 +81,7 @@
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y
+CONFIG_BADRAM=y
#
# PCMCIA/CardBus support
diff -rauN linux-2.4.20_orig/arch/i386/mm/init.c linux-2.4.20_BadRAM/arch/i386/mm/init.c
--- linux-2.4.20_orig/arch/i386/mm/init.c Fri Nov 29 00:53:09 2002
+++ linux-2.4.20_BadRAM/arch/i386/mm/init.c Fri Dec 13 21:45:26 2002
@@ -92,7 +92,7 @@
void show_mem(void)
{
- int i, total = 0, reserved = 0;
+ int i, total = 0, reserved = 0, badram = 0;
int shared = 0, cached = 0;
int highmem = 0;
@@ -106,6 +106,10 @@
highmem++;
if (PageReserved(mem_map+i))
reserved++;
+#ifdef CONFIG_BADRAM
+ if (PageBad(mem_map+1))
+ badram++;
+#endif
else if (PageSwapCache(mem_map+i))
cached++;
else if (page_count(mem_map+i))
@@ -114,6 +118,9 @@
printk("%d pages of RAM\n", total);
printk("%d pages of HIGHMEM\n",highmem);
printk("%d reserved pages\n",reserved);
+#ifdef CONFIG_BADRAM
+ printk("%d pages of BadRAM\n",badram);
+#endif
printk("%d pages shared\n",shared);
printk("%d pages swap cached\n",cached);
printk("%ld pages in page table cache\n",pgtable_cache_size);
@@ -462,7 +469,13 @@
ClearPageReserved(page);
set_bit(PG_highmem, &page->flags);
atomic_set(&page->count, 1);
- __free_page(page);
+#ifdef CONFIG_BADRAM
+ if (PageBad(page))
+ badpages++;
+ else
+#else
+ __free_page(page);
+#endif
totalhigh_pages++;
}
#endif /* CONFIG_HIGHMEM */
@@ -481,7 +494,7 @@
static int __init free_pages_init(void)
{
extern int ppro_with_ram_bug(void);
- int bad_ppro, reservedpages, pfn;
+ int bad_ppro, reservedpages, pfn, badpages;
bad_ppro = ppro_with_ram_bug();
@@ -489,13 +502,19 @@
totalram_pages += free_all_bootmem();
reservedpages = 0;
+ badpages = 0;
for (pfn = 0; pfn < max_low_pfn; pfn++) {
/*
- * Only count reserved RAM pages
+ * Only count reserved and bad RAM pages
*/
if (page_is_ram(pfn) && PageReserved(mem_map+pfn))
reservedpages++;
+#ifdef CONFIG_BADRAM
+ if (page_is_ram(pfn) && PageBad(mem_map+pfn))
+ badpages++;
+#endif
}
+
#ifdef CONFIG_HIGHMEM
for (pfn = highend_pfn-1; pfn >= highstart_pfn; pfn--)
one_highpage_init((struct page *) (mem_map + pfn), pfn, bad_ppro);
@@ -506,7 +525,7 @@
void __init mem_init(void)
{
- int codesize, reservedpages, datasize, initsize;
+ int codesize, reservedpages, datasize, initsize, badpages;
if (!mem_map)
BUG();
@@ -524,6 +543,18 @@
datasize = (unsigned long) &_edata - (unsigned long) &_etext;
initsize = (unsigned long) &__init_end - (unsigned long) &__init_begin;
+#ifdef CONFIG_BADRAM
+ printk("Memory: %luk/%luk available (%dk kernel code, %dk reserved, %dk data, %dk init, %ldk highmem, %ldk BadRAM)\n",
+ (unsigned long) nr_free_pages() << (PAGE_SHIFT-10),
+ max_mapnr << (PAGE_SHIFT-10),
+ codesize >> 10,
+ reservedpages << (PAGE_SHIFT-10),
+ datasize >> 10,
+ initsize >> 10,
+ (unsigned long) (totalhigh_pages << (PAGE_SHIFT-10)),
+ badpages << (PAGE_SHIFT-10)
+ );
+#else
printk(KERN_INFO "Memory: %luk/%luk available (%dk kernel code, %dk reserved, %dk data, %dk init, %ldk highmem)\n",
(unsigned long) nr_free_pages() << (PAGE_SHIFT-10),
max_mapnr << (PAGE_SHIFT-10),
@@ -533,6 +564,7 @@
initsize >> 10,
(unsigned long) (totalhigh_pages << (PAGE_SHIFT-10))
);
+#endif
#if CONFIG_X86_PAE
if (!cpu_has_pae)
diff -rauN linux-2.4.20_orig/include/asm-i386/page.h linux-2.4.20_BadRAM/include/asm-i386/page.h
--- linux-2.4.20_orig/include/asm-i386/page.h Sat Aug 3 02:39:45 2002
+++ linux-2.4.20_BadRAM/include/asm-i386/page.h Fri Dec 13 17:07:30 2002
@@ -132,6 +132,7 @@
#define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)
#define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET))
#define virt_to_page(kaddr) (mem_map + (__pa(kaddr) >> PAGE_SHIFT))
+#define phys_to_page(x) (mem_map + ((unsigned long)(x) >> PAGE_SHIFT))
#define VALID_PAGE(page) ((page - mem_map) < max_mapnr)
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \
diff -rauN linux-2.4.20_orig/include/linux/mm.h linux-2.4.20_BadRAM/include/linux/mm.h
--- linux-2.4.20_orig/include/linux/mm.h Sat Aug 3 02:39:45 2002
+++ linux-2.4.20_BadRAM/include/linux/mm.h Fri Dec 13 17:07:39 2002
@@ -297,6 +297,7 @@
#define PG_arch_1 13
#define PG_reserved 14
#define PG_launder 15 /* written out by VM pressure.. */
+#define PG_badram 16
/* Make it prettier to test the above... */
#define UnlockPage(page) unlock_page(page)
@@ -387,6 +388,9 @@
#define PageSlab(page) test_bit(PG_slab, &(page)->flags)
#define PageSetSlab(page) set_bit(PG_slab, &(page)->flags)
#define PageClearSlab(page) clear_bit(PG_slab, &(page)->flags)
+#define PageBad(page) test_bit(PG_badram, &(page)->flags)
+#define PageSetBad(page) set_bit(PG_badram, &(page)->flags)
+#define PageTestandSetBad(page) test_and_set_bit(PG_badram, &(page)->flags)
#define PageReserved(page) test_bit(PG_reserved, &(page)->flags)
#define PageActive(page) test_bit(PG_active, &(page)->flags)
diff -rauN linux-2.4.20_orig/mm/bootmem.c linux-2.4.20_BadRAM/mm/bootmem.c
--- linux-2.4.20_orig/mm/bootmem.c Fri Nov 29 00:53:15 2002
+++ linux-2.4.20_BadRAM/mm/bootmem.c Fri Dec 13 16:52:49 2002
@@ -257,8 +257,15 @@
if (!test_bit(i, bdata->node_bootmem_map)) {
count++;
ClearPageReserved(page);
+#ifdef CONFIG_BADRAM
+ if (!PageBad(page)) {
+ set_page_count(page, 1);
+ __free_page(page);
+ }
+#else
set_page_count(page, 1);
__free_page(page);
+#endif
}
}
total += count;
@@ -272,8 +279,15 @@
for (i = 0; i < ((bdata->node_low_pfn-(bdata->node_boot_start >> PAGE_SHIFT))/8 + PAGE_SIZE-1)/PAGE_SIZE; i++,page++) {
count++;
ClearPageReserved(page);
+#ifdef CONFIG_BADRAM
+ if (!PageBad(page)) {
+ set_page_count(page, 1);
+ __free_page(page);
+ }
+#else
set_page_count(page, 1);
__free_page(page);
+#endif
}
total += count;
bdata->node_bootmem_map = NULL;
diff -rauN linux-2.4.20_orig/mm/page_alloc.c linux-2.4.20_BadRAM/mm/page_alloc.c
--- linux-2.4.20_orig/mm/page_alloc.c Fri Nov 29 00:53:15 2002
+++ linux-2.4.20_BadRAM/mm/page_alloc.c Fri Dec 13 16:52:49 2002
@@ -10,6 +10,7 @@
* Reshaped it to be a zoned allocator, Ingo Molnar, Red Hat, 1999
* Discontiguous memory support, Kanoj Sarcar, SGI, Nov 1999
* Zone balancing, Kanoj Sarcar, SGI, Jan 2000
+ * BadRAM handling, Rick van Rein, Feb 2001
*/
#include <linux/config.h>
@@ -852,3 +853,96 @@
}
__setup("memfrac=", setup_mem_frac);
+
+
+#ifdef CONFIG_BADRAM
+
+/* Given a pointed-at address and a mask, increment the page so that the
+ * mask hides the increment. Return 0 if no increment is possible.
+ */
+static int __init next_masked_address (unsigned long *addrp, unsigned long mask)
+{
+ unsigned long inc=1;
+ unsigned long newval = *addrp;
+ while (inc & mask)
+ inc += inc;
+ while (inc != 0) {
+ newval += inc;
+ newval &= ~mask;
+ newval |= ((*addrp) & mask);
+ if (newval > *addrp) {
+ *addrp = newval;
+ return 1;
+ }
+ do {
+ inc += inc;
+ } while (inc & ~mask);
+ while (inc & mask)
+ inc += inc;
+ }
+ return 0;
+}
+
+
+void __init badram_markpages (int argc, unsigned long *argv) {
+ unsigned long addr, mask;
+ while (argc-- > 0) {
+ addr = *argv++;
+ mask = (argc-- > 0) ? *argv++ : ~0L;
+ mask |= ~PAGE_MASK; // Optimalisation
+ addr &= mask; // Normalisation
+ do {
+ struct page *pg = phys_to_page(addr);
+printk ("%05lx ", __pa(__va(addr)) >> PAGE_SHIFT);
+printk ("=%05lx/%05lx ", pg-mem_map, max_mapnr);
+ // if (VALID_PAGE(pg)) {
+ if (PageTestandSetBad (pg)) {
+ reserve_bootmem (addr, PAGE_SIZE);
+printk ("BAD ");
+ }
+else printk ("BFR ");
+ // }
+// else printk ("INV ");
+ } while (next_masked_address (&addr,mask));
+ }
+}
+
+
+
+/*********** CONFIG_BADRAM: CUSTOMISABLE SECTION STARTS HERE ******************/
+
+
+// Enter your custom BadRAM patterns here as pairs of unsigned long integers.
+// For more information on these F/M pairs, refer to Documentation/badram.txt
+
+
+static unsigned long __init badram_custom[] = {
+ 0, // Number of longwords that follow, as F/M pairs
+};
+
+
+/*********** CONFIG_BADRAM: CUSTOMISABLE SECTION ENDS HERE ********************/
+
+
+
+static int __init badram_setup (char *str)
+{
+ unsigned long opts[3];
+ if (!mem_map) BUG();
+printk ("PAGE_OFFSET=0x%08lx\n", PAGE_OFFSET);
+printk ("BadRAM option is %s\n", str);
+ if (*str++ == '=')
+ while (str=get_options (str, 3, (int *) opts), *opts) {
+printk (" --> marking 0x%08lx, 0x%08lx [%ld]\n", opts[1], opts[2], opts[0]);
+ badram_markpages (*opts, opts+1);
+ if (*opts==1)
+ break;
+ };
+ badram_markpages (*badram_custom, badram_custom+1);
+ return 0;
+}
+
+__setup("badram", badram_setup);
+
+#endif /* CONFIG_BADRAM */
+
^ permalink raw reply
* Re: raid5: switching cache buffer size
From: Gordon Henderson @ 2002-12-13 22:29 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <3DFA2E2A.20601@comedia.it>
Thanks for the replies - I've also been searching the archives of both the
raid and lvm lists and found some more on it. It seems OK until I take a
snapshot, so need to look more into the lvm stuff if I'm going to continue
using it, but I'm starting to think that lvm on raid5 might be more hassle
than it's worth, and I managed to get it to crash too when using
dump/restore and (s)tar to a SCSI tape system while running an lvm
snapshot. I'm now thinking that as I have enough disk space, I'd be better
off with 3 raid5 partitions and simply copy the data from the life
partition onto the 'yesterday' partition every night rather than use the
lvm snapshot facility...
(I was using ext2 btw, was thinking about XFS, but maybe that'd just be
too much for the system!!!)
Cheers,
Gordon
^ permalink raw reply
* Re: ACPI trouble (AC module, etc.) with Toshiba 1115-S103
From: Ducrot Bruno @ 2002-12-13 22:22 UTC (permalink / raw)
To: NoZizzing OrDripping
Cc: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20021211065826.5869.qmail-ugbtuMWqwv6A/QwVtaZbd3CJp6faPEW9@public.gmane.org>
On Tue, Dec 10, 2002 at 10:58:26PM -0800, NoZizzing OrDripping wrote:
> --- Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
...
>
> OK, I went thru the process of creating a modified
> ASL (diffs from the original attached) for this
> laptop.
> Basically, I cleaned up the original so that the
> errors
> from "iasl" went away.
>
> I now have a working AC module.
>
> This is a stopgap measure though, correct? The goal
> should be for the Linux kernel to support the existing
> AML in flash (the AML apparently comes from Microsoft)
No, it come from your BIOS. Microsoft make only a
interpreter for it, as for ACPI-CA.
> on these laptops. The BIOS on these machines is about
> as fresh as it gets (Nov, 2002). It seems to me that
> the Intel ASL compiler and interpreter needs to be
> changed/relaxed to accomodate what has become a
> defacto
> (de-gates-o) standard here.
>
> As a practical matter, I can't imagine non-programmer
> types having to modify their ASL code to make Linux
> work on their laptops, and I can't imagine that Ducrot
> wants to be the single, worldwide point, for modified
No, I don't want to. FreeBSD acpi team is good also for
this stuff as well.
> Would the ACPI developers be receptive if I made the
> changes necessary to allow the kernel ACPI code to
> accept the existing AML in my laptop as-is?
It's up to Intel ACPI guy to decide, but if I were them,
I will _not_ allow to do the same kind of bug as MS.
Imagine if they have to program as a MS developper...
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [Linux-ia64] [PATCH] fix /proc/.../vm_info
From: David Mosberger @ 2002-12-13 22:09 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805552@msgid-missing>
>>>>> On Fri, 13 Dec 2002 08:45:37 +0100, Christian Hildner <christian.hildner@hob.de> said:
Christian> I agree. But I would like a distinction between both UCs
Christian> like "UC (001)" and "UC (100)".
Ah, yes indeed. I changed it to the strings you suggested.
Thanks for catching this.
--david
^ permalink raw reply
* Re: procps 2.x vs. procps 3.x
From: Brandon Low @ 2002-12-13 22:10 UTC (permalink / raw)
To: Albert D. Cahalan; +Cc: linux-kernel
In-Reply-To: <200212131514.gBDFEhL268190@saturn.cs.uml.edu>
> If nobody else knows about it, it's not too likely to get fixed.
> Send bug reports to procps-feedback@lists.sf.net please.
>
Sorry about that, sent bug report and link to our bug track on it.
> Before you do: "certain characters" will need some explaining.
> (position? value? completely gone or turned into a space?)
In the bug report.
>
> > but the 3.x series is much prettier and
> > feature rich than the 2.x series. On the other hand, 2.x is
> > consistently more up to date with kernel changes since RML and Riel
> > maintain it and are intimately familiar with current kernel
> > development.
>
> I just got the last bit, /proc/*/wchan usage on 2.5.xx kernels.
> Oddly, I'm ahead right now. I have a vmstat that uses a fast O(1)
> algorithm on 2.5.xx kernels and reports the IO-wait time. I also
> have a sysctl that handles the 2.5.xx VLAN interfaces.
Amazing work, thanks! I hope to get your procps into Gentoo Stable RSN :)
--Brandon
^ permalink raw reply
* [RFC] 2tb limit in sd.c
From: Alex Tomas @ 2002-12-13 21:58 UTC (permalink / raw)
To: linux-kernel
Good day!
modern storage boxes support >2TB arrays, but READ CAPACITY
may return 2TB only (with 512 bytes blocksize). According to
SBC, target may return 0xffffffff as device size in order to
notify initiator that device size can't fit into 32 bits and
that initiator should use Long READ CAPACITY with 64bits LBA
field. Following patch implements this logic. Is it possible
to include patch into 2.5 ?
diff -uNr linux-2.5.47/drivers/scsi/sd.c linux-2.5.51/drivers/scsi/sd.c
--- linux-2.5.47/drivers/scsi/sd.c Sat Dec 14 00:30:14 2002
+++ linux-2.5.51/drivers/scsi/sd.c Fri Dec 13 23:58:59 2002
@@ -908,11 +908,15 @@
struct scsi_device *sdp = sdkp->device;
int the_result, retries;
int sector_size;
+ int longrc = 0;
+repeat:
retries = 3;
do {
cmd[0] = READ_CAPACITY;
memset((void *) &cmd[1], 0, 9);
+ if (longrc)
+ cmd[1] = 0x02; /* Long LBA */
memset((void *) buffer, 0, 8);
SRpnt->sr_cmd_len = 0;
@@ -921,7 +925,7 @@
SRpnt->sr_data_direction = SCSI_DATA_READ;
scsi_wait_req(SRpnt, (void *) cmd, (void *) buffer,
- 8, SD_TIMEOUT, SD_MAX_RETRIES);
+ longrc ? 12 : 8, SD_TIMEOUT, SD_MAX_RETRIES);
if (media_not_present(sdkp, SRpnt))
return;
@@ -958,14 +962,34 @@
return;
}
-
- sdkp->capacity = 1 + (((sector_t)buffer[0] << 24) |
- (buffer[1] << 16) |
- (buffer[2] << 8) |
- buffer[3]);
-
- sector_size = (buffer[4] << 24) |
- (buffer[5] << 16) | (buffer[6] << 8) | buffer[7];
+
+ if (!longrc) {
+ if (buffer[0] == 0xff && buffer[1] == 0xff &&
+ buffer[2] == 0xff && buffer[3] == 0xff) {
+ printk ("very big device. try to send long\n");
+ longrc = 1;
+ goto repeat;
+ }
+ sdkp->capacity = 1 + (((sector_t)buffer[0] << 24) |
+ (buffer[1] << 16) |
+ (buffer[2] << 8) |
+ buffer[3]);
+
+ sector_size = (buffer[4] << 24) |
+ (buffer[5] << 16) | (buffer[6] << 8) | buffer[7];
+ } else {
+ sdkp->capacity = 1 + (((sector_t)buffer[0] << 56) |
+ ((sector_t)buffer[1] << 48) |
+ ((sector_t)buffer[2] << 40) |
+ ((sector_t)buffer[3] << 32) |
+ ((sector_t)buffer[4] << 24) |
+ ((sector_t)buffer[5] << 16) |
+ ((sector_t)buffer[6] << 8) |
+ (sector_t)buffer[7]);
+
+ sector_size = (buffer[8] << 24) |
+ (buffer[9] << 16) | (buffer[10] << 8) | buffer[11];
+ }
if (sector_size == 0) {
sector_size = 512;
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Christoph Hellwig @ 2002-12-13 21:51 UTC (permalink / raw)
To: Christoph Hellwig, linux-scsi
In-Reply-To: <20021213212352.GA10883@redhat.com>
On Fri, Dec 13, 2002 at 04:23:52PM -0500, Doug Ledford wrote:
> Hmmm...what's the failure mode here?
It complains that it can't reserve the mem regions but still continues to
setup, download sequencer code, and even register scsi3ff.
^ permalink raw reply
* Re: [BK fbdev] Yet again more fbdev updates.
From: Linus Torvalds @ 2002-12-13 21:50 UTC (permalink / raw)
To: James Simmons
Cc: Christoph Hellwig, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.33.0212091651540.2360-100000@maxwell.earthlink.net>
James,
the fbcon update seems to have broken the plain VGA console. I get a page
fault at vgacon_scroll+0x144, the call sequence seems to be:
vt_console_print+0x203
set_cursor+0x78
vgacon_cursor+x0xb5
scrup+0x122
vgacon_scroll+0x144
I don't know what triggers it, since it seems to happen pretty randomly.
Linus
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Terje Eggestad @ 2002-12-13 21:57 UTC (permalink / raw)
To: Ville Herva
Cc: J.A. Magallon, Mark Mielke, H. Peter Anvin, linux-kernel,
Dave Jones
In-Reply-To: <20021213155859.GC1095@niksula.cs.hut.fi>
I haven't tried the vsyscall patch, but there was a sysenter patch
floating around that I tried. It reduced the syscall overhead with 1/3
to 1/4, but I never tried it on P4.
FYI: Just note that I say overhead, which I assume to be the time it
take to do someting like getpid(), write(-1,...), select(-1, ...) (etc
that is immediatlely returned with -EINVAL by the kernel).
Since the kernel do execute a quite afew instructions beside the
int/iret sysenter/sysexit, it's an assumption that the int 80 is the
culprit.
I would be nice if someone bothered to try this on an windoze box.
(Un)fortunatly I live in a windoze free environment. :-)
TJ
On Fri, 2002-12-13 at 16:58, Ville Herva wrote:
On Fri, Dec 13, 2002 at 10:21:11AM +0100, you [Terje Eggestad] wrote:
>
> Well, it does make sense if Intel optimized away rdtsc for more commonly
> used things, but even that don't seem to be the case. I'm measuring the
> overhead of doing a syscall on Linux (int 80) to be ~280 cycles on PIII,
> and Athlon, while it's 1600 cycles on P4.
Just out of interest, how much would sysenter (or syscall on amd) cost,
then? (Supposing it can be feasibly implemented.)
I think I heard WinXP (W2k too?) is using sysenter?
-- v --
v@iki.fi
--
_________________________________________________________________________
Terje Eggestad mailto:terje.eggestad@scali.no
Scali Scalable Linux Systems http://www.scali.com
Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal +47 975 31 574 (MOBILE)
N-0619 Oslo fax: +47 22 62 89 51
NORWAY
_________________________________________________________________________
^ permalink raw reply
* new kernel patch
From: Russell Coker @ 2002-12-13 21:48 UTC (permalink / raw)
To: selinux
The new version seems to have a bug related to file labelling that affects
devfs.
If I type "ls -l /dev/floppy/0" on a devfs system and the floppy.o module is
not loaded then the kernel will signal the devfsd daemon (through
/dev/.devfsd) that this has been attempted. In a default configuration the
devfsd will then run "modprobe /dev/floppy/0" and as the modutils config has
an alias for /dev/floppy/0 to "floppy" the floppy.o device driver is loaded.
With this new kernel it appears that the labelling takes place at a different
stage such that the devfsd gets to access a device that is not fully
labelled.
You can see the log entry below, it does not log the action, and it claims
that there is a file named /dev/floppy which is bogus. There can be
no file under /dev on a devfs system so any reference to tclass=file and
dev=00:06 means a kernel bug. Without reading the kernel code in question
I guess that file is the default tclass (defined to 0?).
But interestingly after logging >20 of the following messages the kernel
then proceeds to assign the right type to the device nodes that have been
created and then everything goes fine. Of course I expect this to fail
catastrophically in the case of device nodes that need my devfs shared
object to label them, but I haven't got around to testing this yet.
avc: denied { } for pid=65 exe=/sbin/devfsd path=/floppy dev=00:06 ino=527 scontext=system_u:system_r:devfsd_t tcontext=system_u:object_r:unlabeled_t tclass=file
PS The reason my system is unable to run my usual email program is due
to a conflict between unofficial Debian KDE packages that I've been using
and the new official Debian package og QT. Just in case you were
wondering. ;)
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: separation of sysctl and tcp-window-tracking patch?
From: Brian J. Murrell @ 2002-12-13 21:45 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <20021213120625.GA21253@oknodo.bof.de>
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]
On Fri, 2002-12-13 at 07:06, Patrick Schaaf wrote:
> > Failing a helper, I'm unable to come up with anything better than
> > adjusting timeouts on a per-port basis...
>
> What about a single new target, CTTIMEOUT or something, having a single
> parameter, a relative timeout in seconds. Whenever that target hits,
> and we have a connection hanging off our skb, the connection's timeout
> will be refreshed to now+the_given_timeout.
I guess because the idea of a parameter to set the timeout has been
floated before (by me and by others before me) and turned down (by
Rusty) in favour of a (tunable) table in the UDP conntracker. This
would be to further autoconfiguration which Rusty is a great fan of.
> I have not thought about the interplay with the current automatic
> timeout selection. Anybody?
Which is probably why doing it in the udp conntracker, in a tunable
table is the current way of thinking. Should not be too difficult in
fact. I would attempt it myself if I could get a decent stretch of
hacking time.
b.
--
Brian J. Murrell <netfilter@interlinx.bc.ca>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Margit Schubert-While @ 2002-12-13 21:52 UTC (permalink / raw)
To: linux-kernel
Hmm Apples & Oranges
diff hanoi.c hanoi2.c
17a18
> void mov();
51c52
< mov(disk,1,3);
---
> (void)mov(disk,1,3);
58c59
< mov(n,f,t)
---
> void mov(n,f,t)
67,69c68,70
< mov(n-1,f,o);
< mov(1,f,t);
< mov(n-1,o,t);
---
> (void)mov(n-1,f,o);
> (void)mov(1,f,t);
> (void)mov(n-1,o,t);
cc -O3 -march=i686 -mcpu=i686 -fomit-frame-pointer hanoi.c -o hanoi
cc -O3 -march=i686 -mcpu=i686 -fomit-frame-pointer hanoi2.c -o hanoi2
./hanoi 10
536837 loops
./hanoi 10
538709 loops
./hanoi2 10
850127 loops
./hanoi2 10
852651 loops
Huu ?
Margit
^ permalink raw reply
* [PATCH] CREDITS update
From: Christoph Hellwig @ 2002-12-14 5:00 UTC (permalink / raw)
To: marcelo, torvalds; +Cc: linux-kernel
hch moved around to work for SGI..
--- 1.61/CREDITS Thu Dec 12 00:10:28 2002
+++ edited/CREDITS Fri Dec 13 22:42:17 2002
@@ -1236,11 +1236,13 @@
N: Christoph Hellwig
E: hch@infradead.org
-D: misc driver & makefile hacking
+E: hch@sgi.com
+D: all kinds of driver, filesystem & core kernel hacking
D: freevxfs driver
D: sysvfs maintainer
-S: Triftstraße 26
-S: 38644 Goslar
+D: chief codingstyle nitpicker
+S: Auweg 38
+S: 85748 Garching
S: Germany
N: Richard Henderson
^ permalink raw reply
* how do i transform documents to ps
From: r4mz3z @ 2002-12-13 21:37 UTC (permalink / raw)
To: linux-newbie
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi friends
How do I transform a OpenOffice document to postscript format using "gs"??
thanks
- --
Linux User Registered #232544
my GnuPG-key at www.keyserver.net
--- rm -rf /bin/laden ---
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE9+lMSs4dF9gl05swRAnaXAJ9lQA7V/d9pJ0SS20f3na+o9MkdAACaAn0b
9bI9UupqODRY4o8Q0rNbcM0=
=URy/
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Justin T. Gibbs @ 2002-12-13 21:37 UTC (permalink / raw)
To: Doug Ledford, Christoph Hellwig; +Cc: linux-scsi
In-Reply-To: <20021213212352.GA10883@redhat.com>
> On Fri, Dec 13, 2002 at 09:02:15PM +0000, Christoph Hellwig wrote:
>> On Thu, Dec 12, 2002 at 03:20:52PM -0500, Doug Ledford wrote:
>> > On Wed, Dec 11, 2002 at 06:17:46PM +0000, Christoph Hellwig wrote:
>> > >
>> > > Yupp, it currently crashes when I have both compiled in. Dough, any
>> > > chance you could fix that? A PCI driver is not supposed to stop
>> > > over already claimed device.
>> >
>> > If you've got a test machine, the attached patch would I think fix the
>> > problem. Let me know if it does in fact work for you and I'll commit
>> > it to the tree.
>>
>> Still doesn't work. I think you really need to set and check the driver
>> field like justin suggested.
>
> Hmmm...what's the failure mode here?
I haven't tested it locally yet, so I'm not sure. My concern was that
the PCI subsystem would simply not know that your driver had attached
which could lead to a second attach playing with BARs or other configuration
space stuff before the aic7xxx driver even tries to map registers.
This doesn't occur in the non-PCI case, so the request region stuff is
probably sufficient there.
--
Justin
^ permalink raw reply
* Re: mmap() and NFS server performance
From: Brian Pawlowski @ 2002-12-13 21:35 UTC (permalink / raw)
To: Matthew Mitchell; +Cc: nfs
In-Reply-To: <3DFA4C9A.50101@geodev.com>
I would love to see a packet trace in the absence of any known
problems...
> Hello,
>
> We've noticed some interesting behavior regarding mmap file IO and were
> wondering if anyone here had some clues as to what might be going on.
>
> We have some applications that mmap() files into memory for the purpose
> of updating some potentially scattered word-sized data values. These
> apps were originally written on Solaris with Solaris NFS servers assumed
> to be the data source; the Sun guys said that mmap would be much faster
> than read/write and they were correct. However, now that we have a few
> Linux NFS servers, we're seeing the opposite.
>
> It takes, for example, 20-24 hours to update a 2GB file (there are on
> the order of 1M words to update) via mmap, whereas reading in the whole
> file, updating it in memory, and writing it out again takes about 30
> minutes (limited by network speed in our case). This when the file
> resides on the Linux server. On Solaris the mmap update runs on the
> order of 15-20 minutes. Client in both cases is a Solaris 8 machine.
>
> What we are speculating is that the Solaris NFS server is "cheating" by
> keeping file state information between NFS reads and writes. (The
> updates do occur in sequence.) Are there any heuristics or
> optimizations done by the Linux NFS server that might help the
> performance here?
>
> All things, alas, are not equal in this comparison -- the Solaris server
> in question is an 8 CPU Enterprise 4500 with 8GB of RAM, and the Linux
> server is a single-processor P4 with 512MB of RAM. The Solaris server
> is much busier than the Linux server, though (I know it cannot be
> caching the whole file in memory). The Linux server is running Red
> Hat's 2.4.18-14 kernel.
>
> Anyone have any ideas as to why this is happening and what, if anything,
> we can do to speed up the mmap IO when using the Linux server?
>
> --
> Matthew Mitchell
> Systems Programmer/Administrator matthew@geodev.com
> Geophysical Development Corporation phone 713 782 1234
> 1 Riverway Suite 2100, Houston, TX 77056 fax 713 782 1829
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [PATCH] set_cpus_allowed() for 2.4
From: Christoph Hellwig @ 2002-12-14 4:55 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel
In-Reply-To: <20021213213458.GG4817@fs.tum.de>
On Fri, Dec 13, 2002 at 10:34:59PM +0100, Adrian Bunk wrote:
> On Fri, Dec 13, 2002 at 06:08:14PM -0500, Christoph Hellwig wrote:
>
> >...
> > now that all vendors ship a backport of Ingo's O(1) scheduler, external
> >...
>
> #include <all-vendors-except-Debian> ;-)
OOPS, I reused the first template again. I think I owe you a beer :)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.