Oops in 2.4.3: cat /proc/tty/driver/serial
I was just looking around and I found this: # cat /proc/tty/driver/serial Segmentation fault And this is the oops: Unable to handle kernel paging request at virtual address d00eff1c printing eip: d00eff1c *pde = 01505067 *pte = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010282 eax: c6ee3f98 ebx: caaea800 ecx: caaea820 edx: d00eff1c esi: 0400 edi: c6845000 ebp: 0400 esp: c6ee3f60 ds: 0018 es: 0018 ss: 0018 Process cat (pid: 15394, stackpage=c6ee3000) Stack: c0145cca c6845000 c6ee3f98 0400 c6ee3f94 d00f6dc0 caaea800 ffea 0400 c15de220 c012c886 caaea800 0804cda8 0400 caaea820 c6ee2000 0400 0804cda8 b834 Call Trace: [proc_file_read+242/404] [] [sys_read+150/204] [system_call+51/56] Code: Bad EIP value. Here's some info about my system: # lsmod Module Size Used by cmpci 21632 0 soundcore 3888 4 [cmpci] ne2k-pci4480 1 83906144 0 [ne2k-pci] # grep =y /boot/config-2.4.3 CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_MPENTIUMIII=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_PARPORT_1284=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_SYN_COOKIES=y CONFIG_IPV6_EUI64=y CONFIG_IPV6_NO_PB=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y CONFIG_BLK_DEV_SIS5513=y CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_IDE_MODES=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y CONFIG_NET_PCI=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_PSMOUSE=y CONFIG_JOYSTICK=y CONFIG_AGP_INTEL=y CONFIG_AGP_SIS=y CONFIG_QUOTA=y CONFIG_REISERFS_FS=y CONFIG_JOLIET=y CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_NFS_V3=y CONFIG_NFSD_V3=y CONFIG_LOCKD_V4=y CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y CONFIG_VGA_CONSOLE=y CONFIG_SOUND_CMPCI_SPDIFLOOP=y CONFIG_SOUND_CMPCI_4CH=y CONFIG_MAGIC_SYSRQ=y # cat /proc/version Linux version 2.4.3 (root@mazinger) (gcc version 2.95.4 20010319 (Debian prerelease)) #1 sáb abr 14 15:16:13 ART 2001 # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 501.132 cache size : 512 KB fdiv_bug: no hlt_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 sse bogomips: 999.42 # lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 620 Host (rev 02) 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev b3) 00:01.1 Class ff00: Silicon Integrated Systems [SiS] ACPI 00:02.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) 00:0f.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 00:0f.1 Communication controller: C-Media Electronics Inc CM8738 (rev 10) 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 6306 3D-AGP (rev 2a) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in float on Pentium
It's not that you found a new bug or that floats are inaccurate (they are
just less exact than doubles)... For example, if you make your program
print some more digits, you'll get:
5483.9899781721271574497222900390625000
5483.9902343750
#include
int main() {
unsigned int *X;
unsigned int *Y;
double x = 5483.99;
float y = 5483.99;
X = (unsigned int *)
Y = (unsigned int *)
printf ("%60.50lf\n%60.50f\n", x, y);
printf("%lf %x%x %f %x\n", x, X[1], X[0], y, *Y);
return 0;
}
which you can verify by hand:
5483.99 40b56bfd70a3d70a
0 1001011 1.0101 0110 1011 1101 0111 1010 0011 1101 0111
1010
+2^12 * 1.3388647460937499467092948179925 =
5483.9899781721271574497222900390625
5483.990234 45ab5fec
0 10001011 1.010 1011 0101 1110 1100
+ 2^12 * 1.338864803314208984375 = 5489.990234375
check out:
http://www.psc.edu/general/software/packages/ieee/ieee.html
l8r
m
Matt Billenstein
mbillens (at) one (dot) net
http://w3.one.net/~mbillens/
- Original Message -
From: "Joe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 13, 2001 7:23 PM
Subject: bug in float on Pentium
| Not sure but I think I found a NEW bug.
|
| I know that there have been some issues with pentiums and floating point
| arrithmatic, but this takes the cake...
|
| Linux Lserver.org 2.2.18 #43 SMP Fri Mar 9 14:19:41 EST 2001 i586
| unknown
|
| >kgcc --version
| egcs-2.91.66
|
| RH 6.2.x / 7.0
|
| try this program
|
| #include
|
| int main() {
|
| char tmpx[100];
| char tmpy[100];
|
| double x = 5483.99;
| float y = 5483.99;
|
| sprintf (tmpx, "%f",x );
| sprintf (tmpy, "%f",y );
|
| printf ("%s\n%s\n", tmpx, tmpy);
| return 0;
| }
|
|
| I am getting the following as output
|
| joeja@Lserver$ ./testf
| 5483.99
| 5483.990234
|
|
| what is with the .990234?? it should be .99
|
| any ideas on this??
|
| --
| Joe Acosta
| home: [EMAIL PROTECTED]
|
|
|
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to [EMAIL PROTECTED]
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "uname -p" prints unknown for Athlon K7 optimized kernel?
i have this problem using intel 850mhz and 333mhz any know where to get update version of uname ? Ishikawa wrote: > Hi, > > On my athlong K7 optimized kernel prints "unknown" fir oricessir type. > (I have not realized what this "unknown" stood for until today.) > > #uname -p > unknown > #uname -a > Linux duron 2.4.3 #2 Fri Apr 6 04:38:35 JST 2001 i686 unknown > > It would be nice to have the processor name printed. > > Is this kernel configuration procedure issue or > `uname` problem? > > # which uname > /bin/uname > # file /bin/uname > /bin/uname: ELF 32-bit LSB executable, Intel 80386, version 1, > dynamically linked (uses shared libs), stripped > # uname --version > uname (GNU sh-utils) 2.0 > Written by David MacKenzie. > > Copyright (C) 1999 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is > NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > # > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 8139too: defunct threads
On Sat, 14 Apr 2001, Manfred Spraul wrote: > From: "Alan Cox" <[EMAIL PROTECTED]> > > > > That has an implicit race, a zombie can always appear as we are > execing init. > > I think init wants fixing > > > Rod, could you boot again with the unpatched kernel and send a sigchild > to init? > > #kill -CHLD 1 > > If I understand the init code correctly the sigchild handler reaps all > zombies, but probably the signal got lost because the children died > before the parent was created ;-) That doesn't 'fix' it. The thing I find funny is that it only appears when IP_PNP is compiled in. It is as if the driver ends up in some weird state when IP_PNP is used. According to ps, from my limited understanding, the thread is stuck in do_exit [root@stewart-nw34 /root]# ps elaxww|grep eth F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 044 0 7 1 9 0 00 do_exi Z? 0:00 [eth0 ] 044 0 8 1 9 0 00 do_exi Z? 0:00 [eth1 ] 044 0 9 1 9 0 00 do_exi Z? 0:00 [eth2 ] 040 0 229 1 9 0 00 rtl813 SW ? 0:00 [eth1] Thanks for helping with this, -Rms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
one step up from vi .config
This is an example of a minimalist kernel config script using what I call
"subtractive synthesis", rather than the additive synthesis method of
make config and friends. This generates white-noise and then you filter
it, rather than painstakingly constructing your timbre one sinewave at a
time. Kinda. This example is for MCA-related pink noise, so to speak.
I think this may be related in a degenerate-case way to declarative
programming.
This leaves a lot to the user. It is based on the idea that hopefully
people with hardware with configuration interdependancies will be somewhat
cognizant of them.
I think this is close to a minimum for something that can generate any
desired config. I may have broken this somewhat tweaking it a bit to post,
but It's pretty handy when it works.
This is hereby public-domain-ified.
Rick Hohensee
:; cLIeNUX /dev/tty10 16:07:45 /
:;echo $DISTRO
cLIeNUX
.
## cLIeNUX Cheap Quick Dirty kernel config
## MAD (Microchannel Affection Disorder) example
## dependancies Linux sources and...
## sh, awk, clear, ed, your $VISUAL editor, rm, ls, mv, date
## The usual /tmp is /.tm in cLIeNUX
# function declaration
swap () { ## Last field, CONFIG_*, to second, after #
awk -- '
{
ORS=""
print "\n# " $NF
for ( i = 1 ; i < NF ; i++ ) print " "$i
} ' $1
}
# declarations
ARCH=i386
MCA=ONLY
C_INCLUDE_PATH=$C_INCLUDE_PATH:/source/kernel/$1
DATE=`date`
clear
echo -e "\t\t\tcLIeNUX linux/config\n\n\n\n
\ncollating base config data\n\n"
if a bla/Config.in file isn't in this list variable you won't see
### the options that Config.in file contains.
##Season to taste.
configlist="
arch/i386/config.in
fs/Config.in
drivers/char/Config.in
drivers/block/Config.in
drivers/scsi/Config.in
drivers/net/Config.in
fs/nls/Config.in
net/ipv4/Config.in
net/Config.in
net/sched/Config.in
net/irda/Config.in
net/irda/compressors/Config.in
drivers/net/hamradio/Config.in
drivers/net/irda/Config.in
drivers/block/paride/Config.in
drivers/char/ftape/Config.in
drivers/char/hfmodem/Config.in
drivers/char/joystick/Config.in
drivers/sound/lowlevel/Config.in
drivers/sound/Config.in
drivers/isdn/Config.in
drivers/video/Config.in
drivers/fc4/Config.in
fs/ncpfs/Config.in
net/ax25/Config.in
net/ipx/Config.in
"
## EXCLUDED from the above
## drivers/pnp/Config.in## put this back if not MCA
## drivers/cdrom/Config.in ## put this back if not MCA
## drivers/usb/Config.in
## net/irda/irlpt/Config.in
## net/irda/ircomm/Config.in
## net/irda/irlan/Config.in
## net/irda/irlpt/Config.in
## net/irda/ircomm/Config.in
## net/irda/irlan/Config.in
## net/irda/irlpt/Config.in
## drivers/acorn/net/Config.in Acorn
## drivers/acorn/scsi/Config.in
## drivers/acorn/block/Config.in
## drivers/acorn/char/Config.in
## drivers/sgi/Config.inSGI
## drivers/sbus/char/Config.in Mac
## drivers/sbus/audio/Config.in
## net/ipv6/Config.in
## drivers/fc4/Config.inFiber channel
cd linux
###MMMAIIINNN
echo > /.tm/BASE
## generate bulk CONFIG_ list.
#
for CF in $configlist
do
echo -en "\n# CONFIG\n# CONFIG " $CF "# CONFIG\n" >> /.tm/BASE
cat $CF >> /.tm/BASE
done
## format, then prune. Prune out experimental up front.
#
swap /.tm/BASE |grep "^# CONFIG" | grep -v -i "XPERIMEN" \
| cut -b 1-74 > /.tm/BASE2
rm /.tm/BASE
echo -e "\n\n\npruning...\n\n\n"
## convert choice types to "=y" and "=ym", then prune
#
ed < CONFIG
cat <> CONFIG
#
# Assuming you are seeing this via the cqdconfig script, what you do
# now is uncomment (remove the leftmost # from) the kernel options you
# want. Nothing is on now. The variables that are activated by you
# in here are then asserted as kernel sourcecode, and the
# kernel will be built accordingly. Variables can be =y or completely
# unset, and module options can also be m. If an option in here is =y you
# just have to uncomment it to assert it. If it's =ym you have to decide
# if you want it as a module or in the base kernel and pick y or m, IF you
# enable modules, and want that option. These options are additive.
# You can for example build a useless x86 kernel with just CONFIG_M386 and
# maybe a memsize option. In a useful kernel there may be some option
# interdependancies. Your only automated check on them with this
# non-rigorous config method is compiling and running the result. Most
# things that aren't non-interdependant single options will probably be
# known to people that have them. If you have problems use make config ,
# or read Documentation/Configuration.help.
#
# The cqdconfig script that generated this file is part of your
# configuration options in and of itself. You can
# tweak it to not include any options here that you're not interested in
# if you have a
RE: Disorder?
> > What kernel are you running? That is 2.4.4-pre3 > This is disabled by default. search for > where FASTRETRANS_DEBUG is enabled (should be in linux/include/net/tcp.h > and set it someting low (like 1 which is the default. The actual error > message comes up in tcp_input.c (search fro FASTRETRANS_DEBUG). > > Regards, > Bart. Thanks, Bart. Looks like it was set to 2. I have set it to 1 and will build it again. I am trying to figure out why 2.4.4 (or to be more accurate 2.4.>1) dies on me when running in my web farm. This last time I tried running top in the background with: top -b -i -d10 >crap & And it has run like a champ! First time I have ever been able to run it with good performance for more than 15 minutes. Maybe I will just substitute /dev/null for crap and that will fix it :-/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Athlon runtime problems
> Can the folks who are seeing crashes running athlon optimised kernels all mail > me > - CPU model/stepping vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 1202.743 (/proc/cpuinfo attached) 1.2G Tbird > - Chipset Iwill KK266, VIA KT133 > - Amount of RAM 512M PC133 amd-approved > - /proc/mtrr output reg00: base=0x ( 0MB), size= 512MB: write-back, count=1 reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 reg05: base=0xd800 (3456MB), size= 64MB: write-combining, count=1 (This is from inside X on a K6 kernel. I can try to save it out from the K7 kernel if needed.) > - compiler used gcc version 2.95.3 20010219 (prerelease) debian gcc 2.95.3-5 --- _.-==-._ | [EMAIL PROTECTED]| And Remember... \ [EMAIL PROTECTED] / He who controls Purple controls the Universe.. PGP Key given on Request Or at least the Purple parts! -BEGIN GEEK CODE BLOCK- Version: 3.1 [www.ebb.org/ungeek] GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++ --END GEEK CODE BLOCK-- processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 1202.743 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 2398.61
Re: CML2 1.1.1, wiuth experimental fast mode
"Eric S. Raymond" wrote: > Release 1.1.1: Sat Apr 14 23:41:34 EDT 2001 > * Synchronized with 2.4.4-pre1. pre3 is out ;-) > * Added fast-mode command to suppress side-effect computation > on slow machines. > > I'd appreciate it if some of you with slow machines would try running > with fast mode on and seeing if that addresses the sluggishness. I assume that, eventually there will be no slow mode or fast mode distinction... just a single fast mode. Right? :) -- Jeff Garzik | "Give a man a fish, and he eats for a day. Teach a Building 1024 | man to fish, and a US Navy submarine will make sure MandrakeSoft | he's never hungry again." -- Chris Neufeld - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disorder?
What kernel are you running? This is disabled by default. search for where FASTRETRANS_DEBUG is enabled (should be in linux/include/net/tcp.h and set it someting low (like 1 which is the default. The actual error message comes up in tcp_input.c (search fro FASTRETRANS_DEBUG). Regards, Bart. On Sat, 14 Apr 2001, George Bonser wrote: > What's all this in syslog? I don't remember ever seeing it there before. > > ... > Apr 14 13:58:31 foo kernel: Disorder0 3 5 f0 s2 rr1 > Apr 14 13:58:32 foo kernel: Disorder0 3 5 f0 s1 rr1 > Apr 14 13:58:41 foo kernel: Disorder0 3 8 f0 s0 rr1 > Apr 14 13:58:44 foo kernel: Disorder0 3 5 f0 s0 rr1 > Apr 14 13:58:45 foo kernel: Disorder0 3 4 f0 s0 rr1 > Apr 14 13:58:47 foo kernel: Disorder0 3 5 f0 s0 rr1 > Apr 14 13:58:55 foo kernel: Disorder3 1 5 f5 s2 rr0 > Apr 14 13:58:59 foo kernel: Undo Hoe 145.236.164.120/2007 c3 l0 ss2/2 p3 > Apr 14 13:59:00 foo kernel: Disorder0 3 5 f0 s0 rr1 > Apr 14 13:59:01 foo kernel: Disorder0 3 5 f0 s0 rr1 > Apr 14 13:59:02 foo kernel: Undo Hoe 145.236.164.120/2007 c3 l0 ss2/2 p2 > Apr 14 13:59:02 foo kernel: Disorder0 3 4 f0 s0 rr1 > Apr 14 13:59:03 foo kernel: Undo Hoe 145.236.164.120/2007 c3 l0 ss2/2 p1 > Apr 14 13:59:04 foo kernel: Undo retrans 145.236.164.120/2007 c2 l0 ss2/2 > p0 > Apr 14 13:59:11 foo kernel: Disorder0 3 5 f0 s0 rr1 > Apr 14 13:59:15 foo kernel: Disorder0 3 4 f0 s0 rr1 > Apr 14 13:59:17 foo kernel: Disorder0 3 5 f0 s0 rr1 > Apr 14 13:59:19 foo kernel: Disorder0 3 4 f0 s0 rr1 > Apr 14 13:59:21 foo kernel: Disorder0 3 4 f0 s0 rr1 > Apr 14 13:59:24 foo kernel: Disorder0 3 7 f0 s0 rr1 > Apr 14 13:59:25 foo kernel: Disorder0 3 5 f0 s0 rr1 > Apr 14 13:59:37 foo kernel: Disorder0 3 5 f0 s0 rr1 > Apr 14 13:59:57 foo kernel: Disorder3 1 5 f5 s2 rr0 > ... > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- WebSig: http://www.jukie.net/~bart/sig/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with k7 optimizations in 2.4.x?
Blew sky high. Booted stock 2.4.3-ac3, K7 optimizations, init=/bin/sh. First time it went fine for quite some time (10-15 mins, find / -print, etc) and then locked up hard on "open". Second time, it oops'd before hardlocking (which I copied out by hand.) The oops and decode are attached. On Fri, 13 Apr 2001, Alan Cox did have cause to say: > > On the iwill mobo? (I haven't heard of this problem on other > > motherboards.) > > Im not using an Iwill board. I'm using an AMD751/756 based board and an old > 'Uncle Fester' reference board. > --- _.-==-._ | [EMAIL PROTECTED]| And Remember... \ [EMAIL PROTECTED] / He who controls Purple controls the Universe.. PGP Key given on Request Or at least the Purple parts! -BEGIN GEEK CODE BLOCK- Version: 3.1 [www.ebb.org/ungeek] GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++ --END GEEK CODE BLOCK-- ksymoops 2.3.7 on i686 2.4.3. Options used -v vmlinux (specified) -K (specified) -L (specified) -O (specified) -m System.map (specified) -1 EIP: c023873a Call Trace: [] [] [] [] [] [] [] [] [] Code: 0f 6f 03 0f e7 06 0f 6f 4b 08 0f e7 4e 08 0f 6f 53 10 0f e7 Using defaults from ksymoops -t elf32-i386 -a i386 Trace; c0238847 Trace; c0121295 Trace; c0121a3b Trace; c0110d18 Trace; c0110bc0 Trace; c011be74 Trace; c011ce4a Trace; c011d1f5 Trace; c010714c Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f 6f 03 movq (%ebx),%mm0 Code; 0003 Before first symbol 3: 0f e7 06 movntq %mm0,(%esi) Code; 0006 Before first symbol 6: 0f 6f 4b 08 movq 0x8(%ebx),%mm1 Code; 000a Before first symbol a: 0f e7 4e 08 movntq %mm1,0x8(%esi) Code; 000e Before first symbol e: 0f 6f 53 10 movq 0x10(%ebx),%mm2 Code; 0012 Before first symbol 12: 0f e7 00 movntq %mm0,(%eax) null pointer defref EIP: c023873a pgd entry d904 - pmd entry d904 - pmd not present! Call Trace: [] [] [] [] [] [] [] [] [] Code: 0f 6f 03 0f e7 06 0f 6f 4b 08 0f e7 4e 08 0f 6f 53 10 0f e7
CML2 1.1.1, wiuth experimental fast mode
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.1.1: Sat Apr 14 23:41:34 EDT 2001 * Synchronized with 2.4.4-pre1. * Adam Lackorzynski's patch to make install-cml2 do the right thing with relative installation paths. * The old menuconfig shortcut that 'm' in a boolean entry field sets 'y' is now implemented. * Simplified color scheme. * Added fast-mode command to suppress side-effect computation on slow machines. I'd appreciate it if some of you with slow machines would try running with fast mode on and seeing if that addresses the sluggishness. -- http://www.tuxedo.org/~esr/">Eric S. Raymond Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Disorder?
What's all this in syslog? I don't remember ever seeing it there before. ... Apr 14 13:58:31 foo kernel: Disorder0 3 5 f0 s2 rr1 Apr 14 13:58:32 foo kernel: Disorder0 3 5 f0 s1 rr1 Apr 14 13:58:41 foo kernel: Disorder0 3 8 f0 s0 rr1 Apr 14 13:58:44 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:58:45 foo kernel: Disorder0 3 4 f0 s0 rr1 Apr 14 13:58:47 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:58:55 foo kernel: Disorder3 1 5 f5 s2 rr0 Apr 14 13:58:59 foo kernel: Undo Hoe 145.236.164.120/2007 c3 l0 ss2/2 p3 Apr 14 13:59:00 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:01 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:02 foo kernel: Undo Hoe 145.236.164.120/2007 c3 l0 ss2/2 p2 Apr 14 13:59:02 foo kernel: Disorder0 3 4 f0 s0 rr1 Apr 14 13:59:03 foo kernel: Undo Hoe 145.236.164.120/2007 c3 l0 ss2/2 p1 Apr 14 13:59:04 foo kernel: Undo retrans 145.236.164.120/2007 c2 l0 ss2/2 p0 Apr 14 13:59:11 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:15 foo kernel: Disorder0 3 4 f0 s0 rr1 Apr 14 13:59:17 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:19 foo kernel: Disorder0 3 4 f0 s0 rr1 Apr 14 13:59:21 foo kernel: Disorder0 3 4 f0 s0 rr1 Apr 14 13:59:24 foo kernel: Disorder0 3 7 f0 s0 rr1 Apr 14 13:59:25 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:37 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:57 foo kernel: Disorder3 1 5 f5 s2 rr0 ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Athlon runtime problems
Alan Cox wrote: > Can the folks who are seeing crashes running athlon optimised kernels all mail > me > > - CPU model/stepping AMD Athlon Thunderbird 850Mhz Stepping - 2 > - Chipset VIA KT133A chipset, Iwill KK266 MB. According to a couple other people this problem may only occur on this motherboard. > - Amount of RAM 256 MB Corsair PC150 > - /proc/mtrr output reg: base=0x ( 0MB), size= 256MB: write-back, count=1 reg: base=0xd500 (3408MB), size= 16MB: write-combining, count=1 > - compiler used 2.95.3 - Debian unstable package. > > Alan When these errors occur, I never get to a shell prompt. Is there a way to save the errors or have them saved somewhere so I don't have to write all that stuff down? Also, how can I set the console buffer (what is it called, where you can view previous screens with SHIFT + PgUP/DOWN?) to hold more so I don't lose some of the errors? Thanks, Moses - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Thursday 12 April 2001 23:52, Andre Hedrick wrote: > Okay but what will be used for a base for hardware that has critical > timing issues due to the rules of the hardware? > > I do not care but your drives/floppy/tapes/cdroms/cdrws do: > > /* > * Timeouts for various operations: > */ > #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms > */ #ifdef CONFIG_APM > #define WAIT_READY (5*HZ) /* 5sec - some laptops are very > slow */ #else > #define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous > */ #endif /* CONFIG_APM */ > #define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if > all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30*HZ) /* 30sec > - worst case when spinning up */ #define WAIT_CMD(10*HZ) /* 10sec > - maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (2*HZ/100) >/* 20msec - minimum sleep time */ > > Give me something for HZ or a rule for getting a known base so I can have > your storage work and not corrupt. > Wouldn't it make sense to define these in real world units? And to use that to determine requested accuracy... Those who wait for seconds will probably not have a problem with up to (half) a second longer wait - or...? Those in range of the current jiffie should be able to handle up to one jiffie longer... Requesting a wait in ms gives yo ms accuracy... /RogerL -- Roger Larsson Skellefteå Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb-uhci.c problems in latest kernels?
> usb-uhci.c: interrupt, status 3, frame# 1876 This is a known problem, here is the discussion that I initiated on linux-usb-devel: http://marc.theaimsgroup.com/?t=9860950851=2=1 The right fix is to comment that printout out. In fact, that is what I commited for Red Hat 7.1 release. Some people suggest to switch to uhci instead of usb-uhci, which helps precisely because it does not have a corresponding printk. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI tape corruption problem
In article <[EMAIL PROTECTED]> you wrote: > ... still, I've investigated on this because amverify gave me a ton of > crc errors... (I REALLY hope that amanda uses proper blocking :) yes, it does. This really looks like a st problem, or kernel. Or host adapter, or :) I have to try 2.4.x soon. Problem is for me 2.2.x is enough :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[NEED TESTERS] remove swapin_readahead Re: shmem_getpage_locked()/ swapin_readahead() race in 2.4.4-pre3
On Sat, 14 Apr 2001, Rik van Riel wrote:
> On Sat, 14 Apr 2001, Marcelo Tosatti wrote:
>
> > There is a nasty race between shmem_getpage_locked() and
> > swapin_readahead() with the new shmem code (introduced in
> > 2.4.3-ac3 and merged in the main tree in 2.4.4-pre3):
>
> > I don't see any clean fix for this one.
> > Suggestions ?
>
> As we discussed with Alan on irc, we could remove the (physical)
> swapin_readahead() and get 2.4 stable. Once 2.4 is stable we
> could (if needed) introduce a virtual address based readahead
> strategy for swap-backed things ... most of that code has been
> ready for months thanks to Ben LaHaise.
>
> A virtual-address based readahead not only makes much more sense
> from a performance POV, it also cleanly gets the ugly locking
> issues out of the way.
Test (multiple shm-stress) runs fine without swapin_readahead(), as
expected.
I tried "make -j32" test (128M RAM, 4 CPU's) and got 4m17 without
readahead against 3m40 with readahead, on average. Need real swap
intensive workloads to "really" know of how much it hurts, though.
People with swap intensive workloads: please test this and report results.
Stephen/Linus?
Patch against 2.4.4-pre3.
diff -Nur linux.orig/include/linux/mm.h linux/include/linux/mm.h
--- linux.orig/include/linux/mm.h Sat Apr 14 21:31:38 2001
+++ linux/include/linux/mm.hSat Apr 14 21:30:44 2001
@@ -425,7 +425,6 @@
extern void mem_init(void);
extern void show_mem(void);
extern void si_meminfo(struct sysinfo * val);
-extern void swapin_readahead(swp_entry_t);
/* mmap.c */
extern void lock_vma_mappings(struct vm_area_struct *);
diff -Nur linux.orig/include/linux/swap.h linux/include/linux/swap.h
--- linux.orig/include/linux/swap.h Sat Apr 14 21:31:38 2001
+++ linux/include/linux/swap.h Sat Apr 14 21:30:28 2001
@@ -145,7 +145,6 @@
struct inode **);
extern int swap_duplicate(swp_entry_t);
extern int swap_count(struct page *);
-extern int valid_swaphandles(swp_entry_t, unsigned long *);
#define get_swap_page() __get_swap_page(1)
extern void __swap_free(swp_entry_t, unsigned short);
#define swap_free(entry) __swap_free((entry), 1)
diff -Nur linux.orig/mm/memory.c linux/mm/memory.c
--- linux.orig/mm/memory.c Sat Apr 14 21:31:38 2001
+++ linux/mm/memory.c Sat Apr 14 21:28:34 2001
@@ -1012,42 +1012,6 @@
return;
}
-
-
-/*
- * Primitive swap readahead code. We simply read an aligned block of
- * (1 << page_cluster) entries in the swap area. This method is chosen
- * because it doesn't cost us any seek time. We also make sure to queue
- * the 'original' request together with the readahead ones...
- */
-void swapin_readahead(swp_entry_t entry)
-{
- int i, num;
- struct page *new_page;
- unsigned long offset;
-
- /*
-* Get the number of handles we should do readahead io to. Also,
-* grab temporary references on them, releasing them as io completes.
-*/
- num = valid_swaphandles(entry, );
- for (i = 0; i < num; offset++, i++) {
- /* Don't block on I/O for read-ahead */
- if (atomic_read(_async_pages) >= pager_daemon.swap_cluster
- * (1 << page_cluster)) {
- while (i++ < num)
- swap_free(SWP_ENTRY(SWP_TYPE(entry), offset++));
- break;
- }
- /* Ok, do the async read-ahead now */
- new_page = read_swap_cache_async(SWP_ENTRY(SWP_TYPE(entry), offset),
0);
- if (new_page != NULL)
- page_cache_release(new_page);
- swap_free(SWP_ENTRY(SWP_TYPE(entry), offset));
- }
- return;
-}
-
/*
* We hold the mm semaphore and the page_table_lock on entry and exit.
*/
@@ -1062,7 +1026,6 @@
page = lookup_swap_cache(entry);
if (!page) {
lock_kernel();
- swapin_readahead(entry);
page = read_swap_cache(entry);
unlock_kernel();
if (!page) {
diff -Nur linux.orig/mm/shmem.c linux/mm/shmem.c
--- linux.orig/mm/shmem.c Sat Apr 14 21:31:38 2001
+++ linux/mm/shmem.cSat Apr 14 21:28:44 2001
@@ -328,7 +328,6 @@
if (!page) {
spin_unlock (>lock);
lock_kernel();
- swapin_readahead(*entry);
page = read_swap_cache(*entry);
unlock_kernel();
if (!page)
diff -Nur linux.orig/mm/swapfile.c linux/mm/swapfile.c
--- linux.orig/mm/swapfile.cThu Mar 22 14:22:15 2001
+++ linux/mm/swapfile.c Sat Apr 14 21:30:04 2001
@@ -955,34 +955,3 @@
}
return;
}
-
-/*
- * Kernel_lock protects against swap device deletion. Grab an extra
- * reference on the swaphandle so that it dos not become unused.
- */
-int valid_swaphandles(swp_entry_t entry, unsigned long
2.4 stable when?
I have a web server farm that right now has about 125 apache processes running per machine. If I try to use 2.4.3 or even 2.4.3-ac6 it will go to about 400 (meaning it is slow in clearing connections), the load average will start to climb until it gets to close to 100 and then stops responding. It runs ok for about the first 5 minutes of its life and then sinks deeper and deeper into the mire until it disappears. No processes are shown stuck in D state. 2.4.4pre3 works, sorta, but is very "pumpy". The load avg will go up to about 60, then drop, then climb again, then drop. It will vary from very sluggish performance to snappy and back again to sluggish. With 2.2 kernels I see something like this: 00:48:00 up 4:51, 1 user, load average: 0.00, 0.02, 0.06 141 processes: 139 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 2.8% user, 3.2% system, 0.0% nice, 94.1% idle and that is with about 120 remote users connected to the box via apache. Is there any information that would be helpful to the kernel developers that I might be able to provide or is this a known issue that is currently being worked out? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Still cannot compile, 2.4.3-ac6
On Sun, 15 Apr 2001, Marko Kreen wrote: > Sorry. Who said it should not be tested? How else it could get > 'default compiler'? If the gcc-3.0 would start giving errors > on some old code then it could be gcc bug. But this rwsem code > is couple of days old. It is good to let it through stricter > error checking, I guess. This rwsem is very in-flux code. eg. > 2.4.4-pre2 did not compile. ac[56] with um-arch do not compile. For what its worth, I got the same error on 2.4.3-ac5, using gcc 2.91.66. I did seem messages fly by in on the list about a few in -ac5, but haven't gone back to dig them out. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DPT PM3755F Fibrechannel Host Adapter
On Sat, Apr 14, 2001 at 05:33:02PM -0600, [EMAIL PROTECTED] wrote: > I have been unable to set up a module for my DPT fibrechannel host adapter, partly >through unavailability, and partly through inexperience. There is a nice suppary of current DPT driver status on Kernel Traffic #113: http://kt.zork.net/kernel-traffic/kt20010330_113.html#3 -- marko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RealTek 8139 driver updated, tested requested
Hi! Jeff Garzik wrote: > A new version of the ethernet driver for RTL-8139-based 10/100 boards > has been posted at > > http://sourceforge.net/projects/gkernel/ > > This update includes a couple major bugfixes, and I am interested in > getting the widest testing possible for it. No problems so far. It works fine since 10 hours. No more "too much work on interrupt" messages. Thanks, Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DPT PM3755F Fibrechannel Host Adapter
I have been unable to set up a module for my DPT fibrechannel host adapter, partly through unavailability, and partly through inexperience. Found Ricky Beam's 2.4.0-test7 .diff, but lack the experience to retrofit it to 2.4.2. Tried patch -su http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 8139too: defunct threads
Hi,
On Sat, Apr 14, 2001 at 07:53:28PM +0100, Alan Cox wrote:
> > Rod's init version (from RH 7.0) doesn't reap children that died before
> > it was started. Is that an init bug or should the kernel reap them
> > before the execve?
> I would say thats an init bug
It doesn't seem to be that simple.
Redhat's init does child reaping in its SIGCHLD handler using the
following:
while((pid = waitpid(-1, , WNOHANG)) != 0) {
if (errno == ECHILD) break;
/* do some stuff, nothing which could break out of the loop */
}
This should reap all leftover childs from kernel startup when init
receives SIGCHLD for the first time, but somehow the kernel seems to
skip them while searching for a dead process in sys_wait4(). I can't
do any further testing because I don't have a 8139 NIC, but I can't
find a problem in init's child reaping code.
Please tell me if I'm missing something, but I think this is really a
kernel issue, not a bug in init.
Andreas
--
I've finally learned what "upward compatible" means. It means we get to
keep all our old mistakes.
-- Dennie van Tassel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How do I make a circular pipe?
On Sat, Apr 14, 2001 at 10:44:46AM -0700, Rob Landley wrote: > Info. Never thought to check info. Here I am > checking linuxdoc's howtos, man pages, and google... > Sigh... I don't suppose there's an info2html tool > anywhere? 'pinfo' can also be very useful - looks a lot like lynx, but processess info files directly. > Well what do you know, there is. (I LIKE Google.) They also like linux, I hear :-) Regards, bert -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bizarre TCP behavior
On Sat, 14 Apr 2001, Alan Cox wrote: > If the router claims to be RFC compliant then you may want to investigate > trading standards bodies. In the UK at least things like the advertising > standards agency get upset by people who claim standards compliance, are shown > not to be compliant and are not fixing things.. Wasnt someone going to set up an 'ECN hall of shame' webpage to track noncompliant vendors - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Still cannot compile, 2.4.3-ac6
On Sun, Apr 15, 2001 at 01:03:35AM +0300, Matti Aarnio wrote: > On Sat, Apr 14, 2001 at 09:09:00PM +, Thorsten Glaser Geuer wrote: > > Dear Sirs, > > I still cannot compile with gcc-3.0 from 08.04. > > Yes ? Who said gcc-3.0 is suitable compiler ? > > No doubt it some day will be the default compiler, but not yet. Sorry. Who said it should not be tested? How else it could get 'default compiler'? If the gcc-3.0 would start giving errors on some old code then it could be gcc bug. But this rwsem code is couple of days old. It is good to let it through stricter error checking, I guess. This rwsem is very in-flux code. eg. 2.4.4-pre2 did not compile. ac[56] with um-arch do not compile. If nothing else convinces, then AFAIK both Linus and Alan expressed interest in seeing reports of using newer gcc's. Remember, gcc-3.0 is in freeze since Feb 12. (Ofcourse they also suggested against using random CVS snapshot as default compiler in distrubution). -- marko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Writing to Pana DVD-RAM
[EMAIL PROTECTED] wrote: > Hello, > > I am running RedHat Wolverine (beta) with kernel 2.4.2. I have a SCSI subsystem >(AHA2740) with a Panasonic LF-D101 DVDRAM on it. > > I read that the CDROM driver is built to recognize DVDRAMs and allow writes; well I >can mount and read the UDF file system fine, but am not allowed writes. I have >UDF2.0 on the disk, because it didn't recognize UDF2.1. > > Also, when I make xconfig, it includes UDF support, but read-only. >(Write-Experimental is grayed-out) > > In fstab: /dev/scd1 is mounted to /mnt/dvdram udf default 0 0. (paraphrasing) > > I need the DVDRAM for backups and file transfers. Is the problem the driver, the >UDF filesystem, my setup, or what? > -- > C. > > The best way out is always through. > - Robert Frost A Servant to Servants, 1914 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Check that "Experimental " is enabled under "Code Maturity level options", if you can't find it try using "make menuconfig" instead of "make xconfig" Note that the UDF-write support option is listed as "Dangerous"... possibly making things difficult, but then again if you have a DVD-RAM, how bad can things be :) Cheers, Jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Still cannot compile, 2.4.3-ac6
On Sat, Apr 14, 2001 at 09:09:00PM +, Thorsten Glaser Geuer wrote: > Dear Sirs, > I still cannot compile with gcc-3.0 from 08.04. Yes ? Who said gcc-3.0 is suitable compiler ? No doubt it some day will be the default compiler, but not yet. For that matter, what "gcc-3.0" ?? Looking at http://gcc.gnu.org/ I see *NO* gcc-3.0 being released, only CVS tag of 3.0 branch which aims for stability and release. > -- /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape Corruption - update 2
In article <[EMAIL PROTECTED]> you write: >On Fri, 13 Apr 2001, Nate Eldredge wrote: >> (32 bytes is the size of a cache line.) A memory tester might be >> something to try (I wrote a simple program that seemed to show the >> error better than memtest86; can send it if desired.) > >Already tried that... this system has passed some 20 hours running >memtest86... I suggest you try Cerberus: https://sourceforge.net/projects/va-ctcs/ which will viciously beat your system to within an inch of its life. If you have any motherboard problems, they're more likely to show up with Cerberus than with a simple memtest. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 8139too: defunct threads
From: "Alan Cox" <[EMAIL PROTECTED]> > > That has an implicit race, a zombie can always appear as we are execing init. > I think init wants fixing > Rod, could you boot again with the unpatched kernel and send a sigchild to init? #kill -CHLD 1 If I understand the init code correctly the sigchild handler reaps all zombies, but probably the signal got lost because the children died before the parent was created ;-) -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Writing to Pana DVD-RAM
Hello, I am running RedHat Wolverine (beta) with kernel 2.4.2. I have a SCSI subsystem (AHA2740) with a Panasonic LF-D101 DVDRAM on it. I read that the CDROM driver is built to recognize DVDRAMs and allow writes; well I can mount and read the UDF file system fine, but am not allowed writes. I have UDF2.0 on the disk, because it didn't recognize UDF2.1. Also, when I make xconfig, it includes UDF support, but read-only. (Write-Experimental is grayed-out) In fstab: /dev/scd1 is mounted to /mnt/dvdram udf default 0 0. (paraphrasing) I need the DVDRAM for backups and file transfers. Is the problem the driver, the UDF filesystem, my setup, or what? -- C. The best way out is always through. - Robert Frost A Servant to Servants, 1914 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Still cannot compile, 2.4.3-ac6
Dear Sirs, I still cannot compile with gcc-3.0 from 08.04. Yesterday I tried -ac5 (same problem reported earlier) and using egcs-2.91.66 for _only_ the peoblematic files (sys.c exec.c binfmt_elf.c and two others which I dont remember) but the kernel could not boot. Now I get: gcc -D__KERNEL__ -I/glc/build/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c signal.c gcc -D__KERNEL__ -I/glc/build/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c sys.c sys.c: In function `sys_gethostname': /glc/build/linux/include/asm/rwsem-xadd.h:153: inconsistent operand constraints in an `asm' make[2]: *** [sys.o] Error 1 make[2]: Leaving directory `/glc/build/linux/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/glc/build/linux/kernel' make: *** [_dir_kernel] Error 2 ecce:/usr/src/linux # And ver_linux reports: ecce:/usr/src/linux # sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux ecce.homeip.net 2.4.3-ac3 #3 Sun Apr 8 22:06:09 /etc/localtime 2001 i686 unknown Gnu C 3.0 Gnu make 3.77 binutils 2.10.0.33 util-linux 2.11a mount 2.11a modutils 2.4.5 e2fsprogs 1.19 reiserfsprogs 3.x.0j PPP2.4.1b2 Linux C Libraryx 1 root root 1248080 Apr 8 21:14 /lib/libc.so.6 Dynamic linker (ldd) 2.2 Procps 1.2.11 Net-tools 1.59 Kbd0.99 Sh-utils 1.16 Modules Loaded ecce:/usr/src/linux # LIBC6 is originally from SuSE 6.2 but I updated with the one from SuSE 7.1 manually (I think I have both here?? will recompile soon glibc-2.2.2) If any of you could help me, thanks in advance. The problem _did_ _not_ exist with same gcc-3 and 2.4.3-ac3. It doesn't vanish when I get the full patches, not the interdiffs. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "uname -p" prints unknown for Athlon K7 optimized kernel?
uname has printed unknown for the cpu vendor for as long as I can remember. There is a hacked uname.c distributed as "nuname" that works for cyrix intel and amd, maybe others. http://cds.duke.edu/pub/sunsite/utils/shell/nuname-1.0.tar.gz I *think* Cyrix shows up as CyrixInstead Dual P120 Linux mandelbrot 2.4.4-pre3 #2 SMP Sat Apr 14 12:15:33 PDT 2001 i586 GenuineIntel Athlon 1Ghz Linux noc 2.4.3 #1 Fri Mar 30 12:44:13 PST 2001 i686 AuthenticAMD Dual P3-450 Linux sandbox 2.4.3 #1 SMP Sat Mar 31 17:40:57 PST 2001 i686 GenuineIntel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: comments on CML 1.1.0
Marko Kreen <[EMAIL PROTECTED]>: > Using CML2 1.1.0 'menuconfig' on clean 2.4.3 (mach is PPro 180) > > Suggestions: > > * the 'N' should be shown as ' ' as in menuconfig - it is > visually much better to get overview of whole screenful. > 'Y'/'M' and 'N' are basically of 'same size' so you must look > directly on letter to understand what it is - not good. I've gone this one better. It's now "Y", "m", " ", so the m and y responses are easily distinguished. > * the menuconfig had nice shortcut: when you pressed 'm' on > [YN] field, it put 'y' there without questions. So you could > use only 2 keys to configure one screen: 'n/m'. this meant > you did not need to move fingers around and think about it > so much - big thing when you are not touch-typer... Implemented. > * the colors are hard to see (red/blue on black). Probably > matter of terminal settings. I do not have any productive > ideas tho... Probably to get best experience to as much > people as possible the less colors are used the better. > > The 'blue: last visited submenu' is unnecessary. Especially > because it later turns green... And the 'red' vs. 'green' > thing. I guess the green should be used for 'visited entries' > too. Now the red means like 'Doh. So I should not have > touched this?'. Confusing. > > In other words: if there are too much colors, they become > a thing that should be separately learned, not a helpful > aid. > > All this IMHO ofcourse. Colors are 'matter of taste' thing > so there probably is not exact Rigth Thing. You make good points. In the 1.1.1, blue and yellow/brown will be gone; it's just green for everything visited. > Bugs/complaints: > > * aic7xxx is not updated (defaults: are 8/5 should be 253/5000) > (this from arch/i386/defconfig maybe?) Fixed. > * 'IDE chipset support' nesting is very confusing - compare > to menuconfig. I would say even 'wrong'... > (eg. 'PIIXn tuning' is is under 'PIIXn support' which is not > under 'ATA works in progress'. Rules-file patches will be cheerfully accepted. > * screen is redrawn after _every_ keystroke - not only in moving > around, but even when you are on input field... I know. The workaround is to use gnome-term, which for some reason doesn't show this. It's tops on my longer-term to-do list. > * input field: when there is some default and I start typing it > should either clear it or append. On my to-do list. -- http://www.tuxedo.org/~esr/">Eric S. Raymond The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "uname -p" prints unknown for Athlon K7 optimized kernel?
BTW this is also the case for AMD-K6-3 and I would imagine all other AMD processors. B. On Sun, 15 Apr 2001, Ishikawa wrote: > Hi, > > On my athlong K7 optimized kernel prints "unknown" fir oricessir type. > (I have not realized what this "unknown" stood for until today.) > > #uname -p > unknown > #uname -a > Linux duron 2.4.3 #2 Fri Apr 6 04:38:35 JST 2001 i686 unknown > > It would be nice to have the processor name printed. > > Is this kernel configuration procedure issue or > `uname` problem? > > # which uname > /bin/uname > # file /bin/uname > /bin/uname: ELF 32-bit LSB executable, Intel 80386, version 1, > dynamically linked (uses shared libs), stripped > # uname --version > uname (GNU sh-utils) 2.0 > Written by David MacKenzie. > > Copyright (C) 1999 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is > NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > # > > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- WebSig: http://www.jukie.net/~bart/sig/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loop problems continue in 2.4.3
On Sat, 14 Apr 2001, Aaron Lunansky wrote: Why not indeed? - should have thought about it myself Well, I wrote the script. It has been running for 10 minutes now mounting and unmounting an iso image. Nothing happens. I guess I should be happy. Still don't undertand where the original Oops came from > If you're intent on making it oops why not write a script to mount/unmount > it repeatedly? > > > Regards, > Aaron > > > -Original Message- > From: Arthur Pedyczak <[EMAIL PROTECTED]> > To: Jens Axboe <[EMAIL PROTECTED]> > CC: Linux kernel list <[EMAIL PROTECTED]>; Jeff Garzik > <[EMAIL PROTECTED]> > Sent: Sat Apr 14 08:46:49 2001 > Subject: Re: loop problems continue in 2.4.3 > > On Sat, 14 Apr 2001, Jens Axboe wrote: > > [ SNIP..] > > > = > > > Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging > request at virtual address 7e92bfd7 > > > > Please disable syslog decoding (it sucks) and feed it through ksymoops > > instead. > > > > In other words, reproduce and dmesg | ksymoops instead. > > > > > I tried to reproduce the error this morning and couldn't. Same kernel > (2.4.3), same setup, same iso file. It mounted/unmounted 10 times with no > problem. DOn't know what to think. > > Arthur > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Athlon runtime problems
[ sent to linux-kernel due to Alan rejecting all mail from Earthlink/Mindspring, I'm assuming he is still interested in the report though ] On Saturday 14 April 2001 09:13, Alan Cox wrote: > Can the folks who are seeing crashes running athlon optimised > kernels all mail me I have two Athlon machines with mysterious (no oops) lockups. I've just started running them as 586 to see if that stops the lockups. The first one: > - CPU model/stepping model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 1195.214 > - Chipset VIA KT133/KM133 (Iwill KK266) > - Amount of RAM MemTotal: 770960 kB > - /proc/mtrr output reg00: base=0x ( 0MB), size= 512MB: write-back, count=1 reg01: base=0x2000 ( 512MB), size= 256MB: write-back, count=1 reg02: base=0xd400 (3392MB), size= 32MB: write-combining, count=2 reg05: base=0xd000 (3328MB), size= 64MB: write-combining, count=2 > - compiler used gcc 2.95.4 The second one: > - CPU model/stepping model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 1000.050 > - Chipset VIA KT133/KM133 (MSI K7TPro) > - Amount of RAM MemTotal: 255588 kB > - /proc/mtrr output reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg05: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 > - compiler used gcc 2.95.4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"uname -p" prints unknown for Athlon K7 optimized kernel?
Hi, On my athlong K7 optimized kernel prints "unknown" fir oricessir type. (I have not realized what this "unknown" stood for until today.) #uname -p unknown #uname -a Linux duron 2.4.3 #2 Fri Apr 6 04:38:35 JST 2001 i686 unknown It would be nice to have the processor name printed. Is this kernel configuration procedure issue or `uname` problem? # which uname /bin/uname # file /bin/uname /bin/uname: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped # uname --version uname (GNU sh-utils) 2.0 Written by David MacKenzie. Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: comments on CML 1.1.0
jeff millar <[EMAIL PROTECTED]>: > Selecting IP_NF_COMPAT_IPCHAINS turns off IP_NF_CONNTRACK and friends. But, > I think CML1, allowed both support to the new iptables and compatibility > modes to allow old ipchains scripts to work with the new kernel. Would somebody who knows what these dependencies are please send me a rule patch? -- http://www.tuxedo.org/~esr/">Eric S. Raymond ...Virtually never are murderers the ordinary, law-abiding people against whom gun bans are aimed. Almost without exception, murderers are extreme aberrants with lifelong histories of crime, substance abuse, psychopathology, mental retardation and/or irrational violence against those around them, as well as other hazardous behavior, e.g., automobile and gun accidents." -- Don B. Kates, writing on statistical patterns in gun crime - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: shmem_getpage_locked() / swapin_readahead() race in 2.4.4-pre3
On Sat, 14 Apr 2001, Marcelo Tosatti wrote: > There is a nasty race between shmem_getpage_locked() and > swapin_readahead() with the new shmem code (introduced in > 2.4.3-ac3 and merged in the main tree in 2.4.4-pre3): > I don't see any clean fix for this one. > Suggestions ? As we discussed with Alan on irc, we could remove the (physical) swapin_readahead() and get 2.4 stable. Once 2.4 is stable we could (if needed) introduce a virtual address based readahead strategy for swap-backed things ... most of that code has been ready for months thanks to Ben LaHaise. A virtual-address based readahead not only makes much more sense from a performance POV, it also cleanly gets the ugly locking issues out of the way. regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI tape corruption problem
On Sat, 14 Apr 2001, Marc SCHAEFER wrote: > Now try this: > >cd ~archive >mt -f /dev/tapes/tape0 rewind >tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k > > and then: > >mt -f /dev/tapes/tape0 rewind >dd if=/dev/tapes/tape0 bs=32k | gzip -d | tar --compare -v -f - > > The above is the proper way to talk to a tape drive through gzip. I see the blocking part... but in my second experiment I've used ONLY dd to put a large file on tape... ... still, I've investigated on this because amverify gave me a ton of crc errors... (I REALLY hope that amanda uses proper blocking :) -- Lorenzo Marcantonio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 8139too: defunct threads
> Rod's init version (from RH 7.0) doesn't reap children that died before
> it was started. Is that an init bug or should the kernel reap them
> before the execve?
I would say thats an init bug
> The attached patch reaps all zombies before the execve("/sbin/init").
That has an implicit race, a zombie can always appear as we are execing init.
I think init wants fixing
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape Corruption - update 2
On Fri, 13 Apr 2001, Nate Eldredge wrote: > (32 bytes is the size of a cache line.) A memory tester might be > something to try (I wrote a simple program that seemed to show the > error better than memtest86; can send it if desired.) Already tried that... this system has passed some 20 hours running memtest86... Also I've got NO OTHER memory failure symptom (and the tape fails only on writing) -- Lorenzo Marcantonio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI tape corruption problem
In article <[EMAIL PROTECTED]> you wrote: > So you make gzip use blocks of 32 kB. no, infact it really makes it using blocks of 4k (a PIPE_SIZE is 4k), so it is really equivalent to bs=4k. dd doesn't re-join blocks when they are smaller then bs=, unless you specify obs=32k. I have been playing with buffer recently and mixed up both. buffer is really a nice tool. But as I said, as long as you don't play with non-fixed block size you don't have problems. sorry for mixup. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3
On Sat, Apr 14, 2001 at 12:21:20AM +0200, Guest section DW wrote: > No, these codes cannot be larger than 127 today. > You can use the utility setkeycodes to assign keycodes to these keys. I always tought it is 8bit - more-than-128-keys keyboards exists quite long time. > [One of the things for 2.5 is 15- or 31-bit keycodes. > The 7-bits we have today do no longer suffice. I have a 132-key keyboard.] Yes, this is necessary then. Hmm, the move to 15bits looks simple, any ideas why this wasn't implemented before ? Yes, this isn't priority, because it is working fine with setkeycodes, but anyway ... Jan Dvorak <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Swap Corruption in 2.4.3 ?
On 10 Apr 2001, Richard Russon wrote: > VM: Undead swap entry 000bb300 > VM: Undead swap entry 00abb300 > VM: Undead swap entry 016fb300 I have seen similar mysterious crashes of X server when I began accessing large web page using Netscape navigator. It was reproducible the first few times I noticed. Today, a similar problem occurred and luckily I noticed console messages printed on a virtual console. There ware many lines like the following. swap_free: Trying to freee non-existent swap page Bad Swap Entry: 0008 Bad Swap Entry: 008 ... VM: Kiling process jserver Swap_free: Trying to free non-existent swap page ... It seems that there was some sort of kernel data corruption. (In my case, the kernel could not find the swap page and failed to swap out memory and thus the VM's selective process killer was invoked to free up memory?) Then eventually I got Unable to handle kernel NULL pointer defreence at ... message and the system crashed. (I was also typing Alt+SysReq+keystroke to see if I could sync disk.) . Anyway, this probem seems to be in 2.4.2, too from what I recall about the first mysterious X server crash. On Apri 20 Rik van Riel wrote: >Known bug ... unknown cause ;( > >http://www.linux-mm.org/bugzilla.shtml has it already listed The symptom there didn't match mine, but I do suspect a (new) problem in VM of 2.4.3 (2.4.2, too. 2.4.1, I am not sure.). Happy Hacking - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI tape corruption problem
On Sat, 14 Apr 2001, Geert Uytterhoeven wrote: > Do you also mean it is illegal to use blocksize 10 kB (default tar, no gzip) > with a tape drive?? not at all. Infact, with the default settings of the st driver, any multiple of 512 bytes is ok. The additional dd step is just there to be sure everything is fine. If gzip always outputs multiple of 512 bytes then everything is fine. I do this as precaution, since on Solaris with an old Exabyte tape if you didn't do the extra dd you had various bizarre problems. Linux is much nicer, but ... Now if you change st defaults to e.g. variable block mode, then it changes a bit the equation: you need to read exactly the same size of block (e.g. bs=32k) else you get an error. Variable block mode is mt -f /dev/nst0 setblk 0. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.1.0 bug and snailspeed
Anton Altaparmakov <[EMAIL PROTECTED]>: > In the menu the colour scheme is a bit strange but everyone has a > different taste. Would need some getting used to, but ok. It does seem > like a step back in time though, compared to the old menuconfig which had > nice windows feel and colours, IMHO. I am not sure why it had to be > changed. Surely you can have the old interface with the new theorem > prover? I couldn't do both that and share back-end code with the other interfaces. > I found a bug: In "Intel and compatible 80x86 processor options", "Intel > and compatible 80x86 processor types" I press "y" on "Pentium Classic" > option and it activates Penitum-III as well as Pentium Classic options at > the same time!?! Tried to play around switching to something else and then > onto Pentium Classic again and it enabled Pentium Classic and Pentium > Pro/Celeron/Pentium II (NEW) this time! Something is very wrong here. Rules file bug, probably. I'll investigate this afternoon. > Now a general comment: CML2 is extremely slow to the point of not being > usable! )-: I'm still tuning. -- http://www.tuxedo.org/~esr/">Eric S. Raymond Love your country, but never trust its government. -- Robert A. Heinlein. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Athlon runtime problems
On Sat, Apr 14, 2001 at 04:12:09PM +0100, Alan Cox wrote: > Can the folks who are seeing crashes running athlon optimised kernels all mail > me Just trying to privide you with usefull info. I'm NOT seeing any crashes at all. > - CPU model/stepping processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 807.190 cache size : 256 KB > - Chipset VIA KT133/KM133 (An Asus A7V) > - Amount of RAM 128 MiB > - /proc/mtrr output No support for it compiled in. > - compiler used gcc version 2.95.3 20010315 (release) (compiled myself) Kurt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How do I make a circular pipe?
> > Apparently, the pipe > > fd's evaporate when the process does an execve. > > Check out: > > #include > #include > >/* ... */ > > fcntl (fd, F_SETFD, (long) FD_CLOEXEC); > > to set/reset the close on exec bit. Cool. That's EXACTLY what I was looking for. Thanks. Thanks also to the people who pointed out pppd's "pty" option (yes I read the docs on that, but they're a bit cryptic). And yes, my pseudo-code example used fd[0] twice. Thanks. You can stop emailing me now. :) > You might want to check out something like Stevens > advanced UNIX programming, though it is probably > somewhat dated :-) I've got about fifteen books with names like that, but strangely in real world situations I keep trying to use the man pages instead. Sad, I know... > At a guess I would say that the reason is you don't > have as much control with pipes as you do with > devices. Under the standard termios, you can tell > the system to not return from the read until either n > characters have been read, or a given character such > as a newline has been read. You can also switch to > alternative line disciplines that are more targeted > to a given application such as PPP, etc. Hmmm. And the reason these cool toys aren't available as some kind of wrapper around a normal read-from-fd is...? (Performance?) > You probably want to check out pseudo tty's (pty's), > which allow you to create your own terminal. This occurred to me in the car on the way home after five hours messing with this. (Of course. :) > Here is the glibc documentation, Thanks. Info. Never thought to check info. Here I am checking linuxdoc's howtos, man pages, and google... Sigh... I don't suppose there's an info2html tool anywhere? Well what do you know, there is. (I LIKE Google.) http://www.cs.dartmouth.edu/~jonh/info2html/ Rob __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: patch for PLIP and slow, interrupt-less computers
"W. Michael Petullo" <[EMAIL PROTECTED]> writes: |> Here is the patch: |> |> |> |> --- plip.c Tue Feb 13 16:15:05 2001 |> +++ /tmp/linux/drivers/net/plip.cThu Apr 12 16:07:07 2001 |> @@ -137,10 +137,10 @@ |> #define PLIP_DELAY_UNIT1 |> |> /* Connection time out = PLIP_TRIGGER_WAIT * PLIP_DELAY_UNIT usec */ |> -#define PLIP_TRIGGER_WAIT500 |> +static unsigned long trigger_wait = 500; ^ |> |> /* Nibble time out = PLIP_NIBBLE_WAIT * PLIP_DELAY_UNIT usec */ |> -#define PLIP_NIBBLE_WAIT3000 |> +static unsigned long nibble_wait = 3000; ^ |> @@ -1297,6 +1297,8 @@ |> |> MODULE_PARM(parport, "1-" __MODULE_STRING(PLIP_MAX) "i"); |> MODULE_PARM(timid, "1i"); |> +MODULE_PARM(trigger_wait, "i"); |> +MODULE_PARM(nibble_wait, "i"); ^^^ The types don't match. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI tape corruption problem
On Sat, 14 Apr 2001, Marc SCHAEFER wrote:
> Now try this:
>
>cd ~archive
>mt -f /dev/tapes/tape0 rewind
>tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k
>
> and then:
>
>mt -f /dev/tapes/tape0 rewind
>dd if=/dev/tapes/tape0 bs=32k | gzip -d | tar --compare -v -f -
>
> The above is the proper way to talk to a tape drive through gzip.
So you make gzip use blocks of 32 kB.
Do you also mean it is illegal to use blocksize 10 kB (default tar, no gzip)
with a tape drive??
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
shmem_getpage_locked() / swapin_readahead() race in 2.4.4-pre3
Hi, There is a nasty race between shmem_getpage_locked() and swapin_readahead() with the new shmem code (introduced in 2.4.3-ac3 and merged in the main tree in 2.4.4-pre3): shmem_getpage_locked() finds a page in the swapcache and moves it to the pagecache as an shmem page, freeing the swapcache and the swap map entry for this page. (which causes a BUG() in mm/shmem.c:353 since the swap map entry is being used) In the meanwhile, swapin_readahead() is allocating a page and adding it to the swapcache. I don't see any clean fix for this one. Suggestions ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 1.1.0 bug and snailspeed
Ok, I tried the CML2 1.1.0. (Had to spend hours installing Python 2.0 until I found all required configure options and got the right modules compiled in, but ok, that's a one off and is not CML2's fault, also ran make test to make sure it works.) Installed cml, cwd to kernel, and ran make menuconfig. Waited about 2-5 minutes (didn't time it) to get the menu. Slower than CML1 by a bit. [Note: My development machine is a Pentium Classic 133S with 64MiB ECC RAM and ATA-100 7200RPM HD on Promise ATA-100 controller with several network cards, runs like a charm with 2.4 kernel for what it is used for: file serving/ftp serving/smb serving/nat] In the menu the colour scheme is a bit strange but everyone has a different taste. Would need some getting used to, but ok. It does seem like a step back in time though, compared to the old menuconfig which had nice windows feel and colours, IMHO. I am not sure why it had to be changed. Surely you can have the old interface with the new theorem prover? I found a bug: In "Intel and compatible 80x86 processor options", "Intel and compatible 80x86 processor types" I press "y" on "Pentium Classic" option and it activates Penitum-III as well as Pentium Classic options at the same time!?! Tried to play around switching to something else and then onto Pentium Classic again and it enabled Pentium Classic and Pentium Pro/Celeron/Pentium II (NEW) this time! Something is very wrong here. Now a general comment: CML2 is extremely slow to the point of not being usable! )-: It would take me hours to configure a kernel with this. Just pressing "n"/"y" or "m" somewhere takes easily several seconds to complete... Pressing any of the arrow keys takes between 1 (up/down) and 10 (left/right) seconds to complete. *Argh!* When a window is up, saying press any key to continue there are delays of several seconds of nothing happening at all before the window disappers. With this slow response time, I wonder whether I actually pressed the key so press it again, key gets queued, so it gets executed when the first key press has finished executing wreaking havoc. )-: It might be all cool and good having a theorem prover and what not inside the configuration but if this is going to replace CML1 completely, IMHO, you will _have_ to provide some speedy way of configuration (and no, using "vi .config" or equivalent is not an option I would like to use...). Many people have been commenting that speed doesn't matter "just use a newer computer" but that argument is just stupid IMNSHO. That's what MS says when they release a new OS/program... I don't need a new computer, this one works absolutely fine and maxes out all it's 10Mbit network connections quite happily, so why should I buy something faster?!? Just to configure a kernel? Surely not. Linux has always been the OS of choice for people with a small budget and the way it is going it is running the danger of loosing this corner of this rather big market. I will be back to CML1 now so I can configure and kick off the compile of this kernel before dinner... Best regards, Anton -- Anton Altaparmakov (replace at with @) Linux NTFS maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: 8139too: defunct threads
Hi Alan,
Rod's init version (from RH 7.0) doesn't reap children that died before
it was started. Is that an init bug or should the kernel reap them
before the execve?
The attached patch reaps all zombies before the execve("/sbin/init").
I also found a bug in kernel/context.c: it doesn't acquire the sigmask
spinlock around the call to recalc_sigpending.
Rod Stewart wrote:
>
> Yes, that fixes my problem. No more defunct eth? processes when IP_PNP is
> compiled in. With the fix you said to the patch; replacing curtask with
> current.
>
Fortunately you don't use SMP - spin_lock_irq();...;spin_lock_irq()
instead of spin_lock_irq();...;spin_unlock_irq();
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 3
// EXTRAVERSION = -ac3
--- 2.4/init/main.c Sat Apr 7 22:02:27 2001
+++ build-2.4/init/main.c Sat Apr 14 19:18:34 2001
@@ -883,6 +883,13 @@
(void) dup(0);
(void) dup(0);
+
+ while (waitpid(-1, (unsigned int *)0, __WALL|WNOHANG) > 0)
+ ;
+ spin_lock_irq(>sigmask_lock);
+ flush_signals(current);
+ recalc_sigpending(current);
+ spin_unlock_irq(>sigmask_lock);
/*
* We try each of these until one succeeds.
--- 2.4/kernel/context.cFri Feb 2 15:20:37 2001
+++ build-2.4/kernel/context.c Sat Apr 14 19:09:10 2001
@@ -101,8 +101,10 @@
if (signal_pending(curtask)) {
while (waitpid(-1, (unsigned int *)0, __WALL|WNOHANG) > 0)
;
+ spin_lock_irq(>sigmask_lock);
flush_signals(curtask);
recalc_sigpending(curtask);
+ spin_unlock_irq(>sigmask_lock);
}
}
}
2.4.3-ac6 config options with no Configure.help text.
As of kernel 2.4.3-ac6, there are 575 config options which have no help text in Configure.help. Here is a list of these items which have been introduced recently, after 2.4.3-ac1. Each group is incremental, versus 2.4.3-ac[n-1]. If you see one of your options here, please consider generating a patch for Configure.help, or send me the information and I'll do the rest. A status of "acknowledged" means that the item is being worked on by the person named or their designate or the patch has been submitted but hasn't yet appeared in an -ac release. Thank you to the maintainers who have responded. Thanks in advance, Steven 2.4.3-ac6 CONFIG_AIC7XXX_BUILD_FIRMWARE 2.4.3-ac5 CONFIG_IA64_EFIVARS acknowledgedMatt Domsch CONFIG_ITANIUM CONFIG_MCKINLEY CONFIG_MCKINLEY_A0_SPECIFIC CONFIG_MCKINLEY_ASTEP_SPECIFIC 2.4.3-ac4 CONFIG_ARCH_CLPS711X CONFIG_ARCH_P720T CONFIG_ARM_THUMB CONFIG_CPU_ARM1020 CONFIG_CPU_ARM610 acknowledgedRussell King CONFIG_CPU_ARM710 acknowledgedRussell King CONFIG_CPU_ARM720T acknowledgedRussell King CONFIG_CPU_ARM920T acknowledgedRussell King CONFIG_CPU_SA110acknowledgedRussell King CONFIG_DASD_DIAG CONFIG_DEBUG_CLPS711X_UART2 CONFIG_DEBUGSYM CONFIG_GCOV CONFIG_GPROF CONFIG_HOSTFS CONFIG_NET_UM_ETH CONFIG_NET_UMN CONFIG_SA1100_PANGOLIN CONFIG_SA1100_SHERMAN CONFIG_SSL 2.4.3-ac3 none 2.4.3-ac2 CONFIG_GEMINI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loop problems continue in 2.4.3
If you're intent on making it oops why not write a script to mount/unmount it repeatedly? Regards, Aaron -Original Message- From: Arthur Pedyczak <[EMAIL PROTECTED]> To: Jens Axboe <[EMAIL PROTECTED]> CC: Linux kernel list <[EMAIL PROTECTED]>; Jeff Garzik <[EMAIL PROTECTED]> Sent: Sat Apr 14 08:46:49 2001 Subject: Re: loop problems continue in 2.4.3 On Sat, 14 Apr 2001, Jens Axboe wrote: [ SNIP..] > > = > > Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging request at virtual address 7e92bfd7 > > Please disable syslog decoding (it sucks) and feed it through ksymoops > instead. > > In other words, reproduce and dmesg | ksymoops instead. > > I tried to reproduce the error this morning and couldn't. Same kernel (2.4.3), same setup, same iso file. It mounted/unmounted 10 times with no problem. DOn't know what to think. Arthur - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] adding PCI bus information to SCSI layer
Alan Cox wrote: > > > Also ISA adapters are not the only non-PCI adapters, > > there are the growing band of pseudo adapters that > > may or may not have a PCI bus at the bottom of some > > other protocol stack. > > An ioctl might be better. We already have an ioctl for querying the lun > information for a disk. We could also return the bus information for its > controller(s) [remember multipathing] Both 'cat /proc/scsi/scsi' and ioctls used on fds belonging to the existing upper level drivers (e.g. sd and sr) have a problem as far as getting HBA environment information: there needs to be at least one SCSI device (target) connected to the HBA. With no SCSI devices connected, there is no fd to do an ioctl on. [The same problem arises if a device is there but marked offline, has an exclusive lock on it, ...] Perhaps Matt could look at the approach I have taken with the scsimon experimental upper level driver. Scsimon was originally designed to get scsi based information to the /sbin/hotplug mechanism. It also supplies ioctls to probe HBAs as well as SCSI devices. More information about it can be found at: http://www.torque.net/scsi/scsimon.html It should not be difficult to add HBA PCI bus information to scsimon (after the Scsi_Host structure is expanded to hold that information). Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 8139too: defunct threads
On Sat, 14 Apr 2001, Manfred Spraul wrote:
> >> Ah. Of course. All (or most) kernel initialisation is
> >> done by PID 1. Search for "kernel_thread" in init/main.c
> >>
> >> So it seems that in your setup, process 1 is not reaping
> >> children, which is why this hasn't been reported before.
> >> Is there something unusual about your setup?
>
> > I found the difference which causes this. If I build my kernel with
> > IP_PNP (IP: kernel level autoconfiguration) support I get a defunt
> > thread for each 8139too device. If I don't build with IP_PNP
> > support I don't get any, defunct ethernet threads.
>
> Does init(8) reap children that died before it was spawned? I assume
> that the defunct tasks were there _before_ init was spawned.
>
> Perhaps init() [in linux/init/main.c] should reap all defunct tasks
> before the execve("/sbin/init").
>
> I've attached an untested patch, could you try it?
Yes, that fixes my problem. No more defunct eth? processes when IP_PNP is
compiled in. With the fix you said to the patch; replacing curtask with
current.
Thanks,
-Rms
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pci SDSL card
The Xpeed X200/300. Go to http://www.xpeed.com/Products/x300/300ds.pdf Kernel support for the cards appeared in ftp://ftp.cs.helsinki.fi/pub/Software/Linux/Kernel/people/alan/2.2.18pre/pre-patch-2.2.18-18.gz I guess it hasn't been ported to 2.4 yet. Samuli On Fri, 13 Apr 2001, Gabriel Rocha wrote: > does anyone know of a linux supported, pci SDSL card? I see a couple that are >windows based, but nothing on those and linux...thanks in advance. --gabe > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
>>> = Rik van Riel <[EMAIL PROTECTED]> >> = Adam J. Richter <[EMAIL PROTECTED]> > = Michael O'Reilly <[EMAIL PROTECTED]> >> Rik van Riel <[EMAIL PROTECTED]> writes, regarding the idea >> of having do_fork() give all of the parent's remaining time slice to >> the newly created child: >> >>>It could upset programs which use threads to handle >>>relatively IO poor things (like, waiting on disk IO in a >>>thread, like glibc does to fake async file IO). >> >> Good point. >Is it really? If a program is using thread to handle IO things, >then: >a) It's not going to create a thread for every IO! So I think >the argument is suprious anyway. Maybe not that often, but, from my incomplete understanding of linux/kernel/sched.c, it looks like it can be a really long time before the recalculate loop in schedule() gets called. Currently, the time slice of a regular "nice 0" process in Linux is 50ms (NICE_TO_TICKS(20) = 5, and each tick is 10ms). So, if you're on a multiuser system or you're running some parallel algorithm that uses a bunch of threads so that nobody has to rendezvous to block on IO, then this could on the order of one second. Tangential note: I think the 50ms process time slice makes Linux boxes that have a lot of runnable threads or processes unresponsive in ways that will not show up in most benchmarks, making things like multi-user VNC servers much less scalable than they should be. I wish the Linux "recalculate" loop would scale the time slices to #cpu's/#runnable processes, such as by replacing changing the "p->counter = ..." line in the "recalculate" loop in schedule() to something like this: int runnables; ... runnables = 0; list_for_each(tmp, _head) runnables++; runnables /= smp_num_cpus; runnables = runnables ? runnables : 1; /* prevent division by 0 */ for_each_task(p) p->counter = (p->counter >> 1) + (NICE_TO_TICKS(p->nice) / runnables) + 1; (the "+ 1" at the end would ensure that the increment is never zero, even if runnables is very high.) Anyhow, getting back to the topic at hand... >b) You _still_ want the child to run first. The child >will start the I/O and block, then switching back >to the parent. This maximises the I/O thruput without >costing you any CPU. (Reasoning: The child running >2nd will increase the latency which automatically >reduces the number of ops/second you can get). Absolutely. I never said that it would be a good idea run the parent first in that case and Rik didn't either. Under Rik's idea, the child would still run first, but the parent could retain some CPU priority, so that it could get around to running again before the next call to the "recalculate" loop in schedule(), which might be 1 second if the system has 20 runnable runnable threads. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: comments on CML 1.1.0
Selecting IP_NF_COMPAT_IPCHAINS turns off IP_NF_CONNTRACK and friends. But, I think CML1, allowed both support to the new iptables and compatibility modes to allow old ipchains scripts to work with the new kernel. jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
patch for PLIP and slow, interrupt-less computers
I have written a quick patch for the PLIP driver contained in the 2.4.3
version of the Linux kernel. This patch allows one to use PLIP with
computers which have an interrupt-less parallel port and a slow processor.
The stock PLIP driver constantly times out on my 80486-based laptop.
This patch adds the ability to specify two key values, trigger_wait and
nibble_wait, when loading the PLIP driver.
Using this patch and adding the following entry to the modules.conf file
on the computers on either side of my PLIP link makes the connection
work nicely:
# Because my laptop is so slow.
options pliptrigger_wait=5 nibble_wait=30
Here is the patch:
--- plip.c Tue Feb 13 16:15:05 2001
+++ /tmp/linux/drivers/net/plip.c Thu Apr 12 16:07:07 2001
@@ -137,10 +137,10 @@
#define PLIP_DELAY_UNIT 1
/* Connection time out = PLIP_TRIGGER_WAIT * PLIP_DELAY_UNIT usec */
-#define PLIP_TRIGGER_WAIT 500
+static unsigned long trigger_wait = 500;
/* Nibble time out = PLIP_NIBBLE_WAIT * PLIP_DELAY_UNIT usec */
-#define PLIP_NIBBLE_WAIT3000
+static unsigned long nibble_wait = 3000;
/* Bottom halves */
static void plip_kick_bh(struct net_device *dev);
@@ -345,8 +345,8 @@
nl->port_owner = 0;
/* Initialize constants */
- nl->trigger = PLIP_TRIGGER_WAIT;
- nl->nibble = PLIP_NIBBLE_WAIT;
+ nl->trigger = trigger_wait;
+ nl->nibble = nibble_wait;
/* Initialize task queue structures */
INIT_LIST_HEAD(>immediate.list);
@@ -1297,6 +1297,8 @@
MODULE_PARM(parport, "1-" __MODULE_STRING(PLIP_MAX) "i");
MODULE_PARM(timid, "1i");
+MODULE_PARM(trigger_wait, "i");
+MODULE_PARM(nibble_wait, "i");
static struct net_device *dev_plip[PLIP_MAX] = { NULL, };
--
W. Michael Petullo
:wq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Athlon runtime problems
On Sat, 14 Apr 2001, Alan Cox wrote: > Can the folks who are seeing crashes running athlon optimised kernels all mail > me > > - CPU model/stepping Athlon Thunderbird 700mhz /proc/cpu: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 700.034 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 1395.91 > - Chipset VIA KT133 > - Amount of RAM 256MB > - /proc/mtrr output reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xd400 (3392MB), size= 32MB: write-combining, count=2 reg05: base=0xd000 (3328MB), size= 64MB: write-combining, count=3 > - compiler used kgcc under redhat: gcc driver version 2.95.3 19991030 (prerelease) executing gcc version egcs-2.91.66 > > Alan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- There are a thousand hacking at the branches of evil to the one who is striking at the root. --Henry D. Thoreau - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Athlon runtime problems
Can the folks who are seeing crashes running athlon optimised kernels all mail me - CPU model/stepping - Chipset - Amount of RAM - /proc/mtrr output - compiler used Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I can't read data from COM1
On Mon, Apr 09, 2001 at 04:36:30PM +0800, Green wrote: I ran into a similar problem with 2.4.3 where I couldn't enter anything when running mingetty on the console. Turned out that by default the CREAD flag isn't set on a serial interface in 2.4.3 after bootup so you need to initialize this. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
On Sat, 14 Apr 2001, Linus Torvalds wrote: > On Sat, 14 Apr 2001, Adam J. Richter wrote: > > > > [...] > > >If it turns out to be beneficial to run the child first (you > > >can measure this), why not leave everything the same as it is > > >now but have do_fork() "switch threads" internally ? > > > > That is an elegant idea. > > I doubt it. It sounds like one of those "cool value" ideas that > are actually really stupid except they sound cool because you > have to think about the twists and turns. You're right. Time to put a "don't try to think of cool ideas after going out at night" sign on the wall ;) cheers, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
KERNEL: assertion (tp->lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks
While running 2.4.3, I saw the following message a few times: KERNEL: assertion (tp->lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks Is that bad, or should I just ignore it? Kurt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MO-Drive under 2.4.3
> > This is a bug in the scsi layer. [EMAIL PROTECTED], not that any of
> > the scsi maintainers seem to care about it right now.
>
> Err..., now I'm confused. Last time this issue popped up, it was my
> understanding that it's generic_file_{read,write}'s limitation to filesystems
> with logical_blksize >= hw_blksize that makes MOs fail with VFAT. Now, is
> this all moot, or is the SCSI thing just an additional problem?
generic_file_* doesnt handle metadata issues - its too high up
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bizarre TCP behavior
> For example the Zyxel 681 SDSL-Router breaks ECN by > stripping 0x80 (ECN Cwnd Reduced) but not 0x40 (ECN Echo) > (TOS bits) on all SYN packets (!). > > I complained because of this two times more than a month ago > but they do not even respond. If the router claims to be RFC compliant then you may want to investigate trading standards bodies. In the UK at least things like the advertising standards agency get upset by people who claim standards compliance, are shown not to be compliant and are not fixing things.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MO-Drive under 2.4.3
> > This is a bug in the scsi layer. [EMAIL PROTECTED], not that any > > of the scsi maintainers seem to care about it right now. > > Does this mean I can forget about using kernel 2.4.x? :-(( Can you give me a > hint where to look. Maybe I can fix it myself. The FAT layer asks for a 512 byte block, the scsi layer in 2.2 would then reblock the data to handle this internally. In 2.4 the scsi layer errors this then all the error handling gets tangled up (and doesnt work) and the machine oopses. So you either need to teach lots of file systems about handling blocks that are smaller than the physical layer, or the block layer to do reblocking in some cases (at an obvious performance hit). And someone needs to fix the error handling so it errors rather than exploding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 8139too: defunct threads
>> Ah. Of course. All (or most) kernel initialisation is
>> done by PID 1. Search for "kernel_thread" in init/main.c
>>
>> So it seems that in your setup, process 1 is not reaping
>> children, which is why this hasn't been reported before.
>> Is there something unusual about your setup?
> I found the difference which causes this. If I build my kernel with
> IP_PNP (IP: kernel level autoconfiguration) support I get a defunt
> thread for each 8139too device. If I don't build with IP_PNP
> support I don't get any, defunct ethernet threads.
Does init(8) reap children that died before it was spawned? I assume
that the defunct tasks were there _before_ init was spawned.
Perhaps init() [in linux/init/main.c] should reap all defunct tasks
before the execve("/sbin/init").
I've attached an untested patch, could you try it?
--
Manfred
patch-main.dat
Re: Linux-Kernel Archive: No 100 HZ timer !
Andre Hedrick wrote: > > Okay but what will be used for a base for hardware that has critical > timing issues due to the rules of the hardware? > > I do not care but your drives/floppy/tapes/cdroms/cdrws do: > > /* > * Timeouts for various operations: > */ > #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */ > #ifdef CONFIG_APM > #define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */ > #else > #define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous */ > #endif /* CONFIG_APM */ > #define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if all >ATAPI CD is closed at boot */ > #define WAIT_WORSTCASE (30*HZ) /* 30sec - worst case when spinning up */ > #define WAIT_CMD(10*HZ) /* 10sec - maximum wait for an IRQ to happen */ > #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ May I make a coding-style suggestion (which is ugly on one hand, neat on the other): #define mSec *Hz/1000 /* Convert millisecs to jiffies */ #define Sec*Hz /* Convert secs to jiffies */ #define WAIT_DRQ(50 mSec) /* spec allows up to 20ms */ #ifdef CONFIG_APM #define WAIT_READY ( 5 Sec)/* some laptops are very slow */ #else #define WAIT_READY (30 mSec) /* should be instantaneous */ #endif /* CONFIG_APM */ #define WAIT_PIDENTIFY (10 Sec)/* should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30 Sec)/* worst case when spinning up */ #define WAIT_CMD(10 Sec)/* maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (20 mSec) /* minimum sleep time */ I think that this is more readable than the above original. Also note that the numbers are not really repeated in the comments. If someone changes the numbers, but not the comments, it may confuse someone quite some time before he/she notices that the number that is used is not the same as the one in the comment. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
On Fri, 13 Apr 2001, Linus Torvalds wrote: > On Sat, 14 Apr 2001, Rik van Riel wrote: > > > > Also, have you managed to find a real difference with this? > > It actually makes a noticeable difference on lmbench, so I think adam is > 100% right. > > > If it turns out to be beneficial to run the child first (you > > can measure this), why not leave everything the same as it is > > now but have do_fork() "switch threads" internally ? > > Probably doesn't much matter. We've invalidated the TLB anyway due to > the page table copy, so the cost of switching the MM is not all that > noticeable. And we don't even have to physically switch MM, we could simply fake stuff by updating pointers in the parent MM instead of the child so by the time we exit do_fork() we're in the child... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MO-Drive under 2.4.3
On Fri, Apr 13, 2001 at 02:08:41PM +0100, Alan Cox wrote:
> > I have a problem using my MO-Drive under kernel 2.4.3. I have several disks
> > formated with a VFAT filesystem. Under kernel 2.2.19 everything works fine.
> > Under kernel 2.4.3 I cannot write anything to the disk without hanging the
> > complete system so that I have to use the reset button. For disks with an
> > ext2 filesystem it works okay.
>
> This is a bug in the scsi layer. [EMAIL PROTECTED], not that any of
> the scsi maintainers seem to care about it right now.
Err..., now I'm confused. Last time this issue popped up, it was my
understanding that it's generic_file_{read,write}'s limitation to filesystems
with logical_blksize >= hw_blksize that makes MOs fail with VFAT. Now, is
this all moot, or is the SCSI thing just an additional problem?
Regards,
Daniel.
--
GNU/Linux Audio Mechanics - http://www.glame.de
Cutting Edge Office - http://www.c10a02.de
GPG Key ID 89BF7E2B - http://www.keyserver.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SW-RAID0 Performance problems
Am Samstag, 14. April 2001 14:28 schrieb Kurt Roeckx: > Does turning unmaskirq on help? Already tried this, but it doesn't help The actual settings (same on /dev/hdc): bash-2.04# hdparm /dev/hda /dev/hda: multcount= 16 (on) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 59556/16/63, sectors = 60032448, start = 0 bash-2.04# hdparm -tT /dev/md0 /dev/md0: Timing buffer-cache reads: 128 MB in 1.30 seconds = 98.46 MB/sec Timing buffered disk reads: 64 MB in 3.14 seconds = 20.38 MB/sec bash-2.04# hdparm -tT /dev/hda3 /dev/hda3: Timing buffer-cache reads: 128 MB in 1.31 seconds = 97.71 MB/sec Timing buffered disk reads: 64 MB in 2.26 seconds = 28.32 MB/sec Andreas -- Andreas Peter *** [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loop problems continue in 2.4.3
Just a tip: I had the same problems when I started to use 2.4.x kernels. It was the compiler that caused the problem. I switch to using kgcc (comes with RH 7.0) and all the problems when away. :-) - Original Message - From: "Arthur Pedyczak" <[EMAIL PROTECTED]> To: "Jens Axboe" <[EMAIL PROTECTED]> Cc: "Linux kernel list" <[EMAIL PROTECTED]>; "Jeff Garzik" <[EMAIL PROTECTED]> Sent: Saturday, April 14, 2001 2:46 PM Subject: Re: loop problems continue in 2.4.3 > On Sat, 14 Apr 2001, Jens Axboe wrote: > > [ SNIP..] > > > = > > > Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging request at >virtual address 7e92bfd7 > > > > Please disable syslog decoding (it sucks) and feed it through ksymoops > > instead. > > > > In other words, reproduce and dmesg | ksymoops instead. > > > > > I tried to reproduce the error this morning and couldn't. Same kernel > (2.4.3), same setup, same iso file. It mounted/unmounted 10 times with no > problem. DOn't know what to think. > > Arthur > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
I/O errors after moving to 2.4
Hi all After upgrading two 2-CPU servers (intel) from 2.2 to 2.4, users complain about their shell hangs for several seconds, sometimes minutes, when doing trivial stuff like doing a 'cat' or a 'vi' against a file. When trying to do more heavy I/O, the process in question will all of a sudden go Defunct and stay like that till some wonder lets it out in real life again. Does any of you know what this could be? The servers are of quite different hardware; one is a Dell 4300, the other's a home built something. .config listed below Please CC: to me as I'm not on the list Regards roy --- # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=y # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set
comments on CML 1.1.0
Using CML2 1.1.0 'menuconfig' on clean 2.4.3 (mach is PPro 180) Suggestions: * the 'N' should be shown as ' ' as in menuconfig - it is visually much better to get overview of whole screenful. 'Y'/'M' and 'N' are basically of 'same size' so you must look directly on letter to understand what it is - not good. * the menuconfig had nice shortcut: when you pressed 'm' on [YN] field, it put 'y' there without questions. So you could use only 2 keys to configure one screen: 'n/m'. this meant you did not need to move fingers around and think about it so much - big thing when you are not touch-typer... * the colors are hard to see (red/blue on black). Probably matter of terminal settings. I do not have any productive ideas tho... Probably to get best experience to as much people as possible the less colors are used the better. The 'blue: last visited submenu' is unnecessary. Especially because it later turns green... And the 'red' vs. 'green' thing. I guess the green should be used for 'visited entries' too. Now the red means like 'Doh. So I should not have touched this?'. Confusing. In other words: if there are too much colors, they become a thing that should be separately learned, not a helpful aid. All this IMHO ofcourse. Colors are 'matter of taste' thing so there probably is not exact Rigth Thing. Bugs/complaints: * aic7xxx is not updated (defaults: are 8/5 should be 253/5000) (this from arch/i386/defconfig maybe?) * 'IDE chipset support' nesting is very confusing - compare to menuconfig. I would say even 'wrong'... (eg. 'PIIXn tuning' is is under 'PIIXn support' which is not under 'ATA works in progress'. * screen is redrawn after _every_ keystroke - not only in moving around, but even when you are on input field... * input field: when there is some default and I start typing it should either clear it or append. -- marko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loop problems continue in 2.4.3
On Sat, 14 Apr 2001, Jens Axboe wrote: [ SNIP..] > > = > > Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging request at >virtual address 7e92bfd7 > > Please disable syslog decoding (it sucks) and feed it through ksymoops > instead. > > In other words, reproduce and dmesg | ksymoops instead. > > I tried to reproduce the error this morning and couldn't. Same kernel (2.4.3), same setup, same iso file. It mounted/unmounted 10 times with no problem. DOn't know what to think. Arthur - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RealTek 8139 driver updated, tested requested
A new version of the ethernet driver for RTL-8139-based 10/100 boards has been posted at http://sourceforge.net/projects/gkernel/ This update includes a couple major bugfixes, and I am interested in getting the widest testing possible for it. Please report bugs to the bug tracking system on the web page above. Please include in your bug report 'lspci -vvv', 'dmesg', and any other relevant information you can think of. Thanks, Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SW-RAID0 Performance problems
On Sat, Apr 14, 2001 at 11:38:06AM +0200, Andreas Peter wrote: > Am Samstag, 14. April 2001 09:04 schrieb David Rees: > > > OK, so it's not the RAID setup. There's two things that can cause this. > > One is that DMA is turned off (what does hdparm /dev/hda and hdparm > > /dev/hdc show?), the second was that the drives are on the same channel > > (which obviously isn't the case here). Can you verify that the drives are > > in DMA mode? > > hdparm /dev/hda > > /dev/hda: > multcount= 16 (on) > I/O support = 0 (default 16-bit) > unmaskirq= 0 (off) > using_dma= 1 (on) Does turning unmaskirq on help? Kurt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOPS in khttpd, 2.4.4-ac3
Hello. I was performing some benchmarks of http transfer with program 'ab' (apache benchmark), comparing, how it will perform with/without kernel khttpd support. I've got oops several times, the error is replicable on my machine, without appache even started. The exact order of actions i did: modprobe khttpd I let the default configuration for first try ( threads=2, maxconnect=1000, clientport=80, serverport=8080...) echo 1 > /proc/sys/net/khttpd/start ab -n 1000 http://localhost:8080/icons/logo.gif (included as attachement) and everithing goes well for now, really pretty boost. echo 1 > /proc/sys/net/khttpd/stop got message: Daemon 1 has ended, Daemon 0 has ended After this step, i see from ps aux: [khttpd - 0 ] Now, stopped the httpd accelerator and increased number of threads to four: echo 1 > /proc/sys/net/khttpd/stop echo 4 > /proc/sys/net/khttpd/threads Restarted khttpd: echo 1 > /proc/sys/net/khttpd/start (i see some defunct-ed threads too now) Then i reruned the 'ab' benchmark like above: ab -n 1000 http://localhost:8080/icons/logo.gif and the oops become. If i optionally make yet another try of 'ab' benchmark after this oops, i get another oops of type "Aieee in interrupt...killing interrupt"... - Here are infos: ksymoops 2.3.7 on i586 2.4.3-ac3. Options used -v /usr/src/linux/vmlinux (specified) -k ./ksyms (specified) -l ./modules (specified) -o /lib/modules/2.4.3-ac3/ (specified) -m /usr/src/linux/System.map (specified) Apr 14 14:44:04 Boris kernel: Oops: Apr 14 14:44:04 Boris kernel: CPU:0 Apr 14 14:44:04 Boris kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Apr 14 14:44:04 Boris kernel: EFLAGS: 00010202 Apr 14 14:44:04 Boris kernel: eax: ebx: c141702c ecx: 0004 edx: 0004 Apr 14 14:44:04 Boris kernel: esi: edi: c2897a01 ebp: esp: c1415f14 Apr 14 14:44:04 Boris kernel: ds: 0018 es: 0018 ss: 0018 Apr 14 14:44:04 Boris kernel: Process khttpd - 0 (pid: 1016, stackpage=c1415000) Apr 14 14:44:04 Boris kernel: Stack: c000 c1417000 c289638a c2897a01 c141702c c000 c1417000 Apr 14 14:44:04 Boris kernel: c2897538 Apr 14 14:44:04 Boris kernel: c1417000 c02c936c c1417000 c2899e80 0fff Apr 14 14:44:04 Boris kernel: Call Trace: [] [] [] [] [] [] [] Apr 14 14:44:04 Boris kernel:[] [] [] [] Apr 14 14:44:04 Boris kernel: Code: f3 a6 74 0a 96 46 80 78 ff 00 75 ec 31 c0 5e 5f c3 90 90 90 >>EIP; c01bd9a8<= Trace; c289638a <[khttpd]ParseHeader+26/2dc> Trace; c2897a01 <[khttpd].rodata.start+361/6ed> Trace; c2897538 <[khttpd]DecodeHeader+b4/198> Trace; c2899e80 <[khttpd]Buffer+180/37f> Trace; c28973e6 <[khttpd]WaitForHeaders+76/b8> Trace; c28951f1 <[khttpd]MainDaemon+155/218> Trace; c2898e40 <[khttpd]CountBuf+0/40> Trace; c2898e00 <[khttpd]Running+0/40> Trace; c010542c Trace; c2898e40 <[khttpd]CountBuf+0/40> Trace; c2898e40 <[khttpd]CountBuf+0/40> Code; c01bd9a8 <_EIP>: Code; c01bd9a8<= 0: f3 a6 repz cmpsb %es:(%edi),%ds:(%esi) <= Code; c01bd9aa 2: 74 0a je e <_EIP+0xe> c01bd9b6 Code; c01bd9ac 4: 96xchg %eax,%esi Code; c01bd9ad 5: 46inc%esi Code; c01bd9ae 6: 80 78 ff 00 cmpb $0x0,0x(%eax) Code; c01bd9b2 a: 75 ec jnefff8 <_EIP+0xfff8> c01bd9a0 Code; c01bd9b4 c: 31 c0 xor%eax,%eax Code; c01bd9b6 e: 5epop%esi Code; c01bd9b7 f: 5fpop%edi Code; c01bd9b8 10: c3ret Code; c01bd9b9 11: 90nop Code; c01bd9ba 12: 90nop Code; c01bd9bb 13: 90nop - cat /proc/modules: khttpd 21072 5 autofs4 8128 6 (autoclean) 3c509 6896 1 (autoclean) awe_wave 155936 0 sb 7008 0 sb_lib 32368 0 [sb] uart401 6000 0 [sb_lib] sound 52704 0 [awe_wave sb_lib uart401] nls_iso8859-1 2848 2 (autoclean) nls_cp437 4352 2 (autoclean) vfat8400 2 (autoclean) fat29120 0 (autoclean) [vfat] floppy 45872 0 (autoclean) ide-cd 25904 0 (autoclean) cdrom 27008 0 (autoclean) [ide-cd] --- ver_linux script: Linux Boris 2.4.3-ac3 #1 Fri Apr 13 20:48:04 CEST 2001 i586 unknown Gnu C
Re: bizarre TCP behavior
On Wed, Apr 11, 2001 at 02:21:42AM +0200, Andi Kleen wrote: > Try echo 0 > /proc/sys/net/ipv4/tcp_ecn > If it helps complain to the sites that their firewall is broken. Not always firewall related. There are companies like Zyxel that ship broken router too. For example the Zyxel 681 SDSL-Router breaks ECN by stripping 0x80 (ECN Cwnd Reduced) but not 0x40 (ECN Echo) (TOS bits) on all SYN packets (!). I complained because of this two times more than a month ago but they do not even respond. I do not know if they are unable or just unwilling to fix it; maybe they just unable to read RFC's. -- ciao - Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
generic_osync_inode/ext2_fsync_inode still not safe
Hi, As described earlier, code which wants to write an inode cannot rely on the I_DIRTY bits (on inode->i_state) being clean to guarantee that the inode and its dirty pages, if any, are safely synced on disk. The reason for that is sync_one() --- it cleans the I_DIRTY bits of an inode, sets the I_LOCK and starts a writeout. If sync_one() is called to write an inode _asynchronously_, there is no guarantee that an inode will have its data fully synced on disk even if the inode gets unlocked, which means the previous fix to generic_osync_inode() is not safe. The easy and safe fix is to simply remove the I_DIRTY_* checks from generic_osync_inode and ext2_fsync_inode. Easy but slow. Another fix would be to make sync_one() unconditionally synchronous... slow. Any suggestion for a fast, safe, but simple fix to this bug? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: why can't include /sys/types and /linux/fs.h in the same file
>#include
>#include
>int main ()
>{
>; // contains no C programs,
>}
>and give the command " cc -D__KERNEL__ -I/usr/src/linux/include to compiler
>the program .
You can't mix environments. Either you're building part of the kernel, in which
case you need to use -D__KERNEL__ and headers, or you're building an
application, in which case you need to use the headers from libc.
p.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
why can't include /sys/types and /linux/fs.h in the same file
Dear All:
I wrote a very small program as following :
#include
#include
int main ()
{
; // contains no C programs,
}
and give the command " cc -D__KERNEL__ -I/usr/src/linux/include to compiler
the program .
A lot of parser error messages show on the screen .
Does anybody know why ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH- new driver] Maxi Radio FM 2 driver (GemTek) (3)
I can't send any attachment to the list, what's wrong?
I got this mail :
//
Norton AntiVirus quarantined an attachment in a message you sent.
De : NAV for Microsoft Exchange-EXCHANGE <[EMAIL PROTECTED]>
À : 'Fabien CHEVALIER' <[EMAIL PROTECTED]>
Date : Sat, 14 Apr 2001 11:35:10 +0100
Recipient of the attachment: Jonathan Spillett\Personal\Linux Kernel
Subject of the message: [PATCH- new driver] Maxi Radio FM 2 driver (GemTek)
(2)
One or more attachments were quarantined.
Attachment patch-maxifm2-v0.12-2.4.3.gz was Quarantined for the following
reasons:
Scan Engine Failure (0x80004005)
General Scan Engine error
/**/
Sorry, for now i will send the patch uncompressed...
diff -Nru linux/drivers/media/radio/Config.in
linuxm/drivers/media/radio/Config.in
--- linux/drivers/media/radio/Config.in Fri Apr 13 12:46:46 2001
+++ linuxm/drivers/media/radio/Config.inFri Apr 13 12:24:24 2001
@@ -21,6 +21,10 @@
if [ "$CONFIG_RADIO_GEMTEK" = "y" ]; then
hex 'GemTek i/o port (0x20c, 0x30c, 0x24c or 0x34c)'
CONFIG_RADIO_GEMTEK_PORT 34c
fi
+dep_tristate ' Guillemot MAXI Radio FM 2 card support' CONFIG_RADIO_MAXIFM2
$CONFIG_VIDEO_DEV
+if [ "$CONFIG_RADIO_MAXIFM2" = "y" ]; then
+ hex 'Maxi FM 2 i/o port (0x20c, 0x30c, 0x24c or 0x34c)'
CONFIG_RADIO_MAXIFM2_PORT 34c
+fi
dep_tristate ' Guillemot MAXI Radio FM 2000 radio' CONFIG_RADIO_MAXIRADIO
$CONFIG_VIDEO_DEV
dep_tristate ' Maestro on board radio' CONFIG_RADIO_MAESTRO
$CONFIG_VIDEO_DEV
dep_tristate ' Miro PCM20 Radio' CONFIG_RADIO_MIROPCM20 $CONFIG_VIDEO_DEV
diff -Nru linux/drivers/media/radio/Makefile
linuxm/drivers/media/radio/Makefile
--- linux/drivers/media/radio/Makefile Fri Apr 13 12:46:46 2001
+++ linuxm/drivers/media/radio/Makefile Fri Apr 13 12:24:24 2001
@@ -31,6 +31,7 @@
obj-$(CONFIG_RADIO_CADET) += radio-cadet.o
obj-$(CONFIG_RADIO_TYPHOON) += radio-typhoon.o
obj-$(CONFIG_RADIO_TERRATEC) += radio-terratec.o
+obj-$(CONFIG_RADIO_MAXIFM2) += radio-maxifm2.o
obj-$(CONFIG_RADIO_MAXIRADIO) += radio-maxiradio.o
obj-$(CONFIG_RADIO_RTRACK) += radio-aimslab.o
obj-$(CONFIG_RADIO_ZOLTRIX) += radio-zoltrix.o
diff -Nru linux/drivers/media/radio/radio-maxifm2.c
linuxm/drivers/media/radio/radio-maxifm2.c
--- linux/drivers/media/radio/radio-maxifm2.c Thu Jan 1 00:00:00 1970
+++ linuxm/drivers/media/radio/radio-maxifm2.c Fri Apr 13 12:48:46 2001
@@ -0,0 +1,347 @@
+/*
+ * Guillemot Maxi Radio FM 2 ISA radio card driver for Linux
+ * (C) 2001 Fabien Chevalier <[EMAIL PROTECTED]>
+ *
+ * contains code from Maxi Radio FM 2000 and GemTek drivers
+ *
+ * I reversed engineered the protocol from the win16 driver radio.exe
+ * with wine
+ * This driver contains as many features as the windows one : it
+ * even has card detection
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_VERSION "0.12"
+
+#ifndef CONFIG_RADIO_MAXIFM2_PORT
+#define CONFIG_RADIO_MAXIFM2_PORT -1
+#endif
+
+static int io = CONFIG_RADIO_MAXIFM2_PORT;
+
+#define PORTWIDTH 4
+
+/* Maybe this is too small, but i had to choose one
+(works perfectly on my computer)*/
+#define IODELAY 10
+
+#define FREQ_LO 87*16000
+#define FREQ_HI108*16000
+
+static __u8 powerbit = 16;
+static __u8 stereobit = 8;
+
+static int radio_open(struct video_device *, int);
+static int radio_ioctl(struct video_device *, unsigned int, void *);
+static void radio_close(struct video_device *);
+
+static struct video_device maxifm2_radio=
+{
+ owner: THIS_MODULE,
+ name: "Maxi Radio FM2 radio",
+ type: VID_TYPE_TUNER,
+ hardware: VID_HARDWARE_GEMTEK,
+ open: radio_open,
+ close: radio_close,
+ ioctl: radio_ioctl,
+};
+
+static struct radio_device
+{
+ __u16 muted, /* VIDEO_AUDIO_MUTE */
+ tuned; /* signal strength (0 or 0x) */
+
+ unsigned long freq;
+
+ struct semaphore lock;
+} card = {0, 0, 0, };
+
+
+/* to change the frequency, the card wants a 32 bit number : bits = a*f + b
+ * where f is the frequency in Mhz, where "a" is 78.12 and b is 1,107,297,092
+ *
+ * the final formula is :
+ * bits = ( 7812 * ( [video for linux value] / 16000 ) ) / 100 + 1107297092
+ * I had to arrange it because there are no floating points -- Anybody has
+ * a better idea?
+ */
+
+inline __u32 freq_2_bits(unsigned long v4lfreq)
+{
+ __u32 fm2freq;
+ v4lfreq /= 16;
+ v4lfreq *= 7812;
+ v4lfreq /= 10;
+ fm2freq = v4lfreq + 1107297092;
+ return fm2freq;
+}
+
+int __init card_detect()
+{
+ __u8 read, count;
+ int anything = 0;
+
+ for(count=0; count <= 3; count++) {
+ read = inb(io);
+ if (read != 0xff)
+ anything = 1; //There is something on this io port
+ outb_p( (read & 0xfc) | count, io);
+
Re: SW-RAID0 Performance problems
Am Freitag, 13. April 2001 20:11 schrieb Tim Moore: > Try 'hdparm -tT' with simultaneous /dev/hda3 and /dev/hdc3. This gives > you a baseline on the actual partitions involved. hdparm -tT simultanous on /dev/hda3 and /dev/hdc3: /dev/hda3: Timing buffer-cache reads: 128 MB in 2.29 seconds = 55.90 MB/sec Timing buffered disk reads: 64 MB in 4.67 seconds = 13.70 MB/sec /dev/hdc3: Timing buffer-cache reads: 128 MB in 2.28 seconds = 56.14 MB/sec Timing buffered disk reads: 64 MB in 4.61 seconds = 13.88 MB/sec Now on single HD - /dev/hda3 : /dev/hda3: Timing buffer-cache reads: 128 MB in 1.30 seconds = 98.46 MB/sec Timing buffered disk reads: 64 MB in 2.26 seconds = 28.32 MB/sec It looks like reading on /dev/hda3 locks /dev/hdc3 ... Is it necessary to apply the ide-patches to the kernel ? Andreas -- Andreas Peter *** [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH- new driver] Maxi Radio FM 2 driver (GemTek) (2)
>Hi, >I've wrote this driver for my Maxi Radio Fm 2 card. > i hope it can be usefull for somebody. >This card uses a GemTek chip, but the GemTek driver wasn't working very well >: >the card was left uninitialized, and so it didn't mute. >I didn't wrote a patch for the GemTek driver because the protocol to change >frequency is different. >This patch is for 2.4.3 kernel - nobody but me tested it yet... >Please CC your answers as my 56 k modem can't bear the list! Ooops, something went wrong with the attached patch, I hope this time there won't be any problem... X×:
module load/unload race protection?
Does the kernel's module loader (kernel/module.c, not kmod) protect adequately against concurrent load/load or load/unload requests? The question applies to both 2.2 and 2.4 kernels. I'm trying to track down a problem where a user using a RedHat 2.2.17-14 SMP kernel managed to trigger a situation where a driver module had been unloaded while still being in use (as in "the kernel has pointers into it", not USE_COUNT != 0). I'm reviewing the driver's internal INC/DEC_USE_COUNT usage, but so far I've not found any obvious errors. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MO-Drive under 2.4.3
Hi Alan, thanks for the reply. Am Freitag, 13. April 2001 15:08 schrieb Alan Cox: > > I have a problem using my MO-Drive under kernel 2.4.3. I have several > > disks formated with a VFAT filesystem. Under kernel 2.2.19 everything > > works fine. Under kernel 2.4.3 I cannot write anything to the disk > > without hanging the complete system so that I have to use the reset > > button. For disks with an ext2 filesystem it works okay. > > This is a bug in the scsi layer. [EMAIL PROTECTED], not that any > of the scsi maintainers seem to care about it right now. Does this mean I can forget about using kernel 2.4.x? :-(( Can you give me a hint where to look. Maybe I can fix it myself. Regards Detlev -- Detlev Offenbach [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SW-RAID0 Performance problems
Am Samstag, 14. April 2001 09:04 schrieb David Rees: > OK, so it's not the RAID setup. There's two things that can cause this. > One is that DMA is turned off (what does hdparm /dev/hda and hdparm > /dev/hdc show?), the second was that the drives are on the same channel > (which obviously isn't the case here). Can you verify that the drives are > in DMA mode? hdparm /dev/hda /dev/hda: multcount= 16 (on) I/O support = 0 (default 16-bit) unmaskirq= 0 (off) using_dma= 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 59556/16/63, sectors = 60032448, start = 0 the same on /dev/hdc I played with different hdparm-settings, but it's not possible to speed up the HDs Andreas -- Andreas Peter *** [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
On Sat, 14 Apr 2001, Adam J. Richter wrote: > > [...] > >If it turns out to be beneficial to run the child first (you > >can measure this), why not leave everything the same as it is > >now but have do_fork() "switch threads" internally ? > > That is an elegant idea. I doubt it. It sounds like one of those "cool value" ideas that are actually really stupid except they sound cool because you have to think about the twists and turns. So yes, you could "give" your TLB state to the child, and take the childs state yourself (eventually, when you re-schedule back to the parent). They're supposed to be the same, after all. And by doing so, you could do a "switch_to()" to the child, without actually switching mm state at all. Fine. Cool TLB optimization. Except you don't actually _have_ any TLB state to optimize away, as you just invalidated it anyway when you did the COW thing on the page tables. So you would only optimize away a "mov xxx,%cr3" - which is the least expensive part of switching TLB's. You would NOT optimize away any actual TLB reloads. And oh, btw, it also means that you'd better make sure that /proc knows about the fact that the MM state is no longer yours, but your childs, so that a concurrent "ps" doesn't mess us. Maybe it works as-is, and maybe it doesn't. And what if the guy who did the fork() had done a clone(CLONE_MM) before, or was the child of a vfork'ing parent? We can't give the mm state to the child, because we're sharing it with somebody else who expects to share it with the _parent_. Oh, and the co-thread, btw, might be _using_ those page tables on another CPU at any time. And oh, there's the small special case of "init", which uses a fork() to create the first user-mode mm state, so we'd have to special-case that one too - we can't let "init_mm" go to a user process. So at the very least it would have to be conditional on both that and the thread case. There's a ton of reasons why you _really_ don't want to play games here. Switching contexts is tricky enough as it is. Let's not try to be "clever" about it. So the best you could do is to do a full context switch to the child. Which setting "current->need_resched = 1" will already end up doing. Plus it does the right thing on SMP. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
can't compile -ac6
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac6/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c sys.c sys.c: In function `sys_gethostname': /usr/src/linux-2.4.3-ac6/include/asm/rwsem-xadd.h:153: inconsistent operand constraints in an `asm' make[2]: *** [sys.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.3-ac6/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.3-ac6/kernel' make: *** [_dir_kernel] Error 2 I'm using gcc 3.0 (20010402) and had no problems with 2.4.3-ac4. Norbert PGP signature
[PATCH] prune_icache() changes
Hi,
The following patch should fix the OOM deadlock condition caused by
prune_icache(), and improve its performance significantly.
The OOM deadlock can happen because prune_icache() tries to sync _all_
dirty inodes (under PF_MEMALLOC) on the system before trying to free a
portion of the clean unused inodes.
The patch also changes prune_icache() to free clean inodes first, and then
sync _unused_ ones if needed. In case (nr_free_pages < freepages.low) the
code writes one inode synchronously and returns (to avoid the OOM
deadlock).
Patch against 2.4.4-pre1.
Comments are welcome.
--- fs/inode.c~ Thu Apr 12 21:16:35 2001
+++ fs/inode.c Thu Apr 12 21:49:56 2001
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
/*
* New inode.c implementation.
@@ -197,6 +199,34 @@
inodes_stat.nr_unused--;
}
+static inline void __sync_one(struct inode *inode, int sync)
+{
+ unsigned dirty;
+
+ list_del(>i_list);
+ list_add(>i_list, atomic_read(>i_count)
+ ? _in_use
+ : _unused);
+
+ /* Set I_LOCK, reset I_DIRTY */
+ dirty = inode->i_state & I_DIRTY;
+ inode->i_state |= I_LOCK;
+ inode->i_state &= ~I_DIRTY;
+ spin_unlock(_lock);
+
+ filemap_fdatasync(inode->i_mapping);
+
+ /* Don't write the inode if only I_DIRTY_PAGES was set */
+ if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC))
+ write_inode(inode, sync);
+
+ filemap_fdatawait(inode->i_mapping);
+
+ spin_lock(_lock);
+ inode->i_state &= ~I_LOCK;
+ wake_up(>i_wait);
+}
+
static inline void sync_one(struct inode *inode, int sync)
{
if (inode->i_state & I_LOCK) {
@@ -206,29 +236,7 @@
iput(inode);
spin_lock(_lock);
} else {
- unsigned dirty;
-
- list_del(>i_list);
- list_add(>i_list, atomic_read(>i_count)
- ? _in_use
- : _unused);
- /* Set I_LOCK, reset I_DIRTY */
- dirty = inode->i_state & I_DIRTY;
- inode->i_state |= I_LOCK;
- inode->i_state &= ~I_DIRTY;
- spin_unlock(_lock);
-
- filemap_fdatasync(inode->i_mapping);
-
- /* Don't write the inode if only I_DIRTY_PAGES was set */
- if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC))
- write_inode(inode, sync);
-
- filemap_fdatawait(inode->i_mapping);
-
- spin_lock(_lock);
- inode->i_state &= ~I_LOCK;
- wake_up(>i_wait);
+ __sync_one(inode, sync);
}
}
@@ -236,10 +244,42 @@
{
struct list_head * tmp;
- while ((tmp = head->prev) != head)
+ while ((tmp = head->prev) != head)
sync_one(list_entry(tmp, struct inode, i_list), 0);
}
+static inline int try_to_sync_unused_list(struct list_head *head)
+{
+ struct list_head *tmp = head;
+ struct inode *inode;
+
+ while ((tmp = tmp->prev) != head) {
+ inode = list_entry(tmp, struct inode, i_list);
+
+ if (!(inode->i_state & I_LOCK)
+ && !atomic_read(>i_count)) {
+ /*
+* We're under PF_MEMALLOC here, and syncing the
+* inode may have to allocate memory. To avoid
+* running into a OOM deadlock, we write one
+* inode synchronously and stop syncing in case
+* we're under freepages.low
+*/
+
+ int sync = nr_free_pages() < freepages.low;
+ __sync_one(inode, sync);
+ if (sync)
+ return 0;
+ /*
+* __sync_one moved the inode to another list,
+* so we have to start looking from the list head.
+*/
+ tmp = head;
+ }
+ }
+ return 1;
+}
+
/**
* sync_inodes
* @dev: device to sync the inodes from.
@@ -273,13 +313,14 @@
/*
* Called with the spinlock already held..
*/
-static void sync_all_inodes(void)
+static void try_to_sync_unused_inodes(void)
{
struct super_block * sb = sb_entry(super_blocks.next);
for (; sb != sb_entry(_blocks); sb = sb_entry(sb->s_list.next)) {
if (!sb->s_dev)
continue;
- sync_list(>s_dirty);
+ if (!try_to_sync_unused_list(>s_dirty))
+ break;
}
}
@@ -506,13 +547,12 @@
{
LIST_HEAD(list);
struct list_head *entry, *freeable =
- int count = 0;
+ int count = 0, synced = 0;
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"Adam J. Richter" <[EMAIL PROTECTED]> writes: > Rik van Riel <[EMAIL PROTECTED]> writes, regarding the idea > of having do_fork() give all of the parent's remaining time slice to > the newly created child: > > >It could upset programs which use threads to handle > >relatively IO poor things (like, waiting on disk IO in a > >thread, like glibc does to fake async file IO). > > Good point. Is it really? If a program is using thread to handle IO things, then: a) It's not going to create a thread for every IO! So I think the argument is suprious anyway. b) You _still_ want the child to run first. The child will start the I/O and block, then switching back to the parent. This maximises the I/O thruput without costing you any CPU. (Reasoning: The child running 2nd will increase the latency which automatically reduces the number of ops/second you can get). Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] tmpfs and loop
In article <01041321112600.23961@oscar> you wrote:
> oscar% sudo mount /tmp/disk /snap -oloop -text2
> ioctl: LOOP_SET_FD: Invalid argument
are you sure you have a working loop device? Try to verify it in a non tmpfs
filesystem.
> stat64("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
> open("/dev/loop0", O_RDONLY|O_LARGEFILE) = 3
> ioctl(3, 0x4c03, 0xb7fc)= -1 ENXIO (No such device or address)
otherwise try this by hand with losetup.
> close(3)= 0
> open("/tmp/disk", O_RDWR|O_LARGEFILE) = 3
> open("/dev/loop0", O_RDWR|O_LARGEFILE) = 4
> mlockall(MCL_CURRENT|MCL_FUTURE)= 0
> ioctl(4, 0x4c00, 0x3) = -1 EINVAL (Invalid argument)
> write(2, "ioctl: LOOP_SET_FD: Invalid argu"..., 37ioctl: LOOP_SET_FD: Invalid
>argument
Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI tape corruption problem
Now try this: cd ~archive mt -f /dev/tapes/tape0 rewind tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k and then: mt -f /dev/tapes/tape0 rewind dd if=/dev/tapes/tape0 bs=32k | gzip -d | tar --compare -v -f - The above is the proper way to talk to a tape drive through gzip. PS: if you pre-compress, it can be wise to suppress hardware compression (mt -f /dev/nst0 datcompression 0) and maybe use a big buffer with the buffer command. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape Corruption - update 2
On Fri, 13 Apr 2001, Nate Eldredge wrote:
> [EMAIL PROTECTED] wrote:
> > Well, the 2.2 distributed with Mandrake 7.2 works fine ... :)
> >
> > Hmmm... 32 CONSECUTIVE bytes are a very peculiar error. What can it be?
> >
> > Still experimenting...
>
> I once ran into a problem with 32-byte errors appearing in files, and
> later, in memory. I eventually traced it to buggy motherboard cache.
> (32 bytes is the size of a cache line.) A memory tester might be
> something to try (I wrote a simple program that seemed to show the
> error better than memtest86; can send it if desired.)
In that case I'd expect the problem to show up when doing whatever. So far I
could not find corrupted files on my hard disk, only when writing to tape, and
only with 2.3/2.4.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
