Re: Linux 2.4.2ac12 (vt82c686 info)

[Vojtech Pavlik]

On Wed, Mar 07, 2001 at 01:23:49PM +, John Heil wrote:

> > Also, the vt82c686 will work just fine with Linux, but will be limited
> > to UDMA33, because UDMA66 on this chip does reliably fail.
> 
> Based on following the lkml threads on Via chipsets, it seems that
> the 686a at or above rev 22, will run UDMA66 just fine.
> Below that, lies the flakiness...
> My Tyan based 686a rev 22 has been trouble free save a bad cable.

686 rev 00-0f => 686,  UDMA33 (UDMA66 broken, chip very rare)
686 rev 10-2f => 686a, UDMA66
686 rev 40=> 686b, UDMA100

> I just acquired a new 1.1G athlon on an asus a7v133. It has a 686b.
> What should I expect w the 686b?  and is the Via 686b data sheet 
> available somewhere? 

Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
my drivers have little bugs in the 686b support. Harmless but somewhat
annoying.

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

Re: IDE bug in 2.4.2-ac12?

[Vojtech Pavlik]

On Thu, Mar 08, 2001 at 09:01:15AM +0100, [EMAIL PROTECTED] wrote:

> Do you mean the Power Supply Unit? Or the Program Storage Unit? ;-)

Power Supply Unit, yes.

> To answer to your questions:
>  - I haven't tried to remove the CD-ROM because both devices shall work 
> together
>  - the ZIP doesn't cause problems when just the power cable is connected
> 
> Although my PC has only got an old Baby AT 200W power supply I don't think 
> that's the point.

I don't see any other way how the ZIP could have impact on the IDE HDD
on a different IDE interface.

If you wonder why /proc/ide/via reports slower DMA rates for the HDD
when the ZIP is connected is because the auto slowdown code kicks in and
lowers the transfer rate when too many CRC errors happen.

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Mapping a piece of one process' addrspace to another?

[Pavel Machek]

Hi!

> > You are reinventing the wheel.
> > man ptrace (see PTRACE_{PEEK,POKE}{TEXT,DATA} and PTRACE_{ATTACH,CONT,DETACH})
> 
> With ptrace data will be copied twice. As far as I understood, Jeremy
> wants to avoid that. 

mmap /proc/pid/memory?
Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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

Re: scsi vs ide performance on fsync's

[Pavel Machek]

Hi!
> If not, then the drive could by all means optimise the access pattern
> provided it acked the data or provided the results in the same order as the
> instructions were given.  This would probably shorten the time for a new
> pathological set (distributed evenly across the disk surface, but all on
> the worst-possible angular offset compared to the previous) to (8ms seek
> time + 5ms rotational delay) * 4000 writes ~= 52 seconds (compared with
> around 120 seconds for the previous set with rotational delay factored in).
> Great, so you only need half as big a power store to guarantee writing that
> much data, but it's still too much.  Even with a 15000rpm drive and 5ms
> seek times, it would still be too much.

Drive can trivially seek to reserved track, and flush data on it. All within 
25msec. Then, move data to proper location on next powerup. Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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

Re: IDE bug in 2.4.2-ac12?

[Konrad Stopsack]

Vojtech Pavlik wrote:
> On Thu, Mar 08, 2001 at 09:01:15AM +0100, Konrad Stopsack wrote:
> 
> > Do you mean the Power Supply Unit? Or the Program Storage Unit? ;-)
> 
> Power Supply Unit, yes.
> 
> > To answer to your questions:
> >  - I haven't tried to remove the CD-ROM because both devices shall 
work 
> > together
> >  - the ZIP doesn't cause problems when just the power cable is 
connected
> > 
> > Although my PC has only got an old Baby AT 200W power supply I don't
> think 
> > that's the point.
> 
> I don't see any other way how the ZIP could have impact on the IDE HDD
> on a different IDE interface.
The 82c586b can be a chip with locked-together IDE controllers, can't it?

> 
> If you wonder why /proc/ide/via reports slower DMA rates for the HDD
> when the ZIP is connected is because the auto slowdown code kicks in and
> lowers the transfer rate when too many CRC errors happen.

Well, and what should I do now? I really need the ZIP drive. 
Try without CD-ROM? Buy new ATX case with 300W power supply? And new 
motherboard? And new processor? And ... and ... and?
Isn't there a chance to unlock the IDE channels (if they are locked)? 
Remember, I've heard about a Windows patch to do this.

Paul, what did you find out?

cu Konrad

-- 
Konrad Stopsack - [EMAIL PROTECTED]

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

Re: IDE bug in 2.4.2-ac12?

[Konrad Stopsack]

Vojtech Pavlik wrote:
> On Thu, Mar 08, 2001 at 09:51:43AM +0100, Konrad Stopsack wrote:
> 
> > > I don't see any other way how the ZIP could have impact on the IDE 
HDD
> > > on a different IDE interface.
> > The 82c586b can be a chip with locked-together IDE controllers, can't
> it?
> 
> What do you mean by 'locked together'?
Nasty chips whose two IDE channels aren't really separated. On one IDE 
channel you either can use DMA or not. On these chips, switching off DMA 
at the second controller also disables DMA at the first.

> 
> > > If you wonder why /proc/ide/via reports slower DMA rates for the HDD
> > > when the ZIP is connected is because the auto slowdown code kicks in
> and
> > > lowers the transfer rate when too many CRC errors happen.
> > 
> > Well, and what should I do now? I really need the ZIP drive. 
> > Try without CD-ROM? Buy new ATX case with 300W power supply? And new 
> > motherboard? And new processor? And ... and ... and?
> > Isn't there a chance to unlock the IDE channels (if they are locked)? 
> > Remember, I've heard about a Windows patch to do this.
> 
> I have two vt82c586b's here and one old vt82c586. All work fine with
> different drive combinations, one even has a CD-ROM and a ZIP on the
> secondary channel like yours.

Yeah, Ok. My combination SHOULD work without any problems...

What else could I do? Swap CD-ROM and ZIP? Try new 2.4.2-ac14 with command 
line parameters "ide0=dma ide1=nodma"?

cu Konrad

-- 
Konrad Stopsack - [EMAIL PROTECTED]

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

Re: 2.4.3-pre2 aic7xxx crash on alpha

[Metod Kozelj]

Hello,

On Wed, 7 Mar 2001, Justin T. Gibbs wrote:

> >(scsi1:A:0:0): data overrun detected in Data-out phase.  Tag == 0x36.
> >(scsi1:A:0:0): Have seen Data Phase.  Length = 0.  NumSGs = 0.
> 
> As I mentioned to you the last time you brought up this problem, I
> don't believe that this is caused by the aic7xxx driver, but the
> aic7xxx driver may be the first to notice the corruption.

I can second this somehow. I was testing 2.4.2 on SX164 alpha, same
AHA-2940UW controller. In my case, system freezes solid if I do extensive
reading from CD-ROM (NEC CD-ROM DRIVE:465). It happens using stock AIC7xxx
driver (5.3.something) as well as the new (6.1.2 or something).
I'm back to 2.2.18 using AIC7xxx v5.1.31 and everything is happy.
This makes me believe that it must be mid-layer SCSI drivers causing
problems.

Peace!
  Mkx

 perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'


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

Process memory DMA access from devices, kiobuf ?

[Terry Barnaby]

Hi,

We are doing work with FPGA's and have a Linux driver for a particular
board that has these
devices. For performance reasons the driver has the ability to DMA
directly to process (user)
memory. We have made use of the kiobuf routines such as
"map_user_kiobuf()" to map into
physical memory the user address space.
I note that the RedHat kernels have a patched kernel containing the
kiobuf code but the
standard linux source does not right up to 2.4.2.
Is there a better recommended way to perform DMA access to user memory
from a device
using the Linux kernel ?

Cheers

Terry

--
  Dr Terry Barnaby BEAM Ltd
  Phone: +44 1454 324512   Northavon Business Center, Dean Rd
  Fax:   +44 1454 313172   Yate, Bristol, BS37 5NH, UK
  Email: [EMAIL PROTECTED]Web: www.beam.demon.co.uk
  BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Dev
 "Tandems are twice the fun !"



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

Re: IDE bug in 2.4.2-ac12?

[Konrad Stopsack]

Vojtech Pavlik wrote:
> On Thu, Mar 08, 2001 at 10:06:57AM +0100, Konrad Stopsack wrote:
> > Vojtech Pavlik wrote:
> > > On Thu, Mar 08, 2001 at 09:51:43AM +0100, Konrad Stopsack wrote:
> > > 
> > > > > I don't see any other way how the ZIP could have impact on the 
IDE
> 
> > HDD
> > > > > on a different IDE interface.
> > > > The 82c586b can be a chip with locked-together IDE controllers,
> can't
> > > it?
> > > 
> > > What do you mean by 'locked together'?
> > Nasty chips whose two IDE channels aren't really separated. On one IDE 
> > channel you either can use DMA or not. On these chips, switching off 
DMA
> 
> > at the second controller also disables DMA at the first.
> 
> Then this is not the case of the 586b. All four IDE drive transfer
> speeds are programmed separately.
> 
> > > I have two vt82c586b's here and one old vt82c586. All work fine with
> > > different drive combinations, one even has a CD-ROM and a ZIP on the
> > > secondary channel like yours.
> > 
> > Yeah, Ok. My combination SHOULD work without any problems...
> > 
> > What else could I do? Swap CD-ROM and ZIP? Try new 2.4.2-ac14 with
> command 
> > line parameters "ide0=dma ide1=nodma"?
> 
> I don't know. I'm attaching the very latest driver - but I doubt it
> changes anything.

Thank you. I'll try the 2.4.2-ac14 kernel and your driver.

cu Konrad

-- 
Konrad Stopsack - [EMAIL PROTECTED]

Sent through GMX FreeMail - http://www.gmx.net

Re: 64-bit capable block device layer

[David Weinehall]

On Wed, Mar 07, 2001 at 07:53:23PM +0100, Jens Axboe wrote:
> On Wed, Mar 07 2001, Rik van Riel wrote:
> > > > how would you feel about having the block device layer 64-bit
> > > > capable, so Linux can have block devices of more than 2GB in
> > > > size ?
> > >
> > > I already did this here, or something similar at least. Using
> > > a sector_t type that is 64-bit, regardless of platform. Is it
> > > really worth it to differentiate and use 32-bit types for old
> > > machines?
> > 
> > Wonderful !
> > 
> > I'm not sure how expensive 64-bit arithmetic would be on
> > eg. 386, 486 or 68k machines, or how much impact the extra
> > memory taken would have.
> > 
> > OTOH, I'm not sure what problems it could give to make this
> > a compile-time option...
> 
> Plus compile time options are nasty :-). It would probably make
> bigger sense to completely skip all the merging etc for low end
> machines. I think they already do this for embedded kernels (ie
> removing ll_rw_blk.c and elevator.c). That avoids most of the
> 64-bit arithmetic anyway.

My 386/486 and m68k-machines with 4/8/16 MB's of memory would be happy
for any and all options to remove code only needed by larger machines.
I'm pretty sure none of my 386:en will ever have 2GB of swap, 2GB of
blockdevices or 2TB filesystems...

Of course, for embedded kernels, being able to exclude block-devices
might be an idea. Or?


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

Questions - Re: [PATCH] documentation for mm.h

[Anton Altaparmakov]

At 22:33 07/03/2001, Rik van Riel wrote:
[snip]
>  typedef struct page {
>+   struct list_head list;  /* ->mapping has some page lists. */
>+   struct address_space *mapping;  /* The inode (or ...) we belong to. */
>+   unsigned long index;/* Our offset within mapping. */

Assuming index is in bytes (it looks like it is): Shouldn't index of type 
unsigned long long or __u64? Otherwise, AFAICS using the page cache 
automatically results in an artificial 4Gib limit on file size, which is 
not very good, even by todays standards.

[snip]
>+ * During disk I/O, PG_locked is used. This bit is set before I/O
>+ * and reset when I/O completes. page->wait is a wait queue of all
>+ * tasks waiting for the I/O on this page to complete.

Is this physical I/O only or does it include a driver writing/reading the page?

Thanks,

 Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

2.4.1, 2.4.2 don't compile with new 'ld' interface on i386

[Seth Arnold]

Greetings! :)

I was presented with the following error when attempting to compile
kernel 2.4.2 and 2.4.1:

[...]
nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] 
\)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map
make[2]: Entering directory `/home/sarnold/Local/Linux.2.4.1/arch/i386/boot'
make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
gcc -E -D__KERNEL__ -I/home/sarnold/Local/Linux.2.4.1/include -D__BIG_KERNEL__ 
-traditional -DSVGA_MODE=NORMAL_VGA  bootsect.S -o bbootsect.s
as -o bbootsect.o bbootsect.s
bbootsect.s: Assembler messages:
bbootsect.s:253: Warning: indirect lcall without `*'
ld -m elf_i386 -Ttext 0x0 -s -oformat binary bbootsect.o -o bbootsect
ld: cannot open binary: No such file or directory
make[2]: *** [bbootsect] Error 1
make[2]: Leaving directory `/home/sarnold/Local/Linux.2.4.1/arch/i386/boot'
make[1]: *** [bzImage] Error 2
make[1]: Leaving directory `/home/sarnold/Local/Linux.2.4.1'
make: *** [stamp-build] Error 2

Debian bug report #87037 [0] gives many details on the situation.
Upstream for 'ld' has changed -oformat to --oformat. I am probably not
the only person to try compiling the kernel with a new ld (and I
understand older versions of 'ld' support --oformat) so if 2.4.3 could
incorporate the following patch I have created (and tested *only on my
one single machine*) then many people will be spared the trouble I went
through. (Well, not that bad. :)

(Noting that I renamed the original Makefile in arch/i386/boot/Makefile to
Makefile.orig before making the diff; it may not apply cleanly, but I
hope it is obvious ... chances are good other Makefiles will need to be
modified but this is one *I* ran into. It is an exercise to find any
others. :)


[0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87037

-- 
Earthlink: The #1 provider of unsolicited bulk email to the Internet.


--- arch/i386/boot/Makefile.origThu Mar  8 02:42:53 2001
+++ arch/i386/boot/Makefile Thu Mar  8 02:43:04 2001
@@ -43,7 +43,7 @@
$(HOSTCC) $(HOSTCFLAGS) -o $@ $< -I$(TOPDIR)/include
 
 bootsect: bootsect.o
-   $(LD) -Ttext 0x0 -s -oformat binary -o $@ $<
+   $(LD) -Ttext 0x0 -s --oformat binary -o $@ $<
 
 bootsect.o: bootsect.s
$(AS) -o $@ $<
@@ -52,7 +52,7 @@
$(CPP) $(CPPFLAGS) -traditional $(SVGA_MODE) $(RAMDISK) $< -o $@
 
 bbootsect: bbootsect.o
-   $(LD) -Ttext 0x0 -s -oformat binary $< -o $@
+   $(LD) -Ttext 0x0 -s --oformat binary $< -o $@
 
 bbootsect.o: bbootsect.s
$(AS) -o $@ $<
@@ -61,7 +61,7 @@
$(CPP) $(CPPFLAGS) -D__BIG_KERNEL__ -traditional $(SVGA_MODE) $(RAMDISK) $< -o 
$@
 
 setup: setup.o
-   $(LD) -Ttext 0x0 -s -oformat binary -e begtext -o $@ $<
+   $(LD) -Ttext 0x0 -s --oformat binary -e begtext -o $@ $<
 
 setup.o: setup.s
$(AS) -o $@ $<
@@ -70,7 +70,7 @@
$(CPP) $(CPPFLAGS) -traditional $(SVGA_MODE) $(RAMDISK) $< -o $@
 
 bsetup: bsetup.o
-   $(LD) -Ttext 0x0 -s -oformat binary -e begtext -o $@ $<
+   $(LD) -Ttext 0x0 -s --oformat binary -e begtext -o $@ $<
 
 bsetup.o: bsetup.s
$(AS) -o $@ $<

Re: Questions - Re: [PATCH] documentation for mm.h

[Ingo Oeser]

On Thu, Mar 08, 2001 at 10:11:50AM +, Anton Altaparmakov wrote:
> At 22:33 07/03/2001, Rik van Riel wrote:
> [snip]
> >  typedef struct page {
> >+   struct list_head list;  /* ->mapping has some page lists. */
> >+   struct address_space *mapping;  /* The inode (or ...) we belong to. */
> >+   unsigned long index;/* Our offset within mapping. */
> 
> Assuming index is in bytes (it looks like it is): 

isn't. To get the byte offset, you have to multiply it by PAGE_{CACHE_,}SIZE.

> [snip]
> >+ * During disk I/O, PG_locked is used. This bit is set before I/O
> >+ * and reset when I/O completes. page->wait is a wait queue of all
> >+ * tasks waiting for the I/O on this page to complete.
> 
> Is this physical I/O only or does it include a driver writing/reading the page?

Depends on the method of the driver, that is getting called.
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Ooops on 2.2.18...

[Rogier Wolff]

Hi,

I misconfigured my Linux 2.2.18 kernel: forgot to include the network
device, which is kind of essential for a machine with nfs-root.
So it just sat there waiting for the root floppy... Then I recompiled
my kernel, but when I came back to the console I saw:

Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
scsi : 0 hosts.
scsi : detected total.
IP-Config: No network devices available
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
(Warning, this kernel has no ramdisk support)
VFS: Insert root floppy and press ENTER
end_request: I/O error, dev 02:00 (floppy), sector 0
Unable to handle kernel NULL pointer dereference at virtual address 0008
current->tss.cr3 = 00101000, %cr3 = 00101000

If someone has some desire to fix something, you can try to find/fix
this. 

The recompile of course overwrote the symbol table from the kernel
that I was running...

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scsi vs ide performance on fsync's

[Stephen C. Tweedie]

Hi,

On Wed, Mar 07, 2001 at 10:36:38AM -0800, Linus Torvalds wrote:
> On Wed, 7 Mar 2001, Jeremy Hansen wrote:
> > 
> > So in the meantime as this gets worked out on a lower level, we've decided
> > to take the fsync() out of berkeley db for mysql transaction logs and
> > mount the filesystem -o sync.
> > 
> > Can anyone perhaps tell me why this may be a bad idea?
> 
>  - it doesn't help. The disk will _still_ do write buffering. It's the
>DISK, not the OS. It doesn't matter what you do.
>  - your performance will suck.

Added to which, "-o sync" only enables sync metadata updates.  It
still doesn't force an fsync on data writes.

--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: spinlock help

[Hen, Shmulik]

OK guys, you were right. The bug was in our code - sorry for trouble.
Turns out that while I was away, the problem was solved by someone else. The
problem is probably related to the fact that when we did
'spin_lock_irqsave(c,d)', 'd' was a global variable. The fix was to wrap the
call with another function and declare 'd' as local. I can't quite explain,
but I think that changing from a static to automatic variable made the
difference. My best guess is that since 'd' is passed by value and not by
reference, the macro expansion of spin_lock_irqsave() relies on the location
of 'd' in the stack and if 'd' was on the heap instead, it might get
trashed.

I would really like to hear your expert opinion on my assumption.


Thanks,
Shmulik.

-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 07, 2001 2:54 PM
To: Hen, Shmulik
Cc: 'LKML'
Subject: Re: spinlock help


"Hen, Shmulik" wrote:
> 
> The kdb trace was accurate, we could actually see the e100 ISR pop from no
> where right in the middle of our ans_notify every time the TX queue would
> fill up. When we commented out the call to spin_*_irqsave(), it worked
fine
> under heavy stress for days.
> 
> Is it possible it was something wrong with 2.4.0-test10 specifically ?
> 

Sorry, no.  If spin_lock_irqsave()/spin_unlock_irqrestore()
were accidentally reenabling interrupts then it would be
the biggest, ugliest catastrophe since someone put out a kernel
which forgot to flush dirty inodes to disk :)

Conceivably it was a compiler bug.  Were you using egcs-1.1.2/x86?

-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: static scheduling - SCHED_IDLE?

[Zdenek Kabelac]

ludovic wrote:
> 
> Oswald Buddenhagen wrote:
> >
> > > The problem with these things it that sometimes such a task may hold
> > > a lock, which can prevent higher-priority tasks from running.
> > >
> > true ... three ideas:
> > - a sort of temporary priority elevation (the opposite of SCHED_YIELD)
> >   as long as the process holds some lock
> > - automatically schedule the task, if some higher-priorized task wants
> >   the lock
> > - preventing the processes from aquiring locks at all (obviously this
> >   is not possible for required locks inside the kernel, but i don't
> >   know enough about this)
> >
> > > A solution would be to make sure that these tasks get at least one
> > > time slice every 3 seconds or so, so they can release any locks
> > > they might be holding and the system as a whole won't livelock.
> > >
> > did "these" apply only to the tasks, that actually hold a lock?
> > if not, then i don't like this idea, as it gives the processes
> > time for the only reason, that it _might_ hold a lock. this basically
> > undermines the idea of static classes. in this case, we could actually
> > just make the "nice" scale incredibly large and possibly nonlinear,
> > as mark suggested.
> >
> 
> Since the linux kernel is not preemptive, the problem is a little
> bit more complicated; A low priority kernel thread won't lose the
> CPU while holding a lock except if it wants to. That simplifies the
> locking problem you mention but the idea of background low priority
> threads that run when the machine is really idle is also not this
> simple.

You seem to have a sence for black humor right :) ?
As this is purely a complete nonsence 
- you were talking about M$Win3.11 right ?
(are you really the employ of Sun ??)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: spinlock help

[Andrew Morton]

"Hen, Shmulik" wrote:
> 
> OK guys, you were right. The bug was in our code - sorry for trouble.
> Turns out that while I was away, the problem was solved by someone else. The
> problem is probably related to the fact that when we did
> 'spin_lock_irqsave(c,d)', 'd' was a global variable. The fix was to wrap the
> call with another function and declare 'd' as local. I can't quite explain,
> but I think that changing from a static to automatic variable made the
> difference. My best guess is that since 'd' is passed by value and not by
> reference, the macro expansion of spin_lock_irqsave() relies on the location
> of 'd' in the stack and if 'd' was on the heap instead, it might get
> trashed.
> 

Yes, that makes sense.

spin_lock_irqsave() really means "save the current irq mask
on the stack, then disable interrupts". spin_lock_irqrestore()
says "restore the current interrupt mask from the stack".  So they
nest, and spin_lock_irqsave() doesn't have to care whether or
not interrupts are currently enabled.

Using a global variable you could get something like:

CPU0: CPU1
 
__cli();  
spin_lock_irqsave(lock, global)
  __sti();
  spin_lock_irqsave(lock2, global)
  spin_lock_irqrestore(lock2, global)
spin_unlock_irqrestore(lock, global)
/* interrupts should be disabled */

Here, CPU1 will set `global' to "interrupts enabled".  So when
CPU0 restores its flags from `global' it will be picking up
CPU1's flags, not its own!

There are probably less subtle failure modes than this..

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Questions - Re: [PATCH] documentation for mm.h

[Anton Altaparmakov]

At 10:51 08/03/01, Ingo Oeser wrote:
>On Thu, Mar 08, 2001 at 10:11:50AM +, Anton Altaparmakov wrote:
> > At 22:33 07/03/2001, Rik van Riel wrote:
> > [snip]
> > >  typedef struct page {
> > >+   struct list_head list;  /* ->mapping has some page 
> lists. */
> > >+   struct address_space *mapping;  /* The inode (or ...) we 
> belong to. */
> > >+   unsigned long index;/* Our offset within mapping. */
> >
> > Assuming index is in bytes (it looks like it is):
>
>isn't. To get the byte offset, you have to multiply it by PAGE_{CACHE_,}SIZE.

Hi, first of all, thanks for the reply!

How do you reconcile that statement with the following comment from mm.h?

 > * A page may belong to an inode's memory mapping. In this case,
 > * page->mapping is the pointer to the inode, and page->offset is the
 > * file offset of the page (not necessarily a multiple of PAGE_SIZE).

Surely, if you have to multiply index by PAGE_{CACHE_}SIZE, page->offset 
would be a multiple of PAGE_{CACHE_}SIZE?

And even if it really is PAGE_{CACHE_}SIZE units, this still doesn't solve 
the problem, it just defers it to 16Tib (on ia32 arch with 4kib 
PAGE_{CACHE_}SIZE). With NTFS 3.0's use of sparse files, for the usn 
journal for example, even this will be overflowed at some point on a 
busy/large server. The only proper solution AFAICS is to allow the full 
64-bits.

> > [snip]
> > >+ * During disk I/O, PG_locked is used. This bit is set before I/O
> > >+ * and reset when I/O completes. page->wait is a wait queue of all
> > >+ * tasks waiting for the I/O on this page to complete.
> >
> > Is this physical I/O only or does it include a driver writing/reading 
> the page?
>
>Depends on the method of the driver, that is getting called.

Sorry, I should have been more detailed in my question, so let me try 
again: When the NTFS file system driver needs to modify the meta data, 
which will be in the page cache (meta data is stored in normal files on 
NTFS, hence the page cache is very well suited to storing it with it's 
page->mapping and page->offset fields), does the NTFS driver need to set 
PG_locked while writing to the page?

And what about reading for that matter? What is the access serialization here?

Obviously I can have several readers on the same metadata at the same time, 
and that's fine, but if someone is writing, then allowing anyone to read 
the data at the same time would result in corrupt meta data being read 
(this is because I am only going to use the page cache, i.e. there will be 
no copying of the data at all, except for: user space <-> page cache <-> 
disk). I am thinking that a read/write semaphore would be the perfect 
solution for this here, but it would be nice, if this could be handled on a 
per page basis rather than a per file basis, at the very least so for meta 
data files.

Thanks,

 Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

RE: pthreads related issues

[Tony Gale]

I think the following should explain the performance issue you are
seeing.

Quote from Kaz Kylheku <[EMAIL PROTECTED]>:

---

When things run slower on SMP, there are usually these possible
explanations. 

Firstly, there may be cache thrashing: in order for threads to have a
consistent view of shared data across multiple processors, data has to
travel thorugh the interconnecting backplane, switch or what have you,
regardless of how small the footprint of the data is. On a single
processor, no such communication has to take place; the program can
work off the processor's on-chip cache.

Secondly, it may be the case that the threads are strictly alternating
in their acquisition of the mutex, which imposes a severe scheduling
penalty into the execution of the program. Imagine that each time the
producer creates an item, a context switch takes place to the consumer
to remove the item. Such a scenario runs much slower than if the
producer can append a large batch of items which the consumer removes
in one fell swoop when it gets a timeslice.

On Linux, the default mutexes implement a strict fairness policy; when
a mutex is unlocked, ownership is transferred to one of the threads
waiting for it, according to priority---even if some currently running
thread is prime and ready to seize the lock, it must wait its turn.
This behavior can readily lead to strict alternation under SMP,
because
as thread is busy inside the mutex, the other thread can execute on
another processor and independently reach the pthread_mutex_lock()
statement, at which point it is guaranteed that it is eligible to get
that mutex as soon as it is unlocked.

Ulrich Drepper, Xavier Leroy and I have discussed this matter at
length
some months since and decided to leave the mutexes as they are, with
the fairness behavior. You can gain access to alternate behaviors by
using one of the non-portable mutex types.  In glibc2.2 you have the
following:

enum
{
  PTHREAD_MUTEX_TIMED_NP,
  PTHREAD_MUTEX_RECURSIVE_NP,
  PTHREAD_MUTEX_ERRORCHECK_NP,
  PTHREAD_MUTEX_ADAPTIVE_NP
#ifdef __USE_UNIX98
  ,
  PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_TIMED_NP,
  PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
  PTHREAD_MUTEX_ERRORCHECK = PTHREAD_MUTEX_ERRORCHECK_NP,
  PTHREAD_MUTEX_DEFAULT = PTHREAD_MUTEX_NORMAL
#endif
#ifdef __USE_GNU
  /* For compatibility.  */
  , PTHREAD_MUTEX_FAST_NP = PTHREAD_MUTEX_ADAPTIVE_NP
#endif
};

As you can see, the normal mutex now is PTHREAD_MUTEX_TIMED_NP, in
order to support the pthread_mutex_timedlock operation (which only
works with this mutex type). This mutex also has the fair scheduling
behavior that is so detrimental in some SMP scenarios.   It's
essentially your deluxe model with all the fixin's.

The PTHRED_MUTEX_ADAPTIVE_NP is a new mutex that is intended for high
throughput at the sacrifice of fairness and even CPU cycles.  This
mutex does not transfer ownership to a waiting thread, but rather
allows for competition. Also, over an SMP kernel, the lock operation
uses spinning to retry the lock to avoid the cost of immediate
descheduling. 

Try experimenting with this lock type to see how it affects the
behavior of your program. (To keep the program portable, you can use
#ifdef PTHREAD_ADAPTIVE_INITIALIZER_NP to test for the presence of
this
lock type).



-tony


On 07-Mar-2001 Ying Chen wrote:
> Hi,
> 
> I think I forgot to include the subject on the email I sent last
> time.
> Not sure how many people saw it. I'm trying to send this message
> again...
> 
> I have two questions on Linux pthread related issues. Would anyone
> be able 
> to help?
> 
> 1. Does any one have some suggestions (pointers) on good kernel
> Linux thread 
> libraries?
> 2. We ran multi-threaded application using Linux pthread library on
> 2-way 
> SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see 
> significant increase in context switching when moving from UP to
> SMP, and 
> high CPU usage with no performance gain in turns of actual work
> being done 
> when moving to SMP, despite the fact the benchmark we are running
> is 
> CPU-bound. The kernel profiler indicates that the a lot of kernel
> CPU ticks 
> went to scheduling and signaling overheads. Has anyone seen
> something like 
> this before with pthread applications running on SMP platforms? Any
> suggestions or pointers on this subject?
> 

---
E-Mail: Tony Gale <[EMAIL PROTECTED]>
When you jump for joy, beware that no-one moves the ground from beneath
your feet.
-- Stanislaw Lem, "Unkempt Thoughts"

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA

SX driver patch.

[Rogier Wolff]

Hi Alan,

A client noted that we forgot to implement breaks in the SX
driver. Turns out to be easy. Moreover... I actually tested this
patch!  (Somehow the Makefile entry for SX got stomped on, that's
fixed here too.)

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 


diff -ur linux-2.2.19-pre16.clean/drivers/char/Makefile 
linux-2.2.19-pre16.sx/drivers/char/Makefile
--- linux-2.2.19-pre16.clean/drivers/char/Makefile  Thu Mar  8 12:30:33 2001
+++ linux-2.2.19-pre16.sx/drivers/char/Makefile Thu Mar  8 12:31:22 2001
@@ -200,7 +200,13 @@
   endif
 endif
 
-obj-$(CONFIG_SX) += sx.o generic_serial.o
+ifeq ($(CONFIG_SX),y)
+O_OBJS += sx.o generic_serial.o
+else
+  ifeq ($(CONFIG_SX),m)
+  M_OBJS += sx.o generic_serial.o
+  endif
+endif
 
 ifeq ($(CONFIG_RIO),y)
 O_OBJS += rio/rio.o generic_serial.o
diff -ur linux-2.2.19-pre16.clean/drivers/char/sx.c 
linux-2.2.19-pre16.sx/drivers/char/sx.c
--- linux-2.2.19-pre16.clean/drivers/char/sx.c  Thu Jan  4 16:27:07 2001
+++ linux-2.2.19-pre16.sx/drivers/char/sx.c Thu Mar  8 12:31:22 2001
@@ -1799,6 +1799,20 @@
 }
 
 
+static void sx_break (struct tty_struct * tty, int flag)
+{
+   struct sx_port *port = tty->driver_data;
+   int rv;
+
+   if (flag) 
+   rv = sx_send_command (port, HS_START, -1, HS_IDLE_BREAK);
+   else 
+   rv = sx_send_command (port, HS_STOP, -1, HS_IDLE_OPEN);
+   if (rv != 1) printk (KERN_ERR "sx: couldn't send break (%x).\n",
+   read_sx_byte (port->board, CHAN_OFFSET (port, hi_hstat)));
+}
+
+
 static int sx_ioctl (struct tty_struct * tty, struct file * filp, 
  unsigned int cmd, unsigned long arg)
 {
@@ -1867,7 +1881,6 @@
sx_reconfigure_port(port);
}
break;
-
default:
rc = -ENOIOCTLCMD;
break;
@@ -2247,6 +2260,7 @@
sx_driver.table = sx_table;
sx_driver.termios = sx_termios;
sx_driver.termios_locked = sx_termios_locked;
+   sx_driver.break_ctl = sx_break;
 
sx_driver.open  = sx_open;
sx_driver.close = gs_close;

Re: 2.4.3-pre2 aic7xxx crash on alpha

[Wakko Warner]

> > >(scsi1:A:0:0): data overrun detected in Data-out phase.  Tag == 0x36.
> > >(scsi1:A:0:0): Have seen Data Phase.  Length = 0.  NumSGs = 0.
> > 
> > As I mentioned to you the last time you brought up this problem, I
> > don't believe that this is caused by the aic7xxx driver, but the
> > aic7xxx driver may be the first to notice the corruption.
> 
> I can second this somehow. I was testing 2.4.2 on SX164 alpha, same
> AHA-2940UW controller. In my case, system freezes solid if I do extensive
> reading from CD-ROM (NEC CD-ROM DRIVE:465). It happens using stock AIC7xxx
> driver (5.3.something) as well as the new (6.1.2 or something).
> I'm back to 2.2.18 using AIC7xxx v5.1.31 and everything is happy.
> This makes me believe that it must be mid-layer SCSI drivers causing
> problems.

I tried the aic driver from 2.2.17 and 18 which also lockup this system.

Noone on the list that I've seen has used an adaptec card in an alphaserver
1000a 4/266 and said anything about it.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: aic7xxx funcs without return values

[Alan Cox]

> They don't return a value because doing so is meaningless.  You aren't
> going to get past the panic.  The compiler should know that assuming
> panic is properly tagged as a function that cannot return.
> 
> You may also want to check up on your C since having a break after
> a return is, well, kinda silly.  In all the usage of this inline, the
> width is constant, so gcc should completely optimize away the switch
> and surrounding code.

Yep.

The bigger problem with that driver for pedants is that it contains globals with
names like 'hard_error' which are asking for clashes . Bizarrely all
the static functions are carefully named ahc_* and the globals are called
things like 'restart_squencer'

The EISA probe code is also horrible, but thats not Justin's fault. Someone
needs to put some eisa_* bus functions into the kernel for that and some
of the other drivers.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: static scheduling - SCHED_IDLE?

[Andrew Morton]

Zdenek Kabelac wrote:
> 
> > Since the linux kernel is not preemptive, the problem is a little
> > bit more complicated; A low priority kernel thread won't lose the
> > CPU while holding a lock except if it wants to. That simplifies the
> > locking problem you mention but the idea of background low priority
> > threads that run when the machine is really idle is also not this
> > simple.
> 
> You seem to have a sence for black humor right :) ?
> As this is purely a complete nonsence
> - you were talking about M$Win3.11 right ?
> (are you really the employ of Sun ??)

awww..  Don't say that.  Ludovic is a nice guy.

Look.  Suppose you have a SCHED_IDLE task which does this,
in the kernel:

down(&sem1);
down(&sem2);/* This sleeps */

Now, a SCHED_OTHER task does this, in user space:

for ( ; ; )
;

We're dead.  The SCHED_IDLE task will never be scheduled,
and hence will never release sem1.  The solution to this
problem is well known but, as Ludovic says, "not simple".

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

Re: Linux kernel - and regular sync'ing?

[Alan Cox]

> at irregular intervals of 10-30 seconds, most likely calls to sync, so
> that the disk never gets to sleep for long.  I've followed advice in the
> various HOWTO's, e.g. modifying the line "ud::once:/sbin/update" in
> /etc/inittab to only sync once an hour, to no avail.  Watching "top", it

Thats actually I think poor advice - it wont help and its asking to lose data

>Can you offer me any advice?  Any tweeks I can make to tell the system
> that sync'ing only once every 5 minutes is o.k.?

You machine can sync continually - providing it isnt writing data. The real
question is not 'why is it syncing' but 'what is it syncing'.

The normal answer is file access times, and you can turn those off with the
noatime mount option.

To quote the linux on palmax page

   For startup my /etc/rc.d/rc.local contains the following lines.
mount -o remount,rw,noatime /
/sbin/hdparm -S 15 /dev/hda

   The  "noatime"  setting  turns off the writing back of 'last accessed'
   times  to  files. This means reading/opening files does not cause disk
   wakeups.  The  hdparm -S 15 command sets the disk to spin down after 1
   minute  15 seconds (you can play with the value).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.2ac14

[Alan Cox]

> >The next patch would create the file `include/linux/hdlc.h',
> >which already exists!  Assume -R? [n] n
> >Apply anyway? [n] y
> >patching file `include/linux/hdlc.h'
> >Patch attempted to create file `include/linux/hdlc.h', which already exists.
> >Hunk #1 FAILED at 1.
> >1 out of 1 hunk FAILED -- saving rejects to include/linux/hdlc.h.rej
> 
> must remove before patching? or ignore it?

That looks like you applied ac14 over ac13 or to 2.4.3pre not to 2.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

v0.92,Tulip, carrier errors

[John Brosnan]

Hi, 

using Donald Becker's tulip.c:v0.92 on Linux 2.2.16, 
if I bring down an interface using ifconfig and
bring it back up again, when I transmit data on the 
interface I see lots of carrier errors and very bad 
performance.  Is this a known problem ? 
Any workarounds/fixes ?

thanks, 

John


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

Re: 64-bit capable block device layer

[Stephen C. Tweedie]

Hi,

On Wed, Mar 07, 2001 at 07:53:23PM +0100, Jens Axboe wrote:
> > 
> > OTOH, I'm not sure what problems it could give to make this
> > a compile-time option...
> 
> Plus compile time options are nasty :-). It would probably make
> bigger sense to completely skip all the merging etc for low end
> machines. I think they already do this for embedded kernels (ie
> removing ll_rw_blk.c and elevator.c). That avoids most of the
> 64-bit arithmetic anyway.

It's not just a sector-number and ll_rw_blk/elevator issue.  The limit
goes all the way up to the users of the block device, be they the
filesystem, buffer cache or block read/write layer.  

This is especially true for filesystems like XFS which need a 512-byte
blocksize.  At least with ext2 you can set the blocksize to 4kB and
get some of the benefit of larger block devices without having to
overflow the 32-bit block number.

Cheers,
 Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Questions - Re: [PATCH] documentation for mm.h

[Rik van Riel]

On Thu, 8 Mar 2001, Anton Altaparmakov wrote:
> At 10:51 08/03/01, Ingo Oeser wrote:
> >On Thu, Mar 08, 2001 at 10:11:50AM +, Anton Altaparmakov wrote:
> > > At 22:33 07/03/2001, Rik van Riel wrote:

>  > * A page may belong to an inode's memory mapping. In this case,
>  > * page->mapping is the pointer to the inode, and page->offset is the
>  > * file offset of the page (not necessarily a multiple of PAGE_SIZE).
>
> Surely, if you have to multiply index by PAGE_{CACHE_}SIZE,
> page->offset would be a multiple of PAGE_{CACHE_}SIZE?

Whooops, indeed. This was a piece of old documentation which was
200 lines down for inexplicable reasons. It's been corrected now.

thanks,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

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

Re: Questions - Re: [PATCH] documentation for mm.h

[Rik van Riel]

On Thu, 8 Mar 2001, Anton Altaparmakov wrote:
> At 22:33 07/03/2001, Rik van Riel wrote:
> [snip]
> >  typedef struct page {
> >+   struct list_head list;  /* ->mapping has some page lists. */
> >+   struct address_space *mapping;  /* The inode (or ...) we belong to. */
> >+   unsigned long index;/* Our offset within mapping. */
>
> Assuming index is in bytes (it looks like it is): Shouldn't index of type

It's in units of PAGE_CACHE_SIZE. I've corrected the documentation.

> [snip]
> >+ * During disk I/O, PG_locked is used. This bit is set before I/O
> >+ * and reset when I/O completes. page->wait is a wait queue of all
> >+ * tasks waiting for the I/O on this page to complete.
>
> Is this physical I/O only or does it include a driver
> writing/reading the page?

I'm not sure ... anyone ?

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

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

scan directory content in kernel-level code

[christophe barbe]

I'm trying to scan the content of the /dev directory in a init_module function.
I've not found example in the kernel source. So I try to reproduce the work of the 
system call.
I open the directory, check if the readdir pointer is not null in the f_op structure 
and then use it with my filldir function.
Because I don't need to stock names, I use filename directly in the filldir callback.
So in the filldir function, I check if the name match a simple regexp and if yes, I 
open the file and store the filp pointer.

First I don't understand why I need to call several times readdir in order to scan the 
directory (I imagine each times I obtain the content of one buffer). I check the 
number of callback call to stop calling readdir. It works but it seems strange.

Second problem, Sometimes the modprobe dead-locks in my filldir function. And I've 
found that it never arrives if i do a "ls /dev" before modprobe. Moreover if I don't 
take the directory inode semaphore, the problem never arrives. 
What's wrong ?

Christophe ...


struct my_dentry {
char fullname[5];
char name[MAX_DEVNAME_SIZE+1];
int count;
};

int my_filldir(void * __buf, const char * name, int namlen, off_t offset, ino_t ino, 
unsigned unused)
{
struct my_dentry * buf = (struct my_dentry *)__buf;

if (namlen>MAX_DEVNAME_SIZE) namlen=MAX_DEVNAME_SIZE;

memcpy((char *)buf->name, name, namlen);
buf->name[namlen]='\0';
check_device(buf->fullname);  // here I open the file if the string match 
criteria
buf->count++;
return 0;
}

void scan_device_directory(void)
{
struct file * filp;
struct inode * d_inode;
struct my_dentry dir_entry={"/dev/",};
int rc;

filp = filp_open("/dev", O_RDONLY|O_SYNC, 0600);
if ((rc=IS_ERR(filp))>0)  {
printk("bad filp : %d\n", rc);
return;
}

d_inode = filp->f_dentry->d_inode;
if (!d_inode) {
printk("NULL inode\n");
goto out_close_dir;
}

if (! S_ISDIR(d_inode->i_mode)) {
printk("/dev is not a directory (?)\n");
goto out_close_dir;
}

if (filp->f_op->readdir == NULL) {
printk("can't find readidir f_ops\n");
goto out_close_dir;
}

v_printk("/dev : inode=%ld\n", d_inode->i_ino);

down(&d_inode->i_sem);

do {
dir_entry.count=0;
rc=filp->f_op->readdir(filp, (void *)&dir_entry, my_filldir);
} while (dir_entry.count>0);

up(&d_inode->i_sem);

out_close_dir:
fput(filp);
}

-- 
Christophe Barbé
Software Engineer
Lineo High Availability Group
42-46, rue Médéric
92110 Clichy - France
phone (33).1.41.40.02.12
fax (33).1.41.40.02.01
www.lineo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Questions - Re: [PATCH] documentation for mm.h

[Ingo Oeser]

Hi,

On Thu, Mar 08, 2001 at 11:39:27AM +, Anton Altaparmakov wrote:
> > > >+   unsigned long index;/* Our offset within mapping. */
> > > Assuming index is in bytes (it looks like it is):
> >isn't. To get the byte offset, you have to multiply it by PAGE_{CACHE_,}SIZE.
> 
> How do you reconcile that statement with the following comment from mm.h?
> 
>  > * A page may belong to an inode's memory mapping. In this case,
>  > * page->mapping is the pointer to the inode, and page->offset is the
>  > * file offset of the page (not necessarily a multiple of PAGE_SIZE).
 
page->index << PAGE_CACHE_SHIFT is the byte offset of this page
in the mapping.

The comment is crap, that should be removed (page->offset does
not exist anymore). 

Rik did this in his documentation patch or will do it, if he
reads this ;-)

> And even if it really is PAGE_{CACHE_}SIZE units, this still doesn't solve 
> the problem, it just defers it to 16Tib (on ia32 arch with 4kib 
> PAGE_{CACHE_}SIZE). With NTFS 3.0's use of sparse files, for the usn 
> journal for example, even this will be overflowed at some point on a 
> busy/large server. The only proper solution AFAICS is to allow the full 
> 64-bits.
 
Which is discussed already in another thread at lkml. I hope that
we'll get a 64bit blocklayer one day in 2.5/2.6 development.
Since this is only around 2 years and might be backported to 2.4
if needed, I don't see a big problem of deferring this.

Let's leave some market niche for commercial solutions for a while ;-)

> > > [snip]
> > > >+ * During disk I/O, PG_locked is used. This bit is set before I/O
> > > >+ * and reset when I/O completes. page->wait is a wait queue of all
> > > >+ * tasks waiting for the I/O on this page to complete.
> > >
> > > Is this physical I/O only or does it include a driver writing/reading 
> > the page?
> >
> >Depends on the method of the driver, that is getting called.
> 
> Sorry, I should have been more detailed in my question, so let me try 
> again: When the NTFS file system driver needs to modify the meta data, 
> which will be in the page cache (meta data is stored in normal files on 
> NTFS, hence the page cache is very well suited to storing it with it's 
> page->mapping and page->offset fields), does the NTFS driver need to set 
> PG_locked while writing to the page?

Ahh. I thought you've meant DEVICE drivers. If I talk about
drivers, I usally mean that. 

May be you should raise these issues again under a separate
subject and CC [EMAIL PROTECTED] for this.

I think it is worth it, because Linus want all fs to use page
cache for meta data and let buffer cache die slowly.

Basically the rules go like this:

The VM will wait for PG_locked pages, before it accesses them or
ignore them, if it cannot wait.

It will also try to read in pages, that are not PG_uptodate.

But user space will never see metadata pages anyway, so you
should be the only one, who cares about them. Just be prepared to
writepage() and readpage() and the like.

Just use lock_page() if you can sleep and TryLockPage() + EFAULT
(or similar) if you cannot.

Then just check Page_Uptodate() before you read and do
ClearUptodate() if you start writing to the metadata.

Since these operations are atomic bit operations, it should
suffice for your purpose.

But as stated above, I'm not very sure that I understand all the
code and know of all the races.

Multiple readers are AFAICS not yet possible with the current page
cache. 

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch] Module Unloading using Read-Copy-Update

[Maneesh Soni]

Hello,
 
In this post I would like to submit a patch providing a two phase cleanup logic
for solving the module unloading races in linux. It uses the deferred update
interface provided by the Read-Copy-Update mechanism. A patch with 
implementation of Read-Copy-Update on linux has been posted earlier on lkml and 
lse-tech by Dipankar Sarma
   http://marc.theaimsgroup.com/?l=lse-tech&m=98292649600654&w=2
 
In this first version of the new cleanup logic, I have tried to keep the changes 
lesser. Please download the patch and a readme along with a few testcases from
 
   http://lse.sourceforge.net/locking/module_unloading-2.4.1-0.1.tar.gz
 
 
Thank you,
Maneesh
 
--
Maneesh Soni
Linux Technology Center,
IBM Software Labs, Bangalore, INDIA
Phone: +91-80-5262355 Extn: 2717 
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

quota on 32bit-uid patch

[Keitaro Yosimura]

Hi Marco van Wieringen, Linus, and any hackers.

I've ported my quota patches for 2.4.2.

based on 
 
ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/quota-fix-2.4.0-test12-1.diff.gz
 
ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/quota-patch-2.4.0-test12-1.diff.gz

You can download the patches from
http://www.moemoe.gr.jp/~ramsy/Files/Linux/quota/patch-2.4.2-ky2.patch.bz2

RedHat 7.0.X's quota are not ready for 32bit-uid.
You can download the patched rpm from...
http://www.moemoe.gr.jp/~ramsy/Files/Linux/quota/quota-2.00-3ky3.src.rpm
http://www.moemoe.gr.jp/~ramsy/Files/Linux/quota/quota-2.00-3ky3.i386.rpm
(this rpm build on RedHat-7.0.1J. please rebuild src.rpm.)

please merge the kernel&tool patchs:)

Thanks.

<|> YOSHIMURA 'ramsy' Keitaro / Japan Linux Association
<|> mailto:[EMAIL PROTECTED]
<|> http://jla.linux.or.jp/index.html

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

low-latency patches

[Andrew Morton]

These have been updated, retested and I'm now tracking
the -ac kernels.

http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads

Changes since Jan 23:  none.

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

ACPI:system description tables not found.

[Stephen Torri]

I am using kernel-2.4.2-ac12 (will try ac14). The motherboard is a
Supermicro P6DBU. (I will need to check the board when I get home to
confirm). I get the messages below when the system starts:

acpi: system description tables not found

The manufacturer says that there is support for acpi. So I willing to beat
it around a bit to get the tables found. Any ideas where to start?

Stephen

---
Buyer's Guide for a Operating System:
Don't care to know: Mac
Don't mind knowing but not too much: Windows
Hit me! I can take it!: Linux

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: 64-bit capable block device layer

[Ingo Oeser]

On Wed, Mar 07, 2001 at 07:53:23PM +0100, Jens Axboe wrote:
> Plus compile time options are nasty :-). It would probably make
> bigger sense to completely skip all the merging etc for low end
> machines. I think they already do this for embedded kernels (ie
> removing ll_rw_blk.c and elevator.c). That avoids most of the
> 64-bit arithmetic anyway.

Do you know of any patches to do so?

Thanks and regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: static scheduling - SCHED_IDLE?

[Boris Dragovic]

> did "these" apply only to the tasks, that actually hold a lock?
> if not, then i don't like this idea, as it gives the processes
> time for the only reason, that it _might_ hold a lock. this basically 
> undermines the idea of static classes. in this case, we could actually
> just make the "nice" scale incredibly large and possibly nonlinear, 
> as mark suggested.

would it be possible to subqueue tasks that are holding a lock so that
they get some guaranteed amount of cpu and just leave other to be executed
when processor really idle?

lynx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Questions about Enterprise Storage with Linux

[Jesse Pollard]

james rich <[EMAIL PROTECTED]>:
> On Wed, 7 Mar 2001, Tom Sightler wrote:
> 
> > 2.  Does linux have any problems with large (500GB+) NFS exports, how about
> > large files over NFS?
> > 
> > 3.  What filesystem would be best for such large volumes?  We currently use
> > reirserfs on our internal system, but they generally have filesystems in the
> > 18-30GB ranges and we're talking about potentially 10-20x that.  Should we
> > look at JFS/XFS or others?
> 
> I think that for filesystems this size you definately want to look at XFS
> of JFS.  Maybe you will decide not to use them - but you should test them.
> 
> I am currently using XFS and it really works.  It currently has some
> issues when used with raid 1, but it is probably the most suited for what
> you want.  Exporting an XFS volume over NFS is no problem.  You can also
> use xfs_growfs to change the size of your XFS partition.  I haven't had
> any instability during all the time I've used XFS.

The biggest difficulty I had with XFS (not on linux as a server) had
more to do with NFS/XFS performance. The SGI clients worked fine while
the Linux clients were about 10-20% slower. This was a year ago so this
may not apply anymore. I haven't seen any Linux NFS benchmarks recently.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ACPI:system description tables not found.

[Stephen Torri]

Motherboard is a P6DBE. IDE drives. Just found the site and confirmed it.

Stephen

On Thu, 8 Mar 2001, Stephen Torri wrote:

> I am using kernel-2.4.2-ac12 (will try ac14). The motherboard is a
> Supermicro P6DBU. (I will need to check the board when I get home to
> confirm). I get the messages below when the system starts:
>
> acpi: system description tables not found
>
> The manufacturer says that there is support for acpi. So I willing to beat
> it around a bit to get the tables found. Any ideas where to start?
>
> Stephen
>
> ---
> Buyer's Guide for a Operating System:
> Don't care to know: Mac
> Don't mind knowing but not too much: Windows
> Hit me! I can take it!: Linux
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

---
Buyer's Guide for a Operating System:
Don't care to know: Mac
Don't mind knowing but not too much: Windows
Hit me! I can take it!: Linux

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: static scheduling - SCHED_IDLE?

[Rik van Riel]

On Thu, 8 Mar 2001, Boris Dragovic wrote:

> > did "these" apply only to the tasks, that actually hold a lock?
> > if not, then i don't like this idea, as it gives the processes
> > time for the only reason, that it _might_ hold a lock. this basically
> > undermines the idea of static classes. in this case, we could actually
> > just make the "nice" scale incredibly large and possibly nonlinear,
> > as mark suggested.
>
> would it be possible to subqueue tasks that are holding a lock
> so that they get some guaranteed amount of cpu and just leave
> other to be executed when processor really idle?

Of course. Now we just need the code to determine when a task
is holding some kernel-side lock  ;)

regrads,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

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

2.4.2 kernel mount crash

[Jie Zhou]

Hi, Folks,

I did an upgrade from  kernel-2.2.16 to the latest version-2.4.2.
During the "make bzImage"step, I got bunch of this warning:
"pasting would not give a valid preprocessing token". then I just ignored
it and after all done
rebooted the linux and got into the new kernel successfully. However, when
I tried to
mount my DVD RAM using the command mount -t udf /dev/hdb /mnt/dvd
(I did choose the support for udf filesystem), the command completed with a
promp appears.but
after the 'busy' light on the DVD catridge gets on, it never gets off any
more, and
the computer froze then. I thought it might be because I haven't unmount
the DVD
, so I restarted the computer and use the 'dmesg' command to see what
happens, then I found a lot of
"Unable to identify CD-ROM Format" messages in it. so I did a 'mount'
command to check whether it's
 mounted or not, and the result shows that the /dev/hdb(which is the DVD on
my computer) is not mounted
yet.So I did the mount -t udf /dev/hdb /mnt/dvd again, same thing happens
again-the computer froze with the DVD light on.
I read in the book "Running Linux", the author said
"If any errors or warnings occur while compiling, you cannot expect the
resulting
kernel to work correctly..." I'm wondering if it's because of the the
warning I got during
the process of compiling the image file-"pasting would not give a valid
preprocessing token"
that the mount command fails.
Any kind of suggestions are appreciated..

-Jie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.2 kernel mount crash

[Remco B. Brink]

"Jie Zhou" <[EMAIL PROTECTED]> writes:
> I did an upgrade from  kernel-2.2.16 to the latest version-2.4.2.
> During the "make bzImage"step, I got bunch of this warning:
> "pasting would not give a valid preprocessing token". then I just ignored
> it and after all done rebooted the linux and got into the new kernel successfully. 

The above message is related to the version of gcc that you get with
your copy of RedHat7. You might just want to use kgcc instead of gcc
to compile your kernel.

> However, when I tried to mount my DVD RAM using the command mount -t udf /dev/hdb 
>/mnt/dvd
> (I did choose the support for udf filesystem), the command completed with a
> promp appears.but after the 'busy' light on the DVD catridge gets on, it never gets 
>off any
> more, and the computer froze then. I thought it might be because I haven't unmount
> the DVD , so I restarted the computer and use the 'dmesg' command to see what
> happens, then I found a lot of "Unable to identify CD-ROM Format" messages in it. so 
>I did a 'mount'
> command to check whether it's mounted or not, and the result shows that the 
>/dev/hdb(which is the DVD on
> my computer) is not mounted yet.

Same problem here, albeit not with a DVD drive.

After mounting anything with the loopback device (I know it's not working
that well in 2.4.2) all future mounts of my SCSI writer and SCSI cdrom don't 
even return a prompt. The mount just 'hangs' and the mount process can't be killed 
either.

> So I did the mount -t udf /dev/hdb /mnt/dvd again, same thing happens
> again-the computer froze with the DVD light on.
> I read in the book "Running Linux", the author said
> "If any errors or warnings occur while compiling, you cannot expect the
> resulting kernel to work correctly..." I'm wondering if it's because of the the
> warning I got during the process of compiling the image file-"pasting would not give 
>a valid
> preprocessing token" that the mount command fails.

No, probably not.

I used kgcc to compile the kernel, did not get any of the RH7 gcc warning messages
and still am left with a not-so-stable mount.

> Any kind of suggestions are appreciated..

Very much appreciated even ;)

regards,
Remco

-- 
Remco B. Brink  Norge-iNvest AS
Kung foohttp://www.norge-invest.com
PGP/GnuPG key at http://remco.xgov.net/rbb.pgp

panic("Oh boy, that early out of memory?");
2.2.16 /usr/src/linux/arch/mips/mm/init.c
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.2 kernel mount crash

[Alan Cox]

> > During the "make bzImage"step, I got bunch of this warning:
> > "pasting would not give a valid preprocessing token". then I just ignored

The pasting warning is harmless

> The above message is related to the version of gcc that you get with
> your copy of RedHat7. You might just want to use kgcc instead of gcc
> to compile your kernel.

kgcc or gcc 2.96-69  (2.96-74 for DAC960 due to a structure packing assumption
in DAC960)

> I used kgcc to compile the kernel, did not get any of the RH7 gcc warning messages
> and still am left with a not-so-stable mount.

Its certainly worth building with kgcc as well to make sure, and in this case
it looks like the problem is really in the kernel proper

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

Kernel crash - reboot or hang

[Mircea Damian]

Hello,

I NEED TO TRACE THIS!!!

I had two crashes with 2.4.2 and 2.4.2-pre2 on my local SMTP/POP3/SAMBA/WWW
server (once under some load and the second one - with 2.4.2-pre2 - while
it was almost idle).

The machine is an HP Netserver LHII without the standard raid card that
comes with it (see bellow for dmesg output for a better description of
hardware).

I do not see any corruption nor any messages in logs.


Should I use kdb or just remote logging would do the job?


-- 
Mircea Damian
E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED]
WebPage: http://taz.mania.k.ro/~dmircea/


Linux version 2.4.3-pre2 (root@linux) (gcc version 2.95.2 19991024 (release)) #1 SMP 
Mon Mar 5 18:08:49 EET 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: eb0e @ 000f14f2 (reserved)
 BIOS-e820: 00e0 @ 0010 (usable)
 BIOS-e820: 0010 @ 00f0 (usable)
 BIOS-e820: 1f00 @ 0100 (usable)
 BIOS-e820: 1000 @ fec0 (reserved)
 BIOS-e820: 1000 @ fee0 (reserved)
 BIOS-e820: eb0e @ 14f2 (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
found SMP MP-table at 000fd8d0
hm, page 000fd000 reserved twice.
hm, page 000fe000 reserved twice.
hm, page 0009f000 reserved twice.
hm, page 000a reserved twice.
On node 0 totalpages: 131072
zone(0): 4096 pages.
zone(1): 126976 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: HP   Product ID: LH IIAPIC at: 0xFEE0
Processor #1 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
SEP present.
MTRR  present.
PGE  present.
MCA  present.
CMOV  present.
MMX  present.
Bootup CPU
Processor #0 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
SEP present.
MTRR  present.
PGE  present.
MCA  present.
CMOV  present.
MMX  present.
Bus #0 is PCI   
Bus #1 is PCI   
Bus #2 is EISA  
I/O APIC #2 Version 17 at 0xFEC0.
Int: type 3, pol 1, trig 1, bus 2, IRQ 00, APIC ID 2, APIC INT 00
Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01
Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02
Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03
Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04
Int: type 0, pol 0, trig 0, bus 2, IRQ 05, APIC ID 2, APIC INT 05
Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06
Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07
Int: type 0, pol 0, trig 0, bus 2, IRQ 08, APIC ID 2, APIC INT 08
Int: type 0, pol 0, trig 0, bus 2, IRQ 09, APIC ID 2, APIC INT 09
Int: type 0, pol 0, trig 0, bus 2, IRQ 0a, APIC ID 2, APIC INT 0a
Int: type 0, pol 0, trig 0, bus 2, IRQ 0b, APIC ID 2, APIC INT 0b
Int: type 0, pol 0, trig 0, bus 2, IRQ 0c, APIC ID 2, APIC INT 0c
Int: type 0, pol 0, trig 0, bus 2, IRQ 0d, APIC ID 2, APIC INT 0d
Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e
Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f
Lint: type 3, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 00
Lint: type 1, pol 1, trig 1, bus 0, IRQ 00, APIC ID ff, APIC LINT 01
Processors: 2
mapped APIC to e000 (fee0)
mapped IOAPIC to d000 (fec0)
Kernel command line: auto BOOT_IMAGE=Linux ro root=802
Initializing CPU#0
Detected 300.694 MHz processor.
Console: colour VGA+ 80x30
Calibrating delay loop... 599.65 BogoMIPS
Memory: 512764k/524288k available (1348k kernel code, 11136k reserved, 522k data, 208k 
init, 0k highmem)
Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0080fbff  , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0080fbff   
CPU: After generic, caps: 0080fbff   
CPU: Common caps: 0080fbff   
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0080fbff  , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check reporting enabled on CPU#0

Re: 2.4.2 kernel mount crash

[Remco B. Brink]

Alan Cox <[EMAIL PROTECTED]> writes:

> > I used kgcc to compile the kernel, did not get any of the RH7 gcc warning messages
> > and still am left with a not-so-stable mount.
> 
> Its certainly worth building with kgcc as well to make sure, and in this case
> it looks like the problem is really in the kernel proper

Actually the mount process behaves in exactly the same way as my emacs process
as mentioned in an earlier post (topic: "process with connection in CLOSE_WAIT won't 
die in 2.4.2").

It'll stay in the proceslist regardless of what kill signal is sent to it
and appears to be (and very much _stay_) in un-interuptable sleep.

The same can be said for the various mount processes, both when mounting
loopback and scsi devices.

Another thing that struck me as weird was that after all the problems
with the mount and emacs process, trying to unmount a NFS share was not
possible even though the NFS server had no problems whatsoever mounting
new shares.

regards,
Remco

-- 
Remco B. Brink  Norge-iNvest AS
Kung foohttp://www.norge-invest.com
PGP/GnuPG key at http://remco.xgov.net/rbb.pgp

In most countries selling harmful things like drugs is punishable.
Then howcome people can sell Microsoft software and go unpunished?
(By [EMAIL PROTECTED], Hasse Skrifvars)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.2.18 corruption: IDE + PCMCIA ?

[Magnus Damm]

Hi all,

I've experienced some disk corruption on my laptop.

Scenario:
I'm cross-compiling tons of sources and I felt the need
to insert a CompactFlash card (via PCMCIA) in my laptop.
So I did, no problem: 
mounted, touched a file, umounted, cardctl-ejected.

Pretty soon my compilation stops:
bash: /usr/bin/sort: cannot execute binary file

Okey. The date on /usr/bin/sort is unchanged. Must be root to write.
I am NOT compiling as root. 
"File" on /usr/bin/sort says "data". No elf.
The only thing that the logs say:

modprobe: Can't locate module binfmt-464c

The filesystem on /usr is ext2.

I downloaded a new textutils.deb and installed it.
(But I made a backup of the corrupted file for some reason)
Searched the net and found some previous problem with
2.2.10 and DMA + CompactFlash.
Started to write a mail like this. 
Tried to do a ls -> Segmentation fault.
Then the entire machine crashed.
I rebooted the machine and fsck.ext2 complained about
my largest partition, did a manual check and now I'm back.

I wonder how many corrupted files there are left...

The machine is usually very stable, but I haven't done
much PCMCIA activity with it.

Maybe this is not even related to PCMCIA...

Anyway, this is what I do to my disk/controller:

/sbin/hdparm -c1 -d1 -m16 -a0 -S4 -u1 /dev/hda

I don't know if that has anything to do with it.

I've used this computer about three months now
and another Portege (3440CT) six months.
Never experienced anything like that...

So, all Portege users out there - be careful!

Cheers /

Magnus


Software:

linux-2.2.18
pcmcia-cs-3.1.23

Hardware:

Toshiba Portege 3480CT:

CPU and memory:

600MHz Speedstep PII 
192MByte ram.

Harddisk and controller:

PCI_IDE: unknown IDE controller on PCI bus 00 device 39, VID=8086,
DID=7199
PCI_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xbff0-0xbff7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xbff8-0xbfff, BIOS settings: hdc:pio, hdd:pio
hda: TOSHIBA MK1214GAP, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: TOSHIBA MK1214GAP, 11513MB w/0kB Cache, CHS=1467/255/63, UDMA

Pcmcia/pccard:

Linux PCMCIA Card Services 3.1.23
  kernel build: 2.2.18 #2 Mon Jan 15 23:56:28 CET 2001
  options:  [pci] [cardbus] [apm]
PCI routing table version 1.0 at 0xf0190
  00:0b.0 -> irq 11
  00:0b.1 -> irq 11
Intel PCIC probe: 
  Toshiba ToPIC100 rev 20 PCI-to-CardBus at slot 00:0b, mem 0x6800
host opts [0]: [slot 0xf0] [ccr 0x16] [cdr 0x86] [rcr 0xc00]
[pci irq 11] [lat 64/176] [bus 20/20]
host opts [1]: [slot 0xf0] [ccr 0x26] [cdr 0x86] [rcr 0xc00]
[pci irq 11] [lat 64/176] [bus 21/21]

Compact Flash:

hdc: Hitachi CV 7.2.2, ATA DISK drive
hdc: Hitachi CV 7.2.2, 30MB w/1kB Cache, CHS=492/4/32
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Question: fs meta data, page cache and locking

[Anton Altaparmakov]

It was suggested to repost the below as a new thread and to cc: linux-fsdevel.

Any comments would be appreciated.

TIA,
 Anton

So here goes:

At 12:41 08/03/01, Ingo Oeser wrote:
> > On Thu, Mar 08, 2001 at 11:39:27AM +, Anton Altaparmakov wrote:
>[snip, attributions lost]
> > > > >+ * During disk I/O, PG_locked is used. This bit is set before I/O
> > > > >+ * and reset when I/O completes. page->wait is a wait queue of all
> > > > >+ * tasks waiting for the I/O on this page to complete.
>[snip]
> > When the NTFS file system driver needs to modify the meta data,
> > which will be in the page cache (meta data is stored in normal files on
> > NTFS, hence the page cache is very well suited to storing it with it's
> > page->mapping and page->index fields), does the NTFS driver need to set
> > PG_locked while writing to the page?
>[snip]
>May be you should raise these issues again under a separate
>subject and CC [EMAIL PROTECTED] for this.
>
>I think it is worth it, because Linus want all fs to use page
>cache for meta data and let buffer cache die slowly.
>
>Basically the rules go like this:
>
>The VM will wait for PG_locked pages, before it accesses them or
>ignore them, if it cannot wait.
>
>It will also try to read in pages, that are not PG_uptodate.
>
>But user space will never see metadata pages anyway, so you
>should be the only one, who cares about them. Just be prepared to
>writepage() and readpage() and the like.
>
>Just use lock_page() if you can sleep and TryLockPage() + EFAULT
>(or similar) if you cannot.
>
>Then just check Page_Uptodate() before you read and do
>ClearUptodate() if you start writing to the metadata.
>
>Since these operations are atomic bit operations, it should
>suffice for your purpose.
>
>But as stated above, I'm not very sure that I understand all the
>code and know of all the races.
>
>Multiple readers are AFAICS not yet possible with the current page
>cache.
>
>Regards
>
>Ingo Oeser
>--
>10.+11.03.2001 - 3. Chemnitzer LinuxTag 
>     come and join the fun   




-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

Can't use high IRQs on ISA ethernet card

[Jules Bean]

Hi,

I just had a weird and frustrating experience trying to get an
ethernet card to work. I think the problem lies in the kernel's IRQ
handling, which is why I'm reporting it here.  I'll try to think of al 
lthe relevenat details, but it's been one of those mornings consisting 
of much rebooting, and I may forget something:

My machine is an AMD k6-2 500 using a gigabyte motherboard with an
aladdin 5 chipset.  FWIW, dmesg says:

Serial Number SYS-9876543210.
Board Vendor: GA. INC..
Board Name: ALADDIN5.
Board Version: VER:1.0.
Asset Tag: ASS-9876543210.
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 78
PCI: No IRQ known for interrupt pin A of device 00:0f.0.
ALI15X3: chipset revision 194
ALI15X3: not 100% native mode: will probe irqs later

Oh, and I'm using the debian source package of 2.4.0.

The ethernet card concerned has definitely worked many times in the
past, but it wasn't working this monring.  It's a long time since I
last used it, so I can't quite remember for sure what's changed since
them, but I'm almost 100% no new hardware has gone into the machine
apart from a CD writer. The internal modem may be new, though.

As I say, the card is ISA.  The symptoms of it not working were as
follows: It's on a 2-node BNC network with a win98 laptop.  The win98
ethernet is known good, I think. Running a 'ping' (or anything else)
from the linux end resulted in the activity light on the laptop's
adapter flashing, but no response. tcpdump indicates that arp requests 
are being sent, but no reply is being heard.

Conversely, running a ping from the win98 end also flashes the light,
but tcpdump show nothing at all.

I'm pretty sure that the linux ethernet card was capable of sending,
but not receiving. (I.e. it wasn't seeing the ARp reply, so it wasn't
even getting to the ICMP stage). Furthermore, /proc/interrupts
revealed that it wasn't getting any interrupts. Donald Becker's
3c5x9.c program said that the card had unprocessed interrupts (sorry,
I didn't save the message) which it indicated shold never happen.

Sounds like an IRQ conflict, right?

Well, it was.  But what's weird is that the /only/ IRQ it will work on 
is 5. I tried everything from 9 to 13, with no luck.  Now it was
originally on 10, but 10 might conceivably conflict with my PCI bus.
9, however, I'm pretty sure doesn't conflict with anything, and 9
definitely didn't work. [Incidentally, I did go into the BIOS and
assign 9 to 'ISA/EISA' instead of 'PCI/PnP', but that didn't help; I
don't think it's necessary since I haven't done that for IRQ 5 and it
works now].

I know for a fact that when I last had this card working, it was on
IRQ 12.  I am sure about this because I remember having to move it to
a different IRQ when I got a PS/2 mouse for the first time a few weeks 
ago. At that point I moved the ethernet card to IRQ 10, but didn't
bother to check if it worked.

I don't think it's the card at fault because, before I thought of
trying IRQ 5, I switched to a different card -- a simple cheap ne2000
compatible. (Also known to definitely work in the past). It's with the 
ne2000 compatible that I finally tried IRQ 5, and when that worked, I
switched back to the 3c509 (trying to be scientific) and that worked
on IRQ 5, as well.

So, in summary, what seems to me to be happening is that the high IRQs 
(9-13, say) appear to be unavailable for use by ISA cards on my
machine, at the moment.  The kernel allows ISA cards to claim these
IRQs (and the cards then show up in /proc/interrupts) but they don't
actually seem to get the interrupts.  I don't know if the BIOS is
stealing them, or the kernel, or what.

I tried with 2.2.14 (which is what I mainly used until I bit the
bullet and upgraded to 2.4.0), and it also has the same problem.
Which is weird; I'm pretty sure I've had this card working on high
numbered IRQs under some 2.2.x kernel, although I couldn't be sure
which.

Sorry for the length of the message.  The problem is no longer
inconveniencing me (IRQ 5 is fine) but I thought it might be relevant
or interesting to someone.  If it isn't just a stupid hardware
conflict.

Yours,

Jules Bean

(cc: me on any replies you want me to see)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Microsoft begining to open source Windows 2000?

[Venkatesh Ramamurthy]

Please check out this article. Looks like microsoft know open source is the
thing of the future. I would consider that it is a begining step for full
blown GPL

http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

/dev/poll patch for 2.4

[Mathieu Dube]

Hi,
Somebody asked me for that patch it might need some tweaking, adding
#include  somewhere


-- 
Mathieu Dube
Mondo-Live  
www.flipr.com


diff -urP linux-2.4.0/drivers/char/Config.in 
linux-2.4.0-devpoll/drivers/char/Config.in
--- linux-2.4.0/drivers/char/Config.in  Fri Dec 29 14:07:21 2000
+++ linux-2.4.0-devpoll/drivers/char/Config.in  Mon Jan 29 16:24:42 2001
@@ -156,6 +156,7 @@
 
 dep_tristate 'Intel i8x0 Random Number Generator support' CONFIG_INTEL_RNG 
$CONFIG_PCI
 tristate '/dev/nvram support' CONFIG_NVRAM
+tristate '/dev/poll support' CONFIG_DEVPOLL
 tristate 'Enhanced Real Time Clock Support' CONFIG_RTC
 if [ "$CONFIG_IA64" = "y" ]; then
bool 'EFI Real Time Clock Services' CONFIG_EFI_RTC
diff -urP linux-2.4.0/drivers/char/Makefile linux-2.4.0-devpoll/drivers/char/Makefile
--- linux-2.4.0/drivers/char/Makefile   Thu Jan  4 13:00:55 2001
+++ linux-2.4.0-devpoll/drivers/char/Makefile   Mon Jan 29 16:24:42 2001
@@ -181,6 +181,7 @@
 obj-$(CONFIG_60XX_WDT) += sbc60xxwdt.o
 obj-$(CONFIG_WDT) += wdt.o
 obj-$(CONFIG_WDTPCI) += wdt_pci.o
+obj-$(CONFIG_DEVPOLL) += devpoll.o
 obj-$(CONFIG_21285_WATCHDOG) += wdt285.o
 obj-$(CONFIG_977_WATCHDOG) += wdt977.o
 obj-$(CONFIG_I810_TCO) += i810-tco.o
diff -urP linux-2.4.0/drivers/char/devpoll.c 
linux-2.4.0-devpoll/drivers/char/devpoll.c
--- linux-2.4.0/drivers/char/devpoll.c  Wed Dec 31 16:00:00 1969
+++ linux-2.4.0-devpoll/drivers/char/devpoll.c  Tue Jan 30 05:40:19 2001
@@ -0,0 +1,754 @@
+/*
+ * /dev/poll
+ * by Niels Provos <[EMAIL PROTECTED]>
+ *
+ * provides poll() support via /dev/poll as in Solaris.
+ *
+ * Linux 2.3/2.4 port by Michal Ostrowski
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+/*#define DEBUG 1 */
+#ifdef DEBUG
+#define DPRINTK(x) printk x
+#define DNPRINTK(n,x)  if (n <= DEBUG) printk x
+#else
+#define DPRINTK(x)
+#define DNPRINTK(n,x)
+#endif
+
+/* Various utility functions */
+
+#define DEFAULT_POLLMASK (POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM)
+
+/* Do dynamic hashing */
+
+#define INITIAL_BUCKET_BITS 6
+#define MAX_BUCKET_BITS 16
+#define RESIZE_LENGTH  2
+
+
+static void free_pg_vec(struct devpoll *dp);
+
+
+/* Initalize the hash table */
+
+int
+dp_init(struct devpoll *dp)
+{
+   int i;
+   int num_buckets;
+   DNPRINTK(3,(KERN_INFO "/dev/poll: dp_init\n"));
+
+   dp->dp_lock = RW_LOCK_UNLOCKED;
+   dp->dp_entries = 0;
+   dp->dp_max = 0;
+   dp->dp_avg = dp->dp_count = 0;
+   dp->dp_cached = dp->dp_calls = 0;
+   dp->dp_bucket_bits = INITIAL_BUCKET_BITS;
+   dp->dp_bucket_mask = (1 << INITIAL_BUCKET_BITS) - 1;
+
+   num_buckets = (dp->dp_bucket_mask + 1);
+   dp->dp_tab = kmalloc(num_buckets * sizeof(struct list_head),
+GFP_KERNEL);
+
+   if (!dp->dp_tab)
+   return -ENOMEM;
+
+   for (i = 0; i < num_buckets ; i++) {
+   INIT_LIST_HEAD(&dp->dp_tab[i]);
+   }
+
+   return (0);
+}
+
+int
+dp_resize(struct devpoll *dp)
+{
+   u_int16_t new_mask, old_mask;
+   int i;
+   struct list_head *new_tab, *old_tab;
+   struct dp_fd *dpfd;
+   unsigned long flags;
+   int num_buckets;
+
+   old_mask = dp->dp_bucket_mask;
+   new_mask = (old_mask + 1) * 2 - 1;
+   num_buckets = new_mask + 1;
+
+   DPRINTK((KERN_INFO "/dev/poll: resize %d -> %d\n",
+old_mask, new_mask));
+
+   new_tab = kmalloc( num_buckets * sizeof(struct list_head), GFP_KERNEL);
+   if (!new_tab)
+   return -ENOMEM;
+
+   for (i = 0; i < num_buckets; i++) {
+   INIT_LIST_HEAD(&new_tab[i]);
+   }
+
+   old_tab = dp->dp_tab;
+
+   /* Rehash all entries */
+   write_lock_irqsave(&dp->dp_lock, flags);
+   for (i = 0; i <= old_mask; i++) {
+   while(!list_empty(&old_tab[i])){
+   dpfd = list_entry(old_tab[i].next,struct dp_fd,next);
+   list_del(&dpfd->next);
+   INIT_LIST_HEAD(&dpfd->next);
+   list_add(&dpfd->next,&new_tab[dpfd->pfd.fd & new_mask]);
+   }
+   }
+
+   dp->dp_tab = new_tab;
+   dp->dp_bucket_bits++;
+   dp->dp_bucket_mask = new_mask;
+   write_unlock_irqrestore(&dp->dp_lock, flags);
+
+   kfree (old_tab);
+
+   return (0);
+}
+
+int
+dp_insert(struct devpoll *dp, struct pollfd *pfd)
+{
+   struct dp_fd *dpfd;
+   u_int16_t bucket = pfd->fd & dp->dp_bucket_mask;
+   unsigned long flags;
+   struct file *file;
+
+   dpfd = kmalloc(sizeof(struct dp_fd), GFP_KERNEL);
+   if (!dpfd)
+   return -EN

Re: Microsoft begining to open source Windows 2000?

[Jesse Pollard]

Venkatesh Ramamurthy <[EMAIL PROTECTED]>:
> 
> Please check out this article. Looks like microsoft know open source is the
> thing of the future. I would consider that it is a begining step for full
> blown GPL
> 
> http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html

Not a chance. First your company must have at least 1500 licences and
you can't modify any code... which implies that you can't rebuild either...

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

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

Re: Kernel crash - reboot or hang

[Chris Mason]

On Thursday, March 08, 2001 04:17:23 PM +0200 Mircea Damian
<[EMAIL PROTECTED]> wrote:

> 
> Hello,
> 
> I NEED TO TRACE THIS!!!
> 
> I had two crashes with 2.4.2 and 2.4.2-pre2 on my local
> SMTP/POP3/SAMBA/WWW server (once under some load and the second one -
> with 2.4.2-pre2 - while it was almost idle).
> 
> The machine is an HP Netserver LHII without the standard raid card that
> comes with it (see bellow for dmesg output for a better description of
> hardware).
> 
> I do not see any corruption nor any messages in logs.
> 
> 
> Should I use kdb or just remote logging would do the job?

A serial console is probably your best bet.  You if your mail spool is on
reiserfs, you probably want to apply the dir fsync patch (included in
2.4.3pre and the latest ac stuff).

-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: 2.4.2-acX and reiserfs

[Chris Mason]

On Thursday, March 08, 2001 08:36:51 AM -0100 "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

> 
> I'm 99.9% certain that those patches referred to have been merged with the
> latest 2.4.2-acX, but just to make it 100% certain I'm asking this
> question. At www.namesys.com, the reiserfs website, I read:
> "Latest patch for linux-2.4.2 contains fixes for tail conversion bug,
> preallocated block leakage, object id sharing problem, dir fsync bug and
> other minor fixes/improvements."
> Have _all_ those fixes gone into the latest ac-patch? (I saw references to
> "tail conversion fixes" and "dir fsync bug" in Alan's Changelog, but I
> didn't find all of them so I'm not sure. :-)
> The reason of why I'm wondering is that I've been having serious trouble
> with reiserfs, and when I'm going for a new fresh installation I want to
> be 100% sure that all fixes have been merged.
> So I would really appreciate a confirmation that all fixes have been
> merged, so I won't have to worry. :-)

Alan has been really proactive at taking the critical bug fixes.  He has
all the tail conversion fixes and the dir fsync bug (as does linus).  So,
if you are having huge problems with reiserfs on the latest ac series,
please let us know.

The big reiserfs patch that was posted last week wasn't as clean as it
could have been, it has been broken up into smaller units, and the less
important stuff removed.  They'll probably post it again this week.

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

[David Weinehall]

On Mon, Mar 05, 2001 at 09:35:30PM -0500, Richard B. Johnson wrote:
> 
> Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
> in **MASSIVE** file-system destruction. I have (had) all SCSI
> disks, using the BusLogic controller.
> 
> There is something **MAJOR** going on BAD, BAD, BAD, even disks
> that were not mounted got trashed.
> 
> This is (was) a 400MHz SMP machine with 256 Mb of RAM. I don't
> know what else to say, since I have nothing to mount. I can
> "get back" but it will take several days. I have to install a
> minimum system then restore everything from tapes.
> 
> I   -- S T R O N G L Y -- suggest that nobody use this kernel with
> a BusLogic SCSI controller until this problem is fixed.
> 
> This is being sent from another machine, not on the list (actually
> from home where I am trying to see what happened -- I brought all
> 4 of my disks home). It looks like some kind of a loop. I have
> a pattern written throughout one of the disks.

Anything new on this? It sounds rather strange considering your
unmounted disks got trashed too, so either it's a problem with the
SCSI subsystem (or the driver; it might be a bug that got triggered
by something else) or some sort of hardware failure.

What kind of pattern was repeated on the disk, by the way? Maybe this
could shed some light unto what happened.


/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: scsi vs ide performance on fsync's

[Chris Mason]

On Wednesday, March 07, 2001 08:56:59 PM + "Stephen C. Tweedie"
<[EMAIL PROTECTED]> wrote:

> Hi,
> 
> On Wed, Mar 07, 2001 at 09:15:36PM +0100, Jens Axboe wrote:
>> On Wed, Mar 07 2001, Stephen C. Tweedie wrote:
>> > 
>> > For most fs'es, that's not an issue.  The fs won't start writeback on
>> > the primary disk at all until the journal commit has been acknowledged
>> > as firm on disk.
>> 
>> But do you then force wait on that journal commit?
> 
> It doesn't matter too much --- it's only the writeback which is doing
> this (ext3 uses a separate journal thread for it), so any sleep is
> only there to wait for the moment when writeback can safely begin:
> users of the filesystem won't see any stalls.

It is similar under reiserfs unless the log is full and new transactions
have to wait for flushes to free up the log space.  It is probably valid to
assume the dedicated log device will be large enough that this won't happen
very often, or fast enough (nvram) that it won't matter when it does happen.

> 
>> A barrier operation is sufficient then. So you're saying don't
>> over design, a simple barrier is all you need?
> 
> Pretty much so.  The simple barrier is the only thing which can be
> effectively optimised at the hardware level with SCSI anyway.
> 

The simple barrier is a good starting point regardless.  If we can find
hardware where it makes sense to do cross queue barriers (big raid
controllers?), it might be worth trying.

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

[PATCH] remove CONFIG_NCR885E from Configure.help

[Steven Cole]

It appears that use of CONFIG_NCR885E was removed in 2.4.2-ac2,
in Config.in and the Makefile in drivers/net.

If it really is the case that CONFIG_NCR885E is history, then it
should be history in Configure.help as well.

This patch, against 2.4.2-ac14, removes CONFIG_NCR885E from Configure.help.

Steven

--- linux/Documentation/Configure.help.orig Thu Mar  8 08:26:11 2001
+++ linux/Documentation/Configure.help  Thu Mar  8 08:43:36 2001
@@ -16511,16 +16511,6 @@
   whenever you want). If you want to compile it as a module, say M
   here and read Documentation/modules.txt.
 
-Symbios 53c885 (Synergy ethernet) support
-CONFIG_NCR885E
-  This is and Ethernet driver for the dual-function NCR 53C885
-  SCSI/Ethernet controller.
-
-  This driver is also available as a module called ncr885e.o ( = code
-  which can be inserted in and removed from the running kernel
-  whenever you want). If you want to compile it as a module, say M
-  here and read Documentation/modules.txt.
-
 National DP83902AV (Oak ethernet) support
 CONFIG_OAKNET
   Say Y if your machine has this type of Ethernet network card.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Microsoft begining to open source Windows 2000?

[Mohammad A. Haque]

On Thu, 8 Mar 2001, Venkatesh Ramamurthy wrote:

> Please check out this article. Looks like microsoft know open source is the
> thing of the future. I would consider that it is a begining step for full
> blown GPL
>
> http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html
> -

Feh. First, you need be a customer w/ 1500 licences. And then you're not
allowed to made modifications to the source.

This isn't really much different then what they were doing before.
(Paying look at the source code so you could write 'optimized' apps)


-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=

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

opening files in /proc, and modules

[Michael Rothwell]

How can I detect that open() has been called on a file in procfs that a
module provides? If I modprobe my module, open one or more if its proc
entries, then rmmod the module while the proc files are still open, then
the deletion of those entries is deferred. When I close the file(s), the
kernel oopses. I need to be able to detect open() and close() in order
to increment/decrement the reference count for my module, to prevent it
from being rmmoded when in use. Any tips?

Thanks! 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Microsoft begining to open source Windows 2000?

[Alan Cox]

> Please check out this article. Looks like microsoft know open source is the
> thing of the future. I would consider that it is a begining step for full
> blown GPL

Oh sure

Maybe 1200 people

"Users are prohibited from amending"

Sorry but Linus had > 1200 people able to modify his code in 1992

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

Re: Linux 2.4.3

[Richard B. Johnson]

On Thu, 8 Mar 2001, David Weinehall wrote:

> On Mon, Mar 05, 2001 at 09:35:30PM -0500, Richard B. Johnson wrote:
> > 
> > Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
> > in **MASSIVE** file-system destruction. I have (had) all SCSI
> > disks, using the BusLogic controller.
> > 
> > There is something **MAJOR** going on BAD, BAD, BAD, even disks
> > that were not mounted got trashed.
> > 
> > This is (was) a 400MHz SMP machine with 256 Mb of RAM. I don't
> > know what else to say, since I have nothing to mount. I can
> > "get back" but it will take several days. I have to install a
> > minimum system then restore everything from tapes.
> > 
> > I   -- S T R O N G L Y -- suggest that nobody use this kernel with
> > a BusLogic SCSI controller until this problem is fixed.
> > 
> > This is being sent from another machine, not on the list (actually
> > from home where I am trying to see what happened -- I brought all
> > 4 of my disks home). It looks like some kind of a loop. I have
> > a pattern written throughout one of the disks.
> 
> Anything new on this? It sounds rather strange considering your
> unmounted disks got trashed too, so either it's a problem with the
> SCSI subsystem (or the driver; it might be a bug that got triggered
> by something else) or some sort of hardware failure.
> 
> What kind of pattern was repeated on the disk, by the way? Maybe this
> could shed some light unto what happened.
> 

Here is the pattern: Repeated at 0x1000 intervals. It looks like
the first page of the kernel, matched here at 0x0010.

The "Unknown interrupt" text was a dead giveaway.


0010 FC B8 18 00 00 00 8E D8 8E C0 8E E0 8E E8 66 09 ..f.
00100010 DB 74 17 83 3D AC 53 25 00 00 74 26 0F 20 E0 0B .t..=.S%..t&. ..
00100020 05 AC 53 25 00 0F 22 E0 EB 18 BF 00 20 10 00 B8 ..S%..". ...
00100030 07 00 00 00 AB 05 00 10 00 00 81 FF 00 40 10 00 .@..
00100040 75 F2 B8 00 10 10 00 0F 22 D8 0F 20 C0 0D 00 00 u...".. 
00100050 00 80 0F 22 C0 EB 00 B8 5E 00 10 C0 FF E0 0F B2 ..."^...
00100060 25 30 02 10 C0 66 09 DB 74 05 6A 00 9D EB 5C 31 %0...f..t.j...\1
00100070 C0 BF F0 E8 23 C0 B9 50 76 27 C0 29 F9 F3 AA E8 #..Pv'.)
00100080 76 01 00 00 6A 00 9D BF 00 40 10 C0 B9 00 02 00 v...j@..
00100090 00 FC F3 A5 31 C0 B9 00 02 00 00 F3 AB 8B 35 28 1.5(
001000A0 42 10 C0 21 F6 75 18 66 81 3D 20 00 09 00 3F A3 B..!.u.f.= ...?.
001000B0 75 19 0F B7 35 22 00 09 00 81 C6 00 00 09 00 BF u...5"..
001000C0 00 48 10 C0 B9 00 02 00 00 F3 A5 C7 05 88 2C 21 .H,!
001000D0 C0 FF FF FF FF C7 05 80 2C 21 C0 03 00 00 00 9C ,!..
001000E0 58 89 C1 35 00 00 04 00 50 9D 9C 58 31 C8 25 00 X..5P..X1.%.
001000F0 00 04 00 74 79 C7 05 80 2C 21 C0 04 00 00 00 89 ...ty...,!..

00100100 C8 35 00 00 20 00 50 9D 9C 58 31 C8 51 9D 25 00 .5.. .P..X1.Q.%.
00100110 00 20 00 74 4A 31 C0 0F A2 A3 88 2C 21 C0 89 1D . .tJ1.,!...
00100120 90 2C 21 C0 89 15 94 2C 21 C0 89 0D 98 2C 21 C0 .,!,!,!.
00100130 09 C0 74 2B B8 01 00 00 00 0F A2 88 C1 80 E4 0F ..t+
00100140 88 25 80 2C 21 C0 24 F0 C0 E8 04 A2 82 2C 21 C0 .%.,!.$..,!.
00100150 80 E1 0F 88 0D 83 2C 21 C0 89 15 8C 2C 21 C0 0F ..,!,!..
00100160 20 C0 25 11 00 00 80 0D 22 00 05 00 EB 0D 51 9D  .%.".Q.
00100170 0F 20 C0 25 11 00 00 80 83 C8 02 0F 22 C0 E8 4F . .%"..O
00100180 00 00 00 FE 05 D1 01 10 C0 0F 01 15 7A 02 10 C0 z...
00100190 0F 01 1D 72 02 10 C0 EA 9E 01 10 C0 10 00 B8 18 ...r
001001A0 00 00 00 8E D8 8E C0 8E E0 8E E8 B8 18 00 00 00 
001001B0 8E D0 31 C0 0F 00 D0 FC 8A 0D D1 01 10 C0 80 F9 ..1.
001001C0 01 74 07 E8 78 B7 12 00 EB 05 E8 11 66 12 00 EB .t..x...f...
001001D0 FE 02 C6 05 86 2C 21 C0 00 0F 06 DB E3 9B DF E0 .,!.
001001E0 3C 00 74 0C 0F 20 C0 83 F0 04 0F 22 C0 C3 89 F6 <.t.. ."
001001F0 C6 05 86 2C 21 C0 01 DB E4 C3 8D 15 50 02 10 C0 ...,!...P...

00100200 B8 00 00 10 00 66 89 D0 66 BA 00 8E 8D 3D 00 A0 .f..f=..
00100210 23 C0 B9 00 01 00 00 89 07 89 57 04 83 C7 08 49 #.WI
00100220 75 F5 C3 8D B6 00 00 00 00 8D BC 27 00 00 00 00 u..'
00100230 00 54 FF D3 18 00 00 00 55 6E 6B 6E 6F 77 6E 20 .T..Unknown 
00100240 69 6E 74 65 72 72 75 70 74 0A 00 90 8D 74 26 00 interruptt&.
00100250 FC 50 51 52 06 1E B8 18 00 00 00 8E D8 8E C0 68 .PQR...h
00100260 38 02 10 C0 E8 B7 67 01 00 58 1F 07 5A 59 58 CF 8.g..X..ZYX.
00100270 00 00 FF 07 00 A0 23 C0 00 00 5F 04 80 11 21 C0 ..#..._...!.
00100280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00100290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
001002A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
001002B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
001002C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
001002D0 00 00 00 00 00 00 00 00 00 00 00

RE: Microsoft begining to open source Windows 2000?

[Venkatesh Ramamurthy]

My initial thought after seeing this article was that microsoft was testing
its waters on open sourcing. If i have 1500 licenses then i would get the
source. If i find any bug in thier source , i  would report to microsoft or
send a patch and they would put it in thier next version. Is this not the
same way Linux Kernel is developed?. Only thing microsoft does not want to
immediately go full open sourcing and get embarrased at the hands of linux
people.

> -Original Message-
> From: Alan Cox [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, March 08, 2001 11:06 AM
> To:   [EMAIL PROTECTED]
> Cc:   [EMAIL PROTECTED]
> Subject:  Re: Microsoft begining to open source Windows 2000?
> 
> > Please check out this article. Looks like microsoft know open source is
> the
> > thing of the future. I would consider that it is a begining step for
> full
> > blown GPL
> 
> Oh sure
> 
> Maybe 1200 people
> 
> "Users are prohibited from amending"
> 
> Sorry but Linus had > 1200 people able to modify his code in 1992
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] remove CONFIG_NCR885E from Configure.help

[Geert Uytterhoeven]

On Thu, 8 Mar 2001, Steven Cole wrote:
> It appears that use of CONFIG_NCR885E was removed in 2.4.2-ac2,
> in Config.in and the Makefile in drivers/net.
> 
> If it really is the case that CONFIG_NCR885E is history, then it
> should be history in Configure.help as well.

I'm still wondering whether there really are no other boards with a Sym53c885
than the Synergy PPC board (which is no longer supported).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

RE: Microsoft begining to open source Windows 2000?

[Mohammad A. Haque]

On Thu, 8 Mar 2001, Venkatesh Ramamurthy wrote:

> My initial thought after seeing this article was that microsoft was testing
> its waters on open sourcing. If i have 1500 licenses then i would get the
> source. If i find any bug in thier source , i  would report to microsoft or
> send a patch and they would put it in thier next version. Is this not the
> same way Linux Kernel is developed?. Only thing microsoft does not want to
> immediately go full open sourcing and get embarrased at the hands of linux
> people.
>

making a patch means you've modfied the source which you are not allowed
to do. The most you can do is report the bug through normal channels
(you dont even have priority in reporting bugs since you have the code).

at least _ANYONE_ was able to contribute to linux. not just people with
gobs of money. I'm not even gonna comment on the embarrasement bit. The
one consultant quoted in the article summed it pretty nicely.

Also notice that you're now paying MS so you can find their bugs. Very
nice.

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=

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

Re: opening files in /proc, and modules

[Brian Gerst]

Michael Rothwell wrote:
> 
> How can I detect that open() has been called on a file in procfs that a
> module provides? If I modprobe my module, open one or more if its proc
> entries, then rmmod the module while the proc files are still open, then
> the deletion of those entries is deferred. When I close the file(s), the
> kernel oopses. I need to be able to detect open() and close() in order
> to increment/decrement the reference count for my module, to prevent it
> from being rmmoded when in use. Any tips?
> 
> Thanks!

Really, the procfs needs a pointer to the module so it can do the
reference before calling the code in the module.

--

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: Microsoft begining to open source Windows 2000?

[Anton Altaparmakov]

At 16:04 08/03/01, Venkatesh Ramamurthy wrote:
>My initial thought after seeing this article was that microsoft was testing
>its waters on open sourcing. If i have 1500 licenses then i would get the
>source. If i find any bug in thier source , i  would report to microsoft or
>send a patch and they would put it in thier next version. Is this not the
>same way Linux Kernel is developed?. Only thing microsoft does not want to
>immediately go full open sourcing and get embarrased at the hands of linux
>people.

You are not reading the article carefully enough.

With Linux, everyone is free to make their own changes which suit their 
particular setup, recompile the kernel, and run their own linux kernel on 
their site / server / workstation / whatever.

Microsoft specifically forbids this in their license!

It is a "look but don't touch" license which is as far away from the ideas 
of the GPL as you can possibly get.

Even submitting them a patch is technically violating their license as a 
patch implies that you have modified their code already, which is forbidden!

The only change from before that I can see is that Microsoft is going to 
make even more money now, because they will collect the money from ~1000 
instead of ~10 people. No other news there.

Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

RE: Microsoft begining to open source Windows 2000?

[Rik van Riel]

On Thu, 8 Mar 2001, Venkatesh Ramamurthy wrote:

> Only thing microsoft does not want to immediately go full open
> sourcing and get embarrased at the hands of linux people.

They don't need to release their source code to achieve that.

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

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

Re: opening files in /proc, and modules

[Michael Rothwell]

Figured it out -- I think. This appears to be the answer:

In struct proc_dir_entry,set the fill_inode function pointer to a
callback to handle refcounts.

struct proc_dir_entry
{
...
void (*fill_inode)(struct inode *, int);
...
};


void fill_inode_cb(struct inode *i, int v)
{
 if (v==0)
 {
  MOD_DEC_USE_COUNT;
  return;
 };
 if (v==1)
 {
  MOD_INC_USE_COUNT;
  return;
 };
};


... right?  :)


On 08 Mar 2001 11:01:28 -0500, Michael Rothwell wrote:
> How can I detect that open() has been called on a file in procfs that a
> module provides? If I modprobe my module, open one or more if its proc
> entries, then rmmod the module while the proc files are still open, then
> the deletion of those entries is deferred. When I close the file(s), the
> kernel oopses. I need to be able to detect open() and close() in order
> to increment/decrement the reference count for my module, to prevent it
> from being rmmoded when in use. Any tips?
> 
> Thanks! 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: Questions about Enterprise Storage with Linux

[james rich]

On Thu, 8 Mar 2001, Jesse Pollard wrote:

> james rich <[EMAIL PROTECTED]>:
> > On Wed, 7 Mar 2001, Tom Sightler wrote:
> > 
> > > 2.  Does linux have any problems with large (500GB+) NFS exports, how about
> > > large files over NFS?
> > > 
> > > 3.  What filesystem would be best for such large volumes?  We currently use
> > > reirserfs on our internal system, but they generally have filesystems in the
> > > 18-30GB ranges and we're talking about potentially 10-20x that.  Should we
> > > look at JFS/XFS or others?
> > 
> > I think that for filesystems this size you definately want to look at XFS
> > of JFS.  Maybe you will decide not to use them - but you should test them.
> > 
> > I am currently using XFS and it really works.  It currently has some
> > issues when used with raid 1, but it is probably the most suited for what
> > you want.  Exporting an XFS volume over NFS is no problem.  You can also
> > use xfs_growfs to change the size of your XFS partition.  I haven't had
> > any instability during all the time I've used XFS.
> 
> The biggest difficulty I had with XFS (not on linux as a server) had
> more to do with NFS/XFS performance. The SGI clients worked fine while
> the Linux clients were about 10-20% slower. This was a year ago so this
> may not apply anymore. I haven't seen any Linux NFS benchmarks recently.

Recent changes in CVS appear to have resolved this issue.

James Rich
[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: opening files in /proc, and modules

[Alexander Viro]

On 8 Mar 2001, Michael Rothwell wrote:

> Figured it out -- I think. This appears to be the answer:
> 
> In struct proc_dir_entry,set the fill_inode function pointer to a
> callback to handle refcounts.
> 
> struct proc_dir_entry
> {
> ...
> void (*fill_inode)(struct inode *, int);
> ...
> };
[snip]
> ... right?  :)

Right for 2.2, wrong for 2.4. There you just set ->owner to THIS_MODULE
and forget about the whole mess with callbacks.
Cheers,
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: opening files in /proc, and modules

[Michael Rothwell]

Sweet! Thanks!

I'm working on 2.2 for now, but the 2.4 API looks nicer... :)

-M

On 08 Mar 2001 11:43:24 -0500, Alexander Viro wrote:
> 
> 
> On 8 Mar 2001, Michael Rothwell wrote:
> 
> > Figured it out -- I think. This appears to be the answer:
> > 
> > In struct proc_dir_entry,set the fill_inode function pointer to a
> > callback to handle refcounts.
> > 
> > struct proc_dir_entry
> > {
> > ...
> > void (*fill_inode)(struct inode *, int);
> > ...
> > };
> [snip]
> > ... right?  :)
> 
> Right for 2.2, wrong for 2.4. There you just set ->owner to THIS_MODULE
> and forget about the whole mess with callbacks.
>   Cheers,
>   Al

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

crashes if accassing FAT MO

[Tino Keitel]

Hi folks,

I use kernel 2.4.2. If I try to access files on a 640 MB MO (2048 bytes
hardware sector size) and the MO is using FAT fs I only got messages
like these:

Unable to handle kernel NULL pointer dereference at virtual address

 printing eip:

*pde = 
Oops: 
CPU:0
EIP:0010:[<>]
EFLAGS: 00010286
eax:    ebx: c798d740   ecx: 0003   edx: c798d740
esi: ffea   edi:    ebp: 4000   esp: c576bf88
ds: 0018   es: 0018   ss: 0018
Process cat (pid: 458, stackpage=c576b000)
Stack: cc993428 c798d740 0804b220 4000 c798d760 c012d465 c798d740
0804b220
   4000 c798d760 c576a000 4000 0804b220 b994 c0108d43
0003
   0804b220 4000 4000 0804b220 b994 0003 002b
002b
Call Trace: [] [] []

Code:  Bad EIP value.
Segmentation fault

There are no problems if I use ext2fs, exept that I can't use them for
data exchange with Windows. It also works with 2.2 kernels but the MO
drive will be much slower.

Tino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Microsoft begining to open source Windows 2000?

[Wayne . Brown]

No, the Linux way is to send the patch to everyone else who's developing or
testing the kernel.  Even if Linus doesn't accept it into the "official" kernel,
there's nothing to stop you (or anyone else) from using it yourself or
distributing it to others.  The Microsoft agreement prevents you from changing
the source, and if they decide to ignore your bug report, there's nothing you
can do about it.  Oh, and you have to pay (at least 1500 licenses' worth) for
the "privilege" of doing their debugging work for them.  That's about as far
from the Linux way of doing things as you can get.

Wayne




Venkatesh Ramamurthy <[EMAIL PROTECTED]> on 03/08/2001 10:04:25 AM

To:   'Alan Cox' <[EMAIL PROTECTED]>
cc:   [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec)

Subject:  RE: Microsoft begining to open source Windows 2000?



My initial thought after seeing this article was that microsoft was testing
its waters on open sourcing. If i have 1500 licenses then i would get the
source. If i find any bug in thier source , i  would report to microsoft or
send a patch and they would put it in thier next version. Is this not the
same way Linux Kernel is developed?. Only thing microsoft does not want to
immediately go full open sourcing and get embarrased at the hands of linux
people.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] remove CONFIG_NCR885E from Configure.help

[David Weinehall]

On Thu, Mar 08, 2001 at 08:52:20AM -0700, Steven Cole wrote:
> It appears that use of CONFIG_NCR885E was removed in 2.4.2-ac2,
> in Config.in and the Makefile in drivers/net.
> 
> If it really is the case that CONFIG_NCR885E is history, then it
> should be history in Configure.help as well.
> 
> This patch, against 2.4.2-ac14, removes CONFIG_NCR885E from Configure.help.
> 
> Steven
> 
> --- linux/Documentation/Configure.help.orig Thu Mar  8 08:26:11 2001
> +++ linux/Documentation/Configure.help  Thu Mar  8 08:43:36 2001
> @@ -16511,16 +16511,6 @@
>whenever you want). If you want to compile it as a module, say M
>here and read Documentation/modules.txt.
>  
> -Symbios 53c885 (Synergy ethernet) support
> -CONFIG_NCR885E
> -  This is and Ethernet driver for the dual-function NCR 53C885

Oh, and if this entry stays, s/and/an/

> -  SCSI/Ethernet controller.
> -
> -  This driver is also available as a module called ncr885e.o ( = code
> -  which can be inserted in and removed from the running kernel
> -  whenever you want). If you want to compile it as a module, say M
> -  here and read Documentation/modules.txt.
> -
>  National DP83902AV (Oak ethernet) support
>  CONFIG_OAKNET
>Say Y if your machine has this type of Ethernet network card.


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

nfs mount result in invalid operand:000 (on 386 only)

[Mr. Jerome Corre]

Hi, I have recently been given an old 386 PC, I haven't got a hard disk 
for it, just a floppy and a network card, so I decided to create a boot 
disk for it, and then using nfs connect to one of my two pentium (which 
run RedHat 6.2) and work like that. I made a boot disk and with the 
linux 6.2 kernel and a root image, I tested on one of my pentium with the 
other pentium as an nfs server, it is working fine. However when i tryed 
it on the 386 things started to go wrong: 
1- when the kernel was booting i was getting: Checking if this processor 
honours the WP bit even in supervisor mode... No. Kernel panic: This 
Kernel doesn't support CPU's with broken WP. Recompile it for a 386! 
In swapper task - not syncing so i recompiled the kernel as explained in 
Kernel Howto and enable 386 support 
2- Now the kernel boot on the 386 but when i try to use mount to 
connect to the nfs server I get invalid operand: 000. Using strace i had a 
closer look to find out at what point mount was buging here is what i am 
getting: .
mount("boggus:/home/export", "/mnt/temp/", "nfs", 0xc0ed, 
0x8057660) = -1 ENOSYS mount("boggus:/home/export", 
"/mnt/temp/", "nfs", 0xc0ed, 0x8057660invalid operand:  
I have to say I don't know what to do now? did somebody solve that 
problem before? what else can i try to do to find out where the problem 
is comming from? thanks for any help regards 
Jerome 

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

[OT] Re: Microsoft begining to open source Windows 2000?

[Stuart MacDonald]

From: "Venkatesh Ramamurthy" <[EMAIL PROTECTED]>
> http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html

"As such, clients will not be allowed to alter the code in any form and
may not give any other party access to any aspect of that code."

Does this preclude one reading the source and then using
the knowledge gained to write, independently, working
modules for Linux; fixing the fs problems for instance?

Does anyone on the list have access to the code?

It seems to me this might be an opportunity...

..Stu


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Can't use high IRQs on ISA ethernet card

[john slee]

On Thu, Mar 08, 2001 at 02:51:42PM +, Jules Bean wrote:
> So, in summary, what seems to me to be happening is that the high IRQs
> (9-13, say) appear to be unavailable for use by ISA cards on my
> machine, at the moment.  The kernel allows ISA cards to claim these
> IRQs (and the cards then show up in /proc/interrupts) but they don't
> actually seem to get the interrupts.  I don't know if the BIOS is
> stealing them, or the kernel, or what.

my beloved gravis ultrasound classic (ISA, non-pnp) works fine in 2.2.x
and 2.4.x, with io=0x260 irq=11 dma=7.  *hug gravis*

also my dec etherworks3 (different machine) seems to be working
perfectly well in 2.2.x with irq 10, haven't had sufficient spare time
to try it in 2.4 yet...

do you smell a hardware bug?

j.

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

RE: ACPI:system description tables not found.

[David Christensen]

Stephen,

Is there a BIOS setup option for enabling ACPI?  Make sure it is enabled.
Also attach a copy of the E820 output from dmesg.

David Christensen

> I am using kernel-2.4.2-ac12 (will try ac14). The motherboard is a
> Supermicro P6DBU. (I will need to check the board when I get home to
> confirm). I get the messages below when the system starts:
>
> acpi: system description tables not found
>
> The manufacturer says that there is support for acpi. So I willing to beat
> it around a bit to get the tables found. Any ideas where to start?
>
> Stephen
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Microsoft begining to open source Windows 2000?

[James A. Sutherland]

On Thu, 8 Mar 2001, Anton Altaparmakov wrote:

> At 16:04 08/03/01, Venkatesh Ramamurthy wrote:
> >My initial thought after seeing this article was that microsoft was testing
> >its waters on open sourcing. If i have 1500 licenses then i would get the
> >source. If i find any bug in thier source , i  would report to microsoft or
> >send a patch and they would put it in thier next version. Is this not the
> >same way Linux Kernel is developed?. Only thing microsoft does not want to
> >immediately go full open sourcing and get embarrased at the hands of linux
> >people.
>
> You are not reading the article carefully enough.
>
> With Linux, everyone is free to make their own changes which suit their
> particular setup, recompile the kernel, and run their own linux kernel on
> their site / server / workstation / whatever.
>
> Microsoft specifically forbids this in their license!

Yes. It's a pretty crappy license - but still beats the previous one (if
you want to worship our almighty code, hand over your firstborn. Oh, and
leave your brain with us for safekeeping, and you're not allowed to do any
programming ever again, except for us.)

> It is a "look but don't touch" license which is as far away from the ideas
> of the GPL as you can possibly get.

Is it? Going from "totally closed" to "we might let you see the code if
you grovel" is a step in the right direction, at least.

> Even submitting them a patch is technically violating their license as a
> patch implies that you have modified their code already, which is forbidden!

Hmm... Perhaps. I doubt they'd object, particularly if the patch worked :P

> The only change from before that I can see is that Microsoft is going to
> make even more money now, because they will collect the money from ~1000
> instead of ~10 people. No other news there.

They do already license the source to a few trusted companies (Executive
Software used to ship modified NTFS drivers for NT 3.51 as part of
Diskeeper, IIRC). They are inching ever so slowly towards letting human
beings (cf MS drones) read their code...


James.

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

Re: Linux 2.4.2ac12 (vt82c686 info)

[Wayne Whitney]

In mailing-lists.linux-kernel, you wrote:

> Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
> my drivers have little bugs in the 686b support. Harmless but somewhat
> annoying.

Does this mean that the version 3.21 of your driver in the latest
2.4.2-acxx is newer than the version 4.3 that you distributed to the
LKML a couple weeks ago?

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: [OT] Re: Microsoft begining to open source Windows 2000?

[James A. Sutherland]

On Thu, 8 Mar 2001, Stuart MacDonald wrote:

> From: "Venkatesh Ramamurthy" <[EMAIL PROTECTED]>
> > http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html
>
> "As such, clients will not be allowed to alter the code in any form and
> may not give any other party access to any aspect of that code."
>
> Does this preclude one reading the source and then using
> the knowledge gained to write, independently, working
> modules for Linux; fixing the fs problems for instance?
>
> Does anyone on the list have access to the code?
>
> It seems to me this might be an opportunity...

They already license the Win2k bug's source to academic people without a
huge NDA attached (and without the non-compete clause prohibiting work on
other OSs!). There's a copy around here somewhere - I don't have access,
but know who does, and might be able to get a copy at some point...


James.

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

Re: [PATCH] RFC: fix ethernet device initialization

[Jes Sorensen]

> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:

Jeff> People from time to time point out a wart in ethernet
Jeff> initialization: The net_device is allocated and registered to
Jeff> the system in init_etherdev, which is usually one of the first
Jeff> things an ethernet driver probe function does.  The net_device's
Jeff> final members are setup at some time between then and the exit
Jeff> of the probe function.  There is never a clear point where the
Jeff> net device is available to the system for use.

I don't like the way you declare all the code in obscure macros in
there.

+#define DECLARE_CHG_MTU(suffix,low,high) \
+   static int suffix##_change_mtu(struct net_device *dev, int new_mtu) \
..

All it does is to make the code harder to read and debug for little/no
gain.

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

Re: [OT] Re: Microsoft begining to open source Windows 2000?

[rjd]

Stuart MacDonald wrote:
> 
> It seems to me this might be an opportunity...

Or a trap. I'm not about to go anywhere near this and won't even look at
the licience but I bet the M$ argument will go something like:

   You've looked at the code.
   You now know things that are propriatary to M$.
   You are not allowed to apply it to anything outside M$.
   Stop working on those free sources the forbidden knowledge might leak.
   You have me assimilated.


-- 
Bob Dunlop  [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: Q: explicit alignment control for the slab allocator

[Jes Sorensen]

> "Manfred" == Manfred Spraul <[EMAIL PROTECTED]> writes:

Manfred> First of all HW_CACHEALIGN aligns to the L1 cache, not
Manfred> SMP_CACHE_BYTES.  Additionally you sometimes need a
Manfred> guaranteed alignment for other problems, afaik ARM needs 1024
Manfred> bytes for some structures due to cpu restrictions, and
Manfred> several usb controllers need 16 byte alignment.

My question is whats the point in asking for L1_CACHE_BYTES alignment
for hardware reasons when you can't see it beyond the cache controller
anyway? Sure it makes sense for data structures only used by the CPU,
but for structures that are shared between CPUs or goes to DMA
controllers it seems to make little sense.

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

RE: ACPI:system description tables not found.

[Grover, Andrew]

> From: Stephen Torri [mailto:[EMAIL PROTECTED]]

> I am using kernel-2.4.2-ac12 (will try ac14). The motherboard is a
> Supermicro P6DBU. (I will need to check the board when I get home to
> confirm). I get the messages below when the system starts:
> 
> acpi: system description tables not found
> 
> The manufacturer says that there is support for acpi. So I 
> willing to beat
> it around a bit to get the tables found. Any ideas where to start?

download the pmtools package from
http://developer.intel.com/technology/iapc/acpi/downloads.htm . (It's at the
bottom.) The acpidmp utility is what you're interested in (you can ignore
compile errors from the others.) Does this utility find tables, or not?

Thanks -- Regards -- Andy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Microsoft begining to open source Windows 2000?

[Anton Altaparmakov]

At 17:36 08/03/2001, James A. Sutherland wrote:
>On Thu, 8 Mar 2001, Anton Altaparmakov wrote:
> > At 16:04 08/03/01, Venkatesh Ramamurthy wrote:
> > It is a "look but don't touch" license which is as far away from the ideas
> > of the GPL as you can possibly get.
>
>Is it? Going from "totally closed" to "we might let you see the code if
>you grovel" is a step in the right direction, at least.

It would be except there is no big change. Microsoft was already doing 
that, as you say below yourself, except that it is now broadening the 
number of people that are allowed to see the code.

> > Even submitting them a patch is technically violating their license as a
> > patch implies that you have modified their code already, which is 
> forbidden!
>
>Hmm... Perhaps. I doubt they'd object, particularly if the patch worked :P

Well, there is that of course. But if they wanted to, they could shoot you 
down for it in accordance with the license.

> > The only change from before that I can see is that Microsoft is going to
> > make even more money now, because they will collect the money from ~1000
> > instead of ~10 people. No other news there.
>
>They do already license the source to a few trusted companies (Executive
>Software used to ship modified NTFS drivers for NT 3.51 as part of
>Diskeeper, IIRC). They are inching ever so slowly towards letting human
>beings (cf MS drones) read their code...

Exactly my point. Only a slight change in numbers, nothing more, nothing less.

Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

Re: Elevator algorithm parameters

[LA Walsh]

I hate when that happens...

LA Walsh wrote:
> If you ask for code from me, it'll be a while -- My read and write
...Q's are rather full right now with some higher priority I/O...:-)
-l
-- 
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Elevator algorithm parameters

[LA Walsh]

I have a few comments/questions on the elv. alg. as it is now.  Some
of them may be based on a flawed understanding, but please be patient
anyway :-).

1) read-ahead is given the same 'latency' [max-wait priority] as 'read'
   I can see r-a as being less important than 'read' -- 'read' means
   some app is blocked waiting for input *now*.  'ra' -- means the
   kernel is being clever in hopes it is predicting a usage pattern where
   reading ahead will be useful.  I'd be tempted to give read-ahead
   a higher acceptable latency than reads and possibly higher than
   writes.  By definition, 'ra' i/o is i/o that no one currently has
   requested be done.
   a) the code may be there, but if a read request comes in for a
  sector marked for ra, then the latency should be set to 
  min(r-latency,remaining ra latency)

2) I seem to notice a performance boost for my laptop setting the
   read latency down to 1/8th of the write (2048/16384) instead of
   the current 1:2 ratio.  

   I am running my machine as a nfs server as well as doing local tasks
   and compiles.  I got better overall performance because nfs requests
   got serviced more quickly to feed a data-hungry dual-processor
   "compiler-server".  Also, my interactive processes which need
   lots of random reads perform better because they got 'fed' faster
   while some background data transfers (read and writes) of large
   streams of data were going on.

3) It seems that the balance of optimal latency figures would vary
   based on how many cpu-processes are blocked on data-reads, how many
   cpu's are reading from the same disk, the disk speed, the cpu speed
   and available memory for buffering.  Maybe there is a neat wiz-bang
   self-adjusting algorithm that can adapt dynamically to different
   loads (like say detects -- hmmm, we have 100 non mergable read 
   requests plugged, should I wait for more?...well only 1 active write
   request is runningmaybe I should lower the read latency...etc).
   However, in the interim, it seems having the values at least be
   tunable via /proc (rather than the current ioctl) would be useful --
   just able to echo some values into there @ runtime.  I couldn't
   seem to find such a beast in /proc.

Comments/cares?

If you ask for code from me, it'll be a while -- My read and write 
-- 
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Server tuning for maximum I/O performance...

[Fons Rademakers]

Hi Andrea,

   we are trying to build Linux disk servers. We have the following setup:

- L440GX+ intel mobo, 133MHz PCI bus
- 2 dual PIII 700 MHz, 512 MB ECC
- 2 system disks 15 GB mirrored in hw
- 20 data disks IBM 75 GB nominal datarate between 20 and 34 MB/s
  (seq accesses) used in 10 mirrored hw file systems
  thus ~ 750 GB available on each system
- Each disk has its own EIDE channel
- 3x 8 port 3ware 6800 boards (total 24 channels)
- 1 GB eth NIC
- kernel 2.2.18

The machines are used to receive large data files. When the local disks
get to full files are migrated to tape via a remote tape server. The
only processes running are several remote file I/O daemons to receive
the data from GB eth and several migration daemons to send the data
over GB eth to the tape servers (no interactive users or other processes
are running on these machines).

Operating in this setup we observe the following behaviour:

# write streams   # read streams write performance/stream (MB/s)

1 0  25
2 0  14.5
3 0  9.3
1 1  13.6
1 2  8.8
1 3  6.3
2 1  9.3
2 2  6.5
2 3  5.1

As you can see the write performance is severely reduced as soon as
a process starts reading. All write and read streams are to separate
spindles, never will a single disk server more than one stream.

Aggregate datarate for the whole box is only 30-40 MB/s from disk to
network or vice versa. Although network alone can go up to 60 MB/s (full
duplex) and disk alone goes up to 100 MB/s, combining the two drops to 
max 30-40 MB/s.

Are this numbers you expect from the Linux kernel? Are they compatible
with the current PC hardware architecture? To get better performance
what would you advice changing (software, hardware, tuning)?

Thanks for any suggestions.


Cheers, Fons.

-- 
Org:CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: [EMAIL PROTECTED]  Phone: +41 22 7679248
WWW:http://root.cern.ch/~rdm/Fax:   +41 22 7677910
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Microsoft begining to open source Windows 2000?

[Richard B. Johnson]

On Thu, 8 Mar 2001, Mohammad A. Haque wrote:

> On Thu, 8 Mar 2001, Venkatesh Ramamurthy wrote:
> 
> > My initial thought after seeing this article was that microsoft was testing
> > its waters on open sourcing. If i have 1500 licenses then i would get the
> > source. If i find any bug in thier source , i  would report to microsoft or
> > send a patch and they would put it in thier next version. Is this not the
> > same way Linux Kernel is developed?. Only thing microsoft does not want to
> > immediately go full open sourcing and get embarrased at the hands of linux
> > people.
> >
> 
> making a patch means you've modfied the source which you are not allowed
> to do. The most you can do is report the bug through normal channels
> (you dont even have priority in reporting bugs since you have the code).
> 
> at least _ANYONE_ was able to contribute to linux. not just people with
> gobs of money. I'm not even gonna comment on the embarrasement bit. The
> one consultant quoted in the article summed it pretty nicely.
> 
> Also notice that you're now paying MS so you can find their bugs. Very
> nice.

Of course Microsoft, being the industry leader and producer of
the world's most powerful operating system, could not possibly
have any bugs or even room for improvement. Therefore, revealing
their exquisite source code is only being done to educate those
who have not yet achieved Microsoft's pinnacle of perfection.

Sorry, I couldn't resist. FYI, I doubt that much actual code
will be revealed because this could open the door to many lawsuits
having to do with stolen intellectual property. Instead, they
will probably define some MACROS like:

START_OS();
RUN_OS();
STOP_OS();

These are just dummies. The most important is a callable procedure:

make_blue_screen_of_death();


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

OOPS with 2.4.2-ac12

[Gianluca Anzolin]

Hello,

I've been experiencing since 2.4.2-ac5 (I'm not sure about this) some
oops on one of my PCs: it's a Pentium Classic 166, 84 MB of RAM, kernel
2.4.2-ac12.

It works as a gateway (doing NAT) between my LAN and internet. I use a
ISDN card (Hisax HFC-PCI) and a NE2000 compatible nic (ne.c). I can't
reproduce the error, sometimes the box stays up without problems,
sometimes it crash a few minutes after rebooting.

I attach the ooops I get (written down by hand) decoded using ksymoops.

Gianluca


ksymoops 2.3.4 on i586 2.4.2-ac12.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.2-ac12/ (default)
 -m /boot/System.map-2.4.2-ac12 (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.

cpu: 0
eip: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
eflags: 00010246
eax: 1000 ebx:  ecx: 1000 edx:
esi: c4d876c0 edi: c4d10b80 ebp: 0050 esp: c020bde8
ds: 00180  es: 00180  ss: 0018
Process Swapper (pid: 0, stackpage=c020b000)
Stack: c019440d ff00 c4d876c0 c019494b c4d876c0 c4d876c0 c58362a0 c3f711a0
   c58362a0 c0197713 c4d876c0 0002 c2eef200 c4d876c0 c019a713 c4d876c0
   c4d876c0  0004 c01a462c c01a46a5 c4d876c0 0001 c58362a0
Call Trace: c019440d c019494b c58362a0 c58362a0 c0197713 c019a713 c01a462c
c01a46a5 c58362a0 c019c742 c58362a0 c01a1ddc c01a4612 c58362a0 c01a462c
c58362a0 c01a1e2a c019c742 c58362a0 c01a05dc c01a1d89 c58362a0 c01a1ddc
c01a10b8 c01a1219 c01a10b8 c019c742 c01a0f26 c01a10b8 c0197c6d c0115c70
c010a131 c0107120 c0108e20 c0107120 c0107143 c01071a7 c0105000 c0100191
Code: 8b 41 18 85 c0 7c 11 ff 49 14 0f 94 c0 84 c0 74 07 89 c8 e8

>>EIP; c0126de6 <__free_pages+2/1c>   <=
Trace; c019440d 
Trace; c019494b 
Trace; c58362a0 <[ne]__module_kernel_version+0/0>
Trace; c58362a0 <[ne]__module_kernel_version+0/0>
Trace; c0197713 
Trace; c019a713 
Trace; c01a462c 
Code;  c0126de6 <__free_pages+2/1c>
 <_EIP>:
Code;  c0126de6 <__free_pages+2/1c>   <=
   0:   8b 41 18  mov0x18(%ecx),%eax   <=
Code;  c0126de9 <__free_pages+5/1c>
   3:   85 c0 test   %eax,%eax
Code;  c0126deb <__free_pages+7/1c>
   5:   7c 11 jl 18 <_EIP+0x18> c0126dfe <__free_pages+1a/1c>
Code;  c0126ded <__free_pages+9/1c>
   7:   ff 49 14  decl   0x14(%ecx)
Code;  c0126df0 <__free_pages+c/1c>
   a:   0f 94 c0  sete   %al
Code;  c0126df3 <__free_pages+f/1c>
   d:   84 c0 test   %al,%al
Code;  c0126df5 <__free_pages+11/1c>
   f:   74 07 je 18 <_EIP+0x18> c0126dfe <__free_pages+1a/1c>
Code;  c0126df7 <__free_pages+13/1c>
  11:   89 c8 mov%ecx,%eax
Code;  c0126df9 <__free_pages+15/1c>
  13:   e8 00 00 00 00call   18 <_EIP+0x18> c0126dfe <__free_pages+1a/1c>


1 warning issued.  Results may not be reliable.

Re: Microsoft begining to open source Windows 2000?

[Jeff V. Merkey]

On Thu, Mar 08, 2001 at 05:53:08PM +, Anton Altaparmakov wrote:
> >
> >They do already license the source to a few trusted companies (Executive
> >Software used to ship modified NTFS drivers for NT 3.51 as part of
> >Diskeeper, IIRC). They are inching ever so slowly towards letting human
> >beings (cf MS drones) read their code...

Their code is tough to read due to the use of C++ constructs all through 
their architecture.  You can issue a request to some kernel component of 
NT only to have it raise a software exception that shows up somewhere else
in the kernel code.  Since they use structured excpetion handling all 
over the place, it takes a long time to make sense of just what is 
going on in large sections of their kernel.  Their architecture is 
much more flexible than Linux, but you pay the price in increased 
complexity.  The NWFS file system on W2K was an absolute nightmare
to write and debug, and I could not have done it without their source
code and David from MS helping.  

I'm more suprised they are even showing to customers.  It's so damn 
complex, most of the people they give it to won't be able to make
heads or tails of it.  Linux is a lot easier to read and follow.  The
licence they disclose it under is very strict.  

Giving a W2K customer the source to W2K isn't going to do a single one
of them any good, other than to watch some automated makefiles build 
stuff and maybe boost the customer's egos.  An average W2K customer 
lookinh at the W2K sources would be like Captain Kirk from Star Trek 
forgetting his tricorder on Rigel 7 or something -- in 100 years of so,
the natives might figure our how to make it start a fire or something.
It takes years to understand the subtle behaviors in W2K kernel 
programming, and it doesn't have the mongolian horde following of 
Linux developers.  

MS releasing W2K code to customers is pretty much a non-event in terms
of it causing some meaningful "linux-like explosion" of W2K development.

Jeff 




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

[PATCH] ramdisk/VM fix

[Philipp Rumpf]

With the current rd.c code, we can get into a situation where there is
a buffer-only page for data which is also in a page cache page with
page->buffers != NULL.  The current vmscan.c code never frees the page
cache page in this scenario, effectively doubling ramdisk memory
requirements.

Linus, I think this is a bugfix (tested against -ac kernels):

diff -ur linux/include/linux/swap.h linux-prumpf/include/linux/swap.h
--- linux/include/linux/swap.h  Thu Mar  8 10:01:30 2001
+++ linux-prumpf/include/linux/swap.h   Thu Mar  8 10:14:12 2001
@@ -284,7 +284,7 @@
 #endif
 
 #define page_ramdisk(page) \
-   (page->buffers && (MAJOR(page->buffers->b_dev) == RAMDISK_MAJOR))
+   (page->buffers && (MAJOR(page->buffers->b_dev) == RAMDISK_MAJOR) && 
+buffer_protected(page->buffers))
 
 extern spinlock_t swaplock;
 

I don't think I'm missing anything important ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Microsoft begining to open source Windows 2000?

[Joseph Pingenot]

>From Mohammad A. Haque on Thursday, 08 March, 2001:
[snip]
>Also notice that you're now paying MS so you can find their bugs. Very
>nice.

Indeed.  They've been very successful so far in getting people to
  pony up (pay) for beta software (see W2K: The Beta, Whistler/XP: The
  Beta, and (I am pretty sure) VisualStudio.Net: The Beta.)
Interesting concept.  Quite an evil marketing scheme, if you ask me.
  The users pay to help Microsoft debug their software, and also pay
  to put their security (both in the cracking and data safety senses)
  on the line.
Huzzah!  Microsoft has proven it: we're sheep!

  Baaa baa baa baaa,
  Joseph

-- 
[EMAIL PROTECTED]
"I felt a great disturbance in the force.  As if a significant plot
  line suddenly cried out in terror... and was suddenly silenced."
-Torg in "Sluggy Freelance" www.sluggy.com.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: Can't compile 2.4.2-ac14

[Hugh Dickins]

On Thu, 8 Mar 2001, Andrew Morton wrote:
> "J . A . Magallon" wrote:
> > Try this:
> This is the better fix.

I'm interested in the thinking here (because I tend the other way).

With J.A.M.'s patch blessed by Andrew, #ifdef CONFIG_DEBUG_BUGVERBOSE
goes around do_BUG() in fault.c, around its extern declaration in
page.h, and around its export in i386_ksyms.c.  Which stops compiling
do_BUG() into an ndef CONFIG_DEBUG_BUGVERBOSE kernel.

But I have an interest in compiling (some) modules once to run with
different configurations of base kernel - and I'd expect the makers
of Linux distributions to have a similar interest.  Just how many
versions of a driver do you need to build for your distribution?

My main concern is to let modules be independent of HIGHMEM config:
to which end I'd like one day (not imminent) to submit a patch in
which even CONFIG_NOHIGHMEM kernel would have stubs for kmap_high()
and kunmap_high(), to allow CONFIG_HIGHMEM modules to be linked in.

Of course there's a limit to how far such a programme should go,
but I don't think we should add CONFIG obstacles so cheaply avoided.
I'd prefer a module built with CONFIG_DEBUG_BUGVERBOSE to link into
a kernel built without CONFIG_DEBUG_BUGVERBOSE i.e. source as in -ac14,
but the #ifdef CONFIG_DEBUG_BUGVERBOSE moved down one line in page.h.

Am I a heretic?

Hugh

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Microsoft begining to open source Windows 2000?

[Ian Stirling]

> Not a chance. First your company must have at least 1500 licences and
> you can't modify any code... which implies that you can't rebuild either...

You can modify your compiler, so that it accepts patches (with no context)
and completely rewrite anything that needs modified.
The modified source would never be stored anywhere.

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

Re: Question: fs meta data, page cache and locking

[Alexander Viro]

On Thu, 8 Mar 2001, Anton Altaparmakov reposted:

> >But user space will never see metadata pages anyway, so you
> >should be the only one, who cares about them. Just be prepared to
> >writepage() and readpage() and the like.

ITYM ->prepare_write()/->commit_write().

See ftp.math.psu.edu/pub/viro/ext2-dir-patch-S2.gz for example of
metadata in pagecache. For deeper metadata (== stuff that can
be needed to access with some pages locked, in case of ext2 that
would be indirect blocks, inode/block bitmaps and group descriptors)
you need to set ->gfp_mask of address_space to prohibit IO on
allocation. See drivers/block/loop.c - it has to do the same to
->i_mapping of underlying file.
Cheers,
Al

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

Re: Linux 2.4.2ac12 (vt82c686 info)

[Harold Oga]

On Thu, Mar 08, 2001 at 09:17:06AM +0100, Vojtech Pavlik wrote:
>On Wed, Mar 07, 2001 at 01:23:49PM +, John Heil wrote:
>Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
>my drivers have little bugs in the 686b support. Harmless but somewhat
>annoying.
Hi,
   Hmm, last I checked, Alan had only included v3.21 of your VIA ide
driver in the 2.4.2-acxx series, which still had some minor problems with
the 686B.  These didn't clear up until v4.3 of the driver.

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

Re: Linux 2.4.2ac12 (vt82c686 info)

[Vojtech Pavlik]

On Thu, Mar 08, 2001 at 09:30:23AM -0800, Wayne Whitney wrote:

> In mailing-lists.linux-kernel, you wrote:
> 
> > Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
> > my drivers have little bugs in the 686b support. Harmless but somewhat
> > annoying.
> 
> Does this mean that the version 3.21 of your driver in the latest
> 2.4.2-acxx is newer than the version 4.3 that you distributed to the
> LKML a couple weeks ago?

They're about the same - only Alan didn't like the PCI speed measurement
code that's new in the 4.x series, so I added all the other changes to
the 3.20 driver, and 3.21 was born.

4.x is development
3.x is stable

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: aic7xxx funcs without return values

[Justin T. Gibbs]

>The bigger problem with that driver for pedants is that it contains globals
>with names like 'hard_error' which are asking for clashes . Bizarrely all
>the static functions are carefully named ahc_* and the globals are called
>things like 'restart_squencer'

Such is the evolutionary nature of most drivers.  I just spent a bit
of time cleaning this up.  Some of the exported symbols didn't even
need to be in the current layout of the driver.

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