test13-pre6 -- OOPS at boot time in kmem_cache_create (usb-ohci related)

[Miles Lane]

This OOPS occured at boot time when I did not have my Belkin
BusPort Mobile USB host-controller inserted.  /etc/usb/rc.usb
tried loading usb-ohci.  After the boot process completed
(after the OOPS occured), I was unable to unload the module
and lsmod showed that usb-ohci was still initializing.
Presumably, it got wedged when the OOPS occured?

ksymoops 2.3.5 on i686 2.4.0-test13-pre6.  Options used

Kernel command line: BOOT_IMAGE=Serial-Debug ro root=305 pci=biosirq 
console=ttyS0,38400 console=tty0 setup_delay=10
kernel BUG at slab.c:660!
invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010292
eax: 001a   ebx: 2800   ecx: 0001   edx: 0001
esi: 2800   edi: c5824929   ebp: c58251bc   esp: c4af1eb4
ds: 0018   es: 0018   ss: 0018
Process modprobe (pid: 84, stackpage=c4af1000)
Stack: c01ee425 c01ee4a5 0294 2800 c58247d0 0001 c58251bc 
41f0
c021c900 38d8 38db 0286 0203  c58251b4 
c5821079
c5824921 0020  2800   c5821000 
c58247d6
Call Trace: [] [] [] [] 
[] [] []
[] [] [] [] [] 
[] [] []
[] []
Code: 0f 0b 83 c4 0c 6a 07 68 80 c6 21 c0 e8 03 07 00 00 89 c5 83

 >>EIP; c01284bc<=
Trace; c01ee425 
Trace; c01ee4a5 
Trace; c58247d0 <[usb-ohci]init_module+0/0>
Trace; c58251bc <[usb-ohci].bss.end+15/39>
Trace; c58251b4 <[usb-ohci].bss.end+d/39>
Trace; c5821079 <[usb-ohci]ohci_mem_init+19/78>
Trace; c5824921 <[usb-ohci].rodata.start+101/76c>
Trace; c5821000 <[usbcore]__kstrtab_usb_devfs_handle+1864/18c4>
Trace; c58247d6 <[usb-ohci]ohci_hcd_init+6/3c>
Trace; c5821000 <[usbcore]__kstrtab_usb_devfs_handle+1864/18c4>
Trace; c0116b78 
Trace; c5813000 <_end+557b9b0/557ba10>
Trace; c5813000 <_end+557b9b0/557ba10>
Trace; c58251a8 <[usb-ohci].bss.end+1/39>
Trace; c5813000 <_end+557b9b0/557ba10>
Trace; c5821060 <[usb-ohci]ohci_mem_init+0/78>
Trace; c0108d57 
Code;  c01284bc 
 <_EIP>:
Code;  c01284bc<=
0:   0f 0b ud2a  <=
Code;  c01284be 
2:   83 c4 0c  add$0xc,%esp
Code;  c01284c1 
5:   6a 07 push   $0x7
Code;  c01284c3 
7:   68 80 c6 21 c0push   $0xc021c680
Code;  c01284c8 
c:   e8 03 07 00 00call   714 <_EIP+0x714> c0128bd0 

Code;  c01284cd 
   11:   89 c5 mov%eax,%ebp
Code;  c01284cf 
   13:   83 00 00  addl   $0x0,(%eax)


1 warning issued.  Results may not be reliable.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Oops using mke2fs on software raid-0 with pre7

[Tim Bell]

Hi,

First of all, thanks to Marcelo Tosatti for pointing me to pre2 which
fixed my previous mke2fs oops.  Now I've got a new one with pre7 (also
happened with pre5).

[1.] One line summary of the problem:

Oops while using mke2fs on software raid-0 device with pre7.

[2.] Full description of the problem/report:

While running mke2fs on a SCSI software RAID-0 array, there was an
"Unable to handle kernel NULL pointer dereference at virtual address
0024" message, along with an oops (below).
The problem has occurred both with pre5 and pre7.  When running SMP, the
oops below was given.  When running a UP pre7 kernel, there was no oops,
just a lockup.

[3.] Keywords (i.e., modules, networking, kernel):

filesystems, raid

[4.] Kernel version (from /proc/version):

Linux version 2.4.0-test13-pre7 (root@vike) (gcc version 2.95.2 2220 (Debian 
GNU/Linux)) #1 SMP Sun Dec 31 13:13:12 EST 2000

[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)

Note: oops was hand-copied.  I fixed a couple of typos, but there may be
others.

ksymoops 2.3.4 on i686 2.4.0-test13-pre7.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test13-pre7/ (default)
 -m /boot/System.map-2.4.0-test13-pre7 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
Unable to handle kernel NULL pointer dereference at virtual address 0024
Oops:   0002
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010203
eax: dfbe3780   ebx: 0001   ecx: dfbe3720   edx: 
esi: 0008   edi: 0900   ebp: 0158053d   esp: f7871d28
ds: 0018   es: 0018   ss: 0018
Stack: dfbe3720 c0135223 dfbe3720 0001 0900 6014f000 dfbe36c0  
   2d10 c013a299 0900 0158053d 0400 f79bec80 ffea 0005 
   8000 00096cd9 0900 09001547 03f01a80 0400 0400  
Call Trace: [] [] [] [] [] 
[] []
   [] [] [] [] [] [] 
[] []
   []
Code: 89 42 24 8d 14 dd 00 00 00 00 bb 60 56 30 c0 39 0c 1a 75 06

>>EIP; c013479c <__remove_from_free_list+2c/58>   <=
Trace; c0135223 
Trace; c013a299 
Trace; fa0a1ad8 
Trace; c01090a2 
Trace; c01e6827 
Trace; c01970ae 
Trace; c019a843 
Trace; c019a6c3 
Trace; c0a8d993 
Trace; c01eb827 
Trace; c01970ae 
Trace; c019a843 
Trace; c018fa79 
Trace; c0113d32 
Trace; c01333ab 
Trace; c0108eeb 
Code;  c013479c <__remove_from_free_list+2c/58>
 <_EIP>:
Code;  c013479c <__remove_from_free_list+2c/58>   <=
   0:   89 42 24  mov%eax,0x24(%edx)   <=
Code;  c013479f <__remove_from_free_list+2f/58>
   3:   8d 14 dd 00 00 00 00  lea0x0(,%ebx,8),%edx
Code;  c01347a6 <__remove_from_free_list+36/58>
   a:   bb 60 56 30 c0mov$0xc0305660,%ebx
Code;  c01347ab <__remove_from_free_list+3b/58>
   f:   39 0c 1a  cmp%ecx,(%edx,%ebx,1)
Code;  c01347ae <__remove_from_free_list+3e/58>
  12:   75 06 jne1a <_EIP+0x1a> c01347b6 
<__remove_from_free_list+46/58>


2 warnings issued.  Results may not be reliable.

[6.] A small shell script or example program which triggers the
 problem (if possible)

The command which triggered it was:
mke2fs -m 0 -b 4096 /dev/md0

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)

Linux viee 2.4.0-test13-pre7 #1 SMP Sun Dec 31 13:13:12 EST 2000 i686 unknown
Kernel modules 2.3.11
Gnu C  2.95.2
Gnu Make   3.79.1
Binutils   2.9.5.0.37
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.6
Mount  2.10f
Net-tools  2.05
Console-tools  0.2.3
Sh-utils   2.0i
Modules Loaded 

[7.2.] Processor information (from /proc/cpuinfo):

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 6
cpu MHz : 933.444
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 mmx fxsr sse
bogomips: 1861.22

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : 

Posix MessageQ's

[RAJESH BALAN]

Hi,
Does linux support Posix Message Q's. Iam reffering
richard stevens V2 for IPC.. The book said to include 
, which i was not able to find. Iam using
Linux 2.2.

Thanks,
Rajesh balan

__
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] 2.4.0-test12 drivers/Makefile

[Carlos E. Gorges]

--- linux-2.4.0-t12.vanilla+reiser/drivers/Makefile Thu Dec 21 12:52:17 2000
+++ linux-2.4.0-t12/drivers/MakefileSun Dec 31 00:38:09 2000
@@ -42,6 +42,7 @@
 subdir-$(CONFIG_HAMRADIO)  += net/hamradio
 subdir-$(CONFIG_ACPI)  += acpi
 
+subdir-$(CONFIG_I2C)   += i2c
 
 # Subdirectories that should be entered when MAKING_MODULES=1, even if set to 'y'.
 both-m := $(filter $(mod-subdirs), $(subdir-y))
--EOF--

no coments :-).

cya;
-- 
 _
 Carlos E Gorges  
 ([EMAIL PROTECTED])
 Tech informática LTDA
 Brazil   
 _

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: multiple mount of devices possible 2.4.0-test1 -

[Alexander Viro]

On Sat, 30 Dec 2000, Albert D. Cahalan wrote:

> Alexander Viro writes:
> 
> > [...] Not allowing multiple mounts of the same
> > fs was an artifact of original namei() implementation. At some point
> > (late 80s) it had been fixed by Bell Labs folks in their branch. In Linux
> > it had been fixed during the last spring. That's it. You were never promised
> > that multiple mounts will not work. Moreover, in special cases they did work
> 
> Heh. :-)
> 
> 1. go to http://www.linuxcertification.com/resources/quizzes/
> 2. take the "System Administration" quiz
> 3. try answering question 6 correctly

ITYM s/6/7/.
 
None of the variants. A: version-dependent and "just like" part is seriosuly
misleading. B: would be correct for old versions _if_ they would add "and
filesystem is presumed to be block-based". As it is, statement is blatantly
incorrect - some filesystems always could be mounted in many places. C:
not even funny. _None_ of the UNIX flavours I've seen has such limitation -
they either refuse to do second mount at all or they do not care about
relative location in the tree. D: see C.

Correct answer: on versions prior to 2.4 block-based filesystems can be
mounted only once. On 2.4 either do mount -t  /dev/hda2 /users
or mount --bind /var /users.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: multiple mount of devices possible 2.4.0-test1 -

[Steve VanDevender]

Albert D. Cahalan writes:
 > Alexander Viro writes:
 > 
 > > [...] Not allowing multiple mounts of the same
 > > fs was an artifact of original namei() implementation. At some point
 > > (late 80s) it had been fixed by Bell Labs folks in their branch. In Linux
 > > it had been fixed during the last spring. That's it. You were never promised
 > > that multiple mounts will not work. Moreover, in special cases they did work
 > 
 > Heh. :-)
 > 
 > 1. go to http://www.linuxcertification.com/resources/quizzes/
 > 2. take the "System Administration" quiz
 > 3. try answering question 6 correctly

Note: Chances are you won't get the same question 6 that Albert did.

Some poorly-written "certification" quiz shouldn't dictate what goes
into the kernel, either.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: multiple mount of devices possible 2.4.0-test1 -

[Albert D. Cahalan]

Alexander Viro writes:

> [...] Not allowing multiple mounts of the same
> fs was an artifact of original namei() implementation. At some point
> (late 80s) it had been fixed by Bell Labs folks in their branch. In Linux
> it had been fixed during the last spring. That's it. You were never promised
> that multiple mounts will not work. Moreover, in special cases they did work

Heh. :-)

1. go to http://www.linuxcertification.com/resources/quizzes/
2. take the "System Administration" quiz
3. try answering question 6 correctly
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

is there something odd in the aic7xxx driver ?

[Michael Meding]

Hi all,

I am experiencing problem with the latest test kernels and my adaptec 2940uw 
and one ibm hdd.

Thing is that during times the machine simply reboots without apparent 
reasons. Nothing shows up, to my knowledge in /var/log or other places. This 
is with the kernel compiled with gcc 2.95.2 on debian woody.

Using Gibbs respectively the adaptec driver I haven't had this behaviour in 
weeks, or better to say, not once.

The machine is up 24/7 but not under very high load. The times it failed have 
mostly been under more or less heavy i/o like compiling several kernels at a 
time.

Are others experiencing similar behaviours ?

Greetings

Michael Meding



System is kt-133 with mga g400, duron800 adaptec 2940uw with latest bios. 
Further information upon request.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre7...

[J Sloan]

Linus Torvalds wrote:

> On Sat, 30 Dec 2000, Steven Cole wrote:
> >
> > It looks like 2.4.0-test13-pre7 is a clear winner when running dbench 48
> > on my somewhat slow test machine (450 Mhz P-III, 192MB, IDE).
>
> This is almost certainly purely due to changing (some would say "fixing")
> the bdflush synchronous wait point.
>

After evaluating test13-pre7 with the quake 3 arena test,
I think it's even snappier than the previous champ, which
was test10 + low latency patches..

A most auspicious trend, if I might make so bold as
to state it in this forum.

jjs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: multiple mount of devices possible 2.4.0-test1 - 2.4.0-test13-pre4

[Ton Hospel]

In article <[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> writes:
> On Sat, 30 Dec 2000, Ton Hospel wrote:
> 
>> It should still need a special flag or something, since it's
>> impossible for userspace to check this atomically.
> 
> To check _what_? Having the same tree mounted in several places is
> allowed. End of story. Atomicity of any kind is a non-issue - if you
> have processes that do not cooperate and do random mounts you are
> getting exactly what you are asking for.
> 

I wasn't talking about mounting the same device on different mount points.
If you ask for that, it's good that you nowadays you can get that (though
even there it might be a good idea to let the filesystem say if it can
support that or not)

I was talking about avoiding that the same device gets multiple mounted 
at the SAME place, e.g. when doing mount -a, which is often used as a
quick way to get the new entries in /etc/fstab

That would also be no problem if there were a standard about e.g. always
flocking /etc/mtab. But as far as I know there isn't such a standard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre7...

[Linus Torvalds]

On Sat, 30 Dec 2000, Steven Cole wrote:
>
> It looks like 2.4.0-test13-pre7 is a clear winner when running dbench 48
> on my somewhat slow test machine (450 Mhz P-III, 192MB, IDE).

This is almost certainly purely due to changing (some would say "fixing")
the bdflush synchronous wait point.

No actual code was harmed in the making of this improvement.

But I will take full credit anyway.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre7...

[Steven Cole]

It looks like 2.4.0-test13-pre7 is a clear winner when running dbench 48
on my somewhat slow test machine (450 Mhz P-III, 192MB, IDE).

2.2.183.53307 MB/sec (NB=4.41633 MB/sec  35.3307 MBit/sec)
2.2.19-pre3   3.81213 MB/sec (NB=4.76516 MB/sec  38.1213 MBit/sec)
2.4.0-test13-pre5 4.06823 MB/sec (NB=5.08529 MB/sec  40.6823 MBit/sec)
2.4.0-test13-pre6 4.11353 MB/sec (NB=5.14192 MB/sec  41.1353 MBit/sec)
2.4.0-test13pre4-ac2  4.47376 MB/sec (NB=5.5922  MB/sec  44.7376 MBit/sec)
2.4.0-test13-pre7 6.3723  MB/sec (NB=7.96538 MB/sec  63.723  MBit/sec)

The tests were done under identical conditions, after fresh boot-up,
running KDE 2.0, one xterm, and xosview.

Here are a few selected lines from dmesg to put things in perspective.

Detected 448.810 MHz processor.
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: ST317221A, ATA DISK drive
Using r5 hash to sort names
reiserfs: using 3.5.x disk format
ReiserFS version 3.6.23

This is really looking great.

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: strange behaviour with test13-pre6

[dep]

On Saturday 30 December 2000 09:40 pm, [EMAIL PROTECTED] wrote:
| With test13-pre6 I suddenly found that I could not change the
| console. When I wanted to enter a command letters were changed:
| greek \mu appeared for m,
| tilde n for e.
|
| After a few seconds the system returned to normal behaviour.
| No messages can be found in the logfiles.

similar behavior at boot, at least since test11, to wit: at boot: 
prompt, hitting tab causes what seems to be several pages of 
scrolling with the odd character here and there, in place of a list 
of available boot options. after several seconds, boot: prompt 
reappears as usual, and one may, if one has remembered their names, 
type in any of the possibilities, and boot that choice.
-- 
dep
--
bipartisanship: an illogical construct not unlike the idea that
if half the people like red and half the people like blue, the 
country's favorite color is purple.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre7...

[Ray Strode]

>The LDT fixes in particular fix some potentially random strange behaviour.
>And the alpha memmove() thing was a showstopper bug on alphas.
And the network lockup bug...

--Ray



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre4-ac2/test13-pre7 ax25 undefined reference

[Alan Cox]

>   The problem showed up on the stroke of test13-pre4-ac2 and stuff from
> Alan has been merged in. I went from pre4-ac2 to pre5 (AOK) and now
> attempting pre7...

Its definitely coming from the AX.25 related changes. Please send me your
.config and I'll go squash this one

> drivers/net/net.o: In function `network_ldisc_init':
> drivers/net/net.o(.text.init+0x141): undefined reference to
> `mkiss_init_ctrl_dev
> '
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4test-ac merge status

[Tom Rini]

On Sun, Dec 31, 2000 at 02:33:50AM +, Alan Cox wrote:
> > I'm sure at least a few people want to know where the PowerPC port falls in
> > all of that. :)
> > 
> > ...hopeing we aren't in the bitbucket..
> 
> It might be the ppc port is 2.4.0ac1 and 2.4.2 Linus or something. I don't think
> that is likely to be a big problem. I need to get on top of 2.2.19pre4 and
> the rest of the Linus resync then I'm going to dump chunks of stuff out of
> -ac and try and get a nice clean -ac tree. If folks want to sync non x86
> ports with that initially go ahead.

Oh well.  I guess our problem is we can never get Linus to notice the smaller
chunks and he always seems to hate big patches.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

strange behaviour with test13-pre6

[mkloppstech]

With test13-pre6 I suddenly found that I could not change the console.
When I wanted to enter a command letters were changed:
greek \mu appeared for m,
tilde n for e.

After a few seconds the system returned to normal behaviour.
No messages can be found in the logfiles.

Please cc to [EMAIL PROTECTED]

Mirko Kloppstech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

test13-pre4-ac2/test13-pre7 ax25 undefined reference

[Sid Boyce]

The problem showed up on the stroke of test13-pre4-ac2 and stuff from
Alan has been merged in. I went from pre4-ac2 to pre5 (AOK) and now
attempting pre7...

ld -m elf_i386 -T /usr/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/f
s.o ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/ne
t/net.o drivers/media/media.o  drivers/ide/idedriver.o
drivers/scsi/scsidrv.o dr
ivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o
drivers/p
np/pnp.o drivers/video/video.o drivers/net/hamradio/hamradio.o
drivers/usb/usbdr
v.o drivers/acpi/acpi.o \
net/network.o \
/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a
/usr/src/lin
ux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
drivers/net/net.o: In function `network_ldisc_init':
drivers/net/net.o(.text.init+0x141): undefined reference to
`mkiss_init_ctrl_dev
'
make: *** [vmlinux] Error 1

Regards
-- 
Sid Boyce ... hamradio G3VBV ... Cessna/Warrior Pilot
Linux only shop.. Tel. 44-121 422 0375
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Generic deferred file writing

[Andrea Arcangeli]

On Sat, Dec 30, 2000 at 08:50:52PM -0500, Alexander Viro wrote:
> And its meaning for 2/3 of filesystems would be?

It should stay in the private part of the in-core superblock of course.

> I _doubt_ it. If it is a pagecache issue it should apply to NFS. It should
> apply to ramfs. It should apply to helluva lot of filesystems that are not
> block-based. Pagecache doesn't (and shouldn't) know about blocks.

With pagecache I meant the library of pagecache methods in buffer.c. Even
if they are recalled by the lowlevel filesystem code and they can be
overridden by lowlevel filesystem code, they aren't lowlevel filesystem code
but they're infact common code.  We can implement another version of them that
instead of knowing about get_block, also know about another filesystem
callback and when possible it only reserve the space for a delayed allocation
later triggered (in parallel) by future kupdate. They will know about this new
callback in the same way the current standard pagecache library methods knows
about get_block_t. Filesystems implementing this callback will be able to use
those new pagecache library methods.

> it should use functions that do not expect such argument. That's it. No
> need to invent new methods or shoehorn all block filesystems into the same
> scheme.

Of course.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4test-ac merge status

[Alan Cox]

> I'm sure at least a few people want to know where the PowerPC port falls in
> all of that. :)
> 
> ...hopeing we aren't in the bitbucket..

It might be the ppc port is 2.4.0ac1 and 2.4.2 Linus or something. I don't think
that is likely to be a big problem. I need to get on top of 2.2.19pre4 and
the rest of the Linus resync then I'm going to dump chunks of stuff out of
-ac and try and get a nice clean -ac tree. If folks want to sync non x86
ports with that initially go ahead.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Generic deferred file writing

[Linus Torvalds]

On Sun, 31 Dec 2000, Roman Zippel wrote:
> 
> On Sun, 31 Dec 2000, Andrea Arcangeli wrote:
> 
> > > estimate than just the data blocks it should not be hard to add an
> > > extra callback to the filesystem.  
> > 
> > Yes, I was thinking at this callback too. Such a callback is nearly the only
> > support we need from the filesystem to provide allocate on flush.
> 
> Actually the getblock function could be split into 3 functions:
> - alloc_block: mostly just decrementing a counter (and quota)
> - get_block: allocating a block from the bitmap
> - commit_block: inserting the new block into the inode
> 
> This would be really useful for streaming, one could get as fast as
> possible the block number and the data could be very quickly written,
> while keeping the cache usage low. Or streaming directly from a device
> to disk also wants to get rid of the data as fast as possible.

Now, to insert a small note of sanity here: I think people are starting to
overdesign stuff.

The fact is that currently the "get_block()" interface that the page cache
helper functions use does NOT have to be very expensive at all.

In fact, in a properly designed filesystem just a bit of low-level caching
would easily make the average "get_block()" be very fast indeed. The fact
that right now ext2 has not been optimized for this is _not_ a reason to
design the VFS layer around a slow get_block() operation.

If you look at the generic block-based writing routines, they are actually
not all that expensive. Any kind of complication is only going to make
those functions more complex, and any performance gained could easily be
lost in extra complexity.

There are only two real advantages to deferred writing:

 - not having to do get_block() at all for temp-files, as we never have to
   do the allocation if we end up removing the file.

   NOTE NOTE NOTE! The overhead for trying to get ENOSPC and quota errors
   right is quite possibly big enough that this advantage is possibly very
   questionable.  It's very possible that people could speed things up
   using this approach, but I also suspect that it is equally (if not
   more) possible to speed things up by just making sure that the
   low-level FS has a fast get_block().

 - Using "global" access patterns to do a better job of "get_block()", ie
   taking advantage of issues with journalling etc and deferring the write
   in order to get a bigger journal.

The second point is completely different, and THIS is where I think there
are potentially real advantages. However, I also think that this is not
actually about deferred writes at all: it's really a question of the
filesystem having access to the page when the physical write is actually
started so that the filesystem might choose to _change_ the allocation it
did - it might have allocated a backing store block at "get_block()" time,
but by the time it actually writes the stuff out to disk it may have
allocated a bigger contiguous area somewhere else for the data..

I really think that the #2 thing is the more interesting one, and that
anybody looking at ext2 should look at just improving the locking and
making the block allocation functions run faster. Which should not be all
that difficult - the last time I looked at the thing it was quite
horrible.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4test-ac merge status

[Tom Rini]

On Sun, Dec 31, 2000 at 02:17:12AM +, Alan Cox wrote:

> This is to help give folks an idea of what -ac stuff has been pushed to Linus,
> is still in need of work, has been dumped in the bitbucket of bad ideas etc
> 
> Most of the important driver stuff is now in the Linus tree. There are a few
> I'd like to see sorted before 2.4.0 release still. I'll be working on those
> as a priority. Other stuff like the fusion drivers can wait.

I'm sure at least a few people want to know where the PowerPC port falls in
all of that. :)

...hopeing we aren't in the bitbucket..

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5 / test13-pre7

[Dieter Nützel]

Hello Rik,

I did some more benchmarks on this --- puh, took me some time...:-)

Test machine: 256 MB, K7 550 SlotA, SCSI, IDE, ReiserFS 3.6.23, Blocksize=4K
Test: dbench 48

2.4.0-test13-pre5 + Rik's VM fix #2

/dev/sda7:
 Timing buffered disk reads:  64 MB in  6.07 seconds = 10.54 MB/sec

Throughput 7.54785 MB/sec (NB=9.43482 MB/sec  75.4785 MBit/sec)
41.200u 95.870s 13:59.50 16.3%  0+0k 0+0io 1797pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 7.7981 MB/sec (NB=9.74762 MB/sec  77.981 MBit/sec)
42.180u 96.620s 13:32.54 17.0%  0+0k 0+0io 1799pf+0w

--

/dev/hdc1:
 Timing buffered disk reads:  64 MB in  2.89 seconds = 22.15 MB/sec

Throughput 9.4113 MB/sec (NB=11.7641 MB/sec  94.113 MBit/sec)
36.990u 117.720s 11:13.24 22.9% 0+0k 0+0io 1505pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 10.254 MB/sec (NB=12.8175 MB/sec  102.54 MBit/sec)
36.620u 112.870s 10:17.91 24.1% 0+0k 0+0io 1505pf+0w

***

2.4.0-test13-pre7

/dev/sda7:
 Timing buffered disk reads:  64 MB in  6.07 seconds = 10.54 MB/sec

Throughput 9.61382 MB/sec (NB=12.0173 MB/sec  96.1382 MBit/sec)
43.950u 96.790s 10:59.06 21.3%  0+0k 0+0io 1746pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 10.8312 MB/sec (NB=13.539 MB/sec  108.312 MBit/sec)
44.510u 93.000s 9:44.99 23.5%   0+0k 0+0io 1795pf+0w

-

/dev/hdc1:
 Timing buffered disk reads:  64 MB in  2.89 seconds = 22.15 MB/sec

Throughput 12.3312 MB/sec (NB=15.414 MB/sec  123.312 MBit/sec)
35.220u 112.630s 8:33.83 28.7%  0+0k 0+0io 1505pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 14.4331 MB/sec (NB=18.0414 MB/sec  144.331 MBit/sec)
36.060u 119.760s 7:19.00 35.4%  0+0k 0+0io 1505pf+0w

Addition:
Your fix show some 'bad' swap behavior on my 'normal' load (3D medical 
visualization). It do some 'little' swap out and in. Mostly the (not needed?) 
swap in hurts performance. A little 'cp -a X11R6 X11R6-new' take more than 2 
times longer. If my system hits the 'ZERO swap wall' the currently running 
process (render) abort immediately and restart. With test13-pre7 it runs 
several times longer (render generates some more frames) but then load goes 
up to 10 and render would be killed.

SunWave1>cat /proc/version
Linux version 2.4.0-test13-pre7 (root@SunWave1) (gcc version 2.95.2 19991024 
(release)) #1 Sat Dec 30 22:13:04 CET 2000
SunWave1>free -t
 total   used   free sharedbuffers cached
Mem:255728 164980  90748  0  34160  46488
-/+ buffers/cache:  84332 171396
Swap:   200772  8 200764
Total:  456500 164988 291512

Happy New Year!
I'll be back on Monday.

-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]
Please read the FAQ at http://www.tux.org/lkml/

Linux 2.4test-ac merge status

[Alan Cox]

This is to help give folks an idea of what -ac stuff has been pushed to Linus,
is still in need of work, has been dumped in the bitbucket of bad ideas etc

Most of the important driver stuff is now in the Linus tree. There are a few
I'd like to see sorted before 2.4.0 release still. I'll be working on those
as a priority. Other stuff like the fusion drivers can wait.


2.4.0test13pre7-ac1
o   Merge Linus pre7

2.4.0test13pre6-ac1
o   Merge Linus pre6

2.4.0test13pre5-ac1
o   Merge Linus pre5

2.4.0test13pre4-ac2
o   Merge support for CPU's >2Ghz from 2.2.18
o   Merge core loops_per_jiffy support
o   Merge first batch of driver fixes from 2.2.18
o   Further quota build fix (Jarno Paananen)
o   Make smp cpu halt synchronous   (Andi Kleen)
o   Fix various combinations that don't build   (Arjan van de Ven)
o   Further Fusion driver updates   (Steve Ralston)
o   Alpha makefile fixes(Dave Gilbert)

2.4.0test13pre4-ac1
o   Merge Linus pre4
o   Fix network register/hotplug/publish problems   (Andrew Morton)
o   Hopefully fix quotaless compile (me)
o   Help for irda options question  (Steven Cole)

2.4.0test13pre3-ac4
o   Fix frame size on toshoboe  (Christian Gennerat)
o   Quota fixes/updates (Jan Kara)
o   Fix keyspan usb config  (Hugh Blemings)
o   Fix module handling in usb serial   (Greg Kroah-Hartmann)
o   Fix sparc64 build of fusion drivers (Eddie Dost)
o   Fix eepro module warnings   (Aristeu Filho)
o   Clean up config.h includes  (Niels Jensen)
o   Fix most of the netfilter oops cases(David Miller)

2.4.0test13pre3-ac3 
o   Fix the patch file. Some stuff got corrupted. 

2.4.0test13pre3-ac2 adds
o   Resync with the powerpc folks   (Cort Dougan)
o   Fix appletalk config entry  (William McGonigle)
o   Parport experimental label fix  (Tim Waugh)
o   Make uhci return the same error code as the (David Brownell)
other USB hub controllers
o   Merge Fusion drivers(Steve Ralston)
o   Shared memory fixes (Christoph Rohland)

2.4.0test13pre3-ac1 adds
o   Fix leak in link() syscall  (Christopher Yeoh)
o   Fix ramfs deadlock  (Al Viro)
o   Fix udf deadlock(Al Viro)
o   Improve parport docs(Tim Waugh)
o   Document some of the macros (Tim Waugh)
o   Fix ppa timing issues   (Tim Waugh)
o   Mark the parport fifo code as experimental  (Tim Waugh)
o   Resynch ppa changelog   (Tim Waugh)
| Tim please double check as I got offsets
o   Add documentation to the PCI api(Jani Monoses)
o   Fix inode.c documentation   (Jani Monoses)
o   Fix bug in VFAT short name handling (Nicolas Goutte)
o   Clean up the i810 driver(Tjeerd Mulder)
o   Fix ext2 modular build  (Jeff Raubitschek)
o   Fix bug in scripts/Configure.in matching(Matthew Wilcox)
o   Fix ext2 file size limiting for large files (Andreas Dilger)
o   Clean up misleading indenting in partition code (JAmes Antill)
o   Update SiS video drivers(Can-Ru Yeou)
o   Yamaha audio doc fix(Pavel Roskin)
o   Fix timeout problms with rocktports at 249 days

2.4.0test12-ac1 adds
o   ARM bootup/initd fixes  (Russell King)
o   Fix ymf_sb setup bug(Pavel Roskin)
o   Correctly print names of md10+  (me)
[Based on code from Roberto Ragusa]
o   Fix sound crashes in various drivers(Tjeerd Mulder)
o   Update epic100 to new pci api   (Francois Romieu)
o   Fix IOC/SIOC ioctl problems in ac97 code(Dick Streefland)

To merge
o   Fix Ruffian Alpha boot  (Ivan Kokshaysky)
o   Bridge handling patches needed for Alpha(Ivan Kokshaysky /
Richard Henderson)
o   Acenic update
o   Epic100 update
o   Support mixed pnp and legacy sb cards
o   Hopefully fix the bugs in the FAT and HPFS file systems that
caused fs corruption
o   Fix cramfs vanishing data bug
o   Power management locking fixes
o   filemap posix compliance fix
o   Fix pte handling race
o   Remove unneeded inits to 0 in ide code(Bartlomiej Zolnierkiewicz)
o   

Re: [RFC] Generic deferred file writing

[Roman Zippel]

Hi,

On Sun, 31 Dec 2000, Andrea Arcangeli wrote:

> > estimate than just the data blocks it should not be hard to add an
> > extra callback to the filesystem.  
> 
> Yes, I was thinking at this callback too. Such a callback is nearly the only
> support we need from the filesystem to provide allocate on flush.

Actually the getblock function could be split into 3 functions:
- alloc_block: mostly just decrementing a counter (and quota)
- get_block: allocating a block from the bitmap
- commit_block: inserting the new block into the inode

This would be really useful for streaming, one could get as fast as
possible the block number and the data could be very quickly written,
while keeping the cache usage low. Or streaming directly from a device
to disk also wants to get rid of the data as fast as possible.

bye, Roman

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Problem with ATX halt

[Aaron Lehmann]

On Thu, Dec 28, 2000 at 11:59:06PM -1000, Ryan Sizemore wrote:
>I have a comp. running mandrake 7.2, and when i go to power it down, it
> gives me a screen full of errors, including a stackdump. It happens as the
> very last thing (including being after the file system is unmounted, so I
> highly doubt that the error is recorded somewhere. But i will hand-copy the
> stack for whomever thinks it may be useful. The error is reproduced every
> time, without equivication. Any insight or questions are much apriciated.
> The motherboard is a Soyo 5EMA+ r1.0 w/ ETEQ EQ82C6638 Chipset, and it has
> an Award BIOS.

A BIOS upgrade fixes this, as well as some major problems
with large IDE drives. I have the same motherboard and had
the same problem until I updated the BIOS. Their ChangeLog
even says "Systems running Linux can now properly shutdown."
http://www.soyo.com.tw/cgi-bin/prodinfo.exe?track=regular=5EMAFamily=1 
will get you to the page, and get the latest file
for the 5EMA+. In fact, I'll even be kind enough to provide the
disk image I used with DOS and the bios image and updater on
it. Put in a blank 1.4MB floppy disk, download this file from
http://vitelus.com/aaronl/biosdisk.img, and run as root:

  dd if=biosdisk.img of=/dev/fd0 bs=512 conv=sync ; sync

Then boot of the floppy and run the updater with the bios file as an
argument. I forget which is which but the updater ends in .EXE and the
bios image ends in .BIN.

Let it finish and reboot into Linux. Good luck.

Software piracy nazis, M$: No flames, please.

 PGP signature

Re: [RFC] Generic deferred file writing

[Alexander Viro]

On Sun, 31 Dec 2000, Andrea Arcangeli wrote:

> On Sat, Dec 30, 2000 at 03:00:43PM -0700, Eric W. Biederman wrote:
> > To get ENOSPC handling 99% correct all we need to do is decrement a counter,
> > that remembers how many disks blocks are free.  If we need a better
> 
> Yes, we need to add one field to the in-core superblock to do this accounting.

And its meaning for 2/3 of filesystems would be?

> > estimate than just the data blocks it should not be hard to add an
> > extra callback to the filesystem.  
> 
> Yes, I was thinking at this callback too. Such a callback is nearly the only
> support we need from the filesystem to provide allocate on flush. Allocate on
> flush is a pagecache issue, not really a filesystem issue. When a filesystem

I _doubt_ it. If it is a pagecache issue it should apply to NFS. It should
apply to ramfs. It should apply to helluva lot of filesystems that are not
block-based. Pagecache doesn't (and shouldn't) know about blocks.

> doesn't implement such callback we can simply get_block(create) at pagecache
> creation time as usual.

Umm... You do realize that get_block is _not_ visible on pagecache level?
Sure thing, filesystem should be free to use whatever functions it wants
for address_space methods. No arguments here. It should be able whatever
callbacks these functions expect. If filesystem doesn't implement reservation
it should use functions that do not expect such argument. That's it. No
need to invent new methods or shoehorn all block filesystems into the same
scheme.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

oops with 2.4.0-test13-pre7 in acpi_ns_get_next_object

[Manfred]

As I wrote in the subject line I get an oops with 2.4.0-test13-pre7.

Board: Gigabyte BXD with newest BIOS, Dual processor

Previous kernels ( <=-test12) just printed

ACPI: support found
ACPI: PBLK 0 @ 0x:0
ACPI: PBLK 1 @ 0x:0
-0196: *** Error: Sleep State package elements are not both of type
number

Now I get the attached oops.
I've tracked it back into acpi_ns_get_next_object: that function is
called with both child_node and parent_node == NULL, and then the line

if (parent_node->child)

oopses.

If you need further infos, please ask.

--
Manfred

ACPI: System description tables found
ACPI: System description tables loaded
Unable to handle kernel NULL pointer dereference at virtual address 0010
 printing eip:
c01d7583
*pde = 
Oops: 
CPU:0
EIP:0010:[acpi_ns_get_next_object+19/76]
EFLAGS: 00010246
eax:    ebx:    ecx: 54594247   edx: 
esi:    edi: 008d   ebp:    esp: cbf33f34
ds: 0018   es: 0018   ss: 0018
Process kacpid (pid: 7, stackpage=cbf33000)
Stack:  c01d75fb    c01ce2f4  cbf32331 
   cbf32000 08010646 c01d7d16 0008 cbf3afc0  0001 c01ce2f4 
     0008  c0269e55 c01ce39c 0008 cbf3afc0 
Call Trace: [acpi_ns_walk_namespace+63/260] [acpi_ev_save_method_info+0/120] 
[acpi_walk_namespace+70/92] [acpi_ev_save_method_info+0/120] [_acpi_ctype+12949/25696] 
[acpi_ev_init_gpe_control_methods+48/56] [acpi_ev_save_method_info+0/120] 
   [acpi_ev_initialize+74/100] [acpi_enable_subsystem+62/104] 
[acpi_thread+163/540] [empty_bad_page+0/4096] [empty_bad_page+0/4096] 
[startup_32+24/203] [kernel_thread+26/48] [kernel_thread+35/48] 
Code: 8b 40 10 85 c0 74 11 89 c2 eb 0d 89 f6 50 e8 be ff ff ff 89 

Disassembly:
(gdb) x/30i acpi_ns_get_next_object
0xc01d7570 :   push   %ebx
0xc01d7571 : xor%edx,%edx
0xc01d7573 : mov0x10(%esp,1),%eax
0xc01d7577 : mov0x8(%esp,1),%bl
0xc01d757b :test   %eax,%eax
0xc01d757d :jne0xc01d7590 

0xc01d757f :mov0xc(%esp,1),%eax
0xc01d7583 :mov0x10(%eax),%eax
0xc01d7586 :test   %eax,%eax
0xc01d7588 :je 0xc01d759b 

0xc01d758a :mov%eax,%edx
0xc01d758c :jmp0xc01d759b 

0xc01d758e :mov%esi,%esi
0xc01d7590 :push   %eax
0xc01d7591 :call   0xc01d7554 

0xc01d7596 :mov%eax,%edx
0xc01d7598 :add$0x4,%esp
0xc01d759b :test   %bl,%bl
0xc01d759d :jne0xc01d75b3 

0xc01d759f :mov%edx,%eax
0xc01d75a1 :jmp0xc01d75b9 

0xc01d75a3 :cmp%bl,0x1(%edx)
0xc01d75a6 :je 0xc01d759f 

0xc01d75a8 :push   %edx
0xc01d75a9 :call   0xc01d7554 

0xc01d75ae :mov%eax,%edx
0xc01d75b0 :add$0x4,%esp
0xc01d75b3 :test   %edx,%edx
0xc01d75b5 :jne0xc01d75a3 

0xc01d75b7 :xor%eax,%eax
(gdb) quit

Re: [RFC] Generic deferred file writing

[Eric W. Biederman]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> On 30 Dec 2000, Eric W. Biederman wrote:
> > 
> > One other thing to think about for the VFS/MM layer is limiting the
> > total number of dirty pages in the system (to what disk pressure shows
> > the disk can handle), to keep system performance smooth when swapping.
> 
> This is a separate issue,  and I think that it is most closely tied in to
> the "RSS limit" kind of patches because of the memory mapping issues. If
> you've seen the RSS rlimit patch (it's been posted a few times this week),
> then you could think of that modified by a "Resident writable pages Set
> Size" approach. 

Building on the RSS limit approach sounds much simpler then they way
I was thinking.

> Not just for shared mappings - this is also an issue with
> limiting swapout.
> 
> (I actually don't think that RSS is all that interesting, it's really the
> "potentially dirty RSS" that counts for VM behaviour - everything else can
> be dropped easily enough)

Definitely.

Now the only tricky bit is how do we sense when we are overloading
the swap disks.  Well that is the next step.  I'll take a look
and see what it takes to keep statistics on dirty mapped pages.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: TEST13-PRE7 - Nvidia Kernel Module Compile Problem

[davej]

On Sat, Dec 30, 2000 at 07:54:21PM +, Tony Spinillo wrote:
>   The nvidia kernel module (from www.nvidia.com) has compiled and loaded
>   correctly with all test13-pre series up to pre6. I just tried to
>   compile and load under pre7.
>   I got the following:
>   nv.c:860:unknown field `unmap' specified in initializer
>   nv.c:860:warning: initialization from incompatible pointer type
>   make:*** [nv.o] Error 1

Delete the unmap: line somewhere near line 868 of nv.c
Seems to be working fine here.

regards,

Davej.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: tdfx.o and -test13

[Frank Jacobberger]

Alan Cox wrote:

> > >  +#include 
> > >   #include 
> > >   #include 
> > >   #include 
> >
> > I just want to confirm that this small fix solves my drm
> > problems as well - currently running -test13-pre7
> >
> > Er, has anybody sent a patch to the maintainers?
>
> Wrong patch. Modversions.h should be getting automatically included. That
> is what needs fixing. You've nicely located the problem and fixed the symptoms
> for the module versioned case

This "patch" apparently has been around since test13-pre1. I guess the
maintainers are on vacation.

Frank


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Generic deferred file writing

[Andrea Arcangeli]

On Sat, Dec 30, 2000 at 03:00:43PM -0700, Eric W. Biederman wrote:
> To get ENOSPC handling 99% correct all we need to do is decrement a counter,
> that remembers how many disks blocks are free.  If we need a better

Yes, we need to add one field to the in-core superblock to do this accounting.

> estimate than just the data blocks it should not be hard to add an
> extra callback to the filesystem.  

Yes, I was thinking at this callback too. Such a callback is nearly the only
support we need from the filesystem to provide allocate on flush. Allocate on
flush is a pagecache issue, not really a filesystem issue. When a filesystem
doesn't implement such callback we can simply get_block(create) at pagecache
creation time as usual.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: tdfx.o and -test13

[Alan Cox]

> >  +#include 
> >   #include 
> >   #include 
> >   #include 
> 
> I just want to confirm that this small fix solves my drm
> problems as well - currently running -test13-pre7
> 
> Er, has anybody sent a patch to the maintainers?

Wrong patch. Modversions.h should be getting automatically included. That
is what needs fixing. You've nicely located the problem and fixed the symptoms 
for the module versioned case

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

TEST13-PRE7 - Nvidia Kernel Module Compile Problem

[Tony Spinillo]

The nvidia kernel module (from www.nvidia.com) has compiled and loaded
correctly with all test13-pre series up to pre6. I just tried to
compile and load under pre7.
I got the following:
nv.c:860:unknown field `unmap' specified in initializer
nv.c:860:warning: initialization from incompatible pointer type
make:*** [nv.o] Error 1

Is this due to a problem with the recent makefile changes or a problem
with the nvidia module?

Thanks!

Tony

The output for ver_linux:

Kernel modules 2.3.23
Gnu C  egcs-2.91.66
Gnu Make   3.79.1
Binutils   2.10.0.24
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.7
Mount  2.10o
Net-tools  1.57
Console-tools  0.2.3
Sh-utils   2.0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: tdfx.o and -test13

[J Sloan]

Dieter Nützel wrote:

> It haven't loaded since test13-pre1 for me.
> Only the 'module version' was broken.
> Last test12-pre7 was fine, here.
> It was introduced with the Makefile cleanups.
>
>  --- linux/drivers/char/drm/drmP.oldThu Dec 28 16:27:34 2000
>  +++ linux/drivers/char/drm/drmP.hSat Dec 23 13:57:08 2000
>  @@ -40,6 +40,7 @@
>   #include 
>   #endif /* __alpha__ */
>   #include 
>  +#include 
>   #include 
>   #include 
>   #include 

I just want to confirm that this small fix solves my drm
problems as well - currently running -test13-pre7

Er, has anybody sent a patch to the maintainers?

jjs




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Problems with ov511/USB on test13-pre7

[Erik Mouw]

On Sat, Dec 30, 2000 at 11:24:40PM +, [EMAIL PROTECTED] wrote:
>  Problems with Creative Webcam III. This worked fine
> in test13-pre4, haven't tried pre5 & 6.

[snip]

> USB controller is:
> 
> 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if
> 00 [UHCI])
> Subsystem: Unknown device 0925:1234
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> SERR-  Latency: 32, cache line size 08
> Interrupt: pin D routed to IRQ 5
> Region 4: I/O ports at d400 [size=32]
> Capabilities: [80] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-

This looks like some kind of UHCI problem. I have the same camera
(well, it is a Creative Webcam plus, but same chipset) with an Intel
UHCI controller and I haven't seen any errors. Here is my USB
controller:

00:07.2 USB Controller: Intel Corporation 82440MX USB Universal Host
Controller (prog-if 00 [UHCI])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- SERR- http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Alpha: memmove fix - worked!

[Dave Gilbert]

Hi,
  Thanks to everyone who helped out on my NFS problem -> memmove screw up
- pre7 built out of the box and seems to have fixed it.

Dave

-- 
  Have a happy GNU millennium! --   
/ Dr. David Alan Gilbert  | Running GNU/Linux on   |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 \ ___|___ http://www.treblig.org  |/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: multiple mount of devices possible 2.4.0-test1 - 2.4.0-test13-pre4

[Alexander Viro]

On Sat, 30 Dec 2000, Ton Hospel wrote:

> It should still need a special flag or something, since it's
> impossible for userspace to check this atomically.

To check _what_? Having the same tree mounted in several places is
allowed. End of story. Atomicity of any kind is a non-issue - if you
have processes that do not cooperate and do random mounts you are
getting exactly what you are asking for.

BTW, mount(2) is outside of POSIX scope. Ditto for SuS, so references to
standards are not likely to work. Not allowing multiple mounts of the same
fs was an artifact of original namei() implementation. At some point
(late 80s) it had been fixed by Bell Labs folks in their branch. In Linux
it had been fixed during the last spring. That's it. You were never promised
that multiple mounts will not work. Moreover, in special cases they did work
since long - e.g. Linux procfs could be mounted in several places since
'94, if not earlier. AFAIK NFS implementations allowed the same thing
since mid-80s...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Generic deferred file writing

[Daniel Phillips]

On Sat, 30 Dec 2000, Alexander Viro wrote:
> Well, see above. I'm pretty nervous about breaking the ordering of metadata
> allocation. For pageout() we don't have such ordering. For write() we
> certainly do. Notice that reserving disk space upon write() and eating it
> later is _very_ messy job - you'll have to take care of situations when
> we reserve the space upon write() and get pageout do the real allocation.
> Not nice, since pageout has no way in hell to tell whether it is eating
> from a reserved area or just flushing the mmaped one. We could keep the
> per-bh "reserved" flag to fold that information into the pagecache, but
> IMO it's simply not worth the trouble. If some filesystems wants that -
> hey, it can do that right now. Just make ->prepare_write() do reservations
> and let ->commit_write() mark the page dirty. Then ->writepage() will
> eventually flush it.

This is a refinement of the idea and some abstraction like that is
clearly needed, and maybe that is exactly the right one.  For now I'm
interested in putting this on the table so that we can check the
stability and performance, maybe uncover come more bugs, then start
going after some of the things that need to be done to turn it into a
useful option.

P.S., I humbly apologize for writing (!offset && bytes == PAGE_SIZE)
when I could have just written (bytes == PAGE_SIZE).

-- 
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Problems with ov511/USB on test13-pre7

[davej]

Hi,

 Problems with Creative Webcam III. This worked fine
in test13-pre4, haven't tried pre5 & 6.

On boot:

 usb_control/bulk_msg: timeout
 usb_control/bulk_msg: timeout
 usb.c: couldn't get all of config descriptors
 usb.c: unable to get device 2 configuration (error=-110)
 hub.c: USB new device connect on bus1/1, assigned device number 4
 usb_control/bulk_msg: timeout
 usb.c: USB device not accepting new address=4 (error=-110)

On remove/reinsert:

 hub.c: USB new device connect on bus1/1, assigned device number 5
 usb_control/bulk_msg: timeout
 usb.c: USB device not accepting new address=5 (error=-110)
 hub.c: USB new device connect on bus1/1, assigned device number 6
 usb_control/bulk_msg: timeout
 usb.c: USB device not accepting new address=6 (error=-110)

USB controller is:

00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if
00 [UHCI])
Subsystem: Unknown device 0925:1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: multiple mount of devices possible 2.4.0-test1 - 2.4.0-test13-pre4

[Ton Hospel]

In article <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sat, 23 Dec 2000 [EMAIL PROTECTED] wrote:
>> 
>> 1. multiple mount of devices possible 2.4.0-test1 - 2.4.0-test13-pre4
>> 
>> 2. its still possible to mount devices several times.
>>IMHO it shouldnt be possible like 2.2.18
> 
> No.
> 
> The multi-mount thing is a _major_ feature, and the fact that your "mount"
> binary seems to be confused by it is a user-level problem and nothing
> more.
> 
It should still need a special flag or something, since it's
impossible for userspace to check this atomically.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

NIC recommendations (was Re: Repeatable 2.4.0-test13-pre4...)

[Barry K. Nathan]

Andrew Morton wrote:
> The 3c905C is a well manufactured and very feature-rich NIC which at
> present appears to have fewer problem reports than eepro100, 8139 or tulip.

3c905c is a bit expensive, though. pcnet32 cards also work very well for
me, and are less expensive. The 905c could be a better card (I don't
really know), but pcnet32's might be more cost-effective, depending
on your needs. (I've seen pcnet32-based cards selling for $15-20, and
I bought a new 10-pack (of HP NightDirector 10/100's) for about $36,
including shipping, on eBay.)
 
In any case, tulips have been more problematic for me than 8139, pcnet32,
or 3c905c (whose reliability are all comparable IME). I've never tried
eepro100, though. (Also, I'm speaking in terms of my experiences across
all OS's which I've used the cards under, not just under Linux, although
my Linux experiences are similar to the experiences I've had overall.)

Anyway, those are my experiences and recommendations. YMMV. :)

-Barry K. Nathan <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Generic deferred file writing

[Linus Torvalds]

On 30 Dec 2000, Eric W. Biederman wrote:
> 
> One other thing to think about for the VFS/MM layer is limiting the
> total number of dirty pages in the system (to what disk pressure shows
> the disk can handle), to keep system performance smooth when swapping.

This is a separate issue, and I think that it is most closely tied in to
the "RSS limit" kind of patches because of the memory mapping issues. If
you've seen the RSS rlimit patch (it's been posted a few times this week),
then you could think of that modified by a "Resident writable pages Set
Size" approach. Not just for shared mappings - this is also an issue with
limiting swapout.

(I actually don't think that RSS is all that interesting, it's really the
"potentially dirty RSS" that counts for VM behaviour - everything else can
be dropped easily enough)

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Generic deferred file writing

[Eric W. Biederman]

Linus Torvalds <[EMAIL PROTECTED]> writes:


> In short, I don't see _those_ kinds of issues. I do see error reporting as
> a major issue, though. If we need to do proper low-level block allocation
> in order to get correct ENOSPC handling, then the win from doing deferred
> writes is not very big.

To get ENOSPC handling 99% correct all we need to do is decrement a counter,
that remembers how many disks blocks are free.  If we need a better
estimate than just the data blocks it should not be hard to add an
extra callback to the filesystem.  

There look to be some interesting cases to handle when we fill up a
filesystem.  Before actually failing and returning ENOSPC the
filesystem might want to fsync itself. And see how correct it's
estimates were.  But that is the rare case and shouldn't affect
performance.


In the long term VFS support for deferred writes looks like a major
win.  Knowing how large a file is before we write it to disk allows
very efficient disk organization, and fast file access (esp combined
with an extent based fs).   Support for compressing files in real time
falls out naturally.  Support for filesystems maintain coherency by
never writing the same block back to the same disk location also
appears.


One other thing to think about for the VFS/MM layer is limiting the
total number of dirty pages in the system (to what disk pressure shows
the disk can handle), to keep system performance smooth when swapping.
All cases except mmaped files are easy, and they can be handled by a
modified page fault handler that directly puts the dirty bit on the
struct page.  (Except that is buggy with respect to clearing the dirty
bit on the struct page.)  In reality we would have to create a queue
of pointers to dirty pte's from the page fault handler and depending
on a timer or memory pressure move the dirty bits to the actual page.

Combined with the code to make sync and fsync to work on the page
cache we msync would be obsolete?

Of course the most important part is that when all of that is
working, the VFS/MM layer it would be perfect.  World domination
would be achieved.  For who would be caught using an OS with an
imperfect VFS layer :)

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.2.18 Oops..

[Mike A. Harris]

Dist:   Red Hat 7.0
Kernel: Using 2.2.18 + IDE patches.


My lilo.conf:

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
#timeout=50
message=/boot/message
default=linux
vga=ext

image=/boot/bzImage-2.2.18-1NSRI
label=linux
read-only
root=/dev/hda3
append="hdc=ide-scsi hdd=ide-cd mem=96M splitfifo=1"



[ksymoops output]

Options used: -V (default)
  -o /lib/modules/2.2.18-1NSRI/ (default)
  -k /proc/ksyms (default)
  -l /proc/modules (default)
  -m /boot/System.map-2.2.18-1NSRI (specified)
  -c 1 (default)

Reading Oops report from the terminal
Dec 30 12:00:12 asdf kernel: Unable to handle kernel paging
request at virtual address 1c385e13
Dec 30 12:00:12 asdf kernel: current->tss.cr3 = 0450f000, %%cr3 =
0450f000
Dec 30 12:00:12 asdf kernel: *pde = 
Dec 30 12:00:12 asdf kernel: Oops: 0002
Dec 30 12:00:12 asdf kernel: CPU:0
Dec 30 12:00:12 asdf kernel: EIP:0010:[do_gettimeofday+28/108]
Dec 30 12:00:12 asdf kernel: EFLAGS: 00010206
Dec 30 12:00:12 asdf kernel: eax: 004e   ebx: 0206   ecx:
   edx: 0018
Dec 30 12:00:12 asdf kernel: esi: c2237fb8   edi: 50011f5c   ebp:
   esp: c2237f98
Dec 30 12:00:12 asdf kernel: ds: 0018   es: 0018   ss: 0018
Dec 30 12:00:12 asdf kernel: Process netscape-commun (pid: 19385,
process nr: 63, stackpage=c2237000)
Dec 30 12:00:12 asdf kernel: Stack: c2237fb8 c0115f55 c2237fb8
c2236000 50011f7c 08941738 50011f64 
Dec 30 12:00:12 asdf kernel: 50011c50 c01079cc
50011f5c   50011f7c 08941738
Dec 30 12:00:12 asdf kernel:50011f64 004e 002b
002b 004e 4029b0c1 0023 0202
Dec 30 12:00:12 asdf kernel: Call Trace:
[sys_gettimeofday+29/148] [system_call+52/56]
Dec 30 12:00:12 asdf kernel: Code: c0 8b 0d 5c 38 1c c0 85 c9 74
15 89 c8 c1 e0

Code:   Before first symbol <_IP>:
<===
Code:   Before first symbol   0:c0 8b 0d
5c 38 1c c0   rorb   $0xc0,0x1c385c0d(%ebx) <===
Code:  0007 Before first symbol   7:85 c9
test   %ecx,%ecx
Code:  0009 Before first symbol   9:74 15
je  0020 Before first symbol
Code:  000b Before first symbol   b:89 c8
mov%ecx,%eax
Code:  000d Before first symbol   d:c1 e0 00
shl$0x0,%eax


66 warnings issued.  Results may not be reliable.


hdparm is NOT being used to enable anything - just using default
kernel bootup config for all drives:

/dev/hda:
 multcount=  0 (off)
 I/O support  =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 3737/255/63, sectors = 60036480, start = 0

/dev/hdb:
 multcount=  0 (off)
 I/O support  =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 935/255/63, sectors = 15032115, start = 0


-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux asdf.capslock.lan 2.2.18-1NSRI #1 Fri Dec 22 01:34:55 EST
2000 i586 unknown
Kernel modules 2.3.21
Gnu C  2.96
Binutils   2.10.0.18
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.7
Mount  2.10m
Net-tools  1.56
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded ide-scsi scsi_mod ne2k-pci 8390 agpgart
devpts vfat fat opl3 sb uart401 sound soundlow soundcore



Although it shows gcc2.96 above, my kernel is built with:

2 root@asdf:/home/mharris/src/linux-2.2.18-1NSRI/scripts# dmesg
Linux version 2.2.18-1NSRI ([EMAIL PROTECTED]) (gcc
version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Fri
Dec 22 01:34:55 EST 2000

The Oops occured during system idle time.  Nothing significant
was occuring on the machine.  The only thing I can think of is
that last night I used my CD burner with xcdroast for the first
time in 2.2.18.  xcdroast was still running when i saw the oops.
Netscape shows up in the Oops report, but Netscape was not
running when I found it.  The system was not hard locked, but was
able to shut down.  Upon rebooting, I had to mount read-only, and
do fsck manually (forced) on all fs's.  2 partitions had serious
problems /var/log, and /var/spool.  A lot of log files got
trashed in the process.

;o(

.config attached



--
Mike A. Harris  -  Linux advocate  -  Free Software advocate
  This message is copyright 2000, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
--

Be up to date 

Re: [RFC] Generic deferred file writing

[Alexander Viro]

On Sat, 30 Dec 2000, Linus Torvalds wrote:

> 
> 
> On Sat, 30 Dec 2000, Alexander Viro wrote:
> > 
> > Except that we've got file-expanding writes outside of ->i_sem. Thanks, but
> > no thanks.
> 
> No, Al, the file size is still updated inside i_sem.

Then we are screwed. Look: we call write(). Twice. The second call happens
to overflow the quota. Getting the second chunk of data written and the
first one ending up as a hole is the last thing you would expect, isn't it?

> In short, I don't see _those_ kinds of issues. I do see error reporting as
> a major issue, though. If we need to do proper low-level block allocation
> in order to get correct ENOSPC handling, then the win from doing deferred
> writes is not very big.

Well, see above. I'm pretty nervous about breaking the ordering of metadata
allocation. For pageout() we don't have such ordering. For write() we
certainly do. Notice that reserving disk space upon write() and eating it
later is _very_ messy job - you'll have to take care of situations when
we reserve the space upon write() and get pageout do the real allocation.
Not nice, since pageout has no way in hell to tell whether it is eating
from a reserved area or just flushing the mmaped one. We could keep the
per-bh "reserved" flag to fold that information into the pagecache, but
IMO it's simply not worth the trouble. If some filesystems wants that -
hey, it can do that right now. Just make ->prepare_write() do reservations
and let ->commit_write() mark the page dirty. Then ->writepage() will
eventually flush it.

Again, if one is willing to implement reservation on block level - fine,
there is no need to change anything in VFS or VM. I certainly don't want
to mess with that, but hey, if somebody is into masochism - let them.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

system freeze question

[jim m.]

hi,
there are times when newly installed driver just freezes the
RH6.2 and mouse cursor is rock solid frozen. ALT+PRTScreen+...
does not work. I now for fact that ALT+PRT... works because
i tested it. Anything else can be done to reboot the system
graciously than "reset"?.  Any advice..
J
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Generic deferred file writing

[Andreas Dilger]

Linus writes:
> In short, I don't see _those_ kinds of issues. I do see error reporting as
> a major issue, though. If we need to do proper low-level block allocation
> in order to get correct ENOSPC handling, then the win from doing deferred
> writes is not very big.

It should be relatively light-weight to call into the filesystem simply
to allocate a "count" of blocks needed for the current file.  It may
even be possible to do delayed inode allocation.  This would defer
the inode/block bitmap searching/allocation on ext2 until the file
was actually written - only the free_blocks/free_inodes count in the
superblock would be decremented, and we would get ENOSPC immediately
if we don't have enough space for the file.  On fsck, these values are
recalculated from the group descriptors on ext2, so it wouldn't be a
problem if the system crashed with pre-allocated blocks.

It would definitely be a win on ext2 and XFS, and if it isn't possible
on other filesystems, it should at least not be a loss.

We would need to ensure we also keep enough space for indirect blocks
and such, so we need to pass more information than just the number of
blocks added (i.e. how big the file already is).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Bugs in knfsd -- Problem re-exporting an NFS share

[Andrzej Krzysztofowicz]

> On Friday December 29, [EMAIL PROTECTED] wrote:
> > Hi -- could you please CC me if you reply to this mail.
> > 
> > A: /exports/A - Redhat 7.0
> > B1/B2: mount /exports/A on /export/A from A   - Redhat 6.2
> > C: mount /exports/A on /mnt/A from B1 or B2   - Redhat 6.2
> > 
> > I use knfsd/nfs-utils on each machine.
> > 
> > bash# ls /mnt/A
> > /mnt/A/A.txt: No such file or directory
> 
> This is not a supported configuration.  You cannot export NFS mounted
> filesystems with NFS. The protocol does not cope, and it
> implementation doesn't even try.
> NFS is for export local filesystems only.

As I understand problem is somewhere else.
If this is intentionally unsupported configuration - OK. So why the error
appears ? The directory should be empty then.

If the configuration is unsupported at the moment and the  A.txt file is
located on A, some code that attempts to read re-exported files/directories
should be turned off (eg. #if 0).

If the A.txt file is local for B1/B2 hosts, it is (IMHO) an obvious bug.
Sucgh a file should be hidden at the act of mounting. For both local and
remote access.

Neil, could you tell us where the A.txt file is *really* located ?

Regards 
   Andrzej

BTW. AFAIR, I observed similar behaviour (files are visible but
 inaccessible) while mounting a local filesystem at a busy directory
 (eg.: mount /dev/fd0 .;ls -l) even in 2.2...

-- 
===
  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]
Please read the FAQ at http://www.tux.org/lkml/

test13-pre7...

[Linus Torvalds]

The LDT fixes in particular fix some potentially random strange behaviour.
And the alpha memmove() thing was a showstopper bug on alphas.

Linus



 - pre7:
   - x86 LDT handling fixes: revert some cleanups (the LDT really
 doesn't act like a TLB context)
   - Richard Henderson: alpha update (working memmove() from Ivan
 Kokshaysky etc)
   - Manfred: winbond-840.c net driver update (fix oops on module unload etc)
   - Alan Cox: more synchronizations (with some fixes from Andrew Morton)

 - pre6:
   - Marc Joosen: BIOS int15/e820 memory query: don't assume %edx
 unchanged by the BIOS. Fixes at least some IBM ThinkPads.
   - Alan Cox: synchronize
   - Marcelo Tosatti & me: properly sync dirty pages
   - Andreas Dilger: proper ext2 compat flag checking

 - pre5:
   - NIIBE Yutaka: SuperH update
   - Geert Uytterhoeven: m68k update
   - David Miller: TCP RTO calc fix, UDP multicast fix etc
   - Duncan Laurie: ServerWorks PIRQ routing definition.
   - mm PageDirty cleanups, added sanity checks, and don't lose the bit. 

 - pre4:
   - Christoph Rohland: shmfs cleanup
   - Nicolas Pitre: don't forget loop.c flags
   - Geert Uytterhoeven: new-style m68k Makefiles
   - Neil Brown: knfsd cleanups, raid5 re-org
   - Andrea Arkangeli: update to LVM-0.9
   - LC Chang: sis900 driver doc update
   - David Miller: netfilter oops fix
   - Andrew Grover: acpi update

 - pre3:
   - Christian Jullien: smc9194: proper dev_kfree_skb_irq
   - Cort Dougan: new-style PowerPC Makefiles
   - Andrew Morton, Petr Vandrovec: fix run_task_queue
   - Christoph Rohland: shmfs for shared memory handling

 - pre2:
   - Kai Germaschewski: ISDN update (including Makefiles)
   - Jens Axboe: cdrom updates
   - Petr Vandrovec; Matrox G450 support
   - Bill Nottingham: fix FAT32 filesystems on 64-bit platforms
   - David Miller: sparc (and other) Makefile fixup
   - Andrea Arkangeli: alpha SMP TLB context fix (and cleanups)
   - Niels Kristian Bech Jensen: checkconfig, USB warnings
   - Andrew Grover: large ACPI update

 - pre1:
   - me: drop support for old-style Makefiles entirely. Big.
   - me: check b_end_io at the IO submission path
   - me: fix "ptep_mkdirty()" (so that swapoff() works correctly)
   - fix fault case in copy_from_user() with a constant size, where
 ((size & 3) == 3)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre6 weird with tdfx.o

[Dieter Nützel]

> J Sloan wrote:
>
> > Frank Jacobberger wrote:
> >
> > > This is a first for tdfx.o not loading with XFree 4.01.
> > >
> > > All prior kernel build through test13-pre5 would load just fine...
> > >
> > > Strange...
> >
> > Very strange - others on this list, self included,
> > have reported something a bit different:
> >
> > tdfx.o has not loaded in any kernel since -test12.

It haven't loaded since test13-pre1 for me.
Only the 'module version' was broken.
Last test12-pre7 was fine, here.
It was introduced with the Makefile cleanups.

[snip]
> Hi,
>
> This is lets it load.   The same missing symbols happen with mga as well... 
> This is from a patch posted here two weeks ago:
>
> --- linux/drivers/char/drm/drmP.oldThu Dec 28 16:27:34 2000
> +++ linux/drivers/char/drm/drmP.hSat Dec 23 13:57:08 2000
> @@ -40,6 +40,7 @@
>  #include 
>  #endif /* __alpha__ */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 
> Not sure if this is more than a temporay fix though.
>
> Ed Tomlins
[snip]

I think this patch is very fine.
It works here without a hitch.
Rik?

> > The makefile changes have broken it.
> >
> > Are you certain tdfx.o loads for you in prior -test13
> > versions? If so, that would be a most disturbing
> > development...
> >
> > jjs
>
> Yes your right... I just haven't noticed... Why doesn't someone fix it?
>
> Frank

I am involved a little bit into the DRI development and I think it is because 
all the DRI guys (VA Linux) especially Rik Faith are out for vacation...:-)

Happy New Year!

-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]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Generic deferred file writing

[Linus Torvalds]

On Sat, 30 Dec 2000, Alexander Viro wrote:
> 
> Except that we've got file-expanding writes outside of ->i_sem. Thanks, but
> no thanks.

No, Al, the file size is still updated inside i_sem.

Yes, it will do actual block allocation outside i_sem, but that is already
true of any mmap'ed writes, and has been true for a long long time. So if
we have a bug here (and I don't think we have one), it's not something
new. But the inode semaphore doesn't protect the balloc() data structures
anyway, as they are filesystem-global.

If you're nervous about the effects of "truncate()", then that should be
handled properly by truncate_inode_pages().

In short, I don't see _those_ kinds of issues. I do see error reporting as
a major issue, though. If we need to do proper low-level block allocation
in order to get correct ENOSPC handling, then the win from doing deferred
writes is not very big.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Generic deferred file writing

[Alexander Viro]

On Sat, 30 Dec 2000, Daniel Phillips wrote:

> When I saw you put in the if (PageDirty) -->writepage and related code
> over the last couple of weeks I was wondering if you realize how close
> we are to having generic deferred file writing in the VFS.  I took some
> time today to code this little hack and it comes awfully close to doing
> the job.  However, *** Warning, do not run this on a machine you care
> about, it will mess it up ***.
> 
> The advantages of deferred file writing are pretty obvious.  Right now
> we are deferring just the writeout of data to the disk, but we can also
> defer the disk mapping, so that metadata blocks don't have to stay
> around in cache waiting for data blocks to get mapped into them one at
> a time - a whole group can be done in one flush.

Except that we've got file-expanding writes outside of ->i_sem. Thanks, but
no thanks.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Generic deferred file writing

[Linus Torvalds]

On Sat, 30 Dec 2000, Daniel Phillips wrote:
>
> When I saw you put in the if (PageDirty) -->writepage and related code
> over the last couple of weeks I was wondering if you realize how close
> we are to having generic deferred file writing in the VFS.

I'm very aware of it indeed. 

However, it does break various common assumptions, one of them being
proper error handling. Things like proper detection of quota overflows and
even simple "out of disk space" issues. 

One of the main advantages of deferred writing would be that we could do
temp-files without ever actually doing most of the low-level filesystem
block allocation, but in order to get that advantage we really need to
handle the out-of-disk case gracefully.

I considered doing something like this as a mount option, so that people
could decide on their own whether they want a safe filesystem, or whether
it's ok to do deferred writes. People might find it worth it for /tmp, but
might be unwilling to use it for /var/spool/mail, for example.

(Hmm.. It might be perfectly fine for /vsr/spool/mail - mail delivery
tends to be really careful about doing "fsync()" etc and actually pick up
the errors that way. HOWEVER, before doing that you should expand the
writepage logic to set the page "error" bit for when it fails to write out
a full page - right now we just lose the error completely).

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

SYM-2 driver released (:=sym53c8xx+ncr53c8xx).

[Gérard Roudier]

I just released sym-2.1.0 driver, that, according to my personnal QA 
plan :-), is the first Beta-release of this major driver version.

People interested in either using or just trying it can found the
reference tarball at the following URL:

ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/sym-2.1.0-20001230.tar.gz

This driver replaces functionnaly both sym53c8xx and ncr53c8xx.
It is in fact the FreeBSD sym driver that got portable and that, for now, 
also supports Linux.

The driver reference sources layout is the following:

Common:
sym_conf.h   sym_defs.h  sym_fw.csym_fw.h
sym_fw1.hsym_fw2.h   sym_hipd.c  sym_hipd.h
sym_malloc.c sym_misc.h  sym_nvram.c

FreeBSD:
sym_glue.c   sym_glue.h

Linux:
sym53c8xx.h  sym_glue.c  sym_glue.h

All the files can also be clicked/clipped :) individually from the 
the following directory:

   ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/current/

Given the genealogy of this driver, I have decided to maintain a high 
level of compatibility with the sym53c8xx driver under Linux.
But, due to the number of sources files (14 under Linux), the driver 
sources will now own a separate directory instead of being dropped in 
the huge drivers/scsi/ directory.

The installation procedure supplied in the tarball moves the files to:

   /usr/linux/drivers/scsi/sym53c8xx/

As a result, a tiny patch is needed for the related kernel files to 
be aware of the new driver files location. And, as I have limited 
time, only patches for 2.2.16, 2.2.17 and 2.2.18 are supplied for now.

People who will succeed installing the driver on other Linux kernel 
releases, especially recent ones, can send me the corresponding tiny 
kernel patch. Btw, this driver does not support Linux-2.0.X kernels.

The major improvements against sym53c8xx driver can be summarized 
as follows:

- Don't use the scsi_obsolete interface anymore.
  I could word it as 'use the new error handling interface', but the best 
  advantage, in my opinion, is that driver entry points are not called 
  recursively as does the old scsi code.

- Support for the entire NCR/SYMBIOS/LSILOGIC 53C[8XX|1010] in a single 
  driver without significant bloat of the object code.
  The driver with all options enabled is about 73K not stripped and 59K 
  stripped under Linux-2.2.18.

- Refining of a couple of work-arounds that let me claim that the driver 
  supports the best possible all chips of all revisions, even very early 
  revisions of recent chips.

I am highly interested in receiving reports, either success or problem, 
about this driver version, especially when the driver is tried on non Intel 
IA32 platforms.

  Gérard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: modutils 2.3.23 fails with tdfx.o with test13-pre6

[Ed Tomlinson]

Hi,

This is lets it load.   The same missing symbols happen with mga as well... 
This is from a patch posted here two weeks ago:

--- linux/drivers/char/drm/drmP.oldThu Dec 28 16:27:34 2000
+++ linux/drivers/char/drm/drmP.hSat Dec 23 13:57:08 2000
@@ -40,6 +40,7 @@
 #include 
 #endif /* __alpha__ */
 #include 
+#include 
 #include 
 #include 
 #include 

Not sure if this is more than a temporay fix though.

Ed Tomlinson

Frank Jacobberger wrote:

> I can't get the latest modutils to work with loading
> tdfx.o... Even went to the directory where tdfx.o resides
> and did a insmod -S tdfx.o and got the following :
> 
> BTW - test13-pre6 here
> 
> tdfx.o: unresolved symbol remap_page_range
> tdfx.o: unresolved symbol __wake_up
> tdfx.o: unresolved symbol mtrr_add
> tdfx.o: unresolved symbol __generic_copy_from_user
> tdfx.o: unresolved symbol schedule
> tdfx.o: unresolved symbol kmalloc
> tdfx.o: unresolved symbol si_meminfo
> tdfx.o: unresolved symbol create_proc_entry
> tdfx.o: unresolved symbol inter_module_put
> tdfx.o: unresolved symbol __get_free_pages
> tdfx.o: unresolved symbol boot_cpu_data
> tdfx.o: unresolved symbol inter_module_get
> tdfx.o: unresolved symbol remove_wait_queue
> tdfx.o: unresolved symbol high_memory
> tdfx.o: unresolved symbol iounmap
> tdfx.o: unresolved symbol free_pages
> tdfx.o: unresolved symbol __ioremap
> tdfx.o: unresolved symbol del_timer
> tdfx.o: unresolved symbol interruptible_sleep_on
> tdfx.o: unresolved symbol __pollwait
> tdfx.o: unresolved symbol kfree
> tdfx.o: unresolved symbol remove_proc_entry
> tdfx.o: unresolved symbol pci_find_slot
> tdfx.o: unresolved symbol kill_fasync
> tdfx.o: unresolved symbol fasync_helper
> tdfx.o: unresolved symbol add_wait_queue
> tdfx.o: unresolved symbol do_mmap_pgoff
> tdfx.o: unresolved symbol mem_map
> tdfx.o: unresolved symbol sprintf
> tdfx.o: unresolved symbol jiffies
> tdfx.o: unresolved symbol printk
> tdfx.o: unresolved symbol add_timer
> tdfx.o: unresolved symbol __generic_copy_to_user
> 
> So what gives here?
> 
> Frank
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[RFC] Generic deferred file writing

[Daniel Phillips]

When I saw you put in the if (PageDirty) -->writepage and related code
over the last couple of weeks I was wondering if you realize how close
we are to having generic deferred file writing in the VFS.  I took some
time today to code this little hack and it comes awfully close to doing
the job.  However, *** Warning, do not run this on a machine you care
about, it will mess it up ***.

The advantages of deferred file writing are pretty obvious.  Right now
we are deferring just the writeout of data to the disk, but we can also
defer the disk mapping, so that metadata blocks don't have to stay
around in cache waiting for data blocks to get mapped into them one at
a time - a whole group can be done in one flush.  There is more scope
for the filesystem to optimize allocation - we just need some kind of
->get_blocks call that maps n file blocks in one operation.  Sometimes
we'll be able to write files, read them back and erase them without
ever hitting the disk, or even the filesystem.  Sequences of short
writes will cost a lot less cpu and hit less cache.  There are probably
other advantages as well.

For this to work properly there has to be an analog of kflushd for
pages.  We don't have that yet, and it's some distance away - so I'm
not even beginning to suggest this is a 2.4.0 thing.

In the patch below I didn't try to write the error handling exactly
right and the indenting is wrong.  It's just meant to show the idea
clearly.  Instead of mapping each file page to storage as we normally do
in generic_file_write we just mark it dirty and let page_launder or
Marcelo's new flushing code call the filesystem later.

This code worked well enough to copy some files and directories in uml,
and still have them there after a reboot.  Beyond that - patching it
into test13-pre5 on a real machine resulted in a toasted passwd file,
so there's some work to do yet.

Here it is...

--- 2.4.0-test12.clean/mm/filemap.c Sat Dec  9 09:13:23 2000
+++ 2.4.0-test12/mm/filemap.c   Sat Dec 30 19:56:24 2000
@@ -2449,6 +2449,16 @@
PAGE_BUG(page);
}
 
+   if (!offset && bytes == PAGE_SIZE)
+   {
+   kaddr = page_address(page);
+   status = copy_from_user(kaddr+offset, buf, bytes);
+   flush_dcache_page(page);
+   SetPageUptodate(page);
+   SetPageDirty(page); /* set_page_dirty in test13 */
+   }
+   else
+   {
status = mapping->a_ops->prepare_write(file, page, offset, 
offset+bytes);
if (status)
goto unlock;
@@ -2458,6 +2468,7 @@
if (status)
goto fail_write;
status = mapping->a_ops->commit_write(file, page, offset, 
offset+bytes);
+   }
if (!status)
status = bytes;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.19pre3 and poor reponse to RT-scheduled processes?

[Linus Torvalds]

On Sat, 30 Dec 2000, Alexander Viro wrote:
> On 30 Dec 2000, Linus Torvalds wrote:
> 
> > There are other, equally likely, candidates for these kinds of stalls:
> > 
> >  - filesystem locks. Especially the ext2 superblock lock. You can easily
> >hit this one, as some ext2 functions actually do a lot of IO while
> >holding the lock.
> 
> Hmm... In 2.4 we can make the situation with superblock lock on ext2
> much better.

Actually, 2.4.x right now is worse than 2.2.x in this regard, for a really
simple reason: 2.2.x will only do the equivalent of "rebalance_dirty" when
it dirties a previously clean buffer. The current 2.4.x code does that
regardless of whether the buffer was dirty before or not.

I want to see your patches to fix this for good in a 2.5.x timeframe (or,
if they are really clean and obvious, at a later 2.4.x date), but for
2.4.x I think that we'll do either "remove rebalance dirty completely" or
at the very least we'll not re-balance for re-dirtying a dirty buffer.

The re-dirtying a dirty buffer is the common case for the superblock
stuff: bitmap blocks etc are often dirty already, _especially_ in the case
of an active writer. So 2.4.x is actually more likely to hit the
superblock/bdflush contention.

Of course, 2.4.x has had so many improvements in file writing memory
pressure that it might not end up being that noticeable, but even so..

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.19pre3 and poor reponse to RT-scheduled processes?

[Alexander Viro]

On 30 Dec 2000, Linus Torvalds wrote:

> There are other, equally likely, candidates for these kinds of stalls:
> 
>  - filesystem locks. Especially the ext2 superblock lock. You can easily
>hit this one, as some ext2 functions actually do a lot of IO while
>holding the lock.

Hmm... In 2.4 we can make the situation with superblock lock on ext2
much better. I didn't go the whole way down to spinlocks, but right now
I'm sitting on a box with modified ext2 that doesn't do _any_ IO in
protected parts of ext2_new_inode()/ext2_new_block(). I can try to
extract the relevant parts of the patch if you are interested (it also
got directories-in-pagecache stuff and better SMP threading of
get_block()/truncate()). The thing seems to be working fine and I see
no serious contention on lock_super(). Dunno if it's worth doing before
2.4.0, but since it has zero impact on the rest of tree (OK, zero except
that write_on_page() had been exported, but I could trivially get rid
of that)... Maybe 2.4.early would be a good idea.
Cheers,
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: VIA IDE controller strangeness (2.4.0-test12/test13-pre5)

[Evan Thompson]

--(CC replies please)--

On Sat, Dec 30, 2000 at 06:34:14PM +0100, Matthias Andree wrote:
> Could you report the chip set type and revision? Quote the corresponding
> parts from the "lspci -v" output, please. I've been using PC Chips main
> boards with VIA chip sets without IDE difficulties ever since I bought
> one of those in fall 1998. (VIA Apollo MVP3 AGP, VT82C598 + VT82C586
> north+south bridges), both PC Chips M577 and Tyan Trinity S1590S.

Alrighty then (this is output from lspci -v running under 2.2.18pre21):

-- BEGIN OUTPUT --
...

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA
 [Apollo VP] (rev 41)
Subsystem: VIA Technologies, Inc. MVP3 ISA Bridge
Flags: bus master, stepping, medium devsel, latency 0

00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
 (prog-if 8f [Master SecP SecO PriP PriO])
Flags: bus master, medium devsel, latency 32, IRQ 14
I/O ports at 01f0
I/O ports at 03f4
I/O ports at 0170
I/O ports at 0374
I/O ports at ffa0

...

-- END OUTPUT --

Now...one thing I noticed is that Linux is trying to find this IDE
interface through PCI and it reports it on 00:07.1 during -test12 and
-test13-pre5 boot up (I can't get a dmesg output for you 'cause it never
boots...just keeps complaining about hdb: lost interrupt), but the IDE
controller seems to be an ISA device (unless I've read this wrong).
In case I'm configuring something wrong, I've pasted the IDE .config
portions here:

CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
ONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y

Hope this stuff helps you guys out.
If somebody wants to tell me a better way to get nvi to wrap lines at 75
chars (other than hitting enter when I think it has to be hit), you could
e-mail me (don't bother sending it to the list).

CC replies please.  I don't subscribe to linux-kernel.  Sorry.
-- 
| Evan A. Thompson | He's more fun than trying to skinny  | 
| [EMAIL PROTECTED]   | dip in the beach in winter...|
| http://evaner.penguinpowered.com |...in Winnipeg.   |
| ICQ: 2233067 / AIM + MSN: Evaner517  |  (GnuPG key avaiable upon request.)  |

...hmmm...Now I'm going to have to adjust my .signature to fit in 75
chars instead of 79.  Darn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.19pre3 and poor reponse to RT-scheduled processes?

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Andrea Arcangeli  <[EMAIL PROTECTED]> wrote:
>On Fri, Dec 29, 2000 at 04:54:23PM -0500, Rafal Boni wrote:
>> Now my box behaves much more reasonably... I'll just have to beat harder
>> on it and see what happens.
>
>Another thing: while writing to disk if you want low latency readers you can
>do:
>
>   elvtune -r 1 /dev/hd[abcd]
>
>The 1/2 seconds stalls you see could be just because of applications that waits
>I/O synchronously while the elevator is reodering I/O requests (and even if the
>elevator wouldn't reorder anything the new requests would go to the end of the
>I/O queue so they would have some higher latency anyways).

That sounds like too long a stall to be due to elevator ordering except
with some _really_ unlucky access patterns (or with slow disks). 

There are other, equally likely, candidates for these kinds of stalls:

 - filesystem locks. Especially the ext2 superblock lock. You can easily
   hit this one, as some ext2 functions actually do a lot of IO while
   holding the lock.

 - synchronously waiting for bdflush with balance_dirty_buffers().
   Especially mixed with the above.

A mixture of the two above will bascally stall the whole machine: almost
any non-cached file access ends up waiting for the superblock lock and
bdflush, and it can easily get quite unfair.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre6 weird with tdfx.o

[J Sloan]

Frank Jacobberger wrote:

> Yes your right... I just haven't noticed... Why doesn't someone fix it?

hehe, my guess is the chief kernel honchos don't play much q3a

Hopefully fixing the makefile problem is on their todo list -

jjs


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre6 weird with tdfx.o

[Frank Jacobberger]

J Sloan wrote:

> Frank Jacobberger wrote:
>
> > This is a first for tdfx.o not loading with XFree 4.01.
> >
> > All prior kernel build through test13-pre5 would load just fine...
> >
> > Strange...
>
> Very strange - others on this list, self included,
> have reported something a bit different:
>
> tdfx.o has not loaded in any kernel since -test12.
>
> The makefile changes have broken it.
>
> Are you certain tdfx.o loads for you in prior -test13
> versions? If so, that would be a most disturbing
> development...
>
> jjs

Yes your right... I just haven't noticed... Why doesn't someone fix it?

Frank

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre6 weird with tdfx.o

[J Sloan]

Frank Jacobberger wrote:

> This is a first for tdfx.o not loading with XFree 4.01.
>
> All prior kernel build through test13-pre5 would load just fine...
>
> Strange...

Very strange - others on this list, self included,
have reported something a bit different:

tdfx.o has not loaded in any kernel since -test12.

The makefile changes have broken it.

Are you certain tdfx.o loads for you in prior -test13
versions? If so, that would be a most disturbing
development...

jjs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

modutils 2.3.23 fails with tdfx.o with test13-pre6

[Frank Jacobberger]

I can't get the latest modutils to work with loading
tdfx.o... Even went to the directory where tdfx.o resides
and did a insmod -S tdfx.o and got the following :

BTW - test13-pre6 here

tdfx.o: unresolved symbol remap_page_range
tdfx.o: unresolved symbol __wake_up
tdfx.o: unresolved symbol mtrr_add
tdfx.o: unresolved symbol __generic_copy_from_user
tdfx.o: unresolved symbol schedule
tdfx.o: unresolved symbol kmalloc
tdfx.o: unresolved symbol si_meminfo
tdfx.o: unresolved symbol create_proc_entry
tdfx.o: unresolved symbol inter_module_put
tdfx.o: unresolved symbol __get_free_pages
tdfx.o: unresolved symbol boot_cpu_data
tdfx.o: unresolved symbol inter_module_get
tdfx.o: unresolved symbol remove_wait_queue
tdfx.o: unresolved symbol high_memory
tdfx.o: unresolved symbol iounmap
tdfx.o: unresolved symbol free_pages
tdfx.o: unresolved symbol __ioremap
tdfx.o: unresolved symbol del_timer
tdfx.o: unresolved symbol interruptible_sleep_on
tdfx.o: unresolved symbol __pollwait
tdfx.o: unresolved symbol kfree
tdfx.o: unresolved symbol remove_proc_entry
tdfx.o: unresolved symbol pci_find_slot
tdfx.o: unresolved symbol kill_fasync
tdfx.o: unresolved symbol fasync_helper
tdfx.o: unresolved symbol add_wait_queue
tdfx.o: unresolved symbol do_mmap_pgoff
tdfx.o: unresolved symbol mem_map
tdfx.o: unresolved symbol sprintf
tdfx.o: unresolved symbol jiffies
tdfx.o: unresolved symbol printk
tdfx.o: unresolved symbol add_timer
tdfx.o: unresolved symbol __generic_copy_to_user

So what gives here?

Frank

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: aacraid

[Matt_Domsch]

> I want to run kernel 2.2.18 with aacraid support. Does anyone 
> know where I can get the aacraid patches?

Hi David.  Thanks for writing.  This question has come up a number of times
lately, so I'll respond to the LK list too.

The open-source aacraid driver (formerly named percraid) is included in the
Red Hat Linux 7 kernel 2.2.16-22.  I'd recommend using that kernel (if not
the whole distro), or at least you can grab the aacraid patches from the
kernel source RPM for that kernel from ftp.redhat.com or one of its mirrors.
Be sure to grab all the *aacraid* patches from the /usr/src/redhat/SOURCES
directory after installing the kernel source RPM, and apply those patches to
your own kernel.  It's is known to work with 2.2.18 kernels.  Work on
porting to the 2.4 kernel is not yet complete.

Thanks for buying Dell!
Matt Domsch
Dell Enterprise Systems Group
Linux Development Team
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.19pre3 and poor reponse to RT-scheduled processes?

[Andrea Arcangeli]

On Fri, Dec 29, 2000 at 04:54:23PM -0500, Rafal Boni wrote:
> Now my box behaves much more reasonably... I'll just have to beat harder
> on it and see what happens.

Another thing: while writing to disk if you want low latency readers you can
do:

elvtune -r 1 /dev/hd[abcd]

The 1/2 seconds stalls you see could be just because of applications that waits
I/O synchronously while the elevator is reodering I/O requests (and even if the
elevator wouldn't reorder anything the new requests would go to the end of the
I/O queue so they would have some higher latency anyways). That's normal and if
it's the case to avoid those stalls you can only decrease the I/O load or
increase disk throughput ;). The important thing is that the kernel is
not sitting in a tight kernel loop without reschedule in it during such 2
seconds.

However 2.2.19pre3aa4 includes also the lowlatency bugfixes in case you have
tons of ram and you're sending huge buffers to syscalls.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Any Problems with these items and Linux?

[George R . Kasica]

Hello:

Currently running 2.2.18 with a Celeron 333 MHz and 1 256MB SDRAM
PC100 chip on the motherboard.

The MB will support up to a P-III 600 and 1GB of RAM using 256MB
ChipsI'm looking at going to the following in addition to the
existing RAM:

TWO -  **256MB 32x64 PC100 Non-Parity Unbuf DIMM 3.3V SDRAM Standard
Simm/Flash Memory Card 168 Pin PC100 Unbuf 3.3V SDRAM

And a new CPU Intel Pentium III 600EB SECC2 rather than the Celeron.

Any problems with doing this or changes I need to make to the
kernal/system to optimize it??

George


===[George R. Kasica]===+1 262 513 8503
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Waukesha, WI USA 
http://www.netwrx1.com
[EMAIL PROTECTED]
ICQ #12862186
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

test13-pre6 weird with tdfx.o

[Frank Jacobberger]

This is a first for tdfx.o not loading with XFree 4.01.

All prior kernel build through test13-pre5 would load just fine...

Strange...

Frank

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre6

[Alexander Viro]

On Fri, 29 Dec 2000, Linus Torvalds wrote:

> > Oblock_super(): what the hell is wait_on_super() doing in fsync_file()?
> > It gives absolutely no warranties - ->write_super() can easily block, so
> > it looks very odd.
> 
> A lot of the superblock locking has been odd. It should probably be a
> lock_super() + unlock_super(). At least that's what sync_supers() does.

Yeah, that's what I've done, but I'm less than sure that we need anything
of that kind in the first place...

Anyway, under the "it works here" category: current state of sane-s_lock
patch. It will need further cleanup in fs/super.c, but IMO the current
form is already better than code in tree. Comments are more than welcome.

One note on the patch: sb->s_count is amount of extra references to superblock
(== not coming from vfsmounts) + 1 if there is a vfsmount over that superblock.
I.e. same scheme as we use for mm_struct. get_super() bumps the refcount,
put_super() decrements it and frees the superblock if counter hits zero.
add_vfsmnt() bumps refcount if we are adding the first vfsmount.
remove_vfsmnt() bumps refcount _unless_ we are removing the last vfsmount.
I.e. remove_vfsmnt() + put_super() always does the right thing.

List of superblocks contains only "active" ones. kill_super() takes the
superblock out of the list. get_empty_super() became simpler - it doesn't
bother searching the list for "reusable" ones. List is still BKL-protected;
I'll fix that.

We got _two_ sempaphores - one for get_super()/umount() synchronization
(->s_umount) and another for lock_super()/unlock_super() (->s_lock).
I would expect the latter to go into the per-fs part - all synchronization
that is interesting from VFS point of view is done by ->s_umount. The
reason why I've kept s_lock at all is simple - I don't want to mix
changes in fs-private synchronization with the fs-independent stuff.

Patch is against -pre6 and it seems to working here. Comments (and help
in testing) are welcome.

Peter, if you could remind me the uses of get_empty_super() and friends
in your code I would be very grateful - I seriously suspect that we
could use better interface in that area.
Cheers,
Al
Patch follows:

diff -urN rc13-pre6/arch/parisc/hpux/sys_hpux.c 
rc13-pre6-s_lock/arch/parisc/hpux/sys_hpux.c
--- rc13-pre6/arch/parisc/hpux/sys_hpux.c   Tue Dec 12 02:10:00 2000
+++ rc13-pre6-s_lock/arch/parisc/hpux/sys_hpux.cSat Dec 30 09:17:25 2000
@@ -109,9 +109,11 @@
 
lock_kernel();
s = get_super(to_kdev_t(dev));
+   unlock_kernel();
if (s == NULL)
goto out;
err = vfs_statfs(s, );
+   put_super(s);
if (err)
goto out;
 
@@ -124,7 +126,6 @@
/* Changed to hpux_ustat:  */
err = copy_to_user(ubuf,,sizeof(struct hpux_ustat)) ? -EFAULT : 0;
 out:
-   unlock_kernel();
return err;
 }
 
diff -urN rc13-pre6/arch/sparc/kernel/sys_sunos.c 
rc13-pre6-s_lock/arch/sparc/kernel/sys_sunos.c
--- rc13-pre6/arch/sparc/kernel/sys_sunos.c Sun Aug 13 16:56:28 2000
+++ rc13-pre6-s_lock/arch/sparc/kernel/sys_sunos.c  Sat Dec 30 09:17:25 2000
@@ -620,8 +620,6 @@
 };
 
 
-extern dev_t get_unnamed_dev(void);
-extern void put_unnamed_dev(dev_t);
 extern asmlinkage int sys_connect(int fd, struct sockaddr *uservaddr, int addrlen);
 extern asmlinkage int sys_socket(int family, int type, int protocol);
 extern asmlinkage int sys_bind(int fd, struct sockaddr *umyaddr, int addrlen);
diff -urN rc13-pre6/arch/sparc64/kernel/sys_sunos32.c 
rc13-pre6-s_lock/arch/sparc64/kernel/sys_sunos32.c
--- rc13-pre6/arch/sparc64/kernel/sys_sunos32.c Tue Dec 12 02:10:04 2000
+++ rc13-pre6-s_lock/arch/sparc64/kernel/sys_sunos32.c  Sat Dec 30 09:17:25 2000
@@ -580,8 +580,6 @@
char   *netname;   /* server's netname */
 };
 
-extern dev_t get_unnamed_dev(void);
-extern void put_unnamed_dev(dev_t);
 extern asmlinkage int sys_mount(char *, char *, char *, unsigned long, void *);
 extern asmlinkage int sys_connect(int fd, struct sockaddr *uservaddr, int addrlen);
 extern asmlinkage int sys_socket(int family, int type, int protocol);
diff -urN rc13-pre6/drivers/acorn/block/mfmhd.c 
rc13-pre6-s_lock/drivers/acorn/block/mfmhd.c
--- rc13-pre6/drivers/acorn/block/mfmhd.c   Wed Nov 29 19:28:26 2000
+++ rc13-pre6-s_lock/drivers/acorn/block/mfmhd.cSat Dec 30 09:17:26 2000
@@ -1486,13 +1486,8 @@
for (i = maxp - 1; i >= 0; i--) {
int minor = start + i;
kdev_t devi = MKDEV(MAJOR_NR, minor);
-   struct super_block *sb = get_super(devi);
-
-   sync_dev (devi);
-   if (sb)
-   invalidate_inodes (sb);
-   invalidate_buffers (devi);
 
+   invalidate_dev(devi, 1);
mfm_gendisk.part[minor].start_sect = 0;
mfm_gendisk.part[minor].nr_sects = 

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Francois Romieu]

Andrew Morton <[EMAIL PROTECTED]> écrit :
[...]
> The 3c905C is a well manufactured and very feature-rich NIC which at
> present appears to have fewer problem reports than eepro100, 8139 or tulip.

I guess that the lack of problem reports for the epic chipset comes from
a smaller user base. FWIW, I haven't experienced real problems with
it (observation base: 20~30 boards). Neither did I with the few 3c905 used btw.

[...]
> Perhaps most significantly, the 905 has full scatter/gather support.

May be done for the epic. TODO++

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Matthias Andree]

On Sat, 30 Dec 2000, Alan Cox wrote:

> Looking at the one laptop with this problem I could acquire access to it seems
> that the box switches to SMM mode with interrupts disabled for several timer
> ticks. During this time the i2c bus is active and it appears to be having a
> slow polled conversation with the battery or something attached to the battery
> and monitoring it.
> 
> Doing
> 
>   while { true }
>   do
>   cat /proc/apm
>   done
> 
> made the box visibly stall and jerk doing X operations

Alan, that's what I reported -- restricted to the system time -- two
days ago in <[EMAIL PROTECTED]>. That mail is
also in my lk folder and has kernel.org Received: headers, so you should
have got that mail as well; plus you got it as copy. Is there something
wrong with mail routing?

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SYN_SENT block

[Matthias Andree]

On Wed, 27 Dec 2000, Joaquin Rapela wrote:

> I am not a linux kernel guy. I am running a spider that sometimes gets
> blocked for long periods of time.  I run a "netstat -nto" and I
> observe a socket in state SYS_SENT that seems to be blocked. Its timer
> keeps on incrementing. 
> 
> Is there any way to avoid this blocking? Is this a bug in the kernel
> or something wrong in my TCP/IP configuration/settings.

There's something wrong with the network: Your SYN packet that is to
establish the connection to the other machine is never answered by your
"victim".

There's nothing you can do about that. Talk to non-firewalled, working
machines to prevent that. Possibly try to connect() to several sockets
at once (use fork or threads).

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: VIA IDE controller strangeness (2.4.0-test12/test13-pre5)

[Matthias Andree]

On Fri, 29 Dec 2000, Evan Thompson wrote:

> ---(CC answer please)---

To: should be fine as well, I assume.

> I'm having a strange problem with my IDE controller.  I believe (and
> that's what Windows and the m/b manufaturer -- PC Chips -- say) that I
> have a VIA PCI BusMaster IDE controller, and I've had some strange
> history with it.  I've asked many people before on various help
> services, and I was able to fix my problem with the 2.2 series, but
> now my fix does not work.
> 
> THE PROBLEM: 
> 
> Ever since the 2.2 kernel series (I remeber this working properly in
> 2.0.36, without the conflicts), I would get hdc: lost interrupt during
> boot up, and my system would take bloody ages to boot up and load a
> CD.  I tracked it down to a strange IRQ conflict in which Linux would
> try to assign both the primary and secondary IDE channels IRQ 14,
> causing IRQ conflicts galore.  I was able to fix this by giving the
> kernel
> 
> ide1=0x170,0x376,15
> 
> at boot time.  This has worked for 2.2.12-.17 and Alan's 2.2.18pre21
> (I haven't compiled the official 2.2.18 yet, but I'm sure it will
> work).

Could you report the chip set type and revision? Quote the corresponding
parts from the "lspci -v" output, please. I've been using PC Chips main
boards with VIA chip sets without IDE difficulties ever since I bought
one of those in fall 1998. (VIA Apollo MVP3 AGP, VT82C598 + VT82C586
north+south bridges), both PC Chips M577 and Tyan Trinity S1590S.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: How to write patches

[Matthias Andree]

On Fri, 29 Dec 2000, Sourav Sen wrote:

> 
> Hi,
> 
> This question may seem naive, but can anyone tell me if there is any
> structured way of writing patches? 

1. get a base tree, e. g. 2.2.18, and unpack it into /usr/src 
   (rename your old /usr/src/linux first)
2. rename linux you got in 1. to linux-2.2.18 or whatever is appropriate
3. cp -a -l linux-2.2.18 linux-2.2.18-ss1 (your initials and a number)
   that makes hard links which speeds up diff a lot
   WARNING: IF YOU HAVE AN EDITOR THAT DOES NOT RENAME THE ORIGINAL TO A
   BACKUP FILE NAME, YOU MUST NOT USE -l HERE! (You'd end up editing the
   copy AND the original and your diff would be empty.)
   (break link and copy on write would be a cool feature for the fs...)
4. ln -sfn linux-2.2.18-ss1 linux
5. go edit your ss1 tree with an editor that makes backups by renaming
   before it writes out its files (emacs does in default configuration,
   vi does not!)
6. if your -ss1 kernel is ready for release, save your .config from
   /usr/src/linux somewhere you'll find it (for convenience).
7. cd /usr/src/linux ; make distclean
8. cd /usr/src
9. diff -Nur linux-2.2.18 linux-2.2.18-ss1 | gzip -9c >patch-2.2.18-ss1.gz

With diff, that's OLD NEW (or FROM TO), nothing really difficult since
it's the same way as in mv or cp.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Alan Cox]

> > made the box visibly stall and jerk doing X operations
> 
> Yup, same over here. Is there any way to find out if my laptop also
> enters SMM mode? Just to check if it has the same problem as your
> laptop.

Not unless you want to stick wires into it and onto the i2c bus 8) At least
not that I know of other than disassembling the drivers

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: linux 2.2.19pre and thttpd (VM-global problem?)

[Andrea Arcangeli]

On Fri, Dec 29, 2000 at 08:21:12PM -0800, dean gaudet wrote:
> On Fri, 29 Dec 2000, Andrea Arcangeli wrote:
> 
> > On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote:
> > > Your cgi will keep the other CPU occupied, or run two of them. thttpd has
> > > superb scaling properties compared to say apache.
> >
> > I think with 8 CPUs and 8 NICs (usual benchmark setup) you want more than 1 cpu
^
> > serving static data and it should be more efficient if it's threaded and
> > sleeping in accept() instead of running eight of them (starting from sharing
> > tlb entries and avoiding flushes probably without the need of CPU binding).
> 
> hey, nobody sane runs an 8 CPU box with 8 NICs for a production webserver.
> 8 single CPU boxes, or 4 dual boxes behind a load balancer.  now that's
> more common, more scalable, more robust.  :)

and it also provides high avaibility that is mandatory in a setup that
needs high performance anyways.

> oh yeah they all run perl, java, or php too :)  i've seen sites with more

and zope+python as well indeed.

> than 100 dynamic front-ends and a pair of 350Mhz x86 boxes in the corner
> handling all the static needs (running apache even!).  a pair only 'cause
> of redundancy reasons, not because of load reasons.

Exactly. I totally agree with you (everybody who talked with me about those
issues or attended my last two talks can confirm I agree ;).

But you're talking about real world. I was only talking about benchmarks.
Don't complain me if usual benchmark setup is done with one server N-way SMP +
N-Gbit-NICs (infact I can't run any usual webserving benchmark at home).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Erik Mouw]

On Sat, Dec 30, 2000 at 05:01:27PM +, Alan Cox wrote:
> Looking at the one laptop with this problem I could acquire access to it seems
> that the box switches to SMM mode with interrupts disabled for several timer
> ticks. During this time the i2c bus is active and it appears to be having a
> slow polled conversation with the battery or something attached to the battery
> and monitoring it.

Sounds like a good explanation.

> Doing
> 
>   while { true }
>   do
>   cat /proc/apm
>   done
> 
> made the box visibly stall and jerk doing X operations

Yup, same over here. Is there any way to find out if my laptop also
enters SMM mode? Just to check if it has the same problem as your
laptop.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Whats the problem

[Sourav Sen]

I am unable to compile the following code, can anyone say whats the
problem :

The main error msg is like the following:

parse error before `EXPORT_SYMTAB_not_defined'
warning: type defaults to `int' in declaration of
`EXPORT_SYMTAB_not_defined'
warning: data definition has no type or storage class
 
==
#include 
#include 
#include 
#include 
#include 
#include 

int init_module()
{
printk("Hello, World\n");
return 0 ;
}

int show_mystate(void)
{
unsigned long state ;
state = current->state ;
printk("%x\n",state);
return 0 ;
}   

EXPORT_SYMBOL(show_mystate);

void cleanup_module()
{
printk("Goodbye\n");
}

=
 The makefile 

CC=gcc
MODCFLAGS=-Wall -DMODULE -D__KERNEL__ -DLINUX

showinfo.o : showinfo.c

$(CC) $(MODCFLAGS) -c showinfo.c


Thanks
Sourav

SOURAV SENMSc(Engg.) CSA IISc BANGALORE URL : www2.csa.iisc.ernet.in/~sourav 
ROOM NO : N-78  TEL :(080)309-2454(HOSTEL)  (080)309-2906 (COMP LAB) 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Large "clipped" IDE disk support for 2.4 when using old BIOS (fixed patch)

[Tommi Virtanen]

On Sat, Nov 18, 2000 at 09:32:26PM +0200, Taisuke Yamada wrote:
> Earlier this month, I had sent in a patch to 2.2.18pre17 (with
> IDE-patch from http://www.linux-ide.org/ applied) to add support
> for IDE disk larger than 32GB, even if the disk required "clipping"
> to reduce apparent disk size due to BIOS limitation.
[..]
> Now I'm moving to 2.4-based system, and so ported the patch to
> 2.4-test10. It also applies cleanly to 2.4-test11.

Well, the patch in the message didn't apply cleanly and
had some problems, as discussed in the rest of the thread.
As no one seems to have posted an updated patch, here
goes. This works nicely for my Maxtor 81.9GB HDD.

--- linux-2.4.0-test13-pre5/drivers/ide/ide-disk.c  Fri Oct 27 09:35:48 2000
+++ linux/drivers/ide/ide-disk.cThu Dec 28 22:49:18 2000
@@ -513,24 +513,149 @@
current_capacity(drive));
 }
 
+
+/*
+ * Tests if the drive supports Host Protected Area feature.
+ * Returns true if supported, false otherwise.
+ */
+static inline int idedisk_supports_host_protected_area(ide_drive_t *drive)
+{
+int flag = (drive->id->command_set_1 & 0x0400) ? 1 : 0;
+printk("%s: host protected area => %d\n", drive->name, flag);
+return flag;
+}
+
+/*
+ * Queries for true maximum capacity of the drive.
+ * Returns maximum LBA address (> 0) of the drive, 0 if failed.
+ */
+static unsigned long idedisk_read_native_max_address(ide_drive_t *drive)
+{
+byte args[7];
+unsigned long addr = 0;
+
+printk("%s: checking for max native LBA...\n", drive->name);
+
+/* Create IDE/ATA command request structure
+ *
+ * NOTE: I'm not sure if I can safely use IDE_*_OFFSET macro
+ *   here...For real ATA command structure, offset for IDE
+ *   command is 7, but in IDE driver, it needs to be at 0th
+ *   index (same goes for IDE status offset below). Hmm...
+ */
+args[0]  = 0xf8; /* READ_NATIVE_MAX - see ATA spec */
+args[IDE_FEATURE_OFFSET] = 0x00;
+args[IDE_NSECTOR_OFFSET] = 0x00;
+args[IDE_SECTOR_OFFSET]  = 0x00;
+args[IDE_LCYL_OFFSET]= 0x00;
+args[IDE_HCYL_OFFSET]= 0x00;
+args[IDE_SELECT_OFFSET]  = 0x40;
+
+/* submit command request - if OK, read current max LBA value */
+if (ide_wait_cmd_task(drive, args) == 0) {
+if ((args[0] & 0x01) == 0) {
+addr = ((args[IDE_SELECT_OFFSET] & 0x0f) << 24)
+ | ((args[IDE_HCYL_OFFSET] ) << 16)
+ | ((args[IDE_LCYL_OFFSET] ) <<  8)
+ | ((args[IDE_SECTOR_OFFSET]   ));
+}
+}
+
+printk("%s: max native LBA is %lu\n", drive->name, addr);
+
+return addr;
+}
+
+/*
+ * Sets maximum virtual LBA address of the drive.
+ * Returns new maximum virtual LBA address (> 0) or 0 on failure.
+ */
+static unsigned long idedisk_set_max_address(ide_drive_t  *drive,
+ unsigned long addr_req)
+{
+byte args[7];
+unsigned long addr_set = 0;
+
+printk("%s: (un)clipping max LBA...\n", drive->name);
+
+/* Create IDE/ATA command request structure
+ *
+ * NOTE: I'm not sure if I can safely use IDE_*_OFFSET macro
+ *   here...For real ATA command structure, offset for IDE
+ *   command is 7, but in IDE driver, it needs to be at 0th
+ *   index (same goes for IDE status offset below). Hmm...
+ */
+args[0]  = 0xf9; /* SET_MAX - see ATA spec */
+   args[IDE_FEATURE_OFFSET] = 0x00;
+args[IDE_NSECTOR_OFFSET] = 0x00;
+args[IDE_SECTOR_OFFSET]  = ((addr_req  ) & 0xff);
+args[IDE_LCYL_OFFSET]= ((addr_req >>  8) & 0xff);
+args[IDE_HCYL_OFFSET]= ((addr_req >> 16) & 0xff);
+args[IDE_SELECT_OFFSET]  = ((addr_req >> 24) & 0x0f) | 0x40;
+
+/* submit command request - if OK, read new max LBA value */
+if (ide_wait_cmd_task(drive, args) == 0) {
+if ((args[0] & 0x01) == 0) {
+addr_set = ((args[IDE_SELECT_OFFSET] & 0x0f) << 24)
+ | ((args[IDE_HCYL_OFFSET] ) << 16)
+ | ((args[IDE_LCYL_OFFSET] ) <<  8)
+ | ((args[IDE_SECTOR_OFFSET]   ));
+}
+}
+
+printk("%s: max LBA (un)clipped to %lu\n", drive->name, addr_set);
+
+return addr_set;
+}
+
 /*
  * Compute drive->capacity, the full capacity of the drive
  * Called with drive->id != NULL.
+ *
+ * To compute capacity, this uses either of
+ *
+ *1. CHS value set by user   (whatever user sets will be trusted)
+ *2. LBA value from target drive (require new ATA feature)
+ *3. LBA value from system BIOS  (new one is OK, old one may break)
+ *4. CHS value from system BIOS  (traditional style)
+ *
+ * in above order (i.e., if value of higher priority is available,
+ * rest of the values are ignored).
  */
 static void init_idedisk_capacity (ide_drive_t  *drive)
 {
+unsigned long  hd_max;
+unsigned long  

Re: File I/O benchmarks for various kernel

[Ed Tomlinson]

Hi,

Some more numbers to consider:

7.3 MB/s  54.7s user  159.6s system  25% cpu  elaspsed 14:21.9m 
reiserfs on hda whick gets 16.1 MB/s from hdparm -t

9.7 MB/s  51.6s user   78.3s system  19% cpu  elaspsed 10:50.8m
ext2 on hdb which gets 10.6 MB/s from hdparm -t

both drives are udma33.  The sytem is a K6-III 400 with 128m running:
2.4.0test13pre6 + reil #2 + drm fix + reiserfs 3.6.23

Think ext2 is doing pretty good.  I have seen comments that imply dbench 
does not show reiserfs at its best - they favor the bonnie suite.

Luck
Ed Tomlinson

Daniel Phillips wrote:

> I've been using dbench a lot lately for reality checks on various kernel
> mods, and out of interest I decided to run benchmarks with it on a few
> different kernel versions.  I noticed a major difference between 2.2 and
> 2.4 kernels - 2.4 is running the benchmarks about 3 times faster than
> 2.2, and it seems to be getting faster with each step towards 2.4.0.  On
> the other hand, 2.2 seems to be getting slower.  Here are a few points
> on the curve.
> 
>   Test machine: 64 meg, 500 Mhz K6, IDE, Ext2, Blocksize=4K
>   Test: dbench 48
> 
>   Kernel Throughput  Elapsed Time
>   -- --  
>   2.2.16 3.1 MB/sec  33 min 53 secs
>   2.2.18 2.8 MB/sec  38 min 10 secs
>   2.2.19-pre32.7 MB/sec  39 min 44 secs
>   2.4.0-test12   7.3 MB/sec  14 min 32 secs
>   2.4.0-test13-pre4  9.5 MB/sec  11 min 06 secs
>   2.4.0-test13-pre5 10.8 MB/sec   9 min 48 secs
> 
> Dbench was written by Andrew Tridgell to measure disk performance under
> simulated samba network traffic load.  The '48' means it's simulating
> the file access patterns of 48 network clients, all doing heavy io at
> the same time.
> 
> For anyone interested in checking these results on their own hardware,
> dbench is available at:
> 
>   ftp://samba.org/pub/tridge/dbench/dbench-1.1.tar.gz
> 
> --
> Daniel
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Alan Cox]

> However, reading from /proc/apm triggers BIOS calls which involve
> certain action, maybe switching to Real Mode and other things, and I
> suspect that either IRQs are still disabled while the BIOS is called or
> the BIOS plays bad games which Linux would have to compensate for. :-/

Looking at the one laptop with this problem I could acquire access to it seems
that the box switches to SMM mode with interrupts disabled for several timer
ticks. During this time the i2c bus is active and it appears to be having a
slow polled conversation with the battery or something attached to the battery
and monitoring it.

Doing

while { true }
do
cat /proc/apm
done

made the box visibly stall and jerk doing X operations


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre6 compile error..network.o

[Alan Cox]

> net/network.o(.text+0x5ce78): undefined reference to `prepare_trdev'
> net/network.o(.text+0x5ce88): undefined reference to `prepare_etherdev'
> net/network.o(.text+0x5cee3): undefined reference to `publish_netdev'

My fault. I fed Linus a few things too many trying to get the networking
stuff tidied up. Stuff leaked in from the networking core fixes that arent
yet in Linus tree

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Steven N. Hirsch]

On Wed, 13 Dec 2000, Justin T. Gibbs wrote:

> daptec SCSI HBA device driver for the Linux Operating System
> To: [EMAIL PROTECTED]
> cc:
> Fcc: +outbox
> Subject: Adaptec AIC7XXX v6.0.6 BETA Released
> ---
> After several months of testing and refinement, the Adaptec 
> sponsored aic7xxx driver is now entering Beta testing.  Although
> still missing domain validation and the last bits of cardbus
> support, there are no known issues with the driver.  I would
> encourage all users of card supported by this driver to try the
> new code and submit feedback.  Patches for late 2.2.X, 2.3.99
> and 2.4.0 are provided in the driver distribution.  For those
> of you building the driver as a module, take note that the module
> name is now "aic7xxx_mod" rather than "aic7xxx".
> 
> As always, the most recent distribution is available here:
> 
> http://people.FreeBSD.org/~gibbs/linux/

Justin,

Although your driver has worked fine otherwise, I discovered today that it
renders my Seagate/Conner DDS-2 drive inoperative.  Any and all attempts
at accessing the device (e.g. making tar archive, 'mt -f /dev/st0 status',
etc.) result in:

st0:  Error 1 (sugg. bt 0x0, driver bt 0x0, host bt 0x1).

The platform is a Pentium 166 with on-board aic7880 controller.

If I revert back to Doug Ledford's 5.1.31 driver, everything is fine.

Any insights or things you'd like me to try?

Steve



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.2.18 oops

[Dmitry Melekhov]

Hello!

I have problems with kernels >=2.2.15
Always have similar oops about 1-2 times per week.
2.2.13 works good for me, but now I need big ide drive support.
I don't tried 2.2.14 yet, but looks like bug is in 2.2.14 and greater.
I have dual processors server with 5 eepro100 interfaces (2 cards are dual),
I think that problem is in eepro dirver, but not shure- I'm not programmer.
Anyway, I need help, because I need big ide drive support and can't use
new kernels, because they crash. Possibly I need patch for 2.2.13 with big
ide drives support.

Here is oops trace for 2.2.18 ( I posted oops for 2.2.15, 2.2.16 and
2.2.17pre3 before)

WARNING: This version of ksymoops is obsolete.
WARNING: The current version can be obtained from ftp://ftp.
/pub/linux/utils/kernel/ksymoops
Options used: -V (default)
  -o /lib/modules/2.2.18/ (default)
  -k /proc/ksyms (default)
  -l /proc/modules (default)
  -m /usr/src/linux/System.map (default)
  -c 1 (default)

You did not tell me where to find symbol information.  I will assume
that the log matches the kernel and modules that are running right no
and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can ge
more accurate output by telling me the kernel version and where to fi
map, modules, ksyms etc.  ksymoops -h explains the options.

Oops: 
CPU: 0
EIP: 0010: []
EFLAGS: 00010286
eax: f1048197 ebx: cf8d4500 ecx: 0014 edx: 003c
esi: 003c edi: de7bb0e4 ebp: f1048197 esp: dffebd80
ds: 0018
Stack: de7bb04e de7bbea4 e00510b0 cf8d4500 f1048197 003c 
4000
   de7bb04e de7bb000 4050 0014 de7bb8e4 0014 0001
003f
   e0050aad de7bb000 de860760 0401  0005 e0055000
00c8
Call Trace: [] [] [] [] []
[] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] []
Code: 66 83 7d 0c 08 74 21 8b bb 80 00 00 00 00 89 d1 c1 e9 02 89 ce

>>EIP: c01669d8 
Trace: e00510b0 
Trace: e0050aad 
Trace: e0055000 
Trace: e0055000 
Trace: c010bbe2 
Trace: c01107da 
Trace: c010b853 
Trace: c010a328 
Trace: e005d000 
Trace: c010b86a 
Code:  c01669d8 <_EIP>: <===
Code:  c01669d8   0:66 83 7d 0c 08
cmpw   $0x8,0xc(%ebp) <===
Code:  c01669dd   5:74 21
je  c0166a00 
Code:  c01669df   7:8b bb 80 00 00 00
movl   0x80(%ebx),%edi
Code:  c01669e5   d:00 89 d1 c1 e9 02
addb   %cl,0x2e9c1d1(%ecx)
Code:  c01669eb  13:89 ce
movl   %ecx,%esi

Aiee, killing interrupt handler
Kernel panic: Attemted to kill idle task!



Please, help me!


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

linux-2.4.0-test13-pre6 undefined symbols: prepare_etherdev, publish_netdev

[Adam J. Richter]

It looks like 2.4.0-test13-pre6 contains a partially applied
patch in net/atm/lec.c.  It adds references to the symbols
prepare_etherdev and publish_netdev, which are not defined anywhere.

Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Matthias Andree]

On Fri, 29 Dec 2000, Erik Mouw wrote:

> On Thu, Dec 28, 2000 at 02:53:37PM +0100, Matthias Andree wrote:
> However, reading from /proc/apm also triggers other weird problems:
> 
> - Received characters dropped on serial line. I thought my serial port
>   was broken, because a 16550 is supposed to have a receive buffer.

I don't know that the Linux driver sets the IRQ trigger to (you can have
the 16550 request interrupts after its 16-byte FIFO has 1, 4, 8 or 14
bytes ready for reading), but if it's set to 14 (to reduce the IRQ
frequency), you don't have much time at 115200 Bit/s, you have 1 Byte
every 87 ms then (it has 10 bit usually, 1 start + 1 stop bit), and
reading from /proc/apm stops my system clock for approx. 80 ... 90 ms -
then you still have IRQs with higher precedence and whooops, your buffer
overruns. Setting the trigger lower would help, but I never looked how
this will happen.

(I never run into this problem myself since I have 16750s here which
have at least 8 Bytes left when triggering, they have 64 Byte FIFO.)

> I got the same problems with my previous notebook (Asus P6300, PII 266,
> 112MB, Intel BX/ZX chipset). It might be a BIOS problem, because both
> notebooks use a Phoenix BIOS. OTOH, I can create the same problems with
> USB on my desktop (Asus P5A motherboard, K6 333, 160MB, Ali 1541
> chipset, Award BIOS) when I run the GNOME battery_applet. So is this an
> Asus problem, or a general APM problem?

My problem shows up on a Gigabyte board with AMIBIOS, so it's certainly
not a Phoenix or Asus specific problem.

However, reading from /proc/apm triggers BIOS calls which involve
certain action, maybe switching to Real Mode and other things, and I
suspect that either IRQs are still disabled while the BIOS is called or
the BIOS plays bad games which Linux would have to compensate for. :-/

HTH,
Matthias
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [prepatch] 2.4 waitqueues

[Andrew Morton]

Linus Torvalds wrote:
> 
> On Wed, 27 Dec 2000, Andrew Morton wrote:
> >
> > - Introduces a kernel-wide macro `SMP_KERNEL'.  This is designed to
> >   be used as a `compiled ifdef' in place of `#ifdef CONFIG_SMP'.  There
> >   are a few examples in __wake_up_common().
> 
> Please don't do this,

OK.

> >   So this has been changed to:
> >
> >   spin_lock_irq(lock);
> >   spin_unlock(lock);
> >   schedule();
> >   spin_lock(lock);
> >   spin_unlock_irq(lock);
> >
> >   Or did I miss something?
> 
> I'm a bit nervous about changing the old compatibility cruft, but the
> above is probably ok.

Andrea had the following reason to not make this change:

" Because old drivers could be doing ugly stuff like this:
"
"cli()
"for (;;) {
"   if (!resource_available)
"   sleep_on(_for_resource)
"   else
"   break
"   }
"   ...
"   sti()
"   
"   If you don't save and restore flags the second sleep_on could be entered with
"   irq enabled and the wakeup from irq could happen before registering in the
"   waitqueue causing a lost wakeup.
"

If anyone _is_ doing this, then they're scheduling with the global_irq_lock
held, which doesn't sound good.  Anyway, it's probably best not to fiddle with
this stuff today.

> Anyway, I'd like you to get rid of the global SMP_KERNEL thing (turning it
> into a local one if you want to for this case), _and_ I'd like to see this
> patch with the wait-queue spinlock _outside_ the __common_wakeup() path.
> 
> Why? Those semaphores will eventually want to re-use the wait-queue
> spinlock as a per-semaphore spinlock, and they would need to call
> __common_wakeup() with the spinlock held to do so. So let's get the
> infrastructure in place
> 

OK, did that.

__wake_up() now looks like this:

void __wake_up(wait_queue_head_t *q, unsigned int mode, unsigned int wq_mode)
{
if (q) {
unsigned long flags;
wq_read_lock_irqsave(>lock, flags);
__wake_up_common(q, mode, wq_mode, 0);
wq_read_unlock_irqrestore(>lock, flags);
}
}

If we want to use the waitqueue lock to replace semaphore_lock
then I'd suggest we change __wake_up to look like:

void __wake_up(wait_queue_head_t *q, unsigned int mode, unsigned int wq_mode)
{
if (q) {
unsigned long flags;
if (!(wq_mode & WQ_FLAG_UNLOCKED))
wq_read_lock_irqsave(>lock, flags);
__wake_up_common(q, mode, wq_mode, 0);
if (!(wq_mode & WQ_FLAG_UNLOCKED))
wq_read_unlock_irqrestore(>lock, flags);
}
}

So we don't have to expand another instantiation of __wake_up_common.  I always
find this tradeoff hard to make up my mind about...

The USE_RW_WAIT_QUEUE_SPINLOCK option is still there, so we _could_
turn on rwlocks for waitqueues in the future.  I have tested the
rwlock option and it appears to work.  It wasn't safe with the
old (current) __wake_up() implementation, but I think it is safe with
this patch.

rwlocks are a little more scalable here, and will probably allow us to leave
local interrupts enabled while running __wake_up().

BUT!  If we want to throw away semaphore_lock (good move) and then
enable rwlocks in the waitqueues, that means that __down() will
have to do a write_lock of the per-waitqueue lock, so it can
call __add_wait_queue_exclusive() and __remove_wait_queue_exclusive().
We'd need to do this anyway, so the waitqueue locking protects the
semaphore's internals.

We should also remove the extra wake_up() in __down(), which
is going to hurt someone's brain :)


Here's the patch, tested on x86 UP and SMP.  The only substantive change
since last time is hoisting the `wq_mode & WQ_FLAG_EXCLUSIVE' outside the
browsing loop and then commenting it out!


--- linux-2.4.0-test13-pre6/include/linux/sched.h   Sat Dec 30 22:19:58 2000
+++ linux-akpm/include/linux/sched.hSat Dec 30 22:54:21 2000
@@ -545,7 +545,7 @@
 extern void FASTCALL(interruptible_sleep_on(wait_queue_head_t *q));
 extern long FASTCALL(interruptible_sleep_on_timeout(wait_queue_head_t *q,
signed long timeout));
-extern void FASTCALL(wake_up_process(struct task_struct * tsk));
+extern int FASTCALL(wake_up_process(struct task_struct * tsk));
 
 #define wake_up(x) __wake_up((x),TASK_UNINTERRUPTIBLE | 
TASK_INTERRUPTIBLE,WQ_FLAG_EXCLUSIVE)
 #define wake_up_all(x) __wake_up((x),TASK_UNINTERRUPTIBLE | 
TASK_INTERRUPTIBLE,0)
--- linux-2.4.0-test13-pre6/include/linux/wait.hSat Dec 30 22:19:58 2000
+++ linux-akpm/include/linux/wait.h Sat Dec 30 22:54:21 2000
@@ -19,30 +19,10 @@
 #include 
 
 /*
- * Temporary debugging help until all code is converted to the new
- * waitqueue usage.
+ * Debug control.  Slow but 

Timeout: AT keyboard not present?

[Jes=FAs?= Carrete Montaña]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


I receive this message very often in console, in every situation: when
I'm coding and when I'm playing tetrinet. It's quite annoying, mostly
because it fills my screen of garbage (I'll have to buy a new CTRL and
L keys). What's the prolem? It only happens (I think) with >2.2.17
kernels (including 2.4.0-test12).
Please let me know if you need more information.

Un saludo.
- -- 
"I use free software."| ¡Feliz Navidad y buen 2001!
- --
.~. |/,_|-.|
/V\ |\L|(_||<() @ escomposlinux.org
   // \\Linux Registered User #158442
  /(   )\   Public PGP Key avaliable via e-mail
   ^`~'^and pgp.rediris.es

- -- Versions installed: (if some fields are empty or look
- -- unusual then possibly you have very old versions)
Linux relativistic 2.4.0-test12-withoutfb #1 sáb dic 23 02:39:30 CET 2000 i586 unknown
Kernel modules 2.3.19
Gnu C  2.95.2
Gnu Make   3.79.1
Binutils   2.9.5.0.37
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.6
Mount  2.10q
Net-tools  2.05
Console-tools  0.2.3
Sh-utils   2.0i
Modules Loaded adlib_card opl3 sb sb_lib uart401 sound soundcore lp 
nls_iso8859-15 nls_cp437
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard 

iD8DBQE6Tc8afUtQQKOnZ1IRAlH/AKDdLcjIgWREYEGepW5JDRQukDBlJACgucI4
4SxGczkC4QhDgKbWqEXpnL0=
=s3aJ
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ext2's inode i_version gone, what now? (stable branch)

[Andreas Schuldei]

* Andreas Schuldei ([EMAIL PROTECTED]) [001229 22:08]:
> However a real problem (for me) is that the author (whom I can not reach by
> email) build stegfs on top of the ext2 filesystem. There he uses ext2's inode
> structure and at some places reads/writes from ext2 inode's i_version.
> However, this is not there in ext2_fs_i.h. But I am working with source for
> 2.2.18 and a lot could have happend since 2.2.14. I would not have expected
> the inode struct to change, though.
> 
> Why was it taken away? How is compatibility maintained? What could I use 
> instead to fix the problem?

Now I think i_version was moved from ext2_fs_i.h (struct ext2_inode_info) to
fs.h (struct inode). stegfs still has i_version in it's own stegfs_inode_info.
I guess to cleanly move the stegfs from 2.2.14 to 2.2.18 it would be good to
not have a own stegfs i_version. Are there any mean, hidden, desasterous
implications waiting if I move it?

> Anyone who is interested in this:
> http://ban.joh.cam.ac.uk/~adm36/StegFS/download.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[patch] gemtek radio obvious fix

[Zlatko Calusic]

Index: 24012.6/drivers/media/radio/radio-gemtek.c
--- 24012.6/drivers/media/radio/radio-gemtek.c Thu, 14 Dec 2000 00:08:47 +0100 
zcalusic (linux/P/d/1_radio-gemt 1.1.2.2.3.1 644)
+++ 24012.7(w)/drivers/media/radio/radio-gemtek.c Sat, 30 Dec 2000 12:06:56 +0100 
+zcalusic (linux/P/d/1_radio-gemt 1.1.2.2.3.2 644)
@@ -265,7 +265,7 @@
return -EINVAL;
}
 
-   if (request_region(io, 4, "gemtek")) 
+   if (!request_region(io, 4, "gemtek")) 
{
printk(KERN_ERR "gemtek: port 0x%x already in use\n", io);
return -EBUSY;

-- 
Zlatko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] test13-pre6 net/atm/lec.c

[Daniel Stone]

Thanks, but if you ever send HTML email (MIME'd, no less), I'll dismember
you.

> This message is in MIME format.  Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> __JNP_000_5510.0696.1d1b
> Content-Type: text/plain; charset=us-ascii  
> Content-Transfer-Encoding: 7bit
> 
> Hello,
>   The following patch appears to fix 2 of the 3 undefined references:
> publish_netdev is still unresolved.
> Regards,
> Frank
> --- net/atm/lec.c.old Sat Dec 30 03:08:14 2000
> +++ net/atm/lec.c Sat Dec 30 03:17:44 2000
> @@ -772,10 +772,10 @@
>  size = sizeof(struct lec_priv);
>  #ifdef CONFIG_TR
>  if (is_trdev)
> -dev_lec[i] = prepare_trdev(NULL, size);
> +dev_lec[i] = init_trdev(NULL, size);
>  else
>  #endif
> -dev_lec[i] = prepare_etherdev(NULL, size);
> +dev_lec[i] = init_etherdev(NULL, size);
>  if (!dev_lec[i])
>  return -ENOMEM;
>  
> __JNP_000_5510.0696.1d1b
> Content-Type: text/html; charset=us-ascii  
> Content-Transfer-Encoding: quoted-printable
> 
> 
> 
>  Type>
> 
> 
> Hello,
>  The following patch appears to fix 2 of the 3 undefined =
> references:=20
> publish_netdev is still unresolved.
> 
>  style=3D"mso-fareast-font-family: 'MS Mincho'">Regards,
>  style=3D"mso-fareast-font-family: 'MS Mincho'">Frank
>  ">---=20
> net/atm/lec.c.old Sat Dec 30 03:08:=
> 14=20
> 2000+++ net/atm/lec.c=
> ;=20
> Sat Dec 30 03:17:44 2000@@ -772,10 +772,10 @@ style=3D"mso-spacerun: yes">=
> ;=20
> size =3D sizeof(struct lec_priv); style=3D"mso-spacerun: yes">#ifdef CONFIG_TR style=3D"mso-spacerun: yes">=
> ;=20
> if (is_trdev)- style=3D"mso-spacerun: yes">=
> ;&=
> nbsp;=20
> dev_lec[i] =3D prepare_trdev(NULL, size);+ style=3D"mso-spacerun: yes">=
> ;&=
> nbsp;=20
> dev_lec[i] =3D init_trdev(NULL, size); style=3D"mso-spacerun: yes">=
> ;=20
> else#endif-<=
> SPAN=20
> style=3D"mso-spacerun: yes">=
> ;=20
> dev_lec[i] =3D prepare_etherdev(NULL, size);+ style=3D"mso-spacerun: yes">=
> ;=20
> dev_lec[i] =3D init_etherdev(NULL, size); style=3D"mso-spacerun: yes">=
> ;=20
> if (!dev_lec[i]) style=3D"mso-spacerun: yes">=
> ;&=
> nbsp;=20
> return -ENOMEM; style=3D"mso-spacerun: yes">
> 
> __JNP_000_5510.0696.1d1b--
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Andrew Morton]

Linus Torvalds wrote:
> 
> I bet that others will have other recommendations, but so far I have at
> least personally had good luck with the eepro100.

The 3c905C is a well manufactured and very feature-rich NIC which at
present appears to have fewer problem reports than eepro100, 8139 or tulip.

Available in PCI, Cardbus, Mini-PCI.  A dual-interface PCI version has
just been released (3c982), although we've yet to hear of anyone trying
it with Linux.

3com provide full specs without any NDA restrictions, plus a GPL'ed
driver.

Perhaps most significantly, the 905 has full scatter/gather support.
This isn't used at present, but Alexey's zerocopy-sendfile patches
do utilise it.  He currently has scatter-gather support for acenic,
3c905 and sunhme.  I don't know what the plans are to support other
100 mbps NICs.

The in-kernel 3c59x.c isn't the world's fastest driver.  On the todo list
for 2.5 is MMIO support, scatter-gather maintenance, optional use of DPD
polling and implementation of the onboard multicast hash filter. And 
implementation of the on-board VLAN support if 2.5 becomes VLAN-capable.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre6 compile error..network.o

[Andrew Morton]

> Hello,
>  I received the following error while compiling test13-pre6 . 
> 
> net/network.o: In function `lecd_attach':
> net/network.o(.text+0x5ce78): undefined reference to `prepare_trdev'
> net/network.o(.text+0x5ce88): undefined reference to `prepare_etherdev'
> net/network.o(.text+0x5cee3): undefined reference to `publish_netdev'
> make: *** [vmlinux] Error 1

This is caused by some cross-patch leakage between Alan and Linus.

This should fix it:

--- linux-2.4.0-test13-pre6/net/atm/lec.c   Sat Dec 30 18:38:55 2000
+++ linux-akpm/net/atm/lec.cSat Dec 30 21:17:11 2000
@@ -772,10 +772,10 @@
 size = sizeof(struct lec_priv);
 #ifdef CONFIG_TR
 if (is_trdev)
-dev_lec[i] = prepare_trdev(NULL, size);
+dev_lec[i] = init_trdev(NULL, size);
 else
 #endif
-dev_lec[i] = prepare_etherdev(NULL, size);
+dev_lec[i] = init_etherdev(NULL, size);
 if (!dev_lec[i])
 return -ENOMEM;
 
@@ -783,7 +783,6 @@
 priv->is_trdev = is_trdev;
 sprintf(dev_lec[i]->name, "lec%d", i);
 lec_init(dev_lec[i]);
-   publish_netdev(dev_lec[i]);
 } else {
 priv = dev_lec[i]->priv;
 if (priv->lecd)
@@ -858,7 +857,7 @@
 for (i = 0; i < MAX_LEC_ITF; i++) {
 if (dev_lec[i] != NULL) {
 priv = (struct lec_priv *)dev_lec[i]->priv;
-unregister_netdev(dev_lec[i]);
+unregister_trdev(dev_lec[i]);
 kfree(dev_lec[i]);
 dev_lec[i] = NULL;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] winbond driver bugfixes

[Manfred]

I found another nasty bug in the winbond driver:

The driver contains a work around for a hardware problem, and that work
around is not interrupt safe. It's easy to trigger it on SMP, and there
is a 4 instruction window on UP.
The result is silent data corruption.

--
Manfred
P.S.: I'm still waiting for another beta tester. I've tested the driver
with my network card in 2 motherboards - no problems, data transfer at
10.5 MB/s for hours.

<
--- 2.4/drivers/net/winbond-840.c   Fri Dec 29 12:52:33 2000
+++ build-2.4/drivers/net/winbond-840.c Fri Dec 29 12:50:57 2000
@@ -21,11 +21,26 @@
Do not change the version information unless an improvement has been made.
Merely removing my name, as Compex has done in the past, does not count
as an improvement.
+
+   Changelog:
+   * ported to 2.4
+   ???
+   * spin lock update, memory barriers, new style dma mappings
+   limit each tx buffer to < 1024 bytes
+   remove DescIntr from Rx descriptors (that's an Tx flag)
+   remove next pointer from Tx descriptors
+   synchronize tx_q_bytes
+   software reset in tx_timeout
+   Copyright (C) 2000 Manfred Spraul
+
+   TODO:
+   * according to the documentation, the chip supports big endian
+   descriptors. Remove cpu_to_le32, enable BE descriptors.
 */
 
 /* These identify the driver base version and may not be removed. */
 static const char version1[] =
-"winbond-840.c:v1.01 5/15/2000  Donald Becker <[EMAIL PROTECTED]>\n";
+"winbond-840.c:v1.01 (2.4 port) 5/15/2000  Donald Becker <[EMAIL PROTECTED]>\n";
 static const char version2[] =
 "  http://www.scyld.com/network/drivers.html\n";
 
@@ -81,6 +96,8 @@
 #define TX_FIFO_SIZE (2048)
 #define TX_BUG_FIFO_LIMIT (TX_FIFO_SIZE-1514-16)
 
+#define TX_BUFLIMIT(1024-128)
+
 /* Operational parameters that usually are not changed. */
 /* Time in jiffies before concluding the transmitter is hung. */
 #define TX_TIMEOUT  (2*HZ)
@@ -113,12 +130,7 @@
 #include  /* Processor type for cache alignment. */
 #include 
 #include 
-
-/* Condensed operations for readability.
-   The compatibility defines are in kern_compat.h */
-
-#define virt_to_le32desc(addr)  cpu_to_le32(virt_to_bus(addr))
-#define le32desc_to_virt(addr)  bus_to_virt(le32_to_cpu(addr))
+#include 
 
 MODULE_AUTHOR("Donald Becker <[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("Winbond W89c840 Ethernet driver");
@@ -280,7 +292,7 @@
s32 status;
s32 length;
u32 buffer1;
-   u32 next_desc;
+   u32 buffer2;
 };
 
 struct w840_tx_desc {
@@ -293,14 +305,21 @@
 enum desc_status_bits {
DescOwn=0x8000, DescEndRing=0x0200, DescUseLink=0x0100,
DescWholePkt=0x6000, DescStartPkt=0x2000, DescEndPkt=0x4000,
+};
+
+/* Bits in w840_tx_desc.length */
+enum desc_length_bits {
DescIntr=0x8000,
 };
 
 #define PRIV_ALIGN 15  /* Required alignment mask */
 struct netdev_private {
-   /* Descriptor rings first for alignment. */
-   struct w840_rx_desc rx_ring[RX_RING_SIZE];
-   struct w840_tx_desc tx_ring[TX_RING_SIZE];
+   struct w840_rx_desc *rx_ring;
+   dma_addr_t  rx_addr[RX_RING_SIZE];
+   struct w840_tx_desc *tx_ring;
+   dma_addr_t  tx_addr[RX_RING_SIZE];
+   dma_addr_t ring_dma_addr;
+   struct pci_dev *pdev;
/* The addresses of receive-in-place skbuffs. */
struct sk_buff* rx_skbuff[RX_RING_SIZE];
/* The saved address of a sent-in-place packet/buffer, for later free(). */
@@ -334,13 +353,15 @@
 static int  netdev_open(struct net_device *dev);
 static void check_duplex(struct net_device *dev);
 static void netdev_timer(unsigned long data);
+static void init_rxtx_rings(struct net_device *dev);
+static void free_rxtx_rings(struct netdev_private *np);
+static void init_registers(struct net_device *dev);
 static void tx_timeout(struct net_device *dev);
-static void init_ring(struct net_device *dev);
+static int alloc_ring(struct net_device *dev);
 static int  start_tx(struct sk_buff *skb, struct net_device *dev);
 static void intr_handler(int irq, void *dev_instance, struct pt_regs *regs);
 static void netdev_error(struct net_device *dev, int intr_status);
 static int  netdev_rx(struct net_device *dev);
-static void netdev_error(struct net_device *dev, int intr_status);
 static inline unsigned ether_crc(int length, unsigned char *data);
 static void set_rx_mode(struct net_device *dev);
 static struct net_device_stats *get_stats(struct net_device *dev);
@@ -364,6 +385,11 @@
return -EIO;
pci_set_master(pdev);
 
+   if(!pci_dma_supported(pdev,0x)) {
+   printk(KERN_WARNING "Winbond-840: Device %s disabled due to DMA 
+limitations.\n",
+   pdev->name);
+   return -EIO;
+   }
dev = init_etherdev(NULL, sizeof(*np));

[PATCH] test13-pre6 net/atm/lec.c

[Frank Davis]

Hello,
  The following patch appears to fix 2 of the 3 undefined references: 
publish_netdev is still unresolved.

Regards,
Frank
--- 
net/atm/lec.c.old Sat Dec 30 03:08:14 
2000+++ net/atm/lec.c 
Sat Dec 30 03:17:44 2000@@ -772,10 +772,10 @@ 
size = sizeof(struct lec_priv); #ifdef CONFIG_TR 
if (is_trdev)-    
dev_lec[i] = prepare_trdev(NULL, size);+    
dev_lec[i] = init_trdev(NULL, size); 
else #endif-    
dev_lec[i] = prepare_etherdev(NULL, size);+    
dev_lec[i] = init_etherdev(NULL, size); 
if (!dev_lec[i]) 
return -ENOMEM; 

2.2.18 and joy-gravis.o

[BH]

Is the joy-gravis module non-working in 2.2.18 
?
 
setup:
es1370 on a K6-2 400 / ALi 15xx board, Gravis 
XTerminator gamepad
 
I'm loading the module with joystick=1 to enable 
the gameport, and it shows in dmesg, loading joystick module, then when I 
modprobe joy-gravis, I get this output:
 
lib/modules/.../misc/joy-gravis.o: init_module: 
Device or resource busy/lib/modules/.../misc/joy-gravis.o: insmod 
/lib/modules/.../misc/joy-gravis.o failed
 
This also happens with the emu10k1 sound 
card.
Before when the boot-time gameport hack was used, 
the gamepad module loaded up fine.

Re: test13-pre6 (Fork Bug with Athlons? Temporary Fix)

[Graham Murray]

Byron Stanoszek <[EMAIL PROTECTED]> writes:

> I narrowed the problem down to a subset of patches from the MM set in
> test13-pre2. Reversing the attached 'context.patch' fixes the problem (only for
> i386), but I'm not yet sure why. test13-pre2 and up work without any problems
> on an Intel cpu (Pentium 180 & P3 800 tested).
[Snip] 
> root   351  0.0  1.2  9292 1576 ?S21:42   0:00 named
> root   361  0.0  0.0 00 ?Z21:42   0:00 [named ]
> root   363  0.0  1.2  9292 1576 ?S21:42   0:00 named
> root   364  0.0  1.2  9292 1576 ?S21:42   0:00 named
> root   365  0.0  0.7  2064  936 ?S21:42   0:00 /usr/sbin/sshd
> ..etc
> (Note PID 361)

I am seeing the same thing with the [named ] on a PIII 600,
so it is not Athlon specific. I haven't yet tried test13-pre6 but it
happens with pre3,4,5. So I am still running on test12.

I will try running pre6 then, if it still fails will try with your
context.patch and see if that fixes it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre6 (Fork Bug with Athlons? Temporary Fix)

[Graham Murray]

Byron Stanoszek [EMAIL PROTECTED] writes:

 I narrowed the problem down to a subset of patches from the MM set in
 test13-pre2. Reversing the attached 'context.patch' fixes the problem (only for
 i386), but I'm not yet sure why. test13-pre2 and up work without any problems
 on an Intel cpu (Pentium 180  P3 800 tested).
[Snip] 
 root   351  0.0  1.2  9292 1576 ?S21:42   0:00 named
 root   361  0.0  0.0 00 ?Z21:42   0:00 [named defunct]
 root   363  0.0  1.2  9292 1576 ?S21:42   0:00 named
 root   364  0.0  1.2  9292 1576 ?S21:42   0:00 named
 root   365  0.0  0.7  2064  936 ?S21:42   0:00 /usr/sbin/sshd
 ..etc
 (Note PID 361)

I am seeing the same thing with the [named defunct] on a PIII 600,
so it is not Athlon specific. I haven't yet tried test13-pre6 but it
happens with pre3,4,5. So I am still running on test12.

I will try running pre6 then, if it still fails will try with your
context.patch and see if that fixes it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.2.18 and joy-gravis.o

[BH]

Is the joy-gravis module non-working in 2.2.18 
?

setup:
es1370 on a K6-2 400/ ALi 15xx board, Gravis 
XTerminator gamepad

I'm loading the module with joystick=1 to enable 
the gameport, and it shows in dmesg, loading joystick module, then when I 
modprobe joy-gravis, I get this output:

lib/modules/.../misc/joy-gravis.o: init_module: 
Device or resource busy/lib/modules/.../misc/joy-gravis.o: insmod 
/lib/modules/.../misc/joy-gravis.o failed

This also happens with the emu10k1 sound 
card.
Before when the boot-time gameport hack was used, 
the gamepad module loaded up fine.