Re: Linux 2.4.3-ac12

[Geert Uytterhoeven]

On 22 Apr 2001, Jes Sorensen wrote:
> > "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
> Alan> The recommended compilers for non x86 are different too - eg you
> Alan> need 2.96 gcc for IA64, you need 2.95 not egcs for mips and so
> Alan> on.
> 
> In principle you just need 2.7.2.3 for m68k, but someone decided to
> raise the bar for all architectures by putting a check in a common
> header file.

Late 2.3.x proved to be very unstable for user applications (daily cron always
segfaulted somewhere), until I upgraded from 2.7.2.3 to 2.95.2 from Debian.

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/

Re: ALI 1541,K6,AGP 2.4.3-ac12 instability

[Norbert Preining]

Hi Mark!

This is a well known problem. nvidia-0.9-769 does NOT WORK WITH
2.4.X agpgart, either use nvagp (not possible for ali chipsets)
or disable agp (Option "NvAgp" "0") for the time being.

Next version will hopefully fix this!

See #nvidia on openprojects.net

Best wishes

Norbert

-- 
ciao
norb

+---+
| Norbert Preining  http://www.logic.at/people/preining |
| University of Technology Vienna, Austria[EMAIL PROTECTED] |
| DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key |
+---+
-
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: Kernel hang on multi-threaded X process crash

[Manuel McLure]

On 2001.04.22 20:23 Manuel McLure wrote:
> 
> On 2001.04.22 20:17 Manuel McLure wrote:
> > 
> > On 2001.04.22 19:27 Manuel McLure wrote:
> > > 
> > > On 2001.04.22 18:55 Manuel McLure wrote:
> > > 
> > > > The machine is an Athlon Thunderbird 900MHz with 256M of PC133 DRAM
> > on
> > > an
> > > > MSI K7T Turbo R motherboard. I am running 2.4.3-ac12 currently,
> > > > 2.4.3-ac11
> > > > and 2.4.3-ac5 hung the same way at least once each before I started
> > > > tracking this down. I am running Red Hat 7.1, and am using the
> > > > XFree86-4.0.3 RPMs that come with RH71 with the CVS DRI trunk
> > installed
> > > > over it. The kernel was built with kgcc, a gcc-2.96 built kernel
> has
> > > the
> > > > same problem.
> > > 
> > > Following up on myself, I replaced the contents of /usr/X11R6 server
> > with
> > > the standard 4.0.3 RPMs that come with RH 7.1 and it made no
> > difference.
> > > Also, if it's important my video card is a Voodoo 5 5500.
> > 
> > To follow up on my followup, I can now reproduce this 100% and get the
> > "Trying to vfree()..." message on the console. To do this I start
> > Mozilla,
> > switch to a text console, and do a "killall -QUIT mozilla". A couple of
> ^^^
> 
> Make that "killall -QUIT mozilla-bin"...
> 
> 
> > "Trying to vfree()..." messages later, it's big red switch time.
> > 
> > I'm going to try this with standard 2.4.3 as well as the 2.4.2 that
> comes
> > with RH71 - hopefully my filesystem will handle all the fscks :-(

At Andrew Morton's suggestion, I added a BUG() to mm/vmalloc.c:vfree() and
copied down the stack trace. According to gdb on vmlinux, the symbols are:

vfree
release_segments+50
exit_mmap+17
elf_core_dump
elf_core_dump
mmput+38
do_exit+157
do_invalid_op
die+79
do_invalid_op+127
vfree+110
__call_console_drivers+59
_call_console_drivers+87
call_console_drivers+228
release_console_sem+21
error_code+52
elf_core_dump
vfree+110
release_segments+50
exit_mmap+17
elf_core_dump
elf_core_dump
mmput+38
do_coredump+556
collect_signal+168
elf_core_dump
do_signal+418
do_general_protection
force_sig_info+121
do_general_protection
force_sig+17
do_general_protection+53
error_code+52
signal_return+20

(at least one more BUG() output scrolled off the console).

I also tested this on the 2.4.2-2 kernel that comes with RH 7.1 and I did
not see the problem. Also, if with 2.4.3-ac12 I used Alt-Sysrq-s and
Alt-Sysrq-u to sync and mount my filesystems read-only before doing the
killall, the problem did not occur either. Could the core dumping code be
causing the problem?

I'll now try with the base 2.4.3 to see what happens.

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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/

how does linux support domino?

[Xiong Zhao]

hello.on linux we will see a new domino server process/thread is created for each
client.how does linux do this?does it use pthread?using fork or clone or someway 
else?what's the common way of linux to support apps like lotus domino that will
have lots of concurrent users which are served by seperate server process/thread?
regards

james

-
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 "su -" and kernels 2.4.3-ac11 and higher

[Wayne Whitney]

On Mon, 23 Apr 2001, Albert D. Cahalan wrote:

> Try this:
>
> ps -t pts/2 -o pid,ppid,pgid,sess,f,stat,ruid,euid,fname,nwchan,wchan
> ps -t pts/2 s

OK, below are the results.  Since I'm sleepy I haven't looked up the ps
man page to see what it all means or whether I need to translate any
numbers into symbols, sorry.  Let me know if you'd like anything else.

Cheers, Wayne


[whitney@pizza whitney]$ ps auxwOT
USER   PID %CPU %MEM   VSZ  RSS TTY  STAT START   TIME COMMAND
[ . . . ]
root  1792  0.1  0.2  2300 1068 pts/0S22:19   0:00 /bin/su -
root  1796  0.2  0.2  2356 1384 pts/0S22:19   0:00 -bash
root  1825  0.0  0.1  2112  952 pts/0S22:19   0:00 /bin/su -
root  1826  0.2  0.2  2188 1148 pts/0S22:19   0:00 -bash
root  1854  0.0  0.0  1352  412 pts/0T22:19   0:00 stty erase ?
whitney   1855  0.0  0.1  2664  792 pts/2R22:19   0:00 ps auxwOT
[whitney@pizza whitney]$ ps -t pts/0 -o 
pid,ppid,pgid,sess,f,stat,ruid,euid,fname,nwchan,wchan
  PID  PPID  PGID  SESS   F STAT  RUID  EUID COMMAND   WCHAN WCHAN
 1722  1711  1722  1722 000 S  500   500 bash 117801 wait4
 1792  1722  1792  1722 000 S  500 0 su   117801 wait4
 1796  1792  1796  1722 100 S0 0 bash 117801 wait4
 1825  1796  1825  1722 000 S0 0 su   117801 wait4
 1826  1825  1826  1722 100 S0 0 bash 117801 wait4
 1854  1826  1826  1722 000 T0 0 stty 106a5f do_signal
[whitney@pizza whitney]$ ps -t pts/0 s
  UID   PID   PENDING   BLOCKED   IGNOREDCAUGHT STAT TTYTIME COMMAND
  500  1722    0001 <00384004  4b813efb Spts/0  0:00 bash
0  1792   http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with "su -" and kernels 2.4.3-ac11 and higher

[Albert D. Cahalan]

Wayne writes:
> In mailing-lists.linux-kernel, Manuel A. McLure wrote:

>> Did you try nesting more than one "su -"? The first one after a boot
>> works for me - every other one fails.
>
> Same here: the first "su -" works OK, but a second nested one hangs:
>
>  8825 pts/2S  0:00 /bin/su -
>  8826 pts/2S  0:00 -bash
>  8854 pts/2T  0:00 stty erase ?
>  8855 pts/0R  0:00 ps ax

Try this:

ps -t pts/2 -o pid,ppid,pgid,sess,f,stat,ruid,euid,fname,nwchan,wchan
ps -t pts/2 s

(replace "pts/2" as needed to select the right tty, and split that
first one into two commands if it is too long)
-
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/

ALI 1541,K6,AGP 2.4.3-ac12 instability

[Mark Swanson]

Hello,

When I enable AGP on my ALI system 2D seems to work fine but 3D causes
kernel oops messages. (Ran through ksymoops) It looks like it could be
an NVidia driver problem, but I doubt it as I run this with AGP at work with
no problems. I'm wondering if anyone else has AGP working with the
(new?) ALI AGP code.

Linux 2.4.3-ac12
NVidia 0.9-769 drivers
XFree86-4.0.3
Ali 1541
TNT2 rev 11 SGRAM 32MB
(Recompiled the NVidia drivers to only use 1x AGP, and no ssb, and that
didn't help. Also compiled in NVidia AGP code but this code didn't seem
to understand what an ALI 1541 was and disabled AGP.)

Will test patches to help make this work if it is an ALI/Linux problem.

Thanks.

* 1st ***
Apr 23 04:20:13 test kernel: Unable to handle kernel NULL pointer dereference 
at virtual address 
Apr 23 04:20:13 test kernel: d898ef58
Apr 23 04:20:13 test kernel: Oops: 
Apr 23 04:20:13 test kernel: CPU:0
Apr 23 04:20:13 test kernel: EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
Apr 23 04:20:13 test kernel: EFLAGS: 00010056
Apr 23 04:20:13 test kernel: eax:    ebx:    ecx:    
edx: cc5a8824
Apr 23 04:20:13 test kernel: esi: 0101   edi:    ebp: cc5bdbe8   
esp: cc5bdbd4
Apr 23 04:20:13 test kernel: ds: 0018   es: 0018   ss: 0018
Apr 23 04:20:13 test kernel: Process kmorph3d.kss (pid: 1706, 
stackpage=cc5bd000)
Apr 23 04:20:13 test kernel: Stack:  0101 dda21004 4000 
 cc5bdc10 d898f2fb dda21004
Apr 23 04:20:13 test kernel:0101 cc5bdc08  d8a08ac0 
cc5a87e0 c26a cc5a8824 cc5bdc3c
Apr 23 04:20:13 test kernel:d89873b0 dda21004 cc5bde70 0101 
0041 cc5bdcac 0002 2100
Apr 23 04:20:13 test kernel: Call Trace: [] [] 
[] [] []
Apr 23 04:20:13 test kernel:[] [] [] 
[] [] []
Apr 23 04:20:13 test kernel:[] [] [] 
[] [] [update_process_times+35/144]
Apr 23 04:20:13 test kernel:[] [] [] 
[] [] []
Apr 23 04:20:13 test kernel:[] [] [] 
[] [] []
Apr 23 04:20:13 test kernel:[] [] [] 
[] [] []
Apr 23 04:20:13 test kernel:[] [insert_vm_struct+25/64] 
[do_mmap_pgoff+922/1104] [] [] []
Apr 23 04:20:13 test kernel:[] [] [] 
[] [] []
Apr 23 04:20:13 test kernel:[] [] [] 
[]
Apr 23 04:20:13 test kernel: Code: 80 3c 38 00 75 08 83 c3 07 e9 8a 00 00 00 
89 d8 c1 e8 03 8b

>>EIP; d898ef58 <[NVdriver]_nv_rmsym_01050+14/40>   <=
Trace; dda21004 <[NVdriver].bss.end+5024385/5051381>
Trace; d898f2fb <[NVdriver]_nv_rmsym_01064+2b/50>
Trace; dda21004 <[NVdriver].bss.end+5024385/5051381>
Trace; d8a08ac0 <[NVdriver].bss.end+be41/5051381>
Trace; d89873b0 <[NVdriver]dacSetFlatPanelBrightness+60/f8>
Trace; dda21004 <[NVdriver].bss.end+5024385/5051381>
Trace; d8a08a20 <[NVdriver].bss.end+bda1/5051381>
Trace; d898b70b <[NVdriver]DevinitProcessBip2+1df/32c>
Trace; dda21004 <[NVdriver].bss.end+5024385/5051381>
Trace; d898b4c0 <[NVdriver]DevinitGetBMPControlBlock+50/bc>
Trace; dda21004 <[NVdriver].bss.end+5024385/5051381>
Trace; d8a08ac0 <[NVdriver].bss.end+be41/5051381>
Trace; dda21004 <[NVdriver].bss.end+5024385/5051381>
Trace; d8988974 <[NVdriver]edidReadDevEDID+58/1d0>
Trace; d8a08ac0 <[NVdriver].bss.end+be41/5051381>
Trace; dda21004 <[NVdriver].bss.end+5024385/5051381>
Trace; d8a08ac0 <[NVdriver].bss.end+be41/5051381>
Trace; dda21004 <[NVdriver].bss.end+5024385/5051381>
Trace; d8988974 <[NVdriver]edidReadDevEDID+58/1d0>
Trace; d8a08ac0 <[NVdriver].bss.end+be41/5051381>
Trace; dda21004 <[NVdriver].bss.end+5024385/5051381>
Trace; c0119b53 
Trace; c01109f0 
Trace; c0119e33 
Trace; c012935b <__alloc_pages+6b/250>
Trace; c01e7117 
Trace; c016956d 
Trace; c01b1f3b 
Trace; c01b2098 <__kfree_skb+108/110>
Trace; c012154e <__insert_vm_struct+de/190>
Trace; c012935b <__alloc_pages+6b/250>
Trace; d893a404 <[lp]lp_write+174/1f0>
Trace; d893a004 <[ipt_LOG].data.end+344d/34a9>
Trace; d8a08ac0 <[NVdriver].bss.
-
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/

640MB MO disk major problems

[dechris]

[1.] one-line summary of the problem

I/O fails with 640MB MO disks due to 2K sector size (128MB MO disks use 512-byte 
sectors and work fine)
 
[2.] full description of the problem
 
There is a problem writing to a 640MB MO disk using FAT or VFAT.  The 
problem appears to be when reading or writing to a device that has >512K 
sectors.  The read function can be patched so that using generic_file_read() 
routine will solve the read problem.  The problem is the write routines.  My 
machine locks up to the point where I need to reset it.  No OOPS information
is available that I can send along (unless there is a way to force a dump).
If someone can *please* help me create a dump (when writing), I can process it, and 
send you a stack trace.  This is something that used to work in 2.2, but now is 
severely broken.  Thanks for your attention...

[3.] Keywords...

FAT VFAT MO Magneto-Optical hang  

[4.] Kernel info:
Linux version 2.4.3-K6 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red 
Hat Linux 7.0)) #4 Fri Apr 6 17:30:56 CDT 2001
[5.] OOPS info:
[6.] shell program or script
[7.] Environment:
BASH=/bin/bash
BASH_ENV=/root/.bashrc
BASH_VERSINFO=([0]="2" [1]="04" [2]="11" [3]="1" [4]="release" 
[5]="i386-redhat-linux-gnu")
BASH_VERSION='2.04.11(1)-release'
DIRSTACK=()
EUID=0
GROUPS=()
HISTSIZE=1000
HOME=/root
HOSTNAME=localhost.localdomain
HOSTTYPE=i386
IFS='   
'
INPUTRC=/etc/inputrc
KDEDIR=/usr
LANG=en_US
LESSOPEN='|/usr/bin/lesspipe.sh %s'
LOGNAME=root
LS_COLORS='no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:'
MACHTYPE=i386-redhat-linux-gnu
MAIL=/var/spool/mail/root
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin
PIPESTATUS=([0]="0")
PPID=676
PS4='+ '
PWD=/root/bugrpt
QTDIR=/usr/lib/qt-2.2.0
SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=2
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
TERM=linux
UID=0
USER=root
USERNAME=root
_='[7.] Environment:'
[7.1.] Software:
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux localhost.localdomain 2.4.3-K6 #4 Fri Apr 6 17:30:56 CDT 2001 i586 unknown
 
Gnu C  2.96
Gnu make   3.79.1
binutils   2.10.0.18
util-linux 2.10m
modutils   2.4.2
e2fsprogs  1.18
pcmcia-cs  3.1.19
PPP2.3.11
isdn4k-utils   3.1pre1
Linux C Library> libc.2.2
Dynamic linker (ldd)   2.2
Procps 2.0.7
Net-tools  1.56
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded tulip emu10k1
[7.2.] Processor Information:
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 9
model name  : AMD-K6(tm) 3D+ Processor
stepping: 1
cpu MHz : 451.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 mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips: 897.84

[7.3.] Module Information:
tulip  35616   1 (autoclean)
emu10k145840   0
[7.4.1.] ioports:
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
5000-50ff : VIA Technologies, Inc. VT82C586B ACPI
9000-9fff : PCI Bus #01
  9000-90ff : 3Dfx Interactive, Inc. Voodoo 4
a000-a00f : VIA Technologies, Inc. Bus Master IDE
  a000-a007 : ide0
  a008-a00f : ide1
a400-a41f : VIA Technologies, Inc. UHCI USB
  a400-a41f : usb-uhci
a800-a807 : CMD Technology Inc PCI0649
  a800-a807 : ide2
ac00-ac03 : CMD Technology Inc PCI0649
  ac02-ac02 : ide2
b000-b007 : CMD Technology Inc PCI0649
  b000-b007 : ide3
b400-b403 : CMD Technology Inc PCI0649
  b402-b402 : ide3
b800-b80f : CMD Technology Inc PCI0649
  b800-b807 : ide2
  b808-b80f : ide3
bc00-bcff : Lite-On Communications Inc LNE100TX [Linksys EtherFast 10/100]
  bc00-bcff : eth0
c000-c01f : Creative Labs SB Live! EMU1
  c000-c01f : EMU10K1
c400-c407 : Creative Labs SB Live!
[7.4.2.] iomem:
-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000c8000

CML2 1.2.3 is available

[Eric S. Raymond]

The latest version is always available at http://www.tuxedo.org/~esr/cml2/

Release 1.2.3: Mon Apr 23 00:57:39 EDT 2001
* Taral's corrections to the rulefiles.
* Linux kernel version now shows up in the configurator via -B flag.
-- 
http://www.tuxedo.org/~esr/";>Eric S. Raymond

All governments are more or less combinations against the
people. . .and as rulers have no more virtue than the ruled. . .
the power of government can only be kept within its constituted
bounds by the display of a power equal to itself, the collected
sentiment of the people.
-- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794
-
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 "su -" and kernels 2.4.3-ac11 and higher

[Manuel McLure]

On 2001.04.22 20:21 Manuel McLure wrote:
> 
> On 2001.04.22 19:42 Wayne Whitney wrote:
> > In mailing-lists.linux-kernel, Manuel A. McLure wrote:
> > 
> > > Did you try nesting more than one "su -"? The first one after a boot
> > > works for me - every other one fails.
> > 
> > Same here: the first "su -" works OK, but a second nested one hangs:
> > 
> >  8825 pts/2S  0:00 /bin/su -
> >  8826 pts/2S  0:00 -bash
> >  8854 pts/2T  0:00 stty erase ?
> >  8855 pts/0R  0:00 ps ax
> > 
> > "kill -CONT 8854" has no effect.  
> > 
> > > I'm on RH71 - this may be specific to this release. It's also
> > > kernel-dependent, I can reboot with ac5 and the problem does not
> > > happen.  The kernel is compiled with the same compiler as yours.
> > 
> > I'm RH-7.1 and kernel 2.4.4-pre6 (with the via 3.23 driver from -ac)
> 
> It looks like this may very well be a RH 7.1 interaction with the kernel,
> since others are not seeing this.

Your email made me look closer at my ps output. I also have stty waiting in
"T" state.

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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: All architecture maintainers: pgd_alloc()

[Miles Lane]

On Sun, 22 Apr 2001, David S. Miller wrote:



> My main point is that for changes like this, sending stuff to Alan
> first is often an ineffective mechanism.  If someone were to reply to
> this "Linus is hard to push changes too, or takes too long" my reply
> is "if this is really the problem, should the burdon should be
> entirely placed on Alan's shoulders?"

Perhaps Alan could speak to this.

Alan, could you delegate any of this work?  Is it feasible to
have you redirect some portion of the patch analysis and acceptance
load to another person, other than Linus?  Obviously, if the rate
of patch flow increases significantly, others will need to get
involved more closely with the patch acceptance process.

Miles

-
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: All architecture maintainers: pgd_alloc()

[Miles Lane]

On Sun, 22 Apr 2001, David S. Miller wrote:

>
> Russell King writes:
>  > There are various options here:
>  >
>  > 1. Either I can fix up all architectures, and send a patch to this list, or
>
> Fixup all the architectures and send this and the ARM bits to Linus.
>
> I really would wish folks would not choose Alan as the first place
> to send the patch.  I'm not directly accusing anyone of it, but it
> does appear that often AC is used as a "back door" to get a change
> in.  While this scheme most of the time, often it unnecessarily
> overworks Alan which I think is unfair.

Hi David,

While I agree that this state of affairs must be taxing Alan,
it was my understanding that this situation was _intended_.
It's been explicitly stated, IIRC, that only really important
bug fixes for very well-defined problems should be going
to Linus.  This was announced around the time of the 2.4 launch.
The reasoning being that Linus wanted to be assured that we
would not have a backslide in kernel stability after the 2.4
launch, like happened after the 2.2 launch.  My understanding
is that Alan is acting as gatekeeper for the experimental
and lower priority patches until after the 2.5 kernel opens
up.  Of course, then the 2.4 maintainer (who will likely
be Alan?) will be receiving 2.4 patches, while Linus begins
receiving all things 2.5 (experimental or not).  My guess
(perhaps grossly incorrect) is that the flow rate of patches
after the 2.5 tree opens will be pretty evenly split between
2.5 and 2.4.

Again, IIRC, Linus wanted to stay really focused on the 2.4
kernel stability.  Having Alan shielding him from the huge
quantity of patches has probably helped him be effective in
making sure patches in the 2.4.x-pre series are good stuff.

Have I got this right?

Cheers,
Miles

-
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: All architecture maintainers: pgd_alloc()

[David S. Miller]

Russell King writes:
 > There are various options here:
 > 
 > 1. Either I can fix up all architectures, and send a patch to this list, or

Fixup all the architectures and send this and the ARM bits to Linus.

I really would wish folks would not choose Alan as the first place
to send the patch.  I'm not directly accusing anyone of it, but it
does appear that often AC is used as a "back door" to get a change
in.  While this scheme most of the time, often it unnecessarily
overworks Alan which I think is unfair.

Sending it to Linus first also eliminates 2 levels of indirection
each time Linus wants something done differently in the change.

person --> alan --> linus --> needs change

alan BCC's person, person codes new version

person --> alan --> linus --> etc. etc.

Sure Alan could fix it up himself, but...

My main point is that for changes like this, sending stuff to Alan
first is often an ineffective mechanism.  If someone were to reply to
this "Linus is hard to push changes too, or takes too long" my reply
is "if this is really the problem, should the burdon should be
entirely placed on Alan's shoulders?"

The AC patches are huge, but they have substantially decreased in size
during the recent 2.4.4-preX series.  And sure, Alan makes conscious
decisions to apply patches and eventually work to push them to Linus,
but honestly people should consider ways to help decrease his load.

Later,
David S. Miller
[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 to abyss.c against 2.4.2-ac28

[Adam Fritzler]

I've sent an equivelent patch (along with another fix) to Alan, which is
included in the latest -ac.

af.

On Tue, 10 Apr 2001, Bart Dorsey wrote:

> This is my first time sending in a patch to the kernel. 
> 
> This is a one line fix to the abyss tokenring driver in 2.4.2-ac28
> 
> I got this fix from the driver maintainer who said 
> 
> "I guess I really should send this in to Linus"
> 
> I'm just going to go ahead and jump the gun and submit 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: Kernel hang on multi-threaded X process crash

[idalton]

On Sun, Apr 22, 2001 at 08:23:39PM -0700, Manuel McLure wrote:
> 
> On 2001.04.22 20:17 Manuel McLure wrote:
> > 
> > To follow up on my followup, I can now reproduce this 100% and get the
> > "Trying to vfree()..." message on the console. To do this I start
> > Mozilla,
> > switch to a text console, and do a "killall -QUIT mozilla". A couple of
> 
> Make that "killall -QUIT mozilla-bin"...

I'll see if mine does this too. I've been having hard locks
intermittantly too, sometimes starting X, mostly with mozilla. My
system's a dual Pmmx200 with ATI rage pro and Matrox Mill 2 PCI.

-- Ferret
-
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/

rwsem.o undefined reference to __builtin_expect

[Jeff Chua]

cannot compile 2.4.4-pre6. This may have been reported, but I
haven't seen it.

Thanks,
Jeff.


ld -m elf_i386 -T /u2/src/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o  drivers/char/drm/drm.o
drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o
drivers/md/mddev.o \
net/network.o \
/u2/src/linux/arch/i386/lib/lib.a /u2/src/linux/lib/lib.a
/u2/src/linux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
/u2/src/linux/lib/lib.a(rwsem.o): In function `__rwsem_do_wake':
rwsem.o(.text+0x30): undefined reference to `__builtin_expect'
rwsem.o(.text+0x73): undefined reference to `__builtin_expect'
make: *** [vmlinux] Error 1



-
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: Kernel hang on multi-threaded X process crash

[Manuel McLure]

On 2001.04.22 20:17 Manuel McLure wrote:
> 
> On 2001.04.22 19:27 Manuel McLure wrote:
> > 
> > On 2001.04.22 18:55 Manuel McLure wrote:
> > 
> > > The machine is an Athlon Thunderbird 900MHz with 256M of PC133 DRAM
> on
> > an
> > > MSI K7T Turbo R motherboard. I am running 2.4.3-ac12 currently,
> > > 2.4.3-ac11
> > > and 2.4.3-ac5 hung the same way at least once each before I started
> > > tracking this down. I am running Red Hat 7.1, and am using the
> > > XFree86-4.0.3 RPMs that come with RH71 with the CVS DRI trunk
> installed
> > > over it. The kernel was built with kgcc, a gcc-2.96 built kernel has
> > the
> > > same problem.
> > 
> > Following up on myself, I replaced the contents of /usr/X11R6 server
> with
> > the standard 4.0.3 RPMs that come with RH 7.1 and it made no
> difference.
> > Also, if it's important my video card is a Voodoo 5 5500.
> 
> To follow up on my followup, I can now reproduce this 100% and get the
> "Trying to vfree()..." message on the console. To do this I start
> Mozilla,
> switch to a text console, and do a "killall -QUIT mozilla". A couple of
^^^

Make that "killall -QUIT mozilla-bin"...


> "Trying to vfree()..." messages later, it's big red switch time.
> 
> I'm going to try this with standard 2.4.3 as well as the 2.4.2 that comes
> with RH71 - hopefully my filesystem will handle all the fscks :-(

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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 "su -" and kernels 2.4.3-ac11 and higher

[Manuel McLure]

On 2001.04.22 19:42 Wayne Whitney wrote:
> In mailing-lists.linux-kernel, Manuel A. McLure wrote:
> 
> > Did you try nesting more than one "su -"? The first one after a boot
> > works for me - every other one fails.
> 
> Same here: the first "su -" works OK, but a second nested one hangs:
> 
>  8825 pts/2S  0:00 /bin/su -
>  8826 pts/2S  0:00 -bash
>  8854 pts/2T  0:00 stty erase ?
>  8855 pts/0R  0:00 ps ax
> 
> "kill -CONT 8854" has no effect.  
> 
> > I'm on RH71 - this may be specific to this release. It's also
> > kernel-dependent, I can reboot with ac5 and the problem does not
> > happen.  The kernel is compiled with the same compiler as yours.
> 
> I'm RH-7.1 and kernel 2.4.4-pre6 (with the via 3.23 driver from -ac)

It looks like this may very well be a RH 7.1 interaction with the kernel,
since others are not seeing this.

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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 "su -" and kernels 2.4.3-ac11 and higher

[Manuel McLure]

On 2001.04.22 19:42 Brett wrote:
> On Sun, 22 Apr 2001, Manuel McLure wrote:
> >
> > 
> > On 2001.04.22 14:38 Andrzej Krzysztofowicz wrote:
> > > > 
> > > > I'm having a problem with "su -" on ac11/ac12. ac5 doesn't show the
> > > > problem.
> > > > The problem is easy to reproduce - go to a console, log in as root,
> do
> > > an
> > > > "su -" (this will succeed) and then another "su -". The second "su
> -"
> > > > should hang - ps shows it started bash and that the bash process is
> > > > sleeping. You need to "kill -9" the bash to get your prompt back.
> > > 
> 
> No problem here either...
> Tried nesting 7 levels deep, a few times.
> 
> p75
> 
> # uname -a
> Linux lapsis 2.4.3-ac12 #2 Sun Apr 22 17:41:08 EST 2001 i586 unknown
> 
> # ls /lib/libc-*
> -rwxr-xr-x1 root root  1417065 Feb 17 14:57
> /lib/libc-2.2.2.so*
> 
> # gcc --version
> 2.95.3
> 
> # su --version
> su (GNU sh-utils) 2.0j
> 
>   / Brett
> 

In my case:

# su --version
su (GNU sh-utils) 2.0

# bash --version
GNU bash, version 2.04.21(1)-release (i386-redhat-linux-gnu)

# uname -a
Linux ulthar 2.4.3-ac12 #3 Sat Apr 21 23:15:08 PDT 2001 i686 unknown

# ls -l /lib/libc-*
-rwxr-xr-x2 root root  1236396 Apr  6 14:58 /lib/libc-2.2.2.so

# kgcc --version
egcs-2.91.66


-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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: Kernel hang on multi-threaded X process crash

[Manuel McLure]

On 2001.04.22 19:27 Manuel McLure wrote:
> 
> On 2001.04.22 18:55 Manuel McLure wrote:
> 
> > The machine is an Athlon Thunderbird 900MHz with 256M of PC133 DRAM on
> an
> > MSI K7T Turbo R motherboard. I am running 2.4.3-ac12 currently,
> > 2.4.3-ac11
> > and 2.4.3-ac5 hung the same way at least once each before I started
> > tracking this down. I am running Red Hat 7.1, and am using the
> > XFree86-4.0.3 RPMs that come with RH71 with the CVS DRI trunk installed
> > over it. The kernel was built with kgcc, a gcc-2.96 built kernel has
> the
> > same problem.
> 
> Following up on myself, I replaced the contents of /usr/X11R6 server with
> the standard 4.0.3 RPMs that come with RH 7.1 and it made no difference.
> Also, if it's important my video card is a Voodoo 5 5500.

To follow up on my followup, I can now reproduce this 100% and get the
"Trying to vfree()..." message on the console. To do this I start Mozilla,
switch to a text console, and do a "killall -QUIT mozilla". A couple of
"Trying to vfree()..." messages later, it's big red switch time.

I'm going to try this with standard 2.4.3 as well as the 2.4.2 that comes
with RH71 - hopefully my filesystem will handle all the fscks :-(
-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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] Longstanding elf fix (2.4.3 fix)

[David S. Miller]

Eric W. Biederman writes:
 > In building a patch for 2.4.3 I also discovered that we are not taking 
 > the mmap_sem around do_brk in the exec paths.

Does that really matter?  Who else can get at the address space?  We
are a singly referenced address space at that point... perhaps ptrace?

Later,
David S. Miller
[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: 2.4.3+ sound distortion

[David]

  I have noticed a problem with sound lately.  I have a cs46xx card and 
it randomly gets distorted.  Normally I just reboot but on this last 
occurence I simply left it as it was.  The distortion sounds someone 
punched the speaker core, it's tinny and mangled.  Today it fixed itself 
out of the blue in the middle of playing a sound. All sound programs are 
equally affected.

It's only done this in the 2.4 series, I haven't had the desire to look 
into it.

David

Mike Castle wrote:

>On Sat, Apr 21, 2001 at 06:04:47PM +0200, Victor Julien wrote:
>
>>I have a problem with kernels higher than 2.4.2, the sound distorts when 
>>playing a song with xmms while the seti@home client runs. 2.4.2 did not have 
>>
>
>Would this be the same issue as describe in these threads:
>
>http://www.uwsg.indiana.edu/hypermail/linux/kernel/0104.0/0233.html
>http://www.uwsg.indiana.edu/hypermail/linux/kernel/0104.1/0231.html
>
>That is, the change in how nice is recalculated.
>
>mrc
>


-
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 "su -" and kernels 2.4.3-ac11 and higher

[John Cavan]

Manuel McLure wrote:
> Did you try nesting more than one "su -"? The first one after a boot works
> for me - every other one fails.

I tried it with about a half-dozen nested and no problem. Mandrake
cooker here...

uname -a
Linux lion 2.4.3-ac11 #5 SMP Fri Apr 20 22:10:41 EDT 2001 i686 unknown

gcc --version 
2.96

ls -l /lib/libc-*
-rwxr-xr-x1 root root  1216268 Feb 21 05:38
/lib/libc-2.2.2.so

su --version
su (GNU sh-utils) 2.0

I don't think libc is the problem, unless it is in conjunction with the
compiler choice. Have you tried building the kernel with the updated Red
Hat gcc version? I know Mandrake has kept theirs current to Red Hat and
it works fine for me.

John
-
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/

MO drives (2048 byte block vfat fs) in lk 2.4

[Douglas Gilbert]

The "MO" bug (also 2048 byte block vfat problem) has been
reported several times in the lk 2.4 series. Since the
finger was being pointed at the SCSI subsystem I decided
to investigate. As far as I can see the sd driver offers
the same physical block (other than 512 byte) capabilities
in lk 2.4 as it did in lk 2.2 .

One error report stated that a MO drive with a vfat
fs based on 2048 byte sectors can be mounted and read
but any significant write causes a system lockup. I
have been able to replicate this behaviour. Luckily
Alt-SysRq-P did work. Pressing this sequence multiple
times gave similar addresses. Rebooting the machine
and rerunning the experiment multiple time gave 
addresses in the same area.

The EIP resolved most often to cont_prepare_write() in
fs/buffer. A disassembly suggests line 1802 in buffer.c
[2.4.3ac11]. That is around a memset() between
__block_prepare_write() and __block_commit_write() calls
within the while loop. Most other addresses were within
the same while loop. Perhaps someone with expertize
in this area may like to examine that loop.


Details: I modified the "scsi_debug" adapter driver to look
like it had one 2048 byte block MO drive connected to it.
The driver uses 8 MB of RAM to simulate a storage device.
[For anyone who wants to run similar experiments, I have
placed the driver at www.torque.net/sg/p/scsi_debug_mo.tgz ].
The sequence of commands that lead up to the failure was:
 $ modprobe scsi_debug
 $ cat /proc/scsi/scsi# "optical" device should be there
 $ fdisk -ul /dev/sdb # should see 3 partitions
 $ mkdosfs -S 2048 /dev/sdb3
 $ mount /dev/sdb3 /mnt/extra
 $ cd /mnt/extra
 $ touch t# worked ok
 $ cp /boot/vml-2.2.18 u  # system locks up

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: Problem with "su -" and kernels 2.4.3-ac11 and higher

[Wayne Whitney]

In mailing-lists.linux-kernel, Manuel A. McLure wrote:

> Did you try nesting more than one "su -"? The first one after a boot
> works for me - every other one fails.

Same here: the first "su -" works OK, but a second nested one hangs:

 8825 pts/2S  0:00 /bin/su -
 8826 pts/2S  0:00 -bash
 8854 pts/2T  0:00 stty erase ?
 8855 pts/0R  0:00 ps ax

"kill -CONT 8854" has no effect.  

> I'm on RH71 - this may be specific to this release. It's also
> kernel-dependent, I can reboot with ac5 and the problem does not
> happen.  The kernel is compiled with the same compiler as yours.

I'm RH-7.1 and kernel 2.4.4-pre6 (with the via 3.23 driver from -ac)

Cheers, Wayne
-
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 "su -" and kernels 2.4.3-ac11 and higher

[Brett]

On Sun, 22 Apr 2001, Manuel McLure wrote:
>
> 
> On 2001.04.22 14:38 Andrzej Krzysztofowicz wrote:
> > > 
> > > I'm having a problem with "su -" on ac11/ac12. ac5 doesn't show the
> > > problem.
> > > The problem is easy to reproduce - go to a console, log in as root, do
> > an
> > > "su -" (this will succeed) and then another "su -". The second "su -"
> > > should hang - ps shows it started bash and that the bash process is
> > > sleeping. You need to "kill -9" the bash to get your prompt back.
> > 

No problem here either...
Tried nesting 7 levels deep, a few times.

p75

# uname -a
Linux lapsis 2.4.3-ac12 #2 Sun Apr 22 17:41:08 EST 2001 i586 unknown

# ls /lib/libc-*
-rwxr-xr-x1 root root  1417065 Feb 17 14:57 /lib/libc-2.2.2.so*

# gcc --version
2.95.3

# su --version
su (GNU sh-utils) 2.0j

/ Brett

-
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/

Ext3 for Linux 2.4 progress report

[Peter J. Braam]

Hi Andreas, Stephen, 

We have a lot working now: 

1. journal recovery and initialization stuff is working
2. transactions go to the disk
3. infrastructure is there to do transcactions
4. ext3_create is fully operational. 

The problems we have seen mostly have to do with differences in which
buffer heads are being initialized.  Things like b_transaction etc. were
not cleaned up.

There are more buffer head problems around, but we are debugging them
quickly now.

You can play with this, make a loop device, mount it and to things like
touch (NOTE: only file creations have been handled so far).  If you
re-mount a dirty ext3 image, it will recovery.  The first few always
work, but at present things go wrong when bdflush kicks in.

We left a patch at: 

ftp.inter-mezzo.org:/pub/ext3/242-ac26-1um.ext3-ph5_4.patch.gz

In the patch there are markers of the form @@@ with your names, asking for
help!

- Peter -

-
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: Kernel hang on multi-threaded X process crash

[Manuel McLure]

On 2001.04.22 18:55 Manuel McLure wrote:

> The machine is an Athlon Thunderbird 900MHz with 256M of PC133 DRAM on an
> MSI K7T Turbo R motherboard. I am running 2.4.3-ac12 currently,
> 2.4.3-ac11
> and 2.4.3-ac5 hung the same way at least once each before I started
> tracking this down. I am running Red Hat 7.1, and am using the
> XFree86-4.0.3 RPMs that come with RH71 with the CVS DRI trunk installed
> over it. The kernel was built with kgcc, a gcc-2.96 built kernel has the
> same problem.

Following up on myself, I replaced the contents of /usr/X11R6 server with
the standard 4.0.3 RPMs that come with RH 7.1 and it made no difference.
Also, if it's important my video card is a Voodoo 5 5500.

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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 "su -" and kernels 2.4.3-ac11 and higher

[Manuel McLure]

On 2001.04.22 14:38 Andrzej Krzysztofowicz wrote:
> > 
> > I'm having a problem with "su -" on ac11/ac12. ac5 doesn't show the
> > problem.
> > The problem is easy to reproduce - go to a console, log in as root, do
> an
> > "su -" (this will succeed) and then another "su -". The second "su -"
> > should hang - ps shows it started bash and that the bash process is
> > sleeping. You need to "kill -9" the bash to get your prompt back.
> 
> No problem here.
> 
> P233MMX
> 
> # uname -a
> Linux kufel 2.4.3-ac12 #2 nie kwi 22 15:32:51 CEST 2001 i586 unknown
> 
> # ls -l /lib/libc-*
> -rwxr-xr-x   1 root root  1060168 Nov 19 11:17 /lib/libc-2.1.3.so
> 
> # gcc --version
> egcs-2.91.66
> (kernel with the fix by Niels Kristian Bech Jensen <[EMAIL PROTECTED]>)
> 
> # su --version
> su (GNU sh-utils) 2.0
> 
> Maybe it is RH7 specyfic ? Or you have some compiler / hardware problem ?
> 
> Andrzej

Did you try nesting more than one "su -"? The first one after a boot works
for me - every other one fails.
I'm on RH71 - this may be specific to this release. It's also
kernel-dependent, I can reboot with ac5 and the problem does not happen.
The kernel is compiled with the same compiler as yours.

My libc is 2.2.2 while yours is 2.1.3 - this may be the difference.

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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: Pcmcia-Updates for Xircomcards?

[Jeff Garzik]

An updated driver "xircom_cb" written by Arjan is available in Alan
Cox's 2.4.3-acXX series.  This fixes all known problems AFAIK.
-- 
Jeff Garzik  | The difference between America and England is that
Building 1024| the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
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 "su -" and kernels 2.4.3-ac11 and higher

[Andrzej Krzysztofowicz]

> 
> I'm having a problem with "su -" on ac11/ac12. ac5 doesn't show the
> problem.
> The problem is easy to reproduce - go to a console, log in as root, do an
> "su -" (this will succeed) and then another "su -". The second "su -"
> should hang - ps shows it started bash and that the bash process is
> sleeping. You need to "kill -9" the bash to get your prompt back.

No problem here.

P233MMX

# uname -a
Linux kufel 2.4.3-ac12 #2 nie kwi 22 15:32:51 CEST 2001 i586 unknown

# ls -l /lib/libc-*
-rwxr-xr-x   1 root root  1060168 Nov 19 11:17 /lib/libc-2.1.3.so

# gcc --version
egcs-2.91.66
(kernel with the fix by Niels Kristian Bech Jensen <[EMAIL PROTECTED]>)

# su --version
su (GNU sh-utils) 2.0

Maybe it is RH7 specyfic ? Or you have some compiler / hardware problem ?

Andrzej

-
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/

USB fails in 2.4.3-ac6

[Joseph Carter]

With 2.4.3-ac6, USB input doesn't work.  It works with -ac4, and I'm
waiting for -ac13 or so before I try something later.

By "doesn't work", I mean that the USB keyboard and mouse are never
detected.  A config snippet:

CONFIG_INPUT=y
CONFIG_INPUT_KEYBDEV=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y

CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set

CONFIG_USB_UHCI_ALT=y

CONFIG_USB_HID=y


Has anyone else seen this problem?  I suspect it is the Alt UHCI driver
which I read somewhere was preferred for VIA-based systems.  I don't
really know what the difference is between them - the help in the kernel
doesn't really say much about how they are different other than that they
are.

I must compile the USB stuff into the kernel as I do not have legacy input
devices on this system (and am proud of it!  hehe)

-- 
Joseph Carter <[EMAIL PROTECTED]>Free software developer

 you are not a nutcase
 You obviously don't know me well enough yet.  =>


 PGP signature

Kernel hang on multi-threaded X process crash

[Manuel McLure]

Well, this is what I get for being on the cutting edge... :-(

I'm now running into problems where the machine will totally hang (no
network, no SysRq, no nothin') regularly. The triggers seem to be running
aviplay or mozilla.

Symptoms will be that I am running aviplay or mozilla, and the machine will
suddenly hang and need to be hard-reset. I can trigger it 100% by telling
aviplay to zoom 2x.

I finally managed to reproduce it while I was on a console (I telneted in
from another machine, and ran aviplay on the X display that was on console
7 while the machine was displaying console 1) - the only message before the
hang was "Trying to vfree() nonexistent vm area (d0992000)" - no Oops was
shown.

Whenever this happens, the e2fsck step at reboot shows a
"Entry 'core.' in  (XX) had deleted/unused inode XX.
CLEARED" message. The core file is always in whatever directory I was
running the process that seems to cause the crash. It seems like either the
core is a symptom of the underlying problem, or the process coredumping is
causing the hang.

The machine is an Athlon Thunderbird 900MHz with 256M of PC133 DRAM on an
MSI K7T Turbo R motherboard. I am running 2.4.3-ac12 currently, 2.4.3-ac11
and 2.4.3-ac5 hung the same way at least once each before I started
tracking this down. I am running Red Hat 7.1, and am using the
XFree86-4.0.3 RPMs that come with RH71 with the CVS DRI trunk installed
over it. The kernel was built with kgcc, a gcc-2.96 built kernel has the
same problem.

Any ideas?

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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/

xf86 server crash and VM problem(?)

[Ishikawa]

First, excuse my rather length posting.
I have been trying to figure out what is wrong with my
setup  for the last few weeks and hit upon the slight chance
that there may be a VB related problem in the linux kernel.
Thus my post here.

PROBLEM:
I can crash X server by the following step rather reliably.
run X : whether I run this under xdm or X is irrelevant here.
run netscape .

Load the following page in netscape.
This is a 250KB+ solaris 2 FAQ page.

http://www.fwi.uva.nl/pub/solaris/solaris2.html

While looking at this page using netscape,
begin searching the successive occurences of
the string "handle" using netscape "Find in page" menu.
On the search of the second or the third occurence of the
string in the said page, suddenly, the
screen went blank and xdm restarts the X server.

X server crashed!

(Now of course, the setting of fonts and others
will make the reproduction of this bug? rather
difficult on other systems.)

SYSTEM:
Linux Kernel : 2.4.4-pre4.
uname -a
Linux duron 2.4.4-pre4 #15 Thu Apr 19 01:58:23 JST 2001 i686
unknown
System: Debian (testing).
CPU : AMD Duron 750.
Memory : 256MB  (+ Swap 80MB).
Video card: ATI rage 128.
Used X server: XFree86 3.3.6 XF86_SVGA (with fixes)

SUSPECT:

Now there can be various causes of this problem which I am
investigating, but I suspect a VM problem because of the
following:

 - from my investigation shown below, it seems that the X server was
   accessing an invalid(?) memory area, but I am not quite sure why it
can
   be an invalid memory area.

 - on linux kernel 2.4.[1-4], I once observed strange
   hung of my Xsession and when I tried to switch to another
   virtual console, I observed strange console messages like

swap_free: Trying to free non-existent swap page
   Bad Swap Entry: 0008
// many //

I also noticed a few posting about
unresolved swap problems in linux kernel mailing list.

 - My manual procedure to repeat the bug causes the
   swap device to be used initially. That is the main memory
   was about to overflow or just began overflowing when the
   crash was observed (I think).

   I use xosview monitor program to monitor memory usage.
   When I start netscape "Used+Share" is about 100MB+.
   After loading the web page, it goes up to slighly abote 128MB.
   Afte the first search, it goes to close to 200MB. But
   in a transient manner, it goes up to close to 250MB and
   comes down to this 200MB value.
   So if I assume similar transient increase is expected for
   the subsequent string search,
   I think during the manual testing, the main memory (256MB)
   is exhausted and swap area was about to be touched.

  ( I run squid, nntpcache and xfs-xtt font server, dns and other
daemons on  this machine
   and so memory usage is rather heavy.)


Of course, I am not ruling out the following possibilities:
 (i)  - the bug of the XFree86 3.3.6 XF_SVGA server,
   (ii) especially the ATI rage 128 driver portion,
 - and the bug hardware of my PC, such as
 (iii) memory
 (iv) video card itself.
 - (v) and possibly other reasons (I can't fathom yet).

So far, I think I could rule out the bug of (ii) since from what I
found out below.  The problem of the xserver occurs in a generic
bitblt copy routine for 16bit depth color frame.  (On the other hand,
it is hard to believe such a bug still exists in 3.3.6 server. Hmm..)

Also, by testing the memory with memtest86 over the last couple of
weeks on and off I think I can rule out (iii).

I am stumped for now here and posting this to solict
tips and hints for debugging.

(I am sticking to XFree86 3.3.6 server  because of
the following reason.
The linux swap bug and other subtle VM bug seem to be very
hard to reproduce. *IF* this probem I have observed
is caused by a linux VM bug, my setting then would
be an ideal setting to find out exactly what the VM bug is.)

Anyway, here is what I did and found out
(I tidied up the list. Actually, I did lot of
backtracking and trials and errors.)

1. After the crash, checked the output of xdm.log.
(My X server is invoked via xdm.)
   Found that the X server died due to segmentation error.

2. Found that I set the core sizelimit to 0 and so no core
   was created. Too bad.

3. I changed  core size limit (using "ulimit -c")
   and re-started the xdm (and X11 server) so that
   a core will be roduced when the X server crashes.

4. I repeated the manual procedure
   to crash X server, i.e. the problematic netscape page access,
   the XFree86 X11 server crashed. Now a core file was produced. Good!

2. Tried to find out in which function the server dumped core.
   I ran gdb X core.
   At least I knew the function "cfb16DoBitbltCopy ()"
   was the cause.
   But I found out that the supplied X server binary has no debug
information.
   And so the information was sparce.

3. I needed more

Re: [PATCH] PPP update against 2.4.4-pre5

[Paul Mackerras]

Byeong-ryeol Kim writes:

> I met 'unresolved symbol sk_chk_filter ...' after applying this patch
> and rebooting.( with CONFIG_PPP_FILTER=y )
> There shoud be folling lines in linux/net/netsyms.c or so:
> 
> #ifdef CONFIG_PPP_FILTER
> EXPORT_SYMBOL(sk_chk_filter);
> #endif

Good idea, actually let's put it next to the export of sk_run_filter,
as in the patch below.  Linus, could you apply this patch please?

Paul.

diff -urN linux/net/netsyms.c pmac/net/netsyms.c
--- linux/net/netsyms.c Sun Apr 22 17:07:40 2001
+++ pmac/net/netsyms.c  Mon Apr 23 11:24:31 2001
@@ -158,6 +158,7 @@
 
 #ifdef CONFIG_FILTER
 EXPORT_SYMBOL(sk_run_filter);
+EXPORT_SYMBOL(sk_chk_filter);
 #endif
 
 EXPORT_SYMBOL(neigh_table_init);
-
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] rw_semaphores, optimisations

[Andrea Arcangeli]

On Mon, Apr 23, 2001 at 03:04:41AM +0200, Andrea Arcangeli wrote:
> that is supposed to be a performance optimization, I do the same too in my code.

ah no I see what you mean, yes you are hurted by that. I'm waiting your #try 3
against pre6, by that time I hope to be able to make a run of the benchmark of
my asm version too (I will grow the graph).

Andrea
-
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] rw_semaphores, optimisations

[Andrea Arcangeli]

On Sun, Apr 22, 2001 at 11:52:29PM +0100, D . W . Howells wrote:
> Hello Andrea,
> 
> Interesting benchmarks... did you compile the test programs with "make 
> SCHED=yes" by any chance? Also what other software are you running?

No I never tried the SCHED=yes. However in my modification of the rwsem-rw bench
I dropped the #ifdef SCHED completly and I schedule the right way (first
checking need_resched) in a more interesting place (in the middle of the
critical section).

> The reason I ask is that running a full blown KDE setup running in the 
> background, I get the following numbers on the rwsem-ro test (XADD optimised 
> kernel):
> 
> SCHED: 4615646, 4530769, 4534453 and 4628365
> no SCHED: 6311620, 6312776, 6327772 and 6325508

No absolutely not, that machine has nearly only the kernel daemons running
in background (even cron is disabled to make sure it doesn't screwup
the benchmarks). This is how the machine looks like before running the
bench.

andrea@laser:~ > ps xa
  PID TTY  STAT   TIME COMMAND
1 ?S  0:03 init [2] 
2 ?SW 0:00 [keventd]
3 ?SW 0:00 [kswapd]
4 ?SW 0:00 [kreclaimd]
5 ?SW 0:00 [bdflush]
6 ?SW 0:00 [kupdated]
7 ?SW<0:00 [mdrecoveryd]
  123 ?S  0:00 /sbin/dhcpcd -d eth0
  150 ?S  0:00 /sbin/portmap
  168 ?S  0:00 /usr/sbin/syslogd -m 1000
  172 ?S  0:00 /usr/sbin/klogd -c 5
  220 ?S  0:00 /usr/sbin/sshd
  254 ?S  0:00 /usr/sbin/automount /misc file /etc/auto.misc
  256 ?S  0:00 /usr/sbin/automount /net program /etc/auto.net
  271 ?S  0:00 /usr/sbin/rpc.kstatd
  276 ?S  0:00 /usr/sbin/rpc.kmountd
  278 ?SW 0:00 [nfsd]
  279 ?SW 0:00 [nfsd]
  280 ?SW 0:00 [nfsd]
  281 ?SW 0:00 [nfsd]
  282 ?SW 0:00 [lockd]
  283 ?SW 0:00 [rpciod]
  459 ?S  0:00 /usr/sbin/inetd
  461 tty1 S  0:00 /sbin/mingetty --noclear tty1
  462 tty2 S  0:00 /sbin/mingetty tty2
  463 tty3 S  0:00 /sbin/mingetty tty3
  464 tty4 S  0:00 /sbin/mingetty tty4
  465 tty5 S  0:00 /sbin/mingetty tty5
  466 tty6 S  0:00 /sbin/mingetty tty6
 1177 ?S  0:00 in.rlogind
 1178 pts/0S  0:00 login -- andrea
 1179 pts/0S  0:00 -bash
 1186 pts/0R  0:00 ps xa
andrea@laser:~ > 

> > (ah and btw the machine is a 2-way PII 450mhz). 
> 
> Your numbers were "4274607" and "4280280" for this kernel and test This I 
> find a little suprising. I'd expect them to be about 10% higher than I get on 
> my machine given your faster CPUs.
> 
> What compiler are you using? I'm using the following:
> 
>Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
>gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-80)

andrea@athlon:~ > gcc -v
Reading specs from 
/home/andrea/bin/i686/gcc-2_95-branch-20010325/lib/gcc-lib/i686-pc-linux-gnu/2.95.4/specs
gcc version 2.95.4 20010319 (prerelease)
andrea@athlon:~ > 

ah and btw, I also used the builtin expect in all the fast path but they were
compiled out by the preprocessor because I'm compiling with <96.

> Something else that I noticed: Playing a music CD appears to improve the 
> benchmarks all round:-) Must be some interrupt effect of some sort, or maybe 
> they just like the music...

The machine is a test box without soundcard, disk was idle.

> > rwsem-2.4.4-pre6 + my new generic rwsem (fast path in C inlined)
> 
> Linus wants out of line generic code only, I believe. Hence why I made my 
> generic code out of line.

I also did a run with my code out of line of course and as you can see
it's not a relevant penality.

> I have noticed one glaring potential slowdown in my generic code's down 
> functions. I've got the following in _both_ fastpaths!:
> 
> struct task_struct *tsk = current;

that is supposed to be a performance optimization, I do the same too in my code.

> It's also interesting that your generic out-of-line semaphores are faster 
> given the fact that you muck around with EFLAGS and CLI/STI, and I don't. 

as said in my last email I changed the semantics and you cannot call up_* from
irq context anymore, so in short I'm not mucking with cli/sti/eflags anymore.

Note that I didn't released anything but the bench yet, I am finishing to
plugin an asm fast path on top of my slow path and then I will run new
benchmark and post some code.

But my generic semaphore is also smaller, it's 16 byte in size even in SMP both
the asm optimized rwsem and the C generic one (of course on 32bit archs, for
64bit archs is slightly bigger than 16 bytes).

Andrea
-
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.

RE: [PATCH] ppp_generic, kernel 2.4.3

[Paul Mackerras]

Tim Wilson writes:

> Thanks for your reply. It seems I am finally talking to the right person (I
> had previously tried posting this on the pptp-server mailing list, and I
> also tried sending it to you directly, but no luck).

Sorry, life has been a little turbulent for me over the last couple of
months.

> Well, I do know that people set up Linux gateways as PPTP servers, and that
> they use MPPE to allow win98 clients to connect to those servers. That's
> what I was trying to do anyway. After the connect, the gateway log says that
> MPPE is negotiated, and the win98 client claims MPPE is being used, so all
> looks OK, but the gateway sends PPP frames in cleartext. If that's not a
> security hole, it is certainly not a Good Thing.

Well, it's a consequence of using a knife to drive in a nail. :)

Neither CCP nor the Linux CCP implementation are really designed to
support encryption.  There is a fairly strong assumption that if
things go pear-shaped you can always take CCP down and send stuff
uncompressed - it will be slower but it will still work.

> As my patch shows, the fix
> is quite easy, so reqardless of what we call it, might as well fix it.

Sure, we can fix the problem you've pointed out, but that won't make
for a secure MPPE implementation.  (Is that an oxymoron, actually?)
What I am saying is that even with your fix there is still a lot more
work to do if you want to make sure that you never send or accept
unencypted PPP frames.

>  Server   Client
> 1)    2)   ConfAck-->
> 3)   ConfReq-->
> 4)    
> 
> The existing code (correctly) enables the compressor when it sends the
> ConfAck (2). Then, it (incorrectly) disables the compressor when sending the
> ConfReq in (3). With my fix, that doesn't happen; the compressor is disabled
> at by reception of the ConfReq at(1), but it's not enabled yet anyway, so no
> harm done.

Good point.

>   if( ppp->flags & SC_CCP_UP) {
>   ppp->rstate &= ~SC_DECOMP_RUN;
>   ppp->xstate &= ~SC_COMP_RUN;
>   ppp->flags &= ~SC_CCP_UP;
>   }

Yep, with the exception that I wouldn't clear SC_CCP_UP, since that is
set and cleared by pppd.

Here is an updated patch.

Paul.

diff -urN linux/drivers/net/ppp_generic.c pmac/drivers/net/ppp_generic.c
--- linux/drivers/net/ppp_generic.c Sun Apr 22 17:07:28 2001
+++ pmac/drivers/net/ppp_generic.c  Mon Apr 23 10:12:27 2001
@@ -1993,10 +1993,10 @@
/*
 * CCP is going down - disable compression.
 */
-   if (inbound)
+   if (ppp->flags & SC_CCP_UP) {
ppp->rstate &= ~SC_DECOMP_RUN;
-   else
ppp->xstate &= ~SC_COMP_RUN;
+   }
break;
 
case CCP_CONFACK:
@@ -2054,7 +2054,7 @@
ppp->xc_state = 0;
}
 
-   ppp->xstate &= ~SC_DECOMP_RUN;
+   ppp->rstate &= ~SC_DECOMP_RUN;
if (ppp->rc_state) {
ppp->rcomp->decomp_free(ppp->rc_state);
ppp->rc_state = 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: Request for comment -- a better attribution system

[Rik van Riel]

On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Horst von Brand <[EMAIL PROTECTED]>:
> > Then explain to everybody here in a language they'll understand _what_ is
> > wrong and _why_. Then propose a solution.
> 
> I'm on it.  You'll see the results fairly shortly.

"Here, have this solution.  I'm sure there must be a problem for it."

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: Linux 2.4.3-ac12

[John Cavan]

Alan Cox wrote:
> 
> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_down_write_failed
> >
> > Same thing with tdfx.o...
> 
> "Works for me" as ever. What configuration options are you using. This sounds
> like some of the code is built with each kind of semaphore.

Mine is attached. I always run "make menuconfig", reconfirm my
selections (which haven't changed in ages), save it, and then run "make
dep" before building. I should note that I'm using a version of the DRI
from CVS from early April, but it has been perfectly happy until now. I
also tried it with the code in the kernel tree, same problem.

John
 config

[PATCH] Add DHCP to 2.4.x ipconfig support

[Eric W. Biederman]

Here is a forward port of the 2.2.x improvements to ipconfig.c.
Especially support for DHCP.

Eric



diff -uNr linux-2.4.3/Documentation/Configure.help linux-2.4.3.ipdhcp/Documentation/Configure.help
--- linux-2.4.3/Documentation/Configure.help	Fri Apr 20 12:06:37 2001
+++ linux-2.4.3.ipdhcp/Documentation/Configure.help	Sun Apr 22 16:03:26 2001
@@ -3961,6 +3961,21 @@
   want to use BOOTP, a BOOTP server must be operating on your network.
   Read Documentation/nfsroot.txt for details.
 
+DHCP support
+CONFIG_IP_PNP_DHCP
+  If you want your Linux box to mount its whole root filesystem (the
+  one containing the directory /) from some other computer over the
+  net via NFS and you want the IP address of your computer to be
+  discovered automatically at boot time using the DHCP protocol (a
+  special protocol designed for doing this job), say Y here. In case
+  the boot ROM of your network card was designed for booting Linux and
+  does DHCP itself, providing all necessary information on the kernel
+  command line, you can say N here.
+
+  If unsure, say Y. Note that if you want to use DHCP, a DHCP server
+  must be operating on your network.  Read Documentation/nfsroot.txt
+  for details.
+
 RARP support
 CONFIG_IP_PNP_RARP
   If you want your Linux box to mount its whole root file system (the
diff -uNr linux-2.4.3/include/net/ipconfig.h linux-2.4.3.ipdhcp/include/net/ipconfig.h
--- linux-2.4.3/include/net/ipconfig.h	Mon Jan  4 16:31:35 1999
+++ linux-2.4.3.ipdhcp/include/net/ipconfig.h	Sun Apr 22 16:03:26 2001
@@ -6,16 +6,33 @@
  *  Automatic IP Layer Configuration
  */
 
-extern __u32 root_server_addr;
-extern u8 root_server_path[];
-extern u32 ic_myaddr;
-extern u32 ic_servaddr;
-extern u32 ic_gateway;
-extern u32 ic_netmask;
-extern int ic_enable;
-extern int ic_host_name_set;
-extern int ic_set_manually;
-extern int ic_proto_enabled;
+/* The following are initdata: */
 
-#define IC_BOOTP 1
-#define IC_RARP 2
+extern int ic_enable;		/* Enable or disable the whole shebang */
+
+extern int ic_proto_enabled;	/* Protocols enabled (see IC_xxx) */
+extern int ic_host_name_set;	/* Host name set by ipconfig? */
+extern int ic_set_manually;	/* IPconfig parameters set manually */
+
+extern u32 ic_myaddr;		/* My IP address */
+extern u32 ic_netmask;		/* Netmask for local subnet */
+extern u32 ic_gateway;		/* Gateway IP address */
+
+extern u32 ic_servaddr;		/* Boot server IP address */
+
+extern u32 root_server_addr;	/* Address of NFS server */
+extern u8 root_server_path[];	/* Path to mount as root */
+
+
+
+/* The following are persistent (not initdata): */
+
+extern int ic_proto_used;	/* Protocol used, if any */
+extern u32 ic_nameserver;	/* DNS server IP address */
+extern u8 ic_domain[];		/* DNS (not NIS) domain name */
+
+/* bits in ic_proto_{enabled,used} */
+#define IC_PROTO	0xFF	/* Protocols mask: */
+#define IC_BOOTP	0x01	/*   BOOTP (or DHCP, see below) */
+#define IC_RARP		0x02	/*   RARP */
+#define IC_USE_DHCP0x100	/* If on, use DHCP instead of BOOTP */
diff -uNr linux-2.4.3/net/ipv4/Config.in linux-2.4.3.ipdhcp/net/ipv4/Config.in
--- linux-2.4.3/net/ipv4/Config.in	Tue Nov  7 15:12:02 2000
+++ linux-2.4.3.ipdhcp/net/ipv4/Config.in	Sun Apr 22 16:03:26 2001
@@ -20,6 +20,7 @@
 fi
 bool '  IP: kernel level autoconfiguration' CONFIG_IP_PNP
 if [ "$CONFIG_IP_PNP" = "y" ]; then
+   bool 'IP: DHCP support' CONFIG_IP_PNP_DHCP
bool 'IP: BOOTP support' CONFIG_IP_PNP_BOOTP
bool 'IP: RARP support' CONFIG_IP_PNP_RARP
 # not yet ready..
diff -uNr linux-2.4.3/net/ipv4/ipconfig.c linux-2.4.3.ipdhcp/net/ipv4/ipconfig.c
--- linux-2.4.3/net/ipv4/ipconfig.c	Mon Mar 26 18:20:57 2001
+++ linux-2.4.3.ipdhcp/net/ipv4/ipconfig.c	Sun Apr 22 16:55:36 2001
@@ -1,10 +1,10 @@
 /*
  *  $Id: ipconfig.c,v 1.35 2000/12/30 06:46:36 davem Exp $
  *
- *  Automatic Configuration of IP -- use BOOTP or RARP or user-supplied
- *  information to configure own IP address and routes.
+ *  Automatic Configuration of IP -- use DHCP, BOOTP, RARP, or
+ *  user-supplied information to configure own IP address and routes.
  *
- *  Copyright (C) 1996--1998 Martin Mares <[EMAIL PROTECTED]>
+ *  Copyright (C) 1996-1998 Martin Mares <[EMAIL PROTECTED]>
  *
  *  Derived from network configuration code in fs/nfs/nfsroot.c,
  *  originally Copyright (C) 1995, 1996 Gero Kuhlmann and me.
@@ -16,6 +16,16 @@
  *  Fixed ip_auto_config_setup calling at startup in the new "Linker Magic"
  *  initialization scheme.
  *	- Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>, 08/11/1999
+ *
+ *  DHCP support added.  To users this looks like a whole separate
+ *  protocol, but we know it's just a bag on the side of BOOTP.
+ *		-- Chip Salzenberg <[EMAIL PROTECTED]>, May 2000
+ *
+ *  Ported DHCP support from 2.2.16 to 2.4.0-test4
+ *  -- Eric Biederman <[EMAIL PROTECTED]>, 30 Aug 2000
+ *
+ *  Merged changes from 2.2.19 into 2.4.3
+ *  -- Eric Biederman <[EMAIL PROTECTED]>, 22 April Aug 2001
  */
 
 #include 
@@ -36,6 +46,7 @@
 

Re: [PATCH] CONFIG_PPP_FILTER in -ac12 / -pre6

[Paul Mackerras]

Andrzej Krzysztofowicz writes:

> CONFIG_PPP_FILTER depends on CONFIG_FILTER (2.4.4-pre6, 2.4.3-ac12)
> [ sk_run_filter(), ...]
> So updated Config.in ...

> -   bool '  PPP filtering' CONFIG_PPP_FILTER
> +   dep_bool '  PPP filtering' CONFIG_PPP_FILTER $CONFIG_FILTER

Yep, definitely a good idea.  Thanks.

Paul.
-
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] Longstanding elf fix (2.4.3 fix)

[Eric W. Biederman]

A little while ago I was playing with building an elf self extracting
binary.  In doing so I discovered that the linux kernel does not
handle elf program headers with multiple BSS segments.

In building a patch for 2.4.3 I also discovered that we are not taking 
the mmap_sem around do_brk in the exec paths.

Attached is a patch that corrects, both of these problems.

Eric



diff -uNrX linux-exclude-files linux-2.4.3/arch/mips/kernel/irixelf.c linux-2.4.3.elf-fix2/arch/mips/kernel/irixelf.c
--- linux-2.4.3/arch/mips/kernel/irixelf.c	Fri Apr 20 12:06:40 2001
+++ linux-2.4.3.elf-fix2/arch/mips/kernel/irixelf.c	Sun Apr 22 17:00:28 2001
@@ -130,7 +130,9 @@
 	end = PAGE_ALIGN(end);
 	if (end <= start) 
 		return;
+	down_write(¤t->mm->mmap_sem);
 	do_brk(start, end - start);
+	up_write(¤t->mm->mmap_sem);
 }
 
 
@@ -379,7 +381,9 @@
 
 	/* Map the last of the bss segment */
 	if (last_bss > len) {
+		down_write(¤t->mm->mmap_sem);
 		do_brk(len, (last_bss - len));
+		up_write(¤t->mm->mmap_sem);
 	}
 	kfree(elf_phdata);
 
@@ -567,8 +571,10 @@
 	unsigned long v;
 	struct prda *pp;
 
+	down_write(¤t->mm->mmap_sem);
 	v =  do_brk (PRDA_ADDRESS, PAGE_SIZE);
-	
+	up_write(¤t->mm->mmap_sem);
+		
 	if (v < 0)
 		return;
 
@@ -858,8 +864,11 @@
 
 	len = (elf_phdata->p_filesz + elf_phdata->p_vaddr+ 0xfff) & 0xf000;
 	bss = elf_phdata->p_memsz + elf_phdata->p_vaddr;
-	if (bss > len)
-	  do_brk(len, bss-len);
+	if (bss > len) {
+		down_write(¤t->mm->mmap_sem);
+		do_brk(len, bss-len);
+		up_write(¤t->mm->mmap_sem);
+	}
 	kfree(elf_phdata);
 	return 0;
 }
diff -uNrX linux-exclude-files linux-2.4.3/arch/s390x/kernel/binfmt_elf32.c linux-2.4.3.elf-fix2/arch/s390x/kernel/binfmt_elf32.c
--- linux-2.4.3/arch/s390x/kernel/binfmt_elf32.c	Fri Apr 20 12:06:43 2001
+++ linux-2.4.3.elf-fix2/arch/s390x/kernel/binfmt_elf32.c	Sun Apr 22 17:00:28 2001
@@ -188,16 +188,29 @@
 static unsigned long
 elf_map32 (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int prot, int type)
 {
+	unsigned long start, data_len, mem_len, offset;
 	unsigned long map_addr;
 
 	if(!addr)
 		addr = 0x4000;
 
-	down_write(¤t->mm->mmap_sem);
-	map_addr = do_mmap(filep, ELF_PAGESTART(addr),
-			   eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr), prot, type,
-			   eppnt->p_offset - ELF_PAGEOFFSET(eppnt->p_vaddr));
-	up_write(¤t->mm->mmap_sem);
+	start = ELF_PAGESTART(addr);
+	data_len = ELF_PAGEALIGN(eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr));
+	mem_len = ELF_PAGEALIGN(eppnt->p_memsz + ELF_PAGEOFFSET(eppnt->p_vaddr));
+	offset = eppnt->p_offset - ELF_PAGEOFFSET(eppnt->p_vaddr);
+
+	if (eppnt->p_filesz) {
+		down_write(¤t->mm->mmap_sem);
+		map_addr = do_mmap(filep, start, data_len, prot, type, offset);
+		do_mmap(NULL, map_addr + data_len, mem_len - data_len, prot,
+			MAP_FIXED | MAP_PRIVATE, 0);
+		up_write(¤t->mm->mmap_sem);
+		padzero(map_addr + eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr));
+	} else {
+		down_write(¤t->mm->mmap_sem);
+		map_addr = do_mmap(NULL, start, mem_len, prot, MAP_PRIVATE, 0);
+		up_write(¤t->mm->mmap_sem);
+	}
 	return(map_addr);
 }
 
diff -uNrX linux-exclude-files linux-2.4.3/arch/sparc64/kernel/binfmt_aout32.c linux-2.4.3.elf-fix2/arch/sparc64/kernel/binfmt_aout32.c
--- linux-2.4.3/arch/sparc64/kernel/binfmt_aout32.c	Fri Apr 20 12:06:44 2001
+++ linux-2.4.3.elf-fix2/arch/sparc64/kernel/binfmt_aout32.c	Sun Apr 22 17:00:28 2001
@@ -49,7 +49,9 @@
 	end = PAGE_ALIGN(end);
 	if (end <= start)
 		return;
+	down_write(¤t->mm->mmap_sem);
 	do_brk(start, end - start);
+	up_write(¤t->mm->mmap_sem);
 }
 
 /*
@@ -245,10 +247,17 @@
 	if (N_MAGIC(ex) == NMAGIC) {
 		loff_t pos = fd_offset;
 		/* Fuck me plenty... */
+		down_write(¤t->mm->mmap_sem);
 		error = do_brk(N_TXTADDR(ex), ex.a_text);
+		up_write(¤t->mm->mmap_sem);
+
 		bprm->file->f_op->read(bprm->file, (char *) N_TXTADDR(ex),
 			  ex.a_text, &pos);
+
+		down_write(¤t->mm->mmap_sem);
 		error = do_brk(N_DATADDR(ex), ex.a_data);
+		up_write(¤t->mm->mmap_sem);
+
 		bprm->file->f_op->read(bprm->file, (char *) N_DATADDR(ex),
 			  ex.a_data, &pos);
 		goto beyond_if;
@@ -256,8 +265,10 @@
 
 	if (N_MAGIC(ex) == OMAGIC) {
 		loff_t pos = fd_offset;
+		down_write(¤t->mm->mmap_sem);
 		do_brk(N_TXTADDR(ex) & PAGE_MASK,
 			ex.a_text+ex.a_data + PAGE_SIZE - 1);
+		up_write(¤t->mm->mmap_sem);
 		bprm->file->f_op->read(bprm->file, (char *) N_TXTADDR(ex),
 			  ex.a_text+ex.a_data, &pos);
 	} else {
@@ -271,7 +282,9 @@
 
 		if (!bprm->file->f_op->mmap) {
 			loff_t pos = fd_offset;
+			down_write(¤t->mm->mmap_sem);
 			do_brk(0, ex.a_text+ex.a_data);
+			up_write(¤t->mm->mmap_sem);
 			bprm->file->f_op->read(bprm->file,(char *)N_TXTADDR(ex),
   ex.a_text+ex.a_data, &pos);
 			goto beyond_if;
@@ -382,7 +395,9 @@
 	len = PAGE_ALIGN(ex.a_text + ex.a_data);
 	bss = ex.a_text + ex.a_data + ex.a_bss;
 	if (bss > len) {
+		down_write(¤t->mm->mmap_sem);
 		error = do_brk(start_addr + len, bss - len);
+		up_write(¤t->mm->mmap_sem);
 		retval = error;
 		if (error != start_

[PATCH] Longstanding elf fix (2.2.19 fix)

[Eric W. Biederman]

A little while ago I was playing with building an elf self extracting
binary.  In doing so I discovered that the linux kernel does not
handle elf program headers with multiple BSS segments.

Eric



Binary files linux-2.2.19/drivers/char/conmakehash and linux-2.2.19.elf-fix/drivers/char/conmakehash differ
Binary files linux-2.2.19/drivers/char/hfmodem/gentbl and linux-2.2.19.elf-fix/drivers/char/hfmodem/gentbl differ
diff -uNrX linux-exclude-files linux-2.2.19/fs/binfmt_elf.c linux-2.2.19.elf-fix/fs/binfmt_elf.c
--- linux-2.2.19/fs/binfmt_elf.c	Fri Apr 20 13:25:11 2001
+++ linux-2.2.19.elf-fix/fs/binfmt_elf.c	Sun Apr 22 17:55:42 2001
@@ -71,18 +71,6 @@
 #endif
 };
 
-static void set_brk(unsigned long start, unsigned long end)
-{
-	start = ELF_PAGEALIGN(start);
-	end = ELF_PAGEALIGN(end);
-	if (end <= start)
-		return;
-	do_mmap(NULL, start, end - start,
-		PROT_READ | PROT_WRITE | PROT_EXEC,
-		MAP_FIXED | MAP_PRIVATE, 0);
-}
-
-
 /* We need to explicitly zero any fractional pages
after the data section (i.e. bss).  This would
contain the junk from the file that should not
@@ -213,6 +201,28 @@
 	return sp;
 }
 
+static inline unsigned long
+elf_map (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int prot, int type)
+{
+	unsigned long start, data_len, mem_len, offset;
+	unsigned long map_addr;
+
+	start = ELF_PAGESTART(addr);
+	data_len = ELF_PAGEALIGN(eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr));
+	mem_len = ELF_PAGEALIGN(eppnt->p_memsz + ELF_PAGEOFFSET(eppnt->p_vaddr));
+	offset = eppnt->p_offset - ELF_PAGEOFFSET(eppnt->p_vaddr);
+	
+	if (eppnt->p_filesz) {
+		map_addr = do_mmap(filep, start, data_len, prot, type, offset);
+		do_mmap(NULL, map_addr + data_len, mem_len - data_len, prot,
+			MAP_FIXED | MAP_PRIVATE, 0);
+		padzero(map_addr + eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr));
+	} else {
+		map_addr = do_mmap(NULL, start, mem_len, prot, MAP_PRIVATE, 0);
+	}
+	return(map_addr);
+}
+
 
 /* This is much more generalized than the library routine read function,
so we keep this separate.  Technically the library read function
@@ -293,12 +303,7 @@
 #endif
 	}
 
-	map_addr = do_mmap(file,
-			load_addr + ELF_PAGESTART(vaddr),
-			eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr),
-			elf_prot,
-			elf_type,
-			eppnt->p_offset - ELF_PAGEOFFSET(eppnt->p_vaddr));
+	map_addr = elf_map(file, load_addr + vaddr, eppnt, elf_prot, elf_type);
 	if (map_addr > -1024UL) /* Real error */
 		goto out_close;
 
@@ -325,23 +330,6 @@
 	  }
 	}
 
-	/* Now use mmap to map the library into memory. */
-
-	/*
-	 * Now fill out the bss section.  First pad the last page up
-	 * to the page boundary, and then perform a mmap to make sure
-	 * that there are zero-mapped pages up to and including the 
-	 * last bss page.
-	 */
-	padzero(elf_bss);
-	elf_bss = ELF_PAGESTART(elf_bss + ELF_EXEC_PAGESIZE - 1); /* What we have mapped so far */
-
-	/* Map the last of the bss segment */
-	if (last_bss > elf_bss)
-		do_mmap(NULL, elf_bss, last_bss - elf_bss,
-			PROT_READ|PROT_WRITE|PROT_EXEC,
-			MAP_FIXED|MAP_PRIVATE, 0);
-
 	*interp_load_addr = load_addr;
 	/*
 	 * AUDIT: is everything deallocated properly if this happens
@@ -660,12 +648,7 @@
 		if (elf_ex.e_type == ET_EXEC || load_addr_set) {
 			elf_flags |= MAP_FIXED;
 		}
-
-		error = do_mmap(file, ELF_PAGESTART(load_bias + vaddr),
-		(elf_ppnt->p_filesz +
-		ELF_PAGEOFFSET(elf_ppnt->p_vaddr)),
-		elf_prot, elf_flags, (elf_ppnt->p_offset -
-		ELF_PAGEOFFSET(elf_ppnt->p_vaddr)));
+		error = elf_map(file, load_bias + vaddr, elf_ppnt, elf_prot, elf_flags);
 
 		if (!load_addr_set) {
 			load_addr_set = 1;
@@ -760,13 +743,6 @@
 	current->mm->start_code = start_code;
 	current->mm->end_data = end_data;
 	current->mm->start_stack = bprm->p;
-
-	/* Calling set_brk effectively mmaps the pages that we need
-	 * for the bss and break sections
-	 */
-	set_brk(elf_bss, elf_brk);
-
-	padzero(elf_bss);
 
 #if 0
 	printk("(start_brk) %x\n" , current->mm->start_brk);

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Horst von Brand <[EMAIL PROTECTED]>:
> Then explain to everybody here in a language they'll understand _what_ is
> wrong and _why_. Then propose a solution.

I'm on it.  You'll see the results fairly shortly.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Strict gun laws are about as effective as strict drug laws...It pains
me to say this, but the NRA seems to be right: The cities and states
that have the toughest gun laws have the most murder and mayhem.
-- Mike Royko, Chicago Tribune
-
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: Request for comment -- a better attribution system

[Horst von Brand]

"Eric S. Raymond" <[EMAIL PROTECTED]> said:
> Alexander Viro <[EMAIL PROTECTED]>:
> > Eric, it would save everyone a lot of time if you actually cared to
> > pull your head out of your... theoretical constructions and spent
> > some efforts figuring out how the things really work.
> 
> I've had my nose rubbed in how things really work.  That's why I want to
> fix the things that are broken about how things really work.

Then explain to everybody here in a language they'll understand _what_ is
wrong and _why_. Then propose a solution. I for one am not convinced you
have a "what", let alone a "why". And AFAIKS your solution will be an
enormous burden to maintain if it is not to rot away in a very short time.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
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/

error in Menuconfig

[J. Liu]

Q> scripts/Menuconfig: MCmenu39: command not found
 
Please report this to the maintainer <[EMAIL PROTECTED]>.  You may also
send a problem report to <[EMAIL PROTECTED]>.
 
Please indicate the kernel version you are trying to configure and
which menu you were trying to enter when this error occurred.
 
make: *** [menuconfig] Error 1


SuSE Linux 7.1 Professional, Kernel 2.2.18

I got this error message when I was trying to add ACL patch to the kernel.


-
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] rw_semaphores, optimisations

[D . W . Howells]

Hello Andrea,

Interesting benchmarks... did you compile the test programs with "make 
SCHED=yes" by any chance? Also what other software are you running?

The reason I ask is that running a full blown KDE setup running in the 
background, I get the following numbers on the rwsem-ro test (XADD optimised 
kernel):

SCHED: 4615646, 4530769, 4534453 and 4628365
no SCHED: 6311620, 6312776, 6327772 and 6325508

Also quite stable as you can see.

> (ah and btw the machine is a 2-way PII 450mhz). 

Your numbers were "4274607" and "4280280" for this kernel and test This I 
find a little suprising. I'd expect them to be about 10% higher than I get on 
my machine given your faster CPUs.

What compiler are you using? I'm using the following:

   Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
   gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-80)

Something else that I noticed: Playing a music CD appears to improve the 
benchmarks all round:-) Must be some interrupt effect of some sort, or maybe 
they just like the music...

> rwsem-2.4.4-pre6 + my new generic rwsem (fast path in C inlined)

Linus wants out of line generic code only, I believe. Hence why I made my 
generic code out of line.

I have noticed one glaring potential slowdown in my generic code's down 
functions. I've got the following in _both_ fastpaths!:

struct task_struct *tsk = current;

It shouldn't hurt _too_ much (its only reg->reg anyway), but it will have an 
effect. I'll have to move it and post another patch tomorrow.

I've also been comparing the assembly from the two generic spinlock 
implementations (having out-of-lined yours in what I think is the you'd have 
done it). I've noticed a number of things:

  (1) My fastpaths have slightly fewer instructions in them

  (2) gcc-2.96-2731 produces what looks like much less efficient code
  than gcc-snapshot-20010409 (to be expected, I suppose).

  (3) Both compilers do insane things to registers (like in one instruction
  moving %eax to %edx and then moving it back again in the next).

  (4) If _any_ inline assembly is used, the compiler grabs extra chunks of
  stack which it does not then use. It will then pop these into registers
  under some circumstances. It'll also save random registers it doesn't
  clobber under others.

(Basically, I had a lot of frustrating fun playing around with the spinlock 
asm constraints trying to avoid the compiler clobbering registers 
unnecessarily because of them).

I've attached the source file I've been playing with and an example 
disassembly dump for your amusement. I used the snapshot gcc to do this (it 
emits conditional chunks of code out of line more intelligently than the 
older one.

It's also interesting that your generic out-of-line semaphores are faster 
given the fact that you muck around with EFLAGS and CLI/STI, and I don't. 
Maybe I'm getting hit by an interrupt. I'll have to play around with it and 
benchmark it again.

David


/* slowpath.c: description
 *
 * Copyright (c) 2001   David Howells ([EMAIL PROTECTED]).
 */
#define __KERNEL__
#include 
#include 
#include 
#include 
#include 
#include 

struct rw_semaphore_dwh {
	__u32			active;
	__u32			waiting;
	spinlock_t		wait_lock;
};

extern void FASTCALL(dwh_down_read(struct rw_semaphore_dwh *));
extern void FASTCALL(dwh_up_read(struct rw_semaphore_dwh *));
extern void FASTCALL(dwh_down_read_failed(struct rw_semaphore_dwh *,
	  struct task_struct *));
extern void FASTCALL(dwh__rwsem_do_wake(struct rw_semaphore_dwh *));

struct rw_semaphore_aa {
	spinlock_t lock;
	int count;
	struct list_head wait;
};

#define RWSEM_WAITQUEUE_READ 0

extern void FASTCALL(aa_down_read(struct rw_semaphore_aa *));
extern void FASTCALL(aa_up_read(struct rw_semaphore_aa *));
extern void FASTCALL(aa_down_failed(struct rw_semaphore_aa *, int));
extern void FASTCALL(aa_rwsem_wake(struct rw_semaphore_aa *));

void dwh_down_read(struct rw_semaphore_dwh *sem)
{
	struct task_struct *tsk = current;
	spin_lock(&sem->wait_lock);

	if (sem->waiting) {
		sem->active++;
		spin_unlock(&sem->wait_lock);
		goto out;
	}
	sem->waiting++;
	dwh_down_read_failed(sem,tsk);
	spin_unlock(&sem->wait_lock);
 out:
}

void aa_down_read(struct rw_semaphore_aa *sem)
{
	spin_lock_irq(&sem->lock);
	if (sem->count < 0 || !list_empty(&sem->wait))
		goto slow_path;
	sem->count++;
 out:
	spin_unlock_irq(&sem->lock);
	return;

 slow_path:
	aa_down_failed(sem, RWSEM_WAITQUEUE_READ);
	goto out;
}

void dwh_up_read(struct rw_semaphore_dwh *sem)
{
	spin_lock(&sem->wait_lock);

	if (--sem->active==0 && sem->waiting)
		dwh__rwsem_do_wake(sem);

	spin_unlock(&sem->wait_lock);
}

void aa_up_read(struct rw_semaphore_aa *sem)
{
	unsigned long flags;

	spin_lock_irqsave(&sem->lock, flags);
	if (!--sem->count && !list_empty(&sem->wait))
		aa_rwsem_wake(sem);
	spin_unlock_irqrestore(&sem->lock, flags);
}



slowpath.o: file format elf32-i386

Disassembly of section .text:

 :
   0:   53 

Re: Linux 2.4.3-ac12

[Mr. James W. Laferriere]

Hello Alan ,  To whom is this attributed ?  Tia ,  JimL

On Sun, 22 Apr 2001, Alan Cox wrote:
> o Hopefully fix bugtraq reported netfilter ftp
>   flaw
   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

-
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/

Compile problem with 2.4.4-pre6 (net_pcmcia.o not found in link)

[Ben Greear]

If I configure PCMCIA out of the build, the build will not link,
because the linker is still looking for the net_pcmcia.o file.

If I say yes for PCMCIA and enable a single module, it works.

compile configuration available if someone would like to see it.

Thanks,
Ben

-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
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: question on atomic_t

[Matthew Wilcox]

> can I assume that a member of a structure of type atomic_t is 0 after
> using memset to zero on the structure ?

You must not do this.  use atomic_init instead.  on parisc, the locked value
of a spinlock is 0, so no more updates to that atomic value would ever work.

-- 
Revolutions do not require corporate support.
-
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/

question on atomic_t

[Oliver Neukum]

Hi list,

can I assume that a member of a structure of type atomic_t is 0 after using 
memset to zero on the structure ?

TIA
Oliver
-
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] CONFIG_PPP_FILTER in -ac12 / -pre6

[Andrzej Krzysztofowicz]

Hi,

CONFIG_PPP_FILTER depends on CONFIG_FILTER (2.4.4-pre6, 2.4.3-ac12)
[ sk_run_filter(), ...]
So updated Config.in ...

Andrzej

diff -ur drivers/net/Config.in.old drivers/net/Config.in
--- drivers/net/Config.in.old   Sun Apr 22 14:48:51 2001
+++ drivers/net/Config.in   Sun Apr 22 16:24:10 2001
@@ -227,7 +227,7 @@
 tristate 'PPP (point-to-point protocol) support' CONFIG_PPP
 if [ ! "$CONFIG_PPP" = "n" ]; then
dep_bool '  PPP multilink support (EXPERIMENTAL)' CONFIG_PPP_MULTILINK 
$CONFIG_EXPERIMENTAL
-   bool '  PPP filtering' CONFIG_PPP_FILTER
+   dep_bool '  PPP filtering' CONFIG_PPP_FILTER $CONFIG_FILTER
dep_tristate '  PPP support for async serial ports' CONFIG_PPP_ASYNC $CONFIG_PPP
dep_tristate '  PPP support for sync tty ports' CONFIG_PPP_SYNC_TTY $CONFIG_PPP
dep_tristate '  PPP Deflate compression' CONFIG_PPP_DEFLATE $CONFIG_PPP


-- 
===
  Andrzej M. Krzysztofowicz   [EMAIL PROTECTED]
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk
-
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] cmsfs 2.4.3-ac12 compile fix

[Andrzej Krzysztofowicz]

Hi,

cmsfs does not compile without this fix.

Andrzej

diff -ur linux-2.4.3-ac12/fs/cmsfs/cmsfsvfs.c linux/fs/cmsfs/cmsfsvfs.c
--- linux-2.4.3-ac12/fs/cmsfs/cmsfsvfs.cSun Apr 22 14:48:52 2001
+++ linux/fs/cmsfs/cmsfsvfs.c   Sun Apr 22 16:18:40 2001
@@ -26,6 +26,7 @@
 #include
 #include
 #include   
+#include   
 
 #include
  


-- 
===
  Andrzej M. Krzysztofowicz   [EMAIL PROTECTED]
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk
-
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: Architecture-specific include files

[Jeff Dike]

[EMAIL PROTECTED] said:
> Would anyone have a problem with this change? 

UML already has a arch/um/include for private headers that the rest of the 
kernel is not allowed to see.

It would mean moving it, which is not a big deal.

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/

Pcmcia-Updates for Xircomcards?

[Waldemar Brodkorb]

Hello David Hinds, Hello Kernelhackers,

sorry that I also directly contact you. 
But I'am very confused, at the moment.

My Hardware: 
Toshiba Satellite Pro 4280 
PCMCIA: Xircom RBEM56G-100 

When I use SuSE 7.1 and Kernel 2.4.2 (SuSE) the card 
is recognized and network works, also configured via DHCP.
(tulib_cb,serial_cb , perhaps from pcmcia-cs )

But now I want to use Kernel 2.4.3-ac12, because of the 
new module, which I've heard/read is better than the old drivers.

O.K., here what I done:
build yenta_socket,xircom_cb,serial_cs,pcmcia_core,..

Modified /etc/pcmcia/config:
device "xircom_cb"
  class "network" module "cb_enabler", "xircom_cb"

card "Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem"
  manfid 0x0105, 0x0103
  bind "xircom_cb" to 0, "serial_cs" to 1

Linus said serial_cs is for both, old serial_cb & serial_cs.

But when I start the notebook with the same /etc/init.d/pcmcia
I get this:
Apr 22 21:34:36 T50179768G kernel: PCI: Enabling device 14:00.1
( -> 0003)
Apr 22 21:34:36 T50179768G cardmgr[206]: initializing socket 0
Apr 22 21:34:36 T50179768G cardmgr[206]: socket 0: Xircom
CBEM56G-100 CardBus 10
/100 Ethernet + 56K Modem
Apr 22 21:34:36 T50179768G cardmgr[206]: executing: 'modprobe
cb_enabler'
Apr 22 21:34:36 T50179768G cardmgr[206]: executing: 'modprobe
xircom_cb'
Apr 22 21:34:36 T50179768G kernel: PCI: Setting latency timer of
device 14:00.0
to 64
Apr 22 21:34:36 T50179768G kernel: eth0: Xircom cardbus revision 3
at irq 11
Apr 22 21:34:36 T50179768G cardmgr[206]: executing: 'modprobe
serial_cs'
Apr 22 21:34:36 T50179768G kernel: Serial driver version 5.05a
(2001-03-20) with
 MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
 Apr 22 21:34:36 T50179768G kernel: ttyS00 at 0x03f8 (irq = 4) is a
 16550A
 Apr 22 21:34:36 T50179768G cardmgr[206]: executing: './network
 start xircom_cb'
 Apr 22 21:34:36 T50179768G kernel: serial_cs: ParseTuple: No more
 items
 Apr 22 21:34:36 T50179768G cardmgr[206]: + xircom_cb: error
 fetching interface i
 nformation: Device not found
 Apr 22 21:34:37 T50179768G cardmgr[206]: + /sbin/ifconfig xircom_cb
 up
 Apr 22 21:34:37 T50179768G cardmgr[206]: + xircom_cb: unknown
 interface: No such
  device
  Apr 22 21:34:37 T50179768G dhcpcd[1115]: dhcpStart: ioctl
  SIOCGIFHWADDR: No such
   device
   Apr 22 21:34:37 T50179768G cardmgr[206]: + /sbin/dhcpcd
   xircom_cb >/dev/null 2>
   &1
   Apr 22 21:34:37 T50179768G cardmgr[206]: executing: './serial
   start xircom_cb'
   Apr 22 21:34:37 T50179768G cardmgr[206]: + expr: syntax error
   Apr 22 21:34:37 T50179768G cardmgr[206]: + ./MAKEDEV xircom_cb
   Apr 22 21:34:37 T50179768G cardmgr[206]: + ./serial: ./MAKEDEV:
   No such file or
   directory
   Apr 22 21:34:37 T50179768G cardmgr[206]: + /dev/xircom_cb: No
   such file or direc
   tory


It is possible I missed something essential?

More information added below.

Would it a good idea to split pcmcia-cs package?
One for use with kernel 2.4, without client-modules
and one for kernel 2.2.x with all modules? 
Because of the different names and modules ?

-
pcmcia-cs 3.1.22 & 3.1.25 (same problem, cardmgr have the same
version number)

What to do?

thanks for any hints or help.

bye
Waldemar 

-- 
* A good website for linuxsoftware:|  (o_  *
*   http://www.freshmeat.net   |  //\  *
*   Linux rulez!;-)|  V_/_ *
* GnuPG-Key: 0xBE21BD90 | Tux: #155220 | ICQ: 64035650 *




00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, medium devsel, latency 64
Memory at e000 (32-bit, prefetchable) [size=128M]
Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 
(prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
Memory behind bridge: f000-f7ff

00:05.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
Flags: bus master, medium devsel, latency 0

00:05.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 
[Master])
Flags: bus master, medium devsel, latency 64
I/O ports at fff0 [size=16]

00:05.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 
[UHCI])
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at ff80 [size=32]

00:05.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03)
Flags: medium devsel, IRQ 9

00:07.0 Communication controller: Lucent Microelectronics 56k WinModem (rev 01)
Subsystem: Toshiba America Info Systems Internal V.90 Modem
Flags: bus master, medium devsel, latency 0, IRQ 3
Memory at ffefff00 (32-bit, non-prefetchable) [size=256]
I/O ports at 02f8 [size=8]
I/O ports at 1c00 [size=256]
Cap

Re: BUG: Global FPU corruption in 2.2

[kees]

Hello,

Linux 2.2.19 SMP, confirm report. Even games are going weird after
running this test, (my wife is complaining :-))

Have to reboot.

Kees


-
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: performance degradation on -ac tree

[J Sloan]

There is a bit more clarity on the performance degradation
issue now - In fact the degradation only appears when
using iptables. It's just that sometime shortly after 2.4.2,
the hit imposed by iptables got worse.

For instance:

netperf results  without iptables   with iptables
-
2.4.2 400 MB/s  330 MB/s
2.4.3-ac10400 MB/s  250 MB/s


BTW, the stock seawolf kernel gets the highest netperf
results ever seen on this box, around 450 MB/sec,
but with iptables or ipchains module loaded, it falls to
about 270 MB/sec.

Just a data point fyi -

cu

jjs



-
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: Request for comment -- a better attribution system

[Olaf Titz]

>   * you've ignored the robustness of design behind the UNIX kernel.
> These beasts keep going without falling apart even after serious injuries.

Do you mean design or operation? In fact UNIX design has a number of
serious errors/problems, we just have gotten accustomed to it so much
that we don't care any more. Here the robustness is in fact inertia.

Robust operation is possible with any halfway cleanly designed system,
cf. VMS.

Olaf
-
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: APIC-Errors+Crashes on GA 586DX, 2.2.17/2.4.3

[Ingo Oeser]

On Sun, Apr 22, 2001 at 11:22:24AM +0200, Hermann Himmelbauer wrote:
> Karsten Keil wrote:
> > 
> > I have here the same board with 2*233 MMX and don't see this kind of ISDN
> > error on recent 2.2 kernels, but got also lot of APIC errors with the
> > 2.3/2.4, because the APIC errors are only reported in 2.3/4.
> 
> Right - same behavior here, no APIC errors with 2.2 (as they are not
> reported). The ISDN error happens very seldom (4 times last year) and is
> not reproducable - which is not so with the eth0 errors (as eth0 locks
> at around 500-1000MB while copying data).

I had a similar problem, but with less RAM than you have, I think.
And it hung the whole machine that heavy, that not even SysRq was
responding.

On that machine I had no swap installed and only 64MB of RAM.
Adding just another 64MB of RAM made it go away.

This might be an VM-skb-interaction-issue, but I saw no solution
so far.

The problem persistent with several processor (Cyrix III, Intel
Pentium (MXX), AMD Duron), several Chipsets (VIA-598, Intel BX)
and 3 different NICs (Realtek 8139, 3c509TX, Ether Express Pro)
and only under 100MBit.

I could copy MANY files (smb, scp, ftp), but ONE single file with
about 60MB or more (I tried to receive ISO images) killed the
machine. The behavior was also very random. Twice I got a
panic, but had problems writing it down due to the screen
darkening because of APM or setting "reboot on panic" :-(

Just FYI.

I don't know, why adding 64MB made it go away. I tried very hard
to reproduce it with 128MB, but really couldn't :-(

Regards 

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
  been there and had much fun   
-
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/

Architecture-specific include files

[Matthew Wilcox]

Something which came up in one of the hallway discussions at the
kernelsummit was that a lot of the architecture maintainers would find
it more convenient if the arch-specific header files were moved from
include/asm-$ARCH to arch/$ARCH/include.  Since we use a symlink _anyway_,
no global changes to include statements are necessary, we'd merely need
to change Makefile from

symlinks:
rm -f include/asm
( cd include ; ln -sf asm-$(ARCH) asm)

to

symlinks:
rm -f include/asm
( cd include ; ln -sf ../arch/$(ARCH)/include asm)

Would anyone have a problem with this change?  It'll make for a hell
of a big patch from Linus, but it really will simplify the lives of the
architecture maintainers.

-- 
Revolutions do not require corporate support.
-
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 2.4.3-ac12

[J . A . Magallon]

On 04.22 Dieter Nützel wrote:
> > My belief however is that several million people have gcc 2.96-69+, about 50
> > are likely to have random cvs snapshots and none of them are going to build
> > kernels with them anyway, as they wont work __builtin_expect or otherwise.
> >
> > Alan
> 
> I will not add fuel to the fire, but isn't 2.4.XX the "stable" version?
> And I think most people (here in Europe :-) are running 2.95.2 at the moment.
> But, yes the previously patches fixed it.
> 

That's going to change in a few weeks, I suspect. Dunno about SuSE, but just
released Mandrake 8.0 and RedHat 7.1 ship gcc-2.96.

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.3-ac12 #1 SMP Sun Apr 22 10:27:22 CEST 2001 i686

-
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: ide dma in /proc/dma

[Steven Walter]

On Sun, Apr 22, 2001 at 01:53:59PM +0200, [EMAIL PROTECTED] wrote:
> Hi!
> 
> why doesnt the dma for ide disks show up in /proc/dma?
> 
> heineken:~# hdparm -d /dev/discs/disc0/disc 
> /dev/discs/disc0/disc:
>  using_dma=  1 (on)
> 
> heineken:~# cat /proc/dma 
>  4: cascade

I suspect this is because only ISA DMA's are listed in /proc/dma, and
your IDE controller is likely PCI.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
-
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/

2.2.19: inconsistency between sys_utime and sys_utimes

[Kai Großjohann]

In fs/open.c I see the following code in sys_utime in case the struct
utimbuf * is NULL:

if (current->fsuid != inode->i_uid &&
(error = permission(inode,MAY_WRITE)) != 0)
goto dput_and_out;

In sys_utimes, there is a similar piece of code in case the struct
timeval * is NULL:

if ((error = permission(inode,MAY_WRITE)) != 0)
goto dput_and_out;

Is this intentional?

I'm very much a newbie with respect to the kernel internals, but I
observe the following behavior: calling `touch' on my own file on an
NFS mounted directory works nicely.  However, if I don't own the file,
only have write permissions to it and the containing directory due to
being in the right group and the file (and directory) having g+w
permissions, then I see this:

/
| grossjoh@lucy> strace touch xxirql.bbl
| execve("/usr/bin/touch", ["touch", "xxirql.bbl"], [/* 86 vars */]) = 0
| brk(0)  = 0x804e5c8
| open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
| open("/usr/sw/pilot/null.0/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such 
|file or directory)
| stat("/usr/sw/pilot/null.0/lib/i686/mmx", 0xbfffe6e4) = -1 ENOENT (No such file or 
|directory)
| open("/usr/sw/pilot/null.0/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file 
|or directory)
| stat("/usr/sw/pilot/null.0/lib/i686", 0xbfffe6e4) = -1 ENOENT (No such file or 
|directory)
| open("/usr/sw/pilot/null.0/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file 
|or directory)
| stat("/usr/sw/pilot/null.0/lib/mmx", 0xbfffe6e4) = -1 ENOENT (No such file or 
|directory)
| open("/usr/sw/pilot/null.0/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or 
|directory)
| stat("/usr/sw/pilot/null.0/lib", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
| open("i686/mmx/libc.so.6", O_RDONLY)= -1 ENOENT (No such file or directory)
| open("i686/libc.so.6", O_RDONLY)= -1 ENOENT (No such file or directory)
| open("mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
| open("libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
| open("/etc/ld.so.cache", O_RDONLY)  = 3
| fstat(3, {st_mode=S_IFREG|0644, st_size=24988, ...}) = 0
| old_mmap(NULL, 24988, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
| close(3)= 0
| open("/lib/libc.so.6", O_RDONLY)= 3
| fstat(3, {st_mode=S_IFREG|0755, st_size=887712, ...}) = 0
| read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\244\213"..., 4096) = 4096
| old_mmap(NULL, 902044, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001b000
| mprotect(0x400f, 29596, PROT_NONE)  = 0
| old_mmap(0x400f, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xd4000) 
|= 0x400f
| old_mmap(0x400f4000, 13212, PROT_READ|PROT_WRITE, 
|MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400f4000
| close(3)= 0
| old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
|0x400f8000
| munmap(0x40014000, 24988)   = 0
| getpid()= 25522
| brk(0)  = 0x804e5c8
| brk(0x804e600)  = 0x804e600
| brk(0x804f000)  = 0x804f000
| open("xxirql.bbl", O_WRONLY|O_CREAT|0x8000, 0666) = 3
| close(3)= 0
| utime("xxirql.bbl", NULL)   = -1 EPERM (Operation not permitted)
| write(2, "touch: ", 7touch: )  = 7
| write(2, "xxirql.bbl", 10xxirql.bbl)  = 10
| write(2, ": Operation not permitted", 25: Operation not permitted) = 25
| write(2, "\n", 1
| )   = 1
| _exit(1)= ?
\

Note how utime tells me the operation is not permitted, yet:

/
| grossjoh@lucy> ls -ld . xxirql.bbl
| drwxrws---4 fuhr crew 1024 Apr 20 19:08 .
| -rw-rw1 fuhr crew 5081 Mar 30 16:42 xxirql.bbl
| grossjoh@lucy> groups
| crew dialout floppy medoc cyclades mind teaching exam secware system software 
|cvs_rcp ncstrl bibdb research wwwadm carmen daffodil
\

... I can write to the file because I'm in the right group.

This behavior seems counter-intuitive.

Thanks,
kai
-- 
The passive voice should never be used.
-
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: ide-cs module name mismatch.

[Arjan van de Ven]

In article <[EMAIL PROTECTED]> you wrote:

> The kernel module is called ide-cs while the pcmcia-cs package
> looks for ide_cs. I'm not sure which should be corrected...
 
pcmcia-cs I'd say.
-
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/

ide-cs module name mismatch.

[rui.sousa]

Hi,

I'm using kernel-2.4.3 and pcmcia-cs-3.1.25.

The kernel module is called ide-cs while the pcmcia-cs package
looks for ide_cs. I'm not sure which should be corrected...

Rui Sousa

-
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] rw_semaphores, optimisations

[Andrea Arcangeli]

On Sun, Apr 22, 2001 at 09:07:03PM +0200, Andrea Arcangeli wrote:
> On Sun, Apr 22, 2001 at 01:27:20AM +0100, D . W . Howells wrote:

btw, I noticed I answered your previous email but for my benchmarks I really
used your latest #try2 posted today at 13 (not last night a 1am), just to avoid
mistakes this is the the md5sum of the patch I applied on top of pre6:

510c05d168c2b60e0d9c804381579b51  rwsem.diff

Andrea
-
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] rw_semaphores, optimisations

[Andrea Arcangeli]

On Sun, Apr 22, 2001 at 01:27:20AM +0100, D . W . Howells wrote:
> This patch (made against linux-2.4.4-pre6) makes a number of changes to the
> rwsem implementation:
> 
>  (1) Fixes a subtle contention bug between up_write and the down_* functions.
> 
>  (2) Optimises the i386 fastpath implementation and changed the slowpath
>  implementation to aid it.
>  - The arch/i386/lib/rwsem.c is now gone.
>  - Better inline asm constraints have been applied.
> 
>  (3) Changed the sparc64 fastpath implementation to use revised slowpath
>  interface.
>  [Dave Miller: can you check this please]
> 
>  (4) Makes the generic spinlock implementation non-inline.
>  - lib/rwsem.c has been duplicated to lib/rwsem-spinlock.c and a
>slightly different algorithm has been created. This one is simpler
>since it does not have to use atomic operations on the counters as
>all accesses to them are governed by a blanket spinlock.

I finally finished dropping the list_empty() check from my generic rwsemaphores.

The new behaviour of my rwsemaphores are:

-   max sleepers and max simultanous readers both downgraded to 
2^(BITS_PER_LONG>>1) for
higher performance in the fast path
-   up_* cannot be recalled from irq/softirq context anymore

I'm using this your latest patch on top of vanilla 2.4.4-pre6 to benchmark my
new generic rwsemaphores against yours.

To benchmark I'm using your tar.gz but I left my 50 seconds run of the rwtest
with many more readers and writers to stress it a bit more (I posted the
changes to the rwsem-rw.c test in the message where I reported the race in your
semaphores before pre6).

Here the results (I did two tries for every bench and btw the numbers are
quite stable as you can see).

rwsem-2.4.4-pre6 + my new generic rwsem (fast path in C inlined)

rw

reads taken: 6499121
writes taken: 3355701
reads taken: 6413447
writes taken: 3311328

r1

reads taken: 15218540
reads taken: 15203915

r2

reads taken: 5087253
reads taken: 5099084

ro

reads taken: 4274607
reads taken: 4280280

w1

writes taken: 14723159
writes taken: 14708296

wo

writes taken: 1778713
writes taken: 1776248

--
rwsem-2.4.4-pre6 + my new generic rwsem with fast path out of line (fast path in C out 
of line)

rw

reads taken: 6116063
writes taken: 3157816
reads taken: 6248542
writes taken: 3226122

r1

reads taken: 14092045
reads taken: 14112771

r2

reads taken: 4002635
reads taken: 4006940

ro

reads taken: 4150747
reads taken: 4150279

w1

writes taken: 13655019
writes taken: 13639011

wo

writes taken: 1757065
writes taken: 1758623

--
RWSEM_GENERIC_SPINLOCK y in rwsem-2.4.4-pre6 + your latest #try2 (fast path in C out 
of line)

rw

reads taken: 5872682
writes taken: 3032179
reads taken: 5892582
writes taken: 3042346

r1

reads taken: 13079190
reads taken: 13104405

r2

reads taken: 3907702
reads taken: 3906729

ro

reads taken: 3005924
reads taken: 3006690

w1

writes taken: 12581209
writes taken: 12570627

wo

writes taken: 1376782
writes taken: 1328468

--
RWSEM_XCHGADD y in rwsem-2.4.4-pre6 + your latest #try2 (fast path in asm in line)

rw

reads taken: 5789650
writes taken: 2989604
reads taken: 5776594
writes taken: 2982812
r1

reads taken: 16935488
reads taken: 16930738

r2

reads taken: 5646446
reads taken: 5651600

ro

reads taken: 4952654
reads taken: 4956992

w1

writes taken: 15432874
writes taken: 15408684

wo

writes taken: 814131
writes taken: 815551

To make it more readable I plotted the numbers in a graph (attached).

So my new C based rw semaphores are faster than your C based semaphores in
all tests and they're even faster than your x86 asm inlined semaphores when
there's contention (however it's probably normal that with contention the asm
semaphores are slower so I'm not sure I can make the asm inlined semaphore
faster than yours).  I will try to boost my new rwsem with asm in the fast path
now (it won't be easy but possibly by only changing a few lines of the slow
path inside an #ifdef CONFIG_...) to see where can I go. Once I will have an
asm inlined fast path for >=486 integrated I will upload a patch but if you
want a patch now with only the new generic C implementation to verify the above
numbers let me know of course (ah and btw the machine is a 2-way PII 450mhz).

I think it's interesting also the comparison of my generic rwsem when inlined
and not inlined (first four columns). BTW, I also tried to move my only lock in
a separated cacheline (growing the size of the rwsem over 32bytes) and that
hurted a lot.

Note also the your wo results with your asm version (the one in pre6 + your
latest try#2) is scoring more than two times worse than my generic semaphores.

Andrea

 rwsem.png

Re: Linux 2.4.3-ac12 unresolved symbol rwsem...

[J Sloan]

Alan Cox wrote:

> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_down_write_failed
> >
> > Same thing with tdfx.o...
>
> "Works for me" as ever. What configuration options are you using. This sounds
> like some of the code is built with each kind of semaphore.

I'm getting the same thing here - Red Hat 7.1, amd K6/2
450 with a voodoo 3 -

After successful build and booting of 2.4.3-ac12, I found
I had no 3D acceleration, and saw error msgs similar to
those above, concerning tdfx.o.

As always, building agp and tdfx as modules.

jjs

-
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 2.4.3-ac12

[Manuel McLure]

On 2001.04.22 11:48 Alan Cox wrote:
> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_down_write_failed
> > 
> > Same thing with tdfx.o...
> 
> "Works for me" as ever. What configuration options are you using. This
> sounds
> like some of the code is built with each kind of semaphore.

.config attached - note that I build a lot more than I actually need. I
took a .config from the Red Hat 7 2.4 kernel RPM and have just been keeping
it up to date with "make oldconfig". I suppose some day I should go through
and select only the stuff I want...

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft
 .config

Re: BUG: Global FPU corruption in 2.2

[Alan Cox]

> OK, regardless of how the linux kernel actually manages the FPU for user-space
> 
> programs, does anybody have any comments on the original bugreport?

Complete mystification.

> >of pi begins to look wrong.  Then kill everything and run pi by itself
> >again.  It will no longer produce good results.  We find that the FPU
> >persistently gives bad results until we reboot.
> 
> I tried this on my dual PIII-600 runnng 2.2.19 and got exactly the behavior
> described.

This is the most odd bit of all. The processor state for the FPU is per task
private and each task initializes its own FPU state. In terms of FPU state
itself I don't currently see what there is that can be left behind

-
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: 2.4.3+ sound distortion

[Alan Cox]

> Wow! Now it not only boots right, the sound distortion problem also seems
> to be fixed!!! Great work! However another problem is still here, i see
> only one of the two ide-channels of the PDC20265.

There is a possible patch for that in the Red Hat source rpm but its a bit
ugly. I need to figure out if it can be cleaned up and get it included into
the main tree


-
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: 2.4.3+ sound distortion

[Alan Cox]

> 2.4.4-pre6 did only compile when I aplied the '__builtin_expect'-patch. It
> crashed at boot however, when initializing my onboard raidcontroller
> (PDC20265 on a MSI K7T Turbo-R). It seems to be the same problem as
> reported by Manuel A. McLure. So no word yet about the sound
> distortion-problem being fixed.

I've sent Linus a fix for the PDC20265 crash
-
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 2.4.3-ac12

[Alan Cox]

> > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > symbol rwsem_up_write_wake
> > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > symbol rwsem_down_write_failed
> 
> Same thing with tdfx.o...

"Works for me" as ever. What configuration options are you using. This sounds
like some of the code is built with each kind of semaphore.
-
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: Request for comment -- a better attribution system

[Alan Cox]

> And before you write me off as one of the $BIGNUM clueless
> visionaries, you might do well to remember that I actually *have*
> radically changed the world lkml operates in.  At least twice.

I must have missed them 8)

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: Linux 2.4.3-ac12

[Alan Cox]

> In principle you just need 2.7.2.3 for m68k, but someone decided to
> raise the bar for all architectures by putting a check in a common
> header file.

I suspect you would find that some of the problems with the initialisers
in structures were common to 2.7.2 across all platforms, but I may be wrong

> Maybe it's time to move that check to the arch include dir instead?

I have no problem there

-
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: Global FPU corruption in 2.2

[David Konerding]

Ulrich Drepper wrote:

> "Richard B. Johnson" <[EMAIL PROTECTED]> writes:
>
> > The kernel doesn't know if a process is going to use the FPU when
> > a new process is created. Only the user's code, i.e., the 'C' runtime
> > library knows.
>
> Maybe you should try to understand the kernel code and the features of
> the processor first.  The kernel can detect when the FPU is used for
> the first time.

OK, regardless of how the linux kernel actually manages the FPU for user-space

programs, does anybody have any comments on the original bugreport?

>We have found that one of our programs can cause system-wide
>corruption of the x86 FPU under 2.2.16 and 2.2.17.  That is, after we
>run this program, the FPU gives bad results to all subsequent
>processes.

>We see this problem on dual 550MHz Xeons with 1GB RAM.  We have 64 of
>these things, and we see the problem on every node we try (dozens).
>We don't have other SMPs handy.  Uniprocessors, including other PIIIs,
>don't seem to be affected.

>Below are two programs we use to produce the behavior.  The first
>program, pi, repeatedly spawns 10 parallel computations of pi.  When
>all is well, each process prints pi as it completes.

>The second program, pt, repeatedly attaches to and detaches from
>another process.  Run pt against the root pi process until the output
>of pi begins to look wrong.  Then kill everything and run pi by itself
>again.  It will no longer produce good results.  We find that the FPU
>persistently gives bad results until we reboot.

I tried this on my dual PIII-600 runnng 2.2.19 and got exactly the behavior
described.
If it is a bug in the linux kernel (I can see nothing wrong with the source
code provided),
I would suspect probems with SMP and ptrace, somehow causing the wrong FP
registers
to be returned to a process after the scheduler restarted it.  It's very
interesting that the
PI program works fine until you run PT, but after you run PT, PI is screwed
until reboot.



-
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: 2.4.3+ sound distortion

[Victor Julien]

Wow! Now it not only boots right, the sound distortion problem also seems
to be fixed!!! Great work! However another problem is still here, i see
only one of the two ide-channels of the PDC20265.


> 
> On 2001.04.22 10:47 Victor Julien wrote:
> 
> > 2.4.4-pre6 did only compile when I aplied the '__builtin_expect'-patch.
> > It
> > crashed at boot however, when initializing my onboard raidcontroller
> > (PDC20265 on a MSI K7T Turbo-R). It seems to be the same problem as
> > reported by Manuel A. McLure. So no word yet about the sound
> > distortion-problem being fixed.
> 
> The PCD20265 crash is fixed in 2.4.3-ac12 and should be fixed in the next
> -pre.
> In the meantime you can apply the following patch from Alan Cox:
> 
> *** drivers/ide/ide-pci.c.origSun Apr 22 11:07:51 2001
> --- drivers/ide/ide-pci.c Sat Apr 21 20:07:09 2001
> ***
> *** 596,602 
>   if (IDE_PCI_DEVID_EQ(d->devid, DEVID_PDC20265))
>   {
>   printk(KERN_INFO "ide: Found promise 20265 in
> RAID mode.\n");
> ! if(dev->bus->self->vendor == PCI_VENDOR_ID_INTEL
> &&
>   dev->bus->self->device == PCI_DEVICE_ID_INTEL_I960)
>   {
>   printk(KERN_INFO "ide: Skipping Promise
> PDC20265 attached to I2O RAID controller.\n");
> --- 596,602 
>   if (IDE_PCI_DEVID_EQ(d->devid, DEVID_PDC20265))
>   {
>   printk(KERN_INFO "ide: Found promise 20265 in
> RAID mode.\n");
> ! if(dev->bus->self && dev->bus->self->vendor ==
> PCI_VENDOR_ID_INTEL &&
>   dev->bus->self->device == PCI_DEVICE_ID_INTEL_I960)
>   {
>   printk(KERN_INFO "ide: Skipping Promise
> PDC20265 attached to I2O RAID controller.\n");
> 
> 
> 
> -- 
> Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
> <[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
>  | -- H.P. Lovecraft
> 
> 
> 


-
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: Inspiron 8000 does not resume after suspend

[Alan Cox]

> This sounds a little like the problem I am seeing with my
> StinkPad 600E, you might want to try enabling CONFIG_APM_ALLOW_INTS
> and see if that makes a difference (thats the magic option required
> for the 600E).

If you have machines which have requirements for specific APM settings please
run dmidecode 1.1 or later on them (ftp.linux.org.uk/pub/linux/alan/DMI/...)
and give me the options you needed as well as the DMI output. I can then 
extend the DMI blacklists in -ac to automatically set these 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: Kernel Error Message

[Alan Olsen]

I am getting the same message with kernel 2.2.19 on a Vaio 505VE. (Celeron
333 with 128 megs of memory.)  I usually see the message when copying
large quantites from the PCMCIA CD-ROM to the hard drive.

On Sun, 22 Apr 2001, Andreas Neidhardt wrote:

> Hello from Germany,
> 
> I have trouble with a 2.2.18 kernel on a Gigabyte GA 5AX Rev. 5.2
> Mainboard.
> I have a lot of entrys in /var/log/messages like this:
> 
> kernel: probable hardware bug: clock timer configuration lost - probably
> a VIA686a.
> horst kernel: probable hardware bug: restoring chip configuration.
> 
> The Mainboard has definitely not a VIA686a. It is a Acer M1541 and M1543
> Chipset ( Aladin V) with a Intel Pentium 200 MMX CPU.
> 
> My Linux Computer:
> 
> GA 5AX Rev. 5.2
> 128 MB SDRAM
> Matrox Mystique PCI 2 MB Graphics Adapter
> 3Com Fast EtherLink XL 3C905B-COMBO NIC
> Maxtor 20 GB IDE HDD UDMA 100
> Fritz PCI ISDN Card
> TEKRAM SCSI II Controller DC 390 (no SCSI Devices connected)
> 
> cat /proc/pci  =>
> 
> PCI devices found:
>   Bus  0, device   0, function  0:
> Host bridge: Acer Labs M1541 Aladdin V (rev 4).
>   Slow devsel.  Master Capable.  Latency=32.
>   Non-prefetchable 32 bit memory at 0xe000 [0xe000].
>   Bus  0, device   1, function  0:
> PCI bridge: Acer Labs M5243 AGP (rev 4).
>   Slow devsel.  Master Capable.  Latency=32.  Min Gnt=4.
>   Bus  0, device   7, function  0:
> ISA bridge: Acer Labs M1533 Aladdin IV (rev 195).
>   Medium devsel.  Master Capable.  No bursts.
>   Bus  0, device   8, function  0:
> VGA compatible controller: Matrox Mystique (rev 2).
>   Medium devsel.  Fast back-to-back capable.  IRQ 11.  Master
> Capable.  Late
> ncy=32.
>   Non-prefetchable 32 bit memory at 0xe100 [0xe100].
>   Prefetchable 32 bit memory at 0xe200 [0xe208].
>   Non-prefetchable 32 bit memory at 0xe300 [0xe300].
>   Bus  0, device  10, function  0:
> Ethernet controller: 3Com Unknown device (rev 0).
>   Vendor id=10b7. Device id=9058.
>   Medium devsel.  IRQ 5.  Master Capable.  Latency=32.  Min
> Gnt=10.Max Lat=1
> 0.
>   I/O at 0xe000 [0xe001].
>   Non-prefetchable 32 bit memory at 0xe600 [0xe600].
>   Bus  0, device  11, function  0:
> Non-VGA device: AMD 53C974 (rev 16).
>   Medium devsel.  IRQ 3.  Master Capable.  Latency=32.  Min
> Gnt=4.Max Lat=40
> .
>   I/O at 0xe400 [0xe401].
>   Bus  0, device  12, function  0:
> Network controller: AVM A1 (Fritz) (rev 2).
>   Medium devsel.  Fast back-to-back capable.  IRQ 11.
>   Non-prefetchable 32 bit memory at 0xe6002000 [0xe6002000].
>   I/O at 0xe800 [0xe801].
>   Bus  0, device  15, function  0:
> IDE interface: Acer Labs M5229 TXpro (rev 194).
>   Medium devsel.  Fast back-to-back capable.  Master Capable.
> Latency=32.
> Min Gnt=2.Max Lat=4.
>   I/O at 0xf000 [0xf001].
> 
> 
> 
> 
> 
> 
> 
> best regards
> 
> andreas
> 
> -
> 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/
> 

[EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply
Alan Olsen| to my mail, just hit the ctrl, alt and del keys.
"In the future, everything will have its 15 minutes of blame."

-
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: a way to restore my hd ?

[Ville Holma]

Thank You everybody who helped me solve the problem. I found a working
back-up of the superblock at -b 32768 and was able to save all of my
important work from the harddrive. The filesystem was however badly
corrupted and lots of other files were truncated after e2fsck had finished.
So I ended up just re-installing my linux distribution but didn't loose any
valuable work. Lucky me.

So, again, Thank You all for the great help I received. You know who you
are.

Ville


> > The memory I had was however somehow corrupt and after I got my new
system
> > booted up and used it a little it became shaky and then locked hard and
I
> > could do nothing but reset it. I suppose this was caused by the
> > malfunctioning memory but I can't be sure, I know there has been
problems
> > with the via chipset also.
>
> Nod
>
> > debian:~# e2fsck /dev/hdb7
> > e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> > Corruption found in superblock.  (frags_per_group = 2147516416).
>
> Try e2fsck -b 8193 /dev/hdb7
>
> (and 16384, 32768)
>
> This is a backup copy of the superblock.
>

-
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: ATA66 on a Via Chipset

[Arjan van de Ven]

In article <01042213394300.23387@athena> you wrote:
> megs/second.  So, my question is - why were they so much faster in debian, 
> and how can I replicate that in redhat?

What version ? 7.1 tries to take countermeasures against the datacorruption
bugs in the VIA chipsets

-
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 Error Message

[Andreas Neidhardt]

Hello from Germany,

I have trouble with a 2.2.18 kernel on a Gigabyte GA 5AX Rev. 5.2
Mainboard.
I have a lot of entrys in /var/log/messages like this:

kernel: probable hardware bug: clock timer configuration lost - probably
a VIA686a.
horst kernel: probable hardware bug: restoring chip configuration.

The Mainboard has definitely not a VIA686a. It is a Acer M1541 and M1543
Chipset ( Aladin V) with a Intel Pentium 200 MMX CPU.

My Linux Computer:

GA 5AX Rev. 5.2
128 MB SDRAM
Matrox Mystique PCI 2 MB Graphics Adapter
3Com Fast EtherLink XL 3C905B-COMBO NIC
Maxtor 20 GB IDE HDD UDMA 100
Fritz PCI ISDN Card
TEKRAM SCSI II Controller DC 390 (no SCSI Devices connected)

cat /proc/pci  =>

PCI devices found:
  Bus  0, device   0, function  0:
Host bridge: Acer Labs M1541 Aladdin V (rev 4).
  Slow devsel.  Master Capable.  Latency=32.
  Non-prefetchable 32 bit memory at 0xe000 [0xe000].
  Bus  0, device   1, function  0:
PCI bridge: Acer Labs M5243 AGP (rev 4).
  Slow devsel.  Master Capable.  Latency=32.  Min Gnt=4.
  Bus  0, device   7, function  0:
ISA bridge: Acer Labs M1533 Aladdin IV (rev 195).
  Medium devsel.  Master Capable.  No bursts.
  Bus  0, device   8, function  0:
VGA compatible controller: Matrox Mystique (rev 2).
  Medium devsel.  Fast back-to-back capable.  IRQ 11.  Master
Capable.  Late
ncy=32.
  Non-prefetchable 32 bit memory at 0xe100 [0xe100].
  Prefetchable 32 bit memory at 0xe200 [0xe208].
  Non-prefetchable 32 bit memory at 0xe300 [0xe300].
  Bus  0, device  10, function  0:
Ethernet controller: 3Com Unknown device (rev 0).
  Vendor id=10b7. Device id=9058.
  Medium devsel.  IRQ 5.  Master Capable.  Latency=32.  Min
Gnt=10.Max Lat=1
0.
  I/O at 0xe000 [0xe001].
  Non-prefetchable 32 bit memory at 0xe600 [0xe600].
  Bus  0, device  11, function  0:
Non-VGA device: AMD 53C974 (rev 16).
  Medium devsel.  IRQ 3.  Master Capable.  Latency=32.  Min
Gnt=4.Max Lat=40
.
  I/O at 0xe400 [0xe401].
  Bus  0, device  12, function  0:
Network controller: AVM A1 (Fritz) (rev 2).
  Medium devsel.  Fast back-to-back capable.  IRQ 11.
  Non-prefetchable 32 bit memory at 0xe6002000 [0xe6002000].
  I/O at 0xe800 [0xe801].
  Bus  0, device  15, function  0:
IDE interface: Acer Labs M5229 TXpro (rev 194).
  Medium devsel.  Fast back-to-back capable.  Master Capable.
Latency=32.
Min Gnt=2.Max Lat=4.
  I/O at 0xf000 [0xf001].







best regards

andreas

-
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: Request for comment -- a better attribution system

[Eric S. Raymond]

Rik van Riel <[EMAIL PROTECTED]>:
> Let me see ...
> 
> 1) fetchmail, allowing dialup users to get lkml
> 2) getting snake.thyrsus.com out of ORBS and starting
>the mother of all lkml threads
> 
> Did I forget anything ?

Yes, Rik, you did.  It's not `snake', it's `snark'.

:-)
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Freedom, morality, and the human dignity of the individual consists
precisely in this; that he does good not because he is forced to do
so, but because he freely conceives it, wants it, and loves it.
-- Mikhail Bakunin 
-
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/

BPF and SKB

[gis88530]

Hello,

I have study the BPF, and I know it calls Socket Filtering in Linux.
(user)
|
(buffer)
|
(BPF)(origin protocol stack)
|   |
(Data Link Layer)

Does the buffer above BPF is skb_buff?
If yes, origin protocol stack will get packet from it.
After the packet be processed, the packet in the buffer will be del.
Right? Thanks for your advise.




-
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] ppp_generic, kernel 2.4.3

[Tim Wilson]

Thanks for your reply. It seems I am finally talking to the right person (I
had previously tried posting this on the pptp-server mailing list, and I
also tried sending it to you directly, but no luck).

> Hmmm... using CCP to negotiate encryption is a Bad Idea IMHO.  I know
> Microsoft does, but that isn't really a recommendation. :)  Certainly
> pppd and the Linux PPP kernel driver don't include support for some of
> the things that the MPPE spec says you have to do, like taking down
> the link if MPPE doesn't get negotiated successfully, and not sending
> or receiving any data before MPPE is up.
>
> All of which goes to say that MPPE support is not a "feature point" of
> the Linux PPP implementation.  So a potential insecurity in an MPPE
> implementation is hardly a bug.

Well, I do know that people set up Linux gateways as PPTP servers, and that
they use MPPE to allow win98 clients to connect to those servers. That's
what I was trying to do anyway. After the connect, the gateway log says that
MPPE is negotiated, and the win98 client claims MPPE is being used, so all
looks OK, but the gateway sends PPP frames in cleartext. If that's not a
security hole, it is certainly not a Good Thing. As my patch shows, the fix
is quite easy, so reqardless of what we call it, might as well fix it.

> The bug is only going to show up if CCP gets re-negotiated, i.e. if
> CCP get negotiated and comes up and then one side starts sending
> Configure-requests to renegotiate the compression method and
> parameters.

Sorry, that's not the case. Let me see if I can explain using a little ASCII
art. Here's a legal exchange for initially opening CCP:

 Server Client
1)   
3)   ConfReq-->
4)    Actually, after having another look at RFC 1962 I think that either
> sending or receiving a ConfReq takes CCP out of Opened state and
> should stop compression in *both* directions.  So on balance I would
> change it like you have for TermReq and TermAck, but make the same
> change for ConfReq as well.

I'll take a look at the RFCs myself, but that sounds right. However, you
can't just handle the ConfReq like I was handling the TermReq/TermAck--take
another look at the scenario above. The compressor would get reset at (3),
we'd end up with the same problem. The ConfReq should make CCP go down only
if it's already up, something like this:

...
case CCP_CONFREQ:
case CCP_TERMREQ:
case CCP_TERMACK:
if( ppp->flags & SC_CCP_UP) {
ppp->rstate &= ~SC_DECOMP_RUN;
ppp->xstate &= ~SC_COMP_RUN;
ppp->flags &= ~SC_CCP_UP;
}
break;
...

(This assumes that SC_CCP_UP is the right thing to check--I'm not sure about
the distinction between SC_CCP_UP and SC_CCP_OPEN--haven't studied the code
enough. But you probably know that stuff already).

Incidentally, I looked at the 2.2 code and that's what it does.


> BTW, the spacing/indentation in the patch you sent was broken; the
> patch seemed to have 1-space indentation whereas it should be 1-tab
> indentation.  Does your mailer convert tabs to single spaces maybe?

Sorry. I'll try to fix that for next time. If we can agree on a fix for this
problem, I'll be happy to let you submit the patch. It's your code.

-
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: 2.4.3+ sound distortion

[Victor Julien]

>We are still playing with the VIA fixups, but this may also be VM related.
I'm
>currently playing with several VM ideas, and potential fixes which might
>impact overall performance.
>
>Test 2.4.4pre6 that has the VIA fixes but does not have the VM changes

2.4.4-pre6 did only compile when I aplied the '__builtin_expect'-patch. It
crashed at boot however, when initializing my onboard raidcontroller
(PDC20265 on a MSI K7T Turbo-R). It seems to be the same problem as
reported by Manuel A. McLure. So no word yet about the sound
distortion-problem being fixed.

Victor Julien

-
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 2.4.3-ac12

[Jes Sorensen]

> "Roman" == Roman Zippel <[EMAIL PROTECTED]> writes:

Roman> Hi, Jes Sorensen wrote:

>> In principle you just need 2.7.2.3 for m68k, but someone decided to
>> raise the bar for all architectures by putting a check in a common
>> header file.

Roman> IIRC 2.7.2.3 has problems with labeled initializers for
Roman> structures, which makes 2.7.2.3 unusable for all archs under
Roman> 2.4.

True, so our bar is egcs-1.1.2, but thats still a bit from 2.96+

Jes
-
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/

ATA66 on a Via Chipset

[Alexander Valys]

Recently, I decided to try out Debian 2.2.  I downloaded the iso, installed 
it, and went to compile kernel 2.4.3.  I used the same .config file I've used 
before, containing all the appropriate support (ATA66, notably) for my Via 
Apollo Pro133A-based motherboard, installed it, and rebooted.  To make sure 
everything worked correctly, I ran hdparm -t /dev/hda, and was amazed to see 
transfer rates of 22 megs/second.  In redhat, the most I can get is 15.  So, 
I immediately reinstalled redhat, and (using the same .config file), compiled 
the kernel again.  After rebooting, my transfer rates were still 15 
megs/second.  So, my question is - why were they so much faster in debian, 
and how can I replicate that in redhat?
--A. Valys
-
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 2.4.3-ac12

[Roman Zippel]

Hi,

Jes Sorensen wrote:

> In principle you just need 2.7.2.3 for m68k, but someone decided to
> raise the bar for all architectures by putting a check in a common
> header file.

IIRC 2.7.2.3 has problems with labeled initializers for structures,
which makes 2.7.2.3 unusable for all archs under 2.4.

bye, Roman
-
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: Request for comment -- a better attribution system

[Alexander Viro]

On Sun, 22 Apr 2001, Eric S. Raymond wrote:

> Alexander Viro <[EMAIL PROTECTED]>:
> > Sigh... Would these broken things, by any chance, be "my grand ideas are
> > not met with applause"?
> 
> Nope.  Not at all.  Stay tuned, because I'll explain.
> 
> And before you write me off as one of the $BIGNUM clueless
> visionaries, you might do well to remember that I actually *have*
> radically changed the world lkml operates in.  At least twice.

So had certain wa.us-based company. If you refer to your "Cathedral
and Bazaar" - pardon me the bluntness, but it doesn't speak well of your
clue level.  L-k is not a place for detailed analysis of that text, so let
me just point to the fact that
* you've ignored the robustness of design behind the UNIX kernel.
These beasts keep going without falling apart even after serious injuries.
* you've ignored another factor - maintainer with a taste and ability
to say "no".
* you've made a completely unwarranted assumption - that widely-used
and available code actually gets reviewed by many people.  It's demonstrably
false.

Ability to do PR != having a shred of clue in other areas.
I'm sure that you can come up with relevant examples yourself.

-
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/

Problem with "su -" and kernels 2.4.3-ac11 and higher

[Manuel McLure]

I'm having a problem with "su -" on ac11/ac12. ac5 doesn't show the
problem.
The problem is easy to reproduce - go to a console, log in as root, do an
"su -" (this will succeed) and then another "su -". The second "su -"
should hang - ps shows it started bash and that the bash process is
sleeping. You need to "kill -9" the bash to get your prompt back.

Distribution is Red Hat 7.1, running on an Athlon Thunderbird 900MHz on a
MSI K7T Turbo R motherboard.

Thanks,
-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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 2.4.3-ac12

[Manuel McLure]

On 2001.04.22 09:25 John Cavan wrote:
> Alan Cox wrote:
> > 2.4.3-ac12
> > o   Further semaphore fixes (David Howells)
> 
> Getting unresolved symbols in some modules (notably, for me, microcode.o
> and radeon.o)...
> 
> Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> symbol rwsem_up_write_wake
> /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> symbol rwsem_down_write_failed

Same thing with tdfx.o...

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<[EMAIL PROTECTED]> | and significant law, no man may kill a cat.
 | -- H.P. Lovecraft

-
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 2.4.3-ac12

[Dieter Nützel]

> My belief however is that several million people have gcc 2.96-69+, about 50
> are likely to have random cvs snapshots and none of them are going to build
> kernels with them anyway, as they wont work __builtin_expect or otherwise.
>
> Alan

I will not add fuel to the fire, but isn't 2.4.XX the "stable" version?
And I think most people (here in Europe :-) are running 2.95.2 at the moment.
But, yes the previously patches fixed it.

Thanks,
Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany

email: [EMAIL PROTECTED]
@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/

Re: Request for comment -- a better attribution system

[Rik van Riel]

On Sun, 22 Apr 2001, Eric S. Raymond wrote:

> And before you write me off as one of the $BIGNUM clueless
> visionaries, you might do well to remember that I actually *have*
> radically changed the world lkml operates in.  At least twice.

Let me see ...

1) fetchmail, allowing dialup users to get lkml
2) getting snake.thyrsus.com out of ORBS and starting
   the mother of all lkml threads

Did I forget anything ?



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: Request for comment -- a better attribution system

[Rik van Riel]

On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> David Woodhouse <[EMAIL PROTECTED]>:
> > [EMAIL PROTECTED] said:
> > >  I've had my nose rubbed in how things really work.  That's why I want
> > > to fix the things that are broken about how things really work.
> > 
> > Then you're going to conjure up maintainers for the code which is currently 
> > orphaned?
> 
> That's a *really* hard problem.  I don't know how to solve that one myself.

You could volunteer to maintain all the code you reveal
to be orphaned ...

*runs like hell*

cheers,

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: Request for comment -- a better attribution system

[Eric S. Raymond]

Alexander Viro <[EMAIL PROTECTED]>:
> Sigh... Would these broken things, by any chance, be "my grand ideas are
> not met with applause"?

Nope.  Not at all.  Stay tuned, because I'll explain.

And before you write me off as one of the $BIGNUM clueless
visionaries, you might do well to remember that I actually *have*
radically changed the world lkml operates in.  At least twice.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

In the absence of any evidence tending to show that possession 
or use of a 'shotgun having a barrel of less than eighteen inches 
in length' at this time has some reasonable relationship to the 
preservation or efficiency of a well regulated militia, we cannot 
say that the Second Amendment guarantees the right to keep and bear 
such an instrument. [...] The Militia comprised all males 
physically capable of acting in concert for the common defense.  
-- Majority Supreme Court opinion in "U.S. vs. Miller" (1939)
-
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: hundreds of mount --bind mountpoints?

[Alexander Viro]

On Sun, 22 Apr 2001, David L. Parsley wrote:

> Hi,
> 
> I'm still working on a packaging system for diskless (quasi-embedded)
> devices.  The root filesystem is all tmpfs, and I attach packages inside
> it.  Since symlinks in a tmpfs filesystem cost 4k each (ouch!), I'm
> considering using mount --bind for everything.  This appears to use very
> little memory, but I'm wondering if I'll run into problems when I start
> having many hundreds of bind mountings.  Any feel for this?

Memory use is sizeof(struct vfsmount) per binding. In principle, you can get
in trouble when size of /proc/mount will get past 4Kb - you'll get only
first 4 (actually 3, IIRC) kilobytes, so stuff that relies on the contents
of said file may get unhappy. It's fixable, though.

-
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 2.4.3-ac12

[Mohammad A. Haque]

In case everyone missed my original patch =P

http://marc.theaimsgroup.com/?l=linux-kernel&m=98791931115515&w=2


Jes Sorensen wrote:
> 
> > "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
> 
> Alan> The recommended compilers for non x86 are different too - eg you
> Alan> need 2.96 gcc for IA64, you need 2.95 not egcs for mips and so
> Alan> on.
> 
> In principle you just need 2.7.2.3 for m68k, but someone decided to
> raise the bar for all architectures by putting a check in a common
> header file.
> 
> Maybe it's time to move that check to the arch include dir instead?
> 
> Jes
> -
> 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/

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [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: Request for comment -- a better attribution system

[Alexander Viro]

On Sun, 22 Apr 2001, Eric S. Raymond wrote:

> Alexander Viro <[EMAIL PROTECTED]>:
> > Eric, it would save everyone a lot of time if you actually cared to
> > pull your head out of your... theoretical constructions and spent
> > some efforts figuring out how the things really work.
> 
> I've had my nose rubbed in how things really work.  That's why I want to
> fix the things that are broken about how things really work.

Sigh... Would these broken things, by any chance, be "my grand ideas are
not met with applause"?

Take it from a guy who've done  quite a few global changes: they are pretty
much doable, but spamming maintainers with requests to support your k3wl
ideas is not a way to go. All you are getting that way is a bunch of procmail
rules.

Everyone who had been on l-k for more than a couple of months had seen
$BIGNUM of "visionary" lusers with grand schemes of Changing The World(tm)
and monumental lack of desire to learn. Until you demonstrate that you
understand what you are "fixing" - don't expect special treatment.

-
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/