diff -urP virgin-linux/drivers/block/rd.c linux/drivers/block/rd.c
--- virgin-linux/drivers/block/rd.c Fri Nov 17 17:46:55 2000
+++ linux/drivers/block/rd.c Wed Nov 29 15:45:33 2000
@@ -497,7 +497,7 @@
/*
* If it matches the gzip magic numbers, return -1
*/
- if (buf[0] == 037 && ((buf[1] == 0213) || (buf[1] == 0236))) {
+ if (buf[0] == 0x1f && ((buf[1] == 0x8b) || (buf[1] == 0x9e))) {
printk(KERN_NOTICE
"RAMDISK: Compressed image found at block %d\n",
start_block);
On Wed, Nov 29, 2000 at 04:27:04PM -0700, Ian S. Nelson wrote:
> c) octals were invented for UNIX file permissions and not
> programming
You must be joking. Read much history of computing? Or
alt.folklore.computers? Octal was very natural for 18- and 36-bit
machines, after all.
Jeff
Followup to: <[email protected]>
By author: Jeff Epler <[email protected]>
In newsgroup: linux.dev.kernel
>
> On Wed, Nov 29, 2000 at 04:27:04PM -0700, Ian S. Nelson wrote:
> > c) octals were invented for UNIX file permissions and not
> > programming
>
> You must be joking. Read much history of computing? Or
> alt.folklore.computers? Octal was very natural for 18- and 36-bit
> machines, after all.
>
Not to mention that it's still quite natural for a lot of machines.
If you ever look at raw x86 machine code, with it's 3-bit fields,
byteized octal actually makes it quite easy to read.
Octal probably predates hexadecimal, since it fit within the 0-9
digits most people used. Hex is really the natural choice for
modern power-of-two-width machines, though.
-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
[1.] One line summary of the problem: PROBLEM: do_try_free_pages failed for
python
[2.] Full description of the problem/report: Running 2.2.18pre22 on a dual
Sparc20 with 128Mb of RAM.
[3.] Keywords (i.e., modules, networking, kernel):
do_try_free_pages, Sparc
[4.] Kernel version (from /proc/version):
Linux version 2.2.18pre22 (natecars@warrior) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #2 SMP Mon Nov 20 14:16:58 CST 2000
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
Not an Ooops.
[6.] A small shell script or example program which triggers the
problem (if possible)
qrunner for the mailman-2.0 final package and more then 48 files in the qfiles
directory will trigger the problem.
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux warrior 2.2.18pre22 #2 SMP Mon Nov 20 14:16:58 CST 2000 sparc unknown
Kernel modules 2.3.20
Gnu C egcs-2.91.66
Binutils 2.9.5.0.22
Linux C Library 2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.6
Mount 2.10f
Net-tools 1.54
Console-tools 0.3.3
Sh-utils 2.0
Modules Loaded
[7.2.] Processor information (from /proc/cpuinfo):
cpu : ROSS HyperSparc RT625 or RT626
fpu : ROSS HyperSparc combined IU/FPU
promlib : Version 3 Revision 2
prom : 2.25
type : sun4m
ncpus probed : 2
ncpus active : 2
Cpu0Bogo : 89.90
Cpu1Bogo : 89.90
MMU type : ROSS HyperSparc
invall : 0
invmm : 0
invrnge : 0
invpg : 0
contexts : 4096
CPU0 : online
CPU1 : online
[7.3.] Module information (from /proc/modules):
Nothing
[7.4.] SCSI information (from /proc/scsi/scsi)
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SEAGATE Model: ST15230N Rev: 0298
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: EXABYTE Model: EXB-8505 Rev: 0051
Type: Sequential-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
Vendor: IBM Model: DNES-318350 Rev: SA30
Type: Direct-Access ANSI SCSI revision: 03
[7.5.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
$ cat swaps
Filename Type Size Used Priority
/dev/sda4 partition 131804 132 -1
/dev/sdb2 partition 129596 0 -2
$ cat meminfo
total: used: free: shared: buffers: cached:
Mem: 130293760 127279104 3014656 29020160 81747968 24367104
Swap: 267673600 135168 267538432
MemTotal: 127240 kB
MemFree: 2944 kB
MemShared: 28340 kB
Buffers: 79832 kB
Cached: 23796 kB
SwapTotal: 261400 kB
SwapFree: 261268 kB
[X.] Other notes, patches, fixes, workarounds:
On Wed, 29 Nov 2000, Ian S. Nelson wrote:
> I'm sure this is a religious issue... but I'm going to suggest it
> anyways because I spent a few minutes on it.
[snip a boring troll]
Could you come up with something more, erm, amusing?
> [snip a boring troll]
Please, don't insult my mother in law. She's not that boring ;P
Igmar
On Wed, 29 Nov 2000, Bob Tanner wrote:
> [1.] One line summary of the problem: PROBLEM: do_try_free_pages
> failed for python
>
> [2.] Full description of the problem/report: Running 2.2.18pre22
> on a dual Sparc20 with 128Mb of RAM.
The important thing to know here is if you had swap
free when this error was occuring or not. If you
still had lots of swap free, this may mean that VM
in 2.2 still has some bugs left ...
regards,
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
On Thu, Nov 30, 2000 at 02:06:55PM -0200, Rik van Riel wrote:
> still had lots of swap free, this may mean that VM
> in 2.2 still has some bugs left ...
I guess it's the free_before_allocate band-aid that hurts in 2.2. That subtle
race condition is fixed efficiently in VM-global with per-process freelist
flushed atomically to the global freelist before allocation, so I'd suggest him
to try to reproduce on VM-global-7.
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre18/VM-global-2.2.18pre18-7.bz2
Andrea