Re: REVISED: Experimentation with Athlon and fast_page_copy

[Bobby D. Bryant]

Aaron Tiensivu wrote:

> > What still stands out is that exactly _zero_ people have reported the same
> > problem with non VIA chipset Athlons.
>
> This might be grasping at straws [...] This could be (total conjecture)

> related somehow to the corruption bugs they are admitting to in

> the 686B although they are blaming the SB Live now.

Just another data point (the news is in the final paragraph):

I recently built two near-twin systems using Athlon 1.2's and VIA chipsets
(EPoX 8KTA3), and have *never* been able to get either to boot an
Athlon-optimized kernel, having tried 2.4.0, 2.4.2, 2.4.4, and about 5
different -ac* variants of 2.4.3.

They do boot PIII kernels reliably for all those variants, though they still
suffer occasional oopses, hangs, or crashes (as discussed in other threads).

However (and here's the part I haven't mentioned before), yesterday I switched
one of them to a new mb with a non-VIA chipset (Asus A7A266), and it booted the
first Athlon kernel I tried (2.4.4).  No other changes to .config, same
processor as before, same memory, same disks, same video, same case, same power
cord, you name it.

Bobby Bryant
Austin, Texas


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

Re: REVISED: Experimentation with Athlon and fast_page_copy

[Joseph Carter]

On Sat, May 05, 2001 at 03:51:13PM +1200, Chris Wedgwood wrote:
> I don't see how they figure, but in case there was any doubt I
> have a VIA KT133A/686B board (Abit KT7A) and don't experience
> anything resembling disk corruption unless the box crashes for
> some other reason.  I do seem to be experiencing AGP problems in
> spades, but my disks at least are fine.
> 
> I too seem no disk problems whatsoever (nothing really interesting
> there, many people do not) but am also seeing AGP problems.
> 
> In fact, I had to disable AGP to stop X locking the box hard... yet
> agpgart and the video driver (NVidia[1]) both claim to support the
> chipset -- does anyone actually have this working?)

Not an option with the Radeon unfortunately.  At least, not yet.  Whenever
I find the solution (recently a bunch of people have suggested a bunch of
things to try on dri-devel - thanks guys!) I'll post to that list what
fixed it since I know I am not the only person seeing this kind of
problem.  I think some of the guys are looking into improving the docs a
bit, so maybe if I find it soon the problem and workaround will get
documented.  =)

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

 kb: I demand integrity and honesty in those who i do business with
 i know my demands are unreasonable, but a guy can dream, can't he?


 PGP signature

Re: Possible PCI subsystem bug in 2.4

[Eric W. Biederman]

Alan Cox <[EMAIL PROTECTED]> writes:

> > Seriously.  With the general attitude of distrusting BIOS's I have
> > been amazed at the number of things linux expects the BIOS to get
> > right.  In practice windows seem to trust the BIOS much less than
> > linux does.
> 
> It becomes more and more obvious over time exactly why. One problem however
> is that windows gets away with this because many vendors ship random extra
> gunge for their box with the system. We dont yet have that power

Right.  So we always need to keep heuristics in our toolbox to fallback on,
so we can run on boards with incomplete information.  However there is a lot
of things we can do that we aren't currently doing.

The example that sticks out in my head is we rely on the MP table to
tell us if the local apic is in pic_mode or in virtual wire mode.
When all we really have to do is ask it.

Eric

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

Bus error - Shortly later kernel lockup, many MTRR registers

[paul harris]

Hello, I hope I am doing this correctly per the BUG-REPORTING doc.

1.  Bus error - Shortly later kernel lockup MTRR registers

2.  My kernel has locked up 3 times since moving to the 2.4.x kernel.
I am not excaly sure of what triggers it
  but it does always happen while I am actively using it.
Netscape 4.77 ussally has a bus error shortly before the box
  will lock up,  but the netscape bus error can happen and no
messages will get logged or any lock up happen.The message

 mtrr: no MTRR for e400,200 found

frequently shows up in my /var/log/message file.

3.   MTRR,  Invalid opernad

4. kernel version: 2.4.4

5.   Opps message (?)Oops: 
  Apr 30 19:51:29 bugs kernel: CPU:0
  Apr 30 19:51:29 bugs kernel: EIP:0010:[]
  Apr 30 19:51:29 bugs kernel: EFLAGS: 00010202
  Apr 30 19:51:29 bugs kernel: eax: c49f3efc   ebx: c15bc440   ecx:
0001   edx: c14e9ec0
  Apr 30 19:51:29 bugs kernel: esi: 41449340   edi: c49f3f9c   ebp:
c544700d   esp: c49f3edc
  Apr 30 19:51:29 bugs kernel: ds: 0018   es: 0018   ss: 0018
  Apr 30 19:51:29 bugs kernel: Process pidof (pid: 11075,
stackpage=c49f3000)
  Apr 30 19:51:29 bugs kernel: Stack: ceeae640 fff3 c0147681
ceeae640 c49f3ef8 c49f3efc  c544700a
  Apr 30 19:51:29 bugs kernel:c14e9ec0 ceeae640 fff3
c49f3f9c c544700d c0147a4f ceeae640 c49f2000
  Apr 30 19:51:29 bugs kernel:cfd1d140 ceeae640 c01394d9
cfd1d140 c49f3f9c ceeae640 c49f3f40 c49f3f40
  Apr 30 19:51:29 bugs kernel: Call Trace: [] []
[] [] [] [] []
Apr 30 19:51:29 bugs kernel:[]

6.  I know of know program which can dupicate the problem exaclty.

7.0  Environment:
800 MHz Processor on a Asus A7V MB
256 MB PC133 memory
xfree86 4.03
distributon :RedHat 7.1


7.1.   Out output of ver_linux:
 [root@bugs scripts]# sh ver_linux
If some fields are empty or look unusual you may have an old
version.
Compare to the current minimal requirements in
Documentation/Changes.

Linux bugs.harris.org 2.4.4 #2 Sat Apr 28 21:37:19 CDT 2001 i686
unknown

Gnu C  2.96
Gnu make   3.79.1
binutils   2.10.91.0.2
util-linux 2.10s
mount  2.10r
modutils   2.4.2
e2fsprogs  1.19
PPP2.4.0
isdn4k-utils   3.1pre1
Linux C Library2.2.2
Dynamic linker (ldd)   2.2.2
Procps 2.0.7
Net-tools  1.57
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded loop NVdriver autofs tulip ipchains ide-scsi
scsi_mod ide-cd cdrom vfat fat usbmouse mousedev hid input usb-uhci
usbcore
[root@bugs scripts]#

7.2  cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 4
model name  : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 807.194
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge
mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 1608.90

7.3 cat /proc/modules:
loop8080   6 (autoclean)
NVdriver  629552  12 (autoclean)
autofs 10784   1 (autoclean)
tulip  36672   1 (autoclean)
ipchains   33136   0 (unused)
ide-scsi8032   0
scsi_mod   52928   1 [ide-scsi]
ide-cd 26400   0
cdrom  27296   0 [ide-cd]
vfat9328   1 (autoclean)
fat31392   0 (autoclean) [vfat]
usbmouse1888   0 (unused)
mousedev4128   1
hid11680   0 (unused)
input   3168   0 [usbmouse mousedev hid]
usb-uhci   21808   0 (unused)
usbcore48240   1 [usbmouse hid usb-uhci]

7.4 [pbharris@bugs pbharris]$ cat /proc/ioports
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
8000-803f : Promise Technology, Inc. 20265
  8000-8007 : ide2
  8008-800f : ide3
  8010-803f : PDC20265
8400-8403 : Promise Technology, Inc. 20265
8800-8807 : Promise Technology, Inc. 20265
9000-9003 : Promise T
echnology, Inc. 20265
9400-9407 : Promise Technology, Inc. 20265
9800-987f : Digital Equipment Corporation 

Win98 Setup ignores partition table, corrupts filesystems

[Michael D. Crawford]

Bill sez: "All Your Partition Are Belong To Us."

Do you have the pleasure of installing or using multiple operating
systems, one of which is a Microsoft product?  Then the following
information may be of great importance to you.
Failure to pay attention to warning symptoms will result in filesystem
corruption the likes of which you've never seen before.

Under certain conditions, the Windows 98 Setup drive formatter will lay
down a FAT filesystem which describes a volume larger than the partition
it is contained in.  If you then initialize other filesystems like ext2
on the same drive afterward, everything will seem to OK at first,
perhaps for weeks of use.  But the day will come that you add some new
files to your Windows partition, and your other filesystems will get
overwritten with FAT data, perhaps (as in my sorry case) unrecoverably.

I guess our friends in Redmond take the partition not as the hard and
fast barrier that most of us do, but as a mere hint of how we want our
drive laid out.  In some cases that hint is ignored and Windows will use
its own ideas to figure out how to initialize the drive.

Something else seemed to have happened besides a simple overwriting of
some filesystem sectors; my drive was bleeding like an ebola victim,
it's partition map full of garbage and me unable to find any superblocks
using disk recovery utilties like gpart, rescuept and findsuper.  I had
to declare it a total loss; fortunately I have backups so my economic
loss is just a few days work but it is a lot of effort to rebuild my
system.  Some files were not backed up and are just gone.

If you initialize your partition map so that exactly the first partition
is labeled as a FAT partition you _should_ be OK.

I recall from earlier installations that if you have some partitions,
none of which are marked as a FAT variety, Windows setup will
repartition your drive without asking and lay down a single filesystem
that uses the whole drive.  While painful, it is not disastrous because
when you go to install your other operating systems you will find their
partitions gone and you can start over before having committed important
data to the drive.  It is more of a problem if you had installed the
other operating systems first - so one tip is to install Windows first,
so that if it screws up your system you at least won't have to reinstall Linux.

The above mistake can happen if you aren't careful to set the FAT
partition type when partitioning with a Linux utility like cfdisk, fdisk
or sfdisk, perhaps while booted off an installation CD or utility floppy.

What happened to me is that I had _two_ FAT partitions, one was the
first partition in the drive, and the second was the second to last in a
drive that had lots of partitions.

I had three primary partitions, marked as FAT, ext2, BeOS, then an
extended partition with BeOS, Linux swap, BeOS, FAT32 and ext32.

The problem is that the presence of the second FAT32 partition on the
drive is taken by the formatter in the Win98 setup as a signal to ignore
the partition map and allocate the entire remaining drive space as a FAT volume.

It might make some twisted sense if it allocated all the space from the
beginning of the drive to the start of the second fat partition, but my
hazy recollection is that Windows said the filesystem had the entire
remaining space on the drive - that is, the sum of the two fat
partitions was the entire drive space, and the two filesystems
overlapped.  I'm less sure of this however.

The formatter used is the formatter that runs within the Windows 98
setup program.  This is apparently a different formatter than is
available if you don't start setup and run DOS off the Win98
installation CD.

There are two early warning signs: when Windows setup formats your C:
drive, it takes longer than it should.  I had allocated 4 GB for C: on
an 18 GB drive, and the formatting took quite a long time, because it
does bad block checking.  This would be less noticeable if the FAT
partition took up proportionally more space on your drive.  Compare the
time to the time required to low-level format the whole drive with a bad
block check.

The other warning sign is that when Windows is installed, the total size
and free space shown for the C drive is much larger than it should be. 
Here is where I am kicking myself because I had noticed it, and I just
assumed it was a bug in the code that displayed the free space.  I
simply didn't conceive of the possibility that a bad filesystem had been written.

If you mount the fat partition under Linux, df will show a total size
and free space indicating the same size that Windows thinks it is.  This
will be larger than the partition size.  So one tip is, after formatting
the drive under Windows setup, quit from setup and restart off a Linux
installation CD, mount the FAT partition and check the size with df. 
Doing this, I found after my reformat, repartition and first attempt at
reinstalling the Windows had done it 

Athlon and fast_page_copy: What's it worth ? :)

[Seth Goldberg]

Hi,

  Before I go any further with this investigation, I'd like to get an
idea
of how much of a performance improvement the K7 fast_page_copy will give
me.
Can someone suggest the best benchmark to test the speed of this
routine?

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

Re: 2.4.x APM interferes with FA311TX/natsemi.o

[Paul Komarek]

On Tue, 1 May 2001, Alan Cox wrote:

> > When the call
> >   apm_bios_call_simple(APM_FUNC_SET_STATE, 0x100, APM_STATE_READY, )
> > is made, the PMEEN (PME enable) bit in the CCSR register on my FA311
> > mysteriously changes from 0 to 1, causing the card to stop processing
> 
> The Linux driver set the power management of the card off. The BIOS then 
> rudely fiddled with it. If its not a laptop seriously consider just turning
> off APM support. The Linux idle loop halts will do a fair job of power
> saving anyway

Thanks to everyone that has helped me with this problem (Netgear FA311
dies when apm.c's set_power_state() is called to unblank screen, for
instance when an X server exits or the monitor is awakened from
APM-induced sleep).  Since everyone has suggested work arounds, I'm going
to assume it isn't worthwhile digging any deeper for causes.

I've sent a two-line patch for the natsemi.c driver to the mainainers,
which simply re-disables power management before checking if there are any
packets to process in the receive buffer.  Turning off the APM screen
blanking option in the kernel also works.  My patch isn't in the 2.4.4
kernel -- perhaps the maintainers have a better idea than my hack, or are
hoping to find one =-) -- but if anybody wants this patch, my email
address should be valid at least until the 2.6.x kernels.

-Paul Komarek
[EMAIL PROTECTED]



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

Re: REVISED: Experimentation with Athlon and fast_page_copy

[Seth Goldberg]

Chris Wedgwood wrote:
> 
> On Fri, May 04, 2001 at 05:26:57PM -0700, Joseph Carter wrote:
> 
> I don't see how they figure, but in case there was any doubt I
> have a VIA KT133A/686B board (Abit KT7A) and don't experience
> anything resembling disk corruption unless the box crashes for
> some other reason.  I do seem to be experiencing AGP problems in
> spades, but my disks at least are fine.
> 
> I too seem no disk problems whatsoever (nothing really interesting
> there, many people do not) but am also seeing AGP problems.
> 
> In fact, I had to disable AGP to stop X locking the box hard... yet
> agpgart and the video driver (NVidia[1]) both claim to support the
> chipset -- does anyone actually have this working?)

  My IWILL (KT133A) + GeForce 256 are working fine over AGP.

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

Re: PROBLEM: 2.4.5pre1 will not boot

[Seth Goldberg]

Gordon Sadler wrote:
> 
> On Fri, May 04, 2001 at 01:28:23AM -0700, Seth Goldberg wrote:Seth Goldberg 
><[EMAIL PROTECTED]>
> > Gordon Sadler wrote:
> > >
> > > On Fri, May 04, 2001 at 12:43:22AM -0700, Seth Goldberg wrote:
> > > > Hi,
> > Hi,
> >
> >  Have you tried compiling ther kernel with Athlon optimiztions turned

> I've seen some others reporting some success with K6-II[I] or
> Pentium-II[I] configurations. I haven't tried it here as 2.2.19 is
> running fine for me. -) I just keep trying the new 2.4.x and reporting
> here with hopes someone will find the problem and be able to resolve it.
> There could very well be something wrong with my/our hardware. I'm at a
> loss as to why none of the developers can reproduce this? Is it possible
> none of the 'core' developers have/have access to this hardware? It
> isn't all that unusual I think.

  Yep.  I think it's just the fact that the KT133A chipset is so new
that
very few people have it.  And of the people who have it, I think a great
majority are running on distributions of Linux whose kernels are
NOT athlon optimized.  

  I'd like to ask everyone who has a KT133A to please try a 2.4.x kernel
with Athlon optimizations and let us know what percentage are displaying
this problem. 
 
  Thank you!
  --Seth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.4.5pre1 will not boot

[Gordon Sadler]

On Fri, May 04, 2001 at 01:28:23AM -0700, Seth Goldberg wrote:Seth Goldberg 
<[EMAIL PROTECTED]>
> Gordon Sadler wrote:
> > 
> > On Fri, May 04, 2001 at 12:43:22AM -0700, Seth Goldberg wrote:
> > > Hi,
> Hi,
> 
>  Have you tried compiling ther kernel with Athlon optimiztions turned
> off (try
> compiling for a K6-II[I])?  The has stopped the same thing from
> happening on
> my system and those of a few other people.
> 
I've seen some others reporting some success with K6-II[I] or
Pentium-II[I] configurations. I haven't tried it here as 2.2.19 is
running fine for me. -) I just keep trying the new 2.4.x and reporting
here with hopes someone will find the problem and be able to resolve it.
There could very well be something wrong with my/our hardware. I'm at a
loss as to why none of the developers can reproduce this? Is it possible
none of the 'core' developers have/have access to this hardware? It
isn't all that unusual I think.

If anyone needs more info, just ask. Lots of time/hardrive space here
available for experimenting. (As long as you don't blow it up -) ).

Gordon Sadler


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

Re: anybody home at device@lanana.org?

[Mr. James W. Laferriere]

Hello Peter ,  Would also please drop a line as to what is going
on to the rest of the community as well .  Tia , JimL

On 23 Apr 2001, H. Peter Anvin wrote:
> Followup to:  <[EMAIL PROTECTED]>
> By author:Kipp Cannon <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> > I've sent some messages to [EMAIL PROTECTED] but haven't received any
> > responses.  Does anyone know if there's anybody home?
> Yes, but there are some issues with respect to device registration
> right now.  I will be sending out a message explaining in detail to
> the people who have pending registrations sometime this week.
>   -hpa
   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

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

Re: REVISED: Experimentation with Athlon and fast_page_copy

[Dieter Nützel]

> What still stands out is that exactly _zero_ people have reported the same
> problem with non VIA chipset Athlons.

Sorry Alan, but...

My (very) old Athlon 550 (model 1, stepping 2) show it on my MSI MS-6167 (AMD 
Irongate C4) with your 2.4.4-ac5, now :-(
Even with or without apm/acpi enabled.
It freezes during "Freeing unused kernel memory: 172k freed".
Never saw this before.

I am open for any test fixes...

-Dieter

SuSE 7.1 (glibc-2.2, gcc-2.95.2)

Linux version 2.4.4 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) 
#1 Sun Apr 29 02:30:34 CEST 2001
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 13ff (usable)
 BIOS-e820: 13ff - 13ff3000 (ACPI NVS)
 BIOS-e820: 13ff3000 - 1400 (ACPI data)
 BIOS-e820:  - 0001 (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009f800 for 4096 bytes.
On node 0 totalpages: 81904
zone(0): 4096 pages.
zone(1): 77808 pages.
zone(2): 0 pages.
mapped APIC to e000 (01555000)

SunWave1>cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 1
model name  : AMD-K7(tm) Processor
stepping: 2
cpu MHz : 548.950
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov 
pat mmx syscall mmxext 3dnowext 3dnow
bogomips: 1094.45

-- 
Dieter Nützel
Graduate Student, Computer Science

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

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

[PATCH] (was Re: 2.4.4 & IPv6 oopses)

[David S. Miller]

Pekka Savola writes:
 > struct in6_addr *saddr = NULL;
 > [...]
 > if (skb && ipv6_chk_addr(>nh.ipv6h->saddr, dev))
 > saddr = >nh.ipv6h->saddr;
 > [...]
 >  ndisc_send_ns(dev, neigh, target, target, saddr);
 > [...]
 > This check apparently fails? and saddr is left null.

Yes, it can fail, and this is normal.  The problem is in
ndisc_send_ns().

 > in ndisc_send_ns, NULL saddr is checked:
 > 
 > send_llinfo = dev->addr_len && ipv6_addr_type(saddr) != IPV6_ADDR_ANY;
 > 
 > which make a null ptr dereference.  send_llinfo check was added recently
 > to fix RFC incompliancy a week or so ago.

A few lines later we setup saddr properly if it is NULL, what we need
to do is either:

1) Move that "if (saddr == NULL)" code block up above the send_llinfo
   check.

   I think this would break the thing the send_llinfo check
   was meant to fix, but I can't be sure.

2) Just check for NULL saddr in the send_llinfo check and if NULL
   then send_llinfo is set to zero.

For now, I've put solution #2 into my tree, patch attached below.

--- linux/net/ipv6/ndisc.c.~1~  Thu May  3 00:01:10 2001
+++ linux/net/ipv6/ndisc.c  Fri May  4 18:44:54 2001
@@ -382,7 +382,7 @@
int send_llinfo;
 
len = sizeof(struct icmp6hdr) + sizeof(struct in6_addr);
-   send_llinfo = dev->addr_len && ipv6_addr_type(saddr) != IPV6_ADDR_ANY;
+   send_llinfo = dev->addr_len && saddr && ipv6_addr_type(saddr) != IPV6_ADDR_ANY;
if (send_llinfo)
len += NDISC_OPT_SPACE(dev->addr_len);
 




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

Re: How to debug a 2.4.4 tulip problem?

[Wayne Whitney]

On Sat, 5 May 2001, Manfred Spraul wrote:

> Do you know if transmit or receive is slow? tcpdump on both ends of
> the ping might help.

Sorry, I don't currently know.

OK, the next time I see this, I'll give tulip-diag a whirl and report
back.  Until then, I can't really provide any more details.

Thanks, Wayne


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

Compressed iso9660 filesystem

[H. Peter Anvin]

Okay, I think I now feel comfortable enough that I think I can unleash
this on the world...

I have made an extension to iso9660/RockRidge to allow for transparent
uncompression of block-compressed files.  Because the files are
block-compressed, random access is fast; it uses a 32K blocksize which
gets pretty good compression ratios (I got 2:1 overall compression on
my SuperRescue CD; that includes a fair number of incompressible
files.)

The patches are available as:

ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/filemap-2.4.4-1.diff.gz
ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/zisofs-2.4.5-pre1-5.diff.gz

(Both are needed.)

Additionally, the user-space utilities (a program to compress and
uncompress file trees, and a patch to mkisofs to generate the new
RockRidge records for compressed files) are available at:

ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/zisofs/

If you test this out, please let me know; I'd like to know if anyone
actually cares about this... also, I would like to gauge if I have
messed up stability anywhere.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to debug a 2.4.4 tulip problem?

[Manfred Spraul]

> 
> What information should I gather when the card is wedged to aid in 
> debugging? Is 'lspci -xxx' enough? Any suggestions would be welcome. 
>
tulip-diag from www.scyld.com.

Do you know if transmit or receive is slow? tcpdump on both ends of the
ping might help.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

CML2 1.4.0, aka "brutality and heuristics"

[Eric S. Raymond]

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

Release 1.4.0: Fri May  4 18:18:15 EDT 2001
* Ugly hack for recovery from inconsistent configurations.

We've spent a lot of time and effort recently arguing about elaborate
recovery algorithms for the extremely unusual case that the CML2
configurator loads a configuration that has become invalid because of
a constraint added to the rulebase since the configuration was
written.  (Mere addition of new symbols doesn't trigger this.)

The general problem is theoretically hard and for practical purposes
insoluble, so I've have implemented a suggestion by Dave Wagner and
John Stoffel.  CML2 will now try to recover fom a load-time
inconsistency by smashing all the non-frozen symbols in the violated
constraint to the value N (and notifying the user that it's doing so).
This is ugly, but will handle most cases.  In the few it doesn't
handle, the bindings loaded from the file will be backed out as a
unit.  In any case the user will be left in a running configurator.

Sigh...now, I hope, we can get back to solving problems that I don't
expect to be so rare they're lost in the statistical noise.  It's not
good to get so obsessed about finding clever solutions to corner cases
that one loses sight of the larger issues.
-- 
http://www.tuxedo.org/~esr/;>Eric S. Raymond

The prestige of government has undoubtedly been lowered considerably
by the Prohibition law. For nothing is more destructive of respect for
the government and the law of the land than passing laws which cannot
be enforced. It is an open secret that the dangerous increase of crime
in this country is closely connected with this.
-- Albert Einstein, "My First Impression of the U.S.A.", 1921
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

How to debug a 2.4.4 tulip problem?

[Wayne Whitney]

Hello,

I'm having a small intermittent problem with the tulip driver in linux
2.4.4, and I'm looking for some guidance on how to debug it.

What happens is that on one of my boxes the card ocasionally gets wedged.
That is, network traffic gets painfully slow, e.g. pinging another host on
the same segment causes each ping to take (almost exactly) 1 second,
rather than the usual 200 usecs or so.  Executing ifup/ifdown unwedges the
card.

Some relevant details about this box:
 eth0: Lite-On 82c168 PNIC rev 32 at 0xb800, 00:C0:F0:2D:3D:8A, IRQ 17.
 MSI-6321 motherboard (VIA Apollo Pro)

Now I have a similar box that I think does not show the problem (not 100%
sure).  It has:
 eth0: Lite-On 82c168 PNIC rev 33 at 0xe800, 00:A0:CC:3F:33:32, IRQ 18.
 Tekram P6B40D-A5 motherboard (Intel 440BX)

As a wild guess, it seems like when the card is wedged, some interrupt is
getting lost, so that the transmit or send doesn't occur until a timer
times out.  Perhaps there is a bug in rev 32 of this card that is not in
rev 33.

What information should I gather when the card is wedged to aid in
debugging?  Is 'lspci -xxx' enough?  Any suggestions would be welcome.

Cheers,
Wayne

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

Re: REVISED: Experimentation with Athlon and fast_page_copy

[Joseph Carter]

On Fri, May 04, 2001 at 06:26:14PM -0400, Aaron Tiensivu wrote:
> This might be grasping at straws I remember VIA problem in the "good old
> days" of Socket 7 with CPU/PCI Prefetches and especially Read-around-Write
> settings that would cause issues like we're seeing with the Athlon
> pre-fetches. This could be (total conjecture) related somehow to the
> corruption bugs they are admitting to in the 686B although they are blaming
> the SB Live now.

I don't see how they figure, but in case there was any doubt I have a VIA
KT133A/686B board (Abit KT7A) and don't experience anything resembling
disk corruption unless the box crashes for some other reason.  I do seem
to be experiencing AGP problems in spades, but my disks at least are fine.

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

<_Anarchy_> Argh.. who's handing out the paper bags  8)


 PGP signature

Re: [PATCH] 3 one-liner bugfixes

[Manfred Spraul]

Manfred Spraul wrote:
> 
> +   else
> +   fl->fl_type & ~F_INPROGRESS;
   ^^
> +   unlock_kernel();
> +   return ret;
>  }

The last patch was incorrect. Corrected version attached.

--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 4
//  EXTRAVERSION =
--- 2.4/fs/fcntl.c  Thu Nov 16 07:50:25 2000
+++ build-2.4/fs/fcntl.cSat May  5 00:32:17 2001
@@ -338,7 +338,6 @@
if (!filp)
goto out;
 
-   lock_kernel();
switch (cmd) {
case F_GETLK64:
err = fcntl_getlk64(fd, (struct flock64 *) arg);
@@ -353,7 +352,6 @@
err = do_fcntl(fd, cmd, arg, filp);
break;
}
-   unlock_kernel();
fput(filp);
 out:
return err;
--- 2.4/fs/locks.c  Sun Apr 22 13:21:33 2001
+++ build-2.4/fs/locks.cSat May  5 01:54:59 2001
@@ -1157,11 +1157,16 @@
 int fcntl_getlease(struct file *filp)
 {
struct file_lock *fl;
-   
+   int ret;
+
+   lock_kernel();
fl = filp->f_dentry->d_inode->i_flock;
if ((fl == NULL) || ((fl->fl_flags & FL_LEASE) == 0))
-   return F_UNLCK;
-   return fl->fl_type & ~F_INPROGRESS;
+   ret = F_UNLCK;
+   else
+   ret = fl->fl_type & ~F_INPROGRESS;
+   unlock_kernel();
+   return ret;
 }
 
 /* We already had a lease on this file; just change its type */
@@ -1357,7 +1362,9 @@
goto out_putf;
 
if (filp->f_op && filp->f_op->lock) {
+   lock_kernel();
error = filp->f_op->lock(filp, F_GETLK, _lock);
+   unlock_kernel();
if (error < 0)
goto out_putf;
else if (error == LOCK_USE_CLNT)
@@ -1481,7 +1488,9 @@
}
 
if (filp->f_op && filp->f_op->lock != NULL) {
+   lock_kernel();
error = filp->f_op->lock(filp, cmd, file_lock);
+   unlock_kernel();
if (error < 0)
goto out_putf;
}
@@ -1522,7 +1531,9 @@
goto out_putf;
 
if (filp->f_op && filp->f_op->lock) {
+   lock_kernel();
error = filp->f_op->lock(filp, F_GETLK, _lock);
+   unlock_kernel();
if (error < 0)
goto out_putf;
else if (error == LOCK_USE_CLNT)
@@ -1619,7 +1630,9 @@
}
 
if (filp->f_op && filp->f_op->lock != NULL) {
+   lock_kernel();
error = filp->f_op->lock(filp, cmd, file_lock);
+   unlock_kernel();
if (error < 0)
goto out_putf;
}

Re: Setting kernel options at compile time.

[H. Peter Anvin]

Followup to:  
By author:(Chip Schweiss) [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
> 
> The catch I'm running into is RPLD cannot pass parameters to the kernel 
> and without this setting the system has video problem, most likely from 
> the memory sharing issues.  When the mem parameter is set when using a 
> disk it doesn't demonstrate any problems.
> 

What is RPLD?

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 3 one-liner bugfixes

[Manfred Spraul]

Linus Torvalds wrote:
> 
> On Sat, 5 May 2001, Manfred Spraul wrote:
> >
> > * missing/wrong lock_kernel calls in fs/fcntl.c: getlk/setlk run without
> > the big kernel lock. The ..64 function acquire the lock.
> 
> This is wrong. The big lock (if it is needed, but I thought the current
> locking should be safe) should be pushed down into the point where it is
> needed, not at the caller..
>
Ok, I've removed the locks from fs/fcntl.c and added them into
fs/locks.c:

* fcntl_getlease dereferences filp->f_dentry->d_inode->i_flock. Race
with multithreaded app: sys_close()->filp_close()->locks_remove_posix()
+ fcntl_getlease()
* according to Documentation/filesystems/Locking, f_op->lock() is called
with the blk acquired. lock added around that call in
fcntl_{get,set}lk{,64}

I've attached a new patch.

--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 4
//  EXTRAVERSION =
--- 2.4/fs/fcntl.c  Thu Nov 16 07:50:25 2000
+++ build-2.4/fs/fcntl.cSat May  5 00:32:17 2001
@@ -338,7 +338,6 @@
if (!filp)
goto out;
 
-   lock_kernel();
switch (cmd) {
case F_GETLK64:
err = fcntl_getlk64(fd, (struct flock64 *) arg);
@@ -353,7 +352,6 @@
err = do_fcntl(fd, cmd, arg, filp);
break;
}
-   unlock_kernel();
fput(filp);
 out:
return err;
--- 2.4/fs/locks.c  Sun Apr 22 13:21:33 2001
+++ build-2.4/fs/locks.cSat May  5 01:20:50 2001
@@ -1157,11 +1157,16 @@
 int fcntl_getlease(struct file *filp)
 {
struct file_lock *fl;
-   
+   int ret;
+
+   lock_kernel();
fl = filp->f_dentry->d_inode->i_flock;
if ((fl == NULL) || ((fl->fl_flags & FL_LEASE) == 0))
-   return F_UNLCK;
-   return fl->fl_type & ~F_INPROGRESS;
+   ret = F_UNLCK;
+   else
+   fl->fl_type & ~F_INPROGRESS;
+   unlock_kernel();
+   return ret;
 }
 
 /* We already had a lease on this file; just change its type */
@@ -1357,7 +1362,9 @@
goto out_putf;
 
if (filp->f_op && filp->f_op->lock) {
+   lock_kernel();
error = filp->f_op->lock(filp, F_GETLK, _lock);
+   unlock_kernel();
if (error < 0)
goto out_putf;
else if (error == LOCK_USE_CLNT)
@@ -1481,7 +1488,9 @@
}
 
if (filp->f_op && filp->f_op->lock != NULL) {
+   lock_kernel();
error = filp->f_op->lock(filp, cmd, file_lock);
+   unlock_kernel();
if (error < 0)
goto out_putf;
}
@@ -1522,7 +1531,9 @@
goto out_putf;
 
if (filp->f_op && filp->f_op->lock) {
+   lock_kernel();
error = filp->f_op->lock(filp, F_GETLK, _lock);
+   unlock_kernel();
if (error < 0)
goto out_putf;
else if (error == LOCK_USE_CLNT)
@@ -1619,7 +1630,9 @@
}
 
if (filp->f_op && filp->f_op->lock != NULL) {
+   lock_kernel();
error = filp->f_op->lock(filp, cmd, file_lock);
+   unlock_kernel();
if (error < 0)
goto out_putf;
}

Re: SMP races in proc with thread_struct

[Keith Owens]

On 04 May 2001 15:11:37 +0200, 
Andreas Schwab <[EMAIL PROTECTED]> wrote:
>Keith Owens <[EMAIL PROTECTED]> writes:
>|> Wrap the reference to the parent task structure with exception table
>|> recovery code, like copy_from_user().
>
>Exception tables only protect accesses to user virtual memory.  Kernel
>memory references must always be valid in the first place.

Wrong.  Exception tables say that if the kernel gets an exception
between labels A and B then branch to fixup label C.  See show_regs()
in arch/i386/kernel/process.c and wrmsr_eio() in arch/i386/kernel/msr.c
for examples which do not depend on user virtual memory.

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

Re: [linux-usb-devel] pegasus + MediaGX: Oops in khubd,the continuing story?

[David Brownell]

> I suspect the ohci driver currently. I've been reviewing it a little and it
> is full of code written by someone who does not know about pci write posting.

I think there's a lot of that going around ... I don't think any of what you
mentioned was in the Documentation/pci.txt writeup, or any other source
of kernel documentation I found when I started to look at at that code!

That diagnosis works as well with the known facts as any other; maybe
better, considering some of the info I've collected offline.  And it could
also explain some other intermittent failures.


> You have to do
> 
> writel(STOP, reg->dmactrl);
> [posted]
> readl(reg->dmactrl)
> [read forces write, read reply will follow any DMA
> pending the other way]

Good to know.  That'd apply for any register read, not just the
one that was written to, yes?

- Dave


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

Re: Setting kernel options at compile time.

[Brian Gerst]

Chip Schweiss wrote:
> 
> I'm trying to get a 2.2.19 kernel loaded on an i810 system using RPLD on
> a diskless system.  I can get the kernel loaded and running.  The
> problem is the i810 needs the kernel parameter "mem=xxxM" set to tell
> the kernel how much memory the system has since the on the i810 the
> kernel doesn't know how much was taken for video.
> 
> The catch I'm running into is RPLD cannot pass parameters to the kernel
> and without this setting the system has video problem, most likely from
> the memory sharing issues.  When the mem parameter is set when using a
> disk it doesn't demonstrate any problems.
> 
> What I'm trying to figure out is how to compile in this setting.
> 
> Thanks,
> Chip Schweiss

Try a 2.4 kernel.  If the BIOS is reserving memory for the video card it
should show up in the e820 memory map.  2.2.x last I checked doesn't use
e820 for memory detection.

-- 

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

Re: Memory management issues with 2.4.4

[Jorge Nerin]

Marcelo Tosatti wrote:

 >
 > On Wed, 2 May 2001, Jorge Nerin wrote:
 >
 >> Short version:
 >> Under very heavy thrashing (about four hours) the system either lockups
 >> or OOM handler kills a task even when there is swap space left.
 >
 >
 > First of all, please try to reproduce the problem with 2.4.5-pre1.
 >
 > If it still happens with pre1, please show us the output of "cat
 > /proc/slabinfo" when the kernel is about to trigger the OOM killer.
 >
 > Thanks.
 >


Well, as I had said this morning I have feed the Oops to ksymoops, note 
that I may have mirtyped something, but anyway here is the output of 
ksymoops:


ksymoops 2.3.4 on i586 2.4.5-pre1.  Options used
  -V (default)
  -k /proc/ksyms (default)
  -l /proc/modules (default)
  -o /lib/modules/2.4.5-pre1/ (default)
  -m /usr/src/linux/System.map (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.

Warning (compare_maps): ksyms_base symbol 
__VERSIONED_SYMBOL(shmem_file_setup) not found in System.map.  Ignoring 
ksyms_base entry
invalid operand: 
CPU: 1
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010096
eax: 001b ebx:  ecx: 0001 edx: 0001
esi: c021b960 edi: c5fe2000 ebp: c5fe3ce0 esp: c5fe3c88
Stack: c01e89a5 c01c8af6 02c5  c021b960 c021b954  
0001
0020 00cc c02961c0 0120 c012ca08 c5fe2000  
c216960
c21b954  c5fe2000 0080 0001 c5fe2000 0001 0001 
c12da64
Call Trace:   [] [] [] [] 
[] [] []
  [] [] [] [] [] 
[] [] []
  [] [] [] [] [] 
[] [] []
  [] [] [] [] [] 
[] [] []
Code: 0f 0b 8d 65 b4 5b 5f 89 ec 5d c3 55 89 e5 83 ec 18 57 56

 >>EIP; 0c0123c4 Before first symbol   <=
Trace; c012ca08 
Trace; c012da64 <__alloc_pages+16c/2c0>
Trace; c012dbcc <__get_free_pages+14/20>
Trace; c0113bbb 
Trace; c01058c9 
Trace; c0106d07 
Trace; c010e568 
Trace; c01054ea 
Trace; c010e591 
Trace; c010e568 
Trace; c01746de 
Trace; c0172dfd 
Trace; c0173fcc 
Trace; c017405c 
Trace; c0108516 
Trace; c0108709 
Trace; c0106de0 
Trace; c010fc60 
Trace; c0129e78 
Trace; c0129c78 
Trace; c0129e52 
Trace; c0129e78 
Trace; c0129f56 
Trace; c0129e78 
Trace; c0129f83 <__kmem_cache_shrink+b/6c>
Trace; c0129a29 
Trace; c01471a4 
Trace; c012cc9b 
Trace; c012cd2b 
Trace; c0105000 
Trace; c01054f3 
Code;  0c0123c4 Before first symbol
 <_EIP>:
Code;  0c0123c4 Before first symbol   <=
0:   0f 0b ud2a  <=
Code;  0c0123c6 Before first symbol
2:   8d 65 b4  lea0xffb4(%ebp),%esp
Code;  0c0123c9 Before first symbol
5:   5bpop%ebx
Code;  0c0123ca Before first symbol
6:   5fpop%edi
Code;  0c0123cb Before first symbol
7:   89 ec mov%ebp,%esp
Code;  0c0123cd Before first symbol
9:   5dpop%ebp
Code;  0c0123ce Before first symbol
a:   c3ret
Code;  0c0123cf Before first symbol
b:   55push   %ebp
Code;  0c0123d0 Before first symbol
c:   89 e5 mov%esp,%ebp
Code;  0c0123d2 Before first symbol
e:   83 ec 18  sub$0x18,%esp
Code;  0c0123d5 Before first symbol
   11:   57push   %edi
Code;  0c0123d6 Before first symbol
   12:   56push   %esi

Kernel panic Aiee killing interrupt handler

2 warnings issued.  Results may not be reliable.

As I said I have tried to no make errors, but I copied it at 7 in the 
morning, so who knows ... ;-)

-- 
Jorge Nerin
<[EMAIL PROTECTED]>



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

Linux 2.4.4-ac5

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

Intermediate diffs are available from

http://www.bzimage.org

Please test this code **carefully** if using an HPT366/370 IDE controller as
there are driver changes there. Otherwise its mostly just catching up with
the bugfixes.

2.4.4-ac5
o   Fix DMA setup on hpt366/370 (Tim Hockin)
o   DRM memory alloc failure checks (Akash Jain)
o   Remove bogus fs/buffer.c diff   (Ben LaHaise)
o   cs46xx update - adds Hercules Game Theatre XP   (Thomas Woller)
o   Fix menuconfig breakage with () (Andrzej Krzysztofowicz)
o   Updated multithreaded core dump support (Don Dugger)
o   Remove dead ibmtr.h include (Mike Phillips)
o   Fix misplaced letters in koi8-u (Andriy Rysin)
o   Further alpha module locking fix(Andrea Arcangeli)
o   Keyspan bitwidth fixes  (Hugh Blemings)
o   usb-uhci oops fix   (Pete Zaitcev)
o   Add ability to specify preferred minor on   (Gerd Knorr)
video/radio4linux devices
o   Further IPX updates (Arnaldo Carvalho de Melo)
o   Further IRDA updates(Dag Brattli)
o   Make x86 ptrace framesize a define (code clean) (Pavel Machek)
o   Moxa serial tidy(Tim Hockin)
o   Fix tiny select race(Rusty Russell)
o   Update aic7xxx to 6.1.12(Justin Gibbs)
o   Alpha was missing rwlock_init   (Reto Baettig)
o   Alpha SCHED_YIELD was broken on UP  (Andrea Arcangeli)
o   Allow IRQ sharingon more PCI ide(Pete Zaitcev)
o   Fix capable checks found by Stanford analyser   (me)
for cciss/cpqarray
o   List more devices in sysrq table(Andrzej Krzysztofowicz)
o   Run uml exit callbacks reverse to init  (Andrew Morton)
o   Fix SMP resched_idle pre-emption bug(Nigel Gamble)
o   Work around config problem with menuconfig
and USB (Andrzej Krzysztofowicz)
o   Fix nasty bug in Alpha PCI mapping  (Hyung Min SEO)
| Nautilus specific stuff not applied yet
o   SBLive endianness fixes (output only so far)(Ira Weiny)
o   Move sblive pci_enable earlier  (Marcus Meissner)
o   Merge IBM ServeRAID 4.72 driver (Keith Mitchell)
o   Fix affs races  (Roman Zippel)
o   Fix cdrom unload crash  (Andrzej Krzysztofowicz)

2.4.4-ac4
o   Fix future domain scsi  (Carlo Prelz)
o   Merge Linux 2.4.5pre1
o   Fix ipx without sysctl compile  (Pavel Roskin)
o   Revert fork changes to match Linus 2.4.5pre1
o   Drop the threaded core dump code
| It can go back in when it works
o   Drop pa-risc work - it'll be easier to resync
just once as pa has moved on a lot
o   Add spin_lock_prefetch to get_empty_inode   (me)
| Experimenting
o   Kbuild has moved(Keith Owens)
o   Update kernel docs on memory barriers   (Rusty Russell)
o   Move es1370 pci_enable and do some cleanup  (Marcus Meissner)
o   Fix netfilter overuse of __exit (Rusty Russell)
o   Fix alpha build bug (Michal Jaegermann)
o   Fix tigon1 build(Olivier Galibert)
o   Fix tmpfs deadlocks writing into a file from(Christoph Rohland)
an mmap of itself
o   Fix missing (but harmless) return in vmtruncate (Al Viro)

2.4.4-ac3
o   Fix hang on boot with SMP   (Andrea Arcangeli)
| and fixes a few more uglies too
o   freevxfs module name was wrong (should be   (me)
freevxfs.o)
o   Update alloc_etherdev docs  (Erik Mouw)
o   Remove dead funcs, put back ip_set_manually (David Miller,
in the ipconfig code(Arnaldo Carvalho de Melo)
o   Fix SA_ONSTACK standards violation (for x86)(Christian Ehrhardt)
| Other arch maintainers should check..
o   Add another species of SB AWE 32(Bill Nottingham)
o   SE401 USB camera driver (Jeroen Vreeken)
o   Correct MAX_HD and make stuff static in ps2esdi (Hal Duston)
o   Fix inode-nr corruption (Al Viro)
o   Fix pgd_alloc for user mode linux   (Jeff Dike)
o   Fix UML hostfs for get_hardsect_size(Jeff Dike)
o   Tidy up APM options setting, add module opts(Stephen Rothwell)
o   Fix acm open race   (Oliver 

Re: REVISED: Experimentation with Athlon and fast_page_copy

[Aaron Tiensivu]

> What still stands out is that exactly _zero_ people have reported the same
> problem with non VIA chipset Athlons.

This might be grasping at straws I remember VIA problem in the "good old
days" of Socket 7 with CPU/PCI Prefetches and especially Read-around-Write
settings that would cause issues like we're seeing with the Athlon
pre-fetches. This could be (total conjecture) related somehow to the
corruption bugs they are admitting to in the 686B although they are blaming
the SB Live now.



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

Re: 2.4.4-ac4 - oops on unload "cdrom" module

[Jens Axboe]

On Fri, May 04 2001, Pavel Roskin wrote:
> > The following patch fixes unloading of cdrom module when no cdrom driver
> > loaded (2.4.5-pre, 2.4.4-ac):
> 
> It works for me. Thank you! You have even managed to find out that I had
> my CD-ROM disconnected :-)
> 
> By the way, shouldn't we register sysctl, /proc/sys/dev/cdrom/ and
> /dev/cdrom/ always when the cdrom driver is loaded/initialized, not when a
> cdrom unit is found?
> 
> I don't know what's the official "policy" is, but wouldn't it be logical
> to have some control over the drivers that handle no devices in the
> moment?

We should, the -ac tree has the first cut of the cdrom updates and they
didn't have the linking right. The right init sequence fixes the issue
as well, not just initing after the first cdrom driver registers.

-- 
Jens Axboe

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

Re: [Patch] sis_main.c

[Christopher Kanaan]

Sorry


--- /usr/src/linux/drivers/video/sis/sis_main.c Fri Feb  9 11:30:23 2001
+++ ./sis_main.cFri May  4 07:34:47 2001
@@ -1030,6 +1030,10 @@
if (heap.pohFreeList == NULL) {
poha = kmalloc(OH_ALLOC_SIZE, GFP_KERNEL);
 
+   if(!poha) {
+   return(NULL);
+ }
+
poha->pohaNext = heap.pohaChain;
heap.pohaChain = poha;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.4-ac4 - oops on unload "cdrom" module

[Jens Axboe]

On Fri, May 04 2001, Andrzej Krzysztofowicz wrote:
> > This oops happens when I run "rmmod cdrom" on a 2.4.4-ac4 kernel with
> > CONFIG_SYSCTL enabled. It doesn't happen if CONFIG_SYSCTL is disabled.
> > 
> > sr_mod isn't loaded at this point. Reference to sd_mod looks weird. After
> > this oops the "cdrom" module remains in memory in the "deleted" state.
> 
> > Unable to handle kernel NULL pointer dereference at virtual address 0008
> [...]
> > >>EIP; c0118051<=
> 
> The following patch fixes unloading of cdrom module when no cdrom driver
> loaded (2.4.5-pre, 2.4.4-ac):
> 
> --- drivers/cdrom/cdrom.c.old Fri May  4 22:44:31 2001
> +++ drivers/cdrom/cdrom.c Fri May  4 22:54:36 2001
> @@ -2698,7 +2698,8 @@
>  
>  static void cdrom_sysctl_unregister(void)
>  {
> - unregister_sysctl_table(cdrom_sysctl_header);
> + if (cdrom_sysctl_header)
> + unregister_sysctl_table(cdrom_sysctl_header);
>  }
>  
>  #endif /* CONFIG_SYSCTL */

Thanks applied.

-- 
Jens Axboe

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

Re: [PATCH] 3 one-liner bugfixes

[Linus Torvalds]

On Sat, 5 May 2001, Manfred Spraul wrote:
>
> * missing/wrong lock_kernel calls in fs/fcntl.c: getlk/setlk run without
> the big kernel lock. The ..64 function acquire the lock.

This is wrong. The big lock (if it is needed, but I thought the current
locking should be safe) should be pushed down into the point where it is
needed, not at the caller..

Linus

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

Re: Setting kernel options at compile time.

[Alan Cox]

> a diskless system.  I can get the kernel loaded and running.  The 
> problem is the i810 needs the kernel parameter "mem=xxxM" set to tell 
> the kernel how much memory the system has since the on the i810 the 
> kernel doesn't know how much was taken for video.

The BIOS itself marks off the block of memory used in VGA emulation
modes. The agpgart driver then gets used by X11 to allocate for the other
modes it uses.  At least for every i810 device I have ever seen.

Alan

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

Setting kernel options at compile time.

[Chip Schweiss]

I'm trying to get a 2.2.19 kernel loaded on an i810 system using RPLD on 
a diskless system.  I can get the kernel loaded and running.  The 
problem is the i810 needs the kernel parameter "mem=xxxM" set to tell 
the kernel how much memory the system has since the on the i810 the 
kernel doesn't know how much was taken for video.

The catch I'm running into is RPLD cannot pass parameters to the kernel 
and without this setting the system has video problem, most likely from 
the memory sharing issues.  When the mem parameter is set when using a 
disk it doesn't demonstrate any problems.

What I'm trying to figure out is how to compile in this setting.

Thanks,
Chip Schweiss
 

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

[PATCH] 3 one-liner bugfixes

[Manfred Spraul]

Hi Linus,

I found a 3 small bugs:

* mm/slab.c: the offslab_limit calculation used 2 instead of
sizeof(kmem_bufctl_t) [==4]. Cosmetic bug, since offslab_limit is never
reached.

* expand_stack is not down_read() safe, but used in the page-in path.
Fix is trivial.

* missing/wrong lock_kernel calls in fs/fcntl.c: getlk/setlk run without
the big kernel lock. The ..64 function acquire the lock.

--
Manfred

--- 2.4/mm/slab.c   Sat Mar  3 17:58:05 2001
+++ build-2.4/mm/slab.c Sat Mar  3 19:57:16 2001
@@ -448,7 +448,7 @@
/* Inc off-slab bufctl limit until the ceiling is hit. */
if (!(OFF_SLAB(sizes->cs_cachep))) {
offslab_limit = sizes->cs_size-sizeof(slab_t);
-   offslab_limit /= 2;
+   offslab_limit /= sizeof(kmem_bufctl_t);
}
sprintf(name, "size-%Zd(DMA)",sizes->cs_size);
sizes->cs_dmacachep = kmem_cache_create(name, sizes->cs_size, 0,


--- 2.4/include/linux/mm.h  Mon Apr 30 23:14:10 2001
+++ build-2.4/include/linux/mm.hFri May  4 23:14:35 2001
@@ -502,12 +502,14 @@
 {
unsigned long grow;
 
+   spin_lock(>vm_mm->page_table_lock);
address &= PAGE_MASK;
grow = (vma->vm_start - address) >> PAGE_SHIFT;
if (vma->vm_end - address > current->rlim[RLIMIT_STACK].rlim_cur ||
-   ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) > 
current->rlim[RLIMIT_AS].rlim_cur)
+   ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) > 
+current->rlim[RLIMIT_AS].rlim_cur) {
+   spin_unlock(>vm_mm->page_table_lock);
return -ENOMEM;
-   spin_lock(>vm_mm->page_table_lock);
+   }
vma->vm_start = address;
vma->vm_pgoff -= grow;
vma->vm_mm->total_vm += grow;


--- 2.4/fs/fcntl.c  Thu Nov 16 07:50:25 2000
+++ build-2.4/fs/fcntl.cFri May  4 23:12:24 2001
@@ -254,11 +254,15 @@
unlock_kernel();
break;
case F_GETLK:
+   lock_kernel();
err = fcntl_getlk(fd, (struct flock *) arg);
+   unlock_kernel();
break;
case F_SETLK:
case F_SETLKW:
+   lock_kernel();
err = fcntl_setlk(fd, cmd, (struct flock *) arg);
+   unlock_kernel();
break;
case F_GETOWN:
/*
@@ -338,22 +342,26 @@
if (!filp)
goto out;
 
-   lock_kernel();
switch (cmd) {
case F_GETLK64:
+   lock_kernel();
err = fcntl_getlk64(fd, (struct flock64 *) arg);
+   unlock_kernel();
break;
case F_SETLK64:
+   lock_kernel();
err = fcntl_setlk64(fd, cmd, (struct flock64 *) arg);
+   unlock_kernel();
break;
case F_SETLKW64:
+   lock_kernel();
err = fcntl_setlk64(fd, cmd, (struct flock64 *) arg);
+   unlock_kernel();
break;
default:
err = do_fcntl(fd, cmd, arg, filp);
break;
}
-   unlock_kernel();
fput(filp);
 out:
return err;

TCP Timer granularity

[shreenivasa H V]

Hi,

Can anyone tell me what is the granularity of the TCP timer in kernel 2.4? Can
I have microsecond timers? What's the value I need to use for the field
"tcp_opt.timer.expires" if I need to have something like 20 ms timer?

shreeni.


Get free email and a permanent address at http://www.netaddress.com/?N=1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] sis_main.c

[David Weinehall]

On Fri, May 04, 2001 at 07:58:59AM -0700, Christopher Kanaan wrote:
> Hello, 
> I am a working with Dawson Englers meta compilation group at Stanford. 
> Here is a patch for sis_main.c  Basically the patch checks to see 
> if kmalloc returns null.  This patch applies to kernel version 2.4.4

Great, but why not follow Documentation/CodingStyle, and the example set
by the rest of the file?!

Instead of:

> --- /usr/src/linux/drivers/video/sis/sis_main.c Fri Feb  9 11:30:23 2001
> +++ ./sis_main.cFri May  4 07:34:47 2001
> @@ -1030,6 +1030,11 @@
> if (heap.pohFreeList == NULL) {
> poha = kmalloc(OH_ALLOC_SIZE, GFP_KERNEL);
>  
> +   if(!poha)
> + {
> +   return(NULL);
> + }
> +
> poha->pohaNext = heap.pohaChain;
> heap.pohaChain = poha;

Something like this:

if (heap.pohFreeList == NULL) {
poha = kmalloc(OH_ALLOC_SIZE, GFP_KERNEL);
 
+   if (!poha) {
+   return(NULL);
+   }
+
poha->pohaNext = heap.pohaChain;
heap.pohaChain = poha;



/David Weinehall
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.4-ac4 - oops on unload "cdrom" module

[Pavel Roskin]

Hi, Andrzej!

> The following patch fixes unloading of cdrom module when no cdrom driver
> loaded (2.4.5-pre, 2.4.4-ac):

It works for me. Thank you! You have even managed to find out that I had
my CD-ROM disconnected :-)

By the way, shouldn't we register sysctl, /proc/sys/dev/cdrom/ and
/dev/cdrom/ always when the cdrom driver is loaded/initialized, not when a
cdrom unit is found?

I don't know what's the official "policy" is, but wouldn't it be logical
to have some control over the drivers that handle no devices in the
moment?

Actually, the scsi module behaves differently. Right now I have empty
/dev/scsi and /proc/scsi/scsi contains "Attached devices: none"

Anyway, the patch is small, straightforward and consistent with the
current behavior of the driver. And it works.

-- 
Regards,
Pavel Roskin

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

[Patch] sis_main.c

[Christopher Kanaan]

Hello, 
I am a working with Dawson Englers meta compilation group at Stanford. 
Here is a patch for sis_main.c  Basically the patch checks to see 
if kmalloc returns null.  This patch applies to kernel version 2.4.4

Thanks,
Christopher Kanaan


--- /usr/src/linux/drivers/video/sis/sis_main.c Fri Feb  9 11:30:23 2001
+++ ./sis_main.cFri May  4 07:34:47 2001
@@ -1030,6 +1030,11 @@
if (heap.pohFreeList == NULL) {
poha = kmalloc(OH_ALLOC_SIZE, GFP_KERNEL);
 
+   if(!poha)
+ {
+   return(NULL);
+ }
+
poha->pohaNext = heap.pohaChain;
heap.pohaChain = poha;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Linus Torvalds]

On Fri, 4 May 2001, Alan Cox wrote:
>
> iso9660 alas doesn't allow you to do that. You can speed it up by reading
> the entire file into memory rather than paging it in (or reading it in and
> then executing it). iso9660 layout is pretty constrained and designed for
> linear file reads

Note that this you can do for any filesystem, including ext2. If you
instead of trying to remember what _blocks_ the bootup process reads, you
keep the trace at a higher level, and then sort the _high_level_ trace and
re-do that with some program, then you can obviously populate the virtual
caches properly with any filesystem.

The advantage of that approach is that it will continue to work forever,
because there will  never be any cache aliasing issues. You're always
"pre-caching" using the same operation that you'll actually use when you
do the real reads..

Now, that still leaves the question on how to sort the virtual cache
accesses, and you might want to know what the low-level layout of the
filesystem is to actually create the "sort". You might not want to sort
alphabetically on the file-name, but use a "where on the disk is this
file", and use _that_ as the sort oder function.

That's easy to do, actually. Just use the "bmap()" ioctl.

Now, you won't be able to use "dd" to populate the caches: you'd have to
have your own program that walks your sorted action list and populates the
caches that way (and you might want to take kernel read-ahead etc
heuristics into account).

SMOP.

Linus

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

Re: [linux-usb-devel] pegasus + MediaGX: Oops in khubd, the continuing story?

[Alan Cox]

> The Oops'es are mostly in the khubd process, but they sometimes appear in other
> programs (insmod, ifconfig). They always lead to an immedate panic, and nothing

I suspect the ohci driver currently. I've been reviewing it a little and it
is full of code written by someone who does not know about pci write posting.

Specifically

writel(value, pciaddr)

is a queued operation. So 

writel(value, foo)
delay
real(foo)

might not do the writel into the delay is over or during it. PCI makes 
guarantees that

-   writes will go out in order and will be merged only if prefetchable set
-   multiple writes to the same addr will remain multiple writes
-   reads will not complete until the writes do

This applies in both directions - bus mastering nasties abound notably


writel(STOP, reg->dmactrl)
kfree(buffer)

is dangerous 

You have to do

writel(STOP, reg->dmactrl);
[posted]
readl(reg->dmactrl)
[read forces write, read reply will follow any DMA
 pending the other way]

I've not attempted to fix it yet


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

Re: DPT I2O RAID and Linux I2O

[Alan Cox]

> When I look at the source from the i2o driver, i find that my module will
> have to primary create an handler to respond to the messages, but does the
> configuration of the i2o should be done by my module or it is gonna be done
> by the functions I cant use right now ? (i2o_pci_enable...)

You are looking much too high a level. The only stuff the hardware layer itself
does is the message fifo stack.

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

Re: Sending packets from within the kernel

[bert hubert]

On Fri, May 04, 2001 at 02:09:16PM -0700, [EMAIL PROTECTED] wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello,
> 
> I am working on an kernel module which forwards TCP segments from one
> interface to another (basic routing, no proxy or listener socket), but
> which needs to be able to generate some segments completely independently
> of the client<-->server data stream.  For example, when receiving a SYN
> segment from the client, I want the module to be able to respond itself
> with a SYN+ACK on behalf of the server (and drop the SYN).

The iptables MIRROR target does some stuff you might be able to use.

-- 
http://www.PowerDNS.com  Versatile DNS Services  
Trilab   The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: REVISED: Experimentation with Athlon and fast_page_copy

[Alan Cox]

> prefetch 320(%0) can fetch memory behind the end of the source page.
> Perhaps it accesses memory in the ISA hole, or beyond the end of memory?
> Could you post the e820 map from dmesg?
> 
> It's possible to build manually a memory map.
> Could you build one with wide margins from "dangerous" areas? (untested:
> mem=exactmap mem=620k@0 mem=M@1M)
> 
> Then boot with prefetch enabled.

That might not be the actual bug but for rev 1 Athlon it is a real bug. The
first step athlons have an unfortunate problem in that will prefetch
memory marked uncachable and corrupt their caches with it.

Arjan - care to unroll the tail 320 bytes of copying from the main loop ?

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

Re: 3ware 6410 RAID 10 performance?

[Larry McVoy]

On Fri, May 04, 2001 at 02:03:35PM -0700, Adam Radford wrote:
> Larry,
> 
> If there's anything to fix in the driver for this problem I'd be interested,
> however I have not seen this problem before.
> 
> What benchmark (and options) are you running? bonnie++ ?
> 
> BTW... I am the author of the Linux driver.

First let me say I really like this card.  It's definitely the right
idea and when it works it screams.  I used to work on really large I/O
systems at SGI so I have a fair amount of experience in this area (the
last system I worked on images the entire earth down to about 32 point
fonts, pretty wacky, our tax dollars at work).

Anyway, the benchmark I use is a program called lmdd, it's part of
lmbench but I've pulled all the files together into one and included
it below.  It's really a handy tool, lots of different file system and
disk drive people use it.  For years, I've known I need to wrap a shell
script around it so that we could toss stuff like bonnie and iozone.

The typical ways I run it 

# allocate and touch a buffer to flush memory
lmdd opat=1 bs=512m count=1

# write a file, watching for variation in write times
lmdd of=XXX bs=100m wt=1 move=2g

# read a file, watching for variation in read times
lmdd if=XXX bs=100m rt=1 move=2g

lmdd is a lot like dd(1) but has the following key differences

a) the default if is an interal form of if=/dev/zero, it
   doesn't bother with the read from /dev/zero.
b) the default of is an interal form of of=/dev/null, it
   doesn't bother with the write to /dev/null.
c) default blocksize is 8KB

On top of that, it has a number of options not found in dd

fork=1  fork to do write I/O
fsync=1 fsync output before exit
ipat=1  check input for a pattern (see opat)
mismatch=1  use with ipat, stop at first mismatch
move=  move  bytes; takes k, m, and g suffices
k/m/g are powers of ten, not 2, the disk people
want powers of ten.  Yeah, it sucks.
opat=1  put a pattern in the output stream
rand=   do randoms over this size
print=   different output formats, you want print=1 with rand
rt=1time and report results for each read
wt=1time and report results for each write
srand=seed  seed the random number generator, used with rand.

There are others, read the source for them, those are the useful ones.

Another tidbit of data on the 3ware card issues - it is definitely associated
with that card or the drives on that card; if I do the same tests on a file
system which is not going through the 3ware card, I get repeatable 27MB/sec
performance.  Yes, I did try it after the 3ware card was wedged, the 
non 3ware performance is still good.

Adam, if you want to ssh in and play with the machine directly, call me
at 415-401-8808 x101 and I'll set you up immediately.

Thanks,

--lm

/*
 * $Id$
 */
#ifndef _BENCH_H
#define _BENCH_H

#ifdef WIN32
#include 
typedef unsigned char bool_t;
#endif

#include
#include
#include
#ifndef WIN32
#include
#endif
#include
#include
#include
#include
#ifndef WIN32
#include
#endif
#include
#ifndef WIN32
#include
#endif
#include
#ifndef WIN32
#include
#include
#include
#include
#include
#include
#define PORTMAP
#include
#endif

typedef unsigned int u32;

#ifdef HAVE_u64_t
typedef u64_t u64;
#else
typedef unsigned long long u64;
#endif

#define NO_PORTMAPPER   /* needs to be up here, lib_*.h look at it */
#include"stats.h"
#include"timing.h"


#ifdef  DEBUG
#   define  debug(x) fprintf x
#else
#   define  debug(x)
#endif
#ifdef  NO_PORTMAPPER
#define TCP_SELECT  -31233
#define TCP_XACT-31234
#define TCP_CONTROL -31235
#define TCP_DATA-31236
#define TCP_CONNECT -31237
#define UDP_XACT-31238
#define UDP_DATA-31239
#else
#define TCP_SELECT  (u_long)404038  /* XXX - unregistered */
#define TCP_XACT(u_long)404039  /* XXX - unregistered */
#define TCP_CONTROL (u_long)404040  /* XXX - unregistered */
#define TCP_DATA(u_long)404041  /* XXX - unregistered */
#define TCP_CONNECT (u_long)404042  /* XXX - unregistered */
#define UDP_XACT(u_long)404032  /* XXX - unregistered */
#define UDP_DATA(u_long)404033  /* XXX - unregistered */
#define VERS(u_long)1
#endif

#define UNIX_CONTROL"/tmp/lmbench.ctl"
#define UNIX_DATA   "/tmp/lmbench.data"
#define UNIX_LAT"/tmp/lmbench.lat"

/*
 * socket send/recv buffer optimizations
 */
#define SOCKOPT_READ0x0001
#define SOCKOPT_WRITE   0x0002
#define SOCKOPT_RDWR0x0003
#define SOCKOPT_PID 0x0004
#define SOCKOPT_REUSE 

[OOPS] pegasus + MediaGX: Oops in khubd, the continuing story?

[Frank de Lange]

Well,

I got fed up with all those Oops'es, so I started scribbling one on a piece of
paper. This is what ksymoops makes of it:

ksymoops 2.4.1 on i586 2.4.4.  Options used
 -V (default)
 -k /var/log/ksymoops/20010504223943.ksyms (specified)
 -l /var/log/ksymoops/20010504223943.modules (specified)
 -o /lib/modules/2.4.3 (specified)
 -m /boot/System.map-2.4.3 (specified)

Warning (compare_maps): snd symbol pm_register not found in 
/usr/lib/alsa-modules/2.4.3/0.5/snd.o.  Ignoring /usr/lib/alsa-modules/2.4.3/0.5/snd.o 
entry
Warning (compare_maps): snd symbol pm_send not found in 
/usr/lib/alsa-modules/2.4.3/0.5/snd.o.  Ignoring /usr/lib/alsa-modules/2.4.3/0.5/snd.o 
entry
Warning (compare_maps): snd symbol pm_unregister not found in 
/usr/lib/alsa-modules/2.4.3/0.5/snd.o.  Ignoring /usr/lib/alsa-modules/2.4.3/0.5/snd.o 
entry
eip: c010f6f3
Oops: 
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010007
eax: c2667000   ebx:  ecx: c2686000   edx: 
esi: 0046   edi: fff8 ebp: c26c7ce8   esp: c26c7ccc
ds: 0018   es: 0018   ss: 0018
Process khubd (pid: 428, stackpage=c26c7000)
Stack: c2686000 c2686074 c283ee40 c26861d0 0001 0286 0001 c283ee40
   c4c840e5 c2686074 c4c7d222 c2686074 2f10 c2686074 0002 c4c7eccd
   c2686074 c4c88010 c4c88010 c2a6c000 0006 c2666000 
Call Trace: c4c840e5 c4c7d222 c4c7cccd c4c88010 c4c88010 c4c7fe9b c4c88014
c4c80857 c4c8000c c4c88000 c01077df c010813e c0106e60 c0115054
c0108171 c0106c60 c011196c c4c84213 c4c859c0 c4c84601 0006
c4c851a2 5f5f c4c85564 c4c86334 c4c8639c c4c86380 c4c8639c
c4c70ad2 c4c86334 c4c7b2e0 c4c70d5b c4c72988 c4c73dba c4c7b334
c4c73fa2 c4c7b36c c4c7b36c c4c74135 c010542c
Code: 8b 4f 04 8b 1b 8b 01 85 45 fc 74 51 31 c0 9c 5e fa c7 01 00

>>EIP; c010f6f3 <__wake_up+33/a8>   <=
Trace; c4c840e5 <[pegasus]__module_parm_desc_loopback+25/28>
Trace; c4c7d222 <[usb-ohci]sohci_return_urb+10e/118>
Trace; c4c7cccd <[usbcore]__kstrtab_usb_devfs_handle+1291/15c4>
Trace; c4c88010 <.data.end+1c51/>
Trace; c4c88010 <.data.end+1c51/>
Trace; c4c7fe9b <[usb-ohci]hc_release_ohci+4b/b0>
Trace; c4c88014 <.data.end+1c55/>
Code;  c010f6f3 <__wake_up+33/a8>
 <_EIP>:
Code;  c010f6f3 <__wake_up+33/a8>   <=
   0:   8b 4f 04  mov0x4(%edi),%ecx   <=
Code;  c010f6f6 <__wake_up+36/a8>
   3:   8b 1b mov(%ebx),%ebx
Code;  c010f6f8 <__wake_up+38/a8>
   5:   8b 01 mov(%ecx),%eax
Code;  c010f6fa <__wake_up+3a/a8>
   7:   85 45 fc  test   %eax,0xfffc(%ebp)
Code;  c010f6fd <__wake_up+3d/a8>
   a:   74 51 je 5d <_EIP+0x5d> c010f750 <__wake_up+90/a8>
Code;  c010f6ff <__wake_up+3f/a8>
   c:   31 c0 xor%eax,%eax
Code;  c010f701 <__wake_up+41/a8>
   e:   9cpushf  
Code;  c010f702 <__wake_up+42/a8>
   f:   5epop%esi
Code;  c010f703 <__wake_up+43/a8>
  10:   facli
Code;  c010f704 <__wake_up+44/a8>
  11:   c7 01 00 00 00 00 movl   $0x0,(%ecx)


3 warnings issued.  Results may not be reliable.

I may have made some transcription errors, but the main stuff is there.

This Oops (and others just like it) appear when the pegasus module is reloaded
into the system. Some info on the system and the circumstances:

MediaGXLV (200 MHz) + 5530 'kahlua' companion chip
 (so this is ohci usb)
60 MB RAM (+4MB for video)

SMC 2202 (pegasus chip) 10/100tx USB NIC on a 10baseT LAN

Oops also appears on 2.4.4

Cheers//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] 2.4.4 alpha semaphores optimization

[Richard Henderson]

On Thu, May 03, 2001 at 07:47:47PM +0400, Ivan Kokshaysky wrote:
> Initially I tried to use __builtin_expect in the rwsem.h, but found
> that it doesn't help at all in the small inline functions - it works
> as expected only in a reasonably large block of code.

Eh?  Would you give me an example that isn't working properly?


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

Re: [PATCH] strtok -> strsep (The Easy Cases)

[Ren=E9=20Scharfe]

Rusty Russell <[EMAIL PROTECTED]> schrieb am 04.05.01:
> In message <01050413055100.00907@golmepha> you write:
> > Am Freitag,  4. Mai 2001 02:57 schrieb Rusty Russell:
> > > There are two cases where the substitution is problematic:
> > 
> > Yes, but...
> > 
> > The cases which my patch modifies are of a different kind:
> 
> The very first hunk of your patch is wrong.  I didn't check the
> others.  Note that the declaration of switches is:

Oops. *blush*

I think all other chunks are OK, but I'll check that thoroughly when I'll be home 
again next monday.

Thank you for taking the time to look at my patch.

René

(who bites the table out of shame)
__
Ferienklick.de - 225 Reisekataloge auf einen Blick!
Direkt zu Ihrem Traumurlaub: http://ferienklick.de/?PP=2-0-100-105-0

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

Re: [patch] 2.4.4 alpha semaphores optimization

[Richard Henderson]

On Thu, May 03, 2001 at 07:47:47PM +0400, Ivan Kokshaysky wrote:
>  - removed some mb's for non-SMP

This isn't correct.  Either you need atomic updates or you don't.
If you don't, then you shouldn't be using ll/sc at all.  If you do
(perhaps to coordinate with devices) then the barriers are required.

>  - removed non-inline up()/down_xx() when semaphore/waitqueue debugging
>isn't enabled.

They should still be exported for module compatibility.


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

Sending packets from within the kernel

[bp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I am working on an kernel module which forwards TCP segments from one
interface to another (basic routing, no proxy or listener socket), but
which needs to be able to generate some segments completely independently
of the client<-->server data stream.  For example, when receiving a SYN
segment from the client, I want the module to be able to respond itself
with a SYN+ACK on behalf of the server (and drop the SYN).

I understand how silly this sounds.  Setting aside the reasoning and
pitfalls of such a desire, technically what is the best way to do it?  I've
reviewed the SYN_COOKIE and RST_COOKIE logic and it seems we must create a
dummy socket which is not attached to any inode.

Is there a cheaper way of accomplishing the same thing, assuming I don't
need to record any state for the endpoints?

Sincerely,
- -bp
- --
# bp at terran dot org
# http://www.terran.org/~bryan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE68xp/qAGIoYtXZJERAtvDAJ0QCgrfzdoqnRr5hWNpuersTtKpSwCgrtNl
gnGcBjCt+W41tHunmyTuFAM=
=GCRW
-END PGP SIGNATURE-

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

Re: 2.4.4-ac4 - oops on unload "cdrom" module

[Andrzej Krzysztofowicz]

> This oops happens when I run "rmmod cdrom" on a 2.4.4-ac4 kernel with
> CONFIG_SYSCTL enabled. It doesn't happen if CONFIG_SYSCTL is disabled.
> 
> sr_mod isn't loaded at this point. Reference to sd_mod looks weird. After
> this oops the "cdrom" module remains in memory in the "deleted" state.

> Unable to handle kernel NULL pointer dereference at virtual address 0008
[...]
> >>EIP; c0118051<=

The following patch fixes unloading of cdrom module when no cdrom driver
loaded (2.4.5-pre, 2.4.4-ac):

--- drivers/cdrom/cdrom.c.old   Fri May  4 22:44:31 2001
+++ drivers/cdrom/cdrom.c   Fri May  4 22:54:36 2001
@@ -2698,7 +2698,8 @@
 
 static void cdrom_sysctl_unregister(void)
 {
-   unregister_sysctl_table(cdrom_sysctl_header);
+   if (cdrom_sysctl_header)
+   unregister_sysctl_table(cdrom_sysctl_header);
 }
 
 #endif /* CONFIG_SYSCTL */


Andrzej


-- 
===
  Andrzej M. Krzysztofowicz   [EMAIL PROTECTED]
  tel.  (0-58) 347 14 61
Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Alan Cox]

> Now, if you want to speed up accesses, there are things you can do. You
> can lay out the filesystem in the access order - trace the IO accesses at
> bootup ("which file, which offset, which metadata block?") and lay out the
> blocks of the files in exactly the right order. Then you will get linear
> reads _without_ doing any "dd" at all.

iso9660 alas doesn't allow you to do that. You can speed it up by reading
the entire file into memory rather than paging it in (or reading it in and
then executing it). iso9660 layout is pretty constrained and designed for
linear file reads

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

Re: REVISED: Experimentation with Athlon and fast_page_copy

[Alan Cox]

> the memory copy in the fast_page_copy routine.  The machine then
> proceeded
> not to stop at my panic, but I got my "normal" oopses.  I then had an

Ok

> idea and removed all the prefetch instructions from the beginning of the
> routine and tried the resultin kernel.  I now have no crashes.
> What could this mean?

I think it has to mean a hardware problem.

> Here is a nother patch just so you can keep me honest if I
> made another mistake:

There is a mistake but you wont trigger it. It is no longer 26 bytes 8)
That patch is only used when the prefetchw faults with an illegal instruction
and is done so you can boot an athlon kernel on a lesser cpu

The prefetch instructions hint to the CPU what memory we will access very soon.
The primary effect of that is that we hit full theoretical memory bandwidth
when copying pages. It doesnt really change execution behaviour in any other
way which then does rather point to cpu or other hardware problem. The very
early athlons had prefetch bugs but we would not trigger those and no reporters
have such an early CPU.

What still stands out is that exactly _zero_ people have reported the same
problem with non VIA chipset Athlons.

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

Re: [OT] Interrupting select.

[Olaf Dietsche]

Hi,

"Peter T. Breuer" <[EMAIL PROTECTED]> writes:

> "A month of sundays ago Alan Cox wrote:"
> > > What IS the magic combination that makes select interruptible
> > > by honest-to-goodness non-blocked signals!
> > man
> > 
> > [seriously man sigaction]
> 
> Equally seriously .. all signals are unblocked in my code and always
> have been. The processes receive signals vury happily. Except when
> they are in a select-with-timeout loop, when they keep going round the
> loop poking their head out of the select every 5s, and taking no notice
> of the murderous hail of die die die die die stuff being slammed at
> them.
[snip]
> Looking at the kernel code in select.c. I see it's implemented by poll
> (I knew that). sys_select calls do_select and I can't for the life of
> me see where anyone sets a signal mask. OTOH if all signals are
> masked by default when syscalls are made (I don't know, but it seems
> possible) then I can't see where interrupts are allowed again.
> 
> The man page for select says nothing about it being interruptible, or
> not. 
> 
> This has been in the back of my mind for months. I'm glad somebody
> asked about it!

I'm not really sure, what you're asking for. Select() is interruptible.

But: if you have multiple threads, the signal may be delivered to any
thread. So, what you may see, is, that the signal is delivered to a
thread, but the signaled thread is not the thread waiting in the
select() call.

Therefore it _seems_, as if select() is not interruptible, but it
surely is.

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

RFC: new zero copy pipe

[Manfred Spraul]

I've rewritten the single copy pipe code again.
Main changes:

* doesn't use map_user_kiobuf anymore. That function locked the pages
into memory. DoS attacks were possible. Now pages stay pageable.
* simpler code, fewer loops.
* support added for set_fs(KERNEL_DS)+pipe_write
* all transfers that block now use single copy. This should reduce the
number of context switches.

The patch is not yet fully tested, but boots, compiles kernels and
survives man .

Should I merge pio_copy_to_user() with access_process_vm()?
The main part of pio_copy_to_user() is access_process_vm(), but with
copy_to_user() instead of memmove().

--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 4
//  EXTRAVERSION =
--- 2.4/fs/pipe.c   Thu Feb 22 22:29:46 2001
+++ build-2.4/fs/pipe.c Fri May  4 21:35:37 2001
@@ -2,6 +2,9 @@
  *  linux/fs/pipe.c
  *
  *  Copyright (C) 1991, 1992, 1999  Linus Torvalds
+ *
+ *  Major pipe_read() and pipe_write() cleanup:  Single copy,
+ *  fewer schedules.   Copyright (C) 2001 Manfred Spraul
  */
 
 #include 
@@ -10,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -36,214 +41,380 @@
down(PIPE_SEM(*inode));
 }
 
+#define ASSERT(x)  do { if (!(x)) BUG(); } while(0)
+
+#define ADDR_USER  1
+#define ADDR_KERNEL2
+struct pipe_pio {
+   struct list_head list;
+   int state;  /* >0: still pending. 0: success. < 0:error code */
+   struct task_struct *tsk;
+   unsigned long addr;
+   size_t len;
+};
+
+/*
+ * Do a quick page-table lookup for a single page. 
+ */
+static struct page * follow_page(struct mm_struct *mm, unsigned long address) 
+{
+   pgd_t *pgd;
+   pmd_t *pmd;
+   pte_t *ptep, pte;
+
+   pgd = pgd_offset(mm, address);
+   if (pgd_none(*pgd) || pgd_bad(*pgd))
+   goto out;
+
+   pmd = pmd_offset(pgd, address);
+   if (pmd_none(*pmd) || pmd_bad(*pmd))
+   goto out;
+
+   ptep = pte_offset(pmd, address);
+   if (!ptep)
+   goto out;
+
+   pte = *ptep;
+   if (pte_present(pte))
+   return pte_page(pte);
+out:
+   return 0;
+}
+
+static int
+pio_copy_to_user(struct inode* inode, char* ubuf, int chars)
+{
+   /* pio->tsk is within pipe_write(), we don't have to protect
+* against sudden death of that thread.
+*/
+   struct pipe_pio* pio;
+   struct mm_struct* mm;
+   struct vm_area_struct * vma;
+   int read;
+
+   pio = list_entry(PIPE_PIO(*inode).next, struct pipe_pio, list);
+   ASSERT(pio->state>0);
+   mm = pio->tsk->mm;
+
+   if (chars > pio->len)
+   chars = pio->len;
+   if (pio->state == ADDR_KERNEL) {
+   /* kernel thread writes into a pipe. */
+   if(copy_to_user(ubuf, (void*)pio->addr, chars)) {
+   return -EFAULT;
+   }
+   pio->addr += chars;
+   pio->len -= chars;
+   read = chars;
+   goto done;
+   }
+   down_read(>mmap_sem);
+   read = 0;
+   ASSERT(chars != 0);
+   goto start;
+   do {
+   struct page *page;
+   void *kaddr;
+   int pcount;
+   int r;
+   if (pio->addr >= vma->vm_end) {
+start:
+   vma = find_extend_vma(mm, pio->addr);
+   if (!vma) {
+   up_read(>mmap_sem);
+   pio->state = -EFAULT;
+   goto unlink;
+   }
+   }
+
+repeat:
+   spin_lock(>page_table_lock);
+   page = follow_page(mm, pio->addr);
+   if (!page) {
+   int ret;
+   spin_unlock(>page_table_lock);
+   /* -1: out of memory. 0 - unmapped page */
+   ret = handle_mm_fault(mm, vma, pio->addr, 0);
+   if (ret > 0)
+   goto repeat;
+   up_read(>mmap_sem);
+   if (ret < 0)
+   pio->state = -ENOMEM;
+   else
+   pio->state = -EFAULT;
+   goto unlink;
+   }
+   get_page(page);
+   spin_unlock(>page_table_lock);
+
+   kaddr = kmap(page);
+   flush_cache_page(vma, pio->addr);
+
+   pcount = PAGE_SIZE-pio->addr%PAGE_SIZE;
+   if (pcount > chars)
+   pcount = chars;
+   r = copy_to_user(ubuf, kaddr+pio->addr%PAGE_SIZE, pcount);
+   flush_page_to_ram(page);
+   kunmap(page);
+   put_page(page);
+   if (r) {
+   up_read(>mmap_sem);
+   return -EFAULT;
+   }
+
+   

3c900 card and kernel 2.4.3

[r.verhees]

Hi there,

when i install kernel 2.4.3 or higher on my slackware
system the card (3c900) gets detected but doesn't do
anything, i also get the line "using NWAY 8" or something
like that (had to switch back to 2.4.2 to type e-mail)
wondered if anyone else had this problem and if there's
some way to solve it?

if you need any other info please mail
Regards, Ronnie

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

Re: 3ware 6410 RAID 10 performance?

[Larry McVoy]

And yet more data -

Under 2.2.15 using 3ware's driver rather than the one shipped with the
kernel, one complete read goes at 35MB/sec (nice).  The second one starts
out there and then drops down to 4MB/sec at the 1.2GB offset.

Here's the cool part - if I unmount, rmmod the driver, insmod, mount, and
then run again, I get exactly the same behavior as above.

This starts to sound like some resource in the kernel or the card are
getting used up and removing the card frees them.

Has anyone seen this besides me?

On Fri, May 04, 2001 at 01:12:39PM -0700, Larry McVoy wrote:
> More data:
> 
> the test file is 2GB in size.
> When I do a reboot and time the reading of the entire file,
> the first time the performance is great, 27MB.
> The second time it sucks, 2.7MB.
> I tried clearing memory by allocating and pounding on an array of 512MB 
> (size of main mem), that clears out memory but the performance still 
> sucks.
> Unmounting and remounting the drive does not help.
> 
> Any ideas?
> 
> On Fri, May 04, 2001 at 01:01:03PM -0700, Larry McVoy wrote:
> > I'm looking for people who know about the 3ware 6410 driver.  I've got one
> > of these and sometimes it goes fast and sometimes it doesn't.  The bad 
> > case seems to happen after memory has a lot of cached blocks in it.
> > 
> > I've tried 2.2.15, 2.4.4, and 2.4.3-ac9 and they all behave pretty similarly.
> > 
> > I'm most interested in seeing this fixed in the 2.4 series so if there is
> > someone who wants to go into a test/debug cycle with me, speak up.  I'd
> > really like this thing to work well.
> > 
> > hardware config:
> > 
> > K7 @ 750Mhz
> > ASUS K7V motherboard
> > 512MB
> > 4x 3c905
> > boot disk on the motherboard
> > 4 WD 40GB 7200 drives on one 3ware 6410
> > matrox g200 AGP
> > -- 
> > ---
> > Larry McVoy  lm at bitmover.com   
>http://www.bitmover.com/lm 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> -- 
> ---
> Larry McVoylm at bitmover.com   
>http://www.bitmover.com/lm 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: added a new feature: disable pc speaker

[Oystein Viggen]

Quoth Nico Schottelius: 

> Can somebody give me a hint where to find documentation about
> sysctl and howto use/program that ?
> This is what Simon and David suggested.
> 
> But as long as I am not able to make sysctl's, I would like
> to add this feature under the General setup.
> 
> What do you think ?

A sysctl would be a lot nicer for distributions, as one could ship a
standard nosound setup and letting people enable it in rc.sysctl or
whatever.  This would save you from hearing the clueless users who just
installed linux (RH 7.2 :) for the first time going *beep* *beep* *beep*
for hours.

For people who compile their own kernels, a compile time option should
be quite enough, though.

Oystein
-- 
This message was generated by a flock of happy penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

pegasus + MediaGX: Oops in khubd, the continuing story?

[Frank de Lange]

Hi'all,

I'm experiencing loads of intermittent Oops'es when loading the pegasus driver
(for an SMC 2202) on my MediaGX-equipped (Webplayer) systems. A scan of the
lists turned up more problems with the MediaGX (which contains an OHCI
implementation in the 5530 companion chip) in combination with the pegasus
driver, so I'm not the only one it seems...

The Oops'es are mostly in the khubd process, but they sometimes appear in other
programs (insmod, ifconfig). They always lead to an immedate panic, and nothing
is ever written to any log. When I tried to copy the Oops by hand on a
notebook, the harddisk in that thing chose that specific moment to drop dead (I
was nearly finished typing in the last call trace address...). And there was no
rejoicing, and no call trace... Sorry...

Is this a known problem (MediaGX + pegasus == intermittent Oops on
load/reload), or am I telling something new? If I am, I'll create that call
trace and run it through ksymoops, if it is known I'd rather spare myself the
chore of typing in loads and loads of hex code. I've done enough of that in my
Commodore-64 days...

Cheers//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: added a new feature: disable pc speaker

[Nico Schottelius]

> >   setterm -blength 0 (text)
> >   xset b 0 (X11)
>
> Well, some buggy programs don't care about you turning off beeping in
> X.  I think gnome-terminal or such has its own checkbox for turning
> beeps on or off.

Exactly.

> I still agree that this is fixing userspace bugs in the kernel, and
> probably not desirable, even if I think I'd disable the pc speaker if
> the kernel actually asked me.  If nothing else, I figure it would make
> my kernel 0.5k or so smaller  ;)

Something about that, didn't make any comparision to a original
2.4.4 kernel.


I first thought the same Keith did, a userspace program.
This could call the same asm code used in kd_nosound,
but the problem is, the next time _kd_mksound is called,
sound is enabled again.

Can somebody give me a hint where to find documentation about
sysctl and howto use/program that ?
This is what Simon and David suggested.

But as long as I am not able to make sysctl's, I would like
to add this feature under the General setup.

What do you think ?

Nico

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

Re: 3ware 6410 RAID 10 performance?

[Larry McVoy]

More data:

the test file is 2GB in size.
When I do a reboot and time the reading of the entire file,
the first time the performance is great, 27MB.
The second time it sucks, 2.7MB.
I tried clearing memory by allocating and pounding on an array of 512MB 
(size of main mem), that clears out memory but the performance still 
sucks.
Unmounting and remounting the drive does not help.

Any ideas?

On Fri, May 04, 2001 at 01:01:03PM -0700, Larry McVoy wrote:
> I'm looking for people who know about the 3ware 6410 driver.  I've got one
> of these and sometimes it goes fast and sometimes it doesn't.  The bad 
> case seems to happen after memory has a lot of cached blocks in it.
> 
> I've tried 2.2.15, 2.4.4, and 2.4.3-ac9 and they all behave pretty similarly.
> 
> I'm most interested in seeing this fixed in the 2.4 series so if there is
> someone who wants to go into a test/debug cycle with me, speak up.  I'd
> really like this thing to work well.
> 
> hardware config:
> 
> K7 @ 750Mhz
> ASUS K7V motherboard
> 512MB
> 4x 3c905
> boot disk on the motherboard
> 4 WD 40GB 7200 drives on one 3ware 6410
> matrox g200 AGP
> -- 
> ---
> Larry McVoylm at bitmover.com   
>http://www.bitmover.com/lm 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Maximum files per Directory

[Chris Mason]

On Friday, May 04, 2001 01:15:22 PM -0600 Andreas Dilger
<[EMAIL PROTECTED]> wrote:

> Chris writes:
>> On Tuesday, May 01, 2001 04:57:02 PM -0600 Andreas Dilger
>> <[EMAIL PROTECTED]> wrote:
>> > I see that reiserfs plays some tricks with the directory i_nlink count.
>> > If you exceed 64536 links in a directory, it reverts to "1" and no
>> > longer tracks the link count.
>> 
>> Correct.  The link count isn't used at all when deciding if the directory
>> is empty (we use the size instead), so we can just lie to VFS if someone
>> tries to make tons of subdirs.
> 
> For that matter, ext2 doesn't use the link count on directories to
> determine if they are empty either, so it shouldn't be too hard to do the
> same with the ext2 indexed-directory code.  Is there a reason that
> reiserfs chose to have "large number of directories" represented by "1"
> and not "LINK_MAX+1"?
> 

find and a few others consider a link count of 1 to mean there is no link
count tracking being done.

-chris

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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Richard Gooch]

Alexander Viro writes:
> 
> 
> On Fri, 4 May 2001, Richard Gooch wrote:
> 
> > I don't bother splitting /usr off /. I gave up doing that when disc
> > became cheap. There's no point anymore. And since I have a lightweight
> 
> Yes, there is. Locality. Resistance to fs fuckups. Resistance to
> disk fuckups. Easier to restore from tape. Different tunefs optimum
> (higher inodes/blocks ratio, for one thing). Ability to keep /usr
> read-only.  Enough?

The correct solution to avoiding fs fuckups is to keep /tmp, /var and
/home separate. Basically, anything that gets written to for reasons
other than sysadmin/upgrades.

However, my point is not that it's always a bad idea to split /usr,
simply that the converse is not true. IOW, it is not true to say that
/usr *should* be split off. For a generic workstation, splitting /usr
is not useful. Importantly, it is most certainly entirely valid to
keep /usr on /.

> > distribution (500 MiB and I get X, LaTeX, emacs, compilers, netscrap
> > and a pile of other things), it makes even less sense to split /usr
> > off. Sorry, I don't have those fancy desktops. Don't need 'em. I spend
> > most of my day in emacs and xterm.
> 
> What desktops? None of that crap on my boxen either. EMACS? What EMACS?
> LaTeX is unfortunately needed (I prefer troff and AMSTeX on the TeX side).
> Netrape? No chance in hell. bash  is there, but I prefer to use
> rc.
> 
> I don't see what does it have to keeping root on a separate
> filesystem, though - the reasons have nothing to bloat in /usr/bin.

In any case, my point is that splitting /usr wouldn't help, because
I'd want to preload stuff from there as well. Splitting /usr doesn't
address the problem.

Regards,

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

RE added a new feature: disable pc speaker

[Nico Schottelius]

Keith Owens wrote:

> On Fri, 04 May 2001 13:37:08 +0200,
> Nico Schottelius <[EMAIL PROTECTED]> wrote:
> >I have searched a long time for a method to disable the internal
> >speaker for every application, every daemon and so on.
>
> Userspace problem, userspace fix.

This sounds good :) ... but ->

>
>   setterm -blength 0 (text)
>   xset b 0 (X11)

This was what I tried and used before. Aplications like Netscape
get a beep throught it, although running xset b 0 or xset b off.

3ware 6410 RAID 10 performance?

[Larry McVoy]

I'm looking for people who know about the 3ware 6410 driver.  I've got one
of these and sometimes it goes fast and sometimes it doesn't.  The bad 
case seems to happen after memory has a lot of cached blocks in it.

I've tried 2.2.15, 2.4.4, and 2.4.3-ac9 and they all behave pretty similarly.

I'm most interested in seeing this fixed in the 2.4 series so if there is
someone who wants to go into a test/debug cycle with me, speak up.  I'd
really like this thing to work well.

hardware config:

K7 @ 750Mhz
ASUS K7V motherboard
512MB
4x 3c905
boot disk on the motherboard
4 WD 40GB 7200 drives on one 3ware 6410
matrox g200 AGP
-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Alexander Viro]

On Fri, 4 May 2001, Richard Gooch wrote:

> I don't bother splitting /usr off /. I gave up doing that when disc
> became cheap. There's no point anymore. And since I have a lightweight

Yes, there is. Locality. Resistance to fs fuckups. Resistance to disk
fuckups. Easier to restore from tape. Different tunefs optimum (higher
inodes/blocks ratio, for one thing). Ability to keep /usr read-only.
Enough?

> distribution (500 MiB and I get X, LaTeX, emacs, compilers, netscrap
> and a pile of other things), it makes even less sense to split /usr
> off. Sorry, I don't have those fancy desktops. Don't need 'em. I spend
> most of my day in emacs and xterm.

What desktops? None of that crap on my boxen either. EMACS? What EMACS?
LaTeX is unfortunately needed (I prefer troff and AMSTeX on the TeX side).
Netrape? No chance in hell. bash  is there, but I prefer to use
rc.

I don't see what does it have to keeping root on a separate filesystem,
though - the reasons have nothing to bloat in /usr/bin.

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

Re: REVISED: Experimentation with Athlon and fast_page_copy

[Brian Gerst]

Seth Goldberg wrote:
> 
> Hi,
> 
>  After removing my head from my a**, I revised the code that checks
> the memory copy in the fast_page_copy routine.  The machine then
> proceeded
> not to stop at my panic, but I got my "normal" oopses.  I then had an
> idea and removed all the prefetch instructions from the beginning of the
> routine and tried the resultin kernel.  I now have no crashes.
> What could this mean?

What are your "normal" oopses?

--

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

[Patch] encapsulate shmem access to shmem_inode_info

[Christoph Rohland]

Hi,

On 24 Apr 2001, Christoph Rohland wrote:
> Hi Al,
> 
> On Tue, 24 Apr 2001, Alexander Viro wrote:
>> So yes, IMO having such patches available _is_ a good thing. And in
>> 2.5 we definitely want them in the tree. If encapsulation part gets
>> there during 2.4 and separate allocation is available for all of
>> them it will be easier to do without PITA in process.
> 
> OK I will do that for tmpfs soon. And I will do the symlink inlining
> with that patch.

Here comes the patch to encapsulate all accesses to struct
shmem_inode_info into a macro. It is now trivial to allocate the
private part independently from the inode.

Greetings
Christoph

P.S: The symlink inlining will come in a separate patch

diff -uNr 2.4.4-mmap_write/include/linux/shmem_fs.h 
2.4.4-mmap_write-SHMEM_I/include/linux/shmem_fs.h
--- 2.4.4-mmap_write/include/linux/shmem_fs.h   Tue May  1 20:02:00 2001
+++ 2.4.4-mmap_write-SHMEM_I/include/linux/shmem_fs.h   Tue May  1 20:06:10 2001
@@ -18,14 +18,15 @@
 } swp_entry_t;
 
 struct shmem_inode_info {
-   spinlock_t  lock;
-   struct semaphore sem;
-   unsigned long   max_index;
-   swp_entry_t i_direct[SHMEM_NR_DIRECT]; /* for the first blocks */
-   swp_entry_t   **i_indirect; /* doubly indirect blocks */
-   unsigned long   swapped;
-   int locked; /* into memory */
+   spinlock_t  lock;
+   struct semaphoresem;
+   unsigned long   max_index;
+   swp_entry_t i_direct[SHMEM_NR_DIRECT]; /* for the first blocks */
+   swp_entry_t   **i_indirect; /* doubly indirect blocks */
+   unsigned long   swapped;
+   int locked; /* into memory */
struct list_headlist;
+   struct inode   *inode;
 };
 
 struct shmem_sb_info {
@@ -35,5 +36,7 @@
unsigned long free_inodes;  /* How many are left for allocation */
spinlock_tstat_lock;
 };
+
+#define SHMEM_I(inode)  (>u.shmem_i)
 
 #endif
diff -uNr 2.4.4-mmap_write/ipc/shm.c 2.4.4-mmap_write-SHMEM_I/ipc/shm.c
--- 2.4.4-mmap_write/ipc/shm.c  Wed Apr 11 12:36:47 2001
+++ 2.4.4-mmap_write-SHMEM_I/ipc/shm.c  Tue May  1 20:06:10 2001
@@ -348,6 +348,7 @@
 
 static void shm_get_stat (unsigned long *rss, unsigned long *swp) 
 {
+   struct shmem_inode_info *info;
int i;
 
*rss = 0;
@@ -361,10 +362,11 @@
if(shp == NULL)
continue;
inode = shp->shm_file->f_dentry->d_inode;
-   spin_lock (>u.shmem_i.lock);
+   info = SHMEM_I(inode);
+   spin_lock (>lock);
*rss += inode->i_mapping->nrpages;
-   *swp += inode->u.shmem_i.swapped;
-   spin_unlock (>u.shmem_i.lock);
+   *swp += info->swapped;
+   spin_unlock (>lock);
}
 }
 
diff -uNr 2.4.4-mmap_write/mm/shmem.c 2.4.4-mmap_write-SHMEM_I/mm/shmem.c
--- 2.4.4-mmap_write/mm/shmem.c Tue May  1 20:02:00 2001
+++ 2.4.4-mmap_write-SHMEM_I/mm/shmem.c Wed May  2 16:46:00 2001
@@ -73,7 +73,7 @@
unsigned long freed;
 
freed = (inode->i_blocks/BLOCKS_PER_PAGE) -
-   (inode->i_mapping->nrpages + inode->u.shmem_i.swapped);
+   (inode->i_mapping->nrpages + SHMEM_I(inode)->swapped);
if (freed){
struct shmem_sb_info * info = >i_sb->u.shmem_sb;
inode->i_blocks -= freed*BLOCKS_PER_PAGE;
@@ -159,7 +159,7 @@
unsigned long index, start;
unsigned long freed = 0;
swp_entry_t **base, **ptr, **last;
-   struct shmem_inode_info * info = >u.shmem_i;
+   struct shmem_inode_info * info = SHMEM_I(inode);
 
down(>sem);
inode->i_ctime = inode->i_mtime = CURRENT_TIME;
@@ -206,7 +206,7 @@
struct shmem_sb_info *info = >i_sb->u.shmem_sb;
 
spin_lock (_ilock);
-   list_del (>u.shmem_i.list);
+   list_del (_I(inode)->list);
spin_unlock (_ilock);
inode->i_size = 0;
shmem_truncate (inode);
@@ -239,7 +239,7 @@
goto out;

inode = page->mapping->host;
-   info = >u.shmem_i;
+   info = SHMEM_I(inode);
swap = __get_swap_page(2);
error = -ENOMEM;
if (!swap.val)
@@ -407,7 +407,7 @@
page_cache_release(*ptr);
}
 
-   info = >u.shmem_i;
+   info = SHMEM_I(inode);
down (>sem);
/* retest we may have slept */  
 
@@ -415,7 +415,7 @@
if (inode->i_size < (loff_t) idx * PAGE_CACHE_SIZE)
goto failed;
 
-   *ptr = shmem_getpage_locked(>u.shmem_i, inode, idx);
+   *ptr = shmem_getpage_locked(info, inode, idx);
if (IS_ERR (*ptr))
goto failed;
 
@@ -462,7 +462,7 @@
 void shmem_lock(struct file * file, int lock)
 {
struct inode * inode = file->f_dentry->d_inode;
-   struct shmem_inode_info * info = >u.shmem_i;
+   struct 

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Richard Gooch]

Alexander Viro writes:
> 
> 
> On Fri, 4 May 2001, Richard Gooch wrote:
> 
> > > Two of them: use less bloated shell (and link it statically) and
> > > clean your rc scripts.
> > 
> > No, because I'm not using the latest bloated version of bash, and I'm
> 
> Umm... Last version of bash I could call not bloated was _long_ time
> ago. Something like ash(1) might be a better idea for /bin/sh.

The shell is irrelevant. I can easily preload that too, if I wanted
to, since it's just one thing. But it's not practical to preload all
files used by name, because it's just too hard to find out all that is
needed. Too much people time required, and it is specific to one
distribution (and a particular revision at that).

> > The problem is all the various daemons and system utilities (mount,
> > hwclock, ifconfig and so on) that turn a kernel into a useful system.
> > And then of course there's X...
> 
> How do you partition the thing? I.e. what's the size of your root
> partition?  I'm usually doing something from 10Mb to 30Mb - that may
> be the reason of differences.

I don't bother splitting /usr off /. I gave up doing that when disc
became cheap. There's no point anymore. And since I have a lightweight
distribution (500 MiB and I get X, LaTeX, emacs, compilers, netscrap
and a pile of other things), it makes even less sense to split /usr
off. Sorry, I don't have those fancy desktops. Don't need 'em. I spend
most of my day in emacs and xterm.

And even if I did split /usr off, that would just mean I'd want to
record block accesses for that device as well. This is because part of
my boot process requires stuff in /usr. And after that, firing up xdm.

Regards,

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

Re: REVISED: Experimentation with Athlon and fast_page_copy

[Seth Goldberg]

On Fri, 4 May 2001, Manfred Spraul wrote:

| > ---
| > >   __asm__ __volatile__ (
| > 158c157
| > <   "3: movw $0x1AEB, 1b\n"
| > ---
| > >   "3: movw $0x1AEB, 1b\n" /* jmp on 26 bytes */
| > 166c165
| > < */
| > ---
| > >
| > 170c169
| > <   "1: nop\n" /* prefetch 320(%0)\n" */
| > ---
| > >   "1: prefetch 320(%0)\n" 
| > -
| >   Please let me know if that makes sense :).
| 
| Very interesting.
| You've removed only the prefetch 320(%0), not the other prefetch
| instructions?

  No, I have removed them all -- I just commented the block above it
completely out :). (maybe you didn't see the whole patch?)

  --Seth



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

RE: DPT I2O RAID and Linux I2O

[Patrick Allaire]

> Ok thats nothing to do with I2O itself. Some hardware has the messaging
> layer built into it as the messenger is very simple and stuff
> like the 21554
> are using in I2O controllers.
>
> You might find i2o_pci.c and the i2o_core message passing code interesting
> but probably not that much. The I2O 1.5 specification covers the hardware
> interface briefly and that bit is worth reading. Ignore the rest.

Hi, its me again (c:

First of all, is it supposed to be working with 2.2.19 or should I take a
new 2.4.4-ac kernel for that support ?

Ok, i allready did look at those files (i2o_pci.c i2o_core), but I cant find
were to begin. I was doing i2o_install_controler, and after that i was
trying to do a i2o_pci_enable or i2o_pci_bind,because they are the only
fonction that seem to bind i2o with a pci_dev, but I get unresolved error
with those functions ... if I do a cat /proc/ksyms I dont see them listed
there. After that when I do i2o_delete_control, I receive a segmentation
fault !!! (Those test are done in 2.2.19)

I have built my kernel with i2o support and i2o_pci support !!!

As for the spec, I have the i2o spec 2.0 here. Is it supported ?

When I look at the source from the i2o driver, i find that my module will
have to primary create an handler to respond to the messages, but does the
configuration of the i2o should be done by my module or it is gonna be done
by the functions I cant use right now ? (i2o_pci_enable...)

Thank you very much !!!

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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Alexander Viro]

On Fri, 4 May 2001, Richard Gooch wrote:

> > Two of them: use less bloated shell (and link it statically) and
> > clean your rc scripts.
> 
> No, because I'm not using the latest bloated version of bash, and I'm

Umm... Last version of bash I could call not bloated was _long_ time
ago. Something like ash(1) might be a better idea for /bin/sh.

> The problem is all the various daemons and system utilities (mount,
> hwclock, ifconfig and so on) that turn a kernel into a useful system.
> And then of course there's X...

How do you partition the thing? I.e. what's the size of your root partition?
I'm usually doing something from 10Mb to 30Mb - that may be the reason of
differences.

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

Re: REVISED: Experimentation with Athlon and fast_page_copy

[Manfred Spraul]

> ---
> >   __asm__ __volatile__ (
> 158c157
> <   "3: movw $0x1AEB, 1b\n"
> ---
> >   "3: movw $0x1AEB, 1b\n" /* jmp on 26 bytes */
> 166c165
> < */
> ---
> >
> 170c169
> <   "1: nop\n" /* prefetch 320(%0)\n" */
> ---
> >   "1: prefetch 320(%0)\n" 
> -
>   Please let me know if that makes sense :).

Very interesting.
You've removed only the prefetch 320(%0), not the other prefetch
instructions?

prefetch 320(%0) can fetch memory behind the end of the source page.
Perhaps it accesses memory in the ISA hole, or beyond the end of memory?
Could you post the e820 map from dmesg?

It's possible to build manually a memory map.
Could you build one with wide margins from "dangerous" areas? (untested:
mem=exactmap mem=620k@0 mem=M@1M)

Then boot with prefetch enabled.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Maximum files per Directory

[Andreas Dilger]

Chris writes:
> On Tuesday, May 01, 2001 04:57:02 PM -0600 Andreas Dilger
> <[EMAIL PROTECTED]> wrote:
> > I see that reiserfs plays some tricks with the directory i_nlink count.
> > If you exceed 64536 links in a directory, it reverts to "1" and no longer
> > tracks the link count.
> 
> Correct.  The link count isn't used at all when deciding if the directory
> is empty (we use the size instead), so we can just lie to VFS if someone
> tries to make tons of subdirs.

For that matter, ext2 doesn't use the link count on directories to determine
if they are empty either, so it shouldn't be too hard to do the same with
the ext2 indexed-directory code.  Is there a reason that reiserfs chose to
have "large number of directories" represented by "1" and not "LINK_MAX+1"?

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Linus Torvalds]

On Fri, 4 May 2001, Alexander Viro wrote:
>
> ObProcfs: I don't think that walking the page tables is a good way to
> compute RSS, especially since VM maintains the thing.

Well, the VM didn't always use to maintain the stuff it does now, so I bet
that most of the code is just old code that still works.

Feel free to rip it out.

Linus

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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Jens Axboe]

On Fri, May 04 2001, Richard Gooch wrote:
> The idea I had (motivated by the desire to eliminate random disc
> seeks, which is the limiting factor in how fast my boxes boot) was:
> 
> - init(8) issues an ioctl(2) on the root FS block device which turns
>   on recording of block reads (it records block numbers)
> 
> - at the end of the bootup process, init(8) issues another ioctl(2) to
>   grab the buffered block numbers, and turn off recording
> 
> - init(8) then sorts this list in ascending order and saves the result
>   in a file
> 
> - next boot, init(8) checks the file, and if it exists, opens the root
>   FS block device and reads in each block listed in the file. The
>   effect is to warm the buffer cache extremely quickly. The head will
>   move in one direction, grabbing data as it flys by. I expect this
>   will take around 1 second
> 
> - init(8) now continues the boot process (starting the magic ioctl(2)
>   again so as to get a fresh list of blocks, in case something has
>   changed)
> 
> - booting is now super fast, thanks to no disc activity.

I did 95% of what you need sometime last year, to do I/O scheduler
profiling (blocks requested, merge stats, request sent to disk). It was
a pretty gross hack, requiring a pretty big ring buffer of kernel memory
to be able to log at a sufficiently fast rate (you'd be amazed how much
output a single dbench 48 run produces :-). A user space app would read
data from a simple char device, save for later inspection.

A better approach would be to map the ring buffer from the user app, but
it was just a quick fix.

-- 
Jens Axboe

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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Richard Gooch]

Alexander Viro writes:
> 
> 
> On Fri, 4 May 2001, Richard Gooch wrote:
> 
> > However, doing an ioctl(2) on the block device won't help. So the
> > question is, where to add the hook? One possibility is the FS, and
> > record inum,bnum pairs. But of course we don't have a way of accessing
> > via inum in user-space. So that's no good. Besides, we want to get
> > block numbers on the block device, because that's the only meaningful
> > number to resort.
> > 
> > So, what, then? Some kind of hook on the page cache? Ideas?
> 
> Two of them: use less bloated shell (and link it statically) and
> clean your rc scripts.

No, because I'm not using the latest bloated version of bash, and I'm
not using the slow and bloated RedHat boot scripts. My boot scripts
are lean and mean. Oh. And I already have init(8) warming the cache
with these scripts.

The problem is all the various daemons and system utilities (mount,
hwclock, ifconfig and so on) that turn a kernel into a useful system.
And then of course there's X...

Sorry. A "don't do that then" answer isn't appropriate for this
problem space.

Regards,

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

Patch for ymfpci in 2.4.4

[Pete Zaitcev]

Hello:

Here are updates from ALSA. The interrupt acknowledge has a
potential bug report for it in RH bugzilla. Power-up fix I include
"just because", Alan bounced it to me from sound-hackers;
Also Jeff Garzik asked for it. I wanted to include it with
full PM support, but perhaps not.

-- Pete

--- linux-2.4.4/drivers/sound/ymfpci.c  Thu Apr 26 22:17:27 2001
+++ linux-2.4.4-niph/drivers/sound/ymfpci.c Fri May  4 11:02:56 2001
@@ -989,11 +989,6 @@
 
status = ymfpci_readl(codec, YDSXGR_STATUS);
if (status & 0x8000) {
-   spin_lock(>reg_lock);
-   ymfpci_writel(codec, YDSXGR_STATUS, 0x8000);
-   mode = ymfpci_readl(codec, YDSXGR_MODE) | 2;
-   ymfpci_writel(codec, YDSXGR_MODE, mode);
-   spin_unlock(>reg_lock);
codec->active_bank = ymfpci_readl(codec, YDSXGR_CTRLSELECT) & 1;
spin_lock(>voice_lock);
for (nvoice = 0; nvoice < 64; nvoice++) {
@@ -1007,6 +1002,11 @@
ymf_cap_interrupt(codec, cap);
}
spin_unlock(>voice_lock);
+   spin_lock(>reg_lock);
+   ymfpci_writel(codec, YDSXGR_STATUS, 0x8000);
+   mode = ymfpci_readl(codec, YDSXGR_MODE) | 2;
+   ymfpci_writel(codec, YDSXGR_MODE, mode);
+   spin_unlock(>reg_lock);
}
 
status = ymfpci_readl(codec, YDSXGR_INTFLAG);
@@ -2106,6 +2106,8 @@
pci_write_config_byte(pci, PCIR_DSXGCTRL, cmd | 0x03);
pci_write_config_byte(pci, PCIR_DSXGCTRL, cmd & 0xfc);
}
+   pci_write_config_word(pci, PCIR_DSXPWRCTRL1, 0);
+   pci_write_config_word(pci, PCIR_DSXPWRCTRL2, 0);
 }
 
 static void ymfpci_enable_dsp(ymfpci_t *codec)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Alexander Viro]

On Fri, 4 May 2001, Richard Gooch wrote:

> However, doing an ioctl(2) on the block device won't help. So the
> question is, where to add the hook? One possibility is the FS, and
> record inum,bnum pairs. But of course we don't have a way of accessing
> via inum in user-space. So that's no good. Besides, we want to get
> block numbers on the block device, because that's the only meaningful
> number to resort.
> 
> So, what, then? Some kind of hook on the page cache? Ideas?

Two of them: use less bloated shell (and link it statically) and clean
your rc scripts.

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

Re: X15 alpha release: as fast as TUX but in user space

[Davide Libenzi]

On 04-May-2001 Fabio Riccardi wrote:
> ok, I'm totally ignorant here, what is a pipelined request?



http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html


A pipelined application implementation buffers its output before writing it to
the underlying TCP stack, roughly equivalent to what the Nagle algorithm does
for telnet connections.
These two buffering algorithms tend to interfere, and using them together will
often cause very significant performance degradation. For each connection, the
server maintains a
response buffer that it flushes either when full, or when there is no more
requests coming in on that connection, or before it goes idle. This buffering
enables aggregating responses
(for example, cache validation responses) into fewer packets even on a
high-speed network, and saving CPU time for the server. 






- Davide

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

Re: added a new feature: disable pc speaker

[Oystein Viggen]

Quoth Keith Owens: 

> Userspace problem, userspace fix.
> 
>   setterm -blength 0 (text)
>   xset b 0 (X11)

Well, some buggy programs don't care about you turning off beeping in
X.  I think gnome-terminal or such has its own checkbox for turning
beeps on or off. 

I still agree that this is fixing userspace bugs in the kernel, and
probably not desirable, even if I think I'd disable the pc speaker if
the kernel actually asked me.  If nothing else, I figure it would make
my kernel 0.5k or so smaller  ;)

Oystein
-- 
When in doubt: Recompile.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Alexander Viro]

On Fri, 4 May 2001, Linus Torvalds wrote:

> 
> On Fri, 4 May 2001, Alexander Viro wrote:
> > 
> > Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
   ^^^
> > * add pagecache access for block device
> > * put your "real" root on /dev/loop0 (setup from initrd)
> > * dd
> 
> You're one sick puppy.

[snip]
/me bows

Nice to see that imitation was good enough ;-) Seriously, I half-expected
Albert to show up at that point of thread and tried to anticipate what
he'd produce.

ObProcfs: I don't think that walking the page tables is a good way to
compute RSS, especially since VM maintains the thing. Mind if I rip
it out? In effect, implementation of /prc//statm
* produces extremely bogus values (VMA is from library if it goes
  beyond 0x6000? Might be even true 7 years ago...) and nobody
  had cared about them for 6-7 years
* makes stuff like top(1) _walk_ _whole_ _page_ _tables_ _of_ _all_
  _processes_ each 5 seconds. No wonder it's slow like hell and eats
  tons of CPU time.

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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Richard Gooch]

Linus Torvalds writes:
> Now, if you want to speed up accesses, there are things you can
> do. You can lay out the filesystem in the access order - trace the
> IO accesses at bootup ("which file, which offset, which metadata
> block?") and lay out the blocks of the files in exactly the right
> order. Then you will get linear reads _without_ doing any "dd" at
> all.

A year ago I came up with an alternative approach for cache warming,
but I see that it wouldn't work with our current infrastructure.
However, maybe there is still a way to use the basic technique. If so,
please make suggestions.

The idea I had (motivated by the desire to eliminate random disc
seeks, which is the limiting factor in how fast my boxes boot) was:

- init(8) issues an ioctl(2) on the root FS block device which turns
  on recording of block reads (it records block numbers)

- at the end of the bootup process, init(8) issues another ioctl(2) to
  grab the buffered block numbers, and turn off recording

- init(8) then sorts this list in ascending order and saves the result
  in a file

- next boot, init(8) checks the file, and if it exists, opens the root
  FS block device and reads in each block listed in the file. The
  effect is to warm the buffer cache extremely quickly. The head will
  move in one direction, grabbing data as it flys by. I expect this
  will take around 1 second

- init(8) now continues the boot process (starting the magic ioctl(2)
  again so as to get a fresh list of blocks, in case something has
  changed)

- booting is now super fast, thanks to no disc activity.

The advantage of this scheme over blindly reading the first 50 MB is
that it only reads in what you *need*, and thus will work better on
low memory systems. It's also useful for other applications, not just
speeding up the boot process.

However, doing an ioctl(2) on the block device won't help. So the
question is, where to add the hook? One possibility is the FS, and
record inum,bnum pairs. But of course we don't have a way of accessing
via inum in user-space. So that's no good. Besides, we want to get
block numbers on the block device, because that's the only meaningful
number to resort.

So, what, then? Some kind of hook on the page cache? Ideas?

Regards,

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

Re: modularized SYSENTER support

[Manfred Spraul]

> Q. How come the handler doesn't manage so called "bottom halves" or 
>"soft IRQs"? 
> A. There is no need for this. Soft IRQs can only appear at exit from 
>hardware interrupt handlers. Indeed, we can't count on user app. 
>being around and performing a system call when it comes to 
>interrupt handling, right? 

That's probably a bug.
syscall
* spin_lock_bh()
* hardware interrupt arrives
* BH's are blocked, delayed
* spin_unlock_bh()
* return from syscall.

You must check for softirq's before returning.

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

Re: X15 alpha release: as fast as TUX but in user space

[Fabio Riccardi]

ok, I'm totally ignorant here, what is a pipelined request?

btw: please be kind with my mistakes, X15 _is_ alpha code anyway... :)

 - Fabio

Ingo Molnar wrote:

> yet another anomaly i noticed. X15 does not appear to handle pipelined
> HTTP/1.1 requests properly, it ignores the second request if two requests
> arrive in the same packet.
>
> SPECweb99 does not send pipelined requests, but a number of RL web clients
> do. (Mozilla, apt-get, etc.)
>
> Ingo

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

Re: X15 alpha release

[Fabio Riccardi]

Ingo,

I'm really impressed by your feedback! How do you manage to discover so many
things?

I fixed the bug, and checked that it hadn't affected my specweb results.

Indeed specweb never issues closing 1.1 connections, it would use a 1.0
request with close in that case.

Moreover even if a client says that it will close the connection and the
server instead leaves it open, the client would just close the connection
anyway, unless there is a (very contrived) bug in the client which would let
itself be diverted from its original intention by an overly talkative
server...

X15 would be indeed negatively affected by these useless idle open
connections cluttering the file descriptor table and consuming resources for
nothing.

I'll post the corrected version later on today.

BTW: is there any _concise_ document specifying the HTTP protocol and its
variants?

 - Fabio

Ingo Molnar wrote:

> Fabio,
>
> i noticed another RFC anomaly in X15. It ignores the "Connection: close"
> request header passed by a HTTP/1.1 client. This behavior is against RFC
> 2616, a server must not override the client's choice of non-persistent
> connection. (there might be HTTP/1.1 clients that do not support
> persistent connections and signal this via "Connection: close".)
>
> the rule is this: a request is either keepalive or non-keepalive. HTTP/1.0
> requests default to non-keepalive. HTTP/1.1 requests default to keepalive.
> The default can be overriden via the "Connection: Keep-Alive" or
> "Connection: close" header fields.
>
> if you fix this, does it impact SPECweb99 performance in any way?
>
> Ingo
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Linus Torvalds]

On Fri, 4 May 2001, Alexander Viro wrote:
> 
> Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
>   * add pagecache access for block device
>   * put your "real" root on /dev/loop0 (setup from initrd)
>   * dd

You're one sick puppy.

Now, the above is basically equivalent to using and populating a
dynamically sized ramdisk.

If you really want to go this way, I'd much rather see you using a real
ram-disk (that you populate at startup with something like a compressed
tar-file). THAT is definitly going to speed up booting - thanks to
compression you'll not only get linear reads, but you will get fewer reads
than the amount of data you need would imply.

Couple that with tmpfs, or possibly something like coda (to dynamically
move things between the ramdisk and the "backing store" filesystem), and
you can get a ramdisk approach that actually shrinks (and, in the case of
coda or whatever, truly grows) dynamically.

Think of it as an exercise in multi-level filesystems and filesystem
management. Others have done it before (usually between disk and tape, or
disk and network), and in these days of ever-growing memory it might just
make sense to do it on that level too.

(No, I don't seriously think it makes sense today. But if RAM keeps
growing and becoming ever cheaper, it might some day. At the point where
everybody has multi-gigabyte memories, and don't really need it for
anything but caching, you could think of it as just moving the caching to
a higher level - you don't cache blocks, you cache parts of the
filesystem).

>   Al, feeling sadistic today...

Sadistic you are.

Linus

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

[PATCH][RFC] Re: SMP races in proc with thread_struct

[Alexander Viro]

Linus, could you consider the patch below? As it is, access to
/proc//status of dead process with dead parent is possible and
leads to access to freed memory. Besides, cd /proc/ means
that even after  is gone, readdir() _and_ lookup on /proc/ work.
Patch makes sure that ->p_pptr is NULL once the process is gone (fixes
readdir/lookup stuff) and adds obvious couple of checks in array.c.
Al

diff -urN S5-pre1/fs/proc/array.c S5-pre1-p_pptr/fs/proc/array.c
--- S5-pre1/fs/proc/array.c Sat Apr 28 02:12:56 2001
+++ S5-pre1-p_pptr/fs/proc/array.c  Fri May  4 13:15:47 2001
@@ -157,7 +157,9 @@
"Uid:\t%d\t%d\t%d\t%d\n"
"Gid:\t%d\t%d\t%d\t%d\n",
get_task_state(p),
-   p->pid, p->p_opptr->pid, p->p_pptr->pid != p->p_opptr->pid ? 
p->p_pptr->pid : 0,
+   p->pid, p->p_opptr->pid,
+   p->p_pptr && p->p_pptr->pid != p->p_opptr->pid
+   ? p->p_pptr->pid : 0,
p->uid, p->euid, p->suid, p->fsuid,
p->gid, p->egid, p->sgid, p->fsgid);
read_unlock(_lock);
@@ -339,7 +341,7 @@
nice = task->nice;
 
read_lock(_lock);
-   ppid = task->p_opptr->pid;
+   ppid = task->p_pptr ? task->p_opptr->pid : 0;
read_unlock(_lock);
res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \
 %lu %lu %lu %lu %lu %ld %ld %ld %ld %ld %ld %lu %lu %ld %lu %lu %lu %lu %lu \
diff -urN S5-pre1/kernel/exit.c S5-pre1-p_pptr/kernel/exit.c
--- S5-pre1/kernel/exit.c   Fri Feb 16 22:52:15 2001
+++ S5-pre1-p_pptr/kernel/exit.cFri May  4 13:18:33 2001
@@ -62,6 +62,9 @@
current->counter += p->counter;
if (current->counter >= MAX_COUNTER)
current->counter = MAX_COUNTER;
+   write_lock_irq(_lock);
+   p->p_pptr = NULL;
+   write_unlock_irq(_lock);
free_task_struct(p);
} else {
printk("task releasing itself\n");


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

Re: Possible PCI subsystem bug in 2.4

[Linus Torvalds]

On 4 May 2001, Eric W. Biederman wrote:
> 
> There are a couple of options here.
> 1) read the MTRRs unless the BIOS is braindead it will set up that area as
>write-back.  At any rate we shouldn't ever try to allocate a pci region
>that is write-back cached.

This one I'd really hesitate to use. We do _not_ want to trust the BIOS
any more than necessary (obviously trusting even the e820 was too much),
and especially wrt MTRR's we know that there are too many buggy bioses
already out there.

> 2) read the memory locations from the northbridge.  It's not possible
>on every chipset (lack of documentation) but with the linuxBIOS
>project we code for a couple of them, and we are working on more
>all of the time.

This will be easy.

In fact, we can easily "mix" different heuristics. Ie we'd do the simple
thing I suggested in setup_arch(), and use that as a "base guess", and
then we can have incremental improvements on that guess that might be
chipset-specific or might depend on other information that is not
necessarily generic (things like existing PCI programming etc).

Linus

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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Alexander Viro]

On Fri, 4 May 2001, Linus Torvalds wrote:

> Now, if you want to speed up accesses, there are things you can do. You
> can lay out the filesystem in the access order - trace the IO accesses at
> bootup ("which file, which offset, which metadata block?") and lay out the
> blocks of the files in exactly the right order. Then you will get linear
> reads _without_ doing any "dd" at all.
> 
> Now, laying out the filesystem that way is _hard_. No question about it.
> It's kind of equivalent to doing a filesystem "defreagment" operation,
> except you use a different sorting function (instead of sorting blocks
> linearly within each file, you sort according to access order).

Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
* add pagecache access for block device
* put your "real" root on /dev/loop0 (setup from initrd)
* dd
The last step will populate pagecache for underlying device and later
access to root fs will ultimately hit said pagecache, be it from page
cache of files or buffer cache of /dev/loop0 - loop_make_request() will
take care of that, by copying data from pagecache of /dev/.

Al, feeling sadistic today...

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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Linus Torvalds]

On Fri, 4 May 2001, Andrea Arcangeli wrote:

> On Fri, May 04, 2001 at 01:56:14PM +0200, Jens Axboe wrote:
> > Or you can rewrite block_read/write to use the page cache, in which case
> > you'd have more luck doing the above.
> 
> once block_dev is in pagecache there will obviously be no-way to share
> cache between the block device and the filesystem, because all the
> caches will be in completly different address spaces.

They already pretty much are.

I do want to re-write block_read/write to use the page cache, but not
because it would impact anything in this discussion. I want to do it early
in 2.5.x, because:

 - it will speed up accesses
 - it will re-use existing code better and conceptualize things more
   cleanly (ie it would turn a disk into a _really_ simple filesystem with
   just one big file ;).
 - it will make MM handling much better for things like fsck - the memory
   pressure is designed to work on page cache things.
 - it will be one less thing that uses the buffer cache as a "cache" (I
   want people to think of, and use, the buffer cache as an _IO_ entity,
   not a cache).

It will not make the "cache at bootup" thing change at all (because even
in the page cache, there is no commonality between a virtual mapping of a
_file_ (or metadata) and a virtual mapping of a _disk_). 

It would have hidden the problem with "dd" or "dump" touching buffer cache
blocks that the filesystem was using, so the original metadata corruption
that started this thread would not happen. But that's not a design issue
or a design goal, that would just have been a random result.

Linus

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

Re: smp_send_stop() and disable_local_APIC()

[Matt D. Robinson]

"Eric W. Biederman" wrote:
> 
> "Matt D. Robinson" <[EMAIL PROTECTED]> writes:
> 
> > It looks like around 2.3.30 or so, someone added the call
> > disable_local_APIC() to smp_send_stop().  I'm not sure what the
> > intention was, but I'm getting some strange behavior as a result
> > based on some code I'm writing.
> >
> > Basically, I'm doing the following ...
> >
> > panic()
> > {
> > /* do whatever you want, notifier list, etc. */
> > smp_send_stop();
> > write_system_memory();
> > /* then do whatever */
> > }
> >
> > write_system_memory() does a write of all system memory pages to some
> > block device.  It uses kiobufs as the way to get the pages to disk,
> > doing brw_kiovec() on those pages (using either the IDE or SCSI
> > driver to write the data).
> 
> IDE being less likely to hang than SCSI as it tends to use legacy isa
> interrupt lines.

Actually, we see the problem more with IDE than SCSI, but that's
neither here nor there.

> > The wierd behavior I see is that sometimes, smp_send_stop()
> > being called causes the system to hang up (not every time).
> 
> Doing event driver i/o after disabling the interrupt controller
> hmm, I wonder why...

It's an SMP (and only when your system crashes on a CPU other
than 0) problem.  I did some more checking of this to verify the
specifics of the behavior.  Thanks for the sarcasm, though. :)

> > If we don't call smp_send_stop() on those systems, everything works fine.
> > This looks to be directly caused by the disabling of the APIC, which
> > we may need to dump pages to local disk.  This only applies to some
> > people's systems -- not everyone displays the same behavior.
> >
> > I'm sure it's good to disable the APIC, but there's no clean way to
> > wait on disabling the APIC until after I'm done writing pages out.
> >
> > My questions are:
> >
> > 1) Why was disable_local_APIC() added to stop_this_cpu()
> >and smp_send_stop()?  Completeness?
> >
> > 2) Is there a better way around this to disable all the
> >other CPUs without disabling the APIC?
> >
> 
> I don't know what a good way is, since there is a kernel panic it
> should only be something truly fatal.  Given that reusing anything
> that hasn't been designed to run in that situation is playing with
> fire.

Someone's sent me a suggestion as to how to get around this issue.
It goes back to turning off the disable_local_APIC() behavior for
one (if I'm writing pages out), but secondly to avoid doing any
TLB flushing of CPUs that are stopped.

The problem is, on SMP configurations where one CPU's
task causes a panic() condition to another CPU's task (let's say
they are playing with the same list of structures in the kernel),
I need to stop all CPUs except the one panic()ing, and let him
be responsible for dumping system memory, so I can at least try
to figure out what the other CPU's task did to cause the problem.

A hack way around this is to stop job scheduling, but it doesn't
help if you want to catch the state of the task that caused the
problem on another CPU just after it happens.  Secondly, because there
is no disk driver to dump raw to disk (I've written one, but
not for SCSI -- only for IDE), you require interrupts and must
use the current block driver.  Sure, brw_kiovec() is nice, but it
isn't raw I/O without kernel interrupts.

All I wanted was clarification as to why it was added in the first
place, and whether there was a better way around the scenario.
I think Ingo added the code, but I never heard back from him.
Thanks for the response.

> Eric

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

Re: X15 alpha release: as fast as TUX but in user space (fwd)

[dean gaudet]

um, presumably this new magic page won't eliminate the old syscall entry
points.  so just use those for UML.

-dean

On Fri, 4 May 2001, Pavel Machek wrote:

> Hi!
>
> > > > That means that for fooling closed-source statically-linked binary,
> > >
> > > If they are using glibc then you have the right to the object to link
> > > with the library and the library source under the LGPL. I dont know of any
> > > app using its own C lib
> >
> > Some don't use any libc at all, some just don't use it for the time call
> > that were talking about substituting.
> >
> > Lying about the time is a hack, pure and simple. It will still be possible
> > with magic pages. The fact that it will require more kernel hacking to
> > accomplish it is irrelevant.
>
> No. You are breaking self-virtualization here. That is not irrelevant.
>
> It used to require no kernel support before. Now it will require
> kernel support. That's step back. (Think uml).
>
>   Pavel
> --
> I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
> Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Linus Torvalds]

On Fri, 4 May 2001, Rogier Wolff wrote:
>
> Linus Torvalds wrote:
> > 
> > Ehh. Doing that would be extremely stupid, and would slow down your boot
> > and nothing more.
> 
> Ehhh, Linus, Linearly reading my harddisk goes at 26Mb per second.

You obviously didn't read my explanation of _why_ it is stupid.

> By analyzing my boot process I determine that 50M of my disk is used
> during boot. I can then reshuffle my disk to have that 50M of data at
> the beginning and reading all that into 50M of cache, I can save
> thousands of 10ms seeks.

No. Have you _tried_ this?

What the above would do is to move 50M of the disk into the buffer cache.

Then, a second later, when the boot proceeds, Linux would start filling
the page cache.

BY READING THE CONTENTS FROM DISK AGAIN!

In short, by doing a "dd" from the disk, you would _not_ help anything at
all. You would only make things slower, by reading things twice.

The Linux buffer cache and page cache are two separate entities. They are
not synchronized, and they are indexed through totally different
means. The page cache is virtually indexed by , while
the
buffer cache is indexed by . 

> Is this simply: Don't try this then? 

Try it. You will see. 

You _can_ actually try to optimize certain things with 2.4.x: all
meta-data is still in the buffer cache in 2.4.x, so what you could do is
to lay out the image so that the metadata is at the front of the disk,
and do the "dd" to cache just the metadata. Even then you need to be
careful, and make sure that the "dd" uses the same block size as the
filesystem will use.

And even that will largely stop working very early in 2.5.x when the
directory contents and possibly inode and bitmap metadata moves into the
page cache.

Now, you may ask "why use the page cache at all then"? The answer is that
the page cache is a _lot_ faster to look up, exactly because of the
virtual indexing (and also because the data structure is much better
designed - fixed-size entities with none of the complexities of the buffer
cache. The buffer cache needs to be able to do IO, while the page cache is
_only_ a cache and does that one thing really well - doing IO is a
completely separate issue with the page cache).

Now, if you want to speed up accesses, there are things you can do. You
can lay out the filesystem in the access order - trace the IO accesses at
bootup ("which file, which offset, which metadata block?") and lay out the
blocks of the files in exactly the right order. Then you will get linear
reads _without_ doing any "dd" at all.

Now, laying out the filesystem that way is _hard_. No question about it.
It's kind of equivalent to doing a filesystem "defreagment" operation,
except you use a different sorting function (instead of sorting blocks
linearly within each file, you sort according to access order).

Linus

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

REVISED: Experimentation with Athlon and fast_page_copy

[Seth Goldberg]

Hi,
 
 After removing my head from my a**, I revised the code that checks
the memory copy in the fast_page_copy routine.  The machine then
proceeded
not to stop at my panic, but I got my "normal" oopses.  I then had an
idea and removed all the prefetch instructions from the beginning of the
routine and tried the resultin kernel.  I now have no crashes.
What could this mean?

Here is a nother patch just so you can keep me honest if I
made another mistake:

-
diff -r ./arch/i386/lib/mmx.c ../lin2/linux/arch/i386/lib/mmx.c
149,150c149
<
< /*__asm__ __volatile__ (
---
>   __asm__ __volatile__ (
158c157
<   "3: movw $0x1AEB, 1b\n"
---
>   "3: movw $0x1AEB, 1b\n" /* jmp on 26 bytes */
166c165
< */
---
>
170c169
<   "1: nop\n" /* prefetch 320(%0)\n" */
---
>   "1: prefetch 320(%0)\n" 
-

  Please let me know if that makes sense :).

  Thank you,
   Seth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dhcp problem with realtek 8139 clone with rh 7.1

[Jeff Garzik]

Alan Cox wrote:
> 
> > I've had the same problem with the 8139too drivers and DHCP.  The reason
> > I figure it must be the drivers is because in the 2.4.3 kernel, I'm able
> > to use the 8139too drivers with DHCP without any problems.  In 2.4.4 it
> > locks my system.
> 
> Multiple such reports - seems the 8139too update broke stuf - any ideas Jeff,
> should I revert to the 2.4.3 one ?

I would say if Monday comes by without hearing from me, yes. It fixes
some people, breaks others :/

I've already got a fix on the dhcp breakage -- need to lock and unlock
EEprom before setting certain registers, and I am working on the other
problem (symptom: 'partner ability ' even when a link is present).

-- 
Jeff Garzik  | Game called on account of naked chick
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] 2.4.4 alpha semaphores optimization

[Andrea Arcangeli]

On Fri, May 04, 2001 at 09:02:33PM +0400, Ivan Kokshaysky wrote:
> But I can't imagine how this "feature" could be useful in a real life :-)

It will be required by the time we can fork more than 2^16 tasks (which
I'm wondering if it could be just the case if you use CLONE_PID as
root, I didn't checked the code yet to be sure).

> You meant "the fast path", I guess? Then it's true. However with those

Yes, I guess the slow path is quite painful to maintain, however I'd add
at least the __builtin_expect() so it gets optimized by 2.96 and 3.[01].

> atomic functions code is much more readable.

Your attached code is nice enough IMHO ;).

> Anyway, I've attached asm-alpha/rwsem_xchgadd.h for your implementation.

Sweet, thanks.

> However I got processes in D state early on boot with it -- maybe
> I've made a typo somewhere...

It has to be a bug in a non contention case then, or maybe you run some
threaded app during boot?  Note that my version is a bit different than
David's one, my fast path has less requirements in up_write and so it
can be implemented with less instructions. I will check and integrate
your code soon into my patch, thanks. If you find the bug meanwhile let
me know (to beat it hard you can use my userspace threaded app that
faults and mmap/munmap in loop from dozen of threads).

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

Re: [patch] 2.4.4 alpha semaphores optimization

[Ivan Kokshaysky]

On Fri, May 04, 2001 at 04:33:59PM +0200, Andrea Arcangeli wrote:
> the 2^16 limit is not a per-user limit it is a global one so the max
> user process ulimit is irrelevant.
> 
> Only the number of pid and the max number of tasks supported by the
> architecture is a relevant limit for this.

Thanks for the correction. I thought about a case where one user could
exhaust 2^16 limit.

> > b. "long" count would cost extra 8 bytes in the struct rw_semaphore;
> 
> correct but that's the "feature" to be able to support 2^32 concurrent
> sleepers at not relevant runtime cost 8).

But I can't imagine how this "feature" could be useful in a real life :-)

> > c. I can use existing atomic routines which deal with ints.
> 
> I was thinking at a dedicated routine that implements the slow path by
> hand as well like x86 just do. Then using ldq instead of ldl isn't
> really a big deal programmer wise.

You meant "the fast path", I guess? Then it's true. However with those
atomic functions code is much more readable.

Anyway, I've attached asm-alpha/rwsem_xchgadd.h for your implementation.
However I got processes in D state early on boot with it -- maybe
I've made a typo somewhere...

Ivan.



#ifndef _ALPHA_RWSEM_XCHGADD_H
#define _ALPHA_RWSEM_XCHGADD_H

#include   /* BITS_PER_LONG */

static inline void __down_read(struct rw_semaphore *sem)
{
long count, temp;
__asm__ __volatile__(
"1: ldq_l   %0,%1\n"
"   addq%0,1,%2\n"
"   stq_c   %2,%1\n"
"   beq %2,2f\n"
#ifdef CONFIG_SMP
"   mb\n"
#endif
".subsection 2\n"
"2: br  1b\n"
".previous"
:"=" (count), "=m" (sem->count), "=" (temp)
:"m" (sem->count) : "memory");

if (count < 0)
rwsem_down_failed(sem, RWSEM_READ_BLOCKING_BIAS);
}

static inline void __down_write(struct rw_semaphore *sem)
{
long granted, temp = RWSEM_WRITE_BIAS + RWSEM_READ_BIAS;
__asm__ __volatile__(
"1: ldq_l   %0,%1\n"
"   addq%0,%2,%2\n"
"   stq_c   %2,%1\n"
"   beq %2,2f\n"
#ifdef CONFIG_SMP
"   mb\n"
#endif
"   cmpeq   %0,0,%0\n"
".subsection 2\n"
"2: br  1b\n"
".previous"
:"=" (granted), "=m" (sem->count), "=" (temp)
:"2" (temp),"m" (sem->count) : "memory");

if (!granted)
rwsem_down_failed(sem, RWSEM_WRITE_BLOCKING_BIAS);
}


static inline void __up_read(struct rw_semaphore *sem)
{
long oldcount, temp;
__asm__ __volatile__(
#ifdef CONFIG_SMP
"   mb\n"
#endif
"1: ldq_l   %0,%1\n"
"   subq%0,1,%2\n"
"   stq_c   %2,%1\n"
"   beq %2,2f\n"
"   subl%0,1,%2\n"
".subsection 2\n"
"2: br  1b\n"
".previous"
:"=" (oldcount), "=m" (sem->count), "=" (temp)
:"m" (sem->count) : "memory");

if (oldcount < 0 && temp == 0)
rwsem_wake(sem);
}

static inline void __up_write(struct rw_semaphore *sem)
{
long count, temp = RWSEM_READ_BIAS + RWSEM_WRITE_BIAS;
__asm__ __volatile__(
#ifdef CONFIG_SMP
"   mb\n"
#endif
"1: ldq_l   %0,%1\n"
"   subq%0,%2,%2\n"
"   mov %2,%0\n"
"   stq_c   %2,%1\n"
"   beq %2,2f\n"
".subsection 2\n"
"2: br  1b\n"
".previous"
:"=" (count), "=m" (sem->count), "=" (temp)
:"2" (temp), "m" (sem->count) : "memory");

if (count < 0)
rwsem_wake(sem);
}

static inline long rwsem_xchgadd(long value, long * count)
{
long ret, temp;
__asm__ __volatile__(
"1: ldq_l   %0,%1\n"
"   addq%0,%3,%2\n"
"   stq_c   %2,%1\n"
"   beq %2,2f\n"
".subsection 2\n"
"2: br  1b\n"
".previous"
:"=" (ret), "=m" (count), "=" (temp)
:"Ir" (value), "m" (count) : "memory");

return ret;
}

#endif

Re: dhcp problem with realtek 8139 clone with rh 7.1

[Alan Cox]

> I've had the same problem with the 8139too drivers and DHCP.  The reason
> I figure it must be the drivers is because in the 2.4.3 kernel, I'm able
> to use the 8139too drivers with DHCP without any problems.  In 2.4.4 it
> locks my system.

Multiple such reports - seems the 8139too update broke stuf - any ideas Jeff,
should I revert to the 2.4.3 one ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Possible PCI subsystem bug in 2.4

[Alan Cox]

> Seriously.  With the general attitude of distrusting BIOS's I have
> been amazed at the number of things linux expects the BIOS to get
> right.  In practice windows seem to trust the BIOS much less than
> linux does.

It becomes more and more obvious over time exactly why. One problem however
is that windows gets away with this because many vendors ship random extra
gunge for their box with the system. We dont yet have that power

Alan

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