Re: [PATCH] one of $BIGNUM devfs races

Re: [PATCH] one of $BIGNUM devfs races

[Alan Cox]

> OK, fair enough. When is your next merge with Linus scheduled? I'd
> prefer to get a few races fixed before shipping a patch, but I can try
> to plan for an earlier release if necessary.

I send stuff Linus regularly and sometimes it goes in and sometimes it
doesn't. Stuff with active maintainers I don't send on to Linus unless asked
too - hence joystick. input and much of USB are so far behind in Linus tree

How/when to send patches - (was Re: [PATCH] one of $BIGNUM devfs races)

[Neil Brown]

On Tuesday August 7, alan@lxorguk.ukuu.org.uk wrote:
> > OK, fair enough. When is your next merge with Linus scheduled? I'd
> > prefer to get a few races fixed before shipping a patch, but I can try
> > to plan for an earlier release if necessary.
> 
> I send stuff Linus regularly and sometimes it goes in and sometimes it
> doesn't. Stuff with active maintainers I don't send on to Linus unless asked
> too - hence joystick. input and much of USB are so far behind in Linus tree

This is something I would like to understand better.

Sometimes I send patches to Linus, and a new prepatch comes out within
hours that contains them.
Sometimes I send patches to Linus and it's like sending them to
/dev/null. Sometimes I resend.  Sometimes it helps.

So I wonder "is he busy? does he have other priorities? does he have a
broken mail system?  is he being rude" in decreasing order of
likelyhood from "very" to "very un-".

So I thought I would try sending to Alan and Linus.  Then they
appeared in an -ac patch, but not in a pre patch.

I thought that might be close enough, but if Alan doesn't plan to
forward them the Linus, then it isn't.


Now I am happy to just resent the pending patches every time a pre
patch comes out that doesn't contain then, but I want to be sure that
isn't going to negatively impact Linus at all.

Comments?

NeilBrown

(I'm talking about patches to fs/nfsd and drivers/md)

Re: How/when to send patches - (was Re: [PATCH] one of $BIGNUM devfs races)

[Linus Torvalds]

On Thu, 9 Aug 2001, Neil Brown wrote:
>
> This is something I would like to understand better.
>
> Sometimes I send patches to Linus, and a new prepatch comes out within
> hours that contains them.
> Sometimes I send patches to Linus and it's like sending them to
> /dev/null. Sometimes I resend.  Sometimes it helps.

Re-sending is always the right thing to do. Sometimes it takes a few
times, and you can add a small exasperated message at the top by the third
time ("Don't you love me any more?").

> Now I am happy to just resent the pending patches every time a pre
> patch comes out that doesn't contain then, but I want to be sure that
> isn't going to negatively impact Linus at all.

It's not. Sometimes (like now), I have other priorities, and right now for
example I've been concentrating on the VM balancing issues (and, in all
honesty, sometimes the "other priorities" aren't Linux issues at all ;).

When that happens, any other patches may still be merged, but they might
equally well just end up staying pending in my mailbox. And if they stay
there for more than a day they are basically so stale that I'll likely
never see them again.

I _seldom_ have pending patches over a pre-patch, so while it is possible
that I'm still mulling over your old patch when a new pre-patch comes out,
it's much more likely that the right answer is just to re-send. Maybe with
a slightly bigger explanation on why the patch is such a good and worthy
patch ;^)

And it's absolutely not worth it to worry about filling up my mailbox with
patches. Rule of thumb is: "if it's not really _really_ important, try to
keep one pre-patch or 48 hours between re-sends". And if it is _really_
important, ping me as often as you like.

		Linus

Re: How/when to send patches - (was Re: [PATCH] one of $BIGNUM devfs races)

[Rik van Riel]

On Wed, 8 Aug 2001, Linus Torvalds wrote:

> Re-sending is always the right thing to do.

So many VM patches, so little time ;)

I need to automate this ...

cheers,

Rik
--
IA64: a worthy successor to the i860.

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

Re: How/when to send patches - (was Re: [PATCH] one of $BIGNUM devfs races)

[Alan Cox]

> So I thought I would try sending to Alan and Linus.  Then they
> appeared in an -ac patch, but not in a pre patch.
> 
> I thought that might be close enough, but if Alan doesn't plan to
> forward them the Linus, then it isn't.

I can forward fs/nfs stuff to Linus if you want me to add it to the stuff
I do forward, ditto md (non lvm) stuff. In many ways -ac is far enough, if
it gets to -ac it gets to most folks and its there for all the vendors

Alan

Re: Fuzzy hash stuff.. (was Re: 2.1.xxx makes Electric Fence 22x slower)

[Jamie Lokier]

"David S. Miller" <davem@dm.cobaltmicro.com> wrote:
>As promised here is my work in progress fuzzy hash VMA lookup stuff.

On Tue, Aug 25, 1998 at 10:47:26PM +1000, Keith Owens wrote:
> Lots of code with very few comments snipped.  Come on Davem, make it
> understandable for us mere mortals.  If it took two people to fix
> quirks and bugs and converge the algorithm, surely a few notes on how
> it works would not go astray.

Nope, I can't see how it works either.

BTW, a splay tree would also be as fast as what we have now in the
common case, without need for a special one entry cache.  The root of
the tree automatically acts as the cache.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

Re: GPS Leap Second Scheduled!

[Jamie Lokier]

On Wed, Sep 09, 1998 at 09:35:59AM -0700, David Lang wrote:
> I am probably missing something, but can't you just ignore the leap second
> until you discover that the time is 1 sec off and then use the normal NTP
> procedure to get back to the exact time

Until the NTP procedure discovers and corrects this (a few minutes, plus
correction time), anything that expects synchronised time between
machines can go wrong.

Admittedly synchronisation isn't perfect anyway.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html

Re: GPS Leap Second Scheduled!

[Michael Shields]

In article <19980910073422.A13283@tantalophile.demon.co.uk>,
Jamie Lokier <lkd@tantalophile.demon.co.uk> wrote:
> On Wed, Sep 09, 1998 at 09:35:59AM -0700, David Lang wrote:
> > I am probably missing something, but can't you just ignore the leap second
> > until you discover that the time is 1 sec off and then use the normal NTP
> > procedure to get back to the exact time
> 
> Until the NTP procedure discovers and corrects this (a few minutes, plus
> correction time), anything that expects synchronised time between
> machines can go wrong.

NTP has the capability to know in advance that a leap second is
scheduled and act upon that at the correct time.

Check your logs the next time a leap second happens; xntpd does it.
-- 
Shields, CrossLink.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html

Re: Access to I/O-mapped / Memory-mapped resources

[Jamie Lokier]

On Wed, Dec 09, 1998 at 03:19:10PM -0800, Linux Lists wrote:
> I have a question: is there any reference in regards to how / when to use
> the virt_to_phys, virt_to_bus, ioremap, etc. ... functions, other than 
> /usr/src/linux/Documentation/IO-mapping.txt ?!? I'd like to understand it
> better, but this text has not been enough (for me, of course).

Well, the whole address thing is a bit messy anyway; I don't expect a
perfect understanding of it is even possible...

But in case it helps, try the document below.

> If there is no other way, I'll try to re-read it 1000 times to see if my
> understanding increases 1000 times as well ... ;)

Do that :-)

	linux/Documentation/IO-mapping.txt
        ----------------------------------

...is a little out of date but basically right.  Give it a read.
Then read this addendum; it might clarify things a bit.

Types of address
================

*bus* is an address you pass to devices.  E.g., what you'd write to a
PCI bus-mastering DMA device for its target address.  To access a bus
address from kernel C code, known as memory-mapped I/O, you must use
ioremap() to convert it to an *ioremap* address.  From C code, these
should always be accessed through readl(), writel() etc. and not as
ordinary memory references.  See <asm/io.h>.

*phys* is a CPU address after MMU translation.  It only appears in page
tables and things related to page tables.  Even this is hidden to some
extent because pte_page(*pte) returns a *virt* address despite appearances.
See <asm/pgtable.h>.

*virt* is a kernel direct-mapped address.  These are addresses you can
read and write from C, that correspond to main memory.  E.g., on x86,
the *virt* address 0xc0001000 means the 4097th byte of main memory.  See
<asm/page.h>.

There are other kinds of address too:

*user* addresses (such as passed to read() and write()) are
none of the above, and should always by accessed through get_user(),
put_user() etc.  See <asm/uaccess.h>.

*static* addresses are the addresses of functions and variables that are
declared in source code.  Because kernel code and modules are allocated
in various ways, you can't assume much about these addresses, but you
can always read and write them from kernel C code.

*vmalloc* addresses (returned by vmalloc()).  These are kernel virtual
address, which you can read and write from kernel C code.  But you can't
pass them to any of the virt_to_XXX macros, because they're *not* *virt*
addresses!  See <linux/vmalloc.h>.

*fixmap* addresses (returned by fix_to_virt()) (which has a misleading
name).  These are like *vmalloc* addresses: you can't pass them to the
virt_to_XXX macros, so they're _not_ *virt* addresses.  It's not very
clear if you're supposed to use readl() and writel() to access these.
See <asm/fixmap.h>.

*ioremap* addresses are returned by ioremap(), which takes a *bus*
address.  These have some similarity to *vmalloc* addresses, but you can
only use readl(), writel() etc. to access the device memory referred to
here.  Unhelpfully, just reading and writing these directly does work on
some architectures, and most older device drivers still do this.

Memory map
==========

The actual memory map varies a lot between architectures.  But since
someone asked, I'll give a quick summary of one particular memory map.
This example is for an i386 architecture: a particular 64MB Pentium II
dual processor box with PCI and an ISA bridge.

Virtual map
...........

This is what C code sees in user mode:

0x00000000-0xbfffffff  User space virtual memory mappings.

This is what C code sees in kernel mode:

0x00000000-0xbfffffff User space virtual memory mappings (current->mm context).
0xc0000000-0xc3ffffff 64MB kernel view of all of main memory, uses 4MB pages.
0xc4000000-0xc47fffff 8MB unmapped hole.
0xc4800000-0xffffbfff Kernel virtual mappings for vmalloc() and ioremap().
0xffffc000-0xffffcfff Memory mapped local APIC registers.
0xffffd000-0xffffdfff Memory mapped IO-APIC registers.

The 64MB view is subdivided like this (it depends on the PC's details):

0xc0000000-0xc00003ff Zero page, reserved for BIOS.
0xc0000000-0xc009ffff Low memory (first 640k minus zero page).
0xc00a0000-0xc00fffff Low memory-mapped I/O (especially VGA adapter) and ROMs.
0xc0100000-0xc3ffffff High memory (remaining 63MB).

The 64MB view at 0xc0000000 (= PAGE_OFFSET) is directly addressable main
memory.  This is simply memory addresses with PAGE_OFFSET added.  This
contains the main kernel image, and memory allocated with kmalloc(),
get_free_page() and the slab allocator.  Cached disk pages, network
buffers etc. are all addressed in this space.

The 64MB view is the *virt* addresses described earlier.  "Virtual" here
simply refers to the PAGE_OFFSET translation, nothing more.

The vmalloc() mappings are a different way to see this memory, used only
when a large, contiguous address range needs to be allocated.  This is
used to hold loaded modules amongst other things.

The ioremap() mappings occupy the same address range as the vmalloc()
mappings, but are a view onto memory-mapped I/O space (MMIO).  Not all
devices are mapped with ioremap() -- those in the low memory-mapped area
aren't.  In theory you are supposed to use readl(), writel(),
memcpy_fromio() etc. to access memory-mapped I/O space, but many older
drivers fail to do this and work fine on the current x86 implementation.

Physical map
............

Physical addresses are the result of virtual address translation on
board the CPU.  C code (and assembly code) doesn't see these directly,
but they are used in page tables, which control the address translation.

There is some confusion in the kernel page table code about whether the
physical addresses passed around are *phys* addresses (also known as
*linear*), or *virt* address, which are a restricted subset of *phys*
with PAGE_OFFSET added.

When setting entries, *phys* tends to be used, but when reading entries
*virt* tends to be returned.  This sometimes loses information, so
breaking some device drivers.  Perhaps those drivers are broken by
design anyway.

Bus map
.......

This view is completely different to the virtual address view, and the
*virt* view which is a subset of virtual addresses.  Bus addresses can
overlap virtual addresses in an arbitrary way, 

The bus map is the view seen by peripheral devices, like video cards and
disk controllers.  Although different from the CPU's physical map (which
is a sort of private bus map for the CPU), the bus addresses tend to be
consistent between different devices in a single machine.

On a PC, the bus map is arranged by the system BIOS at boot time,
according to rules of Plug'n'Play and other rules.  For the PCI bus,
regions of prefetchable and non-prefetchable memory are mixed
arbitrarily: there's no particularly significant address where one kind
stops and another starts.  (Although your BIOS might make it appear so).
You don't have to worry about the differences, as long as your BIOS
configured everything properly.

`lspci -vb' will show the bus addresses of all PCI devices on a system.

Memory mapped ISA cards tend to have rather low addresses (in the first
megabyte), while PCI cards can be mapped to all sorts of addresses, high
and low depending on the BIOS.

Non-PC architectures have different rules.

On an i386 architecture, bus addresses and *phys* addresses are the
same.  This is convenient but it does tend to hide some problems.  On
other architectures, these two are often different.

Devices with *bus* addresses are supposed to be memory mapped using
ioremap(), and then accessed using readl(), writel() etc.  Because none
of this was necessary on the i386 with the 2.0.x kernels, and the other
platforms weren't very well supported then, many older device drivers
simply access device bus addresses as if they were memory.

This poses big problems with some non-i386 architectures, which require
readl() etc. for the drivers to work.  These days it also poses problems
with the i386, because in 2.1.x kernels the memory layout was changed to
make communication between user space and kernel space more efficient.
As a result, ioremap() is required to get a virtual address which you
can pass to readl(), writel() etc.

Note: there is an ironic twist.  The virtual address returned by
ioremap() is not a *virt* address, so you can't expect meaningful
results if you pass it to virt_to_bus() or virt_to_phys().

Another note: at least on a PC, you don't need ioremap() to access
devices in the first 1MB of the bus address range.  This includes most
ISA devices (but not video cards).

I/O port map
............

This is similar to the bus map, but refers to I/O ports that are
accessed by special I/O instructions from the CPU, if it is an i386
based architecture.  For some other architectures, the I/O ports are
actually quite similar to memory-mapped I/O but using different
addresses.  Although some buses support more than 64k I/O ports, the
i386 architecture does not so this address range is restricted to
0x0000-0xffff.

`cat /proc/ioports' shows all the I/O ports used by drivers currently
loaded on a system.  `lspci -v' shows all the I/O ports used by PCI
devices.

Use inb(), outb() etc. to access I/O ports.  This has been required ever
since the earliest versions of Linux, so all drivers that use I/O ports
get this right.  There is no equivalent to ioremap().

Translating virtual addresses
=============================

Some people try to look up page tables to convert a *user* address or
*vmalloc* address to a *bus* address or *virt* address.  This works for
some things, but breaks others.  It makes a number of assumptions that
are incorrect and won't work when you want to use the driver in a new
way one day, or on a new architecture.

This mess will be cleaned up sometime in version 2.3.  So if you want it
cleaned up, perhaps the best way is to help ensure 2.2 is ready for
release.  Hint :-)

Hope this helps,
-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: RLIM_INFINITY inconsistency between archs

[Adam Sampson]

On Thu, Jul 27, 2000 at 12:39:51AM -0700, Linus Torvalds wrote:
> Is there some documentation file that I've not updated and that people
> are slavishly following outdated information in? I don't read the
> documentation myself, so I'd never notice ;)

Yes; the glibc installation instructions.

-- 

Adam Sampson
azz@gnu.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: RLIM_INFINITY inconsistency between archs

[Adam Sampson]

On Thu, Jul 27, 2000 at 07:03:57PM +0200, Jamie Lokier wrote:
> But instead, how about a script: /lib/modules/VERSION/compile-module.
> The script would know where to find the kernel headers.  That could be
> /lib/modules/include for distributions, and /my/kernel/tree/include for
> folks who used `make modules_install' recently.

I'll second that suggestion. This kind of thing works very well indeed for
projects like Apache.

-- 

Adam Sampson
azz@gnu.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: RLIM_INFINITY inconsistency between archs

[Miquel van Smoorenburg]

In article <cistron.20000728232030.C8868@gnu.org>,
Adam Sampson  <azz@gnu.org> wrote:
>On Thu, Jul 27, 2000 at 07:03:57PM +0200, Jamie Lokier wrote:
>> But instead, how about a script: /lib/modules/VERSION/compile-module.
>> The script would know where to find the kernel headers.  That could be
>> /lib/modules/include for distributions, and /my/kernel/tree/include for
>> folks who used `make modules_install' recently.
>
>I'll second that suggestion. This kind of thing works very well indeed for
>projects like Apache.

It is indeed a very good idea. The script could just spit out the
CFLAGS used for kernel compilation like this:

#! /bin/sh
cat <<EOF
-D__KERNEL__ -I/usr/src/linux-2.2.15/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DUTS_MACHINE='"i386"'
EOF

Then a module Makefile would be as simple as

# Set KVER manually if you want to compile against another kernel version
KVER=$(shell uname -r)
CFLAGS=$(shell /lib/modules/$(KVER)/kernel-config)

module.o: module.c module.h

I've tried this, it works.

Mike.
-- 
Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] linux likes to kill bad inodes

[Andreas Dilger]

I previously wrote:
> I will post a patch separately which handles a couple of cases where
> *_delete_inode() does not call clear_inode() in all cases.

OK, here it is.  The ext2_delete_inode() change isn't exactly a bug fix,
but rather a "performance" change.  No need to hold BLK to check status
or call clear_inode() (we call clear_inode() outside BLK in VFS if
delete_inode() method does not exist).

Cheers, Andreas
=======================================================================
diff -ru linux-2.4.4p1.orig/fs/ext2/inode.c linux/fs/ext2/inode.c
--- linux-2.4.4p1.orig/fs/ext2/inode.c	Tue Apr 10 16:44:49 2001
+++ linux/fs/ext2/inode.c	Fri Apr 27 13:51:15 2001
@@ -44,12 +47,12 @@
  */
 void ext2_delete_inode (struct inode * inode)
 {
-	lock_kernel();
-
 	if (is_bad_inode(inode) ||
 	    inode->i_ino == EXT2_ACL_IDX_INO ||
 	    inode->i_ino == EXT2_ACL_DATA_INO)
 		goto no_delete;
+
+	lock_kernel();
 	inode->u.ext2_i.i_dtime	= CURRENT_TIME;
 	mark_inode_dirty(inode);
 	ext2_update_inode(inode, IS_SYNC(inode));
@@ -59,9 +62,7 @@
 	ext2_free_inode (inode);
 
 	unlock_kernel();
 	return;
 no_delete:
-	unlock_kernel();
 	clear_inode(inode);	/* We must guarantee clearing of inode... */
 }
 
diff -ru linux-2.4.4p1.orig/fs/bfs/inode.c linux/fs/bfs/inode.c
--- linux-2.4.4p1.orig/fs/bfs/inode.c	Tue Apr 10 16:44:49 2001
+++ linux/fs/bfs/inode.c	Fri Apr 27 15:45:31 2001
@@ -145,7 +145,7 @@
 	if (is_bad_inode(inode) || inode->i_ino < BFS_ROOT_INO ||
 	    inode->i_ino > inode->i_sb->su_lasti) {
 		printf("invalid ino=%08lx\n", inode->i_ino);
-		return;
+		goto bad_inode;
 	}
 	
 	inode->i_size = 0;
@@ -155,8 +156,7 @@
 	bh = bread(dev, block, BFS_BSIZE);
 	if (!bh) {
 		printf("Unable to read inode %s:%08lx\n", bdevname(dev), ino);
-		unlock_kernel();
-		return;
+		goto bad_unlock;
 	}
 	off = (ino - BFS_ROOT_INO)%BFS_INODES_PER_BLOCK;
 	di = (struct bfs_inode *)bh->b_data + off;
@@ -178,7 +178,9 @@
 		s->su_lf_eblk = inode->iu_sblock - 1;
 		mark_buffer_dirty(s->su_sbh);
 	}
+bad_unlock:
 	unlock_kernel();
+bad_inode:
 	clear_inode(inode);
 }
 
diff -ru linux-2.4.4p1.orig/fs/ufs/ialloc.c linux/fs/ufs/ialloc.c
--- linux-2.4.4p1.orig/fs/ufs/ialloc.c	Thu Nov 16 14:18:26 2000
+++ linux/fs/ufs/ialloc.c	Fri Apr 27 15:53:26 2001
@@ -82,6 +82,7 @@
 	if (!((ino > 1) && (ino < (uspi->s_ncg * uspi->s_ipg )))) {
 		ufs_warning(sb, "ufs_free_inode", "reserved inode or nonexistent inode %u\n", ino);
 		unlock_super (sb);
+		clear_inode (inode);
 		return;
 	}
 	
@@ -90,6 +91,7 @@
 	ucpi = ufs_load_cylinder (sb, cg);
 	if (!ucpi) {
 		unlock_super (sb);
+		clear_inode (inode);
 		return;
 	}
 	ucg = ubh_get_ucg(UCPI_UBH);
-- 
Andreas Dilger                               TurboLabs filesystem development
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: Tracking down semaphore usage/leak

[Ken Brownfield]

Urgh, learn something new everyday (ipcs, ipcrm).  My apologies; apropos
didn't catch it on my boxes. :-(
-- 
Ken.
brownfld@irridia.com

On Tue, Jun 26, 2001 at 02:09:16PM -0700, Ken Brownfield wrote:
| With RedHat's new Samba 2.0.10 RPM (the one to patch the latest 
| vulnerability) they seem to have sniffed enough glue to start using SysV 
| IPC semaphores which apparently leak until SEM??? are reached.  semget() 
| is returning "No space left on device", and disk/inodes/memory are all 
| fine.
| 
| Anyway, could someone give me a very quick rundown of the options for 
| tracking/force-freeing semaphores, or how to determine from proc, if 
| possible, what the current semaphore allocation status is?  Or did RH 
| slay a machine I really don't want to reboot?  I've restarted all 
| semaphore-using processes to no avail, but even so the SEM??? limits are 
| far above the normal needs of this machine.
| 
| Thanks much.  Searched the archives/Google/FAQ/semaphore docs; sorry if 
| it's been covered.  I'll summarize if folks want to hit me on or off the 
| list.
| --
| Ken.
| brownfld@irridia.com

Re: user-mode port 0.44-2.4.7

[Alan Cox]

> Suppose I loop against xtime reaching a particular value.  While this is

xtime isnt used this way that I can see. jiffies however is. There are good
arguments for getting rid of most [ab]use of jiffies however. For one its
pretty important to scaling on both big mainframes and beowulf setups doing
heavy computation to reduce timer ticks

Re: user-mode port 0.44-2.4.7

[Chris Friesen]

Alan Cox wrote:
> 
> > Suppose I loop against xtime reaching a particular value.  While this is
> 
> xtime isnt used this way that I can see. jiffies however is. There are good
> arguments for getting rid of most [ab]use of jiffies however. For one its
> pretty important to scaling on both big mainframes and beowulf setups doing
> heavy computation to reduce timer ticks

jiffies is (as of 2.4.7 anyways) marked as volatile, so we're safe there.  My
point is this--should someone writing badly designed (but technically correct)
code be able to totally hose the system?

The only difference between volatile and normal is that if it is marked as
volatile it must be accessed every time rather than being pre-cached.  If we
never spin on accessing xtime, then the fact that we can't optimize it shouldn't
hurt. (Am I wrong here?  If I am then please explain because I'm missing
something...)  If someone ever *does* spin on xtime, then we really don't want
to optimize that access out of the loop, because doing so could cause nasty
problems.


-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: patch for allowing msdos/vfat nfs exports

[Alan Cox]

> I've been using it for half a day now and so far it hasn't done
> anything bad, but please be careful if you decide to test it and
> backup your data and after testing, be sure to compare your data
> to your backup.

Rename ?

> +	struct inode *inode = dentry->d_inode;
> +	unsigned int i_pos = MSDOS_I(inode)->i_location;

i_location is not a constant across renames or other operations, so you may
inadvertantly do I/O to completely the wrong file


The infrastructure looks great, I just don't think your handles are safe 

Re: Externally transparent routing

[Alan Cox]

> To prevent my NAT-box from showing up on traceroutes I'd like to let it
> route without decreasing the TTL. I was told that proxy arp also archieves

And what happens if you get a routing loop ?

A NAT box really does need to drop the TTL. Nothing stops you giving it a
more bizarre name, or indeed you can do what a few folks have found
excruciatingly funny to do to tracerouters which is to spoof totally bogus
icmp unreachables so they see crazy paths

Re: Externally transparent routing

[Jordi Verwer]

> And what happens if you get a routing loop ?
Bad Things would happen, but I only have one router and since it's a NAT box
it isn't very likely to end up in a routing loop anyway.

> A NAT box really does need to drop the TTL. Nothing stops you giving it a
> more bizarre name, or indeed you can do what a few folks have found
> excruciatingly funny to do to tracerouters which is to spoof totally bogus
> icmp unreachables so they see crazy paths
What I wanted to do was be able to send my traceroutes to websites that
don't function properly, but since my NAT box is headless and I'd like to
avoid the hassle of SSH-ing to it, I do these traceroutes from one of my
internal machines. If I don't manually remove my NAT box from the list, the
braindead webmaster will allways blame my NAT box (which naturally is
innocent;)). But I suppose you do not want this to be possible. That is
understandable, but still BSD has a very clean implementation of
transrouting and I see no reason not to let Linux do this.

Jordi Verwer
P.S.: I adjust my computer's (which isn't mine btw, but belongs to my
"boss") date.
P.P.S.: Still not subscribed, so please CC any replies to me. Thank you.

Re: user-mode port 0.44-2.4.7

[Alan Cox]

> Should head and tail be volatile in the definition, or should they be
> accessed with:
> int head = (volatile)myqueue.head;
> or with barrier() around the read/write?

The best way is to use barrier calls. It makes your assumptions about
ordering absolutely explicit. However you should still be careful - you
can't be sure that head will be read atomically or written atomically on
all processors eg if it was

	struct
	{
		unsigned char head;
		unsigned char tail;
		char buf[256];
	}

you would get some suprisingly unpleasant suprises on SMP Alpha. Currently
"int" is probably safe for all processors.

So unless this is a precision tuned fast path it is better to play safe with
this and use atomic_t or locking. The spinlock cost on an Athlon or a later
PIII is pretty good in most cases. Using the -ac prefetch stuff can make it
good in almost all cases, but thats probably a 2.5 thing for the generic
case.

Basically locks are getting cheaper on x86, the suprises are getting more
interesting on non-x86

Alan

my patches won't compile under 2.4.7

[Kirk Reiser]

As of 2.4.7 my patches to the kernel won't compile.  It appears to be
something to do with devfs_fs_kernel.h being part of miscdevices.h.  I
have sifted through the code but have not been able to determine
exactly why they won't work any more.  Here is the error output from
my compile:

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i586    -c -o speakup.o speakup.c
In file included from /usr/src/linux/include/linux/locks.h:8,
                 from /usr/src/linux/include/linux/devfs_fs_kernel.h:6,
                 from /usr/src/linux/include/linux/miscdevice.h:4,
                 from speakup.c:63:
/usr/src/linux/include/linux/pagemap.h:35: `currcons' undeclared here (not in a function)
/usr/src/linux/include/linux/pagemap.h:35: parse error before `.'
make[4]: *** [speakup.o] Error 1

I'm not sure even where to start trying to describe what I've looked
at and what I don't understand.  It appears that page_cache_alloc() is
now an inline function with an argument passed to it, where it used to
be a #define with no arguments.  I see that struct misc_device now has
a new member devfs_handle but the other drivers I've looked at rtc.c
haven't changed their structure members to take this into account.  It
seems nothing new is necessary because misc_register checks if it's
been set or not.  The two error lines don't look to me to have anything
to do with any of these things either currcons isn't used in any of
the misc_device structure or anything I can see which might end up
calling page_cache_alloc().  Can anyone give me any ideas what I
should check to hunt down exactly what's going on here?  It almost
looks like gcc is getting screwed up in it's parsing or something.

Any ideas will greatefully be accepted I'm lost!

  Kirk

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: kirk@braille.uwo.ca		University of Western Ontario
phone: (519) 661-3061

Re: my patches won't compile under 2.4.7

[Alan Cox]

> 
> As of 2.4.7 my patches to the kernel won't compile.  It appears to be
> something to do with devfs_fs_kernel.h being part of miscdevices.h.  I
> have sifted through the code but have not been able to determine
> exactly why they won't work any more.  Here is the error output from
> my compile:
> 
> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i586    -c -o speakup.o speakup.c
> In file included from /usr/src/linux/include/linux/locks.h:8,
>                  from /usr/src/linux/include/linux/devfs_fs_kernel.h:6,
>                  from /usr/src/linux/include/linux/miscdevice.h:4,
>                  from speakup.c:63:
> /usr/src/linux/include/linux/pagemap.h:35: `currcons' undeclared here (not in a function)
> /usr/src/linux/include/linux/pagemap.h:35: parse error before `.'
> make[4]: *** [speakup.o] Error 1
> 
> I'm not sure even where to start trying to describe what I've looked
> at and what I don't understand.  It appears that page_cache_alloc() is
> now an inline function with an argument passed to it, where it used to
> be a #define with no arguments.  I see that struct misc_device now has
> a new member devfs_handle but the other drivers I've looked at rtc.c
> haven't changed their structure members to take this into account.  It
> seems nothing new is necessary because misc_register checks if it's
> been set or not.  The two error lines don't look to me to have anything
> to do with any of these things either currcons isn't used in any of
> the misc_device structure or anything I can see which might end up
> calling page_cache_alloc().  Can anyone give me any ideas what I
> should check to hunt down exactly what's going on here?  It almost
> looks like gcc is getting screwed up in it's parsing or something.
> 
> Any ideas will greatefully be accepted I'm lost!
> 
>   Kirk
> 
> -- 
> 
> Kirk Reiser				The Computer Braille Facility
> e-mail: kirk@braille.uwo.ca		University of Western Ontario
> phone: (519) 661-3061
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: my patches won't compile under 2.4.7

[Kirk Reiser]

Huh?  Did you actually write something below Alan? or are you just
making me feel insecure? 'grin'

  Kirk

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > 
> > As of 2.4.7 my patches to the kernel won't compile.  It appears to be
> > something to do with devfs_fs_kernel.h being part of miscdevices.h.  I
> > have sifted through the code but have not been able to determine
> > exactly why they won't work any more.  Here is the error output from
> > my compile:
> > 
> > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i586    -c -o speakup.o speakup.c
> > In file included from /usr/src/linux/include/linux/locks.h:8,
> >                  from /usr/src/linux/include/linux/devfs_fs_kernel.h:6,
> >                  from /usr/src/linux/include/linux/miscdevice.h:4,
> >                  from speakup.c:63:
> > /usr/src/linux/include/linux/pagemap.h:35: `currcons' undeclared here (not in a function)
> > /usr/src/linux/include/linux/pagemap.h:35: parse error before `.'
> > make[4]: *** [speakup.o] Error 1
> > 
> > I'm not sure even where to start trying to describe what I've looked
> > at and what I don't understand.  It appears that page_cache_alloc() is
> > now an inline function with an argument passed to it, where it used to
> > be a #define with no arguments.  I see that struct misc_device now has
> > a new member devfs_handle but the other drivers I've looked at rtc.c
> > haven't changed their structure members to take this into account.  It
> > seems nothing new is necessary because misc_register checks if it's
> > been set or not.  The two error lines don't look to me to have anything
> > to do with any of these things either currcons isn't used in any of
> > the misc_device structure or anything I can see which might end up
> > calling page_cache_alloc().  Can anyone give me any ideas what I
> > should check to hunt down exactly what's going on here?  It almost
> > looks like gcc is getting screwed up in it's parsing or something.
> > 
> > Any ideas will greatefully be accepted I'm lost!
> > 
> >   Kirk
> > 
> > -- 
> > 
> > Kirk Reiser				The Computer Braille Facility
> > e-mail: kirk@braille.uwo.ca		University of Western Ontario
> > phone: (519) 661-3061
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> 
> 

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: kirk@braille.uwo.ca		University of Western Ontario
phone: (519) 661-3061

Re: my patches won't compile under 2.4.7

[Richard Gooch]

Alan Cox writes:
> > 
> > As of 2.4.7 my patches to the kernel won't compile.  It appears to be
> > something to do with devfs_fs_kernel.h being part of miscdevices.h.  I
> > have sifted through the code but have not been able to determine
> > exactly why they won't work any more.  Here is the error output from
> > my compile:

I don't see why you're pointing the finger devfs_fs_kernel.h. Other
miscdevice drivers compile fine.

> > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i586    -c -o speakup.o speakup.c
> > In file included from /usr/src/linux/include/linux/locks.h:8,
> >                  from /usr/src/linux/include/linux/devfs_fs_kernel.h:6,
> >                  from /usr/src/linux/include/linux/miscdevice.h:4,
> >                  from speakup.c:63:
> > /usr/src/linux/include/linux/pagemap.h:35: `currcons' undeclared here (not in a function)
> > /usr/src/linux/include/linux/pagemap.h:35: parse error before `.'
> > make[4]: *** [speakup.o] Error 1

Looking at my copy of include/linux/pagemap.h I see no instance of
"currcons" on line 35 or elsewhere.

> > I'm not sure even where to start trying to describe what I've looked
> > at and what I don't understand.  It appears that page_cache_alloc() is
> > now an inline function with an argument passed to it, where it used to
> > be a #define with no arguments.  I see that struct misc_device now has
> > a new member devfs_handle but the other drivers I've looked at rtc.c

This is not new. struct misc_device has had a "devfs_handle" field for
a long time. Since 2.3.46, in fact. So when you say above "since
2.4.7", I suspect you mean "after virgin 2.2.x". It would have helped
if you had specified this.

My guess is that your patch has some bad #define somewhere. Again, it
would have helped if you had sent the patch as well.

Anyway, I don't think this problem is even remotely related to devfs.
I suggest you post more complete information to the linux-kernel
mailing list. Then maybe someone there can help you.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: my patches won't compile under 2.4.7

[Kirk Reiser]

Actually it wasn't Alan pointing the finger it was me.  I was only
trying to figure out what the errors meant and they pointed to
devfs_fs_kernel.h.  The problem as I suspected at eh time was entirely
unrelated.  I moved my #include of misc_devices.h up and removed a
duplicate #include for linux/init.h and poof she compiled.  I am
starting to become a believer in voodoo computing again I guess.

On another note related to devfs though when I compile devfs in the
system just hangs.  I am wondering if I am registering my synth device
before devfs has memory allocated.  I register very early in the boot
process in console_init() and experienced similar problems before because I
don't think  kmalloc() may be available that early in the sequence.

The question then is, do you think that could be why the system is
hanging with devfs configured in?

  Kirk

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: kirk@braille.uwo.ca		University of Western Ontario
phone: (519) 661-3061

Re: my patches won't compile under 2.4.7

[Richard Gooch]

Kirk Reiser writes:
> On another note related to devfs though when I compile devfs in the
> system just hangs.  I am wondering if I am registering my synth device
> before devfs has memory allocated.  I register very early in the boot
> process in console_init() and experienced similar problems before because I
> don't think  kmalloc() may be available that early in the sequence.
> 
> The question then is, do you think that could be why the system is
> hanging with devfs configured in?

Yes. Calling kmalloc() before MM is set up is not allowed. See the
comments in drivers/char/console.c which talks about not calling
kmalloc() before console_init().

Simply move your driver registration after MM is set up. Use
module_init() to declare your initialisation function. This works for
both modules and built-in drivers. Registering a driver before MM
setup is considered bad practice.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: user-mode port 0.44-2.4.7

[Alan Cox]

> > This is not a gcc issue. Even if gcc _were_ to generate bad code, the
> > global volatile _still_ wouldn't be the correct answer.
> 
> I think his worry is the pedantic reason that without the volatile gcc is
> allowed to write code that chokes and dies if xtime happens to change in a
> volatile manner.  The example given earlier was:

Make the volatility explicit where it is needed, either to express a barrier
with barrier() or an assignment as in

	foo = (volatile)xtime

This makes it clear where the barriers are and avoids unpleasant
optimisation hits elsewhere.

Alan

Re: IGMP join/leave time variability

[Alan Cox]

> ASAP with respect to the user mode calls.
> 1. What would be the harm if I set IGMP_Initial_Report_Delay to something
> very small like 5 to 10 (jiffies)?  No need for net_random() I'de expect in
> that case?

Read the IGMP RFC documents they discuss in detail the cases where time
delays and randomness are needed and important. 

Re: Validating Pointers

[Alan Cox]

> Is there a general (correct) kernel subroutine to validate a pointer
> received in a routine as input from the outside world?  Is access_ok() a
> good one to use?

access_ok may do minimal checks, or no checking at all. The only point at
which you can validate a user point is when you use copy*user and
get/put_user to access the data.

Re: Validating Pointers

[tpepper]

On Thu 26 Jul at 16:52:48 +0100 alan@lxorguk.ukuu.org.uk done said:
> access_ok may do minimal checks, or no checking at all. The only point at
> which you can validate a user point is when you use copy*user and
> get/put_user to access the data.

Should the i386 access_ok() fail when checking a copy to/from userspace
from/to a static in a driver module?  The __copy_to|from_user work fine
and copy_to|from_user fail, but I guess that doesn't mean access_ok()
is the culprit.  I don't know intel assembly and the platforms for
which I do get the assembly don't do much in access_ok() so there's no
comparing...but I'd have thought they'd be more concerned with the user
address location than the kernel one.

t.

Re: Validating Pointers

[Alan Cox]

> Should the i386 access_ok() fail when checking a copy to/from userspace
> from/to a static in a driver module?  The __copy_to|from_user work fine
> and copy_to|from_user fail, but I guess that doesn't mean access_ok()
> is the culprit.  I don't know intel assembly and the platforms for
> which I do get the assembly don't do much in access_ok() so there's no
> comparing...but I'd have thought they'd be more concerned with the user
> address location than the kernel one.

You can't pass kernel address as if they were userspace. It might happen to
sometimes work on some architectures. Take a look at the set_fs() stuff

Re: Validating Pointers

[tpepper]

On Thu 26 Jul at 18:12:57 +0100 alan@lxorguk.ukuu.org.uk done said:
> 
> You can't pass kernel address as if they were userspace. It might happen to
> sometimes work on some architectures. Take a look at the set_fs() stuff

Am I?  I though I was doing a pretty plain user<->kernel copy:

	copy_to_user(user_addr, kernel_addr, size);
		and
	copy_from_user(kernel_addr, user_addr, size);

Are you saying that static and dynamically allocated kernel variables end up
in different segments (kernel_ds and user_ds) and the copy is only expected to
succeed if the to and from addresses are in the same segment?

Tim

Re: Validating Pointers

[Alan Cox]

> 	copy_to_user(user_addr, kernel_addr, size);
> 		and
> 	copy_from_user(kernel_addr, user_addr, size);
> 
> Are you saying that static and dynamically allocated kernel variables end up
> in different segments (kernel_ds and user_ds) and the copy is only expected to
> succeed if the to and from addresses are in the same segment?

user and kernel address spaces are seperate. On S/390 and M68K for example
they occupy the same values for both. Long long ago this was done via
segments on x86 (we dont use segments now) and thus the functions to do 
what you want are still called set_fs/get_fs/get_ds

Re: IGMP join/leave time variability

[Alan Cox]

> >From this, I infer that there should be _no_ initial delay on sending 
> the IGMP join.  In fact, a quick peek at the source confirms this: 
> (net/ipv4/igmp.c):
> 
> #define IGMP_Initial_Report_Delay               (1*HZ)
> 
> /* IGMP_Initial_Report_Delay is not from IGMP specs!
>  * IGMP specs require to report membership immediately after
>  * joining a group, but we delay the first report by a
>  * small interval. It seems more natural and still does not
>  * contradict to specs provided this delay is small enough.
>  */
> 
> But this "small interval" is actually very noticeable in our application.

I suspect the small interval for the first one should be 1 not 1*HZ. That
would keep a little bit of jitter which is good to avoid the multicast
receive/join group problem

[Lots of clients all running an app listening for multicast packets, one
 packet says 'do xyz on this group' and they all then send joins at the same
 instant]

Alan

Re: Proliant ML530, Megaraid 493 (Elite 1600), 2.4.7, timeout & abort

[Alan Cox]

> the Elite 1600) in them. I am able to get them to boot with 2.2.19, but
> not 2.4.7.   Under 2.4.7 the relevant message is

Ok first thing - does 2.4.6 work. If so then  there is a bug or firmware
incompatibility with the firmware set you have and the newer driver.

Re: Support for serial console on legacy free machines

[Alan Cox]

> console is "Serial Port Console Redirection" (SPCR) table. This table
> gives me almost all the information I need to initialize and use a
> serial console. The bummer is this table was designed by Microsoft and
> Microsoft owns the copyright on it. Microsoft primarily designed this
> table for use by Whistler. Their copyright may cause potential problems
> with using it in Linux. This makes me reluctant to use this table. I

Such as ?

If its a table that microsoft added to ACPI and its well thought out I don't
see a big problem technically. There are a collection of BIOS services we
use that were microsoft originated

Re: Support for serial console on legacy free machines

[Khalid Aziz]

Alan Cox wrote:
> 
> > console is "Serial Port Console Redirection" (SPCR) table. This table
> > gives me almost all the information I need to initialize and use a
> > serial console. The bummer is this table was designed by Microsoft and
> > Microsoft owns the copyright on it. Microsoft primarily designed this
> > table for use by Whistler. Their copyright may cause potential problems
> > with using it in Linux. This makes me reluctant to use this table. I
> 
> Such as ?
> 
> If its a table that microsoft added to ACPI and its well thought out I don't
> see a big problem technically. There are a collection of BIOS services we
> use that were microsoft originated

I can not say this table is part of ACPI 2.0. ACPI 2.0 Spec document
lists SPCR in the DESCRIPTION_HEADER signatures but calls it Microsoft
Serial Port Console Redirection Table and refers to the URL on Microsoft
web site. If you go to this URL, you see the Microsoft copyright and
terms of use license. The same applies to DBGP (Debug Port Table).

-- 
Khalid

====================================================================
Khalid Aziz                              Linux Systems Operation R&D
(970)898-9214                                        Hewlett-Packard
khalid@fc.hp.com                                    Fort Collins, CO

Re: IGMP join/leave time variability

[David S. Miller]

Alan Cox writes:
 > > But this "small interval" is actually very noticeable in our application.
 > 
 > I suspect the small interval for the first one should be 1 not 1*HZ. That
 > would keep a little bit of jitter which is good to avoid the multicast
 > receive/join group problem

I've changed it to "1" in my sources.  Thanks.

Later,
David S. Miller
davem@redhat.com

Re: 2.4.7 + VIA Pro266 + 2xUltraTx2 lockups

[Alan Cox]

> So the system is stable when driving a single Tx2 card, or on a BX,
> but just not two Tx2's together on the pro266 board :-/ So it's
> perhaps (I'm guessing here :) a non-trivial Tx2 driver bug or maybe a
> VIA Pro266 problem?

Firstly please try 2.4.6-ac5 as that has the proper VIA workaround for their
bridge bugs. Its useful to rule out the very conservative approach the older
kernels use to avoid the disk corruption problem they had

Alan

Re: 2.4.7 + VIA Pro266 + 2xUltraTx2 lockups

[Robin Humble]

Alan Cox wrote:
>Robin Humble wrote:
>> So the system is stable when driving a single Tx2 card, or on a BX,
>> but just not two Tx2's together on the pro266 board :-/ So it's
>> perhaps (I'm guessing here :) a non-trivial Tx2 driver bug or maybe a
>> VIA Pro266 problem?
>
>Firstly please try 2.4.6-ac5 as that has the proper VIA workaround for their
>bridge bugs. Its useful to rule out the very conservative approach the older
>kernels use to avoid the disk corruption problem they had

Ok. That locked up in the same way unfortunately :-/
Also a 2.4.8-pre1-xfs that I just tried...
I tried the "noapic" option as suggested in another email and that
didn't change anything either.

We've moved all the disks and controllers to a BX m/b machine for now, but
if there's anything else you want us to be guinea pigs for them we'll be
happy to try it out on the VIA Pro266 machine.
One other odd thing is that I have yet to make the CUV266 board see any
devices on its built-in secondary IDE controller. I have no idea why that
could be... The BIOS just doesn't detect them. Might that be a related
problem? Perhaps it's a faulty motherboard? Seems unlikely.

Please CC me on any replies as I'm not subscribed... ta...

cheers,
robin

Re: Hard disk problem:

[Alan Cox]

> >  Model=IBM-DTLA-307030, FwRev=TX4OA50C, SerialNo=YKDYKGF1437
> 
> Ah, one of these excellent Hungarian DTLA drives? :) AFAIK, the entire batch
> was broken, although there are people who insist that there was no single
> working hard drive leaving that factory! I personally have seen 7 out of 7
> failing...

I have a large collection of these drives and none of them are problematic,
while the maxtors seem a little less reliable

> Take it back to where you bought it and demand a replacement for something
> NOT bearing "MADE IN HUNGARY" sign.

Of course the writer of this is Polish and the drives are Hungarian ..

Alan

Re: Hard disk problem:

[Steve Underwood]

Alan Cox wrote:
> 
> > >  Model=IBM-DTLA-307030, FwRev=TX4OA50C, SerialNo=YKDYKGF1437
> >
> > Ah, one of these excellent Hungarian DTLA drives? :) AFAIK, the entire batch
> > was broken, although there are people who insist that there was no single
> > working hard drive leaving that factory! I personally have seen 7 out of 7
> > failing...
> 
> I have a large collection of these drives and none of them are problematic,
> while the maxtors seem a little less reliable
> 
> > Take it back to where you bought it and demand a replacement for something
> > NOT bearing "MADE IN HUNGARY" sign.
> 
> Of course the writer of this is Polish and the drives are Hungarian ..
> 
But he is right. Practically all the "Made in Hungary" ones develop bad
sectors after a few months. The "Made in Phillipinnes" ones do not.
Strangely, I am Hong Kong and almost all the GXP75s we got here were
made in Hungary - go figure! They were so bad the dealers finally
wouldn't stock them. If your experience has been different, think
yourself lucky.

Regards,
Steve

Re: Hard disk problem:

[Bill Pringlemeir]

>>>>> "Steve" == Steve Underwood <steveu@coppice.org> writes:

 Steve> But he is right. Practically all the "Made in Hungary" ones
 Steve> develop bad sectors after a few months. The "Made in
 Steve> Phillipinnes" ones do not.  Strangely, I am Hong Kong and
 Steve> almost all the GXP75s we got here were made in Hungary - go
 Steve> figure! They were so bad the dealers finally wouldn't stock
 Steve> them. If your experience has been different, think yourself
 Steve> lucky.

I have an IBM drive made in Hungary.  It get `fiery hot'!  I kept
moving it until I had it in a place with good thermal contact to the
case.  Then these drive errors went away.  At first I had a Linux
install on that drive.  Later it crashed, I fixed it, deleted the OS
on my HDA that I was no longer using and moved Linux there.  Now I
only keep MP3s, tmp, and swap (a 2nd one) on the IBM drive.

Sometimes when I close the case, I still get errors.  So it may be a
case of overheating.  You could try to change the position of the drive
to see if it fixes things.  Mine was made in Hungary.  And in case (ha ha)
I am talking crap,

[bpringle@localhost bpringle]$ dmesg | grep ^hdd:
hdd: IBM-DTTA-351010, ATA DISK drive
hdd: 19807200 sectors (10141 MB) w/466KiB Cache, CHS=19650/16/63, UDMA(33)

 Model=IBM-DTTA-351010, FwRev=T56OA73A, SerialNo=WF0WFFD7387
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
 BuffType=3(DualPortCache), BuffSize=466kB, MaxMultSect=16, MultSect=off
 DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=2(fast)
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=19807200
 WARNING 3293136 ORPHANED SECTORS :: KERNEL REPORTING ERROR
 tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1 mword2
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
 UDMA modes: mode0 mode1 *mode2
 Drive Supports : ATA/ATAPI-4 T13 1153D revision 17 : ATA-1 ATA-2 ATA-3 ATA-4

fwiw,
Bill Pringlemeir.

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> > and when that hangs the kernel it will also screw up all files touched
> > just before it in a edit-make-install-try cycle. Which can be rather
> > annoying, because you can start all over again (this effect randomly
> > distributes the last touched sectors to the last touched files. Very nice
> > effect, but not something I expect from a journalled filesystem).
> > 
> Do you think it is reasonable to ask that a filesystem be designed to
> work well with bad drivers?

Its certainly a good idea. But it sounds to me like he is describing the
normal effect of metadata only logging. 

Putting a sync just before the insmod when developing new drivers is a good
idea btw

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

On Fri, 27 Jul 2001, Alan Cox wrote:

> > > and when that hangs the kernel it will also screw up all files touched
> > > just before it in a edit-make-install-try cycle. Which can be rather
> > > annoying, because you can start all over again (this effect randomly
> > > distributes the last touched sectors to the last touched files. Very nice
> > > effect, but not something I expect from a journalled filesystem).
> > >
> > Do you think it is reasonable to ask that a filesystem be designed to
> > work well with bad drivers?
>
> Its certainly a good idea. But it sounds to me like he is describing the
> normal effect of metadata only logging.
>
> Putting a sync just before the insmod when developing new drivers is a good
> idea btw

I've been doing that most of the time. But I sometimes forget that.
But as I said, it's not something I expected from a journalled filesystem.

Regards,

Bas Vermeulen

-- 
"God, root, what is difference?"
	-- Pitr, User Friendly

"God is more forgiving."
	-- Dave Aronson

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> > Putting a sync just before the insmod when developing new drivers is a good
> > idea btw
> 
> I've been doing that most of the time. But I sometimes forget that.
> But as I said, it's not something I expected from a journalled filesystem.

You misunderstand journalling then

A journalling file system can offer different levels of guarantee. With 
metadata only journalling you don't take any real performance hit but your
file system is always consistent on reboot (consistent as in fsck would pass
it) but it makes no guarantee that data blocks got written.

Full data journalling will give you what you expect but at a performance hit
for many applications.

Alan

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

On Fri, 27 Jul 2001, Alan Cox wrote:

> > > Putting a sync just before the insmod when developing new drivers is a good
> > > idea btw
> >
> > I've been doing that most of the time. But I sometimes forget that.
> > But as I said, it's not something I expected from a journalled filesystem.
>
> You misunderstand journalling then

Yup, I guess I did.

> A journalling file system can offer different levels of guarantee. With
> metadata only journalling you don't take any real performance hit but your
> file system is always consistent on reboot (consistent as in fsck would pass
> it) but it makes no guarantee that data blocks got written.

I allways thought that it could/would roll back the changes that weren't
consistent. But I stand corrected. Thanks... :)

> Full data journalling will give you what you expect but at a performance hit
> for many applications.

Do any of the other journalled filesystems for linux do this? If not, I
guess I'll go back to ext2.

Bas Vermeulen

-- 
"God, root, what is difference?"
	-- Pitr, User Friendly

"God is more forgiving."
	-- Dave Aronson

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> > Full data journalling will give you what you expect but at a performance hit
> > for many applications.
> 
> Do any of the other journalled filesystems for linux do this? If not, I
> guess I'll go back to ext2.

ext3 can do full data journalling, I dont know if reiserfs has an option for
it or not

Alan

Re: ReiserFS / 2.4.6 / Data Corruption

[Matthew Gardiner]

On Saturday 28 July 2001 01:39, Alan Cox wrote:
> > > Putting a sync just before the insmod when developing new drivers is a
> > > good idea btw
> >
> > I've been doing that most of the time. But I sometimes forget that.
> > But as I said, it's not something I expected from a journalled
> > filesystem.
>
> You misunderstand journalling then
>
> A journalling file system can offer different levels of guarantee. With
> metadata only journalling you don't take any real performance hit but your
> file system is always consistent on reboot (consistent as in fsck would
> pass it) but it makes no guarantee that data blocks got written.
>
> Full data journalling will give you what you expect but at a performance
> hit for many applications.
>
> Alan

Just in regards to full journalling, will/is there an option in ReiserFS to 
allow it? Personally, I would much rather have full journalling, and a little 
more of a performance hit for security and reliability, than great 
performance and a higher level of risk.

Matthew Gardiner
-- 
WARNING:

This email was written on an OS using the viral 'GPL' as its license.

Please check with Bill Gates before continuing to read this email/posting.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: ReiserFS / 2.4.6 / Data Corruption

[Stephen C. Tweedie]

Hi,

On Fri, Jul 27, 2001 at 02:39:37PM +0100, Alan Cox wrote:

> > I've been doing that most of the time. But I sometimes forget that.
> > But as I said, it's not something I expected from a journalled filesystem.
> 
> You misunderstand journalling then
> 
> A journalling file system can offer different levels of guarantee. With 
> metadata only journalling you don't take any real performance hit but your
> file system is always consistent on reboot (consistent as in fsck would pass
> it) but it makes no guarantee that data blocks got written.

The default behaviour of ext3 does make this guarantee, for what it's
worth.  If you want the more relaxed mode which doesn't enforce the
flushing of data blocks before a commit, you need to mount with "-o
data=writeback".

> Full data journalling will give you what you expect but at a performance hit
> for many applications.

You can achieve the necessary ordering to avoid stale data blocks
after a crash without the penalty of writing all the data to the
journal.

Cheers,
 Stephen

Re: ReiserFS / 2.4.6 / Data Corruption

[Philip R. Auld]

Alan Cox wrote:
> 
> Its certainly a good idea. But it sounds to me like he is describing the
> normal effect of metadata only logging.
> 

Which brings up something I have been struggling with lately:

Linux (using both ext2 and reiserfs) can show garbage data blocks at the end of
files after a crash. With reiserfs this is clearly due to metadata only logging
and happens say 3 out of 5 times. With ext2 the frequency is about 1 in 5 times,
and more often that not it is simply zeroed data. Sometimes it is old data
though. 


This is something that is not present in other unix filesystems as far as I can
tell. If linux wants to be used in enterprise sites we can't allow 
old data blocks to be read. And ideally shouldn't allow zero blocks to be seen
either, but this is somewhat less serious.

I cannot reproduce this in ufs on either freebsd or solaris8.

I have not tested it with xfs and jfs for linux yet (and don't have any native
systems at hand.)

I believe vxfs to have a mechanism to prevent this despite metadata only
logging.

reiserfs with full data logging enabled of course does not show this behavior
(and works really well if you are willing to take the performance hit).

The basic test I use is to run this perl script for a while (to make sure at
least somehting has had a chance to get written out) and then power-cycle the
machine. When it comes back a simple tail logfile will show the problem. I also
run bonnie before hand to fill the disk with a known pattern so its easier to
spot.

linux is 2.2.16 and 2.4.2 from redhat 7.1. reiserfs is 3.5.33 and was tested
only on 2.2.16.


#!/usr/bin/perl
use Fcntl;
$count = 0;
while (1) {
#sysopen(FH, "/scratch/logfile", O_RDWR|O_APPEND|O_CREAT|O_SYNC)
sysopen(FH, "/scratch/logfile", O_RDWR|O_APPEND|O_CREAT)
        or die "Couldn't open file $path : $!\n";
print FH "Log file line ", $count , " yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda \n" ;
close (FH);
#print $count , "\n";
$count++;
}


------------------------------------------------------
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St, Marlboro, MA 01752        (508)786-9444

Re: ReiserFS / 2.4.6 / Data Corruption

[Jordan]

"Philip R. Auld" wrote:
> 
> Alan Cox wrote:
> >
> > Its certainly a good idea. But it sounds to me like he is describing the
> > normal effect of metadata only logging.
> >
> 
> Which brings up something I have been struggling with lately:
> 
> Linux (using both ext2 and reiserfs) can show garbage data blocks at the end of
> files after a crash. With reiserfs this is clearly due to metadata only logging
> and happens say 3 out of 5 times. With ext2 the frequency is about 1 in 5 times,
> and more often that not it is simply zeroed data. Sometimes it is old data
> though.
> 
> This is something that is not present in other unix filesystems as far as I can
> tell. If linux wants to be used in enterprise sites we can't allow
> old data blocks to be read. And ideally shouldn't allow zero blocks to be seen
> either, but this is somewhat less serious.
> 
> I cannot reproduce this in ufs on either freebsd or solaris8.
> 
> I have not tested it with xfs and jfs for linux yet (and don't have any native
> systems at hand.)
> 
> I believe vxfs to have a mechanism to prevent this despite metadata only
> logging.
> 
> reiserfs with full data logging enabled of course does not show this behavior
> (and works really well if you are willing to take the performance hit).
> 
> The basic test I use is to run this perl script for a while (to make sure at
> least somehting has had a chance to get written out) and then power-cycle the
> machine. When it comes back a simple tail logfile will show the problem. I also
> run bonnie before hand to fill the disk with a known pattern so its easier to
> spot.
> 
> linux is 2.2.16 and 2.4.2 from redhat 7.1. reiserfs is 3.5.33 and was tested
> only on 2.2.16.
> 
> #!/usr/bin/perl
> use Fcntl;
> $count = 0;
> while (1) {
> #sysopen(FH, "/scratch/logfile", O_RDWR|O_APPEND|O_CREAT|O_SYNC)
> sysopen(FH, "/scratch/logfile", O_RDWR|O_APPEND|O_CREAT)
>         or die "Couldn't open file $path : $!\n";
> print FH "Log file line ", $count , " yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda \n" ;
> close (FH);
> #print $count , "\n";
> $count++;
> }
> 
> ------------------------------------------------------
> Philip R. Auld, Ph.D.                  Technical Staff
> Egenera Corp.                        pauld@egenera.com
> 165 Forest St, Marlboro, MA 01752        (508)786-9444
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

I didn't know that there was a way to enable full data journaling using
reiserfs.  I was under the impression that with the latest round of the
unlink patch to go with 2.4.7 that reiserfs was basically in ordered
journaling mode instead of writeback (I believe that is the name), if I
am wrong or if there really is a way to enable full data journaling
please let me know.  Thanks.

Jordan

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

"Philip R. Auld" wrote:
 
> reiserfs with full data logging enabled of course does not show this behavior
> (and works really well if you are willing to take the performance hit).

Hmmm, I didn't realize this had made off our wish list and into the code.:)
We should benchmark the cost to performance.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Philip R. Auld]

Hans Reiser wrote:
> 
> "Philip R. Auld" wrote:
> 
> > reiserfs with full data logging enabled of course does not show this behavior
> > (and works really well if you are willing to take the performance hit).
> 
> Hmmm, I didn't realize this had made off our wish list and into the code.:)
> We should benchmark the cost to performance.
> 
> Hans

Ooops, hope I'm not getting Chris in trouble ;)

This is reiserfs 3.5.33, with a few changes from Chris to enable full logging, 
and from me to make it a mount option. 

We are in a situation where we need the safety more than the speed so it was
necessary.


Here is a simple comparison using bonnie:

              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
pblade 1 (reiserfs defaults)
         1000 13048 98.9 21609 27.4  6599 10.7 11066 72.3 16483  8.4 1011.2  5.3 
	 1000 12771 96.7 21058 25.9  5536  9.0 10430 67.5 17347  8.4 1065.2  6.7 
	 1000 13034 98.6 19746 21.6  7026 11.6  9884 64.4 14838  7.2 1106.0  9.7
         1000 13091 99.3 19483 28.9  7586 12.3 10520 68.4 14685  6.9  900.9  6.3
pblade 2 (ext2 defaults)
         1000 14373 99.9 14940  8.8  7494 11.1 10093 65.3 22213  9.3 1028.3 
6.4      
	 1000 14305 99.6 16129  9.4  7768 11.9  9629 62.2 26108 10.8 1135.8  7.7    
	 1000 14400 99.9 16769  9.8  7397 11.2  9805 63.4 21820  9.1 1139.8  5.7
	 1000 14361 100. 17089 10.4  7768 11.5  9924 64.1 24154  9.8 1112.9  7.2
pblade 3 (log all data)
	 1000  5932 47.6  7244 12.5  4708  9.7 13909 90.5 17051  8.1 894.5  6.5
	 1000  5839 46.9  7229 12.5  4604  9.9 13437 87.9 19852  9.7 724.3  4.7
	 1000  5853 47.0  7176 12.3  4611  9.8 13995 91.1 18838  8.7 908.0  5.7
	 1000  5604 45.1  7106 12.2  4627  9.5 13628 88.6 15248  6.9 882.9  6.6
pblade 6 ( log new data )
	 1000  5556 49.0  7057 11.9  7714 12.6 11559 92.8 18075  8.8 1264.3  7.3    
	 1000  5631 49.8  7307 12.3  7945 13.0 11558 93.0 18859  9.0 1230.7  8.0
	 1000  5610 49.6  7337 12.5  6620 11.0 11821 95.0 16484  7.5 1236.8  9.3
	 1000  5592 49.4  7070 12.1  7422 12.0 11575 92.9 16198  7.3 1236.6  4.9


I suugest we move this to reiserfs-list for more discussion if needed :)


Cheers,

Phil


------------------------------------------------------
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St, Marlboro, MA 01752        (508)786-9444

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Alan Cox wrote:
> 
> > > and when that hangs the kernel it will also screw up all files touched
> > > just before it in a edit-make-install-try cycle. Which can be rather
> > > annoying, because you can start all over again (this effect randomly
> > > distributes the last touched sectors to the last touched files. Very nice
> > > effect, but not something I expect from a journalled filesystem).
> > >
> > Do you think it is reasonable to ask that a filesystem be designed to
> > work well with bad drivers?
> 
> Its certainly a good idea. 
I think it is a terrible idea.... at least as a general expectation to meet, there may be specifics
where things can be done though.... like journaling....

> But it sounds to me like he is describing the
> normal effect of metadata only logging.

Ah, right you are.  Now I understand him.  Well, data-journaling that doesn't cost a whole lot of
performance awaits reiser4, and reiser4 is at least a year away, we are doing seminars and
pseudo-coding now.

> 
> Putting a sync just before the insmod when developing new drivers is a good
> idea btw

This makes a lot of sense to me.  Good suggestion.  It should go into our FAQ.  Dad, please put it
there.

Q: I like to dynamically load buggy drivers into the kernel because that is what kernel developers
like me do for fun, how can I better avoid data corruption when doing this and using ReiserFS?

A: Do sync before insmod.  (Alan Cox's good suggestion.)

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> This is something that is not present in other unix filesystems as far as I can
> tell. If linux wants to be used in enterprise sites we can't allow 
> old data blocks to be read. And ideally shouldn't allow zero blocks to be seen
> either, but this is somewhat less serious.

> I cannot reproduce this in ufs on either freebsd or solaris8.

It can happen on UFS. What normally happens on UFS is that you get an old
file attached to a new filename when the file is deleted and the inode
reused.

Basically it can happen on any no data logging fs (with a few exceptions for
other clever algorithms like tree-phase)

If you write the metadata block first (UFS) then there is a risk of getting
someone elses data appended to the end of a file (eg length updated before
data blocks). If you write data first there is a risk of writing the data
and never committing the removal of the block from previous files.

FreeBSD softupdates probably make it very hard to trigger and they are a
very nice approach

Re: ReiserFS / 2.4.6 / Data Corruption

[Matthew Gardiner]

I've noticed that in the menuconfig there is support for the Vertias 
Journalling File System. Has there been any push for that to be a "bootable" 
filesystem so it can be used for Linux?

Matthew Gardiner
-- 
WARNING:

This email was written on an OS using the viral 'GPL' as its license.

Please check with Bill Gates before continuing to read this email/posting.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> I've noticed that in the menuconfig there is support for the Vertias 
> Journalling File System. Has there been any push for that to be a "bootable" 
> filesystem so it can be used for Linux?

The Linux freevxfs module is read only currently. Veritas apparently will be
releasing the genuine article for Linux but binary only with all the mess
that entails

binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Jeff Garzik]

Alan Cox wrote:
> The Linux freevxfs module is read only currently. Veritas apparently will be
> releasing the genuine article for Linux but binary only with all the mess
> that entails

Isn't that a violation of the GPL, to release binary modules?

-- 
Jeff Garzik      | "Mind if I drive?" -Sam
Building 1024    | "Not if you don't mind me clawing at the dash
MandrakeSoft     |  and shrieking like a cheerleader." -Max

Re: binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Andreas Dilger]

Jeff Garzik writes:
> Alan Cox wrote:
> > The Linux freevxfs module is read only currently. Veritas apparently will be
> > releasing the genuine article for Linux but binary only with all the mess
> > that entails
> 
> Isn't that a violation of the GPL, to release binary modules?

Noooooo....  Not this thread again.

Cheers, Andreas
-- 
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Rik van Riel]

On Sat, 28 Jul 2001, Jeff Garzik wrote:
> Alan Cox wrote:
> > The Linux freevxfs module is read only currently. Veritas apparently will be
> > releasing the genuine article for Linux but binary only with all the mess
> > that entails
>
> Isn't that a violation of the GPL, to release binary modules?

Binary modules using only the interfaces exported in /proc/ksyms
are, under certain readings of the GPL, no less "infected" by the
GPL than binary programs making system calls.

This means binary only modules are ok, as long as they don't need
changes in the kernel to work.

regards,

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

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Richard Gooch]

Jeff Garzik writes:
> Alan Cox wrote:
> > The Linux freevxfs module is read only currently. Veritas apparently will be
> > releasing the genuine article for Linux but binary only with all the mess
> > that entails
> 
> Isn't that a violation of the GPL, to release binary modules?

Linus said it's OK. I know Alan doesn't agree, but that's life :-)
The king penguin has spoken.

I don't see the need to be bloody-minded on this issue. If a vendor
wants to go through the pain of tracking kernel drift and having to
compile modules for many different versions, then let them. Given how
much trouble it is, why bother them with legal threats?

The right answer for vendors who want to ship binary modules is to
ship an Open Source interface layer which shields the vendor from
kernel drift (since users will be able to build the interface layer if
they need to, without waiting for the vendor).
I guess that would also shield them from unhelpful legal threats.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: ReiserFS / 2.4.6 / Data Corruption

[Matthew Gardiner]

On Sunday 29 July 2001 04:25, Alan Cox wrote:
> > I've noticed that in the menuconfig there is support for the Vertias
> > Journalling File System. Has there been any push for that to be a
> > "bootable" filesystem so it can be used for Linux?
>
> The Linux freevxfs module is read only currently. Veritas apparently will
> be releasing the genuine article for Linux but binary only with all the
> mess that entails

tsk tsk tsk. A bit disappointing that Vertias has taken that approach. 
However, even still, reiserFS is pretty awsome. Extremely fast and space 
efficient, esp on a 60gig drive ;)

Matthew Gardiner
-- 
WARNING:

This email was written on an OS using the viral 'GPL' as its license.

Please check with Bill Gates before continuing to read this email/posting.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

On Sun, Jul 29, 2001 at 10:15:03PM +1200, Matthew Gardiner wrote:

    tsk tsk tsk. A bit disappointing that Vertias has taken that approach. 
    However, even still, reiserFS is pretty awsome. Extremely fast and space 
    efficient, esp on a 60gig drive ;)

Why "tsk tsk tsk" ?  If reiserfs suits you, use it --- you need never
go near VXFS.

Personally, even though I use reiserfs, I am of the opinion that XFS,
and VXFS and both superior, especially when you include volume
management.  Time will show whether or not these very well designed
file-systems are suitable under Linux though, as reiserfs has a
considerable head start.



  --cw

Re: ReiserFS / 2.4.6 / Data Corruption

[Luigi Genoni]

On Sun, 29 Jul 2001, Chris Wedgwood wrote:

> On Sun, Jul 29, 2001 at 10:15:03PM +1200, Matthew Gardiner wrote:
>
>     tsk tsk tsk. A bit disappointing that Vertias has taken that approach.
>     However, even still, reiserFS is pretty awsome. Extremely fast and space
>     efficient, esp on a 60gig drive ;)
>
> Why "tsk tsk tsk" ?  If reiserfs suits you, use it --- you need never
> go near VXFS.
It depends, for example if you have to manage a farm (let's say 800
systems) with many Unixes
around, where solaris is the 70% of your installed basis, then
veritas (mainly the VM) could be a solution to keep an uniform
environment. That is a good thing if your sysadmin staff is composed also
by people without a real high skill.
>
> Personally, even though I use reiserfs, I am of the opinion that XFS,
> and VXFS and both superior, especially when you include volume
> management.
a journaling filesystem and a volume manager are two complementary
and usefull things, but anyway are  different things.
While i do agree that Linux LVM is still not complitelly usable in a
production environment, (but anyway ELVM from IBM is somehow immmature),
and some details of its design are not completely, how can I say...,
suitable for future HW developments, I found reiserFS tecnology to be
really interesting. On a technological point of view reiserFS is much
more advanced in front of any other journaled FS around.

I still have to see vxfs with Linux, but i saw it under solaris and HP-UX
(i think I used all journaled aroung, jfs, xfs, reiserFS, ext3, vxfs, gfs,
on all unixes i could), seeing it to too much slow on high end scsi HW,
and XFS on my origin 2000 (8 processor) sometimes takes one CPU just to
manage journaling under heavy I/O. Under Linux xfs is maybe better that
under Irix (!!!???), but its tecnology was thinked for other kind of HW,
and an experienced sysadmin can "feel" this.
> Time will show whether or not these very well designed
> file-systems are suitable under Linux though, as reiserfs has a
> considerable head start.
Yes, time will show. reiserFS can have a wonderfull future, better than
ext3 if it will be mature before ext3, worse if after. But for Linux
jfs and xfs are interesting right now, just untill native journaled will
be ready, then i would bet everyone will stay with reiserFS or ext3, not
considering any other solution.

Luigi

missing symbols in 2.4.7-ac2

[Thomas Kotzian]

when compiling with highmem = 4GB
problem in 3c59x - module:
unresolved symbol nr_free_highpages ...

ThomasK.

Re: missing symbols in 2.4.7-ac2

[Andrew Morton]

Thomas Kotzian wrote:
> 
> when compiling with highmem = 4GB
> problem in 3c59x - module:
> unresolved symbol nr_free_highpages ...
> 

Ah.  Sorry.

Alan, is it OK to export this symbol?


--- linux-2.4.7-ac1/kernel/ksyms.c	Sun Jul 29 11:43:01 2001
+++ ac/kernel/ksyms.c	Sun Jul 29 11:43:05 2001
@@ -122,6 +122,7 @@ EXPORT_SYMBOL(kmap_high);
 EXPORT_SYMBOL(kunmap_high);
 EXPORT_SYMBOL(highmem_start_page);
 EXPORT_SYMBOL(create_bounce);
+EXPORT_SYMBOL(nr_free_highpages);
 #endif
 
 /* filesystem internal functions */

Re: missing symbols in 2.4.7-ac2

[Hugh Dickins]

On Sun, 29 Jul 2001, Andrew Morton wrote:
> Thomas Kotzian wrote:
> > when compiling with highmem = 4GB
> > problem in 3c59x - module:
> > unresolved symbol nr_free_highpages ...
> 
> Ah.  Sorry.
> Alan, is it OK to export this symbol?

Laconic version: "Probably not: si_meminfo() is your friend".

Verbose version:
I don't think you really want nr_free_highpages(), that's transient
info - it won't usually fall so low as 0 if there is highmem, but do
you want to rely on that?  And nr_free_highpages() is CONFIG_HIGHMEM
only, so you'd need #ifdef CONFIG_HIGHMEM around its call in 3c59x.c.

But si_meminfo() is already exported: I think sysinfo.totalhigh is
what you want to check; if I'm wrong, and you really are interested
in whether there are currently free highpages, sysinfo.freehigh
gives you that too without needing a new export.

(I think there probably will be a need for new interfaces
to export more per-zone memory info, but not for this.)

Hugh

--- linux-2.4.7-ac2/drivers/net/3c59x.c	Sat Jul 28 07:12:03 2001
+++ linux/drivers/net/3c59x.c	Sun Jul 29 10:53:31 2001
@@ -1299,8 +1299,11 @@
 	/* The 3c59x-specific entries in the device structure. */
 	dev->open = vortex_open;
 	if (vp->full_bus_master_tx) {
+		struct sysinfo sysinfo;
+
 		dev->hard_start_xmit = boomerang_start_xmit;
-		if (nr_free_highpages() == 0) {
+		si_meminfo(&sysinfo);
+		if (sysinfo.totalhigh == 0) {
 			/* Actually, it still should work with iommu. */
 			dev->features |= NETIF_F_SG;
 		}

Re: missing symbols in 2.4.7-ac2

[Andrew Morton]

Hugh Dickins wrote:
> 
> On Sun, 29 Jul 2001, Andrew Morton wrote:
> > Thomas Kotzian wrote:
> > > when compiling with highmem = 4GB
> > > problem in 3c59x - module:
> > > unresolved symbol nr_free_highpages ...
> >
> > Ah.  Sorry.
> > Alan, is it OK to export this symbol?
> 
> Laconic version: "Probably not: si_meminfo() is your friend".

:)

> Verbose version:
> I don't think you really want nr_free_highpages(), that's transient
> info - it won't usually fall so low as 0 if there is highmem, but do
> you want to rely on that?

Prefer not to.  We want to know "does the system have any highmem
pages".  I didn't know about sysinfo.totalhigh, so I used
nr_free_highpages(), which answers the question "does the system
have any free high pages right now".

It's good enough - if we get it wrong (system was very low on memory
when the driver was initialised) the driver will work - it just won't
perform zerocopy optimisations.

>  And nr_free_highpages() is CONFIG_HIGHMEM
> only, so you'd need #ifdef CONFIG_HIGHMEM around its call in 3c59x.c.

That's OK actually - nr_free_highpages() evaluates to constant zero if
CONFIG_HIGHMEM isn't defined.


--- linux-2.4.7-ac2/drivers/net/3c59x.c Sat Jul 28 07:12:03 2001
+++ linux/drivers/net/3c59x.c   Sun Jul 29 10:53:31 2001
@@ -1299,8 +1299,11 @@
        /* The 3c59x-specific entries in the device structure. */
        dev->open = vortex_open;
        if (vp->full_bus_master_tx) {
+               struct sysinfo sysinfo;
+
                dev->hard_start_xmit = boomerang_start_xmit;
-               if (nr_free_highpages() == 0) {
+               si_meminfo(&sysinfo);
+               if (sysinfo.totalhigh == 0) {
                        /* Actually, it still should work with iommu. */
                        dev->features |= NETIF_F_SG;
                }

Much preferable!  Thanks.

I've checked all the architectures.  Looks fine, works OK.  Alan, please
apply this one.

-

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Hellwig]

In article <01072902183404.02683@kiwiunixman.nodomain.nowhere> you wrote:
> I've noticed that in the menuconfig there is support for the Vertias 
> Journalling File System. Has there been any push for that to be a "bootable" 
> filesystem so it can be used for Linux?

I don't see any reason wht it shoudn't be bootable, I just haven't tested it
yet.  If you want to try it, please follow the below steps:

1) Get one of these CD-ROM readonly distribution
2) Copy it over NFS to a UnixWare (or any other x86 System with VxFS)
3) Make a VxFS system big enough for the distribution
4) Copy the Distribution on the VxFS filesystem

And now the difficult part:

5) Adjust the ondisk dev_t to match Linux's major/minor split instead
   of SVR4's.  This can either be done by creating (bogus) SVR4 device
   nodes that are valid Linux ones when read by Linux or by doing this
   with fsdb after they were created.

If you have success with this sppropeach please drop me a mail - I'll add
it to the freevxfs docs then.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> Don't use RedHat with ReiserFS, they screw things up so many ways.....
> For instance, they compile it with the wrong options set, their boot scripts are wrong, they just
> shovel software onto the CD.

Sorry Hans you can rant all you like but you know you are wrong on most
of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
and didn't ship until we stopped seeing corruption problems with the mm/fs
code. 

That test suite caught bugs in kernel revisions other vendors shipped
blindly to their customers without fixing.

That is hardly shovelling software onto the CD.

> Actually, I am curious as to exactly how they manage to make ReiserFS boot longer than ext2.  Do
> they run fsck or what?

No. The only thing I can think of that might slow it is that we build with
the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was
done the kernel list was awash with reiserfs bug reports and Chris Mason
tail recursion bug patch of the week.

That might be something to check to get a fair comparison

Alan

Re: ReiserFS / 2.4.6 / Data Corruption

[Joshua Schmidlkofer]

On Friday 27 July 2001 09:06 am, Alan Cox wrote:
> > Don't use RedHat with ReiserFS, they screw things up so many ways.....
> > For instance, they compile it with the wrong options set, their boot
> > scripts are wrong, they just shovel software onto the CD.
>
> Sorry Hans you can rant all you like but you know you are wrong on most
> of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
> and didn't ship until we stopped seeing corruption problems with the mm/fs
> code.
>
> That test suite caught bugs in kernel revisions other vendors shipped
> blindly to their customers without fixing.
>
> That is hardly shovelling software onto the CD.
>
> > Actually, I am curious as to exactly how they manage to make ReiserFS
> > boot longer than ext2.  Do they run fsck or what?
>
> No. The only thing I can think of that might slow it is that we build with
> the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was
> done the kernel list was awash with reiserfs bug reports and Chris Mason
> tail recursion bug patch of the week.
>
> That might be something to check to get a fair comparison

   I feel that things are actually progressing above my level of perception 
here, however, I would like to mention that since my Redhat 4.x days i have 
feared vendor kernels, and I never use them, for better or worse.   

    Also, maybe I screwed my own system - I don't think so, but maybe.  I 
prefer to stick with Linus's kernels, and sometimes, depending on the 
changlog -ac kernels.  As far as the kernel & init scirpts are concerned, I 
axed any fsck'ing entries for reiserfs.   [I assume that they were 
unnessecary.]  I used kgcc [w/Rh7.1] to compile kernels, until recently.  And 
I stayed current with the lkml, and the namesys page watching for obvious 
updates that I needed. 

    The slowness [seemed] actually [to be] the process of starting & stopping 
daemons.  Almost like there was some sort of stigma about reading shell 
scripts.  All the binaries executed with appropriate haste.

   As far as shoveling code.   Sometimes the options used to compile packages 
leaves me with a large bit of wonder.  Strange and seemingly heinous changes 
to the various utilities, etc.   But, I have never had a cause to fault them 
based on this. [Except that I have never found the magic that causes all the 
SRPMS to be [re]buildable.]

  So to sort it, I don't feel that being a moron caused to boot slow - unless 
there is some wierd filehandling problem in bash2, or something that causes 
severe slow-down when sourcing shell scripts.  ????   However, Hans, I do 
beleive you about Suse, and if I wasn't a cheap bastard I would probably buy 
a copy.  

thanks for all the response, and I am sorry if this does not belong here.

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Well, I am afraid this is much too vague for me to have any understanding of what went wrong on your
system.

Maybe somebody else who is using both ReiserFS and RedHat's boot scripts can comment on whether
things are slow for them and if so, where they get slow.

With this lack of specificity is entirely possible that things went slow for coincidental reasons
unrelated to ReiserFS (waiting for network stuff to timeout, etc.)

Hans

Joshua Schmidlkofer wrote:
> 
> On Friday 27 July 2001 09:06 am, Alan Cox wrote:
> > > Don't use RedHat with ReiserFS, they screw things up so many ways.....
> > > For instance, they compile it with the wrong options set, their boot
> > > scripts are wrong, they just shovel software onto the CD.
> >
> > Sorry Hans you can rant all you like but you know you are wrong on most
> > of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
> > and didn't ship until we stopped seeing corruption problems with the mm/fs
> > code.
> >
> > That test suite caught bugs in kernel revisions other vendors shipped
> > blindly to their customers without fixing.
> >
> > That is hardly shovelling software onto the CD.
> >
> > > Actually, I am curious as to exactly how they manage to make ReiserFS
> > > boot longer than ext2.  Do they run fsck or what?
> >
> > No. The only thing I can think of that might slow it is that we build with
> > the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was
> > done the kernel list was awash with reiserfs bug reports and Chris Mason
> > tail recursion bug patch of the week.
> >
> > That might be something to check to get a fair comparison
> 
>    I feel that things are actually progressing above my level of perception
> here, however, I would like to mention that since my Redhat 4.x days i have
> feared vendor kernels, and I never use them, for better or worse.
> 
>     Also, maybe I screwed my own system - I don't think so, but maybe.  I
> prefer to stick with Linus's kernels, and sometimes, depending on the
> changlog -ac kernels.  As far as the kernel & init scirpts are concerned, I
> axed any fsck'ing entries for reiserfs.   [I assume that they were
> unnessecary.]  I used kgcc [w/Rh7.1] to compile kernels, until recently.  And
> I stayed current with the lkml, and the namesys page watching for obvious
> updates that I needed.
> 
>     The slowness [seemed] actually [to be] the process of starting & stopping
> daemons.  Almost like there was some sort of stigma about reading shell
> scripts.  All the binaries executed with appropriate haste.
> 
>    As far as shoveling code.   Sometimes the options used to compile packages
> leaves me with a large bit of wonder.  Strange and seemingly heinous changes
> to the various utilities, etc.   But, I have never had a cause to fault them
> based on this. [Except that I have never found the magic that causes all the
> SRPMS to be [re]buildable.]
> 
>   So to sort it, I don't feel that being a moron caused to boot slow - unless
> there is some wierd filehandling problem in bash2, or something that causes
> severe slow-down when sourcing shell scripts.  ????   However, Hans, I do
> beleive you about Suse, and if I wasn't a cheap bastard I would probably buy
> a copy.
> 
> thanks for all the response, and I am sorry if this does not belong here.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Rohland]

Hi Hans,

On Fri, 27 Jul 2001, Hans Reiser wrote:
> Maybe somebody else who is using both ReiserFS and RedHat's boot
> scripts can comment on whether things are slow for them and if so,
> where they get slow.

At least not if it's not the root disk. I have a RH71 box with a 19GB
reiserfs partition and it's booting fast and fine.

Greetings
		Christoph

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Christoph Rohland wrote:
> 
> Hi Hans,
> 
> On Fri, 27 Jul 2001, Hans Reiser wrote:
> > Maybe somebody else who is using both ReiserFS and RedHat's boot
> > scripts can comment on whether things are slow for them and if so,
> > where they get slow.
> 
> At least not if it's not the root disk. I have a RH71 box with a 19GB
> reiserfs partition and it's booting fast and fine.
> 
> Greetings
>                 Christoph
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Ok, well then I conclude that it was a user misdiagnosis as to what his booting problem was of some
unknowable form.

Apologies to RedHat.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Dustin Byford]

Hans Reiser wrote:

> Maybe somebody else who is using both ReiserFS and RedHat's boot scripts can comment on whether
> things are slow for them and if so, where they get slow.


For what it's worth I just configured a RedHat 7.1 box with reiserfs on 
all partitions except /boot using this update disk 
ftp://139.82.28.40/pub/update-rh71reiser-v1.img from 
http://cambuca.ldhs.cetuc.puc-rio.br/.

Upgraded all of redhat's packages, note there is a SysVinit update and a 
gcc update.

Compiled a 2.4.7-pre kernel and the latest reiserfsprogs.

Mounted /boot read only to eliminate the chance of an fsck required on 
that partition.

I have been running reiserfs on a mail server with about 60k accounts 
(30k really active) for about 6 months. I haven't experienced any 
problems with the filesystems. The one I just configured is its intended 
replacment. After a few days of testing with bonnie, some perl scripts I 
wrote, and a few pullings of the power cord I think it's almost ready 
for production. An upgrade to 2.4.7 and some more testing will tell.

If you pull the plug on this machine it takes around 40 seconds to get 
back to the login prompt, (p3-600 60G ide drive). Including the act of 
pulling the power cord, bios delays, lilo delays, and the rest of the 
redhat boot sequence.

So, in my experience I've had very few problems with reiserfs and 
redhat. That said, the slightest hint of data corruption under normal 
(continuous power, no failing hardware) operation and I'll probably be 
evaluating other filesystems. There are sometimes as many as 500,000 
files on this filesystem, reiserfs seems to do a good job under my 
conditions.

				--Dustin

Also, one purely cosmetic patch to rc.sysinit if you want:
--- rc.sysinit.orig Fri Jul 27 13:06:58 2001
+++ rc.sysinit Fri Jul 27 13:38:25 2001
@@ -211,7 +211,8 @@

_RUN_QUOTACHECK=0
ROOTFSTYPE=`grep " / " /proc/mounts | awk '{ print $3 }'`
-if [ -z "$fastboot" -a "$ROOTFSTYPE" != "nfs" ]; then
+if [ -z "$fastboot" -a "$ROOTFSTYPE" != "nfs" \
+ -a "$ROOTFSTYPE" != "reiserfs" ]; then

STRING=$"Checking root filesystem"
echo $STRING

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Dustin Byford wrote:

> Also, one purely cosmetic patch to rc.sysinit if you want:
> --- rc.sysinit.orig Fri Jul 27 13:06:58 2001
> +++ rc.sysinit Fri Jul 27 13:38:25 2001
> @@ -211,7 +211,8 @@
> 
> _RUN_QUOTACHECK=0
> ROOTFSTYPE=`grep " / " /proc/mounts | awk '{ print $3 }'`
> -if [ -z "$fastboot" -a "$ROOTFSTYPE" != "nfs" ]; then
> +if [ -z "$fastboot" -a "$ROOTFSTYPE" != "nfs" \
> + -a "$ROOTFSTYPE" != "reiserfs" ]; then
> 
> STRING=$"Checking root filesystem"
> echo $STRING


Yes, this patch is much needed.  Edward, put it on our website in an appropriate location.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Henning P. Schmiedehausen]

Hans Reiser <reiser@namesys.com> writes:

> Well, I am afraid this is much too vague for me to have any
> understanding of what went wrong on your system.

But you were able on this vagueness of accusing Redhat to "just shovel
software on a CD". Why? Because they didn't give you money unlike some
other vendors, e.g. SuSE?

The thing that really pisses me off about ReiserFS from time to time
is not the "FS" part...

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Alan Cox wrote:
> 
> > Don't use RedHat with ReiserFS, they screw things up so many ways.....
> > For instance, they compile it with the wrong options set, their boot scripts are wrong, they just
> > shovel software onto the CD.
> 
> Sorry Hans you can rant all you like but you know you are wrong on most
> of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
> and didn't ship until we stopped seeing corruption problems with the mm/fs
> code.
> 
> That test suite caught bugs in kernel revisions other vendors shipped
> blindly to their customers without fixing.
> 
> That is hardly shovelling software onto the CD.
> 
> > Actually, I am curious as to exactly how they manage to make ReiserFS boot longer than ext2.  Do
> > they run fsck or what?
> 
> No. The only thing I can think of that might slow it is that we build with
> the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was

Yes, that option should never be on for an end user not having a bug that he wants a more detailed
bug report on.  It just makes us look slow compared to ext2.

2.4.2 was not a stable kernel for any FS, not just for ReiserFS.

2.4.4 was the earliest kernel that should have been called 2.4.0, and sad to say, I bet we won't hit
a really stable kernel for another couple of versions.

I understand the marketing pressure on distributions to ship using 2.4.x as soon as 2.4.0 was
available, and that pressure should never have been generated upon them by making an unstable kernel
be named 2.4.0.

It won't surpise me if you agree with me on the kernel naming though, and if so it is pointless for
me to complain to you about it. 

> done the kernel list was awash with reiserfs bug reports and Chris Mason
> tail recursion bug patch of the week.
> 
> That might be something to check to get a fair comparison
> 
> Alan

I don't think that even with CONFIG_REISERFS_CHECK on, journal replay can take as long as fsck on
ext2.  reiserfsck though, if that was on, oh, could even RedHat be that desperate to make us look
bad to users as to run reiserfsck at every boot?

I surely hope not, and I'd like to hear that this user just had something individually wrong with
his configuration.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Kip Macy]

> Alan Cox wrote:
> > 
> > > Don't use RedHat with ReiserFS, they screw things up so many ways.....
> > > For instance, they compile it with the wrong options set, their boot scripts are wrong, they just
> > > shovel software onto the CD.
> > 
> > Sorry Hans you can rant all you like but you know you are wrong on most
> > of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
> > and didn't ship until we stopped seeing corruption problems with the mm/fs
> > code.

Sorry Alan, but even though I am sure Redhat did lots of stress testing,
Redhat 7.1 was not a particularly solid release. I got oopses in the
eepro100 driver even though lots of other people use it, and the netapp
simulator which works just fine on 2.2.16 does not work on it. When I ran
strace on the simulator while it was zeroing some files it turned out that
sys_write was failing with ENOMEM (on a machine with 1GB of RAM that was 
not doing anything else).

Re: ReiserFS / 2.4.6 / Data Corruption

[Ville Herva]

On Fri, Jul 27, 2001 at 09:25:23AM -0700, you [Kip Macy] claimed:
>  
> sys_write was failing with ENOMEM (on a machine with 1GB of RAM that was 
> not doing anything else).

I second that.

256M memory, no swap at the time.

After fresh boot to the default RH71 kernel (2.4.2-2 or whatever it is) on
console (no X running):

> diff -Naur /usr/src/linux.rh-default /usr/src/linux-2.4.4 > diff
zsh: killed diff

> dmesg | tail
kernel: out of memory, killed process n (xfs)
kernel: out of memory, killed process n (diff)

Phew.


-- v --

v@iki.fi

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> After fresh boot to the default RH71 kernel (2.4.2-2 or whatever it is) on
> console (no X running):
> 
> > diff -Naur /usr/src/linux.rh-default /usr/src/linux-2.4.4 > diff
> zsh: killed diff
> 
> > dmesg | tail
> kernel: out of memory, killed process n (xfs)
> kernel: out of memory, killed process n (diff)
> 
> Phew.

No argument on that one. I'm still seeing it in vanilla 2.4.6 as well but
2.4.7 is looking a lot better. 

Re: ReiserFS / 2.4.6 / Data Corruption

[Ville Herva]

On Fri, Jul 27, 2001 at 06:40:32PM +0100, you [Alan Cox] claimed:
> > After fresh boot to the default RH71 kernel (2.4.2-2 or whatever it is) on
> > console (no X running):
> > 
> > > diff -Naur /usr/src/linux.rh-default /usr/src/linux-2.4.4 > diff
> > zsh: killed diff
> > 
> > > dmesg | tail
> > kernel: out of memory, killed process n (xfs)
> > kernel: out of memory, killed process n (diff)
> > 
> > Phew.
> 
> No argument on that one. I'm still seeing it in vanilla 2.4.6 as well but
> 2.4.7 is looking a lot better. 

I wasn't able to easily reproduce that on 2.4.4ac5 (that I upgraded into
almost immediately). It may be that the OOM rambo wasn't fully sane on that
one either, but at least it seemed to handle the silly "someone filled the
cache - gee, we must be oom" case rather better...


-- v --

v@iki.fi

Re: ReiserFS / 2.4.6 / Data Corruption

[Lehmann]

On Fri, Jul 27, 2001 at 04:06:16PM +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Don't use RedHat with ReiserFS, they screw things up so many ways.....
> > For instance, they compile it with the wrong options set, their boot scripts are wrong, they just
> > shovel software onto the CD.
> 
> Sorry Hans you can rant all you like but you know you are wrong on most
> of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
> and didn't ship until we stopped seeing corruption problems with the mm/fs
> code. 

You might be well advised looking at reality (visit a few other projects)
and you'll see that redhat, indeed, has a very bad reputation. Wether it's
gimp, gtk, perl, wine, dosemu or any other project, the basic reaction is:
oh, you have gt problems under redhat? you compile it yourself and most
probably your problems will go away (gtk+ even had this message in their
install script).

> That test suite caught bugs in kernel revisions other vendors shipped
> blindly to their customers without fixing.

they might have a very good testsuite, but that means nothing: redhat
so frequently takes snapshots of undebugged alpha versions of software
(higher version numbers) that no matter of testing will suffice to ever
make this work.

the might be doing well for the kernel, but that only gets you so far.

> That is hardly shovelling software onto the CD.

Right, that's shovelling the latest alpha versions of software onto CD.

> > Actually, I am curious as to exactly how they manage to make ReiserFS boot longer than ext2.  Do
> > they run fsck or what?
> No. The only thing I can think of that might slow it is that we build with
> the reiserfs paranoia/sanity checks on.

That's a pretty dumb thing. Maybe one should have asked the develoers
before doing this (they never do). Redhat somehow manages pretty well to
show reiserfs in a bad light ;)

However, ext2 is much faster on mount time with -onocheck (instantaneous);
and for all current harddisk sizes ext2 is somewhat to much slower on
mount. And yes, the redhat init system (just like suse's or most others,
of course) is sooo slow that improving the init system will have a much
larger effect than the ext2/reiserfs differences.

(So trying to improve this in the kernel would be the wrong place to
start).

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

"pcg( Marc)"@goof(A.).(Lehmann )com wrote:

> > No. The only thing I can think of that might slow it is that we build with
> > the reiserfs paranoia/sanity checks on.
> 
> That's a pretty dumb thing. Maybe one should have asked the develoers
> before doing this (they never do). Redhat somehow manages pretty well to
> show reiserfs in a bad light ;)

Let us be a bit more precise here.  If you click on the help button when deciding whether to select
that option it tells you not to do it.  What can you say about a distro that doesn't read the help
buttons for the kernel options when configuring the kernel?  Shovelware?

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> > No. The only thing I can think of that might slow it is that we build with
> > the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was
> 
> Yes, that option should never be on for an end user not having a bug that he wants a more detailed
> bug report on.  It just makes us look slow compared to ext2.

Maybe its old fashioned but we'd rather any inconsistency in the file system
behaviour was made obvious to the end user. Enterprise customers object to
losing data.

> 2.4.2 was not a stable kernel for any FS, not just for ReiserFS.

The RH 2.4.2 derived kernel isnt 2.4.2 by any stretch of the imagination. 
Vanilla 2.4.2 wouldnt pass a test suite.

> I don't think that even with CONFIG_REISERFS_CHECK on, journal replay can take as long as fsck on
> ext2.  reiserfsck though, if that was on, oh, could even RedHat be that desperate to make us look
> bad to users as to run reiserfsck at every boot?

Hans, if you stopped considering every report that your file system wasn't
the best in the world as either a conspiracy theory or someone elses fault
you'd have a much better product

Nobody needs conspiracies to not use reiserfs as their core fs, and until
things like big endian support are cleanly resolved that isnt likely to
change.

Alan

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Alan Cox wrote:

> Nobody needs conspiracies to not use reiserfs as their core fs, and until
> things like big endian support are cleanly resolved that isnt likely to
> change.
> 
> Alan
big endian support is resolved, there is a working patch for it by Jeff Mahoney, it passes all of
our tests, but it is a feature not a bug fix, and not something for a supposedly stabilizing kernel.

Nikita, you were supposed to send the big endian support and some other stuff in to Alan for testing
in the ac series, what is the status of patches that are supposed to be going to Alan?

Hans

Re: ext3-2.4-0.9.4

[Alan Cox]

> This sort of attitude is just ridiculous.  Unix had a defined set of
> semantics.  This might have been stupid semantics, but it had them.

The unix defined semantics are very simple and very clear. They btw
dont contain the guarantees that certain email system authors think they do
and they never have.

rename() itself is new as of 4BSD, rather than ever being in true unix.
True unix did the right thing. It said 'this problem is hard, this problem
is application specific, do it at application level'.

> When I contacted the Linux JFS team about the semantics of link(), I
> was told that there is _no way_ of forcing a link() to disk.  Not an
> fsync() on the file, not an fsync() on the directory, just _not
> possible_.

I would expect an fsync of the directory to do that. It does on other
Linux file systems so it violates the least suprise bit. Right now JFS
isnt a standard file system on Linux however, and they have much left to do.
I suspect its something to ask them about.

> Thus why all reasonably paranoid MTAs and other mail programs say "use
> chattr +S on ext2"---we need ordered metadata writes.

And then your IDE disk gets you anyway. Also if you write metadata first 
then you risk delivering email to the wrong person instead. 

> You want to help performance?  Give us an fsync() that works on
> multiple file descriptors at once, or an async fsync() call.  Don't
> make us fight the OS on getting data to disk.

And what pray does an asynchronous fsync do. It seems to be a nop to me.

Doing reliabile transactions on disk is a hard problem. That is why oracle
and friends have spent many man years of research on this kind of problem. 
Current unix mailers do the smoke mirrors and prayer bit to reduce the
probability a little that is all, regardless of fs and os.

Alan

Re: ext3-2.4-0.9.4

[Lawrence Greenfield]

   Date: Fri, 27 Jul 2001 17:50:29 +0100 (BST)
   Cc: linux-kernel@vger.kernel.org
   From: Alan Cox <alan@lxorguk.ukuu.org.uk>

[...]
   > Thus why all reasonably paranoid MTAs and other mail programs say "use
   > chattr +S on ext2"---we need ordered metadata writes.

   And then your IDE disk gets you anyway. Also if you write metadata first 
   then you risk delivering email to the wrong person instead. 

These are tangential issues.  Not everybody uses IDE disks.  I'm not
asking for things that are impossible.  Just because sometimes the
hardware screws you isn't a good reason for not trying to do the right
thing.

The application can avoid the wrong file problem by zeroing out data
before releasing it to the OS to reallocate.

   > You want to help performance?  Give us an fsync() that works on
   > multiple file descriptors at once, or an async fsync() call.  Don't
   > make us fight the OS on getting data to disk.

   And what pray does an asynchronous fsync do. It seems to be a nop to me.

An async fsync allows me to issue multiple fsyncs and then wait for
all of them to complete, hopefully in the same framework that I would
do async I/O (but that's an argument for another day).

   Doing reliabile transactions on disk is a hard problem. That is why oracle
   and friends have spent many man years of research on this kind of problem. 
   Current unix mailers do the smoke mirrors and prayer bit to reduce the
   probability a little that is all, regardless of fs and os.

Isn't the point of the operating system to try to make it as easy as
possible to do these things correctly?

Otherwise you force anyone who wants to write a reliable application
(be it e-mail or not) to go to Oracle and one wonders why fsync() is
even implemented.

Larry

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Friday 27 July 2001 19:41, Lawrence Greenfield wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > Lawrence Greenfield wrote:
> > > You want to help performance?  Give us an fsync() that works on
> > > multiple file descriptors at once, or an async fsync() call. 
> > > Don't make us fight the OS on getting data to disk.
> >
> > And what pray does an asynchronous fsync do. It seems to be a nop
> to me.
>
> An async fsync allows me to issue multiple fsyncs and then wait for
> all of them to complete, hopefully in the same framework that I would
> do async I/O (but that's an argument for another day).

I'll say.  While it's truly desirable, all known filesystems are *far* 
from being able to do that.  An efficient, reliable fsync would do the 
trick for you, or even an efficient sync.  And somewhere in Andrew 
Morton's bag of tricks is something to fix you up too, read his 
comments carefully.

Looking forward, a sanely defined filesystem transaction interface 
from userland would give the best possible combination of performance 
and reliability.[1]  Since we now have four filesystems (five if you 
count JFFS) that could implement such a transaction interface, now is 
the time to figure out what it would look like.  That would include 
accomodating the needs of MTA developers.  It would be Linux-specific 
for sure.  It would also be progress.  If it turned out to be the 
fastest way to run a mailer we'd see it migrate to other nixes soon 
enough.

>    Doing reliabile transactions on disk is a hard problem. That is
> why oracle and friends have spent many man years of research on this
> kind of problem.

Tell me about it ;-)

> Current unix mailers do the smoke mirrors and prayer
> bit to reduce the probability a little that is all, regardless of fs
> and os.
>
> Isn't the point of the operating system to try to make it as easy as
> possible to do these things correctly?

   begin_transaction (filesystem_handle);
   <send the mail>;
   if (!end_transaction (filesystem_handle))
	<confirm sent>;

Something like that.[2]  Caveat: this is blue-sky stuff, it is not 
going to solve your problem today.  Andrew Morton and Hans Reiser are 
working on solving the problem today by giving you at least one mode 
where rename is synchronous, or at least giving you a fast fsync.

I'm with those who think that a little short-term pain is worth it if 
the final result is superior.

> Otherwise you force anyone who wants to write a reliable application
> (be it e-mail or not) to go to Oracle and one wonders why fsync() is
> even implemented.

[1] Al Viro pointed out that such a transaction interface could open up 
new possibilities for DOS attacks, something that has to be anticipated 
in the design.

[2] I see Alan suggested essentially the same thing in another branch 
of this thread.  Then by the "million flies" theorum...

--
Daniel

Re: ext3-2.4-0.9.4

[Patrick J. LoPresti]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> Also if you write metadata first then you risk delivering email to
> the wrong person instead.

The MTAs do this:

    Open temp file
    Write to temp file
    fsync() temp file
    rename() temp file into mail spool
    indicate success to remote MTA

As long as rename() does not return until the metadata are committed,
this should be a reliable delivery mechanism.  After a crash, you
might end up with the temp file still there, or with the file having a
link count of two (temp file and spool file).  But you can clean up
all of this at boot time; if the temp file is gone and the spool file
is present, then the transaction was completed.

(Yes, you might not have returned the success code to the remote MTA,
but that just means you might do a double delivery.  That is an
acceptable failure mode; corrupting, losing, or misdirecting mail is
not.)

How does this scheme "risk delivering mail to the wrong person
instead"?

If you have metadata journalling, all you need for this algorithm to
work is to have rename() write to the journal before returning.  Is
this true for any of the current journalling file systems on Linux?

 - Pat

Re: ext3-2.4-0.9.4

[Alan Cox]

> How does this scheme "risk delivering mail to the wrong person
> instead"?

With the fsync it looks ok for most cases. It depends on the actions of
a rename touching only one disk block - which of course it doesn't do. Even
so with the fsync on a sane fs I cant see that problem occuring

> If you have metadata journalling, all you need for this algorithm to
> work is to have rename() write to the journal before returning.  Is
> this true for any of the current journalling file systems on Linux?

Ext3 I believe so, Reiserfs I would assume so but Hans can answer
definitively

Re: ext3-2.4-0.9.4

[Chris Wedgwood]

On Sat, Jul 28, 2001 at 08:03:37PM +0100, Alan Cox wrote:

    Ext3 I believe so, Reiserfs I would assume so but Hans can answer
    definitively

Reiserfs does not, nor are creates or unlink operations synchronous.

For MTAs it just happens to work: if you fsync the way transactions
are written means the metadata for the dirtectories is written as part
of the transaction --- but I think this is a quirk and not by design?

Chris?




  --cw

Re: ext3-2.4-0.9.4

[Chris Mason]

On Sunday, July 29, 2001 01:53:48 PM +1200 Chris Wedgwood <cw@f00f.org>
wrote:

> On Sat, Jul 28, 2001 at 08:03:37PM +0100, Alan Cox wrote:
> 
>     Ext3 I believe so, Reiserfs I would assume so but Hans can answer
>     definitively
> 
> Reiserfs does not, nor are creates or unlink operations synchronous.
> 
> For MTAs it just happens to work: if you fsync the way transactions
> are written means the metadata for the dirtectories is written as part
> of the transaction --- but I think this is a quirk and not by design?
> 
> Chris?

Correct, in the current 2.4.x code, its a quirk.  fsync(any object) ==
fsync(all pending metadata, including renames).

There is a transcation tracking patch floating around out there that makes
reiserfs fsync/O_SYNC much faster by only committing the last transaction a
given file/dir was involved in.  I had sent this to alan just after 2.4.7
came out, but it looks like I need to resend.

Anyway, during a rename, this patch updates the inode transaction tracking
stuff so an fsync on the file should also commit the directory changes.
But, that isn't something I really intend to advertise much, since the
accepted linux way is fsync(dir).

-chris

Re: ext3-2.4-0.9.4

[Patrick J. LoPresti]

Chris Mason <mason@suse.com> writes:

> Correct, in the current 2.4.x code, its a quirk.  fsync(any object) ==
> fsync(all pending metadata, including renames).

This does not help.  The MTAs are doing fsync() on the temporary file
and then using the *subsequent* rename() as the committing operation.

> Anyway, during a rename, this patch updates the inode transaction
> tracking stuff so an fsync on the file should also commit the
> directory changes.  But, that isn't something I really intend to
> advertise much, since the accepted linux way is fsync(dir).

It would be nice to have an option (on either the directory or the
mountpoint) to cause all metadata updates to commit to the journal
without causing all operations to be fully synchronous.  This would
provide compatibility with BSD-centric code without taking the
performance hit of synchronous data.  Heck, just having link() and
rename() perform a commit would be good enough for almost all
applications.

 - Pat

Re: ext3-2.4-0.9.4

[Alan Cox]

> Chris Mason <mason@suse.com> writes:
> 
> > Correct, in the current 2.4.x code, its a quirk.  fsync(any object) ==
> > fsync(all pending metadata, including renames).
> 
> This does not help.  The MTAs are doing fsync() on the temporary file
> and then using the *subsequent* rename() as the committing operation.

Which is quaint, because as we've pointed out repeatedly to you rename
is not an atomic operation. Even on a simple BSD or ext2 style fs it can
be two directory block writes,  metadata block writes, a bitmap write
and a cylinder group write.

> It would be nice to have an option (on either the directory or the
> mountpoint) to cause all metadata updates to commit to the journal
> without causing all operations to be fully synchronous.  This would

You mean fsync() on the directory. 

Alan

Re: ext3-2.4-0.9.4

[Patrick J. LoPresti]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > Chris Mason <mason@suse.com> writes:
> > 
> > > Correct, in the current 2.4.x code, its a quirk.  fsync(any object) ==
> > > fsync(all pending metadata, including renames).
> > 
> > This does not help.  The MTAs are doing fsync() on the temporary file
> > and then using the *subsequent* rename() as the committing operation.
> 
> Which is quaint, because as we've pointed out repeatedly to you rename
> is not an atomic operation. Even on a simple BSD or ext2 style fs it can
> be two directory block writes,  metadata block writes, a bitmap write
> and a cylinder group write.

But not on a journalling filesystem.  I assume that a journal "commit"
is atomic.  If it is not, then fsync() on the directory does not solve
the problem either.

Put another way, I am suggesting a mount-time or directory option to
effectively cause rename() and link() to automatically be followed by
an fsync() of the containing directory.  (Actually, from this
perspective, maybe you could fix the MTA in user space with LD_PRELOAD
hackery or somesuch.  Hm...)

> > It would be nice to have an option (on either the directory or the
> > mountpoint) to cause all metadata updates to commit to the journal
> > without causing all operations to be fully synchronous.  This would
> 
> You mean fsync() on the directory. 

In other words, "Get the MTA authors to change their code."  That is a
nice little war, but it is fought at the expense of users who just
want to use the code provided by their vendor and have it work.

The situation is this:

  The relevant standards (POSIX, SuS, etc.) provide no way to perform
  reliable transactions on a file system.

  BSD provides one solution, which is synchronous metatdata.  (I am
  assuming modern BSDs already deal with the multiple-disk-block
  problem to make these transactions properly atomic.  Is this
  assumption false?)

  Linux provides a different solution, which is fsync() on the
  directory.

  All MTAs, and other apps besides, currently use the BSD solution for
  reliable transactions.

Is it really so absurd to ask Linux to provide efficient support of
the BSD semantics as an option?

 - Pat

Re: ext3-2.4-0.9.4

[Rik van Riel]

On 30 Jul 2001, Patrick J. LoPresti wrote:

>   The relevant standards (POSIX, SuS, etc.) provide no way to perform
>   reliable transactions on a file system.
>
>   BSD provides one solution, which is synchronous metatdata.  (I am
>   assuming modern BSDs already deal with the multiple-disk-block
>   problem to make these transactions properly atomic.  Is this
>   assumption false?)
>
>   Linux provides a different solution, which is fsync() on the
>   directory.
>
>   All MTAs, and other apps besides, currently use the BSD solution for
>   reliable transactions.
>
> Is it really so absurd to ask Linux to provide efficient support of
> the BSD semantics as an option?

Yes. You could fix this issue in userland very easily,
it might even work with an LD_PRELOAD ...

Besides BSD softupdates and the various journaling
filesystems which are in use on other Unixen also
don't provide the 4.3BSD solution any more ...

regards,

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

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: ext3-2.4-0.9.4

[Andrew McNamara]

>> This does not help.  The MTAs are doing fsync() on the temporary file
>> and then using the *subsequent* rename() as the committing operation.
>
>Which is quaint, because as we've pointed out repeatedly to you rename
>is not an atomic operation. Even on a simple BSD or ext2 style fs it can
>be two directory block writes,  metadata block writes, a bitmap write
>and a cylinder group write.

This is almost (but not quite) irrelevant. The receiving MTA simply
wants the fsync()/rename() system call to not return until everything
(including directory blocks) have been written to disk, at which point,
it says to the remote end "250 OK". If the receiving machine goes down
at any point up until this one, the sending system will resend the
message.  (Yes, the receiving system may have a corrupt directory, and
this is a problem).

 ---
Andrew McNamara (System Architect)

connect.com.au Pty Ltd
Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia
Phone: +61 2 9409 2117, Fax: +61 2 9409 2111

Re: ext3-2.4-0.9.4

[Rik van Riel]

On 30 Jul 2001, Patrick J. LoPresti wrote:

> performance hit of synchronous data.  Heck, just having link() and
> rename() perform a commit would be good enough for almost all
> applications.

It would be "good enough" for some applications,
but it would be absolutely disastrous for most
applications I run (ie. moving source code around).

Exactly what is wrong with doing fsync() on the
directory ?

Why do you want us to turn link() and rename()
into link_slowly() and rename_slowly() ?

Why can't you use a simple wrapper function to
do this for you ?

cheers,

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

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: ext3-2.4-0.9.4

[Patrick J. LoPresti]

Rik van Riel <riel@conectiva.com.br> writes:

> Exactly what is wrong with doing fsync() on the
> directory ?

Nothing, except that it requires source code changes to every
application which expects BSD semantics for these operations.
Anecdotal evidence suggests at least the MTA authors are resistant to
making such changes.

> Why do you want us to turn link() and rename()
> into link_slowly() and rename_slowly() ?

I don't by default, only as an option.  You know, just like "chattr
-S" or "mount -o sync" means do_everything_slowly().

> Why can't you use a simple wrapper function to
> do this for you ?

It would not be all that simple; it would have to parse the arguments
to figure out the containing directories, open() a file descriptor on
each, and fsync() them.  Not impossible, but it does introduce several
those additional system calls as performance hits and points of
failure, not to mention possible race conditions.

Still, I suppose you could do this well enough in the C library.  You
might even want it to be the default when "__USE_BSD" is defined or
something.

But it still seems simpler to me just to make it an option in the file
system.

In your next message, you say:

> Besides BSD softupdates and the various journaling
> filesystems which are in use on other Unixen also
> don't provide the 4.3BSD solution any more ...

This surprises me if it is true; do you have a reference?  And what
mechanism *do* the modern BSDs provide to commit metadata changes to
disk?

 - Pat

Re: ext3-2.4-0.9.4

[Rik van Riel]

On 30 Jul 2001, Patrick J. LoPresti wrote:
> Rik van Riel <riel@conectiva.com.br> writes:
>
> > Exactly what is wrong with doing fsync() on the
> > directory ?
>
> Nothing, except that it requires source code changes to every
> application which expects BSD semantics for these operations.
> Anecdotal evidence suggests at least the MTA authors are resistant to
> making such changes.

You may need to make them anyway for Digital's AdvFS,
IRIX XFS, IBM JFS, Veritas' VXFS and BSD softupdates.

Lets face it, FFS is no longer the only available
filesystem. Don't expect FFS semantics from other
filesystems.

> > Why can't you use a simple wrapper function to
> > do this for you ?
>
> It would not be all that simple; it would have to parse the
> arguments to figure out the containing directories, open() a
> file descriptor on each, and fsync() them.

Hmmm, then maybe we'd just want some flag to fsync()
telling the kernel to also sync the parent directory
of the file and do whatever it needs to do to get the
rename() or link() committed ?

> But it still seems simpler to me just to make it an option in
> the file system.

It's always simpler when it's not YOU who has to
implement it ;)

cheers,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Mon, 30 Jul 2001, Rik van Riel wrote:

> Hmmm, then maybe we'd just want some flag to fsync()
> telling the kernel to also sync the parent directory
> of the file and do whatever it needs to do to get the
> rename() or link() committed ?

Heck, you can't tell the kernel to do rename/link/open/unlink
synchronously in-band. This list doesn't care for other OS's. The
semantics FreeBSD (e. g.) offers ARE indeed documented.

This won't work out without kernel support. Portable reliability doesn't
come for free.

chattr +S is bad (slow). bloating all applications to include every
possible brain fart that the random FS inventor let go is even worse.

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Tue, 31 Jul 2001, Matthias Andree wrote:
> On Mon, 30 Jul 2001, Rik van Riel wrote:
>
> > Hmmm, then maybe we'd just want some flag to fsync()
> > telling the kernel to also sync the parent directory
> > of the file and do whatever it needs to do to get the
> > rename() or link() committed ?
>
> Heck, you can't tell the kernel to do rename/link/open/unlink
> synchronously in-band. This list doesn't care for other OS's.
> The semantics FreeBSD (e. g.) offers ARE indeed documented.

Go back a few posts and read about the semantics
FreeBSD has when the filesystem is mounted with
softupdates.

Then take a deep breath.

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Lawrence Greenfield]

   From: "Patrick J. LoPresti" <patl@cag.lcs.mit.edu>
   Date: 	30 Jul 2001 12:46:13 -0400

   > Besides BSD softupdates and the various journaling
   > filesystems which are in use on other Unixen also
   > don't provide the 4.3BSD solution any more ...

   This surprises me if it is true; do you have a reference?  And what
   mechanism *do* the modern BSDs provide to commit metadata changes to
   disk?

BSD softupdates allows you to call fsync() on the file, and this will
sync the directories all the way up to the root if necessary.

Thus BSD fsync() actually guarantees that when it returns, the file
(and all of it's filenames) will survive a reboot.

Sendmail does:
fd = open(tmp)
write(fd)
fsync(fd)
rename(tmp, final)
fsync(fd)

Cyrus IMAP does:
fd = open(tmp)
write(fd)
fsync(fd)
link(tmp, final1)
link(tmp, final2)
link(tmp, final3)
fsync(fd)
close(fd)
unlink(tmp)

The idea that Linux fsync() doesn't actually make the file survive
reboots is pretty ridiculous.

Larry

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Mon, 30 Jul 2001, Lawrence Greenfield wrote:
>    From: "Patrick J. LoPresti" <patl@cag.lcs.mit.edu>
>    Date: 	30 Jul 2001 12:46:13 -0400
>
>    > Besides BSD softupdates and the various journaling
>    > filesystems which are in use on other Unixen also
>    > don't provide the 4.3BSD solution any more ...
>
>    This surprises me if it is true; do you have a reference?  And what
>    mechanism *do* the modern BSDs provide to commit metadata changes to
>    disk?
>
> BSD softupdates allows you to call fsync() on the file, and this will
> sync the directories all the way up to the root if necessary.
>
> Thus BSD fsync() actually guarantees that when it returns, the file
> (and all of it's filenames) will survive a reboot.

Note that this is very different from the "link() should be
synchronous()" mantra we've been hearing over the last days.

These fsync() semantics make lots of sense to me, I'm all
for it.

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Chris Wedgwood]

On Mon, Jul 30, 2001 at 02:25:51PM -0300, Rik van Riel wrote:

    Note that this is very different from the "link() should be
    synchronous()" mantra we've been hearing over the last days.
    
    These fsync() semantics make lots of sense to me, I'm all
    for it.

And what if the file has hundreds or thousands of links? How do we
cleanly keep track of all those?



  --cw

Re: ext3-2.4-0.9.4

[Lawrence Greenfield]

   Date: Tue, 31 Jul 2001 05:38:13 +1200
   From: Chris Wedgwood <cw@f00f.org>

   On Mon, Jul 30, 2001 at 02:25:51PM -0300, Rik van Riel wrote:

       Note that this is very different from the "link() should be
       synchronous()" mantra we've been hearing over the last days.

       These fsync() semantics make lots of sense to me, I'm all
       for it.

   And what if the file has hundreds or thousands of links? How do we
   cleanly keep track of all those?

You don't have to keep track of all of them, just the uncommitted
ones.  I could imagine the filesystem forcing periodic commits on
pathological files (those with thousands of links) to limit the number
of pending directory operations per file.

While the softupdates paper doesn't appear to directly address this
concern, clearly their implementation has to deal with it in some way.

Larry

Re: ext3-2.4-0.9.4

[Chris Mason]

On Monday, July 30, 2001 01:49:12 PM -0400 Lawrence Greenfield
<leg+@andrew.cmu.edu> wrote:

>    Date: Tue, 31 Jul 2001 05:38:13 +1200
>    From: Chris Wedgwood <cw@f00f.org>
> 
>    On Mon, Jul 30, 2001 at 02:25:51PM -0300, Rik van Riel wrote:
> 
>        Note that this is very different from the "link() should be
>        synchronous()" mantra we've been hearing over the last days.
> 
>        These fsync() semantics make lots of sense to me, I'm all
>        for it.
> 
>    And what if the file has hundreds or thousands of links? How do we
>    cleanly keep track of all those?
> 
> You don't have to keep track of all of them, just the uncommitted
> ones. 

Well, the idea is to get it done in the VFS layer.  reiserfs, ext3, and
probably the other journaled filesystems could keep track of the last
transacation and inode was involved with, making the softupdate style
fsync(file) to commit a rename easy.

But, ext2 and the normal filesystems don't have it quite so good.

-chris

Re: ext3-2.4-0.9.4

[Chris Wedgwood]

On Mon, Jul 30, 2001 at 01:59:04PM -0400, Chris Mason wrote:

    Well, the idea is to get it done in the VFS layer.  reiserfs, ext3, and
    probably the other journaled filesystems could keep track of the last
    transacation and inode was involved with, making the softupdate style
    fsync(file) to commit a rename easy.

But, right now, the VFS layer doesn't know about magic attributes
(such as ext2/3 +S).  The VFS would have to be taught about these and
some other things to support both asynchronous and synchronous
metadata updates (and presumably other smarts too).  The trouble is
these attributes themselves and how they are stored is fs specific, we
could always mandate that as of 2.5.x all filesystems _can_ support
some kind of extended API and defined a minimalist set of attributes
for all filesystems and then allow specific filesystems to have their
own.  Arguably if people are going to force ACLs upon the world, then
a common API would be nice across XFS, resierfs4, JFFS, etc.  (NTFS
can use an API specific to the FS itself as NTFS ACLs are much more
complex and different looking beasts that those from early POSIX
drafts).

For journalling filesystems, it would be really nice if setting an
attribute was all that was required to make rename(2) atomic (or at
the very least to make sure that if the rename system call returns,
the data has been written to non-volatile storage).



  --cw

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Mon, 30 Jul 2001, Rik van Riel wrote:

> > Thus BSD fsync() actually guarantees that when it returns, the file
> > (and all of it's filenames) will survive a reboot.
> 
> Note that this is very different from the "link() should be
> synchronous()" mantra we've been hearing over the last days.

Indeed, but this might still require MTA fixing probably, and opening a
file you just want to rename is quite expensive an operation.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Mon, 30 Jul 2001, Lawrence Greenfield wrote:

> The idea that Linux fsync() doesn't actually make the file survive
> reboots is pretty ridiculous.

That doesn't apply to ReiserFS or ext3fs, it does apply to ext2fs and
possibly others.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Jan Harkes]

On Fri, Aug 03, 2001 at 06:54:12PM +0200, Daniel Phillips wrote:
> On Friday 03 August 2001 18:16, Jan Harkes wrote:
> > On Fri, Aug 03, 2001 at 05:47:17PM +0200, Daniel Phillips wrote:
> > > On Friday 03 August 2001 17:18, Jan Harkes wrote:
> > > > Working on a distributed filesystem with somewhat weaker than UNIX
> > > > semantics might have skewed my vision. In Coda not every client will be
> > > > able to figure out which are all of the possibly paths that can lead to
> > > > a file object. And although we currently try our best to block
> > > > hardlinked directories they could possibly exist, making the problems
> > > > even worse.
> > >
> > > We don't need all the paths, and not any specific path, just a path.
> >
> > Even if that path leads to a name that got removed, thereby forcing the
> > object into lost+found? I thought the MTA did something like,
> 
> We'd better get confirmation from the MTA expert in the thread.
> 
> > fd = open(tmp/file)
> > write(fd)
> > fsync(fd)
> > link(tmp/file, new/file)
> > fsync(fd)		*1
> > unlink(tmp/file)
> >
> > *1 If this fsync only syncs the path leading to tmp/file, and the unlink
> > tmp/file is written back to disk, which is likely because we're only
> > creating/syncing stuff in tmp.  Now, until new/file is written there is
> > no path information leading to the file anymore which makes this as
> > 'safe' as not syncing path name information at all.
> 
> Nice clear example!  Yes, in essence we would have synced the original
> path twice.  If this is what the MTA is really doing I'm willing to join
> the "MTA is broken" camp.

Here is the relevant mail,

On Mon, Jul 30, 2001 at 01:11:32PM -0400, Lawrence Greenfield wrote:
} BSD softupdates allows you to call fsync() on the file, and this will
} sync the directories all the way up to the root if necessary.
} 
} Thus BSD fsync() actually guarantees that when it returns, the file
} (and all of it's filenames) will survive a reboot.
} 
} Sendmail does:
} fd = open(tmp)
} write(fd)
} fsync(fd)
} rename(tmp, final)
} fsync(fd)
} 
} Cyrus IMAP does:
} fd = open(tmp)
} write(fd)
} fsync(fd)
} link(tmp, final1)
} link(tmp, final2)
} link(tmp, final3)
} fsync(fd)
} close(fd)
} unlink(tmp)
} 
} The idea that Linux fsync() doesn't actually make the file survive
} reboots is pretty ridiculous.

As you can see, the 'sync a path leading to the file' semantics from SuS
don't work in the Cyrus IMAP case as is specifically requires to have
_all_ paths committed to disk before fsync returns.

On Fri, Aug 03, 2001 at 06:54:12PM +0200, Daniel Phillips wrote:
> On Friday 03 August 2001 18:16, Jan Harkes wrote:
> > Now if the application would use the directory sync, it can actually
> > tell the kernel that that new/file name is the interesting one to keep
> > and that tmp doesn't even need to be written to disk at all.
> 
> Yep.  Or if it used rename, which updates the dcache entries, instead
> of link/unlink.

MTA's that want to do reliable deliveries using multiple processes (or
on a networked filesystem) tend to not use rename because it implicitly
unlinks the target if it already exists and this could lead to loss of
mail that was already considered as being delivered.

Jan

Re: ext3-2.4-0.9.4

[Patrick J. LoPresti]

Jan Harkes <jaharkes@cs.cmu.edu> writes:

> Here is the relevant mail,
> 
> On Mon, Jul 30, 2001 at 01:11:32PM -0400, Lawrence Greenfield wrote:
> } BSD softupdates allows you to call fsync() on the file, and this will
> } sync the directories all the way up to the root if necessary.
> } 
> } Thus BSD fsync() actually guarantees that when it returns, the file
> } (and all of it's filenames) will survive a reboot.
> } 
> } Sendmail does:
> } fd = open(tmp)
> } write(fd)
> } fsync(fd)
> } rename(tmp, final)
> } fsync(fd)
> } 
> } Cyrus IMAP does:
> } fd = open(tmp)
> } write(fd)
> } fsync(fd)
> } link(tmp, final1)
> } link(tmp, final2)
> } link(tmp, final3)
> } fsync(fd)
> } close(fd)
> } unlink(tmp)
> } 
> } The idea that Linux fsync() doesn't actually make the file survive
> } reboots is pretty ridiculous.
> 
> As you can see, the 'sync a path leading to the file' semantics from SuS
> don't work in the Cyrus IMAP case as is specifically requires to have
> _all_ paths committed to disk before fsync returns.

To fill in more of the table, Qmail does:

  fd = open(tmp)
  write(fd)
  fsync(fd)
  link(tmp,final)
  close(fd)

...and Postfix does:

  fd = open(final)
  write(fd)
  (should be an "fsync(fd)" here, but I cannot find it)
  fchmod(fd,+execute)
  fsync(fd)
  close(fd)

Postfix apparently uses the execute bit to indicate that delivery is
complete.  I am probably misreading the source (version 20010228
Patchlevel 3), but I do not see any fsync() between the write and the
fchmod.  Surely it is there or this delivery scheme is not reliable on
any system, since without an intervening fsync() the writes to the
data and the permissions can happen out of order.

Anyway, it is certainly true that it is largely useless to have
fsync() commit only one path to a file; many applications expect to be
able to force a simple link(x,y) to be committed to disk.

I know this thread is already much too long, but I am still not sure I
understand the conclusions.  I *think* it is true that:

  1) People disagree about what SuS mandates, but at least a few
     critical developers (e.g., sct) say it definitely does not
     require synchronizing directory entries for fsync().

  2) It would be fairly easy and efficient for fsync() to chase one
     chain of directory entries up to the root, but a lot harder and
     slower to find and commit all of them.

  3) Most (?) core developers, including Linus (?), would not object
     to "dirsync" as a mount option and/or directory attribute, but
     somebody has to rise to the occasion and create the patches.

Is this an accurate summary?

 - Pat

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Fri, 03 Aug 2001, Patrick J. LoPresti wrote:

> To fill in more of the table, Qmail does:
> 
>   fd = open(tmp)
>   write(fd)
>   fsync(fd)
>   link(tmp,final)
>   close(fd)

http://cr.yp.to/qmail/faq/reliability.html

> ...and Postfix does:
> 
>   fd = open(final)
>   write(fd)
>   (should be an "fsync(fd)" here, but I cannot find it)
>   fchmod(fd,+execute)
>   fsync(fd)
>   close(fd)

> Postfix apparently uses the execute bit to indicate that delivery is
> complete.  I am probably misreading the source (version 20010228
> Patchlevel 3), but I do not see any fsync() between the write and the
> fchmod.  Surely it is there or this delivery scheme is not reliable on
> any system, since without an intervening fsync() the writes to the
> data and the permissions can happen out of order.

Not really. The error code if fsync() or close failed are propagated
back to the caller who then decides what to do. smtpd.c nukes the file.
postdrop.c/sendmail.c do not, but the pickup daemon will see that the
file had problems on sync and discard it.

I'm asking Wietse off-list how reliable this approach is and will report
back privately. It should be fairly reliable.

> Anyway, it is certainly true that it is largely useless to have
> fsync() commit only one path to a file; many applications expect to be
> able to force a simple link(x,y) to be committed to disk.

BSD FFS + softupdates sync all file names, traversing from the mount
point down to the actual directory entries that need to be synched.

>   1) People disagree about what SuS mandates, but at least a few
>      critical developers (e.g., sct) say it definitely does not
>      require synchronizing directory entries for fsync().
> 
>   2) It would be fairly easy and efficient for fsync() to chase one
>      chain of directory entries up to the root, but a lot harder and
>      slower to find and commit all of them.

For BSD FFS + softupdates, this is already done.

>   3) Most (?) core developers, including Linus (?), would not object
>      to "dirsync" as a mount option and/or directory attribute, but
>      somebody has to rise to the occasion and create the patches.
> 
> Is this an accurate summary?

It looks so to me. After the MTA behaviour has been dug up, the dirsync
option could be even weaker if fsync() behaved like FFS + softupdates:
sync the directory entries, including those of link and rename, as well.

The only things to consider would be unlink and symlink. symlinks are
tough since you cannot open() them. Not sure about unlink, looks as if
there's really no way apart from fsync(2)ing the directory or sync(2)ing
the world for these two unless there's a dirsync option coming up.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Sat, 4 Aug 2001, Matthias Andree wrote:

> http://cr.yp.to/qmail/faq/reliability.html

You should teach the guy about MTAs one day.

Softupdates and other filesystems are perfectly
safe with mailers which work with the filesystem
instead of prescribing the filesystem authors
how they should do their work ;)

Oh, most of those other mailers are RFC compliant
too, but that's a separate issue ;)

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

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: ext3-2.4-0.9.4

[Patrick J. LoPresti]

Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:

> On Fri, 03 Aug 2001, Patrick J. LoPresti wrote:
> 
> > To fill in more of the table, Qmail does:
> > 
> >   fd = open(tmp)
> >   write(fd)
> >   fsync(fd)
> >   link(tmp,final)
> >   close(fd)
> 
> http://cr.yp.to/qmail/faq/reliability.html

...which is consistent.  Qmail is assuming that the link() is
synchronous, as it was back in the "Good Old Days" of stock FFS.

> > ...and Postfix does:
> > 
> >   fd = open(final)
> >   write(fd)
> >   (should be an "fsync(fd)" here, but I cannot find it)
> >   fchmod(fd,+execute)
> >   fsync(fd)
> >   close(fd)
> 
> > Postfix apparently uses the execute bit to indicate that delivery is
> > complete.  I am probably misreading the source (version 20010228
> > Patchlevel 3), but I do not see any fsync() between the write and the
> > fchmod.  Surely it is there or this delivery scheme is not reliable on
> > any system, since without an intervening fsync() the writes to the
> > data and the permissions can happen out of order.
> 
> Not really. The error code if fsync() or close failed are propagated
> back to the caller who then decides what to do. smtpd.c nukes the
> file.

That is not the problem.  The problem is that the system could start
flushing blocks to disk after the call to fchmod and before the call
to fsync.  If so, the system could write the mode bits first and then
crash before writing the data, leaving the execute bit set on the file
but without valid data within.  This could result in a corrupted mail
message.

To avoid this, Postfix *must* do fsync() or fdatasync() after the
write() and before the fchmod()+fsync(); that will insure that the
execute bit implies valid ("committed") data in the file.  I was
unable to find any such call to fsync() or fdatasync(), but as I
mentioned, I am probably simply misreading the code.

> > Anyway, it is certainly true that it is largely useless to have
> > fsync() commit only one path to a file; many applications expect to be
> > able to force a simple link(x,y) to be committed to disk.
> 
> BSD FFS + softupdates sync all file names, traversing from the mount
> point down to the actual directory entries that need to be synched.

...and the Linux developers continue to insist that this is "stupid".
Ah, the joys of gaps in standards.

> It looks so to me. After the MTA behaviour has been dug up, the
> dirsync option could be even weaker if fsync() behaved like FFS +
> softupdates: sync the directory entries, including those of link and
> rename, as well.

Ideally, this would be an option you could set per-application (as
opposed to per-directory or per-mountpoint), because we are really
talking about allowing Linux to support applications written for BSD
file system semantics.  It is not obvious to me what the best
implementation for that would be, though.  Maybe just a compile-time
option to choose the appropriate open/link/rename/etc. operations.

 - Pat

Re: ext3-2.4-0.9.4

[Gregory Maxwell]

On Fri, Aug 03, 2001 at 11:50:23PM -0400, Patrick J. LoPresti wrote:
> > http://cr.yp.to/qmail/faq/reliability.html
> 
> ...which is consistent.  Qmail is assuming that the link() is
> synchronous, as it was back in the "Good Old Days" of stock FFS.

That isn't the only cruft there from the "Good Old Days":

"Battery backups will keep your server alive, letting you park the disk to
avoid a head crash, when the power goes out."

What the hell? Self-parking drives predate qmail by quite a long time.

Re: ext3-2.4-0.9.4

[Mike Castle]

On Fri, Aug 03, 2001 at 11:50:23PM -0400, Patrick J. LoPresti wrote:
> Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:
> 
> > On Fri, 03 Aug 2001, Patrick J. LoPresti wrote:
> > 
> > > To fill in more of the table, Qmail does:
> > > 
> > >   fd = open(tmp)
> > >   write(fd)
> > >   fsync(fd)
> > >   link(tmp,final)
> > >   close(fd)
> > 
> > http://cr.yp.to/qmail/faq/reliability.html
> 
> ...which is consistent.  Qmail is assuming that the link() is
> synchronous, as it was back in the "Good Old Days" of stock FFS.

Which, from my reading of the archives, even BSD folk say is a "Bad 
Thing(tm)."

mrc

-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Fri, 3 Aug 2001, Mike Castle wrote:
> On Fri, Aug 03, 2001 at 11:50:23PM -0400, Patrick J. LoPresti wrote:
> > Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:
> > >
> > > http://cr.yp.to/qmail/faq/reliability.html
> >
> > ...which is consistent.  Qmail is assuming that the link() is
> > synchronous, as it was back in the "Good Old Days" of stock FFS.
>
> Which, from my reading of the archives, even BSD folk say is a "Bad
> Thing(tm)."

...which is consistent, looking at the other things
qmail does in strange ways ;)

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

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Fri, 03 Aug 2001, Patrick J. LoPresti wrote:

> To avoid this, Postfix *must* do fsync() or fdatasync() after the
> write() and before the fchmod()+fsync(); that will insure that the
> execute bit implies valid ("committed") data in the file.  I was
> unable to find any such call to fsync() or fdatasync(), but as I
> mentioned, I am probably simply misreading the code.

Thanks for clarifying, I'm asking Wietse to figure if Postfix's
queue file format is sufficient to check integrity.

> > It looks so to me. After the MTA behaviour has been dug up, the
> > dirsync option could be even weaker if fsync() behaved like FFS +
> > softupdates: sync the directory entries, including those of link and
> > rename, as well.
> 
> Ideally, this would be an option you could set per-application (as
> opposed to per-directory or per-mountpoint), because we are really
> talking about allowing Linux to support applications written for BSD
> file system semantics.  It is not obvious to me what the best
> implementation for that would be, though.  Maybe just a compile-time
> option to choose the appropriate open/link/rename/etc. operations.

To add to that confusion and alternatvies:
HAVE: async, sync
SUGGEST: 1. BSD dirsync, 2. "weak" unlink/symlink dirsync and have
fsync() track and sync pending link/rename as well, 3. make just symlink
dirsync, 4. be confused of all the options.

Where this could be set: directory inode flag, mount option, process
flag (like umask), include file.


Seriously, if fsync() syncs the effects of link and rename as well,
there's no need to make them synchronous unconditionally except if one
wants to offer a "traditional BSD synchronous directory semantics" mode. 

-- 
Matthias Andree

fsync() on directories (was Re: ext3-2.4-0.9.4)

[Patrick J. LoPresti]

Are the Linux "fsync() the directory" semantics documented anywhere?
I mean other than in the source code and on mailing lists.

It might be easier to convince MTA authors to support these semantics
if there were an "official" document describing them and giving some
guarantee that Linux will contine to support them in the future.  It
would be nice to see this described in linux/Documentation or in the
fsync() man page or both.  Without this, it is hard for a software
author to know that Linux's behavior here is not just an
implementation artifact.

 - Pat

P.S.  Is fdatasync() on a directory guaranteed to do anything?  Just
curious.

Re: ext3-2.4-0.9.4

[James Antill]

"Patrick J. LoPresti" <patl@cag.lcs.mit.edu> writes:


[snip sendmail/cyrus/qmail/postfix]

 Just in case anyone cares here's what exim does (AFAICS)...

 int fd1 = open(f1);
 write(fd1);
 fsync(fd1);
 
 int fd2 = open(tmp);
 write(fd2);
 fsync(fd2);
 rename(tmp, f2); // Good at this point.

 So that seems to rely on all dir operations being sync.

 Ps. I did a patch for exim to do the dir sync though...

http://www.and.org/exim-3.31-dirfsync.patch

-- 
# James Antill -- james@and.org
:0:
* ^From: .*james@and\.org
/dev/null

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Mon, 30 Jul 2001, Rik van Riel wrote:

> Exactly what is wrong with doing fsync() on the
> directory ?

It's non-portable and a kludge.

> Why do you want us to turn link() and rename()
> into link_slowly() and rename_slowly() ?

Opening up the directory requires lots of inode lookups which are
unnecessary.

> Why can't you use a simple wrapper function to
> do this for you ?

Because it's more inefficient than necessary and it bloats the
application.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Andrew Morton]

Alan Cox wrote:
> 
>...
> > If you have metadata journalling, all you need for this algorithm to
> > work is to have rename() write to the journal before returning.  Is
> > this true for any of the current journalling file systems on Linux?
> 
> Ext3 I believe so, Reiserfs I would assume so but Hans can answer
> definitively

For ext3: this is true if something forces a commit.  Apart from data in
`-o data=writeback' mode, a commit syncs the entire filesystem.
Things which force a commit include:

- completing a write() on an O_SYNC file.
- Performing any metadata operation on a `chattr +S' object
- Performing any metadata operation on an object on a `mount -o sync'
  filesystem.

In `data=journal' or `data=ordered' mode, any of these things will
commit everything to non-volatile storage.

-

rename() (was Re: ext3-2.4-0.9.4)

[Anthony DeBoer]

Patrick J. LoPresti <patl@cag.lcs.mit.edu> wrote:
>The MTAs do this:
>
>    Open temp file
>    Write to temp file
>    fsync() temp file
>    rename() temp file into mail spool
>    indicate success to remote MTA

Don't forget the unlink() temp file just before or after that last step.

>As long as rename() does not return until the metadata are committed,
>this should be a reliable delivery mechanism.  ...

As I understand it, rename() was originally invented for tasks like
installing a new /bin/sh with guarantees that another process running
at the same time would not fail to find a shell, and that if the system
fell over during the install you'd still have a shell on reboot.

See http://www.qef.com/ftp/rename.ps for an interesting history from
someone who was there at the time.  It's undated, but probably a decade
old.

It's my considered opinion that rename() _should_ fsync the target
directory before returning, and between that and the fsync() call on
the file itself (an install program should do the same call sequence as
above) you get the guarantee that the file is intact before you unlink
the temp version and return success.  OTOH, link() and unlink() are not
in the business of providing guarantees like that, and should not sync.

-- 
Anthony de Boer, curator, Anthony's Home for Aged Computing Machinery
<adb@leftmind.net>

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> > Alan
> big endian support is resolved, there is a working patch for it by Jeff Mahoney, it passes all of
> our tests, but it is a feature not a bug fix, and not something for a supposedly stabilizing kernel.
> 
> Nikita, you were supposed to send the big endian support and some other stuff in to Alan for testing
> in the ac series, what is the status of patches that are supposed to be going to Alan?

I suspect its a bug fix to S/390, ppc and sparc users 8)

I'd be happy to test run it in -ac

Re: ext3-2.4-0.9.4

[Alan Cox]

> 
> "Paul G. Allen" <pgallen@randomlogic.com> writes:
>  
> > Do the newer kernel releases support the 760 MP chipset? Will they
> > anytime soon? (If not I will see if I can put it in myself.)
> 
> There is better support in 2.4.7 (especially IDE) but there is not complete
> support.  
> 
> I don't know of anyone planning on finishing up any the pieces so feel free.
> 
> Eric
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: ext3-2.4-0.9.4

[Alan Cox]

> These are tangential issues.  Not everybody uses IDE disks.  I'm not
> asking for things that are impossible.  Just because sometimes the

Actually if I remember rightly the problem is mathematically insoluble

> The application can avoid the wrong file problem by zeroing out data
> before releasing it to the OS to reallocate.

When you zero out the data what order do you want those writes in relative
to the rename

> An async fsync allows me to issue multiple fsyncs and then wait for
> all of them to complete, hopefully in the same framework that I would
> do async I/O (but that's an argument for another day).

Ok.. right that makes more sense. So you actually want 'begin_fsync' and
'wait_fsync_all' type stuff

>    Doing reliabile transactions on disk is a hard problem. That is why oracle
>    and friends have spent many man years of research on this kind of problem. 
>    Current unix mailers do the smoke mirrors and prayer bit to reduce the
>    probability a little that is all, regardless of fs and os.
> 
> Isn't the point of the operating system to try to make it as easy as
> possible to do these things correctly?

The OS doesnt have enough information. To do transactions you must know the
entire material that corresponds to the transaction and bound it. That isnt
something the kernel has the knowledge about.

The job of the OS is to make the simple things easy, and the hard possible.
Not to burden the simple with the cost of the hard. That why the chattr +S
is such a nice solution in many ways

Alan

Re: Linux 2.4.7-ac1 PNP Oops on shutdown

[Alan Cox]

> 2.4.7-ac1 oopses reproduceably during every shutdown. As far as I can tell,
> 2.4.6-ac5 didn't exhibit this behaviour.

>From the trace that looks what I would expect

> >>EIP; c0112b5d <complete+1d/a0>   <=====
> Trace; c011792d <complete_and_exit+d/20>
> Trace; c01dde51 <pnp_dock_thread+d1/e0>
> Trace; c01054c8 <kernel_thread+28/40>
> Code;  c0112b5d <complete+1d/a0>
> 00000000 <_EIP>:
> Code;  c0112b5d <complete+1d/a0>   <=====
>    0:   8b 03                     mov    (%ebx),%eax   <=====

Its oopsing in the complete_and_exit changes killing the PnP docking thread.

A quick look over the code and I have to admit I don't see why that happened
I'll ponder it later

Re: VIA KT133A / athlon / MMX

[Alan Cox]

> have not found clear answer on the different threads about this topic.
> As I understand, this problem does not exist on every athlon but only on
> some which work with the VIA KT133 chipset ? Right ?

Its heavily tied to certain motherboards. Some people found a better PSU
fixed it, others that altering memory settings helped. And in many cases,
taking it back and buying a different vendors board worked.

> 	Anyway, feel free to ask me more information if needed and please,
> CC'ed me personally the answers/comments because I'm not subscribed to
> the LKML.

http://www.linuxhardware.org/article.pl?sid=01/06/06/1821202&mode=thread

gives a good feel for the current state of play

Re: VIA KT133A / athlon / MMX

[Chris Wedgwood]

On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:

    Its heavily tied to certain motherboards. Some people found a
    better PSU fixed it, others that altering memory settings
    helped. And in many cases, taking it back and buying a different
    vendors board worked.

Does anyone know *why* stuff breaks? surely VIA do as they have a fix
for (some, all?) cases of breakage?

My guess is its some kind of timing or near-miss on a signal edge, and
the bios changes relax things so you don't miss whatever it was you
missed before.



  --cw

Re: VIA KT133A / athlon / MMX

[Alan Cox]

> On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
>     Its heavily tied to certain motherboards. Some people found a
>     better PSU fixed it, others that altering memory settings
>     helped. And in many cases, taking it back and buying a different
>     vendors board worked.
> 
> Does anyone know *why* stuff breaks? surely VIA do as they have a fix
> for (some, all?) cases of breakage?

At the moment the big problem is I don't have enough reliable info to
see patterns that I can give to VIA for study. VIAs fixes for board problems
are for the fifo problem normally seen with the 686B and SB Live but
sometimes in other cases.

(and it seems also we have a few via + promise weirdnesses on all sorts of
 boards not yet explained)

Re: VIA KT133A / athlon / MMX

[Paul G. Allen]

I meant to send this to the list, but sent it straight to Alan instead.

PGA

"Paul G. Allen" wrote:
> 
> Alan Cox wrote:
> >
> 
> [SNIP]
> >
> > (and it seems also we have a few via + promise weirdnesses on all sorts of
> >  boards not yet explained)
> 
> I happen to have one of these boards. I was rather upset with it because it would lock Linux several times a day, especially while playing games. This is part
> of what drove me to purchase the K7 Thunder I now have and put the Asus A7V133 on the shelf.
> 
> Is there anything I can do that might help track down the problem(s)? I still have the board. In fact, it is a complete system less the SB Live! and GeForce 3
> that I relocated to my K7 Thunder, and it's running a Duron 750. (I also have a second system with a SB Live! and Athlon 1.2, but I'd have to beg my wife for
> its use. ;)
> 
> PGA
> 


-- 
Paul G. Allen
UNIX Admin II/Programmer
Akamai Technologies, Inc.
www.akamai.com
Work: (858)909-3630
Cell: (858)395-5043

Re: VIA KT133A / athlon / MMX

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]

Hi Alan,

as I stumbled across the K7 KT133 MMX problem, let me report my failure.
MSI K7 Turbo Ver. 3 (BIOS 2.8). K7 1.2GHz. 256MB SDRam, tested fine by
memtes86 2.7.

The thing would Oops or just hand at random places at the boot process if
compiled with K7 optimization.

On Fri, Jul 27, 2001 at 09:40:09PM +0100, Alan Cox wrote:
> > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
> >     Its heavily tied to certain motherboards. Some people found a
> >     better PSU fixed it, 

PSU = Power supply? 300W should be fine IMHO.

> >     others that altering memory settings helped.

Did not. Board allows you to set CL 3 which won't help (and I guess the SPDs
read out 3 anyway) and to turn off some PCI features which does not
help either.
It does also allow you to increase mainboard speed and multiplier but not
decrease!

> >     And in many cases, taking it back and buying a different
> >     vendors board worked.

The best option most probably.

> > Does anyone know *why* stuff breaks? surely VIA do as they have a fix
> > for (some, all?) cases of breakage?
> 
> At the moment the big problem is I don't have enough reliable info to
> see patterns that I can give to VIA for study.

Well, I did some testing, like reordering the MMX instructions, only using 4
instead of 8 registers, ... to no avail.
It all came down to replacing movntq with movq and the thing magically works.
Looks like the writes just get lost otherwise. (Maybe the sfence is just not
effective? But that would be a CPU bug, not a mainboard one.)

> VIAs fixes for board problems
> are for the fifo problem normally seen with the 686B and SB Live but
> sometimes in other cases.

It also has the 686b southbridge bug, but I believe the workaound works.

> (and it seems also we have a few via + promise weirdnesses on all sorts of
>  boards not yet explained)

No Promise involved here, fortunately.
garloff@gum09:~ $ /sbin/lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50)
[...]

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: VIA KT133A / athlon / MMX

[David Lang]

I have a 1u box at my des that has two MSI boards in it with 1.2G athlons.
at the moment they are both running 2.4.5 (athlon optimized), one box has
no problems at all while the other dies (no video, no keyboard, etc)
within an hour of being booted.

systems have no sound enabled, 512MB ram, 20G ata100 drives. D-Link quad
fast ethernet cards.

if you have any patch you would like me to test on these boxes let me know
(I am arranging to ship this one and three others like it that each have
one working and one failing system in them back to the factory to get the
MLB swapped out on the one that is failing.

David Lang


 On Fri, 27 Jul 2001, Alan Cox wrote:

> Date: Fri, 27 Jul 2001 21:40:09 +0100 (BST)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: cw@f00f.org
> Cc: alan@lxorguk.ukuu.org.uk, ppeiffer@free.fr, linux-kernel@vger.kernel.org
> Subject: Re: VIA KT133A / athlon / MMX
>
> > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
> >     Its heavily tied to certain motherboards. Some people found a
> >     better PSU fixed it, others that altering memory settings
> >     helped. And in many cases, taking it back and buying a different
> >     vendors board worked.
> >
> > Does anyone know *why* stuff breaks? surely VIA do as they have a fix
> > for (some, all?) cases of breakage?
>
> At the moment the big problem is I don't have enough reliable info to
> see patterns that I can give to VIA for study. VIAs fixes for board problems
> are for the fifo problem normally seen with the 686B and SB Live but
> sometimes in other cases.
>
> (and it seems also we have a few via + promise weirdnesses on all sorts of
>  boards not yet explained)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: VIA KT133A / athlon / MMX

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 1327 bytes --]

Hi,

On Fri, Jul 27, 2001 at 05:23:07PM -0700, David Lang wrote:
> I have a 1u box at my des that has two MSI boards in it with 1.2G athlons.
> at the moment they are both running 2.4.5 (athlon optimized), one box has
> no problems at all while the other dies (no video, no keyboard, etc)
> within an hour of being booted.

Somebody told he had the same MoBo already replaced a couple of times ...

> if you have any patch you would like me to test on these boxes let me know

Well, no kernel patches.
But some program which does the K7 optmizied copies and zeroing in userspace.
(Attached)

Strange enough it succeeds on the machine that fails to boot a K7 optimized
kernel. 
So I'm puzzled now. 
Seems we can trigger problems in kernelspace that we can't have in userspace?
Some problem with non-serialization if an interrupt occurs or something
esoteric like this?

> (I am arranging to ship this one and three others like it that each have
> one working and one failing system in them back to the factory to get the
> MLB swapped out on the one that is failing.

Good luck!
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

[-- Attachment #1.2: test_movntq.c --]
[-- Type: text/plain, Size: 4336 bytes --]

/* test_movntq.c 
 * Program that tests the K7 optimized routines for copying 
 * and zeroing pages (which fail on some MoBos in the kernel).
 * gcc -O2 -Wall -g -fomit-frame-pointer -o test_movntq test_movntq.c
 * and run on AMD K7!
 * (c) Kurt Garloff <garloff@suse.de>, 2001-07-28, GNU GPL
 */

#include <stdio.h>
#include <unistd.h>
#include <malloc.h>
#include <stdlib.h>

#define PAGE_SIZE 4096
#define NR_TESTS 4096

void * fpu_ctx;

double c;
void trigger_fpu ()
{

	double a = 4.3;
	double b = rand()/ (float)RAND_MAX;
	c = a/b;
}

void movntq_copy_page0 (void* to, void* from)
{
	//void *d0, *d1;
	//printf ("%p <- %p\n", to, from);
	asm volatile (
		      "\n\t   prefetch (%0)"
		      "\n\t   prefetch 64(%0)"
		      "\n\t   prefetch 128(%0)"
		      "\n\t   prefetch 192(%0)"
		      "\n\t   fxsave (%3)"
		      "\n\t   prefetch 256(%0)"
		      "\n\t   movl %2, %%ecx"
		      "\n\t   fnclex"
		      "\n\t1: prefetch 320(%0)"
		      "\n\t   movq (%0),%%mm0"
		      "\n\t   movntq %%mm0,(%1)"
		      "\n\t   movq 8(%0),%%mm1"
		      "\n\t   movntq %%mm1,8(%1)"
		      "\n\t   movq 16(%0),%%mm2"
		      "\n\t   movntq %%mm2,16(%1)"
		      "\n\t   movq 24(%0),%%mm3"
		      "\n\t   movntq %%mm3,24(%1)"
		      "\n\t   movq 32(%0),%%mm4"
		      "\n\t   movntq %%mm4,32(%1)"
		      "\n\t   movq 40(%0),%%mm5"
		      "\n\t   movntq %%mm5,40(%1)"
		      "\n\t   movq 48(%0),%%mm6"
		      "\n\t   movntq %%mm6,48(%1)"
		      "\n\t   movq 56(%0),%%mm7"
		      "\n\t   movntq %%mm7,56(%1)"
		      /*"\n\t   sfence"*/
		      "\n\t   addl $64,%0"
		      "\n\t   addl $64,%1"
		      "\n\t   loop 1b"
		      "\n\t   movl $5, %%ecx"
		      "\n\t2: movq (%0),%%mm0"
		      "\n\t   movntq %%mm0,(%1)"
		      "\n\t   movq 8(%0),%%mm1"
		      "\n\t   movntq %%mm1,8(%1)"
		      "\n\t   movq 16(%0),%%mm2"
		      "\n\t   movntq %%mm2,16(%1)"
		      "\n\t   movq 24(%0),%%mm3"
		      "\n\t   movntq %%mm3,24(%1)"
		      "\n\t   movq 32(%0),%%mm4"
		      "\n\t   movntq %%mm4,32(%1)"
		      "\n\t   movq 40(%0),%%mm5"
		      "\n\t   movntq %%mm5,40(%1)"
		      "\n\t   movq 48(%0),%%mm6"
		      "\n\t   movntq %%mm6,48(%1)"
		      "\n\t   movq 56(%0),%%mm7"
		      "\n\t   movntq %%mm7,56(%1)"
		      "\n\t   addl $64,%0"
		      "\n\t   addl $64,%1"
		      "\n\t   loop 2b"
		      "\n\t   sfence"
		      "\n\t   fxrstor (%3) \n"
		      :
		      : "r" (from), "r" (to), "i" (PAGE_SIZE/64 - 5), "r" (fpu_ctx)
		      : "memory", "ecx" );
};


void movntq_zero_page0 (void* to)
{
	//void *d0;
	//printf ("%p <- 0\n", to);
	asm volatile (
		      "\n\t   fxsave (%2)"
		      "\n\t   movl %1, %%ecx"
		      "\n\t   fnclex"
		      "\n\t   pxor %%mm0, %%mm0"
		      "\n\t1: "
		      "\n\t   movntq %%mm0,(%0)"
		      "\n\t   movntq %%mm0,8(%0)"
		      "\n\t   movntq %%mm0,16(%0)"
		      "\n\t   movntq %%mm0,24(%0)"
		      "\n\t   movntq %%mm0,32(%0)"
		      "\n\t   movntq %%mm0,40(%0)"
		      "\n\t   movntq %%mm0,48(%0)"
		      "\n\t   movntq %%mm0,56(%0)"
		      /*"\n\t   sfence"*/
		      "\n\t   addl $64,%0"
		      "\n\t   loop 1b"
		      "\n\t   sfence"
		      "\n\t   fxrstor (%2) \n"
		      :
		      : "r" (to), "i" (PAGE_SIZE/64), "r" (fpu_ctx)
		      : "memory", "ecx");
}


void alloc_fpu_ctx ()
{
	fpu_ctx = (void*) memalign (256, 1024);
}

void fill_rand_page (void* mem)
{
	int* ptr = (int*) mem;
	do {
		*ptr = rand();
	} while (( (char*)(++ptr) - (char*)mem) < PAGE_SIZE);
}

void* memzero (void* mem, size_t ln)
{
	int* ptr = (int*)mem;
	int i = ln / sizeof(int);
	while (i--)
		if (*ptr++ != 0) return (void*)ptr;
	return 0;
}

int main ()
{
	void *b1, *b2, *b3; void* err; int i;
	srand (5);
	alloc_fpu_ctx ();
	trigger_fpu ();
	b3 = b1 = (void*) memalign (PAGE_SIZE, (NR_TESTS+1)*PAGE_SIZE);
	fill_rand_page (b1);
	for (i = 0; i < NR_TESTS; i++) {
		b2 = (void*) ((char*)b3 + PAGE_SIZE);
		movntq_copy_page0 (b2, b3);
		if (memcmp (b3, b2, PAGE_SIZE)) {
			printf ("Error (%i)!\n", i);
			exit (1);
		}
		movntq_zero_page0 (b3);
		if ((err = memzero (b3, PAGE_SIZE))) {
			printf ("Error! (%i) %p\n", i, err);
			exit (2);
		}
		b3 = b2;
	}
	free (b1);
	free (fpu_ctx);
	return 0;
}
			      

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: VIA KT133A / athlon / MMX

[Victor Julien]

Do these problems also affect Durons? I have a MSI K7T Turbo-R with Via
KT133A and I have nog problems at all. I even run my Duron 600 at 866(!)
(6,5 * 133) for several months now. Now I wonder if I could get problems
when i upgrade to a tbird at 1,4 ghz. I have a 300 PSU.

Victor

Re: VIA KT133A / athlon / MMX

[J. Dow]

From: "Kurt Garloff" <garloff@suse.de>

On Fri, Jul 27, 2001 at 05:23:07PM -0700, David Lang wrote:
> I have a 1u box at my des that has two MSI boards in it with 1.2G athlons.
> at the moment they are both running 2.4.5 (athlon optimized), one box has
> no problems at all while the other dies (no video, no keyboard, etc)
> within an hour of being booted.

Somebody told he had the same MoBo already replaced a couple of times ...

Kurt, et al, I have been following this VIA vs Linux thing for some time
now. (My "big machine" is an Athlon based system. So it interests me.)
Comments have been made about the size of power supply needed to keep these
systems happy with 400 watts coming up in discussions frequently. But if you
pause to think on it a few minutes you begin to wonder about this concept.
The RAM runs at about 3.3 volts. The CPU core runs at about 1.7v (in my case.)
So both of these are running off of power supplies on the motherboards that
take the 5 volts down to something reasonable. If the problem is inadequate
power supply AND it is more of a problem with some motherboards than others
I look for the volts. Where are the losses which could cause this. One source
is the connector from the power supply to the motherboard. (This was a chronic
problem with A2000s, for example.) I don't see newer style connectors that
have less contact resistance on any systems. That is probably a factor. Since
the problem is greater with some boards than others I suspect that the
auxilliary power sipplies on the motherboards are better for some boards than
for others. Somebody with hardware access to a sufficient variety of mother-
boards should survey this. Do they all use exactly the same power supply parts?

Another issue is the speed of these systems. And the Athlon problem seems to
peak when driving the various buses at their peaks. RF crosstalk is an issue
that a lot of digital designers claim to understand when they design (and
model) their circuits. Now, I built my first circuit analysis program back
in about 1975. Results of that work fly on GPS satellites today. Since it was
MY program I used for design I was acutely aware of its deficiencies as well
as the modeling deficiencies. At some point in the analysis you cut a corner
or two in order to make the calculations tractable. You do not manage to get
all the "strays" into the models. What I ams saying is that board layout is
another area where problems may exist.

These are not thigs software settings in the VIA chips can cure. On another
mailinglist catering to developers for very exotic video cards some problems
with the latest INTEL based motherboards are appearing. (DigiSuite:E and its
kith and kin drive the PCI bus very hard.) I suspect we have a situation not
properly anticipated in modeling the backplanes on all these boards. And until
the designers can wrap their minds around the entire problem the software
solution may simply be, in the words of an old philospher, "Slow down! You move
too fast." At the same time someone with suitable test equipment needs to look
for voltage glitches out of the motherboard regulators and we need to develop
software tools for "forcing" the suspected crosstalk and ideally characterising
it with regards to data passing on the bus at the time of the bad data transfer.
The software based fixes seem to be shooting at black cats in a coal mine
without a flashlight or IR goggles.

{^_^}    Joanne Dow, jdow@earthlink.net

Re: VIA KT133A / athlon / MMX

[Alan Cox]

> I have a 1u box at my des that has two MSI boards in it with 1.2G athlons.
> at the moment they are both running 2.4.5 (athlon optimized), one box has
> no problems at all while the other dies (no video, no keyboard, etc)
> within an hour of being booted.

Same bios, same bios settings ?

lspci -vxx on both show the same settings ?

Re: VIA KT133A / athlon / MMX

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1006 bytes --]

I have not had a chance to examine all the BIOS settings but attached are
the lspci -vxx for 10 different systems with identical hardware configs.
the ones that end in .good have given me no problems, the three ending in
.bad die after a while. the framewall-b system dies with all LEDs on the
network card lit, all others die with no LEDs on.

David Lang

On Sat, 28 Jul 2001, Alan Cox wrote:

> Date: Sat, 28 Jul 2001 13:47:40 +0100 (BST)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: dlang@diginsite.com
> Cc: alan@lxorguk.ukuu.org.uk, cw@f00f.org, ppeiffer@free.fr,
>      linux-kernel@vger.kernel.org
> Subject: Re: VIA KT133A / athlon / MMX
>
> > I have a 1u box at my des that has two MSI boards in it with 1.2G athlons.
> > at the moment they are both running 2.4.5 (athlon optimized), one box has
> > no problems at all while the other dies (no video, no keyboard, etc)
> > within an hour of being booted.
>
> Same bios, same bios settings ?
>
> lspci -vxx on both show the same settings ?
>


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 71680 bytes --]

Re: VIA KT133A / athlon / MMX

[Gav]

On Friday 27 July 2001 20:40, Alan Cox wrote:

> > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
> >     Its heavily tied to certain motherboards. Some people found a
> >     better PSU fixed it, others that altering memory settings
> >     helped. And in many cases, taking it back and buying a different
> >     vendors board worked.
> >
> > Does anyone know *why* stuff breaks? surely VIA do as they have a fix
> > for (some, all?) cases of breakage?
>
> At the moment the big problem is I don't have enough reliable info to
> see patterns that I can give to VIA for study. VIAs fixes for board
> problems are for the fifo problem normally seen with the 686B and SB Live
> but sometimes in other cases.
>
> (and it seems also we have a few via + promise weirdnesses on all sorts of
>  boards not yet explained)

Just FYI, I've been running 2.4.7-pre6 for a few weeks on a Abit-KT7-a 
(hpt370) that uses the KT133/VIA chipset, with a 1.33Ghz Athlon and the 
kernel compiled for an Athlon. 

The machine is now rock solid. I've given it the usual tests, k7burn for 5 
hours, cp'ing 30G+ across drives a few times etc, and all is good.

The broken sound (crackle/pop) with my SB128PCI (same problem as SBLive) 
still didn't go away though, but enabling PCI DRAM PREFETCH on the VT8363 
Bus-PCI Bridge does cure it. This took me a while to find as I can't set this 
in my bios, but powertweak came to the rescue.

While DRAM Prefetch is supposed to be an option to increase performance, my 
sound is totally unusable without this set. I've heard numerous people 
explain the same problem and it would be interesting to find out if this 
cures their sound troubles too. If this is the case, is this something that 
belongs in quirks, or is it too hardware specific? and would enabling this by 
default hurt anything anyway? Or is this just masking the underlaying problem 
?

-- Regards, Gavin Baker

Re: VIA KT133A / athlon / MMX

[Mike Frisch]

On Sun, Jul 29, 2001 at 04:03:29AM +0000, Gav wrote:
> The machine is now rock solid. I've given it the usual tests, k7burn for 5 
> hours, cp'ing 30G+ across drives a few times etc, and all is good.

Sorry to jump in here, but where can I get "k7burn"?  I've searched on
google.com for it and cannot find any reference.  I am running 2.4.7-ac2
(with Athlon optimizations) with an AMD T-Bird 1.2GHz on an ASUS A7A266
and it appears quite stable.  I would like to see how it fares with this
burn-in program you speak of.

Thanks,

Mike.

Re: VIA KT133A / athlon / MMX

[Steffen Persvold]

Gav wrote:
> Just FYI, I've been running 2.4.7-pre6 for a few weeks on a Abit-KT7-a
> (hpt370) that uses the KT133/VIA chipset, with a 1.33Ghz Athlon and the
> kernel compiled for an Athlon.
> 
> The machine is now rock solid. I've given it the usual tests, k7burn for 5
> hours, cp'ing 30G+ across drives a few times etc, and all is good.
> 
> The broken sound (crackle/pop) with my SB128PCI (same problem as SBLive)
> still didn't go away though, but enabling PCI DRAM PREFETCH on the VT8363
> Bus-PCI Bridge does cure it. This took me a while to find as I can't set this
> in my bios, but powertweak came to the rescue.
> 
> While DRAM Prefetch is supposed to be an option to increase performance, my
> sound is totally unusable without this set. I've heard numerous people
> explain the same problem and it would be interesting to find out if this
> cures their sound troubles too. If this is the case, is this something that
> belongs in quirks, or is it too hardware specific? and would enabling this by
> default hurt anything anyway? Or is this just masking the underlaying problem
> ?

Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on, because (and correct
me if i'm wrong) it's causing all the problems with the IDE controller (data trashing).

Regards,
-- 
  Steffen Persvold               Systems Engineer
  Email : mailto:sp@scali.no     Scali AS (http://www.scali.com)
  Tlf   : (+47) 22 62 89 50      Olaf Helsets vei 6
  Fax   : (+47) 22 62 89 51      N-0621 Oslo, Norway

Re: VIA KT133A / athlon / MMX

[Maciej Zenczykowski]

> Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on, because (and correct
> me if i'm wrong) it's causing all the problems with the IDE controller (data trashing).

I think it was IDE Prefetch that should be off (I had this problem on a
AMD 486DX4-133 with Award Bios, turning it on trashed the boot record in
minutes (and many other sectors on the disk too).

Anyone here care to give a link to that program to enable DRAM Prefetch?
My sister has a Duron 750w with VIA motherboard and music and sound pop on
any graphics changes, maybe this is it?

Regards,

Maciej Zenczykowski

Re: VIA KT133A / athlon / MMX

[Luigi Genoni]

I have this bios setting enabled, and no problems at all on two of my
athlons with VIA KT133A, kernel 2.4.7.

>From this full discussion comes out a big confusion.

For what I saw, many  VIA KT133A do work well, many other
give problems to their sysadmins. but the chipset is almost the same,
and the processors are quite the same (they are all athlon, I read no
bug reports about duron).

this is enought for me to get confused.

My production systems do use scsi disks, and i can understand
they donot have troubles (adaptec 2940, 2980 29160....).
But also the ones with IDE disks are working quite well (some using
ata33, others ata100).
I NEVER used DDRAM, just normal SDRAM 133 Mhz.

So I was thinking to FSB. All my systems with ide disks have 200MhzFSB,
(while my latest production systems do have 266 MhzFSB). Maybe a 266
MhzFSB is just too mutch stress
for some via chipset. But i see no clear logic when problems do appear,
or any big difference with systems that are rock solid.

lets' try to make a point to see a logic for those instabilities...

which kind of hardware bug is this, if the same chipset can work or not
depending  if you are lucky? or a full stock of chipset is buggy and
with a certain HW configuration you will see the bug or
what?

Luigi

On Mon, 30 Jul 2001, Maciej Zenczykowski wrote:

> > Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on, because (and correct
> > me if i'm wrong) it's causing all the problems with the IDE controller (data trashing).
>
> I think it was IDE Prefetch that should be off (I had this problem on a
> AMD 486DX4-133 with Award Bios, turning it on trashed the boot record in
> minutes (and many other sectors on the disk too).
>
> Anyone here care to give a link to that program to enable DRAM Prefetch?
> My sister has a Duron 750w with VIA motherboard and music and sound pop on
> any graphics changes, maybe this is it?
>
> Regards,
>
> Maciej Zenczykowski
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: VIA KT133A / athlon / MMX

[Gav]

On Monday 30 July 2001 07:15, Steffen Persvold wrote:

> > While DRAM Prefetch is supposed to be an option to increase performance,
> > my sound is totally unusable without this set. I've heard numerous people
> > explain the same problem and it would be interesting to find out if this
> > cures their sound troubles too. If this is the case, is this something
> > that belongs in quirks, or is it too hardware specific? and would
> > enabling this by default hurt anything anyway? Or is this just masking
> > the underlaying problem ?
>
> Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on,
> because (and correct me if i'm wrong) it's causing all the problems with
> the IDE controller (data trashing).

Obviously I can only comment on my own hardware but the machine has been used 
constantly since Thu Jul 12, its now Jul 30 and I havent had a single IDE 
related problem. 

As a hobby, i use the machine for DigitalVideo, and regularly grab 20-30GB 
from my capture card, then process it, which means the IDE bus gets a lot of 
use and seems to be an ideal situation for the data trashing problems to rear 
their ugly heads (no pun intended) but, as i said, I haven't seen any here.

DRAM Prefetch makes my sound usuable, as the VIA fixups for the SB cards do 
not work here, and for (at least) two other people who i have had email 
correspondancy with.

-- Regards, Gavin Baker

Re: VIA KT133A / athlon / MMX

[PEIFFER Pierre]

Chris Wedgwood a écrit :
> 
> On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
> 
>     Its heavily tied to certain motherboards. Some people found a
>     better PSU fixed it, others that altering memory settings
>     helped. And in many cases, taking it back and buying a different
>     vendors board worked.
> 
> My guess is its some kind of timing or near-miss on a signal edge, and
> the bios changes relax things so you don't miss whatever it was you
> missed before.
> 

Ok, after reading that, I've tried to see if my BIOS setting changes
were implicated or not. And I've found a winner:
Disabling option "Enhance Chip Performance" makes kernel K7-mmx routines
work fine. Enabling it causes the kernel crash at boot time... (And I
haved it enable)

FYI, according to the user's manual, enabling this option "set the north
bridge chipset timing parameters more aggressively providing higher
system performance" (Default value is 'disable'). I can't say more about
what it does exactly.

I don't know if this will help you to locate the problem, but at least,
Abit's users will be warned...

Thanks for your help !

	Pierre

Re: VIA KT133A / athlon / MMX

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

On Sat, Jul 28, 2001 at 01:29:04PM -0400, PEIFFER Pierre wrote:
> FYI, according to the user's manual, enabling this option "set the north
> bridge chipset timing parameters more aggressively providing higher
> system performance" (Default value is 'disable'). I can't say more about
> what it does exactly.

A lspci -vxxx of your northbridge with adn without the BIOS option will
reveal more.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations  <K.Garloff@Phys.TUE.NL>  [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: VIA KT133A / athlon / MMX

[PEIFFER Pierre]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

Kurt Garloff a écrit :
> 
> A lspci -vxxx of your northbridge with adn without the BIOS option will
> reveal more.

In attached files are the result. I've only kept the (what I suppose to
be) northbridge info.
This doesn't tell me anything...

Note: both has been done after booting on  Mandrake-kernel 2.4.3 which
come with Mandrake distribution (i.e. with lot of patches and
options...) I don't know the impact on the result...

Pierre

[-- Attachment #2: lspci_opt_disable.txt --]
[-- Type: text/plain, Size: 1142 bytes --]

00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
	Subsystem: ABIT Computer Corp.: Unknown device a401
	Flags: bus master, medium devsel, latency 0
	Memory at d8000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 2.0
	Capabilities: [c0] Power Management version 2
00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 00 00 00
10: 08 00 00 d8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 7b 14 01 a4
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 17 a3 eb b4 02 00 10 10 c0 00 08 10 10 10 10 10
60: 03 aa 02 20 e6 d6 d6 c6 51 28 43 0d 08 3f 00 00
70: d4 88 cc 0c 0e 81 62 00 01 b4 19 02 00 00 00 00
80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 32 00 00
a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2b 12 14 00
b0: 49 da 00 60 31 ff 80 05 67 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 00 00


[-- Attachment #3: lspci_opt_enable.txt --]
[-- Type: text/plain, Size: 1142 bytes --]

00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
	Subsystem: ABIT Computer Corp.: Unknown device a401
	Flags: bus master, medium devsel, latency 8
	Memory at d8000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 2.0
	Capabilities: [c0] Power Management version 2
00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 08 00 00
10: 08 00 00 d8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 7b 14 01 a4
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 17 a3 eb b4 43 89 10 10 c0 00 08 10 10 10 10 10
60: 03 aa 02 20 e6 d6 d6 c6 45 28 43 0f 08 3f 00 00
70: d4 88 cc 0c 0e 81 62 00 01 b4 19 02 00 00 00 00
80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 32 00 00
a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2f 12 14 00
b0: 49 da 88 60 31 ff 80 05 67 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 91 06

Re: VIA KT133A / athlon / MMX

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 3265 bytes --]

Hi Pierre,

thanks for your info!

On Sat, Jul 28, 2001 at 06:00:11PM -0400, PEIFFER Pierre wrote:
> Kurt Garloff a écrit :
> In attached files are the result. I've only kept the (what I suppose to
> be) northbridge info.
> This doesn't tell me anything...

Me neither. I was hoping that only a bit differs. Unfortunately that's not
the case, so I need to have a look in the datasheet.
But those are not publically available :-(
Anybody having them?

> Note: both has been done after booting on  Mandrake-kernel 2.4.3 which
> come with Mandrake distribution (i.e. with lot of patches and
> options...) I don't know the impact on the result...

With a newer lspci you would have seen that 1106:0305 is VT8363/8365
[KT133/KM133].

I removed everything except for the differences. Underlined. Anybody able to
decode? Otherwise trying out all of them can get boring. (Well, I'd start
with 0x68, followed by 0x6b and 0xac  ...)

Working:

> 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
> 	Subsystem: ABIT Computer Corp.: Unknown device a401
> 	Flags: bus master, medium devsel, latency 0
                                                  ^ This looks wrong to me.
> 	Memory at d8000000 (32-bit, prefetchable) [size=64M]
> 	Capabilities: [a0] AGP version 2.0
> 	Capabilities: [c0] Power Management version 2
> 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 00 00 00
                                              ^ Latency.
> 50: 17 a3 eb b4 02 00 10 10 c0 00 08 10 10 10 10 10
                  ^^ ^^
> 60: 03 aa 02 20 e6 d6 d6 c6 51 28 43 0d 08 3f 00 00
                              ^^       ^^
> a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2b 12 14 00
                                          ^^
> b0: 49 da 00 60 31 ff 80 05 67 00 00 00 00 00 00 00
            ^^
> f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 00 00
                                                ^^ ^^

Buggy: (Own, buggy settings in parens)

> 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
> 	Subsystem: ABIT Computer Corp.: Unknown device a401
> 	Flags: bus master, medium devsel, latency 8
                                                  ^ That's more reasonable.
> 	Memory at d8000000 (32-bit, prefetchable) [size=64M]
> 	Capabilities: [a0] AGP version 2.0
> 	Capabilities: [c0] Power Management version 2
> 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 08 00 00
                                              ^ Latency
> 50: 17 a3 eb b4 43 89 10 10 c0 00 08 10 10 10 10 10
                  ^^ ^^					(47 8d here)
> 60: 03 aa 02 20 e6 d6 d6 c6 45 28 43 0f 08 3f 00 00
                              ^^       ^^		(41 .. 21 here)
> a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2f 12 14 00
                                          ^^		(6b here)
> b0: 49 da 88 60 31 ff 80 05 67 00 00 00 00 00 00 00
            ^^						(22 here)
> f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 91 06
                                                ^^ ^^	(00 00 here)

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: VIA KT133A / athlon / MMX

[Daniela Engert]

Hi Kurt!

On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote:

>Me neither. I was hoping that only a bit differs. Unfortunately that's not
>the case, so I need to have a look in the datasheet.
>But those are not publically available :-(
>Anybody having them?

Try to get a clue yourself from the WPCREDIT KT133 plugin (see below,
stripped down to the differing registers). Some differences look
suspicious to me...

>Working:

>> 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 00 00 00
>                                              ^ Latency.
>> 50: 17 a3 eb b4 02 00 10 10 c0 00 08 10 10 10 10 10
>                  ^^ ^^
>> 60: 03 aa 02 20 e6 d6 d6 c6 51 28 43 0d 08 3f 00 00
>                              ^^       ^^
>> a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2b 12 14 00
>                                          ^^
>> b0: 49 da 00 60 31 ff 80 05 67 00 00 00 00 00 00 00
>            ^^
>> f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 00 00
                                                ^^ ^^

>Buggy: (Own, buggy settings in parens)

>> 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 08 00 00
>                                              ^ Latency
>> 50: 17 a3 eb b4 43 89 10 10 c0 00 08 10 10 10 10 10
>                  ^^ ^^				(47 8d here)
>> 60: 03 aa 02 20 e6 d6 d6 c6 45 28 43 0f 08 3f 00 00
>                              ^^       ^^		(41 .. 21 here)
>> a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2f 12 14 00
>                                          ^^		(6b here)
>> b0: 49 da 88 60 31 ff 80 05 67 00 00 00 00 00 00 00
>            ^^						(22 here)
>> f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 91 06
>                                                ^^ ^^	(00 00 here)

PCR(PCI Configration Registers) Editor / WPCREDIT for WIN32
Copyright (c) 2000  H.Oda!

[COMMENT]=for HWup ng. members (Kx) edited by Guruad tnx to author
H.Oda!
[MODEL]=VT8363 (KT133)
[VID]=1106:VIA
[DID]=0305:Host to PCI Bridge

[54:7]=SDRAM Self-Refresh	0=disable   1=enable
[54:6]=Probe Next Tag State T1	0=disable   1=enable
[54:5]=High Priority DRAM Req.	0=disable   1=enable
[54:4]=Continuous DRAM Request	0=disable   1=enable
[54:3]=DRAM Speculative Read	0=disable   1=enable
[54:2]=PCI Master Pipeline Req. 0=disable   1=enable
[54:1]=PCI-to-CPU / CPU-to-PCI	0=disable   1=enable
[54:0]=Fast Write-to-Read	0=disable   1=enable

[55:0]=S2K Compensation CPU Halt0=disable   1=enable

[68:7]=SDRAM Open Page Control	0=precharge  1=remain act
[68:6]=Bank Page Control	0=same bank  1=different
[68:5]=(Reserved)
[68:4]=DRAM Data Latch Delay	0=Latch     1=Delay latch
[68:3]=EDO Test Mode		0=disable   1=enable
[68:2]=Burst Refresh(4 times)	0=disable   1=enable
[68:1]=System Frequency Divider 00= 66 MHz  01=100 MHz
[68:0]=10=133 MHz  11=Reserved

[6B:7]=Arbitration Parking Pol. 00=bus owner 01=CPU side
[6B:6]=10=AGP side  11=Reserved
[6B:5]=Fast Read to Write t-a	0=disable   1=enable
[6B:4]=(Reserved)
[6B:3]=MD Bus Second Level	0=Normal slew 1=More
[6B:2]=CAS Bus Second Level	0=Normal slew 1=More
[6B:1]=Virtual Channel-DRAM	0=disable   1=enable
[6B:0]=Multi-Page Open		0=disable   1=enable

[AC:7]=(Reserved)
[AC:6]=AGP Read Synchronization 0=disable   1=enable
[AC:5]=AGP Read Snoop DRAM P-W-B0=disable   1=enable
[AC:4]=GREQ# Priority		0=disable   1=enable
[AC:3]=2X Rate Supported	0=not	    1=supported
[AC:2]=LPR In-Order Access	0=not	    1=executed
[AC:1]=AGP Arbitration Parking	0=disable   1=enable
[AC:0]=AGP-PCI Master/CPU-PCI TC0=2T or 3T  1=1T

[B2:7]=GD/GBE/GDS, SBA/SBS Ctrl
[B2:6]=(Reserved)
[B2:5]=(Reserved)
[B2:4]=GD[31-16] Staggered Delay0=none	    1=1ns
[B2:3]=(Reserved)
[B2:2]=(Reserved)
[B2:1]=AGP Voltage		0=1.5V	    1=3.3V
[B2:0]=GDS Output Delay 	0=none	    1=0.4ns

[FE]=Back-Door Device ID
[FF]=Back-Door Device ID

'54'=BIU Control 00 RW
'55'=Debug (Do Not Program)
'68'=DRAM Control 00 RW
'6B'=DRAM Arbitration Control 01 RW
'AC'=AGP Control 00 RW
'B2'=AGP Pad Drive / Delay Control 00 RW
'FE..FF' Back-Door Device ID 0000 RW

Ciao,
  Dani

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniela Engert, systems engineer at MEDAV GmbH
Gräfenberger Str. 34, 91080 Uttenreuth, Germany
Phone ++49-9131-583-348, Fax ++49-9131-583-11

Re: VIA KT133A / athlon / MMX

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

Hi Daniela,

On Mon, Jul 30, 2001 at 08:04:54AM +0200, Daniela Engert wrote:
> On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote:
> 
> >Me neither. I was hoping that only a bit differs. Unfortunately that's not
> >the case, so I need to have a look in the datasheet.
> >But those are not publically available :-(
> >Anybody having them?
> 
> Try to get a clue yourself from the WPCREDIT KT133 plugin (see below,
> stripped down to the differing registers). Some differences look
> suspicious to me...

Hey thanks!

> [54:6]=Probe Next Tag State T1	0=disable   1=enable

Main suspect. (Should be 0)

> [54:0]=Fast Write-to-Read	0=disable   1=enable

Third candidate. (Should be 0)

> [68:4]=DRAM Data Latch Delay	0=Latch     1=Delay latch

Second candidate (Should be 1)

> [68:2]=Burst Refresh(4 times)	0=disable   1=enable

Fourth candidate (Should be 0?)

> [6B:5]=Fast Read to Write t-a	0=disable   1=enable

Should this one match 54:0 (third candidate)?

> [6B:1]=Virtual Channel-DRAM	0=disable   1=enable

Strange, why does this one differ between the configs.

OK, I'll come up with a kernel patches (driver/pci/quirks ...)
for people to test.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: VIA KT133A / athlon / MMX

[Michael]

> > On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote:
> > [54:6]=Probe Next Tag State T1	0=disable   1=enable
> 
> Main suspect. (Should be 0)

That's set in my stable kt133a system.
 
> > [54:0]=Fast Write-to-Read	0=disable   1=enable
> 
> Third candidate. (Should be 0)

as is this one.
 
> > [68:2]=Burst Refresh(4 times)	0=disable   1=enable
> 
> Fourth candidate (Should be 0?)

I set this one yesterday to see if it would trigger the problem, it
didn't :o/ Same with a few differences between my system and 0x6b, which
didn't either.

Out of curiosity, where are you getting the 'should be 0/1' details from?
-- 
Michael.
 

Re: VIA KT133A / athlon / MMX

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

Hi Michael,

thanks for your comments!

On Mon, Jul 30, 2001 at 03:15:38PM +0100, Michael wrote:
> > > On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote:
> > > [54:6]=Probe Next Tag State T1	0=disable   1=enable
> > 
> > Main suspect. (Should be 0)
> 
> That's set in my stable kt133a system.

But did you experience problems at all with your kernel when compiled for
K7? Note that most (if not all) systems seem to work stable with K6 or PPro
optimized kernels.

> > > [54:0]=Fast Write-to-Read	0=disable   1=enable
> > 
> > Third candidate. (Should be 0)
> 
> as is this one.
>  
> > > [68:2]=Burst Refresh(4 times)	0=disable   1=enable
> > 
> > Fourth candidate (Should be 0?)
> 
> I set this one yesterday to see if it would trigger the problem, it
> didn't :o/ Same with a few differences between my system and 0x6b, which
> didn't either.
> 
> Out of curiosity, where are you getting the 'should be 0/1' details from?

Comparing the lspci -vxxx output of working and non-working systems.

You did no comment on the second candidate:

> [68:4]=DRAM Data Latch Delay  0=Latch     1=Delay latch

Second candidate (Should be 1)

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: VIA KT133A / athlon / MMX

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 689 bytes --]

Hi,

OK, patches for different bits are attached.
The patch does modify up to 4 bits, which is more than I would like to do in
the end. But you can easily disable some parts of it, if the full patch
proves to solve your trouble.
Please test!

It seemed to solved the trouble here on first sight (booting went further
then normal) but in the end did not turn out to solve the trouble here.
(Here means: MSI K7T Turbo (Ver.3) with AMD K7 1.2GHz.)

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

[-- Attachment #1.2: 247-viakt133.diff --]
[-- Type: text/plain, Size: 2250 bytes --]

--- linux-2.4.7.compile/drivers/pci/quirks.c.orig	Tue Jul 24 16:50:41 2001
+++ linux-2.4.7.compile/drivers/pci/quirks.c	Mon Jul 30 20:21:56 2001
@@ -160,6 +160,49 @@
 }
 
 /*
+ * KT133a will fsck up under some circumstances if Burst Refresh (4 times)
+ * is enabled or if data latch delay is disabled
+ * and we use the fast streaming K7 optimized zero_page
+ * and copy_page routines from arch/i386/lib/mmx.c 
+ * -- garloff@suse.de, 2001-07-30
+ */
+static void __init quirk_via_noburstrefresh(struct pci_dev *dev)
+{
+	u8 dram_ctrl;
+	pci_read_config_byte(dev, 0x68, &dram_ctrl);
+	if (dram_ctrl & 0x04 || !(dram_ctrl & 0x10)) {
+		if (dram_ctrl & 0x04)
+	  		printk(KERN_INFO "VIA KT133a: Disabling burst refresh.\n");
+		dram_ctrl &= ~0x04;
+		if (!(dram_ctrl & 0x10))
+	  		printk(KERN_INFO "VIA KT133a: Enabling data latch delay.\n");
+		dram_ctrl |= 0x10;
+		pci_write_config_byte(dev, 0x68, dram_ctrl);
+	}
+}
+
+/*
+ * KT133a will fsck up under some circumstances if Probe Next Tag State 
+ * T1 is set to 1 and we use the fast streaming K7 optimized zero_page
+ * and copy_page routines from arch/i386/lib/mmx.c 
+ * -- garloff@suse.de, 2001-07-30
+ */
+static void __init quirk_via_noprobenexttag(struct pci_dev *dev)
+{
+	u8 biu_ctrl;
+	pci_read_config_byte(dev, 0x54, &biu_ctrl);
+	if (biu_ctrl & 0x40 || biu_ctrl & 0x01) {
+		if (biu_ctrl & 0x40)
+			printk(KERN_INFO "VIA KT133a: Disabling probe next tag state T1.\n");
+		if (biu_ctrl & 0x01)
+			printk(KERN_INFO "VIA KT133a: Disabling fast write-to-read.\n");
+		biu_ctrl &= ~0x41;
+		pci_write_config_byte(dev, 0x54, biu_ctrl);
+	}
+}
+
+
+/*
  *	Natoma has some interesting boundary conditions with Zoran stuff
  *	at least
  */
@@ -452,6 +495,9 @@
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_82C586_2,	quirk_via_irqpic },
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_82C686_5,	quirk_via_irqpic },
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_82C686_6,	quirk_via_irqpic },
+
+	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8363_0,	quirk_via_noburstrefresh },
+	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8363_0,	quirk_via_noprobenexttag },
 
 	{ 0 }
 };

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: VIA KT133A / athlon / MMX

[Gerbrand van der Zouw]

Hi,

Kurt Garloff wrote:

 > It seemed to solved the trouble here on first sight (booting went further
 > then normal) but in the end did not turn out to solve the trouble here.
 > (Here means: MSI K7T Turbo (Ver.3) with AMD K7 1.2GHz.)

from your lspci output I seem to have exactly the same system as you 
have. I tried your patch (247-viakt133.diff) and came up with the same 
result here: it seemed to come further than last time with only 
2.4.6ac5, but then it crashed anyway. If you know of any BIOS parameters 
  that might help for this mobo, please let me know. I could not 
identify a parameter that does the same as the "DRAM Prefetch" for Abit 
mobos.

Regards,

Gerbrand van der Zouw

Re: VIA KT133A / athlon / MMX

[Daniela Engert]

Hi Kurt!

On Mon, 30 Jul 2001 15:44:58 +0200, Kurt Garloff wrote:

Just for reference: these are the values taken from my main machine
(Epox EP8KTA2, VIA KT133) with the latest BIOS:

>> [54:6]=Probe Next Tag State T1	0=disable   1=enable
>Main suspect. (Should be 0)

Set to 1 here.

>> [54:0]=Fast Write-to-Read	0=disable   1=enable
>Third candidate. (Should be 0)

Set to 1 here.

>> [68:4]=DRAM Data Latch Delay	0=Latch     1=Delay latch
>Second candidate (Should be 1)

Set to 1 here.

>> [68:2]=Burst Refresh(4 times)	0=disable   1=enable
>Fourth candidate (Should be 0?)

Set to 0 here.

>> [6B:5]=Fast Read to Write t-a	0=disable   1=enable
>Should this one match 54:0 (third candidate)?

Set to 0 here.

>> [6B:1]=Virtual Channel-DRAM	0=disable   1=enable
>Strange, why does this one differ between the configs.

Set to 0 here.

Unfortunately, this machine doesn't run Linux...

Ciao,
  Dani

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> Let us be a bit more precise here.  If you click on the help button when deciding whether to select
> that option it tells you not to do it.  What can you say about a distro that doesn't read the help
> buttons for the kernel options when configuring the kernel?  Shovelware?

The alternative was to disable it. Because at the time we had lots of good
evidence it didnt work reliably. Evidence backed up by the pile of later
Chris Mason patches.

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Alan Cox wrote:
> 
> > Let us be a bit more precise here.  If you click on the help button when deciding whether to select
> > that option it tells you not to do it.  What can you say about a distro that doesn't read the help
> > buttons for the kernel options when configuring the kernel?  Shovelware?
> 
> The alternative was to disable it. Because at the time we had lots of good
> evidence it didnt work reliably. Evidence backed up by the pile of later
> Chris Mason patches.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Better to disable it than to cripple it.

By the way, how about considering the use of tests before redhat coders put stuff in the linux
kernel?  You know, if VFS changes actually got tested before users encountered things like Viro
breaking ReiserFS in 2.4.5, it would be nice.

At Namesys, like all normal software shops, we actually run a test suite before shipping code
externally.  We usually try to require that it be tested by at least one person in addition to the
code author.

It would catch things like your gcc problems.  Test suites don't catch everything, but they are
considered the responsible thing to do at most places.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> By the way, how about considering the use of tests before redhat coders put stuff in the linux
> kernel?  You know, if VFS changes actually got tested before users encountered things like Viro
> breaking ReiserFS in 2.4.5, it would be nice.
> At Namesys, like all normal software shops, we actually run a test suite before shipping code
> externally.  We usually try to require that it be tested by at least one person in addition to the
> code author.

*PLONK*

No doubt if Namesys ran test suites all the tail merging bug fiasco and the
directory/tree balance races wouldnt have happened.

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Alan Cox wrote:
> 
> > By the way, how about considering the use of tests before redhat coders put stuff in the linux
> > kernel?  You know, if VFS changes actually got tested before users encountered things like Viro
> > breaking ReiserFS in 2.4.5, it would be nice.
> > At Namesys, like all normal software shops, we actually run a test suite before shipping code
> > externally.  We usually try to require that it be tested by at least one person in addition to the
> > code author.
> 
> *PLONK*
> 
> No doubt if Namesys ran test suites all the tail merging bug fiasco and the
> directory/tree balance races wouldnt have happened.
Our test suites need much improvement, but we do have them and use them.  Can you say the same?

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Mason]

On Saturday, July 28, 2001 11:36:33 AM +0400 Hans Reiser <reiser@namesys.com>
wrote:

> Alan Cox wrote:
>> 
>> No doubt if Namesys ran test suites all the tail merging bug fiasco and the
>> directory/tree balance races wouldnt have happened.
> Our test suites need much improvement, but we do have them and use them.
> Can you say the same?

He's already described some of the testing they do.  I would suggest there
are better ways to use l-k bandwidth than picking a fight with redhat,
especially on topics that have already been beaten to death.  

Alan, thanks for helping to test the reiserfs patches we've been sending to
in the ac tree, we do appreciate it.

-chris

Re: Linx Kernel Source tree and metrics

[Alan Cox]

> If this happens, I'll update it to the latest source (whatever happens to be available at that time). If it doesn't, I'll update it anyway and just bite the
> bullet and upload the data to a server with more bandwidth.

bzip2 -9 is your friend for repetetive data 8)

Re: Linx Kernel Source tree and metrics

[Paul G. Allen]

Alan Cox wrote:
> 
> > If this happens, I'll update it to the latest source (whatever happens to be available at that time). If it doesn't, I'll update it anyway and just bite the
> > bullet and upload the data to a server with more bandwidth.
> 
> bzip2 -9 is your friend for repetetive data 8)

Isn't that the truth, especially for this much text (I bet it'll compress real nice :)

PGA

-- 
Paul G. Allen
UNIX Admin II/Programmer
Akamai Technologies, Inc.
www.akamai.com
Work: (858)909-3630
Cell: (858)395-5043

Re: Linx Kernel Source tree and metrics

[Paul G. Allen]

Please, no more wgets on my poor limited bandwidth (256Kbit uplink) web server. Next week I will have a fatter pipe and you can D/L the whole dir if you want.
(Though it would be better if you let me compress it and put it on a ftp server).

Thank you for your support. ;)

PGA

-- 
Paul G. Allen
UNIX Admin II/Programmer
Akamai Technologies, Inc.
www.akamai.com
Work: (858)909-3630
Cell: (858)395-5043

Re: binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Alan Cox]

> The right answer for vendors who want to ship binary modules is to
> ship an Open Source interface layer which shields the vendor from
> kernel drift (since users will be able to build the interface layer if
> they need to, without waiting for the vendor).

As people have seen from vmware and from the ever growing piles of 
nvidia crashes the truth about binary modules in general even with glue is
pain and suffering.

Veritas have some good Linux people though, and while I'm sad they won't
open source the core of veritas they do at least appear to have the
knowledgebase to do a good job

Re: binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Matthew Gardiner]

On Sunday 29 July 2001 07:08, Alan Cox wrote:
> > The right answer for vendors who want to ship binary modules is to
> > ship an Open Source interface layer which shields the vendor from
> > kernel drift (since users will be able to build the interface layer if
> > they need to, without waiting for the vendor).
>
> As people have seen from vmware and from the ever growing piles of
> nvidia crashes the truth about binary modules in general even with glue is
> pain and suffering.
>
> Veritas have some good Linux people though, and while I'm sad they won't
> open source the core of veritas they do at least appear to have the
> knowledgebase to do a good job

1. With the file system, why not charge for commercial use?
2. Regards to hardware manufacturers, what have the got to lose from 
publishing the specs? nothing.

Matthew Gardiner
-- 
WARNING:

This email was written on an OS using the viral 'GPL' as its license.

Please check with Bill Gates before continuing to read this email/posting.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Chris Wedgwood]

On Sun, Jul 29, 2001 at 10:24:11PM +1200, Matthew Gardiner wrote:

    1. With the file system, why not charge for commercial use?

Maybe they will... but it's not something they could do under the GPL.

    2. Regards to hardware manufacturers, what have the got to lose from
       publishing the specs? nothing.

Many manufactures will claim otherwise... for some hardware products,
the useful life-cycles is only six months, if you can't make money
within that period of time, the product never will --- so there are
arguments for keeping things vague for just a little while.

Also, some hardware vendors cannot release specifications because they
don't own all the IP here either (see my earlier comments) or are part
of some kind of cartel/consortium which is overrun by labatomized
lawyers, the DVD people for example.




  --cw

Re: binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Florian Weimer]

Matthew Gardiner <kiwiunixman@yahoo.co.nz> writes:

> 2. Regards to hardware manufacturers, what have the got to lose from 
> publishing the specs? nothing.

Some vendors do not have proper specs or have received them under NDA
themselves.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: make rpm

[Alan Cox]

> Alan Cox <alan@lxorguk.ukuu.org.uk> said:
> > I've been meaning to do this one for a while and I now have it working so
> > that with my current -ac kernel working tree I can type
> > 
> > 	make rpm
> > 
> > and out puts kernel-2.4.7ac3-1.i386.rpm
> 
> Great idea!
> 
> Just the bunch of "echo this or that" is ugly as sin... why not a
> kernel.spec template that gets its version &c substituted by sed(1) or
> something?

Well for one because its easier to hack on at the moment. I still need to
finish up packing the right pieces, and also checking if the user
has an /sbin/installkernel and also if they are not using GRUB need to then
rerun lilo

Alan

Re: binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Richard Gooch]

Alan Cox writes:
> > The right answer for vendors who want to ship binary modules is to
> > ship an Open Source interface layer which shields the vendor from
> > kernel drift (since users will be able to build the interface layer if
> > they need to, without waiting for the vendor).
> 
> As people have seen from vmware and from the ever growing piles of
> nvidia crashes the truth about binary modules in general even with
> glue is pain and suffering.

Sure. If you load a binary module (shim layer or not), you don't get
community support. So vendors are digging their own shitpile by
shipping binary-only drivers. I just don't see the need to shove them
in the back while they do it.

Besides, if someone can make a lot of money shipping binary drivers,
then they can afford the support costs, so it may well be a viable
revenue model for them (at the very least, programmers need to eat
too).

> Veritas have some good Linux people though, and while I'm sad they
> won't open source the core of veritas they do at least appear to
> have the knowledgebase to do a good job

Yeah, I'd rather see all source open. But that's an ideal world. In
the meantime, many people want $$$. One of the great things about
Linux is that it is open and allows different funding models. The
success of Linux is due to the openness, not some cool technological
feature.

Open Source pushes the "innovation envelope". Eventually, the "core"
(what's now the basic OS) which isn't worth selling grows outwards,
consuming areas where it used to be profitable to sell software. So it
forces companies to innovate or die, leading to a dynamic industry.
That is good for both Society and Industry (as seen by the respective
idealogical poles).

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Chris Wedgwood]

On Sun, Jul 29, 2001 at 03:05:06AM -0400, Richard Gooch wrote:

    Yeah, I'd rather see all source open. But that's an ideal world. In
    the meantime, many people want $$$. One of the great things about
    Linux is that it is open and allows different funding models. The
    success of Linux is due to the openness, not some cool technological
    feature.

People all need to appreciate sometimes vendors cannot released open
source drivers even if they wanted too.  Sometimes vendors have the
ability to released binary only drivers which are derived in part from
source-code which they license --- but cannot share.

This is also the case for various SCSI cards and such like, firmware
is provided binary-only because the source for the firmware isn't
something that can be distributed.



  --cw

Re: binary modules (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Florian Weimer]

Chris Wedgwood <cw@f00f.org> writes:

> People all need to appreciate sometimes vendors cannot released open
> source drivers even if they wanted too.  Sometimes vendors have the
> ability to released binary only drivers which are derived in part from
> source-code which they license --- but cannot share.

That's particularly true if there is no other documentation for the
hardware other than this reference source code.  This seems to be a
common situation, even with hardware which has good specs, technically
speaking.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: 2.4.2 ext2fs corruption status

[Alan Cox]

> It may be that Red Hat has already released a new kernel RPM since that
> time, or maybe you need to compile a new kernel.

The official VIA workaround fix is now in 2.4.6ac5 and 2.4.7ac*. The fixes
in the older kernels were mostly going to do the job but I dont know if they
were perfect for all cases

The -ac kernel tree also contains important fixes that avoid DMA timeouts
potentially causing disk corruption by forgetting to write sectors

Re: 2.4.2 ext2fs corruption status

[Mohamed DOLLIAZAL]

Alan Cox wrote:

> > It may be that Red Hat has already released a new kernel RPM since that
> > time, or maybe you need to compile a new kernel.
>
> The official VIA workaround fix is now in 2.4.6ac5 and 2.4.7ac*. The fixes
> in the older kernels were mostly going to do the job but I dont know if they
> were perfect for all cases
>
> The -ac kernel tree also contains important fixes that avoid DMA timeouts
> potentially causing disk corruption by forgetting to write sectors

Hi Alan,

   I'am sorry I forgot to mention that the filesystem corruption happened on
SCSI disks.  I guess there is no DMA on the SCSI disks.
   Do you think that the VIA fixes that are included in the 2.4.6ac5 kernel or
above may solve my problem.

Thanks for your help,

Mohamed.

Re: Memory Write Ordering Question

[Alan Cox]

> I'm wondering if anyone has any idea what exactly is causing this.  The
> readl is a so-so work around.  I'd like to figure out how to do it
> correctly.  Does anyone who knows more about Intel CPU's and write
> ordering and PCI have any ideas?

Its entirely a PCI issue. PCI writes are posted and may be deferred. However
a write cannot pass another write to the device, nor a read, so your read
is the real solution.

The full horror is in the PCI specs which you can get on CD nowdays fairly
sanely. Basically PCI is a message passing system disguised as a bus, treat
it as the former and you wont get too badly hurt

Re: SMP possible with AMD CPUs?

[Alan Cox]

> 	a. The IDE is no longer a 7409 PCI ID but 7411 so it operates as a generic IDE (slow as hell).
[Should run full UDMA in -ac]

> 	b. The AGP is now ID 700C and is not detected unless the agpgart driver is loaded with agp_try_unsupported=1.

Send me the relevant pci idents and I'll add it

> 	d. The PCI bridge ID is different and (again) operates in a generic modeAgain send me the ids
> 	e. The Host bridge ID is now 700C and operates in a generic mode.

Send me the idents for these two

> 3. The BIOS (apparently) doesn't setup the MTRR properly on both CPUs making mtrr bitch about a mismatch.

The mtrr driver fixups should cure that - its a common bios bug.

Alan

Re: SMP possible with AMD CPUs?

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
 
> > 3. The BIOS (apparently) doesn't setup the MTRR properly on both CPUs making
> mtrr bitch about a mismatch.
> 
> 
> The mtrr driver fixups should cure that - its a common bios bug.

There is some truth in that.  But note AMD hasn't released all of the
documentation related to their MTRR's so we can't rely on linux fixing
all of those BIOS bugs.   In this case it happens to be different
caching on the BIOS chip, from different cpus.

An interesting question is what is 0x1e in the AMD fixed mtrr's.

Eric

Re: 2.4.2 ext2fs corruption status

[Alan Cox]

>    I'am sorry I forgot to mention that the filesystem corruption happened on
> SCSI disks.  I guess there is no DMA on the SCSI disks.

Well there is but its off the scsi controller so should be ok

>    Do you think that the VIA fixes that are included in the 2.4.6ac5 kernel or
> above may solve my problem.

They might do, they might not. But they are worth checking

Re: 2.4 freezes on init

[Alan Cox]

> However, I believe the kernel image that Mandrake 8's installer uses is
> a 2.4 kernel, yet that works fine. Is this a configuration setting I
> need to toggle, or am I stuck until I switch motherboard?

In the Red Hat case we have seen cases where the installer kernel worked and
not much else did. Install kernels are generally built with the very minimum
of reliance on bios features and for 386.

Typically that means they don't enable common problem items like APM, ACPI
and Athlon optimisation in conjunction with VIA chipsets.

Alan

Re: setsockopt(..,SO_RCVBUF,..) sets wrong value

[Alan Cox]

> When I do a setsockopt(..,SO_RCVBUF,..) and then read the value back
> with getsockopt(), the reported value is exactly twice of what I set.
> Running the same code on Solaris and on DEC UNIX reports back the
> exact size I set.
> Looking at the code it seems that the  *2  should not be there:

You are making assumptions not guaranteed in POSIX or SuS. In the Linux case
we deliberately allow more than requested as our memory accounting behaviour
for buffers is very different to BSD

Re: kernel gdb for intel

[Alan Cox]

> - doesn't support SMP, since I don't have an Intel SMP box.  I'd guess
> what you'd want it to do is an smp_call_function that would halt all the
> processors and put them into some tight little loop while gdb fiddles
> things.  ideas?

With the old old stuff (pre 2.0) gdb stubs I ended up with two copies, one
per cpu on two serial ports. I found that most useful since I could force
events to happen.

Looks nice to me but about the only way you are likely to get Linus to take
in kernel debugging patches is to turn them into hex and disguise them as USB 
firmware ;)

Alan

Re: kernel gdb for intel

[Amit S. Kale]

Alan Cox wrote:
> 
> > - doesn't support SMP, since I don't have an Intel SMP box.  I'd guess
> > what you'd want it to do is an smp_call_function that would halt all the
> > processors and put them into some tight little loop while gdb fiddles
> > things.  ideas?
> 
> With the old old stuff (pre 2.0) gdb stubs I ended up with two copies, one
> per cpu on two serial ports. I found that most useful since I could force
> events to happen.

I can't get this. How can two gdb stubs work correctly
on two serial ports? In absence of any globals, there won't be
any data corruption, though there are inherent assumptions in 
the kernel about progress on all cpus. If GKL, page cache lock etc
are held by one cpu, the other cpu will not be able to make
any/much progress.

Are two gdb stubs useful for debugging some particular kind
of problem? If they are I can think about how I can
add them to current x86 kgdb (kgdb.sourceforge.net).
-- 
Amit Kale
Veritas Software ( http://www.veritas.com )

Re: 3ware Escalade problems? Adaptec?

[Alan Cox]

> I've been pricing out a 3ware-based raid system for my own personal use. Are
> the problems wuth the Escalade cards bad enough to consider not using them
> with 2.4.7?

Im really attached to my 3ware cards, they are the best ide raid cards I've
used. The newer boxes I built just use software raid 0/1 which is easy now
that everyone throws 4 UDMA100 channels on their motherboards.

I've also done the i2o driver fixups for the Promise SuperTrak100 with a
card provided by Promise and that works in -ac but not yet Linus tree.
I'm more impressed with the 3ware than the promise card right now, although
it will depend on workload. The promise card has onboard caches and raid5 
hardware which the earlier 3ware didn't.

Re: [PATCH] make psaux reconnect adjustable

[Alan Cox]

> who asked for this code): if what I say is correct you should
> always see 00 following the AA. So, there may exist a more cautious
> patch that will bite fewer people and does not react to AA but to
> the sequence AA 00.

2.2 has had the sysctl for ages, and it defaults to off

Re: [RFT] Support for ~2144 SCSI discs

[Alan Cox]

> I've seen GFP_KERNEL take 10 minutes in lk 2.4.6 . The 
> mm gets tweaked pretty often so it is difficult to know 
> exactly how it will react when memory is tight. A time 
> bound would be useful on GFP_KERNEL.

kmalloc with GFP_KERNEL has a 128K limit which avoids the bizarre behaviour
you get when you abuse get_free_pages.

Re: [RFT] Support for ~2144 SCSI discs

[Richard Gooch]

Alan Cox writes:
> > I've seen GFP_KERNEL take 10 minutes in lk 2.4.6 . The 
> > mm gets tweaked pretty often so it is difficult to know 
> > exactly how it will react when memory is tight. A time 
> > bound would be useful on GFP_KERNEL.
> 
> kmalloc with GFP_KERNEL has a 128K limit which avoids the bizarre
> behaviour you get when you abuse get_free_pages.

Last I heard, get_free_pages() also has a 128 kiB limit. So what's the
difference?

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [RFT] Support for ~2144 SCSI discs

[Alan Cox]

> > kmalloc with GFP_KERNEL has a 128K limit which avoids the bizarre
> > behaviour you get when you abuse get_free_pages.
> 
> Last I heard, get_free_pages() also has a 128 kiB limit. So what's the
> difference?

get_free_pages doesnt have such a limit. Thats why sg had the problem it did

Re: [RFT] Support for ~2144 SCSI discs

[Douglas Gilbert]

Alan Cox wrote:
> 
> > > kmalloc with GFP_KERNEL has a 128K limit which avoids the bizarre
> > > behaviour you get when you abuse get_free_pages.
> >
> > Last I heard, get_free_pages() also has a 128 kiB limit. So what's the
> > difference?
> 
> get_free_pages doesnt have such a limit. Thats why sg had the problem it did

Alan,
That is incorrect.

The failure I got with the sg driver with cdrdao
and cdda2wav was with 32 KB buffers, lots of them.
cdda2wav in RH 7.1 was trying to get 100 MB of them!

If you look at the sg driver you will find that it never
attempts a get_free_pages greater than SG_SCATTER_SZ (32 KB).
So that unkillable lockup on those apps demonstrates
rather well that GFP_KERNEL is dangerous.

Doug Gilbert

Re: [RFT] #2 Support for ~2144 SCSI discs

[Alan Cox]

> So, yes, you can already patch other subsystems to dynamically assign
> major numbers in 2.4.7. I'd like to see people do that. My patch for
> sd.c can also serve as a demonstration on how to use the new API.

Its a bit of an ugly hack but I guess its the best anyone can put together
for a 2.4 kernel tree. Going to a 32bit dev_t is going to make life so much
simpler do all of this without ugly hacks

Alan

Re: [RFT] #2 Support for ~2144 SCSI discs

[Richard Gooch]

Alan Cox writes:
> > So, yes, you can already patch other subsystems to dynamically assign
> > major numbers in 2.4.7. I'd like to see people do that. My patch for
> > sd.c can also serve as a demonstration on how to use the new API.
> 
> Its a bit of an ugly hack but I guess its the best anyone can put
> together for a 2.4 kernel tree. Going to a 32bit dev_t is going to
> make life so much simpler do all of this without ugly hacks

My patch is definately 2.4 material. I see it as a temporary solution
until the whole block I/O subsystem is ripped out and replaced in 2.5.
Since 2.4 will be the latest production kernel for about two years, we
need to find ways of working around current limitations.

That said, in 2.5 I want to see us move away from using device numbers
as the fundamental device handle and move to device instance
structures. That's a lot cleaner, and BTW is devfs-neutral
(i.e. doesn't need devfs to work). Exposing a 32 bit dev_t to
user-space is acceptable, but internally it should be shunned.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [RFT] #2 Support for ~2144 SCSI discs

[Alan Cox]

> That said, in 2.5 I want to see us move away from using device numbers
> as the fundamental device handle and move to device instance
> structures. That's a lot cleaner, and BTW is devfs-neutral
> (i.e. doesn't need devfs to work). Exposing a 32 bit dev_t to
> user-space is acceptable, but internally it should be shunned.

You need it internally otherwise you are screwed the moment you have 65536
volumes mounted - because you run out of unique device identifiers for stat.

Fortunately 32bit dev_t (not kdev_t .. which I think is what you are talking
about and will I assume go pointer to struct) is only one syscall change

Re: [RFT] #2 Support for ~2144 SCSI discs

[Richard Gooch]

Alan Cox writes:
> > That said, in 2.5 I want to see us move away from using device numbers
> > as the fundamental device handle and move to device instance
> > structures. That's a lot cleaner, and BTW is devfs-neutral
> > (i.e. doesn't need devfs to work). Exposing a 32 bit dev_t to
> > user-space is acceptable, but internally it should be shunned.
> 
> You need it internally otherwise you are screwed the moment you have
> 65536 volumes mounted - because you run out of unique device
> identifiers for stat.

I consider that "external" use. The kernel doesn't need it, it just
provides unique numbers for user-space. The kernel just happens to
carry along the information so that user-space can get it as needed.

Aside: the idea of mounting >65536 volumes frightens me. Accidentally
do a "df" and go away for a coffee while your machine hammers away.

> Fortunately 32bit dev_t (not kdev_t .. which I think is what you are
> talking about and will I assume go pointer to struct) is only one
> syscall change

Looks like we agree. And as long as you have <65536 volumes, then
libc5 will continue to work just fine. Which is also good.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] make psaux reconnect adjustable

[Alan Cox]

> Of course I hope that we'll handle this correctly at some point,
> without any options or parameters. In my eyes a sysctl is heavier
> infrastructure than a boot parameter, so I prefer the latter
> when a temporary fix is needed.

The input device infrastructure pending for 2.5 already handles all of
these issues

Re: [PATCH] vxfs fix

[Alan Cox]

> 	From: Alan
> 
> 	Alternatively pass a flag to the mount command saying
> 	"this is a guesswork special" then V7 fs can just return 'not me'
> 
> Parse failure.

Let me try again:

When the read_super method is invoked
AND we are doing a mount without a defined type
	THEN
		Pass the fs a flag from the VFS saying so
	ENDIF

That way the file system can actually say "I cannot reliably check"

Re: [PATCH] vxfs fix

[Andreas Dilger]

Alan writes:
> When the read_super method is invoked
> AND we are doing a mount without a defined type
> 	THEN
> 		Pass the fs a flag from the VFS saying so
> 	ENDIF
> 
> That way the file system can actually say "I cannot reliably check"

Isn't this what the "silent" option to read_super is for?  It may be that
it can only be used at root fs mount time.  Other than that, I don't
_think_ the kernel does autoprobing of filesystem types, so it is a
mount(8) issue to just not randomly try the V7 filesystem type.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: kernel gdb for intel

[Alan Cox]

> I can't get this. How can two gdb stubs work correctly
> on two serial ports? In absence of any globals, there won't be
> any data corruption, though there are inherent assumptions in 
> the kernel about progress on all cpus. If GKL, page cache lock etc
> are held by one cpu, the other cpu will not be able to make
> any/much progress.

That is fine. It'll get stuck in a lock. One thing it was useful for was
exactly that - getting a given point and checking the locking cases worked

Re: DoS with tmpfs #3

[Alan Cox]

> The same horrible think happens to ramfs, but this
> could be expected. Ramfs don't have size check so that
> hack cannot be used for it.  In this case ramfs must
> be marked as dangerous. 

Ramfs and tmpfs in the -ac tree should behave a lot better. The 
fact you see high pages being a factor sounds to me like a VM rather than
a tmpfs bug. Specifically you should have seen KDE apps terminating with
out of memory kills. 

In paticular in the -ac tree ramfs supports setting limits on the max fs
size, which is essential if you want to use it on something like an iPAQ
where ramfs is a real useful fs to have.

tmpfs would I suspect also benefit immensely from quota support

Alan

Re: Question regarding ACPI

[Alan Cox]

> Will ACPI error be corrected. Since I started compiling my own kernel, 
> version 2.4.6, ACPI hasn't worked. Has the kernel maintainer given up on 
> it? or is it still in the ACPI think tank?

You probably want to drop a mail to andrew.grover@intel.com and also see
http://phobos.fs.tum.de/acpi/index.html which is the mailing list for
ACPI. 

Re: Error when compiling 2.4.7ac6

[Alan Cox]

> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
> -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
> pipe -mpreferred-stack-boundary=2 -march=i686    -DEXPORT_SYMTAB -c check.c
> In file included from check.c:28:
> ldm.h:100: warning: `SYS_IND' redefined
> ldm.h:84: warning: this is the location of the previous definition
> ldm.h:104: warning: `NR_SECTS' redefined
> ldm.h:88: warning: this is the location of the previous definition
> ldm.h:109: warning: `START_SECT' redefined
> ldm.h:92: warning: this is the location of the previous definition
> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
> -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
> pipe -mpreferred-stack-boundary=2 -march=i686    -c -o msdos.o msdos.c
> rm -f partitions.o

Thanks - fixed 

Re: MTRR and Athlon Processors

[Alan Cox]

> Is the mtrr code supposed to work properly for Athlon (Model 4) in
> kernel 2.4.7?
> 
> I still get mtrr errors/warnings.

Mismatched mtrr warnings indicate bios writers who cannot read
specifications. The kernel will fix up after it

Re: MTRR and Athlon Processors

[Paul G. Allen]

Alan Cox wrote:
> 
> > Is the mtrr code supposed to work properly for Athlon (Model 4) in
> > kernel 2.4.7?
> >
> > I still get mtrr errors/warnings.
> 
> Mismatched mtrr warnings indicate bios writers who cannot read
> specifications. 

This does not surprise me. In fact, I need to check Tyan's web site for
a BIOS update.

> The kernel will fix up after it

I also get this message:

Jul 29 03:33:00 keroon kernel: mtrr: type mismatch for f8000000,4000000
old: write-back new: write-combining

This happens quite often, especially with the agpgart and NVdriver
modules.

PGA

-- 
Paul G. Allen
UNIX Admin II/Network Security
Akamai Technologies, Inc.
www.akamai.com

Re: MTRR and Athlon Processors

[Dave Jones]

On Sat, 4 Aug 2001, Paul G. Allen wrote:

> Jul 29 03:33:00 keroon kernel: mtrr: type mismatch for f8000000,4000000
> old: write-back new: write-combining
>
> This happens quite often, especially with the agpgart and NVdriver
> modules.

iirc, this is a problem with the nvidia module, and there's nothing
the kernel can do about it. Complain to nvidia.

regards,

Dave.

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

Re: MTRR and Athlon Processors

[Paul G. Allen]

Dave Jones wrote:
> 
> On Sat, 4 Aug 2001, Paul G. Allen wrote:
> 
> > Jul 29 03:33:00 keroon kernel: mtrr: type mismatch for f8000000,4000000
> > old: write-back new: write-combining
> >
> > This happens quite often, especially with the agpgart and NVdriver
> > modules.
> 
> iirc, this is a problem with the nvidia module, and there's nothing
> the kernel can do about it. Complain to nvidia.
> 

If I knew who to complain to, I would. I used to have a contact there,
but I seem to have lost his e-mail address. :(

(BTW, There's no update to the Tyan [Pheonix] BIOS as yet either.)

PGA

-- 
Paul G. Allen
UNIX Admin II/Network Security
Akamai Technologies, Inc.
www.akamai.com

Re: Error when compiling 2.4.7ac6

[Anton Altaparmakov]

At 01:46 05/08/2001, Alan Cox wrote:
> > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
> > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
> > pipe -mpreferred-stack-boundary=2 -march=i686    -DEXPORT_SYMTAB -c check.c
> > In file included from check.c:28:
> > ldm.h:100: warning: `SYS_IND' redefined
> > ldm.h:84: warning: this is the location of the previous definition
> > ldm.h:104: warning: `NR_SECTS' redefined
> > ldm.h:88: warning: this is the location of the previous definition
> > ldm.h:109: warning: `START_SECT' redefined
> > ldm.h:92: warning: this is the location of the previous definition
> > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
> > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
> > pipe -mpreferred-stack-boundary=2 -march=i686    -c -o msdos.o msdos.c
> > rm -f partitions.o
>
>Thanks - fixed

It's quite funny gcc-2.96 doesn't give these warnings. Perhaps it sees that 
the defines are identical and shuts up?

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: Error when compiling 2.4.7ac6

[Alan Cox]

> It's quite funny gcc-2.96 doesn't give these warnings. Perhaps it sees that 
> the defines are identical and shuts up?

They are actually not identical - the bracketing varies

Re: Error when compiling 2.4.7ac6

[Anton Altaparmakov]

At 02:43 05/08/2001, Alan Cox wrote:
> > It's quite funny gcc-2.96 doesn't give these warnings. Perhaps it sees 
> that
> > the defines are identical and shuts up?
>
>They are actually not identical - the bracketing varies

Oh, ok. I didn't know they hadn't been copied verbatim...

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: SMP Support for AMD Athlon MP motherboards

[Alan Cox]

> Whats the degree of support in Linux for such an AMD mobo? Is the Athlo=
> n MP
> architecture supported at all yet?

It is supported yes. You should have seen both processors and stability

Alan

Re: 3c509: broken(verified)

[Alan Cox]

> The driver for the 3c509 of 2.4.7 is broken:
> It is impossible to set the transmitter type.
> modprobe 3c509 xcvr=X, where X is
> 0,1,2,3,4 doesn't make a difference.

Looking at the code it should set the type fine. The only bug I can see is
that it will report the default type set in the eeprom not the type you
asked.

If thats the case (please check) then its trivial to fix

Re: 3c509: broken(verified)

[Nico Schottelius]

Alan Cox wrote:

> > The driver for the 3c509 of 2.4.7 is broken:
> > It is impossible to set the transmitter type.
> > modprobe 3c509 xcvr=X, where X is
> > 0,1,2,3,4 doesn't make a difference.
>
> Looking at the code it should set the type fine. The only bug I can see is
> that it will report the default type set in the eeprom not the type you
> asked.
>
> If thats the case (please check) then its trivial to fix

While I tried to setup the driver I always let one machine
outside ping it.

It is not just the message.

ozean:~ # modprobe 3c509 ; ifconfig eth1 192.168.4.17 up

eth1: 3c5x9 at 0x360, BNC port, address  00 60 97 39 43 b9, IRQ 5.
3c509.c:1.18 12Mar2001 becker@scyld.com
http://www.scyld.com/network/3c509.html

- the light on the hub keeps off, no ping answer

ozean:~ # ifconfig eth1 down ; rmmod 3c509;

ozean:~ # modprobe 3c509 xcvr=4 debug=4

## xcvr=4 is TP (found on scyld.com/network/3c509.html)


3c509.c:1.18 12Mar2001 becker@scyld.com
http://www.scyld.com/network/3c509.html
eth1: Setting Rx mode to 1 addresses.
  3c509 EEPROM word 7 0x6d50.
  3c509 EEPROM word 0 0x0060.
  3c509 EEPROM word 1 0x9739.
  3c509 EEPROM word 2 0x43b9.
  3c509 EEPROM word 8 0xc096.
  3c509 EEPROM word 9 0x5000.

eth1: 3c5x9 at 0x360, BNC port, address  00 60 97 39 43 b9, IRQ 5.
3c509.c:1.18 12Mar2001 becker@scyld.com
http://www.scyld.com/network/3c509.html
  3c509 EEPROM word 7 0xffff.
eth1: Opening, IRQ 5     status@36e 0000.
eth1: Opened 3c509  IRQ 5  status 2000.
eth1: Setting Rx mode to 1 addresses.

ozean:~ # ifconfig eth1 192.168.4.17 up

- ping does not work, no light is seen


That's it! The cable & the hub are okay.


Nico

Re: 3c509: broken(verified)

[safemode]

On Sunday 05 August 2001 10:23, Nico Schottelius wrote:
> Alan Cox wrote:
> > > The driver for the 3c509 of 2.4.7 is broken:
> > > It is impossible to set the transmitter type.
> > > modprobe 3c509 xcvr=X, where X is
> > > 0,1,2,3,4 doesn't make a difference.
> >
> > Looking at the code it should set the type fine. The only bug I can see
> > is that it will report the default type set in the eeprom not the type
> > you asked.
> >
> > If thats the case (please check) then its trivial to fix
>
> While I tried to setup the driver I always let one machine
> outside ping it.
>
> It is not just the message.
>
> ozean:~ # modprobe 3c509 ; ifconfig eth1 192.168.4.17 up
>
> eth1: 3c5x9 at 0x360, BNC port, address  00 60 97 39 43 b9, IRQ 5.
> 3c509.c:1.18 12Mar2001 becker@scyld.com
> http://www.scyld.com/network/3c509.html
>
> - the light on the hub keeps off, no ping answer
>
> ozean:~ # ifconfig eth1 down ; rmmod 3c509;
>
> ozean:~ # modprobe 3c509 xcvr=4 debug=4
>
> ## xcvr=4 is TP (found on scyld.com/network/3c509.html)
>
>
> 3c509.c:1.18 12Mar2001 becker@scyld.com
> http://www.scyld.com/network/3c509.html
> eth1: Setting Rx mode to 1 addresses.
>   3c509 EEPROM word 7 0x6d50.
>   3c509 EEPROM word 0 0x0060.
>   3c509 EEPROM word 1 0x9739.
>   3c509 EEPROM word 2 0x43b9.
>   3c509 EEPROM word 8 0xc096.
>   3c509 EEPROM word 9 0x5000.
>
> eth1: 3c5x9 at 0x360, BNC port, address  00 60 97 39 43 b9, IRQ 5.
> 3c509.c:1.18 12Mar2001 becker@scyld.com
> http://www.scyld.com/network/3c509.html
>   3c509 EEPROM word 7 0xffff.
> eth1: Opening, IRQ 5     status@36e 0000.
> eth1: Opened 3c509  IRQ 5  status 2000.
> eth1: Setting Rx mode to 1 addresses.
>
> ozean:~ # ifconfig eth1 192.168.4.17 up
>
> - ping does not work, no light is seen
>
>
> That's it! The cable & the hub are okay.
>
>
> Nico
>

i was just using a 3c509 in my friend's old 486 and it was working fine with 
2.4.7.   Just modprobed it and set up the ips and it was able to ping and be 
pinged.   

Re: 3c509: broken(verified)

[Nico Schottelius]

> i was just using a 3c509 in my friend's old 486 and it was working fine with
> 2.4.7.   Just modprobed it and set up the ips and it was able to ping and be
> pinged.

Did you use twisted pair or coax (bnc) ?

This problems occurs (at least ) when trying to use TP.

Nico

ps: Alan, do you have an solution ?

Re: 3c509: broken(verified)

[Nicholas Knight]

On Monday 06 August 2001 08:54 am, Nico Schottelius wrote:
> > i was just using a 3c509 in my friend's old 486 and it was working
> > fine with 2.4.7.   Just modprobed it and set up the ips and it was
> > able to ping and be pinged.
>
> Did you use twisted pair or coax (bnc) ?
>
> This problems occurs (at least ) when trying to use TP.
>
> Nico
>
> ps: Alan, do you have an solution ?

For what it's worth, I'm using a 3c509 card on vanilla 2.4.7 right now, 
using standard twisted pair patch cable, and it works fine. I've used it 
both as a module and compiled in (using compiled in at the moment) on 
2.4.5 and 2.4.7, I've also previously used it on 2.4.3, both compiled in 
and as a module.

The motherboard is a Soyo K7VIA w/single ISA slot, VIA Apollo Pro KX133 
chipset, using an Athlon processor.

The card is connected to a hub and communicates fine with both my other 
system and my cable modem, using DHCP.

You mention the problem is being unable to change the media, I was 
unaware this was even possible with the current 3c509 driver, and most 
people do it on 3c509's and other PNP cards of this sort (such as NE2000 
clones)  by using a DOS boot diskette and the DOS utilities provided by 
the manufacturer.

Re: Problem in Interrupt Handling ....

[Alan Cox]

> serial communication adapter which is based on
> interrrupt driven IO, top half handles registering the
> Immediate task queue and  acknowledging to PIC, bottom
> half performs the actual task of interrupt handling. 

Why are you touching the PIC at all - the kernel handles the PIC for you.
Indeed you IRQ might not even be coming from a PIC

Re: Virtual memory error when restarting X

[Alan Cox]

> Often after restarting X I see the messages similar to "NV0: still have vm que at nv_close(): 0x4023b000 to 0x40245000" in the logs. I presume that these are being caused by the properitry nvidia drivers that I use with X. However I have also noticed that "Unable to handle kernel paging request at virtual address 6b336b50" and the like have also been turning up. I'm wondering whether the graphics drivers problems could be being caused by a vm problem. The oops that
> is enclosed does not appear to be readily repeatable...  but leaving X causes sometimes the system to lock solid with only SysRq getting through. 

Talk to Nvidia. Its their obfuscated/binary driver set, nobody else can help
you fix it.

Alan

Re: [PATCH] one of $BIGNUM devfs races

[Alan Cox]

> Linus: please don't apply.
> Alan: I notice you've put Al's patch into 2.4.7-ac8. Please remove it.

I'll remove it when your preferred fixes are ready. Until then its better
than leaving it broken.

Re: [PATCH] one of $BIGNUM devfs races

[Richard Gooch]

Alan Cox writes:
> > Linus: please don't apply.
> > Alan: I notice you've put Al's patch into 2.4.7-ac8. Please remove it.
> 
> I'll remove it when your preferred fixes are ready. Until then its
> better than leaving it broken.

OK, fair enough. When is your next merge with Linus scheduled? I'd
prefer to get a few races fixed before shipping a patch, but I can try
to plan for an earlier release if necessary.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] one of $BIGNUM devfs races

[Richard Gooch]

Alan Cox writes:
> > OK, fair enough. When is your next merge with Linus scheduled? I'd
> > prefer to get a few races fixed before shipping a patch, but I can try
> > to plan for an earlier release if necessary.
> 
> I send stuff Linus regularly and sometimes it goes in and sometimes
> it doesn't. Stuff with active maintainers I don't send on to Linus
> unless asked too - hence joystick. input and much of USB are so far
> behind in Linus tree

So does that mean you won't try to merge Al's patch?

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: Encrypted Swap

[Alan Cox]

> A relatively cheap way might be a custom pci
> card with a self-destruct RAM bank for
> storing the decryption keys.  Opening the 
> safe cause the card to zero the RAM.  

IBM sell crypto PCI cards with anti tamper environments, they have
development drivers on their oss site too

Re: Encrypted Swap

[Crutcher Dunnavant]

++ 07/08/01 15:17 +0100 - Alan Cox:
> > A relatively cheap way might be a custom pci
> > card with a self-destruct RAM bank for
> > storing the decryption keys.  Opening the 
> > safe cause the card to zero the RAM.  
> 
> IBM sell crypto PCI cards with anti tamper environments, they have
> development drivers on their oss site too

Ohh. Some college buddies and I were considering the difficulty involved from
making a pci card with an onboard giger counter and radiatian source (say, from
a smoke detector) wrapped up in some lead.

Sure, there are simpler ways to build chaotic circuits, but a radioactive
peripheral is cool!

-- 
Crutcher        <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
    R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$

Re: Encrypted Swap

[Chris Wedgwood]

On Tue, Aug 07, 2001 at 11:16:35AM -0400, Crutcher Dunnavant wrote:

    Ohh. Some college buddies and I were considering the difficulty
    involved from making a pci card with an onboard giger counter and
    radiatian source (say, from a smoke detector) wrapped up in some
    lead.

    Sure, there are simpler ways to build chaotic circuits, but a
    radioactive peripheral is cool!

Why?  There are plenty of cards out that that have hardware and more.
The one in the machine I presently use is limited to 1Mbit/second of
data from a noise-diode (fed through various functions in hardware to
further obfuscate the data).




  --cw

Re: [PATCH] one of $BIGNUM devfs races

[Alan Cox]

> > unless asked too - hence joystick. input and much of USB are so far
> > behind in Linus tree
> 
> So does that mean you won't try to merge Al's patch?

Correct. I'd just get in your way if I did

Re: [PATCH] one of $BIGNUM devfs races

[Alan Cox]

> > Very interesting. pwd should be using getcwd(2), which doesn't
> > give a damn for inode numbers. If you have seriously old pwd binary
> > that tries to track the thing down to root by hands - yes, it doesn't
> > work.
> 
> Hm. strace suggests my pwd is walking up the path. But WTF would it
> break? 2.4.7 was fine. What did I break?

Sounds like you are using libc5. The old style pwd should be reliable but
its much slower and can't see across protected directory paths

Alan

Re: [PATCH] one of $BIGNUM devfs races

[Alexander Viro]

On Tue, 7 Aug 2001, Alan Cox wrote:

> > > Very interesting. pwd should be using getcwd(2), which doesn't
> > > give a damn for inode numbers. If you have seriously old pwd binary
> > > that tries to track the thing down to root by hands - yes, it doesn't
> > > work.
> > 
> > Hm. strace suggests my pwd is walking up the path. But WTF would it
> > break? 2.4.7 was fine. What did I break?
> 
> Sounds like you are using libc5. The old style pwd should be reliable but
> its much slower and can't see across protected directory paths

It is not reliable. E.g. on NFS inumbers are not unique - 32 bits is
not enough.

Re: [PATCH] one of $BIGNUM devfs races

[H. Peter Anvin]

Followup to:  <Pine.GSO.4.21.0108071510390.18565-100000@weyl.math.psu.edu>
By author:    Alexander Viro <viro@math.psu.edu>
In newsgroup: linux.dev.kernel
> 
> It is not reliable. E.g. on NFS inumbers are not unique - 32 bits is
> not enough.
> 

Unfortunately there is a whole bunch of other things too that rely on
it, and *HAVE* to rely on it -- (st_dev, st_ino) are defined to
specify the identity of a file, and if the current types aren't large
enough we *HAVE* to go to new types.  THERE IS NO OTHER WAY TO TEST
FOR FILE IDENTITY IN UNIX, and being able to perform such a test is
vital for many things, including security and hard link detection
(think tar, cpio, cp -a.)

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: [PATCH] one of $BIGNUM devfs races

[Alexander Viro]

On 8 Aug 2001, H. Peter Anvin wrote:

> Followup to:  <Pine.GSO.4.21.0108071510390.18565-100000@weyl.math.psu.edu>
> By author:    Alexander Viro <viro@math.psu.edu>
> In newsgroup: linux.dev.kernel
> > 
> > It is not reliable. E.g. on NFS inumbers are not unique - 32 bits is
> > not enough.
> > 
> 
> Unfortunately there is a whole bunch of other things too that rely on
> it, and *HAVE* to rely on it -- (st_dev, st_ino) are defined to
> specify the identity of a file, and if the current types aren't large
> enough we *HAVE* to go to new types.  THERE IS NO OTHER WAY TO TEST
> FOR FILE IDENTITY IN UNIX, and being able to perform such a test is
> vital for many things, including security and hard link detection

Indeed, but it still doesn't help libc5 getcwd(3), which uses 32 bit
values.

> (think tar, cpio, cp -a.)

I'd rather not.  Too bloody depressive... (If you want details - let's
take it off-list).

Re: [PATCH] one of $BIGNUM devfs races

[Richard Gooch]

Alexander Viro writes:
> 
> On 8 Aug 2001, H. Peter Anvin wrote:
> 
> > Followup to:  <Pine.GSO.4.21.0108071510390.18565-100000@weyl.math.psu.edu>
> > By author:    Alexander Viro <viro@math.psu.edu>
> > In newsgroup: linux.dev.kernel
> > > 
> > > It is not reliable. E.g. on NFS inumbers are not unique - 32 bits is
> > > not enough.
> > 
> > Unfortunately there is a whole bunch of other things too that rely on
> > it, and *HAVE* to rely on it -- (st_dev, st_ino) are defined to
> > specify the identity of a file, and if the current types aren't large
> > enough we *HAVE* to go to new types.  THERE IS NO OTHER WAY TO TEST
> > FOR FILE IDENTITY IN UNIX, and being able to perform such a test is
> > vital for many things, including security and hard link detection
> 
> Indeed, but it still doesn't help libc5 getcwd(3), which uses 32 bit
> values.

FYI: the problem that spawned this sub-thread is fixed. The
devfs-patch-v185 that I released last night fixes this. So the libc5
getcwd(3) is fine with 32 bit inums on devfs.

Filesystems with larger inums are left as an exercise for the reader
:-)

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] one of $BIGNUM devfs races

[Richard Gooch]

Alan Cox writes:
> > > Very interesting. pwd should be using getcwd(2), which doesn't
> > > give a damn for inode numbers. If you have seriously old pwd binary
> > > that tries to track the thing down to root by hands - yes, it doesn't
> > > work.
> > 
> > Hm. strace suggests my pwd is walking up the path. But WTF would it
> > break? 2.4.7 was fine. What did I break?
> 
> Sounds like you are using libc5. The old style pwd should be
> reliable but its much slower and can't see across protected
> directory paths

Yes, I use libc5. And I don't care about old pwd being slower. And I
certainly don't want to break it, even if I wasn't using it.
By "protected directory paths", you mean a directory with read access?

Well, rx access is available for the whole path. And the inums looked
fine. So the breakage is odd.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] one of $BIGNUM devfs races

[Alexander Viro]

On Tue, 7 Aug 2001, Richard Gooch wrote:

> Yes, I use libc5. And I don't care about old pwd being slower. And I

So fix getcwd(3) in libc5. BFD... Or use your ->dentry in devfs_readdir() -
then you can get the consistency you want for existing inodes and that
will allow b0rken getcwd() to work.

It _is_ b0rken - it relies on unique 32-bit number for inodes. That's
not guaranteed on NFS and there's nothing we could do about that.

Re: cpu not detected(x86)

[Alan Cox]

> Longer-term, we need to change the kernel to not use the TSC for udelay, but
> to use the PM Timer, if ACPI is going to be monkeying with CPU power states.

That can be done, and may be a help. 

The TSC timer isnt a very good source on many non intel chips that stop it
to get the best power figures. It also helps with SMP because on an SMP box
the tsc values may not calibrate.

Alan

Re: [kbuild-devel] Announce: Kernel Build for 2.5, Release 1 is

[Alan Cox]

> If generating some support files requires some non common tools,
> it is the right thing to ship the two files (source and generated).

Its often easiest. Justin does this with the Adaptec driver now and it makes
life both simple for those who want to build kernels and handy for those
who want to hack the stuff.

> BTW we cannot ship the generated file without the source files,
> because of GPL.

If its part of the kernel tools you want to make it available, that doesn't 
mean it has to be shipped with the kernel. 

Alan

Re: [PATCH] parport_pc.c PnP BIOS sanity check

[Alan Cox]

> The following would seem to be required to protect against
> the case in which PnP BIOS reports an IRQ of 0 for a 
> parport with disabled IRQ.      // Thomas  jdthood_AT_yahoo.co.uk

IRQ 0 is a legal valid IRQ. I suspect the problem is that pnpbios shouldnt
be reporting an IRQ or we should be using some kind of NO_IRQ cookie

Re: [PATCH] parport_pc.c PnP BIOS sanity check

[Richard B. Johnson]

On Wed, 8 Aug 2001, Alan Cox wrote:

> > The following would seem to be required to protect against
> > the case in which PnP BIOS reports an IRQ of 0 for a 
> > parport with disabled IRQ.      // Thomas  jdthood_AT_yahoo.co.uk
> 
> IRQ 0 is a legal valid IRQ. I suspect the problem is that pnpbios shouldnt
> be reporting an IRQ or we should be using some kind of NO_IRQ cookie

IRQ0 will never by reported by a PCI bus device because it means that
no IRQ is used (they figured that IRQ0 would always be used for something
else). Maybe PnP BIOS also presumes this? If so, the use of IRQ0 to
mean "no IRQ" is valid, although misleading.

Cheers,
Dick Johnson

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

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: [PATCH] parport_pc.c PnP BIOS sanity check

[H. Peter Anvin]

Followup to:  <E15UV8M-0005SE-00@the-village.bc.nu>
By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
>
> > The following would seem to be required to protect against
> > the case in which PnP BIOS reports an IRQ of 0 for a 
> > parport with disabled IRQ.      // Thomas  jdthood_AT_yahoo.co.uk
> 
> IRQ 0 is a legal valid IRQ. I suspect the problem is that pnpbios shouldnt
> be reporting an IRQ or we should be using some kind of NO_IRQ cookie
>

IRQ 0 is hardwired to the system timer in PC systems, though, so it
could simply be assumed that IRQ 0 will never be used for any other
purposes.

Reminds me back in the days when you had to worry about DRQs as well;
DRQ 0 was hardwired in the original PC but then became available in
the AT; there was a whole bunch of things that assumed DRQ 0 wasn't
usable, even though it was perfectly fine.  Not to mention the
motherboard I had which would lock up solid if anything ever used
DRQ 5.

Good riddance, all this crap...

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: [PATCH] parport_pc.c PnP BIOS sanity check

[Russell King]

On Wed, Aug 08, 2001 at 02:58:12PM -0700, H. Peter Anvin wrote:
> IRQ 0 is hardwired to the system timer in PC systems, though, so it
                                         ^^^^^^^^^^^^^

Linux doesn't run on only PC systems though, and other systems use
IRQ0 as the (superio-based) parallel port IRQ.

> Good riddance, all this crap...

Indeed - please check the ARM port for our solution to this.  We've
had the NO_IRQ construct for literally years in include/asm-arm/irq.h:

#define NO_IRQ  ((unsigned int)(-1))

Naturally, a similar NO_DMA is defined in dma.h.  The sooner we can get
rid of the "IRQ0 cannot be used" crap from the kernel the better.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] parport_pc.c PnP BIOS sanity check

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Followup to:  <E15UV8M-0005SE-00@the-village.bc.nu>
> By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
> In newsgroup: linux.dev.kernel
> >
> > > The following would seem to be required to protect against
> > > the case in which PnP BIOS reports an IRQ of 0 for a 
> > > parport with disabled IRQ.      // Thomas  jdthood_AT_yahoo.co.uk
> > 
> > IRQ 0 is a legal valid IRQ. I suspect the problem is that pnpbios shouldnt
> > be reporting an IRQ or we should be using some kind of NO_IRQ cookie
> >
> 
> IRQ 0 is hardwired to the system timer in PC systems, though, so it
> could simply be assumed that IRQ 0 will never be used for any other
> purposes.
> 
> Reminds me back in the days when you had to worry about DRQs as well;
> DRQ 0 was hardwired in the original PC but then became available in
> the AT; there was a whole bunch of things that assumed DRQ 0 wasn't
> usable, even though it was perfectly fine.  Not to mention the
> motherboard I had which would lock up solid if anything ever used
> DRQ 5.
> 
> Good riddance, all this crap...

If we are going to list all of the silly assumptions, we still have
the assumption that 640KB-1MB on x86 cannot be used as ram.  It is
less painful but still annoying when you put perfectly valid ram
there.  :) 

Eric

Re: [Dri-devel] Re: DRM Linux kernel merge (update) needed, soon.

[Alan Cox]

> I sent a patch to Linus and Alan this morning.

Tweaked to allow either 4.0 or 4.1 DRM to be built (most folks need 4.0
still) and merged

Re: 386 boot problems with 2.4.7 and 2.4.7-ac9

[Alan Cox]

> This is the panic from 2.4.7-ac9 compiled with gcc-2.96-85 (Red Hat).
> 
> ksymoops 2.4.0 on i686 2.4.7.  Options used

Thanks. For some reason it crashed probing the simple boot flag ACPI
structure. I'll try and work out how and why then send you a diff

Re: Swapping for diskless nodes

[Alan Cox]

> what is the best/recommended way to do remote swapping via the network
> for diskless workstations or compute nodes in clusters in Linux 2.4?=20
> Last time i checked was linux 2.2, and there were some races related=20
> to network swapping back then. Has this been fixed for 2.4?

The best answer probably is "don't". Networks are high latency things for
paging and paging is latency sensitive. If performance is not an issue then
the nbd driver ought to work. You may need to check it uses the right
GFP_ levels to avoid deadlocks and you might need to up the amount of atomic
pool memory. Hopefully other hacks arent needed

[The general case of network swap is basically insoluble but its possible to
 make it perfectly usable as Sun proved]

Alan

Re: Swapping for diskless nodes

[Ingo Oeser]

On Thu, Aug 09, 2001 at 10:08:37AM +0100, Alan Cox wrote:
> > what is the best/recommended way to do remote swapping via the network
> > for diskless workstations or compute nodes in clusters in Linux 2.4?=20
> > Last time i checked was linux 2.2, and there were some races related=20
> > to network swapping back then. Has this been fixed for 2.4?
> 
> The best answer probably is "don't". Networks are high latency things for
> paging and paging is latency sensitive. If performance is not an issue then
> the nbd driver ought to work. You may need to check it uses the right
> GFP_ levels to avoid deadlocks and you might need to up the amount of atomic
> pool memory. Hopefully other hacks arent needed

While we are on it: I have an old machine with 64MB of RAM and a
new, fast machine with 1GB of RAM. 

Sometimes I need more RAM on the old one and asked myself,
whether I could first swap over network to the other one, into
its tmpfs, before digging into real swap on a hard disk.

I have only three machines attached to this small internal
100Mbit LAN.

Both machines use Kernel 2.4.x.

Are there any races I have to consider?

Thanks & Regards

Ingo Oeser
-- 
In der Wunschphantasie vieler Mann-Typen [ist die Frau] unsigned und
operatorvertraeglich. --- Dietz Proepper in dasr

Re: Swapping for diskless nodes

[Dirk W. Steinberg]

I'd like to second that example where you have weak diskless nodes and
a big server with a lot of memory. The important point here is that the
remote paging does not need to really write to the remote disk, especially
not synchronously. The page could eventually be migrated to the remote
disk asynchronously, or maybe not at all if there is no memory pressure
at the remote system.

In such a scenario I would disagree with Alan that network paging is 
high latency as compared to disk access. I have a fully switched 100 Mpbs
full-duplex ethernet network, and sending a page across the net into
the memory of a fast server could have much less latency that writing 
that page out to a local old, slow IDE disk. Clusters could even have
special high-bandwidth, low latency networks that could be used for
remote paging.

In a perfect world, all nodes in a cluster would be able to dynamically 
share a pool of "cluster swap" space, so any locally available swap that
is not used could be utilized by other nodes in the cluster.

/ Dirk

Ingo Oeser wrote:
> On Thu, Aug 09, 2001 at 10:08:37AM +0100, Alan Cox wrote:
> > > what is the best/recommended way to do remote swapping via the network
> > > for diskless workstations or compute nodes in clusters in Linux 2.4?=20
> > > Last time i checked was linux 2.2, and there were some races related=20
> > > to network swapping back then. Has this been fixed for 2.4?
> >
> > The best answer probably is "don't". Networks are high latency things for
> > paging and paging is latency sensitive. If performance is not an issue then
> > the nbd driver ought to work. You may need to check it uses the right
> > GFP_ levels to avoid deadlocks and you might need to up the amount of atomic
> > pool memory. Hopefully other hacks arent needed
> 
> While we are on it: I have an old machine with 64MB of RAM and a
> new, fast machine with 1GB of RAM.
> 
> Sometimes I need more RAM on the old one and asked myself,
> whether I could first swap over network to the other one, into
> its tmpfs, before digging into real swap on a hard disk.
> 
> I have only three machines attached to this small internal
> 100Mbit LAN.
> 
> Both machines use Kernel 2.4.x.

Re: Swapping for diskless nodes

[Rik van Riel]

On Thu, 9 Aug 2001, Ingo Oeser wrote:

> Are there any races I have to consider?

Well, this IS a big issue against swap over network.

Swap over network is inherently prone to deadlock
situations, due to the following three problems:

1) we swap pages out when we are close to running
   out of free memory
2) to write pages out over the network, we need to
   allocate space to assemble network packets
3) we need to have memory to receive the ACKs on
   the packets we sent out

The only real solution to this would be memory
reservations so we know this memory won't be used
for other purposes.

What we can do right now is be careful about how
many writeouts over the network we do at the same
time, but that will still get us killed in case of
a ping flood ;)

regards,

Rik
--
IA64: a worthy successor to the i860.

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

Re: Swapping for diskless nodes

[Dirk W. Steinberg]

Alan,

what you say sound a lot like a hacker solution ("check that it uses the
right GFP_ levels"). I think it's about time that this deficit of linux
as compared to SunOS or *BSD should be removed. Network paging should be
supported as a standard feature of a stock kernel compile.

/ Dirk

Alan Cox wrote:
> > what is the best/recommended way to do remote swapping via the network
> > for diskless workstations or compute nodes in clusters in Linux 2.4?=20
> > Last time i checked was linux 2.2, and there were some races related=20
> > to network swapping back then. Has this been fixed for 2.4?
> 
> The best answer probably is "don't". Networks are high latency things for
> paging and paging is latency sensitive. If performance is not an issue then
> the nbd driver ought to work. You may need to check it uses the right
> GFP_ levels to avoid deadlocks and you might need to up the amount of atomic
> pool memory. Hopefully other hacks arent needed
> 
> [The general case of network swap is basically insoluble but its possible to
>  make it perfectly usable as Sun proved]

Re: Swapping for diskless nodes

[Andreas Haumer]

Hi!

"Dirk W. Steinberg" wrote:
> 
> Alan,
> 
> what you say sound a lot like a hacker solution ("check that it uses the
> right GFP_ levels"). I think it's about time that this deficit of linux
> as compared to SunOS or *BSD should be removed. Network paging should be
> supported as a standard feature of a stock kernel compile.
> 
We have swapping over NBD running for some time now on
our "xS+S Diskless Client" system, and it works really
fine! No problem running StarOffice, Netscape, The Gimp
and KDE on a 128MB Diskless Client and 250MB swap over a 
100MBit switched ethernet!

Check <http://www.xss.co.at/linux/NBD/Applications.html>
to find our solution for that.

Kernel patches are a little bit outdated, but we have NBD swap
for 2.2.19 running internally since this week, and we will
update our web-page soon.

Let us hear if it works for you.

Regards,

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

Re: Swapping for diskless nodes

[Pavel Machek]

Hi!

> > what you say sound a lot like a hacker solution ("check that it uses the
> > right GFP_ levels"). I think it's about time that this deficit of linux
> > as compared to SunOS or *BSD should be removed. Network paging should be
> > supported as a standard feature of a stock kernel compile.
> > 
> We have swapping over NBD running for some time now on
> our "xS+S Diskless Client" system, and it works really
> fine! No problem running StarOffice, Netscape, The Gimp
> and KDE on a 128MB Diskless Client and 250MB swap over a 
> 100MBit switched ethernet!

Try going 8MB of ram, ping -f client and try to compile the kernel.

Netscape + SO + gimp on 128MB is rather light load.

> Check <http://www.xss.co.at/linux/NBD/Applications.html>
> to find our solution for that.
> 
> Kernel patches are a little bit outdated, but we have NBD swap
> for 2.2.19 running internally since this week, and we will
> update our web-page soon.

Be sure to mail me a copy.
								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.

Re: Swapping for diskless nodes

[Pavel Machek]

Hi!

> > what is the best/recommended way to do remote swapping via the network
> > for diskless workstations or compute nodes in clusters in Linux 2.4?=20
> > Last time i checked was linux 2.2, and there were some races related=20
> > to network swapping back then. Has this been fixed for 2.4?
> 
> The best answer probably is "don't". Networks are high latency things for
> paging and paging is latency sensitive. If performance is not an issue then
> the nbd driver ought to work. You may need to check it uses the
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Alan, are you saying it should work reliably?

> right
> GFP_ levels to avoid deadlocks and you might need to up the amount of atomic
> pool memory. Hopefully other hacks arent needed

There still may be some deadlocks. Swapping over nbd seemed to work
for me... until I used mem=8M and did two ping -f's to the victim.

Issue is that you not only need to check nbd, you need to check whole
network layer, too.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Swapping for diskless nodes

[Rik van Riel]

On Thu, 9 Aug 2001, Alan Cox wrote:

> > what is the best/recommended way to do remote swapping via the network
> > for diskless workstations or compute nodes in clusters in Linux 2.4?=20
> > Last time i checked was linux 2.2, and there were some races related=20
> > to network swapping back then. Has this been fixed for 2.4?
>
> The best answer probably is "don't". Networks are high latency
> things for paging and paging is latency sensitive.

Actually, swap over network can be faster than local swap
at times. ;)

Don't forget that disks are really high latency devices
and with local swap you are SURE that the data isn't
in memory while with remote swap you have a chance that
the server is caching your data ...

regards,

Rik
--
IA64: a worthy successor to the i860.

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

Re: Swapping for diskless nodes

[Alan Cox]

> 
> Alan,
> 
> what you say sound a lot like a hacker solution ("check that it uses the
> right GFP_ levels"). I think it's about time that this deficit of linux

Nope. I'm simply advising people to check that nbd is correctly written.

> as compared to SunOS or *BSD should be removed. Network paging should be
> supported as a standard feature of a stock kernel compile.

There I'd agree entirely.

Re: Swapping for diskless nodes

[Pavel Machek]

Hi!

> > what you say sound a lot like a hacker solution ("check that it uses the
> > right GFP_ levels"). I think it's about time that this deficit of linux
> 
> Nope. I'm simply advising people to check that nbd is correctly written.

This bug is unlikely to be in nbd, but you need to check whole network
stack. Even arp handling is cruical for working nbd swap!
								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.

Re: Swapping for diskless nodes

[Alan Cox]

> the memory of a fast server could have much less latency that writing 
> that page out to a local old, slow IDE disk. Clusters could even have
> special high-bandwidth, low latency networks that could be used for
> remote paging.
> 
> In a perfect world, all nodes in a cluster would be able to dynamically 
> share a pool of "cluster swap" space, so any locally available swap that
> is not used could be utilized by other nodes in the cluster.

That I think is a 2.5 problem. One thing that has been talked about several
times now is removing all the swap special case crap from the mm and making
swap a file system. That removes special cases and means anyone can write
or use custom, or multiple swap filesystems, in theory including things like
swap over a shared GFS pool

But its not for 2.4, no way

Alan

Re: Swapping for diskless nodes

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > the memory of a fast server could have much less latency that writing 
> > that page out to a local old, slow IDE disk. Clusters could even have
> > special high-bandwidth, low latency networks that could be used for
> > remote paging.
> > 
> > In a perfect world, all nodes in a cluster would be able to dynamically 
> > share a pool of "cluster swap" space, so any locally available swap that
> > is not used could be utilized by other nodes in the cluster.
> 
> That I think is a 2.5 problem. One thing that has been talked about several
> times now is removing all the swap special case crap from the mm and making
> swap a file system. That removes special cases and means anyone can write
> or use custom, or multiple swap filesystems, in theory including things like
> swap over a shared GFS pool
> 
> But its not for 2.4, no way

I don't know about that.  We already can swap over just about everything 
because we can swap over the loopback device.  So moving making the swapping
code do the right thing is not that big of an allowance, nor that
much of extra code so if 2.5 actually starts up I can see us doing that.

Eric

Re: Swapping for diskless nodes

[Rik van Riel]

On 9 Aug 2001, Eric W. Biederman wrote:

> I don't know about that.  We already can swap over just about
> everything because we can swap over the loopback device.

Last I looked the loopback device could deadlock your
system without you needing to swap over it ;)

Rik
--
IA64: a worthy successor to the i860.

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

Re: Swapping for diskless nodes

[Eric W. Biederman]

Rik van Riel <riel@conectiva.com.br> writes:

> On 9 Aug 2001, Eric W. Biederman wrote:
> 
> > I don't know about that.  We already can swap over just about
> > everything because we can swap over the loopback device.
> 
> Last I looked the loopback device could deadlock your
> system without you needing to swap over it ;)

It wouldn't suprise me.  But the fact remains that in 2.4 we allow it.
And if we allw it there is little excuse for doing it wrong.

Actually except for network cases it looks easier to prevent deadlocks
on the swapping path than with the loop back devices.  We can call
aops->prepare_write_out when we place the page in the swap cache
to make certain we aren't over a hole in a file, and there is room in the
filesystem to store the data.

Eric

Re: esssound.o once more

[Alan Cox]

> Here is messages, that was occured while 2.4.7-ac9 was compiling:
> drivers/sound/sounddrivers.o: In function `solo1_update_ptr':
> drivers/sound/sounddrivers.o(.text+0xd6e): undefined reference to `clear_advance'
> drivers/sound/sounddrivers.o: In function `solo1_write':

Don't compile with gcc 3.0 and it should be fine. Alternatively swap the
extern inline for static inline

Re: question on best "Linux" Internals book

[Alan Cox]

> obvious book is Bovet & Cesati 'Understanding the Linux Kernel' O'Reill=
> y
> 2001 - (it claims it even got by Alan Cox for checking... :-))

It did 8) If you want to understand the kernel its a good book. If your boss
just ordered you to write a Linux device driver then device drivers is the
book you want.

UtLK has a slightly textbookish air about it, but providing that doesn't 
bother you its a very good book

Re: Q: Kernel patching

[Alan Cox]

> > which already exists!  Skipping patch.
> 
> OK, I got it to work. My mistake was trying to use patch-kernel instead
> of just patch.

If you want the inbetween patches for patch-kernel or for going from ac10-11
etc look on www.bzimage.org.

Re: [PATCH] double DRM - fixes

[Alan Cox]

> BTW: Alan, do you think it would be worth to be able to compile both versions
>      together (in the modular case) ?

it seems tricky to get right. Vendors are going to know which X they shipped
and end users build with the right DRM...

Re: [PATCH] LVM snapshot support for reiserfs and others

[Alan Cox]

> ext3 will probably lock up on unmount with 2.4.8-pre8.  The fix is
> to replace fsync_dev with fsync_no_super in fs/ext3/super.c and
> fs/jbd/recovery.c.  I'll be generating a new patchset this weekend.

Actually if you dont fix recovery.c it will hang the machine when you mount
an fs that needs recovering. With the old patches at least umount of ext3
seems fine as is.

Alan

Re: [PATCH] Adaptec I2O RAID driver (kernel 2.4.7)

[Alan Cox]

Ok comments below. 

Summary suggestion:

Can you fix up the
	-	use of u32 for timeouts
	-	partition stuff for i386 (which really can just go)
	-	pci_resource_len usage
	-	multiply overflow
	-	EFAULT
	-	kmalloc check oddments

Don't bother with the static, header file oddments or the i2o core bugs
you inherited. Just let me know which you use and I'll figure out how to
make them shared.

At that point I think its fine to go in. 

Linus btw it might seem odd to add a driver for a specific i2o adapter but
the DPT's speak what is to say the least a very odd dialect of i2o, so it
does make sense.

> +#include <linux/autoconf.h>
> +#if defined(CONFIG_MODVERSIONS) && !defined(MODVERSIONS)
> +#	define MODVERSIONS
> +#endif
> +
> +#if defined MODVERSIONS && defined MODULE
> +#	include <linux/modversions.h>
> +#endif
> +

These will be automatic so should go - ok I can do that

> +MODULE_AUTHOR("Deanna Bonds, with _lots_ of help from Mark Salyzyn");
> +MODULE_DESCRIPTION("Adaptec I2O RAID Driver");
> +char kernel_version[] = UTS_RELEASE;

should be static char [otherwise it clashes built in]

> +static struct file_operations adpt_fops = {
> +	ioctl: adpt_ioctl,
> +	open: adpt_open,
> +	release: adpt_close
> +};
> +
> +
> +u8 adpt_read_blink_led(adpt_hba* host)

static - again not a big item, that can be done later anyway

> +#endif
> +	sht->use_new_eh_code = 1;

Excellent.  old_eh will go in 2.5 so its great you are using the new_eh

> +	printk("dpti: If you have a lot of devices this could take a few
> minutes.\n");

	       ^KERN_INFO


> +	for (pHba = hba_chain; pHba; pHba = pHba->next) {
> +		printk("%s: Reading the hardware resource table.\n",
                       KERN_DEBUG

> +int adpt_queue(Scsi_Cmnd * cmd, void (*done) (Scsi_Cmnd *))
> +{
> +	adpt_hba* pHba = NULL;
> +	struct adpt_device* pDev = NULL;	/* dpt per device
> information */
> +	u32 timeout = jiffies + (TMOUT_SCSI*HZ);
        ^unsigned long

> +	// TODO(defer) dmb - use marks algorythm
> +	if( disk->has_part_table == 1){
> +
> +
> +	}

Linux will trust partition tables for you.

> +		 * Read data from buffer (writing to us) - NOT SUPPORTED
> +		 */
> +		return -ENOSYS;

		-EINVAL

	[-ENOSYS would imply the write() syscall didnt exist]

> +	pci_read_config_dword(pDev,
> PCI_BASE_ADDRESS_0,(u32*)&base_addr0_phys);

No no no.. Dont do this, bad crap will happen on some setups. The length
is pci_resource_len(pDev, 0) 

> +	pci_read_config_word (pDev, PCI_SUBSYSTEM_ID, &subdevice);
> +


> +		//Use BAR1 in this config
> +		pci_read_config_dword(pDev,PCI_BASE_ADDRESS_1,
> (u32*)&base_addr1_phys);
> +		pci_write_config_dword(pDev,PCI_BASE_ADDRESS_1, 0xffffffff);
> +		pci_read_config_dword(pDev,PCI_BASE_ADDRESS_1,
> &hba_map1_area_size);

Again dont do this - use pci_resource_len

> +	base_addr_virt = (ulong)ioremap(base_addr0_phys,hba_map0_area_size);
> +	if(base_addr_virt == 0) {
> +		PERROR("dpti: adpt_config_hba: io remap failed\n");
> +		return -EINVAL;
> +	}
> +
> +        if(raptorFlag == TRUE) {
> +		msg_addr_virt = (ulong)ioremap(base_addr1_phys,
> hba_map1_area_size );
> +		if(msg_addr_virt == 0) {
> +			PERROR("dpti: adpt_config_hba: io remap failed on
> BAR1\n");


You need to unmap the base_addr_virt here or it leaks on error

> +	// Allocate and zero the data structure
> +	if( (pHba = kmalloc(sizeof(adpt_hba), GFP_KERNEL)) == NULL) {
> +		iounmap((void*)base_addr_virt);
	
		msg_addr_virt ??

> +/* Structures and definitions for synchronous message posting.
> + * See adpt_i2o_post_wait() for description
> + * */

Ah you borrowed the i2o post wait code before it was properly debugged. So
that..

> +	spin_unlock_irqrestore(&adpt_post_wait_lock, flags);
> +	kfree(wait_data);

Now in the timeout case this will cause the failed reply data to scribble
somewhere random, if the reply does turn up after the timeout. You actually
can't clean the buffer up until you know the event completed or you shut
down the controller.

> +	u32 timeout = jiffies + 30*HZ;
unsigned long for timers..
> +	do {
> +		rmb();
> +		m = readl(pHba->post_port);
> +		if (m != EMPTY_QUEUE) {

> + */		    	
> +int adpt_i2o_query_scalar(adpt_hba* pHba, int tid, 
> +			int group, int field, void *buf, int buflen)
> +{
> +	u16 opblk[] = { 1, 0, I2O_PARAMS_FIELD_GET, group, 1, field };

If you borrowed the i2o_query_scalar code from the older i2o code thats
also buggy (sorry Im human too 8)).

Can you give me a list of the i2o_ core routines that your driver uses
unchanged and I will do the magic so that we can share them (say an
i2o_lib module)

> +	// get user msg size in u32s 
> +	get_user(size, &user_msg[0]);

	if(get_user(...))
		return -EFAULT;

(so it reports errors nicely

> +	user_reply = &user_msg[size];
> +	size *= 4; // Convert to bytes
> +	if(size > MAX_MESSAGE_SIZE){
> +		return -EFAULT;

Check the size is ok for 1/4, then multiply - it might overflow, same on 
the reply

> +	get_user(reply_size, &user_reply[0]);
		-EFAULT...

> +#if defined __i386__
> +
> +#include <linux/mc146818rtc.h>
> +
> +	/* Get drive type for 1st drive*/
> +	i = CMOS_READ(0x12) >> 4;
> +	j = i >> 4;
> +	if (i == 0x0f) {
> +		j = CMOS_READ(0x19);
> +	}
> +	si->drive0CMOS = j;

Don't do this. You've no idea if there is even CMOS present, if the format
is what you expect of if it is talking to you

> +	/* Get number of drives sys bios found */
> +	si->numDrives = *((char *) phys_to_virt(0x475));

BIOS - again an assumption. Basically flush this code. Geom isnt a big
deal to the kernel, not all drivers even bother to set it, scsi is logical
block based so really doesnt care a bit.

> +	u32 timeout = jiffies + TMOUT_INITOUTBOUND*HZ;

unsigned long - that seems to be everywhere. Its kind of bad to get it wrong
as it means alphas mysteriously dont work after about 50 days 8)

> +/*
> + * dpti2oscsi2.c contains a table of scsi commands that is used to
> determine
> + * the data direction of the command.  It is used in dpt_scsi_to_i2o to
> speed
> + * up the building of the scsi message.

You don't need that in 2.4. The kernel tells you

> +				if( pDev == NULL){
> +					pDev =  kmalloc(sizeof(struct
> adpt_device),GFP_KERNEL);

Missing check for if this one fails..

> +
> +  /* Define the mutually exclusive semaphore type */
> +#define		SEMAPHORE_T	unsigned int *
> +  /* Define a handle to a DLL */
> +#define		DLL_HANDLE_T	unsigned int *
> +
> +#endif
> --- /dev/null	Sat Apr 14 07:06:21 2001
> +++ linux/drivers/scsi/dpti_i2o-dev.h	Fri Aug 10 14:49:34 2001
> @@ -0,0 +1,395 @@
> +/*
> + * I2O user space accessible structures/APIs

Some of these seem to be duplicates of existing includes so could be shared

Re: free_task_struct() called too early?

[Alan Cox]

> When a process terminates, it appears that the task structure is freed too
> early.  There are memory references to the kernel task area (task_struct and
> stack space) after free_task_struct(p) is called.
> 
> If I modify the following line in include/asm-i386/processor.h
> 
> #define free_task_struct(p)   free_pages((unsigned long) (p), 1) to
> #define free_task_struct(p)   memset((void*) (p), 0xf, PAGE_SIZE*2);
> free_pages((unsigned long) (p), 1)
> then kernel will boot to init and lockup on when first task terminates.
> 
> Has anyone looked into or aware of this issue?

2.4.8pre fixed a case with semaphores on the stack. It might not be the only
one. Your #define is wrong though, if a single free_task_struct path is an
if you will not do what you expect

	do { memset(), free_pages } while(0);

would be safer. 

I'd like to know if 2.4.8pre8 does it except on module unload (where it is
still buggy)

Alan

Re: free_task_struct() called too early?

[Linus Torvalds]

On Fri, 10 Aug 2001, Alan Cox wrote:
> >
> > If I modify the following line in include/asm-i386/processor.h
> >
> > #define free_task_struct(p)   free_pages((unsigned long) (p), 1) to
> > #define free_task_struct(p)   memset((void*) (p), 0xf, PAGE_SIZE*2);
> > free_pages((unsigned long) (p), 1)
> > then kernel will boot to init and lockup on when first task terminates.
> >
> > Has anyone looked into or aware of this issue?
>
> 2.4.8pre fixed a case with semaphores on the stack. It might not be the only
> one. Your #define is wrong though, if a single free_task_struct path is an
> if you will not do what you expect
>
> 	do { memset(), free_pages } while(0);
>
> would be safer.

No no no.

You can NOT do a "memset()" before you free the task-struct: it's can
still be actively used, and will be marked such by having an elevated page
count (ie the "free()" may not be doing anything but atomically decrement
the page count).

This is, in fact, a very very common thing - I bet that you will reboot
the first time you touch a /proc/<pid>/xx file or do a "ptrace()", because
that code will do the free_task_struct too after having incremented the
usage count while they held on to it.

If you really really want to, you can do the memset() at the top of
"free_pages_ok()" - it will slow down the system considerably (because
_every_ page will be memset after being free'd), but hey, it's going to be
an even better stress-tester.

Oh, if you do it there, do something like thisL

	memset(page_address(page), 0xf0, PAGE_SIZE << order);

and realize that the above will not work on HIGHMEM machines (and making
it work on highmem machines is simply not worth it).

		Linus

Re: VM nuisance

[Alan Cox]

> - How hard/how much time.. to implement resource baselines (or similar 
> concept)

Ben La Haise has been working on that part of things. Its non trivial. I've
been discussing changes with Rik for VM behaviour shifts when thrashing but
not OOM. We have some ideas but this is research

Re: [PATCH] Adaptec I2O RAID driver (kernel 2.4.7)

[Alan Cox]

> When I coded that, I took a snapshot of the i2o routines at 2.2.18 (I
> think).  I still have requirement to support customers running 2.2.12 with

Ok those will break in two cases - failed table reads and timeouts on post
waits that then complete later. Its probably ok since you know those wont
fail on your card

> support the older kernels.  I could not find a nice way of doing something
> similar in those kernels (2.2.12 again).  

2.2.12 has known and fixed security holes so nobody should be using it 8)
 
I'll read over this version tomorrow morning

Re: struct page to 36 (or 64) bit bus address?

[Alan Cox]

> There have been a few threads on this issue.  One of the core reasons
> the situation is unlikely to change in 2.4.x is that the scsi layer in
> it's current form makes the logic required for recovering from a DMA
> mapping failure aweful at best.

Actually its pretty trivial to resolve that I think. We already follow
precisely the right procedure for some other scsi events. So 

	scsi_retry_command(SCpnt);

would map to setting the error and returning.

Re: Bug report : Build problem with kernel 2.4.8

[Alan Cox]

> Problem: Can't compile kernel 2.4.8 with support of sound card CM8338A.

Its a bug in the code

> In file included from cmpci.c:90:
> /usr/local/src/kernel-source-2.4.8/include/linux/module.h:21: linux/mod=
> versions.h: No such file or directory

drivers/sound/cmpci.c included <linux/modversions.h> directly so broke if
you didnt have module versioning enabled. I've already sent Linus a fix
for this one

Re: PnP BIOS

[Alan Cox]

> I recently began a project that will make Linux a PnP OS (at least the 
> 386 arch).  I'm currently working on a PnP BIOS module for the Linux 

There is already one in Linux 2.4.8ac

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> But later there was a patch from maintainer (Rui Sousa). Besides, there were no
> updates from maintainers for over a year, so I think "non maintainer" did a good
> thing - at least maintainers started to send patches finally. Instead of backing out
> I suggest for maintainers to send more patches...

I've got an even better idea. Its called making major problematic device
changes and debugging them in _UNSTABLE_ kernel trees - like waiting until
2.5 starts. Otherwise 2.4 will never be stable.

Its one thing to take something like the early USB in a stable kernel and
update it because it certainly won't make it worse, and another to update
an emu10k1 driver that worked with one that doesn't work, needs different
user tools and locks all SMP boxes.

Alan

Re: Linux 2.4.8-ac2

[Alan Cox]

> i just want to ask you (sorry for this consumer behavior)
> if you intend to integrate the xfs filesystem in your ac-series

I've discussed it with Martin Petersen a bit. Its not clear it makes
sense, since they kind of do chunks of their own vm (partly because they
had to) and other bits like acls that want to be out for the first one.
Right no I don't know what will occur. I think in part it depends when
Linus starts 2.5

> also .. do you know if it is planed to integrate the xfs fs
> into the main branch of the kernel ?

You'd have to ask Linus

Re: Linux 2.4.8-ac2

[Sven Goethel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 13 August 2001 01:37, Alan Cox wrote:
> > i just want to ask you (sorry for this consumer behavior)
> > if you intend to integrate the xfs filesystem in your ac-series
>
> I've discussed it with Martin Petersen a bit. Its not clear it makes
> sense, since they kind of do chunks of their own vm (partly because they
> had to) and other bits like acls that want to be out for the first one.
> Right no I don't know what will occur. I think in part it depends when
> Linus starts 2.5
>
> > also .. do you know if it is planed to integrate the xfs fs
> > into the main branch of the kernel ?
>
> You'd have to ask Linus
>

thanxs alan

so i ask linus here ..

hello ;-)

dear linus

how about integrating the xfs fs into the main kernel branch ?

i guess 'ya all know how nice this would be ..

sorry for acting just like a wanting customer

thanxs for all the great work - cheers, sven
- -- 
mailto:sgoethel@jausoft.com
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440 ; fax : +49-521-2399442
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7d0glHdOA30NoFAARAsJGAJ992d5j7Q7EOmxmfjGWaVLUfknlLQCgtLOa
wihwthQ6GewYn+lvAaARwt8=
=32Be
-----END PGP SIGNATURE-----

Re: 2.4.9-pre1 unresolved symbols in fat.o/smbfs.o

[Alan Cox]

> depmod: *** Unresolved symbols in /lib/modules/2.4.9-pre1/kernel/fs/fat/fat.o
> depmod: 	generic_file_llseek
> depmod: *** Unresolved symbols in /lib/modules/2.4.9-pre1/kernel/fs/smbfs/smbfs.o
> depmod: 	generic_file_llseek
>  

Oops my fault. My kernel/ksyms goes

EXPORT_SYMBOL(vfs_unlink);
EXPORT_SYMBOL(vfs_rename);
EXPORT_SYMBOL(vfs_statfs);
EXPORT_SYMBOL(generic_file_llseek);
EXPORT_SYMBOL(generic_read_dir);
EXPORT_SYMBOL(__pollwait);
EXPORT_SYMBOL(poll_freewait);


If you edit yours and drop that line in then rebuild from clean all should
be well

Re: 2.4.9-pre1 unresolved symbols in fat.o/smbfs.o

[Linus Torvalds]

On Mon, 13 Aug 2001, Alan Cox wrote:
>
> Oops my fault. My kernel/ksyms goes
>
> EXPORT_SYMBOL(vfs_unlink);
> EXPORT_SYMBOL(vfs_rename);
> EXPORT_SYMBOL(vfs_statfs);
> EXPORT_SYMBOL(generic_file_llseek);
> EXPORT_SYMBOL(generic_read_dir);
> EXPORT_SYMBOL(__pollwait);
> EXPORT_SYMBOL(poll_freewait);
>
> If you edit yours and drop that line in then rebuild from clean all should
> be well

Hmm.. You should probably also add "no_llseek" there..

		Linus

Re: 2.4.9-pre1 unresolved symbols in fat.o/smbfs.o

[Alessandro Suardi]

Linus Torvalds wrote:
> 
> On Mon, 13 Aug 2001, Alan Cox wrote:
> >
> > Oops my fault. My kernel/ksyms goes
> >
> > EXPORT_SYMBOL(vfs_unlink);
> > EXPORT_SYMBOL(vfs_rename);
> > EXPORT_SYMBOL(vfs_statfs);
> > EXPORT_SYMBOL(generic_file_llseek);
> > EXPORT_SYMBOL(generic_read_dir);
> > EXPORT_SYMBOL(__pollwait);
> > EXPORT_SYMBOL(poll_freewait);
> >
> > If you edit yours and drop that line in then rebuild from clean all should
> > be well
> 
> Hmm.. You should probably also add "no_llseek" there..

Don't know about that, but Alan's suggested fix is enough for
 a clean 2.4.9-pre1 build here. Thanks,

--alessandro

 "this is no time to get cute, it's a mad dog's promenade
  so walk tall, or baby don't walk at all"
                (Bruce Springsteen, 'New York City Serenade')

Re: 2.4.9-pre1 unresolved symbols in fat.o/smbfs.o

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>
>On Mon, 13 Aug 2001, Alan Cox wrote:
>>
>> Oops my fault. My kernel/ksyms goes
>>
>> EXPORT_SYMBOL(vfs_unlink);
>> EXPORT_SYMBOL(vfs_rename);
>> EXPORT_SYMBOL(vfs_statfs);
>> EXPORT_SYMBOL(generic_file_llseek);
>> EXPORT_SYMBOL(generic_read_dir);
>> EXPORT_SYMBOL(__pollwait);
>> EXPORT_SYMBOL(poll_freewait);
>>
>> If you edit yours and drop that line in then rebuild from clean all should
>> be well
>
>Hmm.. You should probably also add "no_llseek" there..
>
>		Linus


Seems to need it:

/usr/src/linux }make  modules_install  >/dev/null

depmod: *** Unresolved symbols in /lib/modules/2.4.9-pre1/kernel/drivers/media/video/tvmixer.o
depmod:         no_llseek
depmod: *** Unresolved symbols in /lib/modules/2.4.9-pre1/kernel/drivers/media/video/videodev.o
depmod:         no_llseek
depmod: *** Unresolved symbols in /lib/modules/2.4.9-pre1/kernel/drivers/sound/sound.o
depmod:         no_llseek
depmod: *** Unresolved symbols in /lib/modules/2.4.9-pre1/kernel/fs/fat/fat.o
depmod:         generic_file_llseek




-- 
Windows 2001: "I'm sorry Dave ...  I'm afraid I can't do that."

Re: Lost interrupt with HPT370

[Alan Cox]

> I have just tried an HPT-366 card with IC35L040VER07 drives (latest DeskStar
> 41G ATA-100, although the card is only ATA-66) and could not get them to
> even let me create a filesystem without hard locking the machine. This was
> using 2.4.8-ac1 and 2.4.7-ac11. I wrote this off to motherboard/IDE card
> compatibility (or lack thereof), but could it still be an IDE driver issue?

Some HPT cards have problems with certain drives. I believe its a fixed
problem in newer boards or on those with updatable firmware if you update
the firmware itself

Check your drive is in the bad_ata100_5 and bad_ata66_4 list. If not add
it then rebuild and retry (drivers/ide/hpt366.c) - and let me know

Alan

Re: Lost interrupt with HPT370

[Kevin P. Fleming]

OK, I've downloaded a beta BIOS update, if that doesn't cure it I'll try
adding it to the "bad list" and let y'all know what happens.

----- Original Message -----
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
To: "Kevin P. Fleming" <kevin@labsysgrp.com>
Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>; <linux-kernel@vger.kernel.org>
Sent: Monday, August 13, 2001 4:37 AM
Subject: Re: Lost interrupt with HPT370


> > I have just tried an HPT-366 card with IC35L040VER07 drives (latest
DeskStar
> > 41G ATA-100, although the card is only ATA-66) and could not get them to
> > even let me create a filesystem without hard locking the machine. This
was
> > using 2.4.8-ac1 and 2.4.7-ac11. I wrote this off to motherboard/IDE card
> > compatibility (or lack thereof), but could it still be an IDE driver
issue?
>
> Some HPT cards have problems with certain drives. I believe its a fixed
> problem in newer boards or on those with updatable firmware if you update
> the firmware itself
>
> Check your drive is in the bad_ata100_5 and bad_ata66_4 list. If not add
> it then rebuild and retry (drivers/ide/hpt366.c) - and let me know
>
> Alan
>
>
>

[PATCH] Re: Lost interrupt with HPT370

[Kevin P. Fleming]

This turned out to be the problem. There is a new generation of IBM Deskstar
drives (that are really nice drives :-) that have the same incompatibility
with the HPT-366 chip as the older IBM drives did. Below is a patch to add
the entire series to the "bad drives" lists, although I personally have only
experienced the problem with the 41G model I think it's logical to assume
they'll all have the same problem.

Drives work fine once this patch is in place, although only in ATA-44 (weird
mode).

<snip>

> Check your drive is in the bad_ata100_5 and bad_ata66_4 list. If not add
> it then rebuild and retry (drivers/ide/hpt366.c) - and let me know
>
> Alan

--- linux/drivers/ide/hpt366.old Mon Aug 13 08:45:58 2001
+++ linux/drivers/ide/hpt366.c Mon Aug 13 22:43:43 2001
@@ -60,6 +60,11 @@
  "IBM-DTLA-305040",
  "IBM-DTLA-305030",
  "IBM-DTLA-305020",
+        "IC35L010AVER07-0",
+        "IC35L020AVER07-0",
+        "IC35L030AVER07-0",
+        "IC35L040AVER07-0",
+        "IC35L060AVER07-0",
  "WDC AC310200R",
  NULL
 };
@@ -75,6 +80,11 @@
  "IBM-DTLA-305030",
  "IBM-DTLA-305020",
  "WDC AC310200R",
+        "IC35L010AVER07-0",
+        "IC35L020AVER07-0",
+        "IC35L030AVER07-0",
+        "IC35L040AVER07-0",
+        "IC35L060AVER07-0",
  NULL
 };

Re: Lost interrupt with HPT370

[Wojtek Pilorz]

On Mon, 13 Aug 2001, Alan Cox wrote:

> Date: Mon, 13 Aug 2001 12:37:51 +0100 (BST)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: Kevin P. Fleming <kevin@labsysgrp.com>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
> Subject: Re: Lost interrupt with HPT370
> 
> > I have just tried an HPT-366 card with IC35L040VER07 drives (latest DeskStar
> > 41G ATA-100, although the card is only ATA-66) and could not get them to
> > even let me create a filesystem without hard locking the machine. This was
> > using 2.4.8-ac1 and 2.4.7-ac11. I wrote this off to motherboard/IDE card
> > compatibility (or lack thereof), but could it still be an IDE driver issue?
> 
> Some HPT cards have problems with certain drives. I believe its a fixed
> problem in newer boards or on those with updatable firmware if you update
> the firmware itself
> 
> Check your drive is in the bad_ata100_5 and bad_ata66_4 list. If not add
> it then rebuild and retry (drivers/ide/hpt366.c) - and let me know
> 
> Alan
> -
Alan,

What is the effect of putting or not a drive on bad_ata100_5 and
bad_ata66_4 ?

I am asking as I am using two 30GB IBM DTLA drives connected to HPT370
with kernel 2.2.19+Andre's ide patch, and I have noted that these drives
are present on bad_ata66_4 but not on bad_ata100_5 ?
Should I inderstand that IBM-DTLA-307030 would not be compatible with HPT
366, but *is* OK with HPT 370 running UDMA-100?


I have seen very good performance (15-30 MB/s of transfer with ide.patch,
without ide.patch performance is extremally poor at about 2-3 MB/s) and no
problems, except one serious problem, which made me feel rather bad;
I tried once to measure performance by running two dd command reading
from /dev/hde and /dev/hdg, respectively, concurrently; after dd command
finished reading HDD lamp stayed on until reboot, after which I lost
partition table on one of the disks; before the test I experimented with
hdparm which might have been not a good idea ...
I have not repeat this test later ..

HW: Abit MB with i440BX, FSB 133MHz, HPT 370 on-board,
ECC memory 133 MHz, Pentium-III 800MHz (133 MHz FSB)

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> Does the new driver not work for you? There seems to be a bug at close()
> time, in that the driver uses "tasklet_unlock_wait()" instead of
> "tasklet_kill()" to kill the tasklets, and that wouldn't work reliably.

It hung my SMP box solid
It spews white noise on my box with surround speakers
And worked on the third

So I went back to the old one.

Alan

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[rui.p.m.sousa]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 748 bytes --]


Alan Cox writes:

>> Does the new driver not work for you? There seems to be a bug at close()
>> time, in that the driver uses "tasklet_unlock_wait()" instead of
>> "tasklet_kill()" to kill the tasklets, and that wouldn't work reliably.
> 
> It hung my SMP box solid
> It spews white noise on my box with surround speakers

Digital or analog speakers?

> And worked on the third
> 
> So I went back to the old one.
> 
> Alan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/






--
Crie o seu Email Grátis no Clix em
http://registo.clix.pt/

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> > Also, if you followed the other thread on the Tyan Thunder lockup,
> > you'll have noticed that it locked up under heavy PCI loads. At least on
> > that machine it stopped with the 2.4.8 driver.

No it merely made them less common. I think thats unrelated. Early AMD
chips had bugs, and the SB Live! is famous for triggering PCI bugs because
of the very unusual and tight PCI access patterns it generates - it was
the main trigger for the via audio corruption too (and the AMD chipset
shares common ancestry with the VIA..)

Alan

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> > It hung my SMP box solid
> > It spews white noise on my box with surround speakers
> 
> Digital or analog speakers?

Analogue four output - I didnt know you had digital out working 

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Tobias Ringstrom]

On Mon, 13 Aug 2001, Alan Cox wrote:

> > > It hung my SMP box solid
> > > It spews white noise on my box with surround speakers
> >
> > Digital or analog speakers?
>
> Analogue four output - I didnt know you had digital out working

Same for me, but I got rid of it by muting IGain (whatever that is),
and/or unplugging the microphone.

I did not investigate further.

/Tobias

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Anton Altaparmakov]

At 13:35 13/08/01, Alan Cox wrote:
> > > It hung my SMP box solid
> > > It spews white noise on my box with surround speakers
> >
> > Digital or analog speakers?
>
>Analogue four output - I didnt know you had digital out working

Digital output on my SB Live! has been working since before the original 
emu10k1 driver went into the kernel if my memory hasn't flipped a few bits (-;

And the old driver worked absolutely fine for that matter on my Dual 
Celeron workstation...

Haven't tried the new 2.4.8 emu10k1 addition yet, and considering you are 
reporting it hangs on smp it's probably a waste of time except to confirm 
the hangs...

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: IDE UDMA/ATA Suckage, or something else?

[Alan Cox]

> Currently, I am running a 2.4.7-ac10 SMP debug kernel on my K7 Thunder
> and I was hoping things would be better, and if not then at least I
> could see something in the logs if it did crash/lock. I also compiled
> NVidia driver with debugging enabled. Things are no better as the system
> still locks up frequently while playing Quake 3, and I can't even start
> Unreal Tournament without it locking and requiring a reset (SysRq,
> logging in remotely, etc. does not work). The logs tell me nothing.

Once you've touched the 3D stuff I dont actually care about bug reports that
boot even after 3d unloaded. I'm simply sick of fielding Nvidia's bug
reports.

> What I have found is that if I disable DMA on my IBM ATA100 drive, the
> system is quite stable (though it is slow as snot - running at a
> ridiculous 4.5MB/sec. as compared to 35MB/sec. with UDMA33/66 enabled).

You must disable IDE prefetch on the current versions of the AMD MP 
chipset, you may also need to enable "noapic". 

Re: IDE UDMA/ATA Suckage, or something else?

[Paul G. Allen]

Alan Cox wrote:
> 
> > Currently, I am running a 2.4.7-ac10 SMP debug kernel on my K7 Thunder
> > and I was hoping things would be better, and if not then at least I
> > could see something in the logs if it did crash/lock. I also compiled
> > NVidia driver with debugging enabled. Things are no better as the system
> > still locks up frequently while playing Quake 3, and I can't even start
> > Unreal Tournament without it locking and requiring a reset (SysRq,
> > logging in remotely, etc. does not work). The logs tell me nothing.
> 
> Once you've touched the 3D stuff I dont actually care about bug reports that
> boot even after 3d unloaded. I'm simply sick of fielding Nvidia's bug
> reports.
> 
> > What I have found is that if I disable DMA on my IBM ATA100 drive, the
> > system is quite stable (though it is slow as snot - running at a
> > ridiculous 4.5MB/sec. as compared to 35MB/sec. with UDMA33/66 enabled).
> 
> You must disable IDE prefetch on the current versions of the AMD MP
> chipset, you may also need to enable "noapic".

Unless I can do it with the kernel, I have no choice. The BIOS has no
prefetch setting (which, BTW, I had disabled on all my A7V133 boards).
So what about problems with non MP boards?

PGA

-- 
Paul G. Allen
UNIX Admin II/Network Security
Akamai Technologies, Inc.
www.akamai.com

Re: struct page to 36 (or 64) bit bus address?

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Sun, 12 Aug 2001 12:49:00 +0100 (BST)

   Actually its pretty trivial to resolve that I think. We already follow
   precisely the right procedure for some other scsi events. So 
   
   	scsi_retry_command(SCpnt);
   
   would map to setting the error and returning.

To make sure we're on the same wave length, are you suggesting
this is the kind of thing we'd call in a callback from the PCI
DMA support layer?

That's the core bit, some callback mechanism.  You need this to let
the drivers get "jump started" when IOMMU mappings become available
once more.

Later,
David S. Miller
davem@redhat.com

Re: struct page to 36 (or 64) bit bus address?

[Alan Cox]

>    Actually its pretty trivial to resolve that I think. We already follow
>    precisely the right procedure for some other scsi events. So 
>    
>    	scsi_retry_command(SCpnt);
>    
>    would map to setting the error and returning.
> 
> To make sure we're on the same wave length, are you suggesting
> this is the kind of thing we'd call in a callback from the PCI
> DMA support layer?

Well that would be an ugly layer violation, but how about

	scsi_retry_command_waitq(SCpnt, &dma_waitq)

?

Re: struct page to 36 (or 64) bit bus address?

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Mon, 13 Aug 2001 15:09:31 +0100 (BST)

   > To make sure we're on the same wave length, are you suggesting
   > this is the kind of thing we'd call in a callback from the PCI
   > DMA support layer?
   
   Well that would be an ugly layer violation, but how about
   
   	scsi_retry_command_waitq(SCpnt, &dma_waitq)
   
   ?

I don't mean "PCI DMA support layer knows scsi routines to
call", rather I mean:

... register_new_scsi_host() ...

	add_notifier(&pci_dma_freespace_notifier, &host->dma_notifier_block);

And net drivers would do something similar, registering something
that will do "netdev_wake_queue();" etc.

Also, the DMA support layer must either:

1) require users of it to provide a kernel thread in which
   to execute these things in the correct context

2) have a kernel thread of it's own to do this

3) or somehow else be able to accept this notification
   from any kind of execution context

The notifier is capable of happening anywhere, anytime.
Right?

Later,
David S. Miller
davem@redhat.com

Re: struct page to 36 (or 64) bit bus address?

[Gérard Roudier]

On Mon, 13 Aug 2001, David S. Miller wrote:

>    From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>    Date: Mon, 13 Aug 2001 15:09:31 +0100 (BST)
>
>    > To make sure we're on the same wave length, are you suggesting
>    > this is the kind of thing we'd call in a callback from the PCI
>    > DMA support layer?
>
>    Well that would be an ugly layer violation, but how about
>
>    	scsi_retry_command_waitq(SCpnt, &dma_waitq)
>
>    ?
>
> I don't mean "PCI DMA support layer knows scsi routines to
> call", rather I mean:
>
> ... register_new_scsi_host() ...
>
> 	add_notifier(&pci_dma_freespace_notifier, &host->dma_notifier_block);
>
> And net drivers would do something similar, registering something
> that will do "netdev_wake_queue();" etc.
>
> Also, the DMA support layer must either:
>
> 1) require users of it to provide a kernel thread in which
>    to execute these things in the correct context
>
> 2) have a kernel thread of it's own to do this
>
> 3) or somehow else be able to accept this notification
>    from any kind of execution context
>
> The notifier is capable of happening anywhere, anytime.
> Right?

That's the major problem if we ever want to preserve some ordering in the
queuing of SCSI IOs. It is not clear to me why a thread may help here. A
thread may help if you actually want to thread the queuing and/or if you
want to wait on resource. Note that using a thread for the queuing might
be a solution for preserving queuing ordering, but it is not the sole
solution.

Defunct T10/CAM addresses ordering problems especially during error
recovery by a freeze/unfreeze mechanism of device queues handled by SIMs
(SIMs are low-level drivers under Linux). Using threads, call-backs or any
other evil things on top of this mechanism can be a matter of O/S
dependent issues, but it is not the solution of the problem.

> Later,
> David S. Miller
> davem@redhat.com

Later,
Gérard P. Roudier
groudier@free.fr

:)

Re: struct page to 36 (or 64) bit bus address?

[David S. Miller]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: Text/Plain; charset=big5, Size: 812 bytes --]

   From: Gérard Roudier <groudier@free.fr>
   Date: Mon, 13 Aug 2001 21:07:50 +0200 (CEST)

   That's the major problem if we ever want to preserve some ordering in the
   queuing of SCSI IOs.

When DMA mapping operation fails, you simply "stop queueing".  Queue
freezes and nothing new is executed.

DMA wakeup makes you start where you left off.  I cannot see any
ordering constraints violated by this as a side effect.  It is like a
"cork" for running scsi commands in the driver.

The purpose of the hypothetical kernel thread is to get out
of interrupt context if that is deemed necessary.

It may not be.

Later,
David S. Miller
davem@redhat.com
ý:.žË›±Êâmçë¢kaŠÉb²ßìzwm…ébïîžË›±Êâmébžìÿ‘êçz_âžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣømšSåy«\x1e­æ¶\x17…\x01\x06­†ÛiÿÿðÃ\x0fí»\x1fè®\x0få’i\x7f

Re: struct page to 36 (or 64) bit bus address?

[Alan Cox]

> And net drivers would do something similar, registering something
> that will do "netdev_wake_queue();" etc.

I don't want a callback, or if you give me a callback for scsi I'll just
turn it into a callback to wake_up(). Thats all I happen to need. net
drivers might be different

Alan

Re: add Tvia cyberpro 5050 to sound/trident.c

[Alan Cox]

> This chip is common in settop boxes. I don't know if you can
> buy any PCI cards "off the shelf".
> I think there is still interest in support for this 
> "old" chip (3 years old), at least in the "embedded market".

Ok then send me diffs

Re: IDE UDMA/ATA Suckage, or something else?

[Alan Cox]

> > You must disable IDE prefetch on the current versions of the AMD MP
> > chipset, you may also need to enable "noapic".
> 
> Unless I can do it with the kernel, I have no choice. The BIOS has no
> prefetch setting (which, BTW, I had disabled on all my A7V133 boards).
> So what about problems with non MP boards?

Well its entirely possible that the BIOS vendor did the right thing and
made sure you couldnt turn it on. How does your box behave with noapic ?

Re: IDE UDMA/ATA Suckage, or something else?

[Paul G. Allen]

Alan Cox wrote:
> 
> > > You must disable IDE prefetch on the current versions of the AMD MP
> > > chipset, you may also need to enable "noapic".
> >
> > Unless I can do it with the kernel, I have no choice. The BIOS has no
> > prefetch setting (which, BTW, I had disabled on all my A7V133 boards).
> > So what about problems with non MP boards?
> 
> Well its entirely possible that the BIOS vendor did the right thing and
> made sure you couldnt turn it on. How does your box behave with noapic ?

I haven't had a chance to try it yet. I'll let the lists know when I do.

PGA

-- 
Paul G. Allen
UNIX Admin II/Programmer
Akamai Technologies, Inc.
www.akamai.com
Work: (858)909-3630
Cell: (858)395-5043

Re: Are we going too fast?

[Alan Cox]

> > Welcome to wacky hardware. To get a G400 stable on x86 you need at least
> > 
> > XFree86 4.1 if you are running hardware 3D (and DRM 4.1)
> > 2.4.8 or higher with the VIA fixes
> > Preferably a very recent BIOS update for the VIA box
> 
> I'm sorry, but what "VIA fixes" are we referring to?

Certain VIA chipsets had some nasty bugs that caused corruption. The older
kernels have a workaround that mostly does the job but has a few side
effects. The 2.4.8 kernel has the official VIA provided workaround, which
makes sbpci128 cards work again, and sorts out some bus hangs, especially
with matrox cards

Re: Are we going too fast?

[Anthony Barbachan]

> > > Welcome to wacky hardware. To get a G400 stable on x86 you need at
least
> > >
> > > XFree86 4.1 if you are running hardware 3D (and DRM 4.1)
> > > 2.4.8 or higher with the VIA fixes
> > > Preferably a very recent BIOS update for the VIA box
> >
> > I'm sorry, but what "VIA fixes" are we referring to?
>
> Certain VIA chipsets had some nasty bugs that caused corruption. The older
> kernels have a workaround that mostly does the job but has a few side
> effects. The 2.4.8 kernel has the official VIA provided workaround, which
> makes sbpci128 cards work again, and sorts out some bus hangs, especially
> with matrox cards

    Could these "fixes" resolve any issues with the vt82c686a Southbridge?
For the life of me I have yet to be able to get my FIC VA-503A (that uses a
vt82c686a Southbridge for UDMA66 support) working correctly under Linux
2.4.x (or 2.2.x with the enhanced IDE patch) with DMA enabled by default.
And yes I have already tried switching the 80 pin cables 7 times.  Heck, I
even get CRC errors on UDMA33 drives using 40 pin cables; albeit a lesser
amount.  I have also noticed a hanging issue on a FIC VA-503+ board in which
the PC speaker can hang, in mid beep, along with the system for a short
while occasionally when the speaker issues a beep.  By the way, any ideas on
how I can help debug this particular problem?  There is no Ooops so I am not
sure how I can help out.  Both systems otherwise work very well and
perfectly on Win9x, Win2k, FreeBSD, and OpenBSD.  I'm starting to take a
very dim view of Linux on VIA boards.

Re: 2.4.9-pre2 breaks UFS as a module

[Alan Cox]

> make[2]: Entering directory `/share/src/linux-2.4.9-pre2/fs/ufs'
> gcc -D__KERNEL__ -I/share/src/linux-2.4.9-pre2/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686
> -DMODULE   -c -o file.o file.c
> file.c:80: `generic_file_open' undeclared here (not in a function)
> file.c:80: initializer element is not constant
> file.c:80: (near initialization for `ufs_file_operations.open')
> make[2]: *** [file.o] Error 1
> make[2]: Leaving directory `/share/src/linux-2.4.9-pre2/fs/ufs'
> make[1]: *** [_modsubdir_ufs] Error 2
> make[1]: Leaving directory `/share/src/linux-2.4.9-pre2/fs'
> make: *** [_mod_fs] Error 2

I'll take a look at that, Im trying to merge VFS things with Linus and its
non trivial to get all the bits in place and in the right order 8(

Re: 2.4.9-pre2 breaks UFS as a module

[Alessandro Suardi]

Alan Cox wrote:
> 
> > make[2]: Entering directory `/share/src/linux-2.4.9-pre2/fs/ufs'
> > gcc -D__KERNEL__ -I/share/src/linux-2.4.9-pre2/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686
> > -DMODULE   -c -o file.o file.c
> > file.c:80: `generic_file_open' undeclared here (not in a function)
> > file.c:80: initializer element is not constant
> > file.c:80: (near initialization for `ufs_file_operations.open')
> > make[2]: *** [file.o] Error 1
> > make[2]: Leaving directory `/share/src/linux-2.4.9-pre2/fs/ufs'
> > make[1]: *** [_modsubdir_ufs] Error 2
> > make[1]: Leaving directory `/share/src/linux-2.4.9-pre2/fs'
> > make: *** [_mod_fs] Error 2
> 
> I'll take a look at that, Im trying to merge VFS things with Linus and its
> non trivial to get all the bits in place and in the right order 8(

I can confirm it builds okay in -pre3, thanks ! I've used it only
 once as Digital Unix support folks provided a small patch on a
 floppy to a customer, then said customer noticed Windows could not
 recognize the contents - it was an UFS formatted floppy...

--alessandro

 "this is no time to get cute, it's a mad dog's promenade
  so walk tall, or baby don't walk at all"
                (Bruce Springsteen, 'New York City Serenade')

Re: how to install redhat linux to a scsi disk for which driver is no

[Alan Cox]

> Can somebody guide me on how to install RedHat Linux (e.g. 7.1)
> to a scsi disk which is connected to a scsi controller for which the 
> driver is not present on the installation media ? 

-> redhat-list@redhat.com

Re: NTFS R-Only error

[Alan Cox]

> I am not sure who currently maintains the NTFS driver so I am posting it
> here. It doesn't look to be in the kernel so maybe mount or shell?

It looks like you fed random files to strings and it tried to parse them as
x86 elf files. See the man page and tell it they are raw binary

Re: DoS tmpfs,ramfs, malloc, saga continues

[Alan Cox]

> Good job for Alan Cox, with his patch i could run the
> sample program 20 times before it crashed the system.
> I cannot belive that instead of keeping this
> masskiller for deathlocks, no way out situation, and
> as last resort, You The Great Kernel Hackers use it
> for every day and every body solution. Is it so hard
> to make more memory checks for user level malloc?
> Windows does. Every other OS does. Why linux doesn't? 
> Fix it in the next kernel!

ROTFL

If you cant crash windows nt by running out of memory you aren't doing the
right things.  Just for example feed the Nvidia direct X an infinite number
of objects to draw.

The basic answer is "Set resource limits". The default ones fit typical
usage of a system well but not your case. The more complex answer is to
provide the option for very precise group based resource accounting (aka
the beancounter patch). That is for those who want to pay the probable 2%
or so system penalty for being able to precisely manage a system resource
set. With the beancounter infrastructure you can then get to the point where
student processes are being OOM killed while the admins quake session is
unharmed.

Somewhere in the middle there is address space accounting, where you never 
allow the total address space to violate

	(read-only-pages +
		foreach writeable page
			number of extant copies +
				numer of COW potential copies
	) - kernel fudge factor (space the kernel might need)
	
			>

		    ram + swap


That is much more lightweight and covers all the general cases. However
nobody wants it much as is evident by the fact nobody has either contributed
code or paid for the work to be done

Alan

Re: DoS tmpfs,ramfs, malloc, saga continues

[Szabolcs Szakacsits]

On Tue, 14 Aug 2001, Alan Cox wrote:

> If you cant crash windows nt by running out of memory you aren't doing the
> right things.

Alan, although I didn't completely get what patch Ivan refered, 2.4.8
seems to be the far most instable when OOM happens (it just never
survived the 2nd wave of memory stressing for me).

> The basic answer is "Set resource limits". The default ones fit typical

Sure, every experienced user knows that but many people are lazy, busy,
etc to do it properly and most newcomers, desktop users basically don't
want to know about it. Forget distributors setting unreasonable limits
for them, kernel just shouldn't crash in OOM - it could handle it in the
past. This OOM issue wasn't such big problem in the past but recently
it's really getting scary. I've ported the OOM killer to 2.2 and added
reserved root VM support and AFAIR I mentioned only once here, google
indexed the page and people hits it increasingly -- about 10-20 times
more often then OOM problems pop up here. Most of them USER_AGENT
contains the Windows word - and yes, they are explicitely looking for
solution for Linux related OOM problems.

> usage of a system well but not your case. The more complex answer is to
> provide the option for very precise group based resource accounting (aka
> the beancounter patch). That is for those who want to pay the probable 2%
> or so system penalty for being able to precisely manage a system resource
> set. With the beancounter infrastructure you can then get to the point where

It's not ready for use. It was touched last time about one year ago for
2.4.0-test7.

> Somewhere in the middle there is address space accounting, where you never
> allow the total address space to violate

BTW, 2.4 has another feature. vm_enough_memory() in 2.2 underestimated
the available free memory (memory is overcommited anyway) and apps got
more frequently ENOMEM. 2.4 overestimates free memory (because
e.g. nobody knows how much cache could be freed) so apps get killed
mostly by OOM killer.

[ ... non-overcommitting algorithm ...]
> That is much more lightweight and covers all the general cases. However
> nobody wants it much as is evident by the fact nobody has either contributed
> code or paid for the work to be done

In most cases I would definitely agree with this argument but I think in
this case people who have this problem either can't code it themself or
"can't" pay for it - they just expect (unconsciously) Linux can handle
OOM just as good as others or even better.

	Szaka

Re: DoS tmpfs,ramfs, malloc, saga continues

[Andrey Savochkin]

On Wed, Aug 15, 2001 at 05:20:09PM +0300, Szabolcs Szakacsits wrote:
> 
> > usage of a system well but not your case. The more complex answer is to
> > provide the option for very precise group based resource accounting (aka
> > the beancounter patch). That is for those who want to pay the probable 2%
> > or so system penalty for being able to precisely manage a system resource
> > set. With the beancounter infrastructure you can then get to the point where
> 
> It's not ready for use. It was touched last time about one year ago for
> 2.4.0-test7.

I just can't spare time now to maintain the patch properly and make a port
for each kernel release.
When 2.5 is started, I've promised myself to put other things aside and work
on the patch to have it in the mainstream.

	Andrey

Re: Are we going too fast?

[Alan Cox]

> Mike didn't mention any details of the hardware where he's experiencing this
> bug, but is it possibly a multiprocessor machine?
> Since I only have UP's to test on, the qnxfs might have SMP issues.
> 
> Could someone please glance through the code in fs/qnx4 to check if there
> are any obvious problems?

If I get time tomorrow I'll test the qnxfs code on a dual PPro

Re: Are we going too fast?

[PinkFreud]

On Tue, 14 Aug 2001, Alan Cox wrote:

> Date: Tue, 14 Aug 2001 21:47:03 +0100 (BST)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: Anders Larsen <anders@alarsen.net>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, PinkFreud <pf-kernel1@mirkwood.net>,
>      linux-kernel@vger.kernel.org
> Subject: Re: Are we going too fast?
> 
> > Mike didn't mention any details of the hardware where he's experiencing this
> > bug, but is it possibly a multiprocessor machine?
> > Since I only have UP's to test on, the qnxfs might have SMP issues.
> > 
> > Could someone please glance through the code in fs/qnx4 to check if there
> > are any obvious problems?
> 
> If I get time tomorrow I'll test the qnxfs code on a dual PPro


Woah, good point.  While the system I'm trying this on is only a single
cpu machine (AMD K6), I noticed (after I compiled, alas) that the kernel
was compiled with the SMP option enabled - whoops.  I meant to change that
back to UP, but haven't done so as of yet.


Linux boromir 2.4.8 #1 SMP Sun Aug 12 14:08:25 EDT 2001 i586 unknown

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 5
model		: 6
model name	: AMD-K6tm w/ multimedia extensions
stepping	: 1
cpu MHz		: 199.684
cache size	: 64 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr mce cx8 mmx
bogomips	: 398.13


	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: 2.4.8 Resource leaks + limits

[Alan Cox]

> Linux has had (for a while now) a "struct user" that is actually quickly
> accessible through a direct pointer off every process that is associated
> with that user, and we could (and _will_) start adding these kinds of
> limits. However, part of the problem is that because the limits haven't
> historically existed, there is also no accepted and nice way of setting
> the limits.

For that to work we need to seperate struct user from the uid a little, or
provide heirarchical pools (which seems overcomplex). Its common to want
to take a group of users (eg the chemists) and give them a shared limit
rather than per user limits

Alan

Re: 2.4.8 Resource leaks + limits

[Linus Torvalds]

On Wed, 15 Aug 2001, Alan Cox wrote:
>
> > Linux has had (for a while now) a "struct user" that is actually quickly
> > accessible through a direct pointer off every process that is associated
> > with that user, and we could (and _will_) start adding these kinds of
> > limits. However, part of the problem is that because the limits haven't
> > historically existed, there is also no accepted and nice way of setting
> > the limits.
>
> For that to work we need to seperate struct user from the uid a little, or
> provide heirarchical pools (which seems overcomplex). Its common to want
> to take a group of users (eg the chemists) and give them a shared limit
> rather than per user limits

No, I think the answer there is to do all the same things for "struct
group" as we do for user.

Yes, it would mean that the primary group is _really_ primary, but from a
system management standpoint that's probably preferable (ie you can give
group read-write access to a person without giving group "resource" access
to him)

		Linus

Re: 2.4.8 Resource leaks + limits

[Alan Cox]

> Yes, it would mean that the primary group is _really_ primary, but from a
> system management standpoint that's probably preferable (ie you can give
> group read-write access to a person without giving group "resource" access
> to him)

Non unix systems generally have a separate accounting uid - one reason for
that is the problem of charging for setuid apps and things done in your
name. Otherwise its all too easy to attack a bug in a setuid app to make it
expand to fill memory.

I'd rather we had an luid or equivalent personally.

Alan

Re: 2.4.8 Resource leaks + limits

[Ingo Oeser]

On Wed, Aug 15, 2001 at 09:53:09AM -0700, Linus Torvalds wrote:
> > For that to work we need to seperate struct user from the uid a little, or
> > provide heirarchical pools (which seems overcomplex). Its common to want
> > to take a group of users (eg the chemists) and give them a shared limit
> > rather than per user limits
> 
> No, I think the answer there is to do all the same things for "struct
> group" as we do for user.
 
Not really. Large installations use ACLs instead of groups. 

Why? Because if we have 2^31 users, there might be a slight
chance, that we need more then 32 group memberships per user.

So let's better stop relying more and more on this group brain
damage and start supporting ACLs. We can support building ACL
groups, but please let the user and not the admin build them.

It's called user data, because the user owns it and should
decide, which people are allowed to access it. 

Please look at AFS groups, to see what I mean.

All serious admins I know miss the ACL feature in Linux. One
product even emulates them via groups.


Regards

Ingo Oeser
-- 
I just found out that the brain is like a computer.
If that's true, then there really aren't any stupid people.
Just people running Windows.

Re: 2.4.8 Resource leaks + limits

[Alan Cox]

> Not really. Large installations use ACLs instead of groups. 

Umm you can't use ACL's for resource management. You have to be able to
charge an entity. Its not a permission to access, its a "who is paying" and
that requires a real entity to charge to

Re: 2.4.8 Resource leaks + limits

[Jesse Pollard]

> > Not really. Large installations use ACLs instead of groups. 
> 
> Umm you can't use ACL's for resource management. You have to be able to
> charge an entity. Its not a permission to access, its a "who is paying" and
> that requires a real entity to charge to

And that calls for an accounting id or a project id. As well as the possiblity
of a user having multiple accounting ids.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: 2.4.8 Resource leaks + limits

[Anton Altaparmakov]

At 21:15 15/08/2001, Alan Cox wrote:
> > Not really. Large installations use ACLs instead of groups.
>
>Umm you can't use ACL's for resource management. You have to be able to
>charge an entity. Its not a permission to access, its a "who is paying" and
>that requires a real entity to charge to

While we are on this topic, wouldn't it make sense to introduce unique 
identifiers, which can be associated with users, groups, or any other 
kernel object for that matter, then this is the entity you charge. The 
kernel can then map the id to the user or group (or whatever object).

When ACLs are introduced they would grant/deny permissions and in general 
operate only on unique identifiers.

This would have the benefit that the identifiers can be made sufficiently 
unique to work on a whole network (or even larger scales), which would make 
user management much easier for large corporations, much akin to what 
Netware and Windows servers do in fact...

Just my 2p.

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: 2.4.8 Resource leaks + limits

[Jesse Pollard]

On Wed, 15 Aug 2001, Ingo Oeser wrote:
>On Wed, Aug 15, 2001 at 09:53:09AM -0700, Linus Torvalds wrote:
>> > For that to work we need to seperate struct user from the uid a little, or
>> > provide heirarchical pools (which seems overcomplex). Its common to want
>> > to take a group of users (eg the chemists) and give them a shared limit
>> > rather than per user limits
>> 
>> No, I think the answer there is to do all the same things for "struct
>> group" as we do for user.
> 
>Not really. Large installations use ACLs instead of groups. 
>
>Why? Because if we have 2^31 users, there might be a slight
>chance, that we need more then 32 group memberships per user.
>
>So let's better stop relying more and more on this group brain
>damage and start supporting ACLs. We can support building ACL
>groups, but please let the user and not the admin build them.
>
>It's called user data, because the user owns it and should
>decide, which people are allowed to access it. 
>
>Please look at AFS groups, to see what I mean.
>
>All serious admins I know miss the ACL feature in Linux. One
>product even emulates them via groups.

ACLs are good and very usefull.

HOWEVER, there are cases of users giving away their files to users
that are not authorized to recieve that data.

The advantage of groups is that the facility managment defines the
list of users authorized to view the data. It up to the user to
grant/deny that group access authorization.

Alternatively, it is possible to view the system as you describe - the
user can add others to the ACL to grant access. There should still be
some method that facility management can deny access.... On many systems
(Trusted Solaris, UNICOS, Trix,...) this is done with compartmentalization.
Now, it is subsets of the members of the compartment that the user can
grant access to.

Still more flexible than generic groups, but more restricted than no
limits on members of the ACL.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: jesse@cats-chateau.net

Any opinions expressed are solely my own.

Re: 2.4.8 Resource leaks + limits

[Horst von Brand]

Linus Torvalds <torvalds@transmeta.com> said:

[...]

> No, I think the answer there is to do all the same things for "struct
> group" as we do for user.
> 
> Yes, it would mean that the primary group is _really_ primary, but from a
> system management standpoint that's probably preferable (ie you can give
> group read-write access to a person without giving group "resource" access
> to him)

No good. Some setups (e.g. Red Hat) have a group for each user.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Implications of PG_locked and reference count in page structures....

[Alan Cox]

> So, what I want to do is this: given a pointer to a previously 
> kmalloc'ed block, and the length of that block, I want to (a) identify 
> each page associated with the block and (b) lock each page. It appears 
> that I can lock the page either by incrementing it's reference count, or 
> by setting the PG_locked flag for the page.

If the block was allocated with kmalloc it isnt pageable. That means all you
need to do is to use the virt_to_bus() call. If you are doing PCI DMA
however the preferred approach from 2.4 onwards is the pci_alloc_* API
(see Documentation/DMA-mapping.txt)

> Which method is preferred? Is there another method I should be using 
> instead?

You should be fine. If they were user pages then you would want to look
at the kiovec support for mapping user pages and locking them down. For
kernel allocated buffers it is nice and easy.

The only other oddment to note is that ISA bus DMA requires GFP_DMA as a 
kmalloc flag, PCI DMA does not (GFP_DMA is "below 16Mb please")

Alan

Re: Via chipset

[Alan Cox]

> Alan Cox wrote:
> > We know it happens on some boards that apparently cant keep up. We dont know
> > why, there is no time estimate for a cure. That unfortunately is about it
> 
> FWIW (qualitative data point), my EPoX system with the VIA chipset seems to run a
> few *hours* without an oops when I boot a PIII kernel and run it with X, but a few
> *days* on the same kernel when I don't start X.
> 
> Sometimes it barfs early even without X, but there seems to be a significant
> difference in the expected uptime between using X and not using X.

If you are running XFree servers then provide info on the card, the machine
configuration and XFree version, whether you use DRI or not. Also send the
same info to XFree86 themselves. It's entirely possible the Xserver is
the trigger some of the bugs, and getting the info to both parties will
really help

Re: 2.4.9-pre[34] changes in drivers/char/vt.c broke Sparc64

[Alan Cox]

> Have you guys noticed that new vt.c in 2.4.9-pre[34] doesn't compile on
> Sparc64 (and Sparc32) ?

I dont have sparcs to check, so I reply on the sparc maintains

> sparc64-linux-gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs    -c -o vt.o vt.c
> In file included from vt.c:27:
> /usr/src/linux/include/linux/irq.h:57: asm/hw_irq.h: No such file or directory

Russell posted a fix for this, and he' sright that removing it can be done

> vt.c: In function `vt_ioctl':
> vt.c:507: `kbd_rate' undeclared (first use in this function)
> vt.c:507: (Each undeclared identifier is reported only once
> vt.c:507: for each function it appears in.)
> vt.c:514: `kbd_rate' used prior to declaration
> vt.c:514: warning: implicit declaration of function `kbd_rate'
> 
> Simple commenting out #include <linux/irq.h> and ioctl code that uses kbd_rate works.
> Whoever changed vt.c please post correct fix.

You need a sparc hacker to do this. If there are sparcs implementing the PC
keyboard controller (eg the pci ones) then kbd_rate needs implementing and
XFree86 needs recompiling to fix cases where the keyboard can be hung solid

Alan

Re: Coding convention of function header comments

[Alan Cox]

> /**
>  * list_add - add a new entry
>  * @new: new entry to be added
>  * @head: list head to add it after
>  *
>  * Insert a new entry after the specified head.
>  * This is good for implementing stacks.
>  */
> static __inline__ void list_add(struct list_head *new, struct list_head
> *head)
> {
>  __list_add(new, head, head->next);
> }
> 
> Similar to Java.  I want to ask that (1) is this a well-known convention or
> was just invented (informally) by someone here (e.g., Linus?)?  Where can I
> find the documentation about this convention? (2) can anyone point me to the
> URL of similar well-known coding conventions (except the Java one)?

Ok firstly - yes its a straight rip off of the java one. The history is
something like. Gnome needed a format for this, so Michael Zucchi (I
believe) wrote up a hideous perl hack. Miguel de Icaza couldn't get the
format right so it was extended with a free form body. 

Its documented in Documentation/kernel-doc-nano-HOWTO.txt

We do need to improve it to mark up structures, and also to actually
finish the job.

Re: [patch] zero-bounce highmem I/O

[Alan Cox]

> It is video layer, and the video layer should be helping along with
> these sorts of issues.

Linus refused to let make make the vmalloc helpers generic code, thats
why we have 8 or 9 different copies some containing old bugs

> void video_pci_put_user_pages(struct pci_dev *pdev,
> 			      struct scatterlist *sg,
> 			      int npages);

Why video_pci. WHy is this even video related. This is a generic issue

> In fact, this isn't even a video layer issue, and the kernel
> ought to provide my suggested interfaces in some generic
> place.

Then we agree on that

Re: [patch] zero-bounce highmem I/O

[Gerd Knorr]

On Thu, Aug 16, 2001 at 03:56:21PM +0100, Alan Cox wrote:
> > It is video layer, and the video layer should be helping along with
> > these sorts of issues.
> 
> Linus refused to let make make the vmalloc helpers generic code, thats
> why we have 8 or 9 different copies some containing old bugs

:-(

> > void video_pci_put_user_pages(struct pci_dev *pdev,
> > 			      struct scatterlist *sg,
> > 			      int npages);
> 
> Why video_pci. WHy is this even video related. This is a generic issue

I've moved current bttv's mm stuff to another source file and removed
any bttv-related stuff.  Compiles, but isn't fully tested yet.  The
first three functions are pretty generic.  The videomm_buf probably
isn't useful for anything but video4linux.  Depends on the highmem-io
patches as it uses the new scatterlist->page.

Comments?  Put that into videodev.[ch] ?

  Gerd

------------------------ cut here -----------------------
--- /dev/null	Thu Jan  1 01:00:00 1970
+++ video-mm.h	Fri Aug 17 11:57:02 2001
@@ -0,0 +1,47 @@
+/*
+ * memory management helpers for video4linux drivers (+others?)
+ */
+
+/*
+ * get the page for a kernel virtual address
+ * (i.e. for vmalloc()ed memory)
+ */
+struct page* videomm_vmalloc_to_page(unsigned long virt);
+
+/*
+ * return a scatterlist for vmalloc()'ed memory block.
+ */
+struct scatterlist* videomm_vmalloc_to_sg(unsigned long virt, int nr_pages);
+
+/*
+ * return a scatterlist for a iobuf
+ */
+struct scatterlist* videomm_iobuf_to_sg(struct kiobuf *iobuf);
+
+/* --------------------------------------------------------------------- */
+
+struct videomm_buf {
+	/* for userland buffer */
+	struct kiobuf       *iobuf;
+
+	/* for kernel buffers */
+	void*               *vmalloc;
+
+	/* common */
+	struct scatterlist  *sglist;
+	int                 sglen;
+	int                 nr_pages;
+};
+
+int videomm_init_user_buf(struct videomm_buf *vbuf, unsigned long data,
+			  unsigned long size);
+int videomm_init_kernel_buf(struct videomm_buf *vbuf, int nr_pages);
+int videomm_pci_map_buf(struct pci_dev *dev, struct videomm_buf *vbuf);
+int videomm_pci_unmap_buf(struct pci_dev *dev, struct videomm_buf *vbuf);
+int videomm_free_buf(struct videomm_buf *vbuf);
+
+/*
+ * Local variables:
+ * c-basic-offset: 8
+ * End:
+ */
--- /dev/null	Thu Jan  1 01:00:00 1970
+++ video-mm.c	Fri Aug 17 11:57:14 2001
@@ -0,0 +1,183 @@
+#include <linux/pci.h>
+#include <linux/iobuf.h>
+#include <linux/vmalloc.h>
+#include <linux/slab.h>
+#include <asm/page.h>
+#include <asm/pgtable.h>
+
+#include "video-mm.h"
+
+struct page*
+videomm_vmalloc_to_page(unsigned long virt)
+{
+	struct page *ret = NULL;
+	pmd_t *pmd;
+	pte_t *pte;
+	pgd_t *pgd;
+	
+	pgd = pgd_offset_k(virt);
+	if (!pgd_none(*pgd)) {
+		pmd = pmd_offset(pgd, virt);
+		if (!pmd_none(*pmd)) {
+			pte = pte_offset(pmd, virt);
+			if (pte_present(*pte)) {
+				ret = pte_page(*pte);
+			}
+		}
+	}
+	return ret;
+}
+
+struct scatterlist*
+videomm_vmalloc_to_sg(unsigned long virt, int nr_pages)
+{
+	struct scatterlist *sglist;
+	struct page *pg;
+	int i;
+
+	sglist = kmalloc(sizeof(struct scatterlist)*nr_pages, GFP_KERNEL);
+	if (NULL == sglist)
+		return NULL;
+	memset(sglist,0,sizeof(struct scatterlist)*nr_pages);
+	for (i = 0; i < nr_pages; i++, virt += PAGE_SIZE) {
+		pg = videomm_vmalloc_to_page(virt);
+		if (NULL == pg)
+			goto err;
+		sglist[i].page   = pg;
+		sglist[i].length = PAGE_SIZE;
+	}
+	return sglist;
+	
+ err:
+	kfree(sglist);
+	return NULL;
+}
+
+#if 1
+/*
+ * this is temporary hack only until there is something generic
+ * for that ...
+ */
+# if defined(__i386__)
+#  define NO_DMA(page) (((page) - mem_map) > (0xffffffff >> PAGE_SHIFT))
+# else
+#  define NO_DMA(page) (0)
+# endif
+#endif
+
+struct scatterlist*
+videomm_iobuf_to_sg(struct kiobuf *iobuf)
+{
+	struct scatterlist *sglist;
+	int i;
+
+	sglist = kmalloc(sizeof(struct scatterlist) * iobuf->nr_pages,
+			 GFP_KERNEL);
+	if (NULL == sglist)
+		return NULL;
+	memset(sglist,0,sizeof(struct scatterlist) * iobuf->nr_pages);
+
+	if (NO_DMA(iobuf->maplist[0]))
+		goto no_dma;
+	sglist[0].page   = iobuf->maplist[0];
+	sglist[0].offset = iobuf->offset;
+	sglist[0].length = PAGE_SIZE - iobuf->offset;
+	for (i = 1; i < iobuf->nr_pages; i++) {
+		if (NO_DMA(iobuf->maplist[i]))
+			goto no_dma;
+		sglist[i].page   = iobuf->maplist[i];
+		sglist[i].length = PAGE_SIZE;
+	}
+	return sglist;
+
+ no_dma:
+	/* FIXME: find a more elegant way than simply fail. */
+	kfree(sglist);
+	return NULL;
+}
+
+/* --------------------------------------------------------------------- */
+
+int videomm_init_user_buf(struct videomm_buf *vbuf, unsigned long data,
+			  unsigned long size)
+{
+	int err;
+
+	if (0 != (err = alloc_kiovec(1,&vbuf->iobuf)))
+		return err;
+	if (0 != (err = map_user_kiobuf(READ, vbuf->iobuf, data, size)))
+		return err;
+	vbuf->nr_pages = vbuf->iobuf->nr_pages;
+	return 0;
+}
+
+int videomm_init_kernel_buf(struct videomm_buf *vbuf, int nr_pages)
+{
+	vbuf->vmalloc = vmalloc_32(nr_pages << PAGE_SHIFT);
+	if (NULL == vbuf->vmalloc)
+		return -ENOMEM;
+	vbuf->nr_pages = nr_pages;
+	return 0;
+}
+
+int videomm_pci_map_buf(struct pci_dev *dev, struct videomm_buf *vbuf)
+{
+	int err;
+
+	if (0 == vbuf->nr_pages)
+		BUG();
+	
+	if (vbuf->iobuf) {
+		if (0 != (err = lock_kiovec(1,&vbuf->iobuf,1)))
+			return err;
+		vbuf->sglist = videomm_iobuf_to_sg(vbuf->iobuf);
+	}
+	if (vbuf->vmalloc) {
+		vbuf->sglist = videomm_vmalloc_to_sg
+			((unsigned long)vbuf->vmalloc,vbuf->nr_pages);
+	}
+	if (NULL == vbuf->sglist)
+		return -ENOMEM;
+	vbuf->sglen = pci_map_sg(dev,vbuf->sglist,vbuf->nr_pages,
+				 PCI_DMA_FROMDEVICE);
+	return 0;
+}
+
+int videomm_pci_unmap_buf(struct pci_dev *dev, struct videomm_buf *vbuf)
+{
+	if (!vbuf->sglen)
+		BUG();
+
+	pci_unmap_sg(dev,vbuf->sglist,vbuf->iobuf->nr_pages,
+		     PCI_DMA_FROMDEVICE);
+	kfree(vbuf->sglist);
+	vbuf->sglist = NULL;
+	vbuf->sglen = 0;
+	if (vbuf->iobuf)
+		unlock_kiovec(1,&vbuf->iobuf);
+	return 0;
+}
+
+int videomm_free_buf(struct videomm_buf *vbuf)
+{
+	if (vbuf->sglen)
+		BUG();
+
+	if (vbuf->iobuf) {
+		unmap_kiobuf(vbuf->iobuf);
+		free_kiovec(1,&vbuf->iobuf);
+		vbuf->iobuf = NULL;
+	}
+	if (vbuf->vmalloc) {
+		vfree(vbuf->vmalloc);
+		vbuf->vmalloc = NULL;
+	}
+	return 0;
+}
+
+
+/*
+ * Local variables:
+ * c-basic-offset: 8
+ * End:
+ */

Re: Via chipset

[Alan Cox]

> figured what in xscreensaver is doing this, don't know if it might be kernel
> related or not, probably not. I suspect xscreensaver is triggering something in
> the xserver that is not normally getting hit in normal use.

Thats actually quite possible. In paticular it uses arc's which basically no
other X app ever does. Report that info to either XFree or nvidia (depending
on whose X server)

Alan

Re: Spammer using linux kernel archives

[Alan Cox]

> FYI, a spammer claiming to be Dan Fuller representing D&H Group, Inc. (a
> recruiter) appears to be trolling the Linux kernel archives.  He sent me a
> job offer based on my "reputation as a Linux device driver developer".  I've
> already reported him to his ISP.

It seems to be common unfortunately. I nowdays tell them about ideal
candidates and give them each others details. Hours of fun for the wicked

Re: Spammer using linux kernel archives

[Tina Gasperson]

No wonder you don't have 30 minutes to donate to a poor Linux Users Group! 
Spending all your free time tormenting people!

;)
Tina G

>
> It seems to be common unfortunately. I nowdays tell them about ideal
> candidates and give them each others details. Hours of fun for the wicked
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel threads

[Alan Cox]

> schedule the call to kernel_thread using tq_schedule

You still want to use daemonzie

> - is there no need to call daemonize in the second variant - if yes why?

A task always has a parent, it'll just be a random task that ran the 
kernel_thread request - in fact it might be a kernel thread and then 
I dont guarantee what will occur. In fact I wouldnt try the tq_schedule one

> - can i do both variants during interupt time (when there is no valid 
> current)?

No, but you can create a thread ready in case its needed then wake it from
an IRQ

Re: kernel threads

[Christian Widmer]

On Friday 17 August 2001 00:37, you wrote:
> > schedule the call to kernel_thread using tq_schedule
>
> You still want to use daemonzie
>
> > - is there no need to call daemonize in the second variant - if yes why?
>
> A task always has a parent, it'll just be a random task that ran the
> kernel_thread request - in fact it might be a kernel thread and then
> I dont guarantee what will occur. In fact I wouldnt try the tq_schedule one

sorry i didn't say that i what to use 2.4.x
when looking to kernel/context.c there it says that (or better i looks to me 
like it sais) that all that is sheduled to tq_schedule runns under keventd. so
the parent is predicable and is demonised itsself. is that bad or good?

Re: 2.4.9 does not compile [PATCH]

[Alan Cox]

> The args and semantics of min/max changed to take
> a type first argument, the problem with this ntfs file is that it
> fails to include linux/kernel.h

Thank you for your detailed discussion of this in advance on the kernel
list, your careful consideration of the 2.2 compatibility work horrors you
introduced and the thoughtful way you notified maintainers.

And all this from a man who gives me an earful if I merge third party
network patches without going through him.

Alan

Re: 2.4.9 does not compile [PATCH]

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Thu, 16 Aug 2001 23:41:07 +0100 (BST)

   > The args and semantics of min/max changed to take
   > a type first argument, the problem with this ntfs file is that it
   > fails to include linux/kernel.h
   
   Thank you for your detailed discussion of this in advance on the kernel
   list, your careful consideration of the 2.2 compatibility work horrors you
   introduced and the thoughtful way you notified maintainers.

Listen:

1) All of this was done at the request of Linus.

2) You were CC:'d on every single email
   that Linus and I had on these changes, and you
   saw every single revision of the patch.

Why are you complaining now, please speak up earlier next time when
you have a grip.  This is why you were CC:'d on the emails.

I am actually unhappy Linus waited until 2.4.9 final to put those
changes in as I was sure 1 or 2 compile issues would slip through.
I have been sending it over and over throughout the 2.4.9 prepatches.

Later,
David S. Miller
davem@redhat.com

Re: 2.4.9 does not compile [PATCH]

[Jes Sorensen]

>>>>> "David" == David S Miller <davem@redhat.com> writes:

David>    From: Alan Cox <alan@lxorguk.ukuu.org.uk> Date: Thu, 16 Aug
David> 2001 23:41:07 +0100 (BST)

>    Thank you for your detailed discussion of this in advance on
> the kernel list, your careful consideration of the 2.2
> compatibility work horrors you introduced and the thoughtful
> way you notified maintainers.

David> Listen:

David> 1) All of this was done at the request of Linus.

David> 2) You were CC:'d on every single email that Linus and I had on
David> these changes, and you saw every single revision of the patch.

Alan's point about CC'ing maintainers still stands, where was the CC
to the individual maintainers of the code you changed?

Jes

Re: 2.4.9 does not compile [PATCH]

[Alan Cox]

> 2) You were CC:'d on every single email
>    that Linus and I had on these changes, and you
>    saw every single revision of the patch.

Yep. And at the time I asked you to send it to the maintainers and the like.

Re: 2.4.9 does not compile [PATCH]

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Thu, 16 Aug 2001 23:55:44 +0100 (BST)

   > 2) You were CC:'d on every single email
   >    that Linus and I had on these changes, and you
   >    saw every single revision of the patch.
   
   Yep. And at the time I asked you to send it to the maintainers and the like.

When you were shown the patch your sentiments were:

1) Some of that stuff is against old drivers, I have newer
   ones in -ac so no biggie.
2) The ixj instances look like real bugs, and that you'd
   have a closer look.
3) If there are any merge issues in your -ac tree, no big
   deal because they'd show up as obvious compile errors.
4) Otherwise, it looked just fine to you.

I don't recall you saying anything about "make sure to tell the
maintainers" But, on the other hand, I can't prove that you didn't (I
don't keep detailed mail logs anymore except for what I send out
myself), so if you did I apologize.

Later,
David S. Miller
davem@redhat.com

Re: 2.4.9 does not compile [PATCH]

[David S. Miller]

   From: Rik van Riel <riel@conectiva.com.br>
   Date: Fri, 17 Aug 2001 18:46:20 -0300 (BRST)

   On Thu, 16 Aug 2001, David S. Miller wrote:
   
   > I don't recall you saying anything about "make sure to tell the
   > maintainers"
   
   I'll remember your attitude for if I ever have to
   touch the network code ;)

If Linus scribbled all over the network code I would
have to accept it if it were a kernel wide cleanup he
absolutely wanted.

Later,
David S. Miller
davem@redhat.com
   

Re: 2.4.9 does not compile [PATCH]

[Alan Cox]

> I don't recall you saying anything about "make sure to tell the
> maintainers" But, on the other hand, I can't prove that you didn't (I
> don't keep detailed mail logs anymore except for what I send out
> myself), so if you did I apologize.

I'm pretty sure I did (and I can prove it but whatever 8)). Whats done is done.
I think it was a bad idea for 2.4 (driver compat nightmare). 

Anyway arguing about it achieves nothing for anyone

Alan

Re: 2.4.9 does not compile

[Alan Cox]

> 	If you really want this facility, you could just declare
> a distinct "typed_min" macro.

For -ac I intend to change it to exactly that. Then we can also back
propogate compatibility macros. Abusing min prevents that

Re: 2.4.9 does not compile [PATCH]

[Alan Cox]

>    From: Anton Altaparmakov <aia21@cam.ac.uk>
>    Date: Fri, 17 Aug 2001 00:22:43 +0100
>    
>    IMHO, it would have been more elegant to use the typeof construct provided 
>    by gcc in the new macro instead of introducing a type parameter like this...
> 
> The whole point was to make users explicitly state the type so they
> would have to think about it.

And doing it by forcing them all to change their macro names isnt the
right solution. Its actually basically impossible to do back compat macros
with this mess. Your original smin() umin() proposal was _much_ saner.

As I've said, -ac will use typed_min(a,b,c), and that way I can propogate
back compatibility glue.

Alan

Re: 2.4.9 does not compile [PATCH]

[Alan Cox]

> Wrong.  This is legal:
> 
> int test(unsigned long a, int b)
> {
> 	return min(a, b);
> }

> And the compiler will warn about it with your typeof version.

Good, because its absolutely bogus and you want people to be warned so they
fix the input types to fit in the output type, and are forced to think about
whether all cases actually fit

Re: 2.4.9 does not compile [PATCH]

[Alan Cox]

>    I would hope that it would warn: what if a is the maximum size that an
>    array can be and b is a value passed in from userland?  Most definately
>    not an expected result.
> 
> My example was poor, consider if 'b' was something like '100'
> or for some other reason you already know perfectly well
> the legal range of 'b' or 'a'.

Then the compiler will cast constants for you (and warn if they dont fit),
and you can use casts to make it clear you know the legal ranges

Re: initrd: couldn't umount

[Alan Cox]

> the problem is that a "rpciod" kernel-thread references the initrd,
> and so umounting and freeing it, isn't possible.
> 
> has anybody an idea how to fix this problem, cause it would be nice,
> to free the initrd ram on a diskless node.

It shouldnt be keeping a reference. daemonize() should have dropped its
resources

Re: initrd: couldn't umount

[Daniel Wagner]

Alan Cox wrote:
> 
> > the problem is that a "rpciod" kernel-thread references the initrd,
> > and so umounting and freeing it, isn't possible.
> >
> > has anybody an idea how to fix this problem, cause it would be nice,
> > to free the initrd ram on a diskless node.
> 
> It shouldnt be keeping a reference. daemonize() should have dropped its
> resources

hmm, i've now created a /initrd directory to let the the change_root of
the
initrd work correctly.

and then i looked with fuser, what processes reference the initrd:

---
root@ws4:~ $ fuser -mv /initrd/
 
                     USER        PID ACCESS COMMAND
/initrd/             root         67 .rc.. 
rpciod                                                                                         
---

only the rpciod references the initrd, none of the other
kernel-threads.

Regards,
  Daniel

-- 
Daniel Wagner                      | mailto:daniel@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

Re: initrd: couldn't umount

[Andreas Haumer]

Hi!

Daniel Wagner wrote:
> 
> Alan Cox wrote:
> >
> > > the problem is that a "rpciod" kernel-thread references the initrd,
> > > and so umounting and freeing it, isn't possible.
> > >
> > > has anybody an idea how to fix this problem, cause it would be nice,
> > > to free the initrd ram on a diskless node.
> >
> > It shouldnt be keeping a reference. daemonize() should have dropped its
> > resources
> 
> hmm, i've now created a /initrd directory to let the the change_root of
> the
> initrd work correctly.
> 
> and then i looked with fuser, what processes reference the initrd:
> 
> ---
> root@ws4:~ $ fuser -mv /initrd/
> 
>                      USER        PID ACCESS COMMAND
> /initrd/             root         67 .rc..
> rpciod
> ---
> 
> only the rpciod references the initrd, none of the other
> kernel-threads.
> 
Could it be because, when executed, rpciod() calls 
exit_files(current) and exit_mm(current), but doesn't
call exit_fs(current) (as, for instance, md_thread() does)? 
(we are talking 2.2.19 here)

We well try it in a few minutes... :-)

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

Re: initrd: couldn't umount

[Andreas Haumer]

Hi!

(added okir@monad.swb.de to CC: list, as he is listed in the 
header of linux/net/sunrpc/sched.c as author of this file)

To answer my own question... ;-)

Andreas Haumer wrote:
> 
> Hi!
> 
> Daniel Wagner wrote:
> >
> > Alan Cox wrote:
[...]
> > > It shouldnt be keeping a reference. daemonize() should have dropped its
> > > resources
> >
> > hmm, i've now created a /initrd directory to let the the change_root of
> > the
> > initrd work correctly.
> >
> > and then i looked with fuser, what processes reference the initrd:
> >
> > ---
> > root@ws4:~ $ fuser -mv /initrd/
> >
> >                      USER        PID ACCESS COMMAND
> > /initrd/             root         67 .rc..
> > rpciod
> > ---
> >
> > only the rpciod references the initrd, none of the other
> > kernel-threads.
> >
> Could it be because, when executed, rpciod() calls
> exit_files(current) and exit_mm(current), but doesn't
> call exit_fs(current) (as, for instance, md_thread() does)?
> (we are talking 2.2.19 here)
> 
Yes, an additional call to exit_fs(current) when initializing
the rpciod thread solves this problem without creating other 
(obvious) problems (as it seems after a short test).

The inital ramdisk can now be unmounted cleanly even in case
of NFS root

The suggested patch is:

andreas@ws1:~/cvsdir {625} % cvs diff -C5 -rR_2-2-19~11 -rR_2-2-19~12
linux/net/sunrpc/sched.c
Index: linux/net/sunrpc/sched.c
===================================================================
RCS file:
/raid5/cvs/repository/distribution/Base/linux/net/sunrpc/sched.c,v
retrieving revision 1.1.1.6
retrieving revision 1.12
diff -C5 -r1.1.1.6 -r1.12
*** linux/net/sunrpc/sched.c    2001/03/25 16:37:42     1.1.1.6
--- linux/net/sunrpc/sched.c    2001/08/17 11:53:48     1.12
***************
*** 1066,1075 ****
--- 1066,1076 ----
        rpciod_pid = current->pid;
        up(&rpciod_running);
 
        exit_files(current);
        exit_mm(current);
+       exit_fs(current);
 
        spin_lock_irq(&current->sigmask_lock);
        siginitsetinv(&current->blocked, sigmask(SIGKILL));
        recalc_sigpending(current);
        spin_unlock_irq(&current->sigmask_lock); 


Alan, would you consider adding this patch to 2.2.20?

Thanks!

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

Re: K6 sig11 Bug detection.

[Alan Cox]

> Aug 17 09:06:49 phoenix kernel: CPU: Before vendor init, caps: 008001bf 
> 008005bf 00000000, vendor = 2
> Aug 17 09:06:49 phoenix kernel: AMD K6 stepping B detected - <6>K6 BUG 
> 9016725 20000000 (Report these if test report is incorrect)
> Aug 17 09:06:49 phoenix kernel: AMD K6 stepping B detected - probably OK 
> (after B9730xxxx).

Looks ok to me.

Re: Promise Ultra100(20268) address conflict with ServerWorks IDE

[Alan Cox]

>         I/O ports at 5440 [size=16]
> 
> // notice the gap at 5450-545F.
> // It will be allocated for the Serverworks IDE controller later.
> // This gap is only real, if size=16 is a true statement

The size data is read from the PCI card itself, which would lead me to
suspect we reserve to much maybe ?

Re: Kernel panic problem in 2.4.7

[Alan Cox]

> 
> SGVsbG8uLiBBbGwNCg0KSSBoYXZlIG9wZXJhdGVkIFJlZGhhdCA2LjIgYmFzZWQgc3lzdGVtKGtl
> cm5lbCAyLjQuNykgIHdoaWNoIGlzIER1YWwgQ1BVIGFuZCA1MTJNIFJhbS4NCg0KQSBmZXcgZGF5
> cyBhZ28sIHRoaXMgc3lzdGVtIGlzIGRvd24gYW5kIHRoZSBtZXNzYWdlcyBsaWtlIGJlbG93Lg0K
> DQpKdWwgMjIgMTQ6NTc6NDUgd3d3IGtlcm5lbDogS2VybmVsIHBhbmljOiBDUFUgY29udGV4dCBj
> b3JydXB0DQpKdWwgMjUgMTk6MjU6MzAgd3d3IGtlcm5lbDogS2VybmVsIHBhbmljOiBDUFUgY29u
> dGV4dCBjb3JydXB0DQpKdWwgMjcgMjM6NDM6MjIgd3d3IGtlcm5lbDogS2VybmVsIHBhbmljOiBD
> UFUgY29udGV4dCBjb3JydXB0DQoNCnRoaXMgbWFpbGxpbmcgbGlzdCBzYXkgdGhhdCB0aGlzIGlz
> IENQVSBQcm9ibGVtKG92ZXJjbG9ja2luZy4uLi5idXQgaXQgaXNuJ3QpLg0KU28gSSBjaGFuZ2Vk
> IG90aGVyIENQVXMgdGhhdCBJIHRoaW5rICBubyBwcm9ibGVtLg0KDQpCdXQgYSBmZXcgZGF5cyBs
> YXRlci4ga2VybmVsIHBhbmljIG9jY3VyZWQgYWdhaW4uDQooVGhlIHN5c3RlbSBpcyAyLjQuNykN
> CnRoZSBtZXNzYWdlcyB3YXMgDQoNCktlcm5lbCBwYW5pYzpBaWVlLCBraWxsaW5nIGludGVycnVw
> dCBoYW5kbGVyDQpJbiBpbnRlcnJ1cHQgaGFuZGxlciAtIG5vdCBzeW5jaW5nDQoNClRoaXMgbWVz
> c2FnZSBpcyBvY2N1cmVkIHdoZW4gdGhlIHN5c3RlbSdzIGxvYWQgYXZlcmFnZSBpcyBhIGJpdCBo
> aWdoLg0KKFdoZW4gSSBLZXJuZWwgY29tcGlsZSBvciBwYWNraW5nIHdpdGggdGFyLi4gc29tdGhp
> bmcgbGlrZSB0aGF0Li4pDQoNCkkgc2VhcmNoZWQgYWxsIGxpc3RzLCBCdXQgSSBjb3VsZG4ndCBm
> aW5kIHRoZSAicmVhc29uIiBhbmQgImFuc3dlciIuDQpJIHdvdWxkIGxpa2UgdG8ga25vdyB0aGUg
> cmVhc29uIGFuZCBhbnN3ZXIuDQoNClBsZWFzZSBnaXZlIG1lIHNvbWUgYWR2aWNlIGFib3V0IHRo
> ZXNlIHByb2JsZW1zLg0KDQogDQogVGhhbmtzIGZvciB5b3VyIGhlbHAuDQogIA0KIA0K
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Kernel panic problem in 2.4.7

[Alan Cox]

If your cpu context corrupt is with a machine check exception report then
your processor took an internal fault reporting trap. So its not a happy
bit of silicon I suspect - be it overclocked, overheated, or even faulty.

Re: Kernel panic problem in 2.4.7

[Alan Cox]

> If your cpu context corrupt is with a machine check exception report then
> your processor took an internal fault reporting trap. So its not a happy
> bit of silicon I suspect - be it overclocked, overheated, or even faulty.

Beware beta versions of editors 8)

If your CPU context corrupt message is appearing with a machine check
exception report, then you processor took an internal fault reporting trap.

So it's not a happy piece of silicon I suspect - be it overclocked,
overheated or even faulty.

The machine check numbers it prints can be looked up in the processor
manuals to decode the type of fault.

Re: Via usb problems...

[Alan Cox]

> The work-around for the problem is provided by VIA in the form of some
> updated drivers for windows.  It appears to be some sort of usb filter,
> possibly for low bandwidth USB peripherals.  I suspect this isn't a
> working resolution for most people on this list and I was wondering if
> anyone has been working on this in the kernel?  I might be able to
> provide some more information if it is needed to diagnose and solve the
> problem...

Can you provide me

1.	The lspci -v info for your box (chip revision etc)
2.	Details ont he updated windows drivers (eg URL for)
3.	The USB devices

> Does VIA have any engineers working on linux drivers?

Directly, I don't believe so. However they do provide contact points for
some of us and have provided workarounds for other bugs. We now have a 
mechanism in place for making such requests.

Firstly however I'd like the USB folks to look at the debug and traces to be
sure this isnt a VIA chip bug. If it is I'll take it up with VIA

Re: 2.4.9 does not compile [PATCH]

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Fri, 17 Aug 2001 10:11:17 +0100 (BST)
   
   Its actually basically impossible to do back compat macros
   with this mess. Your original smin() umin() proposal was _much_ saner.

I don't see how you can logically say this.
My sint_min() etc. version broke things just
as equally because it had:

#define min __compile_error_do_not_use_min
#define max __compile_error_do_not_use_max

in it.  Do you think Linus or myself, by doing
this, intended to let anyone undef the damn things
to get around this?

The whole point of the changes was "min and max are
dumb, nobody may use them in their traditional form".

I was pretty sure, you understood this.

Later,
David S. Miller
davem@redhat.com

Re: 2.4.9 does not compile [PATCH]

[Alan Cox]

>    Its actually basically impossible to do back compat macros
>    with this mess. Your original smin() umin() proposal was _much_ saner.
> 
> I don't see how you can logically say this.

Because it would have been trivial to provide back compatibility macros to
provide sint_min/sint_max on 2.2. Now all I can do is make -ac use sint_min
sint_max and friends (or typed_min to be exact) and make 2.2 and -ac 
compatible

> My sint_min() etc. version broke things just
> as equally because it had:

Nothing like as badly.

Alan

Re: 2.4.9 does not compile [PATCH]

[Alan Cox]

> If Linus scribbled all over the network code I would
> have to accept it if it were a kernel wide cleanup he
> absolutely wanted.

That doesn't make it right, it merely makes the perpetrator wrong.

kfree safe in interrupt context?

[Victor Yodaiken]

Seems like calling kfree from interrupt context should
be ok, but is it? 
If it is safe, is this considered a good thing  or not?

Re: kfree safe in interrupt context?

[Rusty Russell]

In message <20010817211406.A21326@hq2> you write:
> Seems like calling kfree from interrupt context should
> be ok, but is it? 
> If it is safe, is this considered a good thing  or not?

Yes, and it logically has to be, as kmalloc(..., GFP_ATOMIC) is safe
from interrupt context.

The network code does this all the time, for example.

Hope that helps,
Rusty.
--
Premature optmztion is rt of all evl. --DK

Re: kfree safe in interrupt context?

[Victor Yodaiken]

On Sun, Aug 19, 2001 at 09:44:45PM +1000, Rusty Russell wrote:
> In message <20010817211406.A21326@hq2> you write:
> > Seems like calling kfree from interrupt context should
> > be ok, but is it? 
> > If it is safe, is this considered a good thing  or not?
> 
> Yes, and it logically has to be, as kmalloc(..., GFP_ATOMIC) is safe
> from interrupt context.
> 
> The network code does this all the time, for example.
> 
> Hope that helps,

It does, but Alan answered first and also much more
eloquently. -)

Re: 2.4.9 does not compile [PATCH]

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Fri, 17 Aug 2001 23:09:15 +0100 (BST)

   > If Linus scribbled all over the network code I would
   > have to accept it if it were a kernel wide cleanup he
   > absolutely wanted.
   
   That doesn't make it right, it merely makes the perpetrator wrong.

To be honest, I like having someone like him who can just put his foot
down on a matter whilst the rest of us waste days in silly flame wars
on the topic. :-)

I've stop caring, personally.  Back it out, it wouldn't bother me.
I made a patch someone asked me to make, so sue me.

What bothers me is all the time being spent arguing about it.

Later,
David S. Miller
davem@redhat.com

Re: 2.4.9 does not compile [PATCH]

[Daniel Phillips]

On August 18, 2001 12:11 am, David S. Miller wrote:
> What bothers me is all the time being spent arguing about it.

It would be safe to conclude it's a universally unpopular change.

--
Daniel

Re: 2.4.9 does not compile [PATCH]

[David S. Miller]

   From: Daniel Phillips <phillips@bonn-fries.net>
   Date: Sat, 18 Aug 2001 01:34:28 +0200

   On August 18, 2001 12:11 am, David S. Miller wrote:
   > What bothers me is all the time being spent arguing about it.
   
   It would be safe to conclude it's a universally unpopular change.

Well, to be fair, popularity sometimes isn't much of an indicator.
Often people argue things because of change itself.  Having to do
something differently can make people feel uneasy, so they resist the
change.

Later,
David S. Miller
davem@redhat.com

Re: 2.4.9: GCC 3.0 problem in "acct.c"

[Alan Cox]

> i just updated my gcc from 2.96 to 3.0.1 and now i cant compile kernel 2.4.9
> anymore, make bzImage fails with the following error message:
> 
> acct.c: In function `check_free_space':
> acct.c:147: Unrecognizable insn:
> (insn 335 102 336 (parallel[
>             (set (reg/v:SI 2 ecx [44])
>                 (const_int 0 [0x0]))
>             (clobber (reg:CC 17 flags))
>         ] ) -1 (insn_list:REG_DEP_ANTI 100 (insn_list:REG_DEP_ANTI 102
> (nil)))
>     (expr_list:REG_UNUSED (reg:CC 17 flags)
>         (nil)))
> acct.c:147: Internal compiler error in insn_default_length, at
> insn-attrtab.c:223
> 
> can anyone tell me how to fix this?

Use gcc 2.96 or gcc 3.0.0. You broke the compiler. Please also see the gcc bug
reporting instructions. You will actually make a gcc hacker very happy 
reporting that problem.

Re: 2.4.x & Celeron = very slow system

[Alan Cox]

> With 2.4.x kernel my system (Celeron (Coppermine) 850Mhz (100x8.5)
> 256Mb i810) behaves like slow i386sx.
> For example, when I extract 25MB gzip file on 2.2.19 kernel - it
> takes about 12 seconds, but with 2.4.8(9) - 6(!) MINUTES on the SAME
> system...
> The only idea is that 2.4.x kernel turns off cache (L1 & L2) on
> processor (on my cpu). How can I check it? Any ideas?

We don't touch the caches like that. First guess is to disable the ACPI
support, because we've seen that do a million bogus things

Re: gcc-3.0 with 2.2.x ?

[Alan Cox]

> I can use gcc-3.0 to compile 2.4.8-ac7 but can not do
> that with 2.2.19

> so I would like to know if there is any patches to
> 2.2.19 to make it friendlier with gcc-3.0. In the mean
> time I am going to see sched.c and sched.h and try to
> make it work :-)

I've got no plans to care about 2.2 and gcc 3.0. Trying to deal with all
the fun things gcc 3.0 does (quite legally too the ones I looked at) is
hard. The amount of work required to fix it is large and given 2.2 is
there for maximum stability also pointless, since its an untrusted compile
combination.

Alan

Re: BUG: pc_keyb.c

[Alan Cox]

>   Due to writing to the status register before it's ready as far as I 
> can se.
> 
>   fix: change all mdelay(1) in pc_keyb.c to mdelay(2)'s .. ( mdelay(1) 
> will be on the timing limit.

Thats interesting. I thought the rule was 1mS. (There is indeed a timing
requirement). Any keyboard controller experts around ?

>   Might also be present during high load on machines running GL on AGP 
> video cards, not 100 % sure same symptoms, above seem's to fix ???? ( 
> strange ).

XFree86 touches they keyboard controller directly unless you rebuild it 
against a recent -ac kernel. This causes amusing problems with legacy free
PC's as well as the timing issue.

That might explain the other one

Re: On Network Drivers......

[Alan Cox]

>  A driver of layered one.., in which one layer
> communicates with another. But overall there should be
> only one driver . (Just like Stream's drivers, but we
> don't want Stream Drivers). 
>     Is there any support in Linux to implement Network
> Drivers as multi layered in a single driver .If so,
> please let me know where I can get good information?

We have a single layer between the network stack and the drivers. However
nothing stops drivers from implementing multiple layers internally or
calling back into other drivers. shaper is an example of a driver that
calls other drivers.

The basic attitude is layering is slow, and generally poor for the cache
behaviour. You want to do a single pass of the packet (or less if possible
when using DMA). However the interface is flexible and if a driver wants
to be layered or has reason for it - sure it can do it internally

Re: On Network Drivers......

[Venu Gopal Krishna Vemula]

Sir,

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

>>  A driver of layered one.., in which one layer
>> communicates with another. But overall there 
>> should be  only one driver . (Just like Stream's
>> drivers, but we don't want Stream Drivers). 

> 
> We have a single layer between the network stack and
> the drivers. However  nothing stops drivers from 
> implementing multiple  layers internally or
> calling back into other drivers. shaper is an
> example of a driver that  calls other drivers.
> 

 Can you please explain something about implementing
multiple layers internally in a Network Driver 
                     or
 inform me where i can find information (Source code)

         Today i have searched a lot to find any
information related to the Network driver(in which
multiple layers has to develop internally)  in
Internet, but i could not found any source code or
information in Internet.

With Thanks,
regards,
vvgkrishna_78@yahoo.com


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: PATCH: linux-2.4.9/drivers/i2o to new module_{init,exit} interface

[Alan Cox]

> declarations in linux/Makefile.  (If you really need i2o
> initialization to occur earlier than do_initcalls(), then that would
> also mean that i2o cannot be a module, right?)

In certain configurations you are correct

> 	If you want, I can send you a new patch that changes
> linux/Makefile to initialize i2o before just before drivers/block,
> thereby reproducing the current initialization order, and, of course,

Sounds ok to me - Im not against tidying it up. Note btw the -ac i2o code
is a little different to vanilla and is the 'current' one. I think your
patches will apply fine however as the changes are small

Re: sound crashes in 2.4

[Alan Cox]

> I have the same problems with an ALS007 card (in a 486 system).
> The card is correctly recognized and set up by the PnP drivers.

Humm. 

> The time after which it crashes is variable, sometimes it crashes
> immediately, sometimes it crashes after 5 minutes.
> Sometimes, it also stalls a few times before finally crashing.

Ok that actually sounds more like a locking bug.

> Both 2.4.8 and 2.4.9 have this problem (these are the ones I tried).
> Btw on 2.2.x i get DMA (output) timeout errors (and broken sound).

Can you try one other thing.

Edit drivers/pci/quirks.c

find 

int isa_dma_bridge_buggy;		/* Exported */

and make it read

int isa_dma_bridge_buggy = 1;

recompile reboot and see if it helps

Re: sound crashes in 2.4

[Chris Pockele]

> Can you try one other thing.
> 
> Edit drivers/pci/quirks.c
> 
> find 
> 
> int isa_dma_bridge_buggy; /* Exported */
> 
> and make it read
> 
> int isa_dma_bridge_buggy = 1;
> 
> recompile reboot and see if it helps
> 
Unfortunately, it does not help.  The machine rebooted
suddenly (i forgot to mention that: sometimes it reboots
too, but mostly it just hangs).

btw the system doesn't have a PCI bus, so its kernel
does not have PCI support enabled

(it's a SIS85C471B-based ISA/VLB motherboard)

Re: sound crashes in 2.4

[Frank Davis]

Hello all,
     A trace of the crashes would be helpful.

Regards,
Frank

Chris Pockele wrote:

>>Can you try one other thing.
>>
>>Edit drivers/pci/quirks.c
>>
>>find 
>>
>>int isa_dma_bridge_buggy; /* Exported */
>>
>>and make it read
>>
>>int isa_dma_bridge_buggy = 1;
>>
>>recompile reboot and see if it helps
>>
>>
> Unfortunately, it does not help.  The machine rebooted
> suddenly (i forgot to mention that: sometimes it reboots
> too, but mostly it just hangs).
> 
> btw the system doesn't have a PCI bus, so its kernel
> does not have PCI support enabled
> 
> (it's a SIS85C471B-based ISA/VLB motherboard)
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

Re: sound crashes in 2.4

[Chris Pockele]

> Hello all,
>      A trace of the crashes would be helpful.
> 
unfortunately, i don't get any oops or panic messages.
There's nothing about it on the console, nothing in
logs either.

The box just freezes.  No more ping/connection
replies, no more reaction to any keyboard input.

(this must be a very hard bug)

cheers

Re: BUG: pc_keyb.c

[Alan Cox]

> But the present code does not guarantee such a delay at all.
> For example, kbd_write_cmd() does
> 	kb_wait();
> 	outb(...);
> 	kb_wait();
> where the second kb_wait reads the status very quickly after the first.

Thats wrong by the spec. I dug out my docs - there is a required 1mS (not
2 tho) delay for keyboard port accesses.

Re: Linux 2.4.8-ac8

[Alan Cox]

> Alan,
> 
> I'm sorry if it was previously answered, but why your tree is currently not 
> in sync with Linus's tree?

Because I don't actually see the point of being in sync with 2.4.9 currently

Re: On Network Drivers......

[Alan Cox]

> information related to the Network driver(in which
> multiple layers has to develop internally)  in
> Internet, but i could not found any source code or
> information in Internet.

How strange. The kernel source code is definitely on the internet, and
definitely contains drivers that implement internal layering - 
nrdev, shaper, the sync cards, isdn

Re: massive filesystem corruption with 2.4.9

[Alan Cox]

> > Aug 21 09:01:06 adlib kernel: EXT2-fs error (device ide0(3,5)):
> > ext2_new_block: Allocating block in system zone - block =3D 3
> > Aug 21 09:01:06 adlib kernel: EXT2-fs error (device ide0(3,5)):
> > ext2_free_blocks: Freeing blocks in system zones - Block =3D 4, count=
>  =3D 1

Typically this indicates disk, memory or chipset problems. If your disk is
in UDMA33/66 mode you can pretty rule the disk out as the data is
protected

If you have a VIA chipset, especially if there is an SB Live! in the machine
then that may be the cause (fixes in 2.4.8-ac, should be a fix in 2.4.9 but
Linus tree also applies another bogus change but which should be harmless)

> > These fatal errors are occuring since 2.4.5 (2.4.8 I've not tested.).=
>  When
> > I work with 2.4.4 everything is fine !

What hardware

Re: massive filesystem corruption with 2.4.9

[Kristian]

Alan Cox wrote:
 > Typically this indicates disk, memory or chipset problems. If your disk is
 > in UDMA33/66 mode you can pretty rule the disk out as the data is
 > protected
 >
 > If you have a VIA chipset, especially if there is an SB Live! in the machine
 > then that may be the cause (fixes in 2.4.8-ac, should be a fix in 2.4.9 but
 > Linus tree also applies another bogus change but which should be harmless)

No. I can't find any VIA chipset. I'm really surprised. :-) But it is an
original Compaq-Board (EP-Series..) with a horroble BIOS. It seems that they're
using intel only..

I did a probe of my harddisk with IBM's Drive Fitness program. It detected no
errors.

Here's the output of it:

     Model                   : IBM-DTLA-305040
     Serial no.              : YJ025714
     Capacity                : 41.17 GB
     Cache size              : 380 KB
     Microcode level         : TW4OA60A
     ATA Compliance          : ATA-5

     Ultra DMA
       Highest mode          : 5
       Active mode           : 1

     Settings
       Write cache           : Enabled
       Read look-ahead       : Enabled
       Auto reassign         : Enabled
       S.M.A.R.T. operations : Enabled
       S.M.A.R.T. status     : Good
       ABLE                  : Disabled
       AAM                   : Disabled
       Security feature      : Supported
         Password            : Not Set


Here is the output of cat /proc/pci:
PCI devices found:
    Bus  0, device   0, function  0:
      Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 3).
        Master Capable.  Latency=64.
        Prefetchable 32 bit memory at 0x44000000 [0x47ffffff].
    Bus  0, device   1, function  0:
      PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 3).
        Master Capable.  Latency=64.  Min Gnt=140.
    Bus  0, device  14, function  0:
      Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 5).
        IRQ 11.
        Master Capable.  Latency=66.  Min Gnt=8.Max Lat=56.
        Prefetchable 32 bit memory at 0x48100000 [0x48100fff].
        I/O at 0x1000 [0x101f].
        Non-prefetchable 32 bit memory at 0x48000000 [0x480fffff].
    Bus  0, device  15, function  0:
      Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 6).
        IRQ 11.
        Master Capable.  Latency=64.  Min Gnt=12.Max Lat=128.
        I/O at 0x1080 [0x10bf].
    Bus  0, device  16, function  0:
      Multimedia video controller: Brooktree Corporation Bt878 (rev 17).
        IRQ 11.
        Master Capable.  Latency=66.  Min Gnt=16.Max Lat=40.
        Prefetchable 32 bit memory at 0x48200000 [0x48200fff].
    Bus  0, device  16, function  1:
      Multimedia controller: Brooktree Corporation Bt878 (rev 17).
        IRQ 11.
        Master Capable.  Latency=66.  Min Gnt=4.Max Lat=255.
        Prefetchable 32 bit memory at 0x48300000 [0x48300fff].
    Bus  0, device  20, function  0:
      ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).
    Bus  0, device  20, function  1:
      IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1).
        Master Capable.  Latency=64.
        I/O at 0x1040 [0x104f].
    Bus  0, device  20, function  2:
      USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).
        IRQ 11.
        Master Capable.  Latency=64.
        I/O at 0x1020 [0x103f].
    Bus  0, device  20, function  3:
      Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2).
        IRQ 9.
    Bus  1, device   0, function  0:
      VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 130).
        IRQ 11.
        Master Capable.  Latency=64.  Min Gnt=16.Max Lat=32.
        Prefetchable 32 bit memory at 0x42000000 [0x43ffffff].
        Non-prefetchable 32 bit memory at 0x40800000 [0x40803fff].
        Non-prefetchable 32 bit memory at 0x40000000 [0x407fffff].

/proc/cpuinfo:

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

/proc/interrupts:

    0:    1337585          XT-PIC  timer
    1:      46916          XT-PIC  keyboard
    2:          0          XT-PIC  cascade
    8:          1          XT-PIC  rtc
   11:     162990          XT-PIC  es1371, bttv, eth0
   12:     294331          XT-PIC  PS/2 Mouse
   14:      21839          XT-PIC  ide0
   15:         17          XT-PIC  ide1
NMI:          0
ERR:          0


Kristian

·· · · reach me :: · ·· ·· ·  · ·· · ··  · ··· · ·
                           :: http://www.korseby.net
                           :: http://www.tomlab.de
kristian@korseby.net ....::

Re: massive filesystem corruption with 2.4.9

[Christian Widmer]

>  > If your disk is in UDMA33/66 mode you can pretty rule the 
>  > disk out as the data is protected
i think this should be with the promise driver.

>  > If you have a VIA chipset, especially if there is an SB Live! in the
>  > machine then that may be the cause (fixes in 2.4.8-ac, should be a fix
>  > in 2.4.9 but Linus tree also applies another bogus change but which
>  > should be harmless)
it was an intel LX chipset

that it is a memory problem i also don't belive. that ram work for over 2 year
with no errors found with memtest (memtset86, intels memtest) compiling
seveal times xfree86 and an many many times several kernels. 

and i never had any problems. until i tried the first time a 2.4.x kernel on 
the fileserver (that was 2.4.6). so i moved the fileserver back to 2.2.19.

Re: i810 audio doesn't work with 2.4.9

[Alan Cox]

> i810 audio didn't work for me with kernel 2.4.9 (artsd from KDE goes into infinite loop, no sound). 
> 
> Reverting to kernel 2.4.7 or replacing in 2.4.9 drivers/sound/ac97_codec.c, drivers/sound/i810_audio.c, 
> include/linux/ac97_codec.h from 2.4.8-ac8 fixed the problem for me

Thats good to know - the 2.4.8-ac8 one is scheduled to go to Linus

Re: i810 audio doesn't work with 2.4.9

[Jeff Chua]

it works for me on 2.4.9.


Thanks,
Jeff
[ jchua@fedex.com ]

On Tue, 21 Aug 2001, Alan Cox wrote:

> > i810 audio didn't work for me with kernel 2.4.9 (artsd from KDE goes into infinite loop, no sound).
> >
> > Reverting to kernel 2.4.7 or replacing in 2.4.9 drivers/sound/ac97_codec.c, drivers/sound/i810_audio.c,
> > include/linux/ac97_codec.h from 2.4.8-ac8 fixed the problem for me
>
> Thats good to know - the 2.4.8-ac8 one is scheduled to go to Linus
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: i810 audio doesn't work with 2.4.9

[Andris Pavenis]

On Tuesday 21 August 2001 16:59, Alan Cox wrote:
> > i810 audio didn't work for me with kernel 2.4.9 (artsd from KDE goes into
> > infinite loop, no sound).
> >
> > Reverting to kernel 2.4.7 or replacing in 2.4.9
> > drivers/sound/ac97_codec.c, drivers/sound/i810_audio.c,
> > include/linux/ac97_codec.h from 2.4.8-ac8 fixed the problem for me
>
> Thats good to know - the 2.4.8-ac8 one is scheduled to go to Linus

Sorry, my fault:

seems that i810_audio.c  from 2.4.7 and 2.4.8 works, but both from 2.4.9 and
2.4.8-ac8 does not ("suceeded" not to copy right version of this file when
testing previous time, so had one from 2.4.7 twice)

Andris

---------- corresponding line from /proc/pci ------------------------
  Bus  0, device  31, function  5:
    Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio (rev 2).
      IRQ 10.
      I/O at 0xe000 [0xe0ff].
      I/O at 0xe100 [0xe13f].

---------  corresponding lines from kernel messages
i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, IRQ 10
ac97_codec: AC97 Audio codec, id: 0x4144:0x5348 (Analog Devices AD1881A)

Re: i810 audio doesn't work with 2.4.9

[Doug Ledford]

Andris Pavenis wrote:

> Sorry, my fault:
> 
> seems that i810_audio.c  from 2.4.7 and 2.4.8 works, but both from 2.4.9 and
> 2.4.8-ac8 does not ("suceeded" not to copy right version of this file when
> testing previous time, so had one from 2.4.7 twice)

(hmmm, what changes went into 2.4.9 kernel for this driver, I haven't 
looked?)

So, Alan, I noticed that in the same ac kernel that you applied my 
updates, you also applied some OSS correctness patch from somewhere.  I 
think someone sent you a bogus patch.  I've fixed this problem with 
artsd once before.  My latest patch didn't touch the GETOSPACE code, and 
obviously that's where this problem with artsd comes from, so my patch 
wasn't it.  I haven't seen this other patch, but at least the GETOSPACE 
changes need to be trashed.



-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: Qlogic/FC firmware

[Alan Cox]

> You might as well remove all of these drivers in whole, as they are
> basically non-functional without the accompanying firmware.

Now you are talking complete and total crap. I tested this firmware removal
stuff on a QlogicFC 2100 card. It works fine and I am now getting to use
the qualified firmware in the BIOS flash not the unqualified firmware in
the kernel.

Alan

Re: Qlogic/FC firmware

[Alan Cox]

> In many cases the driver worked before, and fails to work afterwards.
> I still contend that the whole driver should have been lifted
> instead of leaving a crippled version there.

Well now you know how everyone feels about the min() and max() changes.

However I _did_ test this, you can update the firmware in your BIOS flash
if you want a specific version and you have out of date firmwre currently
loaded.

Alan

Re: Qlogic/FC firmware

[Alan Cox]

> When the Qlogic,FC sees a master abort, the firmware is essentially
> cleared to zero.

None of the cards I have do this. Is this some kind of sparc specific
firmware problem ?

> If you're going to say "put the user thing in initrd", I'm going to
> say "bite me".  I build a static kernel with no initrd and that is how
> I'd like it to stay.  It is one thing to do initrd firmware loading
> for devices not necessary for booting and mounting root, that is
> acceptable, this isn't.

Why. What exactly is your argument ? Lets waste 128K of kernel space to keep
Dave happy. If the lack of proper boot time init on the sparc64 platform is
causing more problems then copy the firmware image out of the BIOS into the
card if sparc64 is defined.

And an initrd is the right answer. You free up the 128K of wasted space
using it.

Alan

Re: Qlogic/FC firmware

[Alexander Viro]

On Tue, 21 Aug 2001, Alan Cox wrote:

> Why. What exactly is your argument ? Lets waste 128K of kernel space to keep
> Dave happy. If the lack of proper boot time init on the sparc64 platform is
> causing more problems then copy the firmware image out of the BIOS into the
> card if sparc64 is defined.
> 
> And an initrd is the right answer. You free up the 128K of wasted space
> using it.

initrd is the right answer to question "where can I find shitty code?"

Now, having firmware loaded from userland _is_ nice and sane, but we
need something better than initrd for that.

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 15:17:25 +0100 (BST)
   
   However I _did_ test this, you can update the firmware in your BIOS flash
   if you want a specific version and you have out of date firmwre currently
   loaded.

There is no BIOS flash on my machines (onboard controllers).  The
kernel driver must be where the firmware comes from to boot reliably.

You broke this driver on all of my systems having QLogic,FC onboard.
The next time I powercycle or there is a PCI master abort on that bus
segment, I will be without a bootable machine.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 15:15:20 +0100 (BST)

   > You might as well remove all of these drivers in whole, as they are
   > basically non-functional without the accompanying firmware.
   
   Now you are talking complete and total crap. I tested this firmware removal
   stuff on a QlogicFC 2100 card. It works fine

It works fine in your x86-centric world, on your x86 BIOS card.
It breaks on every UltraSparc system I have with qlogic,fc onboard.
One powercycle or PCI master abort, and I am unbootable.

And I am the one talking crap? :-)

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Rik van Riel]

On Tue, 21 Aug 2001, David S. Miller wrote:

> And I am the one talking crap? :-)

"All the world's a SPARC"

I guess using an initrd on these 0.3% of machines shouldn't
be too big a problem compared to violating the GPL and adding
to kernel bloat for everybody else.

cheers,

Rik
--
IA64: a worthy successor to i860.

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Qlogic/FC firmware

[Alan Cox]

> I guess using an initrd on these 0.3% of machines shouldn't
> be too big a problem compared to violating the GPL and adding
> to kernel bloat for everybody else.

The license thing is a side issue. We have a sane relationship with Qlogic
so that can easily be dealt with. For 2.5 it definitely wants to be in
initrd-tng however

Re: Qlogic/FC firmware

[christophe barbé]

Le mar, 21 aoû 2001 17:30:46, Alan Cox a écrit :
> > I guess using an initrd on these 0.3% of machines shouldn't
> > be too big a problem compared to violating the GPL and adding
> > to kernel bloat for everybody else.
> 
> The license thing is a side issue. We have a sane relationship with
> Qlogic
> so that can easily be dealt with. For 2.5 it definitely wants to be in
> initrd-tng however

I'm afraid that I don't understand what you mean by "a sane relationship
with Qlogic".
If the relation between kernel hackers and qlogic is good, why we don't
have an uptodate firmware with IP support and without license issue ?

The initial reason behind the firmware drop was the license.
And now it's a waste of RAM.

A few times ago, Dmitry (I don't remember his name but If you want I can
find it) has proposed an update for this driver including twos uptodate
firmware (with and without IP support). He give us a link to a website to
upload his patches ( http://www.datafoundation.org/qlogicfc/ ) but now the
link is broken.
If you are interresting I should be able to find his patch on an old disk.

This update resolves nearly all my problems with the in-kernel one.

And IIRC the included firmwares has no BSD license (no license at all
IIRC).

Christophe

-- 
Christophe Barbé
Software Engineer - christophe.barbe@lineo.fr
Lineo France - 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
http://www.lineo.com

Re: Qlogic/FC firmware

[Ricky Beam]

On Tue, 21 Aug 2001, Rik van Riel wrote:
>I guess using an initrd on these 0.3% of machines shouldn't
>be too big a problem

Were's the initrd going to get the firmware?  It's not in the freakin' tree
anymore.  If I have to go download a firmware image and stick it in an
initrd, why the hell wouldn't I just plug it directly into the kernel?
It's *my* kernel.

> compared to violating the GPL

Oh for the love of God, will you people stop drooling over the fucking GPL?
It's *firmware*... it's just a bunch of bits.  It's *not* a program the
kernel executes.  It's just data. (__init_data to be exact.)

> and adding
>to kernel bloat for everybody else.

One man's bloat is another man's functionality.  Besides, it's got a hell of
a lot of company.  Ask yourself, will you miss 128_K_ in a machine with a
fiber channel card in it?  It "bloats" the kernel for people using that
hardware -- machines that don't need it can release it.

--Ricky

(If Sun would get off their ass(es) and support firewire, I'd stop using linux
 all together.  And before some smartass says they do, point to the ohci and
 sbp-2 drivers on the Solaris 8 Sparc CD.)

Re: Qlogic/FC firmware

[Alan Cox]

> Were's the initrd going to get the firmware?  It's not in the freakin' tree
> anymore.  If I have to go download a firmware image and stick it in an
> initrd, why the hell wouldn't I just plug it directly into the kernel?
> It's *my* kernel.

Well initrd is _user_ space so it probably gets them from user space tools.

> Oh for the love of God, will you people stop drooling over the fucking GPL?
> It's *firmware*... it's just a bunch of bits.  It's *not* a program the
> kernel executes.  It's just data. (__init_data to be exact.)

Look, if its not distributable then its no good to anyone.

> a lot of company.  Ask yourself, will you miss 128_K_ in a machine with a
> fiber channel card in it?  It "bloats" the kernel for people using that
> hardware -- machines that don't need it can release it.

Well maybe, and whats the right way to do that, oh my god I do believe its
an initrd.

Well well well

Alan

Re: Qlogic/FC firmware

[Ricky Beam]

On Tue, 21 Aug 2001, Alan Cox wrote:
>Look, if its not distributable then its no good to anyone.

Who said it wasn't distributable?  The license in the 2.4.5 file doesn't say
you cannot distribute it.  It doesn't even prevent you from sell it.  You have
to leave the notice intact and not use it as a means to attach the Qlogic
mark to any derived product.

Other than it's age, I see *zero* reason to remove it from the tree.

>Well maybe, and whats the right way to do that, oh my god I do believe its
>an initrd.

__init_data

--Ricky

Re: Qlogic/FC firmware

[Alan Cox]

> On Tue, 21 Aug 2001, Alan Cox wrote:
> >Look, if its not distributable then its no good to anyone.
> 
> Who said it wasn't distributable?  The license in the 2.4.5 file doesn't say
> you cannot distribute it.  It doesn't even prevent you from sell it.  You have
> to leave the notice intact and not use it as a means to attach the Qlogic
> mark to any derived product.

 * 2. Redistribution in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.

Which is a problem because the kernel is GPL, that isnt GPL compatible
and until this was pointed out nobody has been going to print their blurb
in all the manuals - because after all it says GPL.

Licenses cannot be ignored. If I merge non GPL compliant code I'm doing to
the contributors to the kernel the very same thing people pirating windows
do to microsoft. 

> Other than it's age, I see *zero* reason to remove it from the tree.

Well let me quote from it again

/*
 *     W     W     A     RRRR    N   N   IIIII   N   N    GGG
 *     W     W    A A    R   R   N   N     I     N   N   G   G
 *     W     W   A   A   R  R    NN  N     I     NN  N   G  
 *     W  W  W   AAAAA   RRR     N N N     I     N N N   G  GG
 *     W  W  W   A   A   R R     N  NN     I     N  NN   G   G
 *     W W W W   A   A   R  R    N   N     I     N   N   G   G
 *      W   W    A   A   R   R   N   N   IIIII   N   N    GGGG
 *
 *         This version of firmware is a release candidate,
 *     design verification testing (DVT) has not been completed.
 */

or in simple terms "might lose all your data"

> >Well maybe, and whats the right way to do that, oh my god I do believe its
> >an initrd.
> 
> __init_data

Doesnt work in modules. See previous twice repeated discussion. 

As Matthew has noted, we have a source of newer firmware, and because the
sparc's have this annoying firmware problem it is going to be appropriate
to add build in firmware as a config option (probably set with def_bool on
sparc..)

At the time a) I didnt realise the sparc setup was so anal, and b) I didnt
know about the firmware update.

Alan

Re: Qlogic/FC firmware

[Matthew Jacob]

> > Other than it's age, I see *zero* reason to remove it from the tree.
>
> Well let me quote from it again
>
> /*
>  *     W     W     A     RRRR    N   N   IIIII   N   N    GGG
>  *     W     W    A A    R   R   N   N     I     N   N   G   G
>  *     W     W   A   A   R  R    NN  N     I     NN  N   G
>  *     W  W  W   AAAAA   RRR     N N N     I     N N N   G  GG
>  *     W  W  W   A   A   R R     N  NN     I     N  NN   G   G
>  *     W W W W   A   A   R  R    N   N     I     N   N   G   G
>  *      W   W    A   A   R   R   N   N   IIIII   N   N    GGGG
>  *
>  *         This version of firmware is a release candidate,
>  *     design verification testing (DVT) has not been completed.
>  */
>
> or in simple terms "might lose all your data"

Take this with a grain of salt. It's true that it hasn't passed DVT. But it's
also true that f/w which *has* passed DVT has eaten your data as well.

Almost precisely by definition, if the system you embed this firmware in is
*not* one that has gone thru Qlogic DVT, you should in fact be putting the
warning on yourself.

>
> > >Well maybe, and whats the right way to do that, oh my god I do believe its
> > >an initrd.
> >
> > __init_data
>
> Doesnt work in modules. See previous twice repeated discussion.
>
> As Matthew has noted, we have a source of newer firmware, and because the
> sparc's have this annoying firmware problem it is going to be appropriate
> to add build in firmware as a config option (probably set with def_bool on
> sparc..)
>
> At the time a) I didnt realise the sparc setup was so anal, and b) I didnt
> know about the firmware update.
>

It's not just a question of having firmware updated into flash- which, btw,
companies like Veritas have shied away from getting custoemrs to do because
you *do* have a small but finite amount of risk updating flash. It's also code
that as yet has to be written for qlogicfc (e.g.) that would pull it *out* of
flash so it can be pushed into SRAM (which is what the BIOS code on other
platforms do).

-matt

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "Matthew" == Matthew Jacob <mjacob@feral.com> writes:

Matthew> It's not just a question of having firmware updated into
Matthew> flash- which, btw, companies like Veritas have shied away
Matthew> from getting custoemrs to do because you *do* have a small
Matthew> but finite amount of risk updating flash. It's also code that
Matthew> as yet has to be written for qlogicfc (e.g.) that would pull
Matthew> it *out* of flash so it can be pushed into SRAM (which is
Matthew> what the BIOS code on other platforms do).

Yeah vendors tend to like this idea, it's not just Veritas and QLogic
who went down this path, unfortunately.

Updating the flash does seem very easy, and the good thing about the
QLA adapters is that you can reflash even if you screwed up in the
first place. Yup I tried that ;) Writing the flash utility seems like
a piece of cake in this as well. What doesn't look as easy is to
figure out that directory structure of the firmware images ;-( Any
chance you got some data on that?

Cheers,
Jes

Re: Qlogic/FC firmware

[Matthew Jacob]

> >>>>> "Matthew" == Matthew Jacob <mjacob@feral.com> writes:
>
> Matthew> It's not just a question of having firmware updated into
> Matthew> flash- which, btw, companies like Veritas have shied away
> Matthew> from getting custoemrs to do because you *do* have a small
> Matthew> but finite amount of risk updating flash. It's also code that
> Matthew> as yet has to be written for qlogicfc (e.g.) that would pull
> Matthew> it *out* of flash so it can be pushed into SRAM (which is
> Matthew> what the BIOS code on other platforms do).
>
> Yeah vendors tend to like this idea, it's not just Veritas and QLogic
> who went down this path, unfortunately.
>
> Updating the flash does seem very easy, and the good thing about the QLA
> adapters is that you can reflash even if you screwed up in the first
> place. Yup I tried that ;) Writing the flash utility seems like a piece of
> cake in this as well. What doesn't look as easy is to figure out that
> directory structure of the firmware images ;-( Any chance you got some
> data on that?

There are x86 utilities from Qlogic to *write* the flash. Reading the flash
isn't that hard itself. There is no documentation as to flash layout. Older
versions of the Linux driver say where they keep a copy of the current target
to WWN mapping in flash (which is a 'maybe not so bright' idea).

We could ask them where it is.

-matt

Re: Qlogic/FC firmware

[Matthew Jacob]

> We could ask them where it is.

I've asked their tech support folks about where and how big in flash the RISC
code is for all their cards. I have other people I can ask too. Let's see if
they're helpful or open about it.

I'm not as sensitive to the bloat issues as I should be- I suppose because I
tend to see all of USB as bloat myself :).. I tend to think that the generic
shipping kernel case should have all of the firmware images there to download
from the driver.

That said, it *would* be nice to give people some tools to strip things down
if they really want, out of a 2GB system, a couple hundred kbytes back that
can the be gobbled up by something really hungry for it like a memory leak in
X or Matzohilla or something :-)....

-matt

Re: Qlogic/FC firmware

[David S. Miller]

   From: Matthew Jacob <mjacob@feral.com>
   Date: Wed, 22 Aug 2001 09:17:07 -0700 (PDT)

   Matzohilla

You're such a nebbish Matt. :-)

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Ricky Beam]

On Wed, 22 Aug 2001, Alan Cox wrote:
> * 2. Redistribution in binary form must reproduce the above copyright
> *    notice, this list of conditions and the following disclaimer in the
> *    documentation and/or other materials provided with the distribution.
>
>Which is a problem because the kernel is GPL, that isnt GPL compatible
>and until this was pointed out nobody has been going to print their blurb
>in all the manuals - because after all it says GPL.

The kernel source counts as "other materials".

>> Other than it's age, I see *zero* reason to remove it from the tree.
>
>Well let me quote from it again
...
>or in simple terms "might lose all your data"

Gee.  And how many installation have been running that firmware for how
many years without problems?  As I said before, other than it's age, there's
no reason to simply delete it.

>Doesnt work in modules. See previous twice repeated discussion.

We aren't talking about a module when it's compiled into the kernel.  In
the case(s) of modules, there are many ways to provide data (such as
firmware) without the aforementioned bloat everyone wants to bitch about.
And I'd like to point out the people screaming about bloat do not have
the hardware for which this driver is required and thusly will *never*
lose the coveted 128K for it's firmware.  There are areas of "bloat" with
far further reach than this.  Go get a few thousand signatures from actual
Qlogic FC owners running linux oking your destablization of the driver and
I'll leave this alone.  Otherwise, either delete the driver entirely or
put the firmware for which the driver is designed and proven stable by the
test of time back in the tree.

This is the 2.4 "stable" kernel tree.  One would assume people work towards
*increasing* it's stability by fixing its flaws, not wildly deleting shit
and (possibly) randomly breaking things. (But I digress.  I'm treading into
the abyss of source/configuration management of which the kernel tree has
none.)

>As Matthew has noted, we have a source of newer firmware, and because the
>sparc's have this annoying firmware problem it is going to be appropriate
>to add build in firmware as a config option (probably set with def_bool on
>sparc..)

As I recall, the Qlogic ISP driver has had a similar option for years.
(Maybe not to prevent compilation but certainly to prevent loading it.)

>At the time a) I didnt realise the sparc setup was so anal, and b) I didnt
>know about the firmware update.

So basically, you had no fucking clue what kind of instability you were about
to introduce into the current "stable" line of kernels, but did it anyway
simply because of the wording (and your interpretation thereof) of the license
on a firmware "data" file.  Wording that has been unchanged since the day
the file was entered into the tree.  If there were objections, questions,
or other concerns, they should have been raised then and not months or years
later.  And there should have been at least some discussion before removing
the file and seeing who notices. (If I missed this discussion, then I
apologize.)

--Ricky

Re: Qlogic/FC firmware

[Alan Cox]

> We aren't talking about a module when it's compiled into the kernel.  In
> the case(s) of modules, there are many ways to provide data (such as
> firmware) without the aforementioned bloat everyone wants to bitch about.

Like loading it from user space. Which is exactly the same code needed
for an initrd. Amazing isn it.

> And I'd like to point out the people screaming about bloat do not have
> the hardware for which this driver is required and thusly will *never*

Wrong. I object to wasting 128K and I have fibrechannel. Its that kind of
sloppy "who cares about 128K" thinking that leads to several megs
disappearing and your OS turning into sludge. 

> So basically, you had no fucking clue what kind of instability you were about
> to introduce into the current "stable" line of kernels, but did it anyway

It caused a trivial little problem for a few sparc people which basically has 
only been more than a

	"Hey Alan, sparc needs firmware compiled in can you fix"

because it seems you have to be arrogant and opinionated to own a sparc64
box 8)

> the file was entered into the tree.  If there were objections, questions,
> or other concerns, they should have been raised then and not months or years
> later.  And there should have been at least some discussion before removing

Take that one up with Linus. I didn't merge it originally

Alan

Re: Qlogic/FC firmware

[Ricky Beam]

On Wed, 22 Aug 2001, Alan Cox wrote:
>Like loading it from user space. Which is exactly the same code needed
>for an initrd. Amazing isn it.

Amazing *and* unnecessarily complex.  What a bargin!  And it's still going
to consume that precious 128K even when loaded from usersapce as the driver
will still need to keep it.  And aren't you one of the Preists of Text in
/proc -- those of the belief in managing everything with 'cat' and 'vi'.

>Wrong. I object to wasting 128K and I have fibrechannel. Its that kind of
>sloppy "who cares about 128K" thinking that leads to several megs
>disappearing and your OS turning into sludge.

Way too damn late make that argument.  That snowball has been gaining mass
and speed for years now.  I would not recommend standing in front of it.

>> So basically, you had no fucking clue what kind of instability you were about
>> to introduce into the current "stable" line of kernels, but did it anyway
>
>It caused a trivial little problem for a few sparc people which basically has
>only been more than a
>
>	"Hey Alan, sparc needs firmware compiled in can you fix"
>
>because it seems you have to be arrogant and opinionated to own a sparc64
>box 8)

I stand by my original "fucking" comment :-)  I wouldn't trivialize this
"little problem".  I'm guessing this is a problem for Alphas as well.  Altho'
Digital (now Compaq) doesn't call it a Qlogic,FC -- their naming scheme is
on par with Cisco -- it doesn't have any firmware on the card.  SRM loads
firmware on it to scan for devices.  Having a machine randomly crash for no
easily detectable reason (esp. if you log to FC) is not good.  In fact,
one may not notice the problem for some time.

Dave, what kind of messages does a master abort cause?

>> the file was entered into the tree.  If there were objections, questions,
>> or other concerns, they should have been raised then and not months or years
>> later.  And there should have been at least some discussion before removing
>
>Take that one up with Linus. I didn't merge it originally

No, you take it up with Linus (and the Qlogic maintainer) as you are the nut
removing it ... and introducing a great big question mark around the stability
of the Qlogic FC driver.

--Ricky

Re: Qlogic/FC firmware

[Alan Cox]

> Amazing *and* unnecessarily complex.  What a bargin!  And it's still going
> to consume that precious 128K even when loaded from usersapce as the driver
> will still need to keep it.  And aren't you one of the Preists of Text in

No. We can jettison it and you know that in fact you commented on using 
__initdata in the non modular case, so stop trolling and if you are going to
be a pain, at least be consistant in your arguments. 

> /proc -- those of the belief in managing everything with 'cat' and 'vi'.

No. That would be Al Viro. 

> >sloppy "who cares about 128K" thinking that leads to several megs
> >disappearing and your OS turning into sludge.
> 
> Way too damn late make that argument.  That snowball has been gaining mass
> and speed for years now.  I would not recommend standing in front of it.

If I was working on Irix maybe, but I'm not. I've got another .5Mb on my
256Mb box I want back in 2.5 as well 8)

> "little problem".  I'm guessing this is a problem for Alphas as well.  Altho'

Alpha's have x86 emulation in the boot loaders. Thats a not-nice solution to
most of the PC worlds evils but works out.

> >Take that one up with Linus. I didn't merge it originally
> 
> No, you take it up with Linus (and the Qlogic maintainer) as you are the nut
> removing it ... and introducing a great big question mark around the stability
> of the Qlogic FC driver.

See previous four conversations on this. Licensing matters. 

Case closed

Alan

Re: Qlogic/FC firmware

[Ricky Beam]

On Wed, 22 Aug 2001, Alan Cox wrote:
>> Amazing *and* unnecessarily complex.  What a bargin!  And it's still going
>> to consume that precious 128K even when loaded from usersapce as the driver
>> will still need to keep it.  And aren't you one of the Preists of Text in
>
>No. We can jettison it and you know that in fact you commented on using
>__initdata in the non modular case, so stop trolling and if you are going to
>be a pain, at least be consistant in your arguments.

I'm missing the "in the case of sparc" clause.  The sparc (and maybe others?)
have to keep the firmware image in memory in the case that it needs to reload
the sequencer.  The initrd simply adds more tool-chains to keep up-to-date.
Any distribution supporting the Qlogic,FC will have to supply a firmware file
in binary form to initialize the card.  And then you're right back to square
one in the binary distribution arena.

--Ricky

Re: Qlogic/FC firmware

[Alan Cox]

> I'm missing the "in the case of sparc" clause.  The sparc (and maybe others?)
> have to keep the firmware image in memory in the case that it needs to reload

Read the source code. The driver never reloads the firmware on a running
card. So if the sparc needed that it never worked anyway, and I don't follow
your argument.

If you do need to reload the firmware on real live sparc setups after driver
setup then someone needs to do some patching.

Unlike you, I actually read the source

Alan

Re: Qlogic/FC firmware

[Ricky Beam]

On Wed, 22 Aug 2001, Alan Cox wrote:
>Read the source code. The driver never reloads the firmware on a running
>card. So if the sparc needed that it never worked anyway, and I don't follow
>your argument.

If the card wasn't setup by the BIOS (OBP in the Sparc case), then the driver
won't work.  And as late as 2.4.8, RELOAD_FIRMWARE was set to '1'.  Gee,
look what was changed in 2.4.9:

--- v2.4.8/linux/drivers/scsi/qlogicfc.c        Sun Aug 12 13:28:00 2001
+++ linux/drivers/scsi/qlogicfc.c       Sun Aug 12 10:51:41 2001
@@ -98,7 +98,7 @@
    isp2200's firmware.
 */

-#define RELOAD_FIRMWARE                1
+#define RELOAD_FIRMWARE                0

 #define USE_NVRAM_DEFAULTS      1

@@ -440,7 +440,7 @@
 #define MBOX_SEND_CHANGE_REQUEST        0x0070
 #define MBOX_PORT_LOGOUT                0x0071

-#include "qlogicfc_asm.c"
+//#include "qlogicfc_asm.c"

(I will note, that's not even a valid C construct. '//' is a C++ism.)

>Unlike you, I actually read the source

So, was that before or after you removed the firmware? (And who says I don't
read source code?  That's the first place I go to find out who fucked up
what.  I'm running 2.4.5 and below.  The only thing I have running 2.4.9 is
my laptop, and that was a certified nightmare.)

--Ricky

Re: Qlogic/FC firmware

[Alan Cox]

> -#include "qlogicfc_asm.c"
> +//#include "qlogicfc_asm.c"
> 
> (I will note, that's not even a valid C construct. '//' is a C++ism.)

Your C standard is as out of date as your architecture ;)

Re: Qlogic/FC firmware

[David S. Miller]

   From: Ricky Beam <jfbeam@bluetopia.net>
   Date: Wed, 22 Aug 2001 14:46:27 -0400 (EDT)

   On Wed, 22 Aug 2001, Alan Cox wrote:
   >Read the source code. The driver never reloads the firmware on a running
   >card. So if the sparc needed that it never worked anyway, and I don't follow
   >your argument.
   
   If the card wasn't setup by the BIOS (OBP in the Sparc case), then the driver
   won't work.  And as late as 2.4.8, RELOAD_FIRMWARE was set to '1'.  Gee,
   look what was changed in 2.4.9:
   
Please read what people are saying.

He said "running card"  Which means that it does not handle the
PCI master case on a running system, which I never claimed it did.

The older code does guarentee that if I did powercycle and reboot
at that point, I will get a functional card back, which the current
code does not do.

Alan's actively trying to resolve this problem by getting usable
firmware from Qlogic.  What are you doing to improve the situation
besides trolling like made on this list?

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "Ricky" == Ricky Beam <jfbeam@bluetopia.net> writes:

Ricky> On Wed, 22 Aug 2001, Alan Cox wrote:
>>> the file was entered into the tree.  If there were objections,
>>> questions, or other concerns, they should have been raised then
>>> and not months or years later.  And there should have been at
>>> least some discussion before removing
>>  Take that one up with Linus. I didn't merge it originally

Ricky> No, you take it up with Linus (and the Qlogic maintainer) as
Ricky> you are the nut removing it ... and introducing a great big
Ricky> question mark around the stability of the Qlogic FC driver.

*plonk*

Jes

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "Ricky" == Ricky Beam <jfbeam@bluetopia.net> writes:

Ricky> On Wed, 22 Aug 2001, Alan Cox wrote:
>> At the time a) I didnt realise the sparc setup was so anal, and b)
>> I didnt know about the firmware update.

Ricky> So basically, you had no fucking clue what kind of instability
Ricky> you were about to introduce into the current "stable" line of
Ricky> kernels, but did it anyway simply because of the wording (and
Ricky> your interpretation thereof) of the license on a firmware
Ricky> "data" file.  Wording that has been unchanged since the day the
Ricky> file was entered into the tree.  If there were objections,
Ricky> questions, or other concerns, they should have been raised then
Ricky> and not months or years later.  And there should have been at
Ricky> least some discussion before removing the file and seeing who
Ricky> notices. (If I missed this discussion, then I apologize.)

Wording as interpreted by lawyers and anybody who is capable of
reading English.

As to your argument about raising the concerns when the thing went
in. We (as in the kernel developers) made a mistake, we noticed it we
fix it ... see it's really that simple.

Jes

Re: Qlogic/FC firmware

[Rik van Riel]

On Wed, 22 Aug 2001, Ricky Beam wrote:

> So basically, you had no fucking clue

Since you're the expert, why won't we all wait for
YOUR patch to fix the problem? ;)

Rik
--
IA64: a worthy successor to i860.

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Qlogic/FC firmware

[Oliver Neukum]

> > Oh for the love of God, will you people stop drooling over the fucking
> > GPL? It's *firmware*... it's just a bunch of bits.  It's *not* a program
> > the kernel executes.  It's just data. (__init_data to be exact.)
>
> Look, if its not distributable then its no good to anyone.

Are you allowed to distribute an initrd that contains it, build from it and 
GNU tools ?

	Regards
		Oliver

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "Oliver" == Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de> writes:

>> > Oh for the love of God, will you people stop drooling over the
>> fucking > GPL? It's *firmware*... it's just a bunch of bits.  It's
>> *not* a program > the kernel executes.  It's just
>> data. (__init_data to be exact.)
>> 
>> Look, if its not distributable then its no good to anyone.

Oliver> Are you allowed to distribute an initrd that contains it,
Oliver> build from it and GNU tools ?

If you don't violate any of the licenses of the apps you stick on the
initrd. The fact you use GNU tools to build the initrd doesn't really
matter.

The problem with including this in the kernel is that the kernel as a
whole is GPL'ed so including something that is in conflict with the
GPL is kinda problematic.

Cheers
Jes

Re: Qlogic/FC firmware

[Ricky Beam]

On Wed, 22 Aug 2001, Oliver Neukum wrote:
>> > Oh for the love of God, will you people stop drooling over the fucking
>> > GPL? It's *firmware*... it's just a bunch of bits.  It's *not* a program
>> > the kernel executes.  It's just data. (__init_data to be exact.)
>>
>> Look, if its not distributable then its no good to anyone.
>
>Are you allowed to distribute an initrd that contains it, build from it and
>GNU tools ?

Depends on who's interpreting the license.  I say as long as the source to
the whole mess is available (even provided *with* the binaries), you aren't
violating anything.  On the otherhand, strictly speaking, once the file
is compiled, it becomes "in binary form" which needs the notice attached to
it in some way -- like all the fine print one finds on any box of stuff from
Sun, Compaq/Digital, Cisco, etc.

However, as others have said, none of us are lawyers.  Of course, none of us
have been sued by Qlogic either.

--Ricky

Re: Qlogic/FC firmware

[Matthew Jacob]

> --Ricky
>
> (If Sun would get off their ass(es) and support firewire, I'd stop using linux
>  all together.  And before some smartass says they do, point to the ohci and
>  sbp-2 drivers on the Solaris 8 Sparc CD.)

Oh-yeah- the ones that cause panics when attached to USB multiport terminal
switch hubs?

Re: Qlogic/FC firmware

[Ricky Beam]

On Tue, 21 Aug 2001, Matthew Jacob wrote:
>Oh-yeah- the ones that cause panics when attached to USB multiport terminal
>switch hubs?

No, the non-existant ieee1394 (firewire) ones.  I refuse to by Sun hardware
with IDE and USB capability.

--Ricky

Re: Qlogic/FC firmware

[David S. Miller]

   From: Ricky Beam <jfbeam@bluetopia.net>
   Date: Tue, 21 Aug 2001 18:45:02 -0400 (EDT)
   
Re: GPL  It's a source file and it had a copyright at the top.
Regardless of what the contents mean, the copyright the author
put there has to be abided by.

   (If Sun would get off their ass(es) and support firewire, I'd stop using linux
    all together.  And before some smartass says they do, point to the ohci and
    sbp-2 drivers on the Solaris 8 Sparc CD.)

I normally chastise Sun just to get my jollies off, but this
is a too much of an untrue statement about them even for me
to tolerate.

Solaris-8 supports fully the ieee1394 interfaces on Ultra-III
machines just fine.  I don't know what the package name is, but
the kernel drivers are there in the SME hw releases done for
the Ultra-III.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[David S. Miller]

   From: Rik van Riel <riel@conectiva.com.br>
   Date: Tue, 21 Aug 2001 11:42:11 -0300 (BRST)
   
   I guess using an initrd on these 0.3% of machines shouldn't
   be too big a problem compared to violating the GPL and adding
   to kernel bloat for everybody else.

init_data the firmware, it isn't bloat.

The copyright is a totally seperate issue.

Later,
David S. Miller
davem@redhat.com
   

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 15:24:17 +0100 (BST)

   > When the Qlogic,FC sees a master abort, the firmware is essentially
   > cleared to zero.
   
   None of the cards I have do this. Is this some kind of sparc specific
   firmware problem ?

Without x86 BIOS this is the situation you will get.

Unless you tell the firmware to probe all scsi devices at the OBP
command line, there is no firmware loaded into the FC card.  There
is no reason for firmware to get loaded onto the card.

So if I boot kernels from the Symbios scsi device and use a disk
on my qlogic,fc as root, I am fucked after my next power cycle.
This is exactly my setup on one of my systems.
   
What other non-x86 systems trying to use QLogic/FC cards as root?
Such as PPC.  There is nothing wrong or stupid about this, and such
systems have been broken by removing the firmware.

   Why. What exactly is your argument ? Lets waste 128K of kernel space to keep
   Dave happy. If the lack of proper boot time init on the sparc64 platform is
   causing more problems then copy the firmware image out of the BIOS into the
   card if sparc64 is defined.
   
That would require that I know where in the forth image Sun
sticks the firmware, I have no way to figure this out except
by toiling over disassembler dumps of the cards firmware.

I have no guarentees even that this is where it is (in the PCI
ROM of the qlogic,fc card) they could have just as well have stuffed
it into some arbitrary place in the main system forth ROM.

   And an initrd is the right answer. You free up the 128K of wasted space
   using it.
   
I'd rather have 128k of wasted space than an unbootable system.

All of Matt Jacob's drivers include all the firmware.  And this
makes a lot of sense for another reason, QA.  If you know what
firmware rev. everyone is using, you don't have to second guess
bug reports by asking "oh and what firmware did the BIOS load onto
your card btw" each time.

Nobody, and I mean nobody, except Linux has a Qlogic,FC kernel driver
that fails to load a known version of the firmware.

Also, "128k of wasted space" is a bogus argument too.  If you
build it statically into the kernel, __init_data the firmware.
And when we have the initmem stuff working for modules again (Jakub
did this years ago) you'll get it free'd up for the non-static case
too.   Fix the problem, not a symptom.

If you had put something like "This driver removed due to copyright
problems" into qlogicfc.c then I would have had no problems.

But to see only the firmware disappear almost looked like a careless
merge error.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Alan Cox]

> There is no BIOS flash on my machines (onboard controllers).  The
> kernel driver must be where the firmware comes from to boot reliably.

Ok so you have a sparc specific firmware loading problem. So IMHO the
right thing to do is to write a sparc specific firmware loader - either
as a module living in arch/sparc64 or assuming you never need to reload
the firmware past boot - use an initrd

For the other 99.9% of the userbase we saved 128Kbytes of ram and improved
reliability by not loading half tested firmeware on them.

Alan

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 15:45:26 +0100 (BST)
   
   For the other 99.9% of the userbase we saved 128Kbytes of ram and improved
   reliability by not loading half tested firmeware on them.

We saved nothing, __init_data the firmware, problem solved.

If the firmware was out of date, update it to a known "Qlogic stamp of
approval" version.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 15:45:26 +0100 (BST)
   
   Ok so you have a sparc specific firmware loading problem.

No, it is a non-x86 firmware loading problem.  Do not label
it is as a "all the world a Sparc" problem, it isn't centric
to any particular platform.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "David" == David S Miller <davem@redhat.com> writes:

David>    From: Alan Cox <alan@lxorguk.ukuu.org.uk> Date: Tue, 21 Aug
David> 2001 15:45:26 +0100 (BST)
   
>    Ok so you have a sparc specific firmware loading problem.

David> No, it is a non-x86 firmware loading problem.  Do not label it
David> is as a "all the world a Sparc" problem, it isn't centric to
David> any particular platform.

It's centric to a limited userbase, other systems such as Alpha and
ia64 can load the firmware off the cards no problem.

Doesn't mean we have solved your problem, true. But initrd is still a
cleaner solution and gets around the licensing problem as well.

Jes

Re: Qlogic/FC firmware

[Alan Cox]

> We saved nothing, __init_data the firmware, problem solved.

Except when its modular, as in 99% of distro kernels

> If the firmware was out of date, update it to a known "Qlogic stamp of
> approval" version.

That requires sorting licensing out with Qlogic. I've talked to them
usefully about other stuff so I'll pursue it for a seperate firmware
loader module.

Alan

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> If the firmware was out of date, update it to a known "Qlogic stamp
>> of approval" version.

Alan> That requires sorting licensing out with Qlogic. I've talked to
Alan> them usefully about other stuff so I'll pursue it for a seperate
Alan> firmware loader module.

Well getting firmware out of them tends to be up and down.

However I just looked through the QLogic v4.27 provided driver from
their web site and it does in fact included firmware with a GPL
license.

Dave, if you want to play with this and stick it into the qlogicfc.c
driver then you will at least have something that sorta works for now
(module all the other problems with that driver).

http://www.qlogic.com/bbs-html/csg_web/adapter_pages/driver_pages/22xx/22linux.html

They do have a stupid 'read and agree' license in front of that page
if you go in via the official qlogic.com door, however if the code
inside is GPL then I asume it's GPL.

Cheers
Jes

Re: Qlogic/FC firmware

[Alan Cox]

> 
> >>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> >> If the firmware was out of date, update it to a known "Qlogic stamp
> >> of approval" version.
> 
> Alan> That requires sorting licensing out with Qlogic. I've talked to
> Alan> them usefully about other stuff so I'll pursue it for a seperate
> Alan> firmware loader module.
> 
> Well getting firmware out of them tends to be up and down.
> 
> However I just looked through the QLogic v4.27 provided driver from
> their web site and it does in fact included firmware with a GPL
> license.
> 
> Dave, if you want to play with this and stick it into the qlogicfc.c
> driver then you will at least have something that sorta works for now
> (module all the other problems with that driver).
> 
> http://www.qlogic.com/bbs-html/csg_web/adapter_pages/driver_pages/22xx/22linux.html
> 
> They do have a stupid 'read and agree' license in front of that page
> if you go in via the official qlogic.com door, however if the code
> inside is GPL then I asume it's GPL.
> 
> Cheers
> Jes
> 

Re: Qlogic/FC firmware

[Matthew Jacob]

On Tue, 21 Aug 2001, Alan Cox wrote:

> >
> > >>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> >
> > >> If the firmware was out of date, update it to a known "Qlogic stamp
> > >> of approval" version.
> >
> > Alan> That requires sorting licensing out with Qlogic. I've talked to
> > Alan> them usefully about other stuff so I'll pursue it for a seperate
> > Alan> firmware loader module.
> >
> > Well getting firmware out of them tends to be up and down.
> >
> > However I just looked through the QLogic v4.27 provided driver from
> > their web site and it does in fact included firmware with a GPL
> > license.

Interesting- I should have checked- they didn't use to have GPL on the f/w.
Earlier driver versions didn't! Oops!

-matt

Re: Qlogic/FC firmware

[Matthew Jacob]

>
> Interesting- I should have checked- they didn't use to have GPL on the f/w.
> Earlier driver versions didn't! Oops!
>

Actually, it's not quite. The 2200 f/w has:

/************************************************************************
 *                                                                      *
 *               --- ISP2200 Initiator/Target Firmware ---              *
 *             with Fabric (Public Loop), Point-point, and              *
 *             expanded LUN addressing for FCTAPE                       *
 *                                                                      *
 ************************************************************************
  Copyright (C) 2000 and 2100 Qlogic Corporation
  (www.qlogic.com)

  This program is distributed in the hope that it will be useful, but
  WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  General Public License for more details.
*******************************************************************
/*
 *      Firmware Version 2.01.27 (11:07 Dec 18, 2000)
 */

(you should  note, btw, that the f/w that's on the internal QLogic website for
OEMS is 2.1.26)

So, it's *sort of* GPLd....

-matt

Re: Qlogic/FC firmware

[Alan Cox]

> However I just looked through the QLogic v4.27 provided driver from
> their web site and it does in fact included firmware with a GPL
> license.

Yep. How has getting them to take updates to their 'official driver' been
going btw

Alan

Re: Qlogic/FC firmware

[David S. Miller]

   From: Jes Sorensen <jes@sunsite.dk>
   Date: 21 Aug 2001 18:39:04 +0200
   
   Dave, if you want to play with this and stick it into the qlogicfc.c

None of this topic matters at all for me.  I
just cvs co -date foo qlogicfc_asm.c and edit
qlogicfc.c to include and use it again :-)

It's more important for others people.

If the firmware you point to is indeed suitably licensed, we should
put it into the tree.  If what you're asking me to do is take care
of this, no problem.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Matthew Jacob]

A few of pieces of information and comments:

The "BSD" copyright in the f/w I have from QLogic is there only because Theo
Deraadt threatened to pull QLogic from the 2.7 OpenBSD release. I'd been
pleading with them for over a year to do *something*. I should have done a BSD
license w/o the advert clause, but, oh, well.....

To understand what shape you're in, it's really best to load firmware into the
card's SRAM. That way you *know* it understands feature foo (like SCCLUN, for
example). QLogic produces so many different flavors of firmware of the same
nominal revision that it's hard to deduce the viability or safety of some
firmware.

That said, it *is* possible in a non-BIOS environment to pull firmware out of
flash rom, I believe- you have to do some hand strobing of registers that
normally only the firmware touches, but I think it *is* technically possible
to pull the contents of flash out into system memory, figure out where the
'resident' f/w image is in this goop and then download *that* into SRAM and
restart the sequencer. Still- this leaves you in the same position as before.

IMO, the best thing is to do an ispfw load module that goes away after you've
loaded SRAM. I've started down this path in FreeBSD (there's a separate ispfw
module)- which will only be really useful if module memory ever gets reclaimed
in FreeBSD :-). This is of particular importance for my driver, because in
supporting 1020 (SBus (yes for NetBSD/OpenBSD, not yet for Linux)  && PCI),
1080/1280 Ultra2, 12160 Ultra3, 2100 FC, 2200FC and 2300FC (next week)- you
end up with an absurd amount of f/w images.

I'm sure there's something similar that can be done for Linux.

Alan- you say you can talk to QLogic- good. I've been finding it harder and
harder to talk to them. If you can get them to put out 2100 and 2200 and 2300
f/w with GPL for Linux- great.

-matt

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "David" == David S Miller <davem@redhat.com> writes:

David> If the firmware you point to is indeed suitably licensed, we
David> should put it into the tree.  If what you're asking me to do is
David> take care of this, no problem.

Well I was offering you a solution to your problem. Whether you want
to take it or not is really up to you. I can live with the driver not
shipping any firmware image, but it sounds like Sparc users can't.

Jes

Re: BUG: pc_keyb.c

[Alan Cox]

> On the other hand, 1 ms is a very long time these days; it is a bit
> surprising that modern hardware should need delays in that order of

I have two boxes that need the 1mS delay, and I actually had to fix a 
missing one to deal with hangs. So its still there, lurking in some boxes
I've had ex Digital engineers confirm the hinote needs the 1mS delay a while
back

Alan

Re: massive filesystem corruption with 2.4.9

[Alan Cox]

> No. I can't find any VIA chipset. I'm really surprised. :-) But it is a=
> n
> original Compaq-Board (EP-Series..) with a horroble BIOS. It seems that=
>  they're
> using intel only..

440BX - good chipset.

Does memtest86 show up anything on this box ?

Re: massive filesystem corruption with 2.4.9

[Kristian]

Alan Cox wrote:
> Does memtest86 show up anything on this box ?

No errors...

Btw: As far as I know did the problem occur since I patched 2.4.5 with ac13 or 
ac15. Maybe a clean 2.4.5 works fine. I'm not sure about this. It's some time 
ago... Did you have made some important ext2-related changes with 2.4.5-ac?. I 
could revert to the old kernel and test him if it is relevant.

Kristian

·· · · reach me :: · ·· ·· ·  · ·· · ··  · ··· · ·
                          :: http://www.korseby.net
                          :: http://www.tomlab.de
kristian@korseby.net ....::

Re: massive filesystem corruption with 2.4.9

[Alan Cox]

> that it is a memory problem i also don't belive. that ram work for over 2 year
> with no errors found with memtest (memtset86, intels memtest) compiling
> seveal times xfree86 and an many many times several kernels. 
> 
> and i never had any problems. until i tried the first time a 2.4.x kernel on 
> the fileserver (that was 2.4.6). so i moved the fileserver back to 2.2.19.

Nod. I can follow that reasoning, I've come across boxes that fialed with
2.4 with memory errors, but not 2.2. So far however those have all shown up
with memtest86, or been Athlon optimisation triggered via things

Curiouser and curiouser

Re: Kernel Startup Delay

[Alan Cox]

> to have a delayed spin up as to not bake the power supply.  These two drives
> will contain a striping RAID.  I am concerned that the kernel will load off
> of the other drives and attempt to start this RAID before the disks have
> even spun up - is there a way to have the kernel delay its startup for a
> certain number of seconds while all the drives spin up?

The kernel scsi code issues test-unit-ready commands and will (should 8)) do
the right things and wait for the drives to spin up. 

Alan

Re: i810 audio doesn't work with 2.4.9

[Alan Cox]

> (hmmm, what changes went into 2.4.9 kernel for this driver, I haven't 
> looked?)

2.4.9 has an obsolete driver

Re: i810 audio doesn't work with 2.4.9

[Alan Cox]

> seems that i810_audio.c  from 2.4.7 and 2.4.8 works, but both from 2.4.9 and
> 2.4.8-ac8 does not ("suceeded" not to copy right version of this file when
> testing previous time, so had one from 2.4.7 twice)

Ok I'll take a glance at that. An strace of artsd failing would be useful

Re: i810 audio doesn't work with 2.4.9

[Andris Pavenis]

On Tuesday 21 August 2001 21:39, Alan Cox wrote:
> > seems that i810_audio.c  from 2.4.7 and 2.4.8 works, but both from 2.4.9
> > and 2.4.8-ac8 does not ("suceeded" not to copy right version of this file
> > when testing previous time, so had one from 2.4.7 twice)
>
> Ok I'll take a glance at that. An strace of artsd failing would be useful

I'm including that at end of this message (a small fragment only):

Some other info:

Got incremental diffs between ac versions since 2.4.5.
Applied all diffs to 2.4.5 version of i810_audio.c except one between 2.4.6-ac1 and 2.4.6-ac2
As result i810 audio seems to work

So it seems that update of i810_audio.c between 2.4.6-ac1 and ac2 breaks it (at least for me).
But I think it still eating too much time (about 2-3% on PIII 700) when I'm not doing anything 
with sound but no more up to 90% as with unmodified version from 2.4.9 (maybe it's a problem
of artsd , I don't know)

Andris

---------------------------- i810_audio.c from 2.4.9  ----------------------------------------------------

09:22:28.328650 select(9, [4 6], [8], [6 8], {0, 119135}) = 1 (out [8], left {0, 120000})
09:22:28.328935 ioctl(8, SNDCTL_DSP_GETOSPACE, 0xbffff5ec) = 0
09:22:28.328984 write(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 608) = 96
09:22:28.329071 gettimeofday({998374948, 329087}, NULL) = 0
09:22:28.329116 gettimeofday({998374948, 329132}, NULL) = 0
09:22:28.329161 select(9, [4 6], [8], [6 8], {0, 118624}) = 1 (out [8], left {0, 120000})
09:22:28.329401 ioctl(8, SNDCTL_DSP_GETOSPACE, 0xbffff5ec) = 0
09:22:28.329450 write(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 592) = 80
09:22:28.329537 gettimeofday({998374948, 329553}, NULL) = 0
09:22:28.329582 gettimeofday({998374948, 329599}, NULL) = 0
09:22:28.329628 select(9, [4 6], [8], [6 8], {0, 118157}) = 1 (out [8], left {0, 120000})
09:22:28.329912 ioctl(8, SNDCTL_DSP_GETOSPACE, 0xbffff5ec) = 0
09:22:28.329964 write(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 608) = 96
09:22:28.330051 gettimeofday({998374948, 330067}, NULL) = 0
09:22:28.330096 gettimeofday({998374948, 330113}, NULL) = 0
09:22:28.330142 select(9, [4 6], [8], [6 8], {0, 117643}) = 1 (out [8], left {0, 120000})
09:22:28.330428 ioctl(8, SNDCTL_DSP_GETOSPACE, 0xbffff5ec) = 0
09:22:28.330476 write(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 600) = 88
09:22:28.330562 gettimeofday({998374948, 330579}, NULL) = 0
09:22:28.330607 gettimeofday({998374948, 330624}, NULL) = 0

------------------------   2.4.9 with i810_audio.c without patch between 2.4.6-ac1 to ac2  ------------------------------
 
11:38:04.550692 select(9, [4 6], [8], [6 8], {0, 87578}) = 1 (out [8], left {0, 90000})
11:38:04.550973 ioctl(8, SNDCTL_DSP_GETOSPACE, 0xbffff41c) = 0
11:38:04.551025 write(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
11:38:04.551116 gettimeofday({998469484, 551134}, NULL) = 0
11:38:04.551162 gettimeofday({998469484, 551180}, NULL) = 0
11:38:04.551207 select(9, [4 6], [8], [6 8], {0, 87062}) = 1 (out [8], left {0, 90000})
11:38:04.551488 ioctl(8, SNDCTL_DSP_GETOSPACE, 0xbffff41c) = 0
11:38:04.551540 write(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
11:38:04.551631 gettimeofday({998469484, 551648}, NULL) = 0
11:38:04.551676 gettimeofday({998469484, 551694}, NULL) = 0
11:38:04.551722 select(9, [4 6], [8], [6 8], {0, 86548}) = 1 (out [8], left {0, 90000})
11:38:04.552003 ioctl(8, SNDCTL_DSP_GETOSPACE, 0xbffff41c) = 0
11:38:04.552054 write(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
11:38:04.552146 gettimeofday({998469484, 552163}, NULL) = 0
11:38:04.552191 gettimeofday({998469484, 552209}, NULL) = 0
11:38:04.552236 select(9, [4 6], [8], [6 8], {0, 86033}) = 1 (out [8], left {0, 90000})
11:38:04.552518 ioctl(8, SNDCTL_DSP_GETOSPACE, 0xbffff41c) = 0
11:38:04.552569 write(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
11:38:04.552658 gettimeofday({998469484, 552676}, NULL) = 0
11:38:04.552703 gettimeofday({998469484, 552721}, NULL) = 0
11:38:04.552749 select(9, [4 6], [8], [6 8], {0, 85521}) = 1 (out [8], left {0, 90000})
11:38:04.553030 ioctl(8, SNDCTL_DSP_GETOSPACE, 0xbffff41c) = 0
11:38:04.553078 write(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 560) = 560
11:38:04.553166 gettimeofday({998469484, 553184}, NULL) = 0
11:38:04.553212 gettimeofday({998469484, 553230}, NULL) = 0
11:38:04.553258 select(9, [4 6], [8], [6 8], {0, 85012}) = 1 (out [8], left {0, 80000})

Re: i810 audio doesn't work with 2.4.9

[Doug Ledford]

Andris Pavenis wrote:

> Got incremental diffs between ac versions since 2.4.5.
> Applied all diffs to 2.4.5 version of i810_audio.c except one between 2.4.6-ac1 and 2.4.6-ac2
> As result i810 audio seems to work

Can you send me that incremental patch you left out.  I would like to 
look at it to see what's going on.

> So it seems that update of i810_audio.c between 2.4.6-ac1 and ac2 breaks it (at least for me).
> But I think it still eating too much time (about 2-3% on PIII 700) when I'm not doing anything 
> with sound but no more up to 90% as with unmodified version from 2.4.9 (maybe it's a problem
> of artsd , I don't know)


Yes, it's a problem of artsd.  Someone decided (presumably to avoid the 
occasional pop/click from the startup or shutdown of the sound device) 
to make artsd transmit silence over the sound card when no sounds 
currently need played.  From my perspective, I will *NEVER* use artsd as 
long as it does this.  I find it so extremely stupid and insane to a 
level that can't be measured that I refuse to run that software.  I 
absolutely will not have my systems PCI bus loaded down with a constant 
data transfer when there is no sound to be played.  Right now, that's 
possibly something as small as a 48KHz/16bit data stream.  But what if 
the system is upgraded to an ac3 5.1 digital system.  Then you would 
have something like 384KByte/s of data to transfer over the PCI bus just 
for frickin silence.  Won't ever happen on any machine I use.  Anyone 
trying to do things like disk benchmarks on a system that runs artsd may 
be suprised to find their performance is actually negatively impacted 
just by having that horrible sound daemon running.  Furthermore, I find 
their use of the sound API to be suboptimal, especially when they are 
going to transmit silence all the time.  I am *FAR* happier with the way 
esd actually handles its interaction with the sound card (other issues 
are a different matter, I don't rightly know which one does better sound 
sample upconversion for instance).


-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: i810 audio doesn't work with 2.4.9

[Andris Pavenis]

On Thursday 23 August 2001 17:00, Doug Ledford wrote:
> Andris Pavenis wrote:
> > Got incremental diffs between ac versions since 2.4.5.
> > Applied all diffs to 2.4.5 version of i810_audio.c except one between
> > 2.4.6-ac1 and 2.4.6-ac2 As result i810 audio seems to work
>
> Can you send me that incremental patch you left out.  I would like to
> look at it to see what's going on.
>

i810_audio.c works for me if all patches except following is aplied (it's a part of update
from 2.4.6-ac1 to 2.4.6-ac2)

Andris

--- linux-2.4.6-ac1/drivers/sound/i810_audio.c	Sun Jul  8 20:45:41 2001
+++ linux-2.4.6-ac2/drivers/sound/i810_audio.c	Sun Jul  8 21:37:01 2001
@@ -1209,23 +1211,30 @@
 		if (dmabuf->count < 0) {
 			dmabuf->count = 0;
 		}
-		cnt = dmabuf->dmasize - swptr;
-		if(cnt > (dmabuf->dmasize - dmabuf->count))
-			cnt = dmabuf->dmasize - dmabuf->count;
+		cnt = dmabuf->dmasize - dmabuf->fragsize - dmabuf->count;
+		// this is to make the copy_from_user simpler below
+		if(cnt > (dmabuf->dmasize - swptr))
+			cnt = dmabuf->dmasize - swptr;
 		spin_unlock_irqrestore(&state->card->lock, flags);
 
+#ifdef DEBUG2
+		printk(KERN_INFO "i810_audio: i810_write: %d bytes available space\n", cnt);
+#endif
 		if (cnt > count)
 			cnt = count;
 		if (cnt <= 0) {
 			unsigned long tmo;
 			// There is data waiting to be played
-			i810_update_lvi(state,0);
 			if(!dmabuf->enable && dmabuf->count) {
 				/* force the starting incase SETTRIGGER has been used */
 				/* to stop it, otherwise this is a deadlock situation */
 				dmabuf->trigger |= PCM_ENABLE_OUTPUT;
 				start_dac(state);
 			}
+			// Update the LVI pointer in case we have already
+			// written data in this syscall and are just waiting
+			// on the tail bit of data
+			i810_update_lvi(state,0);
 			if (file->f_flags & O_NONBLOCK) {
 				if (!ret) ret = -EAGAIN;
 				return ret;

Re: i810 audio doesn't work with 2.4.9

[Doug Ledford]

Andris Pavenis wrote:
> On Thursday 23 August 2001 17:00, Doug Ledford wrote:
> 
>>Andris Pavenis wrote:
>>
>>>Got incremental diffs between ac versions since 2.4.5.
>>>Applied all diffs to 2.4.5 version of i810_audio.c except one between
>>>2.4.6-ac1 and 2.4.6-ac2 As result i810 audio seems to work
>>>
>>Can you send me that incremental patch you left out.  I would like to
>>look at it to see what's going on.
>>
>>
> 
> i810_audio.c works for me if all patches except following is aplied (it's a part of update
> from 2.4.6-ac1 to 2.4.6-ac2)

[snip]

OK, now I know what is going on.  The change you reference was added to 
the i810 driver because some software (mpg123) could fall behind to the 
point that they drained the buffer, then when they refilled it 
(according to the value sent by the GETOSPACE ioctl), it would cause the 
LVI == CVI and the i810 chipset would essentially stop playing.  This 
made it so that we would wait for the LVI != CVI before we wrote all the 
data into the buffer.  Unfortunately, because artsd in particular opens 
the file in non-blocking mode, we only write as much data as is allowed 
before we hit the simplistic "always write actual space - fragsize bytes 
to avoid the LVI == CVI lockup" issue.  Therefore, artsd would check the 
GETOSPACE ioctl, try to write that amount of data, the write routine 
doesn't write the full amount because of the workaround, we return less 
than a full write, artsd immediately tries to write more, we get in an 
endless loop that wastes lots of CPU cycles.  I'll improve the free 
space calculation and then implement it in both the write and GETOSPACE 
areas so that the return from GETOSPACE is in fact the amount of data we 
will allow to be written.  That will solve the problem for both the 
artsd and the mpg123 cases. (I'll likewise have to do something similar 
with read and GETISPACE, and I'll have to verify that GETOPTR and 
GETIPTR are going to work properly with the new scheme as well).  Once 
that's done, I'll send a 0.05 version of the driver to Alan.




-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: 2.4.9 kernel i810 module Initialization problem

[Alan Cox]

>  I was using the i810 module for APG video (2.4.7 kernel) with no problems. 
> After installation of the 2.4.9 kernel the module failed to initialize. 

Linus updated the kernel supporting code for direct rendering to require
XFree 4.1. If you want to use a current kernel with the older XFree 4.0.x
then pick up the 2.4.8-ac tree instead, and use the DRM 4.0 option

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[Alan Cox]

> Try -ac Kernels with integrated PNPBIOS and "lspnp -v",
> then you will see your "motherboard resources". No magic.

Except on the intel boards where your machine crashes, the vaio's where
some queries corrupt memory, the boxes where an interrupt during a pnpbios
call crashes the box, the machines where pnpbios called from both cpus at
the same time is a crash case, the wonderful weird tiny races on some boxes
that use smm traps and fail if random undefined things occur between the
two out instructions...

> Alan, 2.4 would largely benefit from PNPBIOS, do you plan
> to submit this to LT (probably with the proposed life saver fix) ?

Experience is that PnpBIOS services are so astoundingly buggy in many
bioses that they are probably not worth the risk. Ie more boxes break by
calling pnpbios than by assuming the vendor used a sane resource layout.

Before PnPBIOS can go mainstream we'd have to generate a detailed list
of buggy bios signatures

Alan

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[Gunther Mayer]

Alan Cox wrote:
> 
> > Try -ac Kernels with integrated PNPBIOS and "lspnp -v",
> > then you will see your "motherboard resources". No magic.
> 
> Except on the intel boards where your machine crashes, the vaio's where
> some queries corrupt memory, the boxes where an interrupt during a pnpbios
> call crashes the box, the machines where pnpbios called from both cpus at
> the same time is a crash case, the wonderful weird tiny races on some boxes
> that use smm traps and fail if random undefined things occur between the
> two out instructions...

So call it only once early on boot (in real mode) and save the table
for later use (we don't need the fancy features ...) ?

> > Alan, 2.4 would largely benefit from PNPBIOS, do you plan
> > to submit this to LT (probably with the proposed life saver fix) ?
> 
> Experience is that PnpBIOS services are so astoundingly buggy in many
> bioses that they are probably not worth the risk. Ie more boxes break by
> calling pnpbios than by assuming the vendor used a sane resource layout.

How are these bugs handled by Windows ?
Must we only mimick the Windows call layout to
enter bios-writer's well tested code path ?

> Before PnPBIOS can go mainstream we'd have to generate a detailed list
> of buggy bios signatures

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[Gerd Knorr]

On Wed, Aug 22, 2001 at 07:18:20PM +0100, Alan Cox wrote:
> > Try -ac Kernels with integrated PNPBIOS and "lspnp -v",
> > then you will see your "motherboard resources". No magic.
> 
> Except on the intel boards [ ... bios bugs list snipped ... ] 

2.4.8-ac8 works for me, and lspnp does list these "obscure"
ressources:

bytesex kraxel ~# /root/bin/lspnp -v
00 PNP0c01 memory controller: RAM
        mem 0x00000000-0x0009ffff
        mem 0x00100000-0x0bfdffff
        mem 0x0bfe0000-0x0bfeffff
        mem 0x000e0000-0x000fffff
        mem 0xffff0000-0xffffffff
        io 0x0398-0x0399
        io 0x0024-0x003d
        io 0x0062-0x0062
        io 0x0066-0x0066
        io 0x0090-0x009f
        io 0x00a4-0x00bd
        io 0x0230-0x0233
        io 0x1000-0x103f
        io 0x1400-0x140f
        io 0x3810-0x381f

01 PNP0c02 reserved: other
        io 0x0cf8-0x0cff
        io 0x04d0-0x04d1

02 PNP0c04 system peripheral: other
        irq 13
        io 0x00f0-0x00ff

03 PNP0000 system peripheral: programmable interrupt controller
[ ... more standard PC hardware follows ... ]

But it seems they are _not_ reserved by the pnp bios code, at least they
are not listed in /proc/ioports

> Before PnPBIOS can go mainstream we'd have to generate a detailed list
> of buggy bios signatures

Why?  It shouldn't harm if disabled, so IMHO it should be fine when
flagged "experimental" and with a warning label about broken bioses in
Configure.help ...

  Gerd

-- 
Damn lot people confuse usability and eye-candy.

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[Gerd Knorr]

>  But it seems they are _not_ reserved by the pnp bios code, at least they
>  are not listed in /proc/ioports

I've hacked up a small piece of code which does the ressource
registering:

----------------- cut here ------------------
#include <linux/config.h>
#include <linux/module.h>
#include <linux/init.h>

#include <asm/io.h>
#include <asm/dma.h>
#include <asm/uaccess.h>

#include <linux/pnp_bios.h>

static void register_stuff(struct pci_dev *dev)
{
	struct resource *res;
	int i;

	for (i = 0; i < DEVICE_COUNT_RESOURCE &&
		    (dev->resource[i].start || dev->resource[i].end); i++) {
		if (dev->resource[i].start <= 0xffff) {
			res = request_region(dev->resource[i].start,
				dev->resource[i].end - dev->resource[i].start,
				dev->name);
			printk("mboard: alloc io: 0x%04lx-0x%04lx [%s,%s]\n",
				dev->resource[i].start,
				dev->resource[i].end,
				dev->name, res ? "ok" : "failed");
		}
	}
	if (i == DEVICE_COUNT_RESOURCE)
		printk("mboard: warning: >= %d resources\n",
			DEVICE_COUNT_RESOURCE);
}

static int mboard_init(void)
{
	struct pci_dev *dev;
	int found;

	dev = NULL;
	found = 0;
	while ((dev=pnpbios_find_device("PNP0c01",dev))) {
		register_stuff(dev);
		found++;
	}
	if (found)
		MOD_INC_USE_COUNT;
	return 0;
}

static void mboard_fini(void)
{
}

module_init(mboard_init);
module_exit(mboard_fini);

----------------- cut here ------------------

A full patch with this + pnpbios support (pulled out of -ac) for 2.4.9
is available from http://bytesex.org/notebook/pnpbios-2.4.9.diff

Now I have this in my /proc/ioports:
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
0090-009f : PNPBIOS
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
0230-0233 : PNPBIOS
02f8-02ff : nsc-ircc
0398-0399 : PNPBIOS
03c0-03df : vesafb
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1000-103f : PNPBIOS
1100-110f : Intel Corporation 82440MX EIDE Controller
  1100-1107 : ide0
1200-121f : Intel Corporation 82440MX USB Universal Host Controller
  1200-121f : usb-uhci
1400-140f : PNPBIOS
1500-153f : Intel Corporation 82440MX AC'97 Audio Controller
  1500-153f : Intel 440MX
1600-16ff : Intel Corporation 82440MX AC'97 Audio Controller
  1600-16ff : Intel 440MX
1700-177f : PCI device 8086:7196 (Intel Corporation)
1800-18ff : PCI device 8086:7196 (Intel Corporation)
1c00-1cff : PCI CardBus #01
2000-20ff : PCI CardBus #01
3000-30ff : ATI Technologies Inc 3D Rage P/M Mobility
3810-381f : PNPBIOS
3e00-3eff : Realtek Semiconductor Co., Ltd. RTL-8139
  3e00-3eff : 8139too

Note that DEVICE_COUNT_RESOURCE == 12 is too small to hold all the
resources, so I've bumped that to 16.

  Gerd

-- 
Damn lot people confuse usability and eye-candy.

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[Alan Cox]

> > Before PnPBIOS can go mainstream we'd have to generate a detailed list
> > of buggy bios signatures
> 
> Why?  It shouldn't harm if disabled, so IMHO it should be fine when
> flagged "experimental" and with a warning label about broken bioses in
> Configure.help ...

We will see what happens. Certainly if someone wants to provide pnpbios code
patches for -ac that grab and reserve the motherboard resources from the PCI
code go ahead.

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[kuznet]

Hello!

> We will see what happens. Certainly if someone wants to provide pnpbios code
> patches for -ac that grab and reserve the motherboard resources from the PCI
> code go ahead.

Khm... this does not look simple. Seems, right way involves modification
of each place, where the same ports are used by kernel.
pcmcia-cs had completely private resource manager, so that it just
did not worry about other subsystems and they still were able to allocate
the same resources.

Look f.e. at extermal example, pnpbios announces as "system" resource
all the memory. :-)

Pallaitive soultions, sort of reserving of ports >= 0x1000 using
this information do not look cool too. 

Alexey

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[Gunther Mayer]

kuznet@ms2.inr.ac.ru wrote:
> 
> Hello!
> 
> > We will see what happens. Certainly if someone wants to provide pnpbios code
> > patches for -ac that grab and reserve the motherboard resources from the PCI
> > code go ahead.
> 
> Khm... this does not look simple. Seems, right way involves modification
> of each place, where the same ports are used by kernel.

The PNP0C01 ports are not used by the kernel !
No modifications necessary.

Of course you can teach each driver about their PNP devices, e.g.
my patch for parport_pc.c makes perfect io/irq/dma detection and
saves users from the error-prone procedure to supply module parameters.
Even serial now autodetects IRQ 10 when I give this in my BIOS setup !

> pcmcia-cs had completely private resource manager, so that it just
> did not worry about other subsystems and they still were able to allocate
> the same resources.
> 
> Look f.e. at extermal example, pnpbios announces as "system" resource
> all the memory. :-)

So we have another way besides several INTs to detect the avail mem :-)

> 
> Pallaitive soultions, sort of reserving of ports >= 0x1000 using
> this information do not look cool too.

Gerd's patch rules out your objections and should be included
unconditionally with pnpbios.o.

Probably PNP0C02 wants to be reserved, too.

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[kuznet]

Hello!

> So we have another way besides several INTs to detect the avail mem :-)

Well, if this memory is available then I guess port 0x1000 is "available"
as well and all the rest of ports are not available. :-)

No, something is rotted in this kingdom.


> Probably PNP0C02 wants to be reserved, too.

What's about these, they are nice port and could be used by our irq handler.
According to docs they replace functionality missing in standard
int. controller ports for this chipset.

What's about passing parameters from bios setup to linux...
This is amusing, but not more. I am sorry, I still prefer to use usual
kernel command line instead of some ugly foreign interface.

Alexey

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[Gunther Mayer]

kuznet@ms2.inr.ac.ru wrote:
> 
> Hello!
> 
> > So we have another way besides several INTs to detect the avail mem :-)
> 
> Well, if this memory is available then I guess port 0x1000 is "available"
> as well and all the rest of ports are not available. :-)

Read "available" as "onboard".
Before you use onboard resources you should know what it is !
Surely you don't want to place a PCI ioport window over unknown ports
(as this is what yenta did).

> No, something is rotted in this kingdom.
> 
> > Probably PNP0C02 wants to be reserved, too.
> 
> What's about these, they are nice port and could be used by our irq handler.

These ports are not nice here and should not be user by the irq handler:
   	PNP0c02 Motherboard resources
        io 0x0290-0x0297

> According to docs they replace functionality missing in standard
> int. controller ports for this chipset.

What docs ?

> 
> What's about passing parameters from bios setup to linux...

The BIOS setup uses PNPBIOS to pass parameters to Linux :-)

> This is amusing, but not more. I am sorry, I still prefer to use usual
> kernel command line instead of some ugly foreign interface.

You miss the point of PNP and user-friendliness.

This is a necessary interface to prevent (nearly undebuggable) linux hard hangs !

However, Gerd's debugging forces and his new patch already solve this thread
by giving a working solution.

-
Gunther

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[kuznet]

Hello!

> Before you use onboard resources you should know what it is !
> Surely you don't want to place a PCI ioport window over unknown ports
> (as this is what yenta did).

This is right.

Though, to make situation more clean explain me one much simpler thing:
look at these lines from beginning of my lspnp -v:

00 PNP0c01 System board
        mem 0x00000000-0x0009ffff
        mem 0x00100000-0x0bfdffff
        mem 0x0bfe0000-0x0bfeffff
        mem 0x000e0000-0x000fffff
        mem 0xffff0000-0xffffffff

Look at line mem 0x0bfe0000-0x0bfeffff. I hope you never saw this
motherboard before, like this happens with our poor kernel,
so you are not in better position. Imagine, you are kernel,
and decide are you allowed to use these 64K or not? :-)

Additional information: bios-e820 reports this area as ram in one block
with all the rest of memory 0x00100000-0x0bfeffff.


> What docs ?

Intel datashits from developer.intel.com.

Alexey

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[Gerd Knorr]

On Thu, Aug 23, 2001 at 02:00:35PM +0100, Alan Cox wrote:
> We will see what happens. Certainly if someone wants to provide pnpbios code
> patches for -ac that grab and reserve the motherboard resources from the PCI
> code go ahead.

Here is.

  Gerd

---------------------- cut here -------------------------
--- 2.4.8-ac8/include/linux/pci.h.fix	Fri Aug 24 11:40:14 2001
+++ 2.4.8-ac8/include/linux/pci.h	Fri Aug 24 11:40:28 2001
@@ -317,7 +317,7 @@
 #define DEVICE_COUNT_COMPATIBLE	4
 #define DEVICE_COUNT_IRQ	2
 #define DEVICE_COUNT_DMA	2
-#define DEVICE_COUNT_RESOURCE	12
+#define DEVICE_COUNT_RESOURCE	16
 
 #define PCI_ANY_ID (~0)
 
--- 2.4.8-ac8/drivers/pnp/Makefile.fix	Thu Aug 23 10:08:57 2001
+++ 2.4.8-ac8/drivers/pnp/Makefile	Fri Aug 24 11:47:27 2001
@@ -17,7 +17,7 @@
 isa-pnp-objs := isapnp.o quirks.o $(proc-y)
 
 procpnp-$(CONFIG_PROC_FS) = pnp_proc.o
-pnpbios-objs := pnp_bios.o  $(procpnp-y)
+pnpbios-objs := pnp_bios.o mboard.o $(procpnp-y)
 
 obj-$(CONFIG_ISAPNP) += isa-pnp.o
 obj-$(CONFIG_PNPBIOS) += pnpbios.o
--- 2.4.8-ac8/drivers/pnp/pnp_bios.c.fix	Thu Aug 23 10:08:57 2001
+++ 2.4.8-ac8/drivers/pnp/pnp_bios.c	Fri Aug 24 11:39:21 2001
@@ -49,6 +49,7 @@
 
 void pnp_proc_init(void);
 static void pnpbios_build_devlist(void);
+int pnpbios_request_mboard(void);
 
 /*
  * This is the standard structure used to identify the entry point
@@ -605,6 +606,7 @@
 		break;
 	}
 	pnpbios_build_devlist();
+	pnpbios_request_mboard();
 #ifdef CONFIG_PROC_FS
 	pnp_proc_init();
 #endif
--- 2.4.8-ac8/drivers/pnp/mboard.c.fix	Fri Aug 24 11:39:50 2001
+++ 2.4.8-ac8/drivers/pnp/mboard.c	Fri Aug 24 11:38:38 2001
@@ -0,0 +1,73 @@
+/*
+ * request I/O ports which are used according to the PnP BIOS.
+ *
+ * (c) 2001 Gerd Knorr <kraxel@bytesex.org>
+ */
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/init.h>
+
+#include <asm/io.h>
+#include <asm/dma.h>
+#include <asm/uaccess.h>
+
+#include <linux/pnp_bios.h>
+
+static int request_stuff(char *pnp, struct pci_dev *dev)
+{
+	struct resource *res;
+	int i,count = 0;
+
+	printk(KERN_INFO "%s: request ports [%s]:",dev->name,pnp);
+	for (i = 0; i < DEVICE_COUNT_RESOURCE &&
+		    (dev->resource[i].start || dev->resource[i].end); i++) {
+		if (dev->resource[i].start > 0xffff ||
+		    dev->resource[i].end   > 0xffff) {
+			/*
+			 * these are memory ressources -- ignore them.
+			 * The PnP BIOS reports the main memory layout
+			 * this way.
+			 */
+			continue;
+		}
+		if (dev->resource[i].end < 0x100) {
+			/*
+			 * below 0x100 is only standard PC hardware
+			 * (pics, kbd, timer, dma, ...)
+			 *
+			 * We should not get ressource conflicts there,
+			 * and the kernel reserves these anyway
+			 * (see arch/i386/kernel/setup.c).
+			 */
+			continue;
+		}
+		/*
+		 * anything else we'll reserve to avoid these ranges are
+		 * assigned to someone (CardBus bridges for example) and
+		 * thus are triggering resource conflicts.
+		 */
+		res = request_region(dev->resource[i].start,
+			dev->resource[i].end - dev->resource[i].start,
+			dev->name);
+		printk(" 0x%lx-0x%lx",
+			dev->resource[i].start, dev->resource[i].end);
+		count++;
+	} 
+	printk("\n");
+	if (i == DEVICE_COUNT_RESOURCE)
+		printk("%s: warning: >= %d resources, overflow?\n",
+			dev->name,DEVICE_COUNT_RESOURCE);
+	return count;
+}
+
+int pnpbios_request_mboard(void)
+{
+	struct pci_dev *dev = NULL;
+	int count = 0;
+
+	while ((dev=pnpbios_find_device("PNP0c01",dev)))
+		count += request_stuff("PNP0c01",dev);
+	while ((dev=pnpbios_find_device("PNP0c02",dev)))
+		count += request_stuff("PNP0c02",dev);
+	return count;
+}

Re: [PATCH,RFC] make ide-scsi more selective

[Alan Cox]

> I've been rather annoyed by a dual problem in the ide-scsi setup:
> during initialisation, ide-scsi will claim ALL currently unassigned
> IDE devices. This is a problem in modular setups, since there's
> no guarantee that currently unassigned devices actually are intended
> for ide-scsi.

The real problem is that the drivers are claiming resources on load not
on open. Why shouldnt I be able to load ide-cd and ide-scsi and open either
/dev/hda or /dev/sr0 but not both together ?

Alan

Re: [PATCH,RFC] make ide-scsi more selective

[Nicholas Knight]

On Wednesday 22 August 2001 02:17 pm, Alan Cox wrote:
> > I've been rather annoyed by a dual problem in the ide-scsi setup:
> > during initialisation, ide-scsi will claim ALL currently unassigned
> > IDE devices. This is a problem in modular setups, since there's
> > no guarantee that currently unassigned devices actually are intended
> > for ide-scsi.
>
> The real problem is that the drivers are claiming resources on load not
> on open. Why shouldnt I be able to load ide-cd and ide-scsi and open
> either /dev/hda or /dev/sr0 but not both together ?

Here's an end-user perspective for you... I just spent 2 days trying to 
figure out how to use my CD-RW drive to read when using ide-scsi, before 
I finnaly realized that I had to do it by disabling ATAPI CD support and 
enabling SCSI CD support..
This is a severe inconvienience to the end-user who doesn't know what the 
problem is, esspecialy since I only found the answer to the problem in a 
couple places, I had to go through a ton of google search results to find 
anything.

Re: [PATCH,RFC] make ide-scsi more selective

[Ion Badulescu]

On Wed, 22 Aug 2001, Nicholas Knight wrote:

> Here's an end-user perspective for you... I just spent 2 days trying to 
> figure out how to use my CD-RW drive to read when using ide-scsi, before 
> I finnaly realized that I had to do it by disabling ATAPI CD support and 
> enabling SCSI CD support..

Just doing hdX=scsi would have been enough, however. Except it doesn't 
work (currently) if ide-scsi is a module.

I agree with Alan that the problem is the grab-on-load strategy that
ide-scsi (and ide-cd for that matter) uses. I am willing to look into 
changing that to grab-on-open but I'm not sure if the change is an 
appropriate one for a stable series kernel -- it looks pretty non-trivial.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

Re: [PATCH,RFC] make ide-scsi more selective

[Nicholas Knight]

On Wednesday 22 August 2001 03:00 pm, Ion Badulescu wrote:
> On Wed, 22 Aug 2001, Nicholas Knight wrote:
> > Here's an end-user perspective for you... I just spent 2 days trying
> > to figure out how to use my CD-RW drive to read when using ide-scsi,
> > before I finnaly realized that I had to do it by disabling ATAPI CD
> > support and enabling SCSI CD support..
>
> Just doing hdX=scsi would have been enough, however. Except it doesn't
> work (currently) if ide-scsi is a module.

Could you elaborate on this? I almost never use modules for my primary 
desktop system, SCSI emulation support and SCSI generic driver were both 
compiled in, and I had "hdc=ide-scsi" and later also tried "hdc=scsi" and 

I was unable to read from it with any device, /dev/sr0 /dev/sda /dev/scd0 
were all dead-ends, but I was able to WRITE just fine... I just don't 
want to reboot every time I want to write to the drive, nor reboot when I 
want to READ from it.

Disabling ATAPI CD-ROM support, and enabling SCSI CD-ROM (along with SCSI 
emulation support and SCSI generic support) worked, and now I just access 
both my CD-RW drive and my DVD-ROM drive through /dev/sr0 and /dev/sr1.

My primary concern here is other users who haven't figured this out, I 
know at least one ATAPI/IDE CD-R(W) in Linux HOWTO tells the user that 
they'll have to use two seperate kernel images, one to allow reading from 
their drive and the other for writing, infact that was my original method.

> I agree with Alan that the problem is the grab-on-load strategy that
> ide-scsi (and ide-cd for that matter) uses. I am willing to look into
> changing that to grab-on-open but I'm not sure if the change is an
> appropriate one for a stable series kernel -- it looks pretty
> non-trivial.
>
> Ion

Re: [PATCH,RFC] make ide-scsi more selective

[mhobgood]

Well,
	I just double checked my system.  Sure enough I'm using ide-scsi
along with hdd="ide-scsi" with lilo.  It grabs hdd, which is my HP-7200
CD-RW and leaves hdc, which is my DVD alone.  I've no trouble at all
in reading or writing to hdd; no different kernel images, nothing.  I
use modules and have them normally loaded at boot time since I routinely
use both drives to read from.  My understanding was that I only needed
the hdd="ide-scsi" in lilo to prevent ATAPI from grabbing all the drives
it found.  BTW, everything pertaining to scsi is a module on this system.

Cordially,
Mike Hobgood


On Wed, Aug 22, 2001 at 03:39:12PM -0700, Nicholas Knight wrote:
> On Wednesday 22 August 2001 03:00 pm, Ion Badulescu wrote:
> > On Wed, 22 Aug 2001, Nicholas Knight wrote:
> > > Here's an end-user perspective for you... I just spent 2 days trying
> > > to figure out how to use my CD-RW drive to read when using ide-scsi,
> > > before I finnaly realized that I had to do it by disabling ATAPI CD
> > > support and enabling SCSI CD support..
> >
> > Just doing hdX=scsi would have been enough, however. Except it doesn't
> > work (currently) if ide-scsi is a module.
> 
> Could you elaborate on this? I almost never use modules for my primary 
> desktop system, SCSI emulation support and SCSI generic driver were both 
> compiled in, and I had "hdc=ide-scsi" and later also tried "hdc=scsi" and 
> 
> I was unable to read from it with any device, /dev/sr0 /dev/sda /dev/scd0 
> were all dead-ends, but I was able to WRITE just fine... I just don't 
> want to reboot every time I want to write to the drive, nor reboot when I 
> want to READ from it.
> 
> Disabling ATAPI CD-ROM support, and enabling SCSI CD-ROM (along with SCSI 
> emulation support and SCSI generic support) worked, and now I just access 
> both my CD-RW drive and my DVD-ROM drive through /dev/sr0 and /dev/sr1.
> 
> My primary concern here is other users who haven't figured this out, I 
> know at least one ATAPI/IDE CD-R(W) in Linux HOWTO tells the user that 
> they'll have to use two seperate kernel images, one to allow reading from 
> their drive and the other for writing, infact that was my original method.
> 
> > I agree with Alan that the problem is the grab-on-load strategy that
> > ide-scsi (and ide-cd for that matter) uses. I am willing to look into
> > changing that to grab-on-open but I'm not sure if the change is an
> > appropriate one for a stable series kernel -- it looks pretty
> > non-trivial.
> >
> > Ion
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH,RFC] make ide-scsi more selective

[Ion Badulescu]

On Wed, 22 Aug 2001, Nicholas Knight wrote:

> Could you elaborate on this? I almost never use modules for my primary 
> desktop system, SCSI emulation support and SCSI generic driver were both 
> compiled in, and I had "hdc=ide-scsi" and later also tried "hdc=scsi" and 

Well, hdc=ide-scsi is for 2.2 and hdc=scsi is for 2.4. Yup, yet another of 
those gratuitious incompatibilities.

> I was unable to read from it with any device, /dev/sr0 /dev/sda /dev/scd0 
> were all dead-ends, but I was able to WRITE just fine... I just don't 
> want to reboot every time I want to write to the drive, nor reboot when I 
> want to READ from it.

I'm not sure why this is happening for you, my CDR drive works for both 
reading and writing using the ide-scsi driver. But it's a known fact that 
ide-scsi is not perfect, so that could explain it.

> Disabling ATAPI CD-ROM support, and enabling SCSI CD-ROM (along with SCSI 
> emulation support and SCSI generic support) worked, and now I just access 
> both my CD-RW drive and my DVD-ROM drive through /dev/sr0 and /dev/sr1.

So now you're saying it *does* work with ide-scsi? I'm utterly confused...

> My primary concern here is other users who haven't figured this out, I 
> know at least one ATAPI/IDE CD-R(W) in Linux HOWTO tells the user that 
> they'll have to use two seperate kernel images, one to allow reading from 
> their drive and the other for writing, infact that was my original method.

Nope. Ide-scsi should be fine for both reading and writing.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

Re: [PATCH,RFC] make ide-scsi more selective

[Nicholas Knight]

On Wednesday 22 August 2001 08:54 pm, Ion Badulescu wrote:
> On Wed, 22 Aug 2001, Nicholas Knight wrote:
> > Could you elaborate on this? I almost never use modules for my
> > primary desktop system, SCSI emulation support and SCSI generic
> > driver were both compiled in, and I had "hdc=ide-scsi" and later also
> > tried "hdc=scsi" and
>
> Well, hdc=ide-scsi is for 2.2 and hdc=scsi is for 2.4. Yup, yet another
> of those gratuitious incompatibilities.

tried both, neither worked, even with SCSI CD-ROM support enabled

>
> > I was unable to read from it with any device, /dev/sr0 /dev/sda
> > /dev/scd0 were all dead-ends, but I was able to WRITE just fine... I
> > just don't want to reboot every time I want to write to the drive,
> > nor reboot when I want to READ from it.
>
> I'm not sure why this is happening for you, my CDR drive works for both
> reading and writing using the ide-scsi driver. But it's a known fact
> that ide-scsi is not perfect, so that could explain it.

I've gotten the impression that ide-scsi isn't perfect :)

>
> > Disabling ATAPI CD-ROM support, and enabling SCSI CD-ROM (along with
> > SCSI emulation support and SCSI generic support) worked, and now I
> > just access both my CD-RW drive and my DVD-ROM drive through /dev/sr0
> > and /dev/sr1.
>
> So now you're saying it *does* work with ide-scsi? I'm utterly
> confused...

I'll be more specific:

I've used this in 2.4.8 and 2.4.8-ac9 to read from my IDE/ATAPI CD-RW 
drive while also using it to write to
I now have IDE/ATAPI CD-ROM support DISABLED in the ATA/* menu
SCSI emulation is ENABLED in the ATA/* menu
SCSI CD-ROM support is ENABLED in the SCSI menu
SCSI Generic is ENABLED in the SCSI menu
I do not have any parameters (such as hdX=scsi or ide-scsi) being passed 
to the kernel except those for my SB16 card, which doesn't have any 
devices hooked to its IDE port.

this appears at kernel boot:
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
  Vendor: PLEXTOR   Model: CD-R   PX-W1610A  Rev: 1.00
  Type:   CD-ROM                             ANSI SCSI revision: 02
  Vendor: PIONEER   Model: DVD-ROM DVD-113   Rev: 1.08
  Type:   CD-ROM                             ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
Attached scsi CD-ROM sr1 at scsi0, channel 0, id 1, lun 0
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
sr1: scsi3-mmc drive: 0x/0x cd/rw xa/form2 cdda tray

using 0,0,0 works for cdrecord, and using /dev/sr0 to mount discs in my 
CD-RW drive and /dev/sr1
using /dev/hdc and /dev/hdd does NOT work now

Without this setup, I've been unable to read from my CD-RW drive while 
it's also setup to write to with SCSI generic.

>
> > My primary concern here is other users who haven't figured this out,
> > I know at least one ATAPI/IDE CD-R(W) in Linux HOWTO tells the user
> > that they'll have to use two seperate kernel images, one to allow
> > reading from their drive and the other for writing, infact that was
> > my original method.
>
> Nope. Ide-scsi should be fine for both reading and writing.

didn't for me

Re: [PATCH,RFC] make ide-scsi more selective

[Willem Riede]

Alan Cox wrote:
> 
> > I've been rather annoyed by a dual problem in the ide-scsi setup:
> > during initialisation, ide-scsi will claim ALL currently unassigned
> > IDE devices. This is a problem in modular setups, since there's
> > no guarantee that currently unassigned devices actually are intended
> > for ide-scsi.
> 
> The real problem is that the drivers are claiming resources on load not
> on open. Why shouldnt I be able to load ide-cd and ide-scsi and open either
> /dev/hda or /dev/sr0 but not both together ?
> 
Ion Badulescu wrote:
> 
> On Wed, 22 Aug 2001, Nicholas Knight wrote:
> 
> > Here's an end-user perspective for you... I just spent 2 days trying to
> > figure out how to use my CD-RW drive to read when using ide-scsi, before
> > I finnaly realized that I had to do it by disabling ATAPI CD support and
> > enabling SCSI CD support..
> 
> Just doing hdX=scsi would have been enough, however. Except it doesn't
> work (currently) if ide-scsi is a module.
> 
Well, at least on my system (RH 7.1) in rc.sysinit there's a fragment
that checks if ide-scsi is asked for and if so loads ide-cd first, so
it can grab CD drives that are not targeted for scsi emulation.

Personally, I've added a modprobe of ide-tape there so that ide-scsi 
can't grab any tape drives it is not supposed to either.

> I agree with Alan that the problem is the grab-on-load strategy that
> ide-scsi (and ide-cd for that matter) uses. I am willing to look into
> changing that to grab-on-open but I'm not sure if the change is an
> appropriate one for a stable series kernel -- it looks pretty non-trivial.
> 
Right. And it is not limited to ide-scsi but impacts drivers that
connect to ide-scsi such as the osst tape driver I maintain which
would have to allow a device to be ht0 and osst0 at the user's choice...

Regards, Willem Riede.

Re: [PATCH,RFC] make ide-scsi more selective

[Ion Badulescu]

On Wed, 22 Aug 2001, Alan Cox wrote:

> The real problem is that the drivers are claiming resources on load not
> on open. Why shouldnt I be able to load ide-cd and ide-scsi and open either
> /dev/hda or /dev/sr0 but not both together ?

Mostly because sr_open() does not make any calls into the host driver, 
which makes it impossible to claim any resources on open.

I've concocted another patch, which includes my previous one and
implements Mikael's idea somewhat more consistently. It adds another
option, "noscsi", so that by saying hdX=noscsi on the kernel command line
the user can prevent the ide-scsi driver from ever claiming that drive.

So:
- by default it's first come, first served
- hdX=scsi means only the ide-scsi driver can claim hdX
- hdX=noscsi means the ide-scsi driver must not claim hdX ever

Sounds good? If so, please apply, it makes many CDR users' lives easier.

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.
-----------------------------------
diff -ur ../linux-2.4-ac/drivers/ide/ide-cd.c linux-2.4.8-ac7/drivers/ide/ide-cd.c
--- ../linux-2.4-ac/drivers/ide/ide-cd.c	Sat Aug 18 06:03:21 2001
+++ linux-2.4.8-ac7/drivers/ide/ide-cd.c	Sat Aug 25 02:30:03 2001
@@ -3026,7 +3026,7 @@
 				continue;
 			}
 		}
-		if (drive->scsi) {
+		if (drive->scsi == 1) {
 			printk("ide-cd: passing drive %s to ide-scsi emulation.\n", drive->name);
 			continue;
 		}
diff -ur ../linux-2.4-ac/drivers/ide/ide-floppy.c linux-2.4.8-ac7/drivers/ide/ide-floppy.c
--- ../linux-2.4-ac/drivers/ide/ide-floppy.c	Sat Aug 18 06:03:21 2001
+++ linux-2.4.8-ac7/drivers/ide/ide-floppy.c	Sat Aug 25 02:29:51 2001
@@ -2018,7 +2018,7 @@
 			printk (KERN_ERR "ide-floppy: %s: not supported by this version of ide-floppy\n", drive->name);
 			continue;
 		}
-		if (drive->scsi) {
+		if (drive->scsi == 1) {
 			printk("ide-floppy: passing drive %s to ide-scsi emulation.\n", drive->name);
 			continue;
 		}
diff -ur ../linux-2.4-ac/drivers/ide/ide-tape.c linux-2.4.8-ac7/drivers/ide/ide-tape.c
--- ../linux-2.4-ac/drivers/ide/ide-tape.c	Sat Aug 18 06:03:21 2001
+++ linux-2.4.8-ac7/drivers/ide/ide-tape.c	Sat Aug 25 02:29:39 2001
@@ -6235,7 +6235,7 @@
 			printk (KERN_ERR "ide-tape: %s: not supported by this version of ide-tape\n", drive->name);
 			continue;
 		}
-		if (drive->scsi) {
+		if (drive->scsi == 1) {
 			if (strstr(drive->id->model, "OnStream DI-")) {
 				printk("ide-tape: ide-scsi emulation is not supported for %s.\n", drive->id->model);
 			} else {
diff -ur ../linux-2.4-ac/drivers/ide/ide.c linux-2.4.8-ac7/drivers/ide/ide.c
--- ../linux-2.4-ac/drivers/ide/ide.c	Sat Aug 18 06:03:21 2001
+++ linux-2.4.8-ac7/drivers/ide/ide.c	Sat Aug 25 02:29:24 2001
@@ -3045,7 +3045,7 @@
 		const char *hd_words[] = {"none", "noprobe", "nowerr", "cdrom",
 				"serialize", "autotune", "noautotune",
 				"slow", "swapdata", "bswap", "flash",
-				"remap", "noremap", "scsi", NULL};
+				"remap", "noremap", "scsi", "noscsi", NULL};
 		unit = s[2] - 'a';
 		hw   = unit / MAX_DRIVES;
 		unit = unit % MAX_DRIVES;
@@ -3109,13 +3109,15 @@
 				drive->remap_0_to_1 = 2;
 				goto done;
 			case -14: /* "scsi" */
-#if defined(CONFIG_BLK_DEV_IDESCSI) && defined(CONFIG_SCSI)
+#if defined(CONFIG_BLK_DEV_IDESCSI) || defined(CONFIG_BLK_DEV_IDESCSI_MODULE)
 				drive->scsi = 1;
-				goto done;
 #else
-				drive->scsi = 0;
-				goto bad_option;
-#endif /* defined(CONFIG_BLK_DEV_IDESCSI) && defined(CONFIG_SCSI) */
+				printk(" -- ide-scsi support unavailable, ignoring.\n");
+#endif /* defined(CONFIG_BLK_DEV_IDESCSI) || defined(CONFIG_BLK_DEV_IDESCSI_MODULE) */
+				goto done;
+			case -15: /* "noscsi" */
+				drive->scsi = 2;
+				goto done;
 			case 3: /* cyl,head,sect */
 				drive->media	= ide_disk;
 				drive->cyl	= drive->bios_cyl  = vals[0];
--- ../linux-2.4-ac/drivers/scsi/ide-scsi.c	Fri Feb  9 14:30:23 2001
+++ linux-2.4.8-ac7/drivers/scsi/ide-scsi.c	Sat Aug 25 02:29:04 2001
@@ -580,7 +580,10 @@
 	for (i = 0; media[i] != 255; i++) {
 		failed = 0;
 		while ((drive = ide_scan_devices (media[i], idescsi_driver.name, NULL, failed++)) != NULL) {
-
+			if (drive->scsi == 2) {
+				printk ("ide-scsi: skipping reserved drive %s.\n", drive->name);
+				continue;
+			}
 			if ((scsi = (idescsi_scsi_t *) kmalloc (sizeof (idescsi_scsi_t), GFP_KERNEL)) == NULL) {
 				printk (KERN_ERR "ide-scsi: %s: Can't allocate a scsi structure\n", drive->name);
 				continue;

Re: i810 audio doesn't work with 2.4.9

[Stefan Westerfeld]

   Hi!

On Thu, Aug 23, 2001 at 08:03:00PM +0000, Doug Ledford wrote:
 > So it seems that update of i810_audio.c between 2.4.6-ac1 and ac2 breaks it (at least for me).
> > But I think it still eating too much time (about 2-3% on PIII 700) when I'm not doing anything 
> > with sound but no more up to 90% as with unmodified version from 2.4.9 (maybe it's a problem
> > of artsd , I don't know)
> 
> 
> Yes, it's a problem of artsd.  Someone decided (presumably to avoid the 
> occasional pop/click from the startup or shutdown of the sound device) 
> to make artsd transmit silence over the sound card when no sounds 
> currently need played.  From my perspective, I will *NEVER* use artsd as 
> long as it does this.  [... more rant ...]

More or less recent versions of artsd either autosuspend (close the sound
device) either after hard-coded 60 seconds of inactivity, or have a command
line option

-s <seconds>        auto-suspend time in seconds

which should adress this issue.

> Furthermore, I find 
> their use of the sound API to be suboptimal, especially when they are 
> going to transmit silence all the time. [...]

Well, artsd does non-blocking sound I/O combined with select() which tells it
when to wake up and write (read) something. It usually works quite nice if the
driver is implemented correctly, that is, if it wakes up artsd if there is a
suitable amount of data to read (write) - usually a fragment is a good choice
for the driver. The use of the API has the advantage that it

 - doesn't require threads (synchronization, context switches)
 - works well with very low latencies
 - never blocks the server (i.e. the server can always accept requests from
   the net)

Common problems with some drivers appear to be:

 * GETOSPACE/GETISPACE lies about the size that can be read/written (non-fatal,
   as long as there is at least some truth in there)

 * select() does wake up too early (i.e. if either nothing at all or just a
   small amount can be read/written) - thats fatal and leads to the 90% CPU
   scenarios

(I am not subscribed to linux-kernel, so in doubt CC me).

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         

Re: i810 audio doesn't work with 2.4.9

[Doug Ledford]

Stefan Westerfeld wrote:
>    Hi!
> 
> On Thu, Aug 23, 2001 at 08:03:00PM +0000, Doug Ledford wrote:
>>Yes, it's a problem of artsd.  Someone decided (presumably to avoid
>>the occasional pop/click from the startup or shutdown of the sound
>>device) to make artsd transmit silence over the sound card when no
>>sounds currently need played.  From my perspective, I will *NEVER* use 
>>artsd as long as it does this.  [... more rant ...]
>>
> 
> More or less recent versions of artsd either autosuspend (close the
> sound device) either after hard-coded 60 seconds of inactivity, or
> have a command line option
> 
> -s <seconds>        auto-suspend time in seconds
> 
> which should adress this issue.

That's a vast improvement.  Glad to hear it.

>>Furthermore, I find 
>>their use of the sound API to be suboptimal, especially when they are 
>>going to transmit silence all the time. [...]
>>
> 
> Well, artsd does non-blocking sound I/O combined with select() which
> tells it when to wake up and write (read) something. It usually works
> quite nice if the driver is implemented correctly, that is, if it
> wakes up artsd if there is a suitable amount of data to read (write) - 
> usually a fragment is a good choice
> for the driver. The use of the API has the advantage that it
> 
>  - doesn't require threads (synchronization, context switches)
>  - works well with very low latencies
>  - never blocks the server (i.e. the server can always accept requests 
>    from the net)

This is all fine.

> Common problems with some drivers appear to be:
> 
>  * GETOSPACE/GETISPACE lies about the size that can be read/written
>    (non-fatal, as long as there is at least some truth in there)


This is my complaint.  It's redundant and useless to do non blocking I/O 
*and* also waste time on GETOSPACE/GETISPACE syscalls.  Unless you are 
wanting to flirt with the very edge of having the sound buffer emptied 
so that you are only microseconds ahead of the dma engine and any new 
sound can be instantaneously transmitted to your speakers, just write to 
the damn file until you get a write that returns with a short write 
value (aka, not all data was written to the device), then sleep and wait 
for select to wake you up.  GETOSPACE/GETISPACE are there so you know 
how much data you can write, which keeps you from ever blocking.  Non 
blocking I/O is so you don't have to worry about how much space is 
available to write to.  Yes, you can use them together if you want, but 
it makes almost no sense and is a waste of CPU cycles.

>  * select() does wake up too early (i.e. if either nothing at all or
>    just a small amount can be read/written) - thats fatal and leads to 
>    the 90% CPU scenarios

The difference between GETOSPACE and write can also cause the same thing 
(something I just fixed in the i810 driver I'm working on here). 
However, if the sound driver is waking you up from a select call when it 
isn't suppossed to, that's a driver bug and not something that you 
should have to work around.  The workaround just perpetuates the broken 
drivers.

> (I am not subscribed to linux-kernel, so in doubt CC me).
> 
>    Cu... Stefan
> 



-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: Apollo Pro266 system freeze followup

[Barry K. Nathan]

Right now I'm running Linux 2.4.9-ac4, compiled for SMP, with the
following loop (in bash):

while : ; do make dep ; make clean ; make -j3 modules bzImage ; done

It's been going for about 7 and a half hours without a lockup, so far.
Note that I am not using the on-board IDE -- but I did not need the
on-board IDE for my lockups either.

If 2.4.9-ac4 still produces lockups for people, it might be interesting
to try 2.2.19 or 2.2.20pre9, compiled for SMP, and see if the lockups
still happen then.

-Barry K. Nathan <barryn@pobox.com>

Re: OOM /proc logging

[Samium Gromoff]

    5 minutes later my original message one folk wrote on IRC a phrase which
  took me down for some minutes due to -ETOOMUCHLAUGHTER, and i was unable to
  resist an urgent need to post it here cause it was so on-topic:

<wli> The penguin hath spoken, now we must clean the guano from the ice.

cheers, Samium Gromoff

Re: kernel 2.4.14 compiling fail for loop device

[Barry K. Nathan]

> When I did, and used a looped an iso image, eventually my
> computer froze up.  Using the actual cd, it did not.  So my
> personal answer would be no.

Hmmm... my *root* filesystem (with /usr, /home, etc. all on it) on one of
my computers is loop mounted, and I've not had such a freeze with 2.4.14
and the two lines removed... Just another data point.

-Barry K. Nathan <barryn@pobox.com>

Re: kernel 2.4.14 compiling fail for loop device

[Todd M. Roy]

Would you believe that I recompiled 2.4.14 this morning
and can't seem to reproduce it now?

-- todd --

"Barry K. Nathan" wrote:
> 
> > When I did, and used a looped an iso image, eventually my
> > computer froze up.  Using the actual cd, it did not.  So my
> > personal answer would be no.
> 
> Hmmm... my *root* filesystem (with /usr, /home, etc. all on it) on one of
> my computers is loop mounted, and I've not had such a freeze with 2.4.14
> and the two lines removed... Just another data point.
> 
> -Barry K. Nathan <barryn@pobox.com>

-- 
---------------------------------------------------------------
   .~. Todd Roy, Senior Database Administrator .~.
   /V\    Holstein Association, U.S.A. Inc.    /V\
  // \\          troy@holstein.com            // \\
 /(   )\        1-802-254-4551x4230          /(   )\
  ^^-^^                                       ^^-^^
"They that can give up essential liberty to obtain a little 
temporary safety deserve neither liberty nor safety."
		-- Benjamin Franklin, 1759
---------------------------------------------------------------
**********************************************************************
This footnote confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.
**********************************************************************

Re: kernel 2.4.14 compiling fail for loop device

[Mohammad A. Haque]

On Wednesday, November 7, 2001, at 10:12 AM, Barry K. Nathan wrote:

>> When I did, and used a looped an iso image, eventually my
>> computer froze up.  Using the actual cd, it did not.  So my
>> personal answer would be no.
>
> Hmmm... my *root* filesystem (with /usr, /home, etc. all on it) on one 
> of
> my computers is loop mounted, and I've not had such a freeze with 2.4.14
> and the two lines removed... Just another data point.

Hrm. I just did some stuff on a fs mounted via loopback and no problems.

Mike: it's something in particular you were doing that triggered it or 
something else completely?

--

=====================================================================
Mohammad A. Haque                              http://www.haque.net/
                                                mhaque@haque.net

   "Alcohol and calculus don't mix.             Developer/Project Lead
    Don't drink and derive." --Unknown          http://wm.themes.org/
                                                batmanppc@themes.org
=====================================================================

Re: kernel 2.4.14 compiling fail for loop device

[Mohammad A. Haque]

On Wednesday, November 7, 2001, at 10:38 AM, Mohammad A. Haque wrote:
> Hrm. I just did some stuff on a fs mounted via loopback and no problems.
>
> Mike: it's something in particular you were doing that triggered it or 
> something else completely?

Whoops,

That question should have been "is it..." and directed to Todd.

--

=====================================================================
Mohammad A. Haque                              http://www.haque.net/
                                                mhaque@haque.net

   "Alcohol and calculus don't mix.             Developer/Project Lead
    Don't drink and derive." --Unknown          http://wm.themes.org/
                                                batmanppc@themes.org
=====================================================================

Re: ramfs leak

[W Christopher Martin]

Padraig Brady writes:
> When I remove files from a ramfs the space is not reclaimed?
> What am I doing wrong? Details below.

Nothing.  We've noticed the same thing.  It's a bug and was
first reported back in July, but no one has provided a fix yet.
I've had a brief look at the source code, but nothing obvious
pops out at me.

As you mention, this problem is trivially reproducable by
creating and then deleting a file.  Doing that over and over
eventually leads to the ramfs becoming full.  Only a reboot
(or perhaps a umount/mount) makes it usable again.

Chris Martin
Catnap Consultants

Re: ramfs leak

[Tachino Nobuhiro]

Hello,

At Fri, 9 Nov 2001 15:40:43 -0500 (EST),
W Christopher Martin wrote:
> 
> Padraig Brady writes:
> > When I remove files from a ramfs the space is not reclaimed?
> > What am I doing wrong? Details below.
> 
> Nothing.  We've noticed the same thing.  It's a bug and was
> first reported back in July, but no one has provided a fix yet.
> I've had a brief look at the source code, but nothing obvious
> pops out at me.

I think you should use tmpfs instead of ramfs, but if you really want to use ramfs,
the patch below may fix the problem.

diff -Nur linux-2.4.13-ac7.org/fs/ramfs/inode.c linux-2.4.13-ac7/fs/ramfs/inode.c
--- linux-2.4.13-ac7.org/fs/ramfs/inode.c	Mon Nov 12 11:00:47 2001
+++ linux-2.4.13-ac7/fs/ramfs/inode.c	Mon Nov 12 11:26:40 2001
@@ -182,12 +182,9 @@
 {
 	struct ramfs_sb_info *rsb = RAMFS_SB(inode->i_sb);
 
-	if (! Page_Uptodate(page))
-		return;
-
 	lock_rsb(rsb);
-
-	ClearPageDirty(page);
+	if (Page_Uptodate(page))
+		ClearPageDirty(page);
 	
 	rsb->free_pages++;
 	inode->i_blocks -= IBLOCKS_PER_PAGE;

Re: ramfs leak

[Padraig Brady]

Tachino Nobuhiro wrote:

> Hello,
> 
> At Fri, 9 Nov 2001 15:40:43 -0500 (EST),
> W Christopher Martin wrote:
> 
>>Padraig Brady writes:
>>
>>>When I remove files from a ramfs the space is not reclaimed?
>>>What am I doing wrong? Details below.
>>>
>>Nothing.  We've noticed the same thing.  It's a bug and was
>>first reported back in July, but no one has provided a fix yet.
>>I've had a brief look at the source code, but nothing obvious
>>pops out at me.
>>
> 
> I think you should use tmpfs instead of ramfs, but if you really want to use ramfs,
> the patch below may fix the problem.
> 
> diff -Nur linux-2.4.13-ac7.org/fs/ramfs/inode.c linux-2.4.13-ac7/fs/ramfs/inode.c
> --- linux-2.4.13-ac7.org/fs/ramfs/inode.c	Mon Nov 12 11:00:47 2001
> +++ linux-2.4.13-ac7/fs/ramfs/inode.c	Mon Nov 12 11:26:40 2001
> @@ -182,12 +182,9 @@
>  {
>  	struct ramfs_sb_info *rsb = RAMFS_SB(inode->i_sb);
>  
> -	if (! Page_Uptodate(page))
> -		return;
> -
>  	lock_rsb(rsb);
> -
> -	ClearPageDirty(page);
> +	if (Page_Uptodate(page))
> +		ClearPageDirty(page);
>  	
>  	rsb->free_pages++;
>  	inode->i_blocks -= IBLOCKS_PER_PAGE;
> 


Cool, this fixes it,
and I was just getting to the bottom of it myself :-)
None of this accounting stuff is in 2.4.15-pre3, so Alan
can you apply this?

cheers,
Padraig.

Re: ramfs leak

[Alan Cox]

> and I was just getting to the bottom of it myself :-)
> None of this accounting stuff is in 2.4.15-pre3, so Alan
> can you apply this?

RAMfs is 2.4.16 stuff I think

Re: preemption and pccard ?

[Barry K. Nathan]

(Oops, I think I sent this via private mail last time, instead of to the
list.)

I've also seen problems with the preempt patch and PCMCIA/CardBus, on my
Dell Inspiron 5000e. The top CardBus slot doesn't work for me with the
preemption patch (in fact, if I have a card in there, sometimes the
machine freezes at the point in boot when it would normally detect the
card). It usually doesn't even see that I've put a card in there. I don't
remember trying the bottom slot instead of the top though.

I just never got a chance to report the problem, until now. This has
happened with a range of kernels (I think I first tried the preempt patch
back around 2.4.14pre and I last tried it with a late 2.4.17-pre or with
2.4.17-rc1.)

-Barry K. Nathan <barryn@pobox.com>

Re: preemption and pccard ?

[Erik Gustavsson]

I believe I also saw this when trying a preempt kernel somewhere in the
2.4.17pre series. Only one cardbus slot worked (I think it was the
bottom slot that didn't respond, but I could be mistaken). I was playing
around with various patches at the time, so I didn't pay much attention
to it. I can try to verify it if that would help. This was on a Dell
Latitude CPi D266XT.

/cyr
 
-- 
-----------------------------------------------------------------------
You really think you can buy me with promises of power and glory.
You really think... Okay, I'll do it. -- Rimmer

Re: Machines misreporting Bogomips

[Barry K. Nathan]

watermodem wrote:
> If they are Intel CPU's and the heatsink <-> CPU connection is poor
> (no heatsink compound, heatsink loose) or the fan is dead/dying or
> due to dust poor airflow this is reasonable.   Intel CPUs slow down
> when they get hot as as safety measure.

Note that this only applies to Pentium 4's. I believe Coppermine Pentium
III's will simply stop running (i.e., the computer freezes altogether
instead of slowing down) to prevent overheating. I'm not sure off the top
of my head what older Pentiums do, except that they certainly don't have
the slowdown trick that the Pentium 4 has.

Also, some BIOSes have an option called "CPU Speed at Boot" or something
like that, which has a Low and a High setting -- this serves the same
purpose as those old Turbo switches. (Note that I'm *not* talking about
the SpeedStep settings that newer laptops have in their BIOSes.)

-Barry K. Nathan <barryn@pobox.com>

Re: Filesystem Corruption (ext2) on Tyan S2462, 2xAMD1900MP, 2.4.17SMP

[Barry K. Nathan]

[snip]
>Mar 19 00:36:41 fems146 xfs: xfs startuP succeeded
>Mar 19 00:36:41 fems146 xfs: listening on port 7100 
>Mar 19 00:36:41 fems146 xfs: ieNoring font path element /usr/X11R6/lib/X11/fonts/100dpi:unscaled (unreadable) 
>Mar 19 00:36:41 fems146 anacron: anacron startup succeeded
>Mar 19 00:36:41 fems146 xfs: ignoring font path elemeNt /usr/X11R6/lib/X11/fonts/CID (unreadable) 
>Mar 19 00:36:41 fems146 xfs: ignoring font path elEment /usr/X11R6/lib/X11/fonts/local (unreadable) 
>Mar 19 00:36:41 fems146 xfs: ignoring font path element /usr/X11R6/lib/X11/fonts/japanese (unreadable) 
>Mar 19 00:36:41 fems146 atd: atd stapTup succeeded
>Mar 19 00:36:42 fems146 rc: Starting dont_blank:  succeeded
>Mar 19 00:36:42 fems14\x16 hdaset: 
>Mar 19 00:36:42 fems146 hdaset: /dev/hda:
>Mar 19 00:36:42 fems146 hdaset:  setting usIng_dma to 1 (on)
>Mar 19 00:36:42 fems146 hdaset:  using_dma    =  1 (on)
>Mar 19 00:36:42 fems14\x16 rc: Starting hdaset:  succeeded
[snip]

Looking at it on a byte-by-byte level, it looks like (at least) these
types of bit flips are happening:

     --1-----
     --0-----
     ------0-
MSB->76543210<-LSB

That is, it looks like sometimes bit 5 is being flipped on or off, or bit
1 is being flipped off. (There could be others that I just haven't seen in
those logs yet.) I'm suspecting bad hardware (in case that wasn't
obvious), but I don't know exactly what component is defective. (By the
way, the BIOS has ECC error correction enabled, right??)

Also, do the weird capitalization changes in the logs happen on screen
too, or only in the logfile?

-Barry K. Nathan <barryn@pobox.com>

Re: New IBM IDE drive recognized as 40 GB but is 80 GB

[Barry K. Nathan]

> We have bought a new IDE hard drive:
> 
> hdb: IC35L040AVVA07-0, ATA DISK drive
             ^^ 40GB (well, according to IBM, "41.17GB")

Look here if you don't believe me:
http://www.storage.ibm.com/hdd/support/d120gxp/d120gxpmod.htm
 
> This is wrongly recognized as 40GB (should be 80GB) drive:
[snip]
> [root@apu /root]# cat /proc/ide/hdb/capacity
> 80418240           <--------------------------------- this is correct
> [root@apu /root]#
> 
> shows the right capacity.

80418240 512-byte sectors is about 40GB.

The kernel is reporting the correct size... 40GB.

-Barry K. Nathan <barryn@pobox.com>

Re: New IBM IDE drive recognized as 40 GB but is 80 GB

[Martin Rode]

Thanks all for your help!

The drive had a wrong labeled bag and the wrong sticker on it
(indicating 80GB instead of 40GB)!! So Linux IDE works fine...

;Martin


-- 
Dipl.-Kfm. Martin Rode
martin.rode@zeroscale.com

Zeroscale GmbH & Co. KG
Frankfurter Allee 73d
10247 Berlin

http://www.zeroscale.com/
http://www.programmfabrik.de/

Fon +49-(0)30-4281-8001
Fax +49-(0)30-4281-8008
Funk +49-(0)163-5321400

Re: [patch] hpt374 support

[Barry K. Nathan]

Andrew Morton wrote:
> It has a problem with my 80 gigabyte Seagates - in UDMA133
> mode, writes are inexplicably slow.  I manually set UDMA100
> and it flies.

Hmmm... do 80GB Seagates even support UDMA133? I could be mistaken, but
as an owner of one, I'm pretty sure the answer is "no". In fact, I think
Maxtor's the only company making UDMA133 drives at this point in time.

-Barry K. Nathan <barryn@pobox.com>

Re: [patch] hpt374 support

[tomas szepe]

> > It has a problem with my 80 gigabyte Seagates - in UDMA133
> > mode, writes are inexplicably slow.  I manually set UDMA100
> > and it flies.
> Hmmm... do 80GB Seagates even support UDMA133? I could be mistaken, but
> as an owner of one, I'm pretty sure the answer is "no". In fact, I think
> Maxtor's the only company making UDMA133 drives at this point in time.

Right.

hda: ST380021A, ATA DISK drive (i.e., Seagate Barracuda IV)
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=9729/255/63, UDMA(100)

 Model=ST380021A, FwRev=3.75, SerialNo=3HV16GXT
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=156301488
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no
 Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5

ATA-5 would be ATA100 AFAIK?


T.

Re: [patch] hpt374 support

[Andrew Morton]

"Barry K. Nathan" wrote:
> 
> Andrew Morton wrote:
> > It has a problem with my 80 gigabyte Seagates - in UDMA133
> > mode, writes are inexplicably slow.  I manually set UDMA100
> > and it flies.
> 
> Hmmm... do 80GB Seagates even support UDMA133? I could be mistaken, but
> as an owner of one, I'm pretty sure the answer is "no". In fact, I think
> Maxtor's the only company making UDMA133 drives at this point in time.
> 

Doh.  I have enough disks in this thing to feed a small nation, and
I am easily confused.

/dev/hde:

 Model=Maxtor 4D080K4, FwRev=DAK019K0, SerialNo=D4H0GTPE
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160086528
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6 
 Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6 
 Kernel Drive Geometry LogicalCHS=158816/255/63 PhysicalCHS=158816/255/63

-

Re: Linux 2.4.18 floppy driver EATS floppies

[Barry K. Nathan]

> I am discovering that any floppy disks that I try to use under Linux
> don't last very long. This seems to be true with both my UP and SMP 
> machines, neither of which has ever used its floppy drive enough for
> me to believe that the hardware is reaching the end of its life.

Make sure the boot-time floppy seek option is enabled in your BIOS. While
it shouldn't be necessary nowadays in theory, I've seen some
motherboard/(1.44MB 3.5") floppy drive combinations that require it to be
enabled for the floppy drive to work with any level of consistency.

Also, if a particular disk is acting really strange, try ejecting it,
reinserting it, and trying again.

Both of these pieces of advice apply to Windows as well as Linux, FWIW.

-Barry K. Nathan <barryn@pobox.com>

Re: [PATCH] scheduler hints

[Rick Bressler]

> So I went ahead and implemented scheduler hints on top of the O(1)
> scheduler. 

> Other hints could be "I am interactive" or "I am a batch (i.e. cpu hog)
> task" or "I am cache hot: try to keep me on this CPU". 

Sequent had an interesting hint they cooked up with Oracle. (Or maybe it
was the other way around.)  As I recall they called it 'twotask.'
Essentially Oracle clients processes spend a lot of time exchanging
information with its server process. It usually makes sense to bind them
to the same CPU in an SMP (and especially NUMA) machine.  (Probably
obvious to most of the folks on the group, but it is generally lots
better to essentially communicate through the cache and local memory
than across the NUMA bus.)

As I recall it made a significant difference in Oracle performance, and
would probably also translate to similar performance in many situations
where you had a client and server process doing lots of interaction in
an SMP environment.

Don't know if there is enough application to warrant it, but you asked.
:-)

-- 
+--------------------------------------------+ Rick Bressler
|Mushrooms and other fungi have several      | 
|important roles in nature.  They help things| 
|grow, they are a source of food, they       |
|decompose organic matter and they           | 
|infect, debilitate and kill organisms.      | Linux: Because a PC is a
+--------------------------------------------+ terrible thing to waste.

Re: [PATCH] scheduler hints

[Robert Love]

On Wed, 2002-06-05 at 17:46, Rick Bressler wrote:

> Sequent had an interesting hint they cooked up with Oracle. (Or maybe it
> was the other way around.)  As I recall they called it 'twotask.'
> Essentially Oracle clients processes spend a lot of time exchanging
> information with its server process. It usually makes sense to bind them
> to the same CPU in an SMP (and especially NUMA) machine.  (Probably
> obvious to most of the folks on the group, but it is generally lots
> better to essentially communicate through the cache and local memory
> than across the NUMA bus.)

This is similar in theory to why we used to have the sync option on
wake_up for pipes... it does work.

We don't need a scheduler "hint" for this, though.  A big loud command
"bind me to this processor!" would do fine, and in 2.5 we have that:

just have one of the tasks do:

	sched_setaffinity(0, sizeof(unsigned long), 1);
	sched_setaffinity(other_guys_pid, sizeof(unsigned long), 1);

and both will be affined to CPU 1.

	Robert Love

Re: [PATCH] scheduler hints

[Rick Bressler]

> We don't need a scheduler "hint" for this, though.  A big loud command
> "bind me to this processor!" would do fine, and in 2.5 we have that:
> 
> just have one of the tasks do:
> 
> 	sched_setaffinity(0, sizeof(unsigned long), 1);
> 	sched_setaffinity(other_guys_pid, sizeof(unsigned long), 1);
> 
> and both will be affined to CPU 1.

I think that in some ways they were trying to simplify the code.  It is
a bit more complicated to do well from user space.  You're talking
dozens to thousands of process pairs, and maybe dozens of CPU's.  I
think the idea was that the scheduler has a better idea of what CPU's
are least busy, where to put the processes and indeed should migrate
tasks as necessary.  I just does it in pairs.  Keep em together is the
idea, rather than keep them in any one specific place, thus the hint.

I note that Gerrit replied also and as I recall he is one of those ex
Sequent guys who really knows this stuff, so I'll bow out in favor of
the experts. :-)

-- 
+--------------------------------------------+ Rick Bressler
|Mushrooms and other fungi have several      | G-4781 (425)342-1554
|important roles in nature.  They help things| Pager 1-800-946-4646
|grow, they are a source of food, they       |         Pin: 1700898
|decompose organic matter and they           | bressler@mushroom.ca.boeing.com
|infect, debilitate and kill organisms.      | Linux: Because a PC is a
+--------------------------------------------+ terrible thing to waste.

Re: [PATCH] scheduler hints

[Gerrit Huizenga]

In message <200206060046.g560kJi04034@mushroom.ca.boeing.com>, > : Rick Bressle
r writes:
> > So I went ahead and implemented scheduler hints on top of the O(1)
> > scheduler. 
> 
> > Other hints could be "I am interactive" or "I am a batch (i.e. cpu hog)
> > task" or "I am cache hot: try to keep me on this CPU". 
> 
> Sequent had an interesting hint they cooked up with Oracle. (Or maybe it
> was the other way around.)  As I recall they called it 'twotask.'
> Essentially Oracle clients processes spend a lot of time exchanging
> information with its server process. It usually makes sense to bind them
> to the same CPU in an SMP (and especially NUMA) machine.  (Probably
> obvious to most of the folks on the group, but it is generally lots
> better to essentially communicate through the cache and local memory
> than across the NUMA bus.)

Actually, process-to-process affinity, which was later generalized
as a process gang affinity.

> As I recall it made a significant difference in Oracle performance, and
> would probably also translate to similar performance in many situations
> where you had a client and server process doing lots of interaction in
> an SMP environment.

Yep.  Must be used with care, but not terribly damaging for general
access.   Typically arranged as a many to one linkage by the callers,
which simplified the rebalancing decisions a bit.  I think there
was a paper written about it somewhere by Phil Krueger.

gerrit

Re: [PATCH] scheduler hints

[Robert Love]

On Wed, 2002-06-05 at 18:05, Gerrit Huizenga wrote:

> Actually, process-to-process affinity, which was later generalized
> as a process gang affinity.

Oh OK, gang affinity - a bit different and not what we do now :)

Interesting to look into, although not terribly useful I suspect weighed
against its implementation...

	Robert Love

Re: [PATCH] scheduler hints

[Gerrit Huizenga]

In message <1023325903.912.390.camel@sinai>, > : Robert Love writes:
> On Wed, 2002-06-05 at 18:05, Gerrit Huizenga wrote:
> 
> > Actually, process-to-process affinity, which was later generalized
> > as a process gang affinity.
> 
> Oh OK, gang affinity - a bit different and not what we do now :)
> 
> Interesting to look into, although not terribly useful I suspect weighed
> against its implementation...
> 
> 	Robert Love

Our scheduler *was* a long set of conditionals.  However, from the
stock BSD scheduler through the contorted thing that it became, we
saw something like 30-50% increases in some workloads.  I think
the motivator was actually not Oracle originally but something like
SAP.  Specific numbers are hard to extract now since we did so many
SMP & NUMA changes over the years, but I think I remember a slide
showing over 30% increase in SAP for this one additional feature.
I don't know that I ever saw specific Oracle or Oracle Apps numbers
for this although it was viewed as a "large" benefit, especially
in NUMA machines, but even on SMP machines.

gerrit

Re: [PATCH] scheduler hints

[Bill Davidsen]

On Wed, 5 Jun 2002, Rick Bressler wrote:

> > So I went ahead and implemented scheduler hints on top of the O(1)
> > scheduler. 
> 
> > Other hints could be "I am interactive" or "I am a batch (i.e. cpu hog)
> > task" or "I am cache hot: try to keep me on this CPU". 
> 
> Sequent had an interesting hint they cooked up with Oracle. (Or maybe it
> was the other way around.)  As I recall they called it 'twotask.'
> Essentially Oracle clients processes spend a lot of time exchanging
> information with its server process. It usually makes sense to bind them
> to the same CPU in an SMP (and especially NUMA) machine.  (Probably
> obvious to most of the folks on the group, but it is generally lots
> better to essentially communicate through the cache and local memory
> than across the NUMA bus.)

Are you really saying that you think serializing all the clients through a
single processor will gain more than than you lose by not using all the
other CPUs for clients?
 
> As I recall it made a significant difference in Oracle performance, and
> would probably also translate to similar performance in many situations
> where you had a client and server process doing lots of interaction in
> an SMP environment.

I've certainly seen a "significant difference" between uni and SMP, but it
was always in the other direction. Is this particular to some hardware, or
running multiple servers somehow? I'm only fmailiar with Linux, AIX and
Solaris, maybe this is Sequent magic? Or were you talking about having
only one client total on the machine and just making that run fast?

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] scheduler hints

[Gerrit Huizenga]

In message <Pine.LNX.3.96.1020610165913.23851B-100000@gatekeeper.tmr.com>, > : 
Bill Davidsen writes:
> On Wed, 5 Jun 2002, Rick Bressler wrote:
> 
> > > So I went ahead and implemented scheduler hints on top of the O(1)
> > > scheduler. 
> > 
> > > Other hints could be "I am interactive" or "I am a batch (i.e. cpu hog)
> > > task" or "I am cache hot: try to keep me on this CPU". 
> > 
> > Sequent had an interesting hint they cooked up with Oracle. (Or maybe it
> > was the other way around.)  As I recall they called it 'twotask.'
> > Essentially Oracle clients processes spend a lot of time exchanging
> > information with its server process. It usually makes sense to bind them
> > to the same CPU in an SMP (and especially NUMA) machine.  (Probably
> > obvious to most of the folks on the group, but it is generally lots
> > better to essentially communicate through the cache and local memory
> > than across the NUMA bus.)
> 
> Are you really saying that you think serializing all the clients through a
> single processor will gain more than than you lose by not using all the
> other CPUs for clients?
  
When the number of runnable processes exceeds the number of CPUs
in an SMP system, and subsets of the runnable processes share data
(pipes, sockets, shared memory, etc.), minimizing the cache invalidate
effects of the subset by scheduling them on the same CPU (with some
level of cache-affinity, or stickiness) can increase throughput
dramatically.  Oracle Apps and BAAN are two application sets that have
this kind of behavior which benefited from having these subsets of
related processes "tied at the wrists" when they were scheduled.

Figure 1000 runnable process, in sets of two or even sets of ten.
The subsets should be scheduled together if possible, but still
smeared across all processors.  No one is suggesting that a UP machine
will always outperform an SMP machine.  ;-)

As was mentioned in another aspect of this thread, this is different
from explicit user-specified CPU affinity in that there are more processes
than a user wants to allocate explicitly to CPUs.  Instead, the scheduler
can do load balancing by moving/migrating sets of processes from an
overloaded CPU to a less loaded CPU.  However, the cache effects can
make a difference of something like 20-50% of overall throughput in
a fairly intensive data sharing workload like this.

> > As I recall it made a significant difference in Oracle performance, and
> > would probably also translate to similar performance in many situations
> > where you had a client and server process doing lots of interaction in
> > an SMP environment.
> 
> I've certainly seen a "significant difference" between uni and SMP, but it
> was always in the other direction. Is this particular to some hardware, or
> running multiple servers somehow? I'm only fmailiar with Linux, AIX and
> Solaris, maybe this is Sequent magic? Or were you talking about having
> only one client total on the machine and just making that run fast?

This is an SMP thing, which also benefits NUMA pretty dramatically.
And this is about how processes are scheduled, and how hints can
be provided to the scheduler.  It also relates to the overhead of
cache invalidation, the size of CPU caches, etc.  Sequent's hardware
might have seen a bigger improvement from this type of change than
other types of hardware might.  Or vice versa.

gerrit

Re: usb CF reader and 2.4.19

[Vid Strpic]

On Wed, Oct 16, 2002 at 11:22:04AM +0200, Joseph Wenninger wrote:
> Is there anything I can do to flush all usb / usb storage buffers to
> my compact flash ? 
> At the moment I have to rmmod usb-storage && rmmod usb-uhci &&
> modprobe usb-uhci && modprobe usb-storage to ensure all data is
> written correctly, otherwise the directory structure isn't saved even
> after an unmount.

eject sda|whichever device it is, maybe?

Works here with my SM/CF reader.

-- 
           vms@bofhlet.net, IRC:*@Martin, /bin/zsh. C|N>K
Linux lorien 2.4.19rml #1 Mon Sep 16 09:01:48 CEST 2002 i586
 23:08:58 up 3 days,  5:29, 26 users,  load average: 2.17, 1.49, 0.97

Re: Running linux-2.4.20-rc1 on Dell Dimension 4550

[Mitch Adair]

> Thought I'd post some information about what I'm seeing running RH7.3 with 
> kernel 2.4.20-rc1 on a brand new Dell Dimension 4550.  Currently there are 
> two problems with the machine:
> 
> - When I swtich to a text console and back to the X screen, the machine locks 
> up (or at least the console does not respond anymore).

you don't say the kernel, X, or hardware, but I've seen that personally
with radeon 7500... that what you have?

> - The sound driver does not load, although it seems to try.

seems to be ich4 audio - you need 0.23/24 driver for this to work -
check with the AC series - OR -

with my _particular_ i845E chipset - commenting out the "break;" immediately
after the line that goes "Primary codec not ready" makes this work fine --
probably your computer will burst into flames if you do the same or
something... this is *NOT* a recommendation.

	M

Re: Running linux-2.4.20-rc1 on Dell Dimension 4550

[Orion Poplawski]

On Tuesday 29 October 2002 11:42 pm, Mitch Adair wrote:
> > Thought I'd post some information about what I'm seeing running RH7.3
> > with kernel 2.4.20-rc1 on a brand new Dell Dimension 4550.  Currently
> > there are two problems with the machine:
> >
> > - When I swtich to a text console and back to the X screen, the machine
> > locks up (or at least the console does not respond anymore).
>
> you don't say the kernel, X, or hardware, but I've seen that personally
> with radeon 7500... that what you have?

Kernel is 2.4.20-rc1, X is 4.2.0-8 from RH.  The X log reports:

(--) Chipset ATI Rage 128 Pro ULTRA TF (AGP) found

Warnings/errors are:

(WW) R128(0): Can't determine panel dimensions, and none specified.
       Disabling programming of FP registers.

(EE) R128(0): No DFP detected

The Dell packing list reports: 32MB ATI RAGE ULTRA 4X AGP.

Probably should take this off linux-kernel....

- Orion

Re: 2.4.20 kernel link error

[Vid Strpic]

On Fri, Nov 29, 2002 at 07:00:50AM -0800, carbonated beverage wrote:
> Anything other info needed?
> gcc 2.95.4
> binutils 2.12.90.0.1
> Debian/woody
> Linux 2.4.20

Same config, but gcc 3.2.1 :


In file included from /usr/src/linux-2.4.20/include/linux/wait.h:13,
                 from /usr/src/linux-2.4.20/include/linux/fs.h:12,
                 from /usr/src/linux-2.4.20/include/linux/capability.h:17,
                 from /usr/src/linux-2.4.20/include/linux/binfmts.h:5,
                 from /usr/src/linux-2.4.20/include/linux/sched.h:9,
                 from buffer.c:32:
/usr/src/linux-2.4.20/include/linux/kernel.h:10:20: stdarg.h: No such file or directory


... and this repeats all over `make dep`... and when I'm making bzImage:


/usr/src/linux-2.4.20/include/linux/kernel.h:74: parse error before "va_list"
/usr/src/linux-2.4.20/include/linux/kernel.h:74: warning: function declaration isn't a prototype
/usr/src/linux-2.4.20/include/linux/kernel.h:77: parse error before "va_list"
/usr/src/linux-2.4.20/include/linux/kernel.h:77: warning: function declaration isn't a prototype
/usr/src/linux-2.4.20/include/linux/kernel.h:81: parse error before "va_list"
/usr/src/linux-2.4.20/include/linux/kernel.h:81: warning: function declaration isn't a prototype
make[2]: *** [sched.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.4.20/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.20/kernel'
make: *** [_dir_kernel] Error 2


It is the same with gcc-2.95.4 (from Debian package), btw ... I tried
rml patch (for rc4), and it also shows the same behavior....


-- 
           vms@bofhlet.net, IRC:*@Martin, /bin/zsh. C|N>K
Linux lorien 2.4.19 #1 Mon Sep 16 09:01:48 CEST 2002 i586
 23:58:05 up 2 days,  7:41, 29 users,  load average: 3.27, 3.27, 2.94
Prije nego sto ukljucis komp ubaci uticnicu u utikac. (DMC)

Re: spinlock efficiency problem [was 2.5.57 IO slowdown with CONFIG_PREEMPT enabled)

[Joe Korty]

[ resend - forgot to send this to the list, also forgot intro text ]

> Robert Macaulay <robert_macaulay@dell.com> wrote:
>>
>> On Wed, 15 Jan 2003, Andrew Morton wrote:
>>> if you could please test that with CONFIG_PREEMPT=y
>> 
>> Reverting that brings the speed back up
>
> OK.  How irritating.
>
> Presumably there's a fairness problem - once a CPU goes in there to start
> spinning on the lock, the length of the loop is such that it's easy for
> non-holders to zoom in and claim it first.  Or something.
>
> Unless another way of solving the problem which that patch solves presents
> itself we may need to revert it.
>
> Or not.  Should a CONFIG_PREEMPT SMP kernel compromise its latency because of
> overused locking??


Andrew, Everyone,

The new, preemptable spin_lock() spins on an atomic bus-locking
read/write instead of an ordinary read, as the original spin_lock
implementation did.  Perhaps that is the source of the inefficiency
being seen.

Attached sample code compiles but is untested and incomplete (present
only to illustrate the idea).

Joe



--- 2.5-bk/kernel/sched.c.orig	2003-01-20 14:14:55.000000000 -0500
+++ 2.5-bk/kernel/sched.c	2003-01-20 17:31:49.000000000 -0500
@@ -2465,15 +2465,13 @@
 		_raw_spin_lock(lock);
 		return;
 	}
-
-	while (!_raw_spin_trylock(lock)) {
-		if (need_resched()) {
-			preempt_enable_no_resched();
-			__cond_resched();
-			preempt_disable();
+	do {
+		preempt_enable();
+		while(spin_is_locked(lock)) {
+			cpu_relax();
 		}
-		cpu_relax();
-	}
+		preempt_disable();
+	} while (!_raw_spin_trylock(lock));
 }
 
 void __preempt_write_lock(rwlock_t *lock)

Re: spinlock efficiency problem [was 2.5.57 IO slowdown with CONFIG_PREEMPT enabled)

[Alan]

On Mon, 2003-01-20 at 22:58, Joe Korty wrote:
> The new, preemptable spin_lock() spins on an atomic bus-locking
> read/write instead of an ordinary read, as the original spin_lock
> implementation did.  Perhaps that is the source of the inefficiency
> being seen.

Its a fairly critical "Never do this" on older intel processors and
kills the box very efficiently so your diagnosis is extremely 
plausible

Re: Promise SATA chips

[Vid Strpic]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Thu, Feb 13, 2003 at 08:03:42AM +0100, Mĺns Rullgĺrd wrote:
> Samuel Flory <sflory@rackable.com> writes:
> > >Are there any drivers being developed for Promise's SATA chips
> > >(e.g. the pdc20275 with PCI id 0x3375)?  Or do I have to
> > >disassemble their driver to use it on non-intel machines?
> > Last I checked there was no open driver and no prospect of one.  Do
> > yourself a favor and use the silicon image chipset.
> The problem is that no local dealers have it for sale.  Neither do
> they sell Hightpoint gear.

Mine do... but, I cannot find, which driver to use?

cmd64x.c?  I am referring to older, non-SATA boards...

I am using 2.4 kernel (currently 2.4.20).

-- 
           vms@bofhlet.net, IRC:*@Martin, /bin/zsh. C|N>K
Linux lorien 2.4.20rml #3 Sat Nov 30 20:35:09 CET 2002 i586
 09:37:46 up 7 days, 14:39, 30 users,  load average: 0.54, 0.98, 1.42
I FOR WITHOUT NEXT                      (c)1992 ZX Spectrum

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] update filesystems config. menu

[Mitch Adair]

> +config EXT2_FS
> +	tristate "Second extended fs support"

[...]

> +	  module will be called ext2.  Be aware however that the file system
> +	  of your root partition (the one containing the directory /) cannot
> +	  be compiled as a module, and so this could be dangerous.  Most
> +	  everyone wants to say Y here.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I seem to recall if you say Y to ext2 and Y to ext3 and your root is on ext3
then it's likely to be mounted as ext2 unless you set rootfstype=...
The ext3 help comment also warns you should set it to Y, so people with
root ext3 are likely to get a surprise if they follow both help.  Would it
be better to say something like "if your root partition is extX you almost
certainly want to say Y here"?  Or warn about the rootfstype issue maybe?

	M

Re: [PATCH] update filesystems config. menu

[Dave Jones]

On Sat, Mar 15, 2003 at 02:19:40AM -0600, Mitch Adair wrote:

 > I seem to recall if you say Y to ext2 and Y to ext3 and your root is on ext3
 > then it's likely to be mounted as ext2 unless you set rootfstype=...
 > The ext3 help comment also warns you should set it to Y, so people with
 > root ext3 are likely to get a surprise if they follow both help.  Would it
 > be better to say something like "if your root partition is extX you almost
 > certainly want to say Y here"?  Or warn about the rootfstype issue maybe?

(03:40:50:davej@tetrachloride:davej)$ mount
/dev/hda5 on / type ext3 (rw,errors=remount-ro)

(08:40:13:davej@tetrachloride:davej)$ cat /proc/filesystems | grep ext
	ext3
	ext2

Note the ordering, ext3 gets tried before ext2.

		Dave

Re: [PATCH] update filesystems config. menu

[Mitch Adair]

> Note the ordering, ext3 gets tried before ext2.

Was thinking of the "ext3 clings to you like flypaper" thread of a couple
weeks ago, only backwards... -ESLEEPY

Anyway, I have seen instances where root got mounted ext2 instead of ext3
(faulty initrd or whatever it was) - just wondered if the help should really
push people to unreservedly say Y to ext2 if their root is really ext3...

	M

Re: [PATCH] update filesystems config. menu

[Martin Schlemmer]

On Sat, 2003-03-15 at 11:20, Mitch Adair wrote:

> Anyway, I have seen instances where root got mounted ext2 instead of ext3
> (faulty initrd or whatever it was) - just wondered if the help should really
> push people to unreservedly say Y to ext2 if their root is really ext3...
> 

Should be safest for most people .. those that have experience will
anyhow know to only compile in ext3 support, and ext2 as module (if
you ever fsck floppy/whatever as ext2).


Regards,

-- 
Martin Schlemmer

Re: [PATCH] update filesystems config. menu

[Randy.Dunlap]

> On Sat, 2003-03-15 at 11:20, Mitch Adair wrote:
>
>> Anyway, I have seen instances where root got mounted ext2 instead of ext3
>> (faulty initrd or whatever it was) - just wondered if the help should
>> really push people to unreservedly say Y to ext2 if their root is really
>> ext3...
>>
>
> Should be safest for most people .. those that have experience will anyhow
> know to only compile in ext3 support, and ext2 as module (if you ever fsck
> floppy/whatever as ext2).

Hi Martin,

I'm having trouble decoding...
What is it that "should be safest for most people"?
Are you suggesting any changes here?

And some of us don't use fs modules, just build what we need into the
kernel.  Do you know of any problems with doing this (related to
ext2/ext3 for example)?

Thanks,
~Randy

Re: [PATCH] update filesystems config. menu

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

On Sat, 15 Mar 2003 09:08:44 -0800 (PST)
"Randy.Dunlap" <rddunlap@osdl.org> wrote:


> I'm having trouble decoding...
> What is it that "should be safest for most people"?
> Are you suggesting any changes here?
> 
> And some of us don't use fs modules, just build what we need into the
> kernel.  Do you know of any problems with doing this (related to
> ext2/ext3 for example)?
> 

I was just saying that recommending it (ext2) compiled into the kernel
and not a module should be the safe route for newbies to kernel
compiles.

Those of us that have build a few to feel comfortable with it, will know
to compile the fs of our / partition into the kernel.

Except if ext2 is not the most commonly used fs anymore.  I guess a
'cool' feature could be if the make system could 'detect' what your
current root is and warn if you do not have that compiled into your
kernel, but I do not know the limitations of it (the make system).

Then on the other hand, would above be confusing if its a kernel
compiled for another box ?


Regards,

-- 

Martin Schlemmer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] update filesystems config. menu

[Randy.Dunlap]

> On Sat, 15 Mar 2003 09:08:44 -0800 (PST)
> "Randy.Dunlap" <rddunlap@osdl.org> wrote:
>
>> I'm having trouble decoding...
>> What is it that "should be safest for most people"?
>> Are you suggesting any changes here?
>>
>> And some of us don't use fs modules, just build what we need into the
>> kernel.  Do you know of any problems with doing this (related to ext2/ext3
>> for example)?
>>
>
> I was just saying that recommending it (ext2) compiled into the kernel and
> not a module should be the safe route for newbies to kernel
> compiles.

Thanks for the clarification.

> Those of us that have build a few to feel comfortable with it, will know to
> compile the fs of our / partition into the kernel.
>
> Except if ext2 is not the most commonly used fs anymore.  I guess a 'cool'
> feature could be if the make system could 'detect' what your current root is
> and warn if you do not have that compiled into your kernel, but I do not
> know the limitations of it (the make system).
>
> Then on the other hand, would above be confusing if its a kernel
> compiled for another box ?

Yes, I'd say so, although the message could say something like:
  Kernel does not include a filesystem for / on this computer.
And would it also have to check the capabilities of what's in the
initrd?  (not that I'm advocating any of this)

~Randy

Re: [PATCH] update filesystems config. menu

[jw schultz]

On Sat, Mar 15, 2003 at 01:31:59PM -0800, Randy.Dunlap wrote:
> > On Sat, 15 Mar 2003 09:08:44 -0800 (PST)
> > "Randy.Dunlap" <rddunlap@osdl.org> wrote:
> >
> >> I'm having trouble decoding...
> >> What is it that "should be safest for most people"?
> >> Are you suggesting any changes here?
> >>
> >> And some of us don't use fs modules, just build what we need into the
> >> kernel.  Do you know of any problems with doing this (related to ext2/ext3
> >> for example)?
> >>
> >
> > I was just saying that recommending it (ext2) compiled into the kernel and
> > not a module should be the safe route for newbies to kernel
> > compiles.
> 
> Thanks for the clarification.
> 
> > Those of us that have build a few to feel comfortable with it, will know to
> > compile the fs of our / partition into the kernel.
> >
> > Except if ext2 is not the most commonly used fs anymore.  I guess a 'cool'
> > feature could be if the make system could 'detect' what your current root is
> > and warn if you do not have that compiled into your kernel, but I do not
> > know the limitations of it (the make system).
> >
> > Then on the other hand, would above be confusing if its a kernel
> > compiled for another box ?
> 
> Yes, I'd say so, although the message could say something like:
>   Kernel does not include a filesystem for / on this computer.
> And would it also have to check the capabilities of what's in the
> initrd?  (not that I'm advocating any of this)

To me that sounds like a feature for the bootloader
config tool.  That is the first time you have a firm
kernel to rootfs connection. 

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: [PATCH] update filesystems config. menu

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

On Sat, 15 Mar 2003 13:31:59 PST, "Randy.Dunlap" said:

> Yes, I'd say so, although the message could say something like:
>   Kernel does not include a filesystem for / on this computer.
> And would it also have to check the capabilities of what's in the
> initrd?  (not that I'm advocating any of this)

Well... the only time *I*'ve screwed it up was building with ext3 only,
having all ext3 filesystems on the disk, and watching Bad And Ugly things
happen when the ext2-format initrd tried to mount...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Warning message during linux kernel 2.4.21 compilation (ymfpci.c)

[Pete Zaitcev]

> Date: Sun, 22 Jun 2003 05:10:13 +0900
> From: Ishikawa <ishikawa@yk.rim.or.jp>

> It certainly looks that  something is wrong with the code.
> (Maybe some masking of the eid and the immediate value is missing?)

>    u16 eid;
> 	...

>    2462	eid = ymfpci_codec_read(codec, AC97_EXTENDED_ID);
> -->2463	if (eid==0xFFFFFF) {
> 		printk(KERN_WARNING "ymfpci: no codec attached ?\n");
> 		goto out_kfree;
> 	}

This is indeed a bug, and ymfpci inherits it from cs46xx.c.
I wonder why cs46xx.c does not trigger a warning.

Since the check never worked and nobody ever complained,
I think the best fix is to remove the "if" statement with
its block. If we repair the comparison to "eid == 0xFFFF",
then we run a risk of breaking previously working systems.

-- Pete

Re: Adaptec DPT_I2O Driver

[Jason Van Patten]

At Thu Dec 18 08:27:32 2003, jvp wrote:
> In the 2.6 tree, the driver drivers/scsi/dpt_i2o.c has a #error in it that
> prevents it from being compiled.  The note in the file is:
> 
> #error Please convert me to Documentation/DMA-mapping.txt

Can I assume that because no one's replied to my question regarding this
broken driver, that no one's currently working on it?

jas
-- 
Jason Van Patten
AOL IM: Jason VP 

Re: SCO's infringing files list

[Rick Bressler]

> Does anybody have old CD-ROM's lying around?

I have some original Slackware CD's:

slackware.3.2.lst:DISK2: /cdrom/sunsite/libs/oldlibs/libc-2.2.2/00_index.txt
slackware.3.2.lst:DISK2: /cdrom/sunsite/libs/oldlibs/libc-2.2.2/00_TRANS.TBL
slackware.3.2.lst:DISK2: /cdrom/sunsite/libs/oldlibs/libc-2.2.2/libc.2.2.2.z
slackware.3.2.lst:DISK2: /cdrom/sunsite/libs/oldlibs/libc-2.2.2/libm.2.2.2.z
slackware.3.4.lst:DISK3: sunsite/libs/oldlibs/libc-2.2.2
slackware.3.4.lst:DISK3: sunsite/libs/oldlibs/libc-2.2.2/00_index.txt
slackware.3.4.lst:DISK3: sunsite/libs/oldlibs/libc-2.2.2/libc.2.2.2.z
slackware.3.4.lst:DISK3: sunsite/libs/oldlibs/libc-2.2.2/libm.2.2.2.z

If you want them as 'evidence' I will be happy to mail them to you. 



-- 
Rick Bressler                                      rick@the-bresslers.com
   Eagles may soar, but weasels never get sucked into jet air intakes.

Re: printf() overhead

[Alan Curry]

John Richard Moser writes the following:
>Andre Tomt wrote:
>| John Richard Moser wrote:
>|> using strace to run a program takes aeons.  Redirecting the output to a
>|> file can be a hundred times faster sometimes.  This raises question.
>|
>| The terminal is a major factor; gnome-terminal for example can be
>| *extremely* slow.
>|
>
>Is there a way to give the data to the terminal and let the program go
>while that happens?  Or is there an execution path (i.e. terminal says
>"WTF NO") that can be missed that way?

strace -o tracefile prog & tail -n +1 -f tracefile

Re: SVGATextMode on 2.6.11

[Alan Curry]

I wrote:
>
>Was SVGATextMode's cursor-setting ability removed as a result of an
>intentional change, or might it get fixed? Or might CUR_DEFAULT become
>tunable? Maybe another control sequence could make the current cursor
>settings the default, like setterm -store does for foreground and background
>colors.

I found the cause of this new behavior: font loading. SVGATextMode can be
configured to load a font with consolechars. It does that after setting the
cursor. In 2.6.11 vgacon_adjust_height() was changed to reset the cursor in
addition to the font size. The solution is: disable SVGATextMode's font
loading, and if you want to change the font, do it before you run SVGATextMode.

The second problem remains a mystery:

>On another note, the resize function of SVGATextMode has been affected
>strangely too. Sometimes, when resizing the screen to a mode larger than
>80x25, the video settings come out correctly but the terminal only uses the
>first 25 lines, with the bottom of the screen being blank. This one is hard
>to reproduce. I can reproduce it by doing a full boot (which includes an
>SVGATextMode call from /etc/rcS.d/S60svgatextmode) followed by a manual
>SVGATextMode on tty2. The first one works, and the second one screws up the
>terminal size. When I try to reproduce that series of events without the call
>from /etc/rcS.d, the problem doesn't show up.
>
>In any case, when that problem _does_ show up, it can be fixed by immediately
>running the same command again, on the same tty where it just screwed up. And
>it never fails twice without an intervening reboot.

Re: strace on cat /proc/my_file gives results by calling read twice why?

[Alan Curry]

cranium2003 writes the following:
>
>when i strace cat /proc/my_file i found message
>printing twice
>Reading a from a /proc file....
>Reading a from a /proc file....
>       Why that happening?

The first read returns some data and returns the number of bytes, and the
second one indicates that EOF has been reached by returning 0. A single read
call can't do both of those things, so cat needs to do 2 reads.

This has nothing to do with /proc or Linux; it is a logical consequence of
the way read() is defined, and the job cat is supposed to do: it copies
entire files to stdout, so it has to read until EOF. Only if the input file
is empty will it see the EOF on the first read.

[PATCH] Assign task_struct.exit_code before taskstats_exit()

[Jonathan Lim]

taskstats.ac_exitcode is assigned to task_struct.exit_code in bacct_add_tsk()
through the following kernel function calls: 

  do_exit()
    taskstats_exit()
      fill_pid()
        bacct_add_tsk()

The problem is that in do_exit(), task_struct.exit_code is set to 'code' only
after taskstats_exit() has been called.  So we need to move the assignment
before taskstats_exit().

Diff'd against: linux/kernel/git/stable/linux-2.6.22.y.git

Signed-off-by: Jonathan Lim <jlim@sgi.com>

--- a/kernel/exit.c	2007-08-20 16:37:55.000000000 -0700
+++ b/kernel/exit.c	2007-08-21 11:00:56.000000000 -0700
@@ -941,6 +941,7 @@ fastcall NORET_TYPE void do_exit(long co
 	if (unlikely(tsk->audit_context))
 		audit_free(tsk);
 
+	tsk->exit_code = code;
 	taskstats_exit(tsk, group_dead);
 
 	exit_mm(tsk);
@@ -961,7 +962,6 @@ fastcall NORET_TYPE void do_exit(long co
 	if (tsk->binfmt)
 		module_put(tsk->binfmt->module);
 
-	tsk->exit_code = code;
 	proc_exit_connector(tsk);
 	exit_task_namespaces(tsk);
 	exit_notify(tsk);

Re: [PATCH] Provide u64 version of jiffies_to_usecs() in kernel/tsacct.c

[Jonathan Lim]

It's possible that the values used in and returned from jiffies_to_usecs() are
incorrect because of truncation when variables of type u64 are involved.  So a
function specific to that type is used instead.

Updated from previous submission with feedback from Peter Anvin.

Diff'd against: linux/kernel/git/torvalds/linux-2.6.git

Signed-off-by: Jonathan Lim <jlim@sgi.com>

--- a/include/linux/jiffies.h	2008-01-07 16:09:17.737040981 -0800
+++ b/include/linux/jiffies.h	2008-01-07 16:09:17.693033003 -0800
@@ -36,7 +36,7 @@
 /* LATCH is used in the interval timer and ftape setup. */
 #define LATCH  ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
 
-/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, then we can
+/* Suppose we want to divide two numbers NOM and DEN: NOM/DEN, then we can
  * improve accuracy by shifting LSH bits, hence calculating:
  *     (NOM << LSH) / DEN
  * This however means trouble for large NOM, because (NOM << LSH) may no
@@ -198,7 +198,7 @@ extern unsigned long preset_lpj;
  * operator if the result is a long long AND at least one of the
  * operands is cast to long long (usually just prior to the "*" so as
  * not to confuse it into thinking it really has a 64-bit operand,
- * which, buy the way, it can do, but it takes more code and at least 2
+ * which, by the way, it can do, but it takes more code and at least 2
  * mpys).
 
  * We also need to be aware that one second in nanoseconds is only a
@@ -263,6 +263,7 @@ extern unsigned long preset_lpj;
  */
 extern unsigned int jiffies_to_msecs(const unsigned long j);
 extern unsigned int jiffies_to_usecs(const unsigned long j);
+extern u64 jiffies_64_to_usecs(const u64 j);
 extern unsigned long msecs_to_jiffies(const unsigned int m);
 extern unsigned long usecs_to_jiffies(const unsigned int u);
 extern unsigned long timespec_to_jiffies(const struct timespec *value);
--- a/kernel/time.c	2008-01-07 16:09:17.841059839 -0800
+++ b/kernel/time.c	2008-01-07 16:09:17.825056938 -0800
@@ -267,6 +267,12 @@ unsigned int inline jiffies_to_usecs(con
 }
 EXPORT_SYMBOL(jiffies_to_usecs);
 
+u64 inline jiffies_64_to_usecs(const u64 j)
+{
+	return (j*HZ_TO_USEC_NUM + HZ_TO_USEC_DEN-1) / HZ_TO_USEC_DEN;
+}
+EXPORT_SYMBOL(jiffies_64_to_usecs);
+
 /**
  * timespec_trunc - Truncate timespec to a granularity
  * @t: Timespec
--- a/kernel/tsacct.c	2008-01-07 16:09:17.833058389 -0800
+++ b/kernel/tsacct.c	2008-01-07 16:09:17.793051136 -0800
@@ -85,8 +85,8 @@ void xacct_add_tsk(struct taskstats *sta
 	struct mm_struct *mm;
 
 	/* convert pages-jiffies to Mbyte-usec */
-	stats->coremem = jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
-	stats->virtmem = jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
+	stats->coremem = jiffies_64_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
+	stats->virtmem = jiffies_64_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
 	mm = get_task_mm(p);
 	if (mm) {
 		/* adjust to KB unit */

Re: [PATCH] Provide u64 version of jiffies_to_usecs() in kernel/tsacct.c

[Jonathan Lim]

It's possible that the values used in and returned from jiffies_to_usecs() are
incorrect because of truncation when variables of type u64 are involved.  So a
function specific to that type is used instead.

Diff'd against: linux/kernel/git/torvalds/linux-2.6.git

Signed-off-by: Jonathan Lim <jlim@sgi.com>

--- a/include/linux/jiffies.h	Thu Feb 14 18:04:14 PST 2008
+++ b/include/linux/jiffies.h	Thu Feb 14 18:07:17 PST 2008
@@ -42,7 +42,7 @@
 /* LATCH is used in the interval timer and ftape setup. */
 #define LATCH  ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
 
-/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, then we can
+/* Suppose we want to divide two numbers NOM and DEN: NOM/DEN, then we can
  * improve accuracy by shifting LSH bits, hence calculating:
  *     (NOM << LSH) / DEN
  * This however means trouble for large NOM, because (NOM << LSH) may no
@@ -204,7 +204,7 @@ extern unsigned long preset_lpj;
  * operator if the result is a long long AND at least one of the
  * operands is cast to long long (usually just prior to the "*" so as
  * not to confuse it into thinking it really has a 64-bit operand,
- * which, buy the way, it can do, but it takes more code and at least 2
+ * which, by the way, it can do, but it takes more code and at least 2
  * mpys).
 
  * We also need to be aware that one second in nanoseconds is only a
@@ -269,6 +269,7 @@ extern unsigned long preset_lpj;
  */
 extern unsigned int jiffies_to_msecs(const unsigned long j);
 extern unsigned int jiffies_to_usecs(const unsigned long j);
+extern u64 jiffies_64_to_usecs(const u64 j);
 extern unsigned long msecs_to_jiffies(const unsigned int m);
 extern unsigned long usecs_to_jiffies(const unsigned int u);
 extern unsigned long timespec_to_jiffies(const struct timespec *value);
--- a/kernel/time.c	Thu Feb 14 18:05:12 PST 2008
+++ b/kernel/time.c	Tue Feb 19 12:44:03 PST 2008
@@ -268,6 +268,14 @@ unsigned int inline jiffies_to_usecs(con
 }
 EXPORT_SYMBOL(jiffies_to_usecs);
 
+u64 inline jiffies_64_to_usecs(const u64 j)
+{
+	u64 tmp = j*HZ_TO_USEC_NUM + HZ_TO_USEC_DEN-1;
+	do_div(tmp, HZ_TO_USEC_DEN);
+	return tmp;
+}
+EXPORT_SYMBOL(jiffies_64_to_usecs);
+
 /**
  * timespec_trunc - Truncate timespec to a granularity
  * @t: Timespec
--- a/kernel/tsacct.c	Thu Feb 14 18:06:17 PST 2008
+++ b/kernel/tsacct.c	Thu Feb 14 18:08:47 PST 2008
@@ -85,8 +85,8 @@ void xacct_add_tsk(struct taskstats *sta
 	struct mm_struct *mm;
 
 	/* convert pages-jiffies to Mbyte-usec */
-	stats->coremem = jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
-	stats->virtmem = jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
+	stats->coremem = jiffies_64_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
+	stats->virtmem = jiffies_64_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
 	mm = get_task_mm(p);
 	if (mm) {
 		/* adjust to KB unit */

Re: [PATCH] Provide u64 version of jiffies_to_usecs() in kernel/tsacct.c

[Randy Dunlap]

On Tue, 19 Feb 2008 12:52:46 -0800 (PST) Jonathan Lim wrote:

> It's possible that the values used in and returned from jiffies_to_usecs() are
> incorrect because of truncation when variables of type u64 are involved.  So a
> function specific to that type is used instead.
> 
> Diff'd against: linux/kernel/git/torvalds/linux-2.6.git
> 
> Signed-off-by: Jonathan Lim <jlim@sgi.com>
> 
> --- a/include/linux/jiffies.h	Thu Feb 14 18:04:14 PST 2008
> +++ b/include/linux/jiffies.h	Thu Feb 14 18:07:17 PST 2008
> @@ -42,7 +42,7 @@
>  /* LATCH is used in the interval timer and ftape setup. */
>  #define LATCH  ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
>  
> -/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, then we can
> +/* Suppose we want to divide two numbers NOM and DEN: NOM/DEN, then we can
>   * improve accuracy by shifting LSH bits, hence calculating:
>   *     (NOM << LSH) / DEN
>   * This however means trouble for large NOM, because (NOM << LSH) may no
> @@ -204,7 +204,7 @@ extern unsigned long preset_lpj;
>   * operator if the result is a long long AND at least one of the
>   * operands is cast to long long (usually just prior to the "*" so as
>   * not to confuse it into thinking it really has a 64-bit operand,
> - * which, buy the way, it can do, but it takes more code and at least 2
> + * which, by the way, it can do, but it takes more code and at least 2
>   * mpys).
>  
>   * We also need to be aware that one second in nanoseconds is only a
> @@ -269,6 +269,7 @@ extern unsigned long preset_lpj;
>   */
>  extern unsigned int jiffies_to_msecs(const unsigned long j);
>  extern unsigned int jiffies_to_usecs(const unsigned long j);
> +extern u64 jiffies_64_to_usecs(const u64 j);
>  extern unsigned long msecs_to_jiffies(const unsigned int m);
>  extern unsigned long usecs_to_jiffies(const unsigned int u);
>  extern unsigned long timespec_to_jiffies(const struct timespec *value);
> --- a/kernel/time.c	Thu Feb 14 18:05:12 PST 2008
> +++ b/kernel/time.c	Tue Feb 19 12:44:03 PST 2008
> @@ -268,6 +268,14 @@ unsigned int inline jiffies_to_usecs(con
>  }
>  EXPORT_SYMBOL(jiffies_to_usecs);
>  
> +u64 inline jiffies_64_to_usecs(const u64 j)
> +{
> +	u64 tmp = j*HZ_TO_USEC_NUM + HZ_TO_USEC_DEN-1;
> +	do_div(tmp, HZ_TO_USEC_DEN);

do_div() is:
 * The semantics of do_div() are:
 *
 * uint32_t do_div(uint64_t *n, uint32_t base)

Maybe you want div64_64().

> +	return tmp;
> +}
> +EXPORT_SYMBOL(jiffies_64_to_usecs);
> +
>  /**
>   * timespec_trunc - Truncate timespec to a granularity
>   * @t: Timespec
> --- a/kernel/tsacct.c	Thu Feb 14 18:06:17 PST 2008
> +++ b/kernel/tsacct.c	Thu Feb 14 18:08:47 PST 2008
> @@ -85,8 +85,8 @@ void xacct_add_tsk(struct taskstats *sta
>  	struct mm_struct *mm;
>  
>  	/* convert pages-jiffies to Mbyte-usec */
> -	stats->coremem = jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
> -	stats->virtmem = jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
> +	stats->coremem = jiffies_64_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
> +	stats->virtmem = jiffies_64_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
>  	mm = get_task_mm(p);
>  	if (mm) {
>  		/* adjust to KB unit */
> --


---
~Randy

Re: [PATCH] Provide u64 version of jiffies_to_usecs() in

[Jonathan Lim]

On Tue Feb 19 13:25:25 2008, randy.dunlap@oracle.com wrote:
> 
> > +u64 inline jiffies_64_to_usecs(const u64 j)
> > +{
> > +	u64 tmp = j*HZ_TO_USEC_NUM + HZ_TO_USEC_DEN-1;
> > +	do_div(tmp, HZ_TO_USEC_DEN);
> 
> do_div() is:
>  * The semantics of do_div() are:
>  *
>  * uint32_t do_div(uint64_t *n, uint32_t base)
> 
> Maybe you want div64_64().
> 
> > +	return tmp;
> > +}
> > +EXPORT_SYMBOL(jiffies_64_to_usecs);
> > +

In include/asm-generic/div64.h, div64_64(uint64_t dividend, uint64_t divisor)
just returns (dividend / divisor).  Isn't this the same as what I had before
in jiffies_64_to_usecs(), except that the arguments are of type u64?

Jonathan

Re: [PATCH] Provide u64 version of jiffies_to_usecs() in

[Randy Dunlap]

On Tue, 19 Feb 2008 13:59:27 -0800 (PST) Jonathan Lim wrote:

> On Tue Feb 19 13:25:25 2008, randy.dunlap@oracle.com wrote:
> > 
> > > +u64 inline jiffies_64_to_usecs(const u64 j)
> > > +{
> > > +	u64 tmp = j*HZ_TO_USEC_NUM + HZ_TO_USEC_DEN-1;
> > > +	do_div(tmp, HZ_TO_USEC_DEN);
> > 
> > do_div() is:
> >  * The semantics of do_div() are:
> >  *
> >  * uint32_t do_div(uint64_t *n, uint32_t base)
> > 
> > Maybe you want div64_64().
> > 
> > > +	return tmp;
> > > +}
> > > +EXPORT_SYMBOL(jiffies_64_to_usecs);
> > > +
> 
> In include/asm-generic/div64.h, div64_64(uint64_t dividend, uint64_t divisor)
> just returns (dividend / divisor).  Isn't this the same as what I had before
> in jiffies_64_to_usecs(), except that the arguments are of type u64?

but the (linker) problem is with X86_32, so don't look at
asm-generic/div64.h.  Look at lib/div64.c.

Or use div64() with the correct parameter types.

---
~Randy

Re: [PATCH] Provide u64 version of jiffies_to_usecs() in kernel/tsacct.c

[Jonathan Lim]

It's possible that the values used in and returned from jiffies_to_usecs() are
incorrect because of truncation when variables of type u64 are involved.  So a
function specific to that type is used instead.

This version implements a correction to jiffies_64_to_usecs() based on feedback
from Randy Dunlap.

Diff'd against: linux/kernel/git/torvalds/linux-2.6.git

Signed-off-by: Jonathan Lim <jlim@sgi.com>

--- a/include/linux/jiffies.h	Thu Feb 14 18:04:14 PST 2008
+++ b/include/linux/jiffies.h	Thu Feb 14 18:07:17 PST 2008
@@ -42,7 +42,7 @@
 /* LATCH is used in the interval timer and ftape setup. */
 #define LATCH  ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
 
-/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, then we can
+/* Suppose we want to divide two numbers NOM and DEN: NOM/DEN, then we can
  * improve accuracy by shifting LSH bits, hence calculating:
  *     (NOM << LSH) / DEN
  * This however means trouble for large NOM, because (NOM << LSH) may no
@@ -204,7 +204,7 @@ extern unsigned long preset_lpj;
  * operator if the result is a long long AND at least one of the
  * operands is cast to long long (usually just prior to the "*" so as
  * not to confuse it into thinking it really has a 64-bit operand,
- * which, buy the way, it can do, but it takes more code and at least 2
+ * which, by the way, it can do, but it takes more code and at least 2
  * mpys).
 
  * We also need to be aware that one second in nanoseconds is only a
@@ -269,6 +269,7 @@ extern unsigned long preset_lpj;
  */
 extern unsigned int jiffies_to_msecs(const unsigned long j);
 extern unsigned int jiffies_to_usecs(const unsigned long j);
+extern u64 jiffies_64_to_usecs(const u64 j);
 extern unsigned long msecs_to_jiffies(const unsigned int m);
 extern unsigned long usecs_to_jiffies(const unsigned int u);
 extern unsigned long timespec_to_jiffies(const struct timespec *value);
--- a/kernel/time.c	Thu Feb 14 18:05:12 PST 2008
+++ b/kernel/time.c	Tue Feb 19 17:00:11 PST 2008
@@ -268,6 +268,12 @@ unsigned int inline jiffies_to_usecs(con
 }
 EXPORT_SYMBOL(jiffies_to_usecs);
 
+u64 jiffies_64_to_usecs(const u64 j)
+{
+	return div64_64(j*HZ_TO_USEC_NUM + HZ_TO_USEC_DEN-1, HZ_TO_USEC_DEN);
+}
+EXPORT_SYMBOL(jiffies_64_to_usecs);
+
 /**
  * timespec_trunc - Truncate timespec to a granularity
  * @t: Timespec
--- a/kernel/tsacct.c	Thu Feb 14 18:06:17 PST 2008
+++ b/kernel/tsacct.c	Thu Feb 14 18:08:47 PST 2008
@@ -85,8 +85,8 @@ void xacct_add_tsk(struct taskstats *sta
 	struct mm_struct *mm;
 
 	/* convert pages-jiffies to Mbyte-usec */
-	stats->coremem = jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
-	stats->virtmem = jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
+	stats->coremem = jiffies_64_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
+	stats->virtmem = jiffies_64_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
 	mm = get_task_mm(p);
 	if (mm) {
 		/* adjust to KB unit */

Re: [PATCH] Provide u64 version of jiffies_to_usecs() in kernel/tsacct.c

[Randy Dunlap]

Jonathan Lim wrote:
> It's possible that the values used in and returned from jiffies_to_usecs() are
> incorrect because of truncation when variables of type u64 are involved.  So a
> function specific to that type is used instead.
> 
> This version implements a correction to jiffies_64_to_usecs() based on feedback
> from Randy Dunlap.
> 
> Diff'd against: linux/kernel/git/torvalds/linux-2.6.git
> 
> Signed-off-by: Jonathan Lim <jlim@sgi.com>
> 
> --- a/include/linux/jiffies.h	Thu Feb 14 18:04:14 PST 2008
> +++ b/include/linux/jiffies.h	Thu Feb 14 18:07:17 PST 2008
> @@ -42,7 +42,7 @@
>  /* LATCH is used in the interval timer and ftape setup. */
>  #define LATCH  ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
>  
> -/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, then we can
> +/* Suppose we want to divide two numbers NOM and DEN: NOM/DEN, then we can
>   * improve accuracy by shifting LSH bits, hence calculating:
>   *     (NOM << LSH) / DEN
>   * This however means trouble for large NOM, because (NOM << LSH) may no
> @@ -204,7 +204,7 @@ extern unsigned long preset_lpj;
>   * operator if the result is a long long AND at least one of the
>   * operands is cast to long long (usually just prior to the "*" so as
>   * not to confuse it into thinking it really has a 64-bit operand,
> - * which, buy the way, it can do, but it takes more code and at least 2
> + * which, by the way, it can do, but it takes more code and at least 2
>   * mpys).
>  
>   * We also need to be aware that one second in nanoseconds is only a
> @@ -269,6 +269,7 @@ extern unsigned long preset_lpj;
>   */
>  extern unsigned int jiffies_to_msecs(const unsigned long j);
>  extern unsigned int jiffies_to_usecs(const unsigned long j);
> +extern u64 jiffies_64_to_usecs(const u64 j);
>  extern unsigned long msecs_to_jiffies(const unsigned int m);
>  extern unsigned long usecs_to_jiffies(const unsigned int u);
>  extern unsigned long timespec_to_jiffies(const struct timespec *value);
> --- a/kernel/time.c	Thu Feb 14 18:05:12 PST 2008
> +++ b/kernel/time.c	Tue Feb 19 17:00:11 PST 2008

kernel/time.c needs:
#include <asm/div64.h>

After that, it's
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>

> @@ -268,6 +268,12 @@ unsigned int inline jiffies_to_usecs(con
>  }
>  EXPORT_SYMBOL(jiffies_to_usecs);
>  
> +u64 jiffies_64_to_usecs(const u64 j)
> +{
> +	return div64_64(j*HZ_TO_USEC_NUM + HZ_TO_USEC_DEN-1, HZ_TO_USEC_DEN);
> +}
> +EXPORT_SYMBOL(jiffies_64_to_usecs);
> +
>  /**
>   * timespec_trunc - Truncate timespec to a granularity
>   * @t: Timespec
> --- a/kernel/tsacct.c	Thu Feb 14 18:06:17 PST 2008
> +++ b/kernel/tsacct.c	Thu Feb 14 18:08:47 PST 2008
> @@ -85,8 +85,8 @@ void xacct_add_tsk(struct taskstats *sta
>  	struct mm_struct *mm;
>  
>  	/* convert pages-jiffies to Mbyte-usec */
> -	stats->coremem = jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
> -	stats->virtmem = jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
> +	stats->coremem = jiffies_64_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
> +	stats->virtmem = jiffies_64_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
>  	mm = get_task_mm(p);
>  	if (mm) {
>  		/* adjust to KB unit */


-- 
~Randy

Re: [PATCH] Provide u64 version of jiffies_to_usecs() in kernel/tsacct.c

[Jonathan Lim]

It's possible that the values used in and returned from jiffies_to_usecs() are
incorrect because of truncation when variables of type u64 are involved.  So a
function specific to that type is used instead.

This version implements a correction to jiffies_64_to_usecs() based on feedback
from Randy Dunlap.

Diff'd against: linux/kernel/git/torvalds/linux-2.6.git

Signed-off-by: Jonathan Lim <jlim@sgi.com>

--- a/include/linux/jiffies.h	Thu Feb 14 18:04:14 PST 2008
+++ b/include/linux/jiffies.h	Thu Feb 14 18:07:17 PST 2008
@@ -42,7 +42,7 @@
 /* LATCH is used in the interval timer and ftape setup. */
 #define LATCH  ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
 
-/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, then we can
+/* Suppose we want to divide two numbers NOM and DEN: NOM/DEN, then we can
  * improve accuracy by shifting LSH bits, hence calculating:
  *     (NOM << LSH) / DEN
  * This however means trouble for large NOM, because (NOM << LSH) may no
@@ -204,7 +204,7 @@ extern unsigned long preset_lpj;
  * operator if the result is a long long AND at least one of the
  * operands is cast to long long (usually just prior to the "*" so as
  * not to confuse it into thinking it really has a 64-bit operand,
- * which, buy the way, it can do, but it takes more code and at least 2
+ * which, by the way, it can do, but it takes more code and at least 2
  * mpys).
 
  * We also need to be aware that one second in nanoseconds is only a
@@ -269,6 +269,7 @@ extern unsigned long preset_lpj;
  */
 extern unsigned int jiffies_to_msecs(const unsigned long j);
 extern unsigned int jiffies_to_usecs(const unsigned long j);
+extern u64 jiffies_64_to_usecs(const u64 j);
 extern unsigned long msecs_to_jiffies(const unsigned int m);
 extern unsigned long usecs_to_jiffies(const unsigned int u);
 extern unsigned long timespec_to_jiffies(const struct timespec *value);
--- a/kernel/time.c	Thu Feb 14 18:05:12 PST 2008
+++ b/kernel/time.c	Mon Feb 25 14:22:27 PST 2008
@@ -38,6 +38,7 @@
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
+#include <asm/div64.h>
 
 #include "timeconst.h"
 
@@ -267,6 +268,12 @@ unsigned int inline jiffies_to_usecs(con
 #endif
 }
 EXPORT_SYMBOL(jiffies_to_usecs);
+
+u64 jiffies_64_to_usecs(const u64 j)
+{
+	return div64_64(j*HZ_TO_USEC_NUM + HZ_TO_USEC_DEN-1, HZ_TO_USEC_DEN);
+}
+EXPORT_SYMBOL(jiffies_64_to_usecs);
 
 /**
  * timespec_trunc - Truncate timespec to a granularity
--- a/kernel/tsacct.c	Thu Feb 14 18:06:17 PST 2008
+++ b/kernel/tsacct.c	Thu Feb 14 18:08:47 PST 2008
@@ -85,8 +85,8 @@ void xacct_add_tsk(struct taskstats *sta
 	struct mm_struct *mm;
 
 	/* convert pages-jiffies to Mbyte-usec */
-	stats->coremem = jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
-	stats->virtmem = jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
+	stats->coremem = jiffies_64_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
+	stats->virtmem = jiffies_64_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
 	mm = get_task_mm(p);
 	if (mm) {
 		/* adjust to KB unit */

Re: [PATCH] Provide u64 version of jiffies_to_usecs() in kernel/tsacct.c

[Roman Zippel]

Hi,

On Monday 25. February 2008, Jonathan Lim wrote:

> +u64 jiffies_64_to_usecs(const u64 j)
> +{
> +	return div64_64(j*HZ_TO_USEC_NUM + HZ_TO_USEC_DEN-1, HZ_TO_USEC_DEN);
> +}
> +EXPORT_SYMBOL(jiffies_64_to_usecs);

Please also adapt the "BITS_PER_LONG == 32" part from jiffies_to_usecs(), it 
should provide enough resolution to avoid the div64_64() here.

bye, Roman

Re: [PATCH] Provide u64 version of jiffies_to_usecs() in kernel/tsacct.c

[Jonathan Lim]

It's possible that the values used in and returned from jiffies_to_usecs() are
incorrect because of truncation when variables of type u64 are involved.  So a
function specific to that type is used instead.

This version implements a correction to jiffies_64_to_usecs() based on feedback
from Randy Dunlap and Roman Zippel.

Diff'd against: linux/kernel/git/torvalds/linux-2.6.git

Signed-off-by: Jonathan Lim <jlim@sgi.com>

--- a/include/linux/jiffies.h	Thu Feb 14 18:04:14 PST 2008
+++ b/include/linux/jiffies.h	Thu Feb 14 18:07:17 PST 2008
@@ -42,7 +42,7 @@
 /* LATCH is used in the interval timer and ftape setup. */
 #define LATCH  ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
 
-/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, then we can
+/* Suppose we want to divide two numbers NOM and DEN: NOM/DEN, then we can
  * improve accuracy by shifting LSH bits, hence calculating:
  *     (NOM << LSH) / DEN
  * This however means trouble for large NOM, because (NOM << LSH) may no
@@ -204,7 +204,7 @@ extern unsigned long preset_lpj;
  * operator if the result is a long long AND at least one of the
  * operands is cast to long long (usually just prior to the "*" so as
  * not to confuse it into thinking it really has a 64-bit operand,
- * which, buy the way, it can do, but it takes more code and at least 2
+ * which, by the way, it can do, but it takes more code and at least 2
  * mpys).
 
  * We also need to be aware that one second in nanoseconds is only a
@@ -269,6 +269,7 @@ extern unsigned long preset_lpj;
  */
 extern unsigned int jiffies_to_msecs(const unsigned long j);
 extern unsigned int jiffies_to_usecs(const unsigned long j);
+extern u64 jiffies_64_to_usecs(const u64 j);
 extern unsigned long msecs_to_jiffies(const unsigned int m);
 extern unsigned long usecs_to_jiffies(const unsigned int u);
 extern unsigned long timespec_to_jiffies(const struct timespec *value);
--- a/kernel/time.c	Thu Feb 14 18:05:12 PST 2008
+++ b/kernel/time.c	Fri Apr 18 14:44:54 PDT 2008
@@ -38,6 +38,7 @@
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
+#include <asm/div64.h>
 
 #include "timeconst.h"
 
@@ -267,6 +268,16 @@ unsigned int inline jiffies_to_usecs(con
 #endif
 }
 EXPORT_SYMBOL(jiffies_to_usecs);
+
+u64 jiffies_64_to_usecs(const u64 j)
+{
+# if BITS_PER_LONG == 32
+	return ((u64)HZ_TO_USEC_MUL32 * j) >> HZ_TO_USEC_SHR32;
+# else
+	return div64_64(j*HZ_TO_USEC_NUM + HZ_TO_USEC_DEN-1, HZ_TO_USEC_DEN);
+# endif
+}
+EXPORT_SYMBOL(jiffies_64_to_usecs);
 
 /**
  * timespec_trunc - Truncate timespec to a granularity
--- a/kernel/tsacct.c	Thu Feb 14 18:06:17 PST 2008
+++ b/kernel/tsacct.c	Thu Feb 14 18:08:47 PST 2008
@@ -85,8 +85,8 @@ void xacct_add_tsk(struct taskstats *sta
 	struct mm_struct *mm;
 
 	/* convert pages-jiffies to Mbyte-usec */
-	stats->coremem = jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
-	stats->virtmem = jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
+	stats->coremem = jiffies_64_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
+	stats->virtmem = jiffies_64_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
 	mm = get_task_mm(p);
 	if (mm) {
 		/* adjust to KB unit */

[PATCH] Account for user time when updating memory integrals

[Jonathan Lim]

This patch adapts acct_update_integrals() to include user time when calculating
the time difference.  The units of acct_rss_mem1 and acct_vm_mem1 are also
changed from pages-jiffies to pages-usecs to avoid calling jiffies_to_usecs()
in xacct_add_tsk() which might overflow.

This patch obsoletes:

  provide-u64-version-of-jiffies_to_usecs-in-kernel-tsacctc.patch

Signed-off-by: Jonathan Lim <jlim@sgi.com>


--- a/include/linux/sched.h	2008-04-07 15:54:08.000000000 -0700
+++ b/include/linux/sched.h	2008-04-18 15:17:52.996000000 -0700
@@ -940,7 +940,7 @@ struct task_struct {
 #if defined(CONFIG_TASK_XACCT)
 	u64 acct_rss_mem1;	/* accumulated rss usage */
 	u64 acct_vm_mem1;	/* accumulated virtual memory usage */
-	cputime_t acct_stimexpd;/* stime since last update */
+	cputime_t acct_timexpd;	/* stime + utime since last update */
 #endif
 #ifdef CONFIG_NUMA
   	struct mempolicy *mempolicy;
--- a/kernel/tsacct.c	2008-04-07 15:53:52.000000000 -0700
+++ b/kernel/tsacct.c	2008-04-29 16:22:35.888000000 -0700
@@ -81,9 +81,9 @@ void bacct_add_tsk(struct taskstats *sta
  */
 void xacct_add_tsk(struct taskstats *stats, struct task_struct *p)
 {
-	/* convert pages-jiffies to Mbyte-usec */
-	stats->coremem = jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
-	stats->virtmem = jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
+	/* convert pages-usec to Mbyte-usec */
+	stats->coremem = p->acct_rss_mem1 * PAGE_SIZE / MB;
+	stats->virtmem = p->acct_vm_mem1 * PAGE_SIZE / MB;
 	if (p->mm) {
 		/* adjust to KB unit */
 		stats->hiwater_rss   = p->mm->hiwater_rss * PAGE_SIZE / KB;
@@ -104,12 +104,19 @@ void xacct_add_tsk(struct taskstats *sta
 void acct_update_integrals(struct task_struct *tsk)
 {
 	if (likely(tsk->mm)) {
-		long delta = cputime_to_jiffies(
-			cputime_sub(tsk->stime, tsk->acct_stimexpd));
+		cputime_t time, dtime;
+		struct timeval value;
+		u64 delta;
+
+		time = tsk->stime + tsk->utime;
+		dtime = cputime_sub(time, tsk->acct_timexpd);
+		jiffies_to_timeval(cputime_to_jiffies(dtime), &value);
+		delta = value.tv_sec;
+		delta = delta * USEC_PER_SEC + value.tv_usec;
 
 		if (delta == 0)
 			return;
-		tsk->acct_stimexpd = tsk->stime;
+		tsk->acct_timexpd = time;
 		tsk->acct_rss_mem1 += delta * get_mm_rss(tsk->mm);
 		tsk->acct_vm_mem1 += delta * tsk->mm->total_vm;
 	}
@@ -121,7 +128,7 @@ void acct_update_integrals(struct task_s
  */
 void acct_clear_integrals(struct task_struct *tsk)
 {
-	tsk->acct_stimexpd = 0;
+	tsk->acct_timexpd = 0;
 	tsk->acct_rss_mem1 = 0;
 	tsk->acct_vm_mem1 = 0;
 }
--- a/kernel/sched.c	2008-04-07 15:54:08.000000000 -0700
+++ b/kernel/sched.c	2008-04-18 15:17:27.992000000 -0700
@@ -2531,6 +2531,8 @@ void account_user_time(struct task_struc
 		cpustat->nice = cputime64_add(cpustat->nice, tmp);
 	else
 		cpustat->user = cputime64_add(cpustat->user, tmp);
+	/* Account for user time used */
+	acct_update_integrals(p);
 }
 
 /*

Re: Are we going too fast?

[PinkFreud]

> On Mon, 13 Aug 2001, PinkFreud wrote:
> 
> > This even happens after the BIOS flash - the first few times I switched
> > consoles, it actually survived.  After that, it locked up again.
> 
> Could you perchance be running a framebuffer console?

Not at the moment.  I have tried in the past, curious to see if it resolved
the problem - it didn't.

Again, this only seems to happen in the 2.4 kernels (I just read that 2.4.9
has been released, but haven't tried it yet).  2.2.19 is stable when doing this.

Alan, do you have any more thoughts on why this might be happening?

Thanks.


	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: Are we going too fast?

[Roy Murphy]

'Twas brillig when Mike Edwards scrobe:
>I think that's a bit unfair. Rather, I suspect people see the 
>word 'stable', and assume, for some unknown reason, that the kernel is >stable.
*AHEM* 

Whatever truth value 2.4 has for the variable stable, it can not be stored in
a boolean type.

'Stable' means that the direction of development is intended to reduce the number
of bugs not add new features unless they can reasonably be shown to not introduce
major bugs.  That the 2.5 tree has not been opened indicates the recognition
that additional concentrated work on 2.4 is needed.

>Seriously, though - even distributions are including 2.4 kernels now. 
>RedHat, Mandrake, Slackware ... Should the latest versions of these 
>distributions be considered unstable as well? 

Even older releases of distributions are maintained.  Should we ever get to
kernel 2.2.38, the distribution maintainers should be releasing bugfix patches
for older distributions with the latest 2.2 kernel.

>Perhaps it needs to be made clear to people that these kernels still 
>aren't all they could be. 

No kernel is perfect.  The judgement was that it was ready to switch from adding
features to increasing stability.  Thus it has ever been since my first kernel
~= 0.95.
-- 
Roy Murphy      \ CSpice -- A mailing list for Clergy Spouses
murphy@panix.com \  http://www.panix.com/~murphy/CSpice.html

Re: Are we going too fast?

[Per Jessen]

On Tue, 14 Aug 2001 15:54:33 -0400, David Ford wrote:

>Per Jessen wrote:
>
>>>On Mon, 13 Aug 2001 14:11:32 +0100 (BST), Alan Cox wrote:
>>>
>>>If you want maximum stability you want to be running 2.2 or even 2.0. Newer
>>>less tested code is always less table. 2.4 wont be as stable as 2.2 for a
>>>year yet.
>>>
>>
>>Couldn't have put that any better. On mission-critical systems, this is
>>exactly what people do. Personally, my experience is from the big-iron
>>world of S390 -  if you're a bleeding-edge organisation, you'll be out
>>there applying the latest PTFs, you'll be running the latest OS/390 etc. 
>>If you're conservative, you're at least 2, maybe 3 releases (in todays 
>>OS390 this means about 18-24 months) behind. If you're ultra-conservative,
>>you'll wait for the point where you can no longer avoid an upgrade.
>>
>
>Unfortunately, this methodology also introduces another important 
>factor.  You are the most likely target for exploits and 
>vulnerabilities.  As is ever so strongly evidenced by the great numbers 
>of people being exploited because the version of software they have is 
>outdated.
>
>It's a gross measure of risks; where does the risk come from, how can it 
>affect you, and what can you do about it.

Completely agree. This is also why most big-iron shops employ a couple
of people to do change-management, AKA risk-management. And of course
they'll try to evaluate the risk in moving to the latest OS390 and/or Linux  
versus possible external threats. In the OS390 world, external threats
are limited, and being conservative often pays off very well. In the
Linux world, lots of systems have tight internet connections, and being
alert and uptodate will pay off. It all depends - there is no cure for all.


/Per

PS: is it customary to copy posters on a posting to lkml ? I don't
mind, but just to avoid flames.

regards,
Per Jessen, Zurich
http://www.enidan.com - home of the J1 serial console.

Windows 2001: "I'm sorry Dave ...  I'm afraid I can't do that."

Re: Are we going too fast?

[Per Jessen]

On Tue, 14 Aug 2001 12:32:31 -0400 (EDT), PinkFreud wrote:

>> > The latest stable version of the Linux kernel is: 2.4.8 2001-08-11 04:13 
>> > UTC Changelog 
><snip>
>> 
>> Kernel.org certainly should list the 2.2 status (hey I maintain it I'm
>> allowed to be biased). Its unfortunate it many ways that people are still so
>> programmed to the "latest version" obsession of the proprietary world some
>> times. For most people 2.4 is the right choice but for absolute stability
>> why change 8)
>
>I think that's a bit unfair.  Rather, I suspect people see the word 'stable',
>and assume, for some unknown reason, that the kernel is stable.  *AHEM*
>
>Seriously, though - even distributions are including 2.4 kernels now.  RedHat,
>Mandrake, Slackware ... Should the latest versions of these distributions be
>considered unstable as well?

SuSE started shipping 7.1 with a 2.4.0 kernel (optional). I think I installed
it on a development workstation just about the time when 2.4.2 was released.

For what we do (www.enidan.com), I tend to be more conservative, so we were
using 2.0.36 for quite some time, until we decided to move entirely to 2.2.12.
Our 16CPU cluster is up at 2.4.8 - trying to break things :-) -  but for things 
that people depend on, it's 2.2.19. Some workstations are at 2.4.x - depends.

/Per


regards,
Per Jessen, Zurich
http://www.enidan.com - home of the J1 serial console.

Windows 2001: "I'm sorry Dave ...  I'm afraid I can't do that."

Re: Are we going too fast?

[Per Jessen]

On Tue, 14 Aug 2001 09:57:29 +0200, Helge Hafting wrote:

>PinkFreud wrote:
>[...]
>
>> > Matter of opinion. I would say that Linux-2.4 has been way long to come
>> > and wasn't quite ready for stable status. There are numerous other O/Ses
>> 
>> That's what I've been attempting to say, as well.  It seems to have been
>> released too quickly - minimal testing, too many bugs.
>
>The testing isn't minimal - it is merely ongoing.  Users don't
>pay for the kernel, so they are part of the testing team.
>
>If you use anything but a distribution kernel, keep previous
>kernels around when you upgrade.  If the new one fails, report
>it here and go back to the previous one.  The only way to get wide
>testing is when enough people do this.

Very true, although I get the feeling that the 2.2. series was far more
'stable' than the current 2.4 series. Just a feeling, but .... 
What you're saying seems to apply more to a 2.<odd> kernel series, IMHO ?

I haven't done this myself, but perhaps we ought to look at the frequency
of new 2.4 releases compared to new 2.2 releases. Shouldn't their frequency
be roughly equal ? ie. the speed with which we're seeing new 2.4 releases 
should be - roughly - that of which we saw new 2.2 kernels emerging ?

comments ?



regards,
Per Jessen, Zurich
http://www.enidan.com - home of the J1 serial console.

Windows 2001: "I'm sorry Dave ...  I'm afraid I can't do that."

Re: Are we going too fast?

[PinkFreud]

> > The latest stable version of the Linux kernel is: 2.4.8 2001-08-11 04:13 
> > UTC Changelog 
<snip>
> 
> Kernel.org certainly should list the 2.2 status (hey I maintain it I'm
> allowed to be biased). Its unfortunate it many ways that people are still so
> programmed to the "latest version" obsession of the proprietary world some
> times. For most people 2.4 is the right choice but for absolute stability
> why change 8)

I think that's a bit unfair.  Rather, I suspect people see the word 'stable',
and assume, for some unknown reason, that the kernel is stable.  *AHEM*

Seriously, though - even distributions are including 2.4 kernels now.  RedHat,
Mandrake, Slackware ... Should the latest versions of these distributions be
considered unstable as well?

Perhaps it needs to be made clear to people that these kernels still aren't
all they could be.


	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: Are we going too fast?

[PinkFreud]

> PinkFreud <pf-kernel@mirkwood.net> :
> [...]
> > The unthinkable has happened - it locked up again.  Same problem.  No
> > keyboard, no mouse, no display, no network.  It was as far gone as
> > possible.
> 
> Is the nmi_oopser (Documentation/nmi_watchdog.txt) inefficient here ?

>From Documentation/nmi_watchdog.txt:
NOTE: currently the NMI-oopser is enabled unconditionally on x86 SMP
boxes.

I'm not specifically enabling it in LILO, but according to the docs, it's
enabled already.  Unfortunately, the lockup happens when switching between
virtual consoles, so even if something WERE printed to the screen, I'm unlikely
to see it.

Side note: The lockup does *NOT* occur on 2.2.19 with SMP.

> Ueimor


	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: Are we going too fast?

[PinkFreud]

> > Unfortunately, that's all the info I have.  Console switching was still
> > working, so I tried enabling logging to a console - no output.  System just
> > hangs.  Any suggestions on what I might try to get more information for you?
> 
> Dont suppose you know where I can get a qnx file system to play with ?

Same place I got it.  http://get.qnx.com/

> > this thread that perhaps some old HOWTOs on hardware need to be maintained
> > again - I think I agree with that.
> 
> VIA has some chipset bugs, Matrox G400 cards seem to abuse the PCI spec for 
> benchmarketing dirties.
> 
> (All chipsets have bugs in truth, its just how they appear and if they
> affect users. As of 2.4.8 the VIA ones should be in the users not affected
> camp)

I'll give 2.4.8 a try on the SMP box, and let you know the outcome.

> Alan


	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: Are we going too fast?

[PinkFreud]

On Mon, 13 Aug 2001, PinkFreud wrote:

> Date: Mon, 13 Aug 2001 17:44:57 -0400 (EDT)
> From: PinkFreud <pf-kernel@mirkwood.net>
> To: linux-kernel@vger.kernel.org
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Subject: Re: Are we going too fast?
> 
> > VIA has some chipset bugs, Matrox G400 cards seem to abuse the PCI spec for 
> > benchmarketing dirties.
> > 
> > (All chipsets have bugs in truth, its just how they appear and if they
> > affect users. As of 2.4.8 the VIA ones should be in the users not affected
> > camp)
> 
> I'll give 2.4.8 a try on the SMP box, and let you know the outcome.

The unthinkable has happened - it locked up again.  Same problem.  No
keyboard, no mouse, no display, no network.  It was as far gone as
possible.

This even happens after the BIOS flash - the first few times I switched
consoles, it actually survived.  After that, it locked up again.

	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: Are we going too fast?

[Francois Romieu]

PinkFreud <pf-kernel@mirkwood.net> :
[...]
> The unthinkable has happened - it locked up again.  Same problem.  No
> keyboard, no mouse, no display, no network.  It was as far gone as
> possible.

Is the nmi_oopser (Documentation/nmi_watchdog.txt) inefficient here ?

-- 
Ueimor

Re: Are we going too fast?

[Dr. Kelsey Hudson]

On Mon, 13 Aug 2001, PinkFreud wrote:

> This even happens after the BIOS flash - the first few times I switched
> consoles, it actually survived.  After that, it locked up again.

Could you perchance be running a framebuffer console?

 Kelsey Hudson                                           khudson@ctica.com
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------

Re: Are we going too fast?

[PinkFreud]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 5979 bytes --]

> On Mon, 13 Aug 2001, PinkFreud wrote:
> 
> > Have a contact address for LSILOGIC?  I'll be happy to CC them in any
> > future bug reports.  It may also be useful to place this address in
> > comments at the top of the ncr53c8xx driver as well.
> 
> It is in fact Pamela Delaney, a LSILOGIC employee, who added support for
> the 53C1010 in the sym53c8xx driver version 1.6. This allowed me time for
> porting version 1.5 (without C1010 support) to FreeBSD (sym driver) and to
> add my own variant of C1010 support to sym. Pamela didn't seem to want to
> add her name and address in the source.  Anyway, you may want to have a
> look at the LSILOGIC web and ftp site for the Linux support. I would be
> surprised if you cannot find Pamela's email address.

I'll look.  Thanks.

> > I think I've proven a number of things to be broken in the 2.4.x series -
> > but they doesn't seem to be getting fixed.  My point was, perhaps more
> > effort should be put into fixing these bugs, rather than adding new
> > features to a supposedly stable series.
> 
> Matter of opinion. I would say that Linux-2.4 has been way long to come
> and wasn't quite ready for stable status. There are numerous other O/Ses

That's what I've been attempting to say, as well.  It seems to have been
released too quickly - minimal testing, too many bugs.

> that have had to suffer such a problem in their long life, especially
> commercial ones. Nothing that only applies to Linux here, in my
> experience.

I think Linux is something of a unique case here, though.  Linus wanted to get
2.4.x out quickly - and now there's more bugs to deal with than ever.  For
this level of (in?)stability, I'd still expect to see this as a development
kernel.  Please, don't get me wrong - I *do* realize the earlier in a kernel
series we are, the more problems will appear.  I just happen to think that
there are far too many for a series labeled 'stable'.  Either a third series
should be created for the interim, or perhaps the kernels need to be in
'devel' for a bit longer?

Just my 2 cents.

> > If Linux is trying to prove itself usable for the business world, how is
> > that going to help?  I'm not implying that I'm a business in any way,
> > shape, or form - but given that I think the majority of us want to see
> > Linux in the server rooms, and even on the desktop, what does this mean
> > for those users?
> 
> Btw, we are using some Linux machines at the company I work to. They
> donnot seem to run 2.4 kernels for the moment. As I am the only guy that
> also uses FreeBSD, I donnot want to risk FreeBSD 5 for real work for the
> same reason. :)

5.0 is current, 4.3 is release.  As I understand it, 'current' is the
equivalent of Linux's 'devel' and 'stable' the equivalent of Linux's 'stable'.

If that's the case, your refusal to use a 'current' release on a production
machine would be like refusing to use 2.3.x or 2.5.x on a production machine -
a very sound decision.  But what of 2.4.x?  It's called stable, but yet has a
ways to go.

> OTOH, we have software that explodes Solaris 8 in a millisecond but that
> works reliably on previous Solaris releases, but Solaris 8 is not that
> young an OS release as we know. Just an example that applies to a
> commercial Unix O/S...

True.  But is that due to a bug in the particular software, or the OS?  :P

> > I know plenty of Windows users who are quite upset at the lack of
> > stability.  They either don't know/understand that there are alternatives,
> > or feel it's too hard to switch to an alternative.
> 
> A windows machine is generally some melting pot of [an O/S + broken
> hardwares + broken drivers + broken applications + viruses] driven by
> unaware users. It is a miracle for such a thing to work enough for real
> work to be possible. Personnaly, I haven't problems with Windows. It runs
> games just fine and since I donnot use it for anything else, it just fit
> my needs. :-)

There's plenty of unaware users using Linux nowadays (RedHat, Mandrake, ...).
What does this mean for them?  Distributions are now including 2.4.x kernels.
What happens when their systems blow up, as the 3 I've used here have?

> > I definintely believe this (the random panic) to be a bug in your
> > ncr53c8xx driver.  ksymoops seemed to believe it to be the case, and
> > NetBSD seems to be working fine, which means it's not faulty hardware.
> 
> I have retrieved your bug report (emailed on 28 July 2001). I was in
> vacation at this date until yesterday. I cannot read thousands of emails
> in a couple of hours, sorry.

My apologies.  I understand you're busy.  I just got a bit frustrated when I
found that all three systems I've tried 2.4.x kernels on blew up.

> The problem is due to a NULL pointer being read from the driver DONE
> queue. This queue uses 0xfffffff as a tag for empty entries and valid
> addresses for entries pointing to completed CCBs. Since this driver is
> actually stable since years (only sym53c8xx was under development) it is
> likely the driver data structures that are screwed up from some other
> place rather than a driver bug, in my opinion. If this also happens on
> 2.2.x (x>=18) kernel release, it will be another story, obviously.

I haven't tried the later 2.2.x kernels on that machine.  Since I do plan on
using that system in some sort of production capacity, and since it's currently
running NetBSD without a problem, I don't think I'm going to get the chance to
run Linux on it any time in the near future.  I do, as mentioned earlier, have
an Alpha with the same controller, which currently operates just fine with
2.2.14.  I will be more than happy to install the latest 2.2.x kernel on it
when the NetBSD system replaces what it does, and see if it blows up.

> Regards,
>   Gérard.


	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: Are we going too fast?

[Helge Hafting]

PinkFreud wrote:
[...]

> > Matter of opinion. I would say that Linux-2.4 has been way long to come
> > and wasn't quite ready for stable status. There are numerous other O/Ses
> 
> That's what I've been attempting to say, as well.  It seems to have been
> released too quickly - minimal testing, too many bugs.

The testing isn't minimal - it is merely ongoing.  Users don't
pay for the kernel, so they are part of the testing team.

If you use anything but a distribution kernel, keep previous
kernels around when you upgrade.  If the new one fails, report
it here and go back to the previous one.  The only way to get wide
testing is when enough people do this.

Helge Hafting

Re: Are we going too fast?

[PinkFreud]

> > of them have suffered from one malady or another - from the dual PIII with
> > the VIA chipset and Matrox G400 card, which locks up nicely when I switch
> 
> Welcome to wacky hardware. To get a G400 stable on x86 you need at least
> 
> XFree86 4.1 if you are running hardware 3D (and DRM 4.1)

I run 4.1.0 on that system.  DRM, I don't believe, is currently enabled,
though I'd like it to be.

> 2.4.8 or higher with the VIA fixes

Oooooh.  So .8 *does* have fixes for VIA... I think I'll give that a try now.

> Preferably a very recent BIOS update for the VIA box

Hmm.  I'll also check VIA to see if they have any updates for this system.
Thanks for the suggestion.

> Of those only the XFree hardware 3d stuff is software bug related.

I'm not currently using 3D - yet the system insists on locking up when I
switch from X to a text console and back.  Again, this only occurs with an
SMP kernel (this is an SMP system).  This does NOT occur with a uniprocessor
kernel.

> > emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> > (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> > on screen, nothing!) - and this latest is with 2.4.8!
> 
> The qnxfs code is experimental - so I can believe it might fail in 2.4. I'd
> be very interested in info on that one.

Unfortunately, that's all the info I have.  Console switching was still
working, so I tried enabling logging to a console - no output.  System just
hangs.  Any suggestions on what I might try to get more information for you?

> > Should development continue on the latest and supposedly greatest
> > drivers?  Or should the existing bugs be fixed first?  I've got at least
> > three up there that need taking care of, and I'm sure others on this list
> > have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> > boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> > what are others seeing?
> 
> Near enough 0%. But then I try and avoid buying broken chipsets.

I wasn't aware VIA nor Matrox were broken.  I've seen someone else mention in
this thread that perhaps some old HOWTOs on hardware need to be maintained
again - I think I agree with that.

> > I like Linux.  I'd like to stick with it.  But if it's going to
> > continually crash, I'm going to jump ship - and I'll start recommending to
> 
> If you want maximum stability you want to be running 2.2 or even 2.0. Newer
> less tested code is always less table. 2.4 wont be as stable as 2.2 for a
> year yet.

Perhaps series name should be changed from 'stable' to something else - 
'release'?

> Alan


	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: Are we going too fast?

[Alan Cox]

> Unfortunately, that's all the info I have.  Console switching was still
> working, so I tried enabling logging to a console - no output.  System just
> hangs.  Any suggestions on what I might try to get more information for you?

Dont suppose you know where I can get a qnx file system to play with ?

> this thread that perhaps some old HOWTOs on hardware need to be maintained
> again - I think I agree with that.

VIA has some chipset bugs, Matrox G400 cards seem to abuse the PCI spec for 
benchmarketing dirties.

(All chipsets have bugs in truth, its just how they appear and if they
affect users. As of 2.4.8 the VIA ones should be in the users not affected
camp)

Alan

Re: Are we going too fast?

[Rog�rio Brito]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 974 bytes --]

On Aug 13 2001, Alan Cox wrote:
> VIA has some chipset bugs, Matrox G400 cards seem to abuse the PCI spec for 
> benchmarketing dirties.

	If I had to purchase a motherboard and graphics card for a
	desktop that were running Linux, which ones should I be
	buying? Are AMD's chipsets better than those made by VIA? And
	what about ATI's cards?

	Of course, making business with an open source-friendly is a
	requirement that I've beeing making for, say, 2 or 3 years.


	[]s, Roger...

P.S.: I have an Asus A7V/VIA KT133 boarch here with a Matrox G400 card
and I wish the performance were better (especially when I'm playing a
DVD). At least, when I'm using the Promise IDE interface and ignore
the IDE interface supplied by the southbridge, Linux feels faster.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - rbrito@ime.usp.br - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: Are we going too fast?

[Ben Ford]

Alan Cox wrote:

>>Unfortunately, that's all the info I have.  Console switching was still
>>working, so I tried enabling logging to a console - no output.  System just
>>hangs.  Any suggestions on what I might try to get more information for you?
>>
>
>Dont suppose you know where I can get a qnx file system to play with ?
>

http://get.qnx.com/

-- 
Number of restrictions placed on "Alice in Wonderland" (public domain) eBook:  5

Maximum penalty for reading "Alice in Wonderland" aloud (possible DMCA    
violation):  5 years jail
                                
Average sentence for commiting Rape: 5 years

Re: Are we going too fast?

[Peter Wächtler]

Alan Cox wrote:
> 
> Dont suppose you know where I can get a qnx file system to play with ?
> 

You can download the newer QNX RTP at http://get.qnx.com.

You can install it in a separate partition ("primary" ones) or
into an existing Windows FAT FS.

If you want to avoid the effort, I can generate a floppy image and
email one to you.

Re: Are we going too fast?

[David Ford]

PinkFreud wrote:

>I wasn't aware VIA nor Matrox were broken.  I've seen someone else mention in
>this thread that perhaps some old HOWTOs on hardware need to be maintained
>again - I think I agree with that.
>

VIA comes up as a bloody thorn quite often it seems.  I have a VIA 586B 
system and it seems to work decently but I think I'm just lucky 
considering the large number of broken VIA chipset complaints.

>Perhaps series name should be changed from 'stable' to something else - 
>'release'?
>

Erm...they are called release.  2.<even> is a release kernel and 2.<odd> 
is a development kernel.  Some people (myself included) fight the 
impression given by a lot of people of stable/unstable naming. 
 Typically called slashdotters...</humor>


David

Re: Are we going too fast?

[Nicholas Knight]

On Monday 13 August 2001 07:24 pm, David Ford wrote:
> PinkFreud wrote:
> >I wasn't aware VIA nor Matrox were broken.  I've seen someone else
> > mention in this thread that perhaps some old HOWTOs on hardware need
> > to be maintained again - I think I agree with that.
>
> VIA comes up as a bloody thorn quite often it seems.  I have a VIA 586B
> system and it seems to work decently but I think I'm just lucky
> considering the large number of broken VIA chipset complaints.
>
> >Perhaps series name should be changed from 'stable' to something else
> > - 'release'?
>
> Erm...they are called release.  2.<even> is a release kernel and
> 2.<odd> is a development kernel.  Some people (myself included) fight
> the impression given by a lot of people of stable/unstable naming.
> Typically called slashdotters...</humor>

If this is truely the case, I'd suggest that kernel.org be modified, as 
it refers to them as *stable*
as of 9:18PM PDT, direct copy & paste from kernel.org page:

The latest stable version of the Linux kernel is: 2.4.8 2001-08-11 04:13 
UTC Changelog 

The latest prepatch (alpha) version appears to be: 2.4.9-pre3 2001-08-13 
23:56 UTC Changelog

Re: Are we going too fast?

[Alan Cox]

> If this is truely the case, I'd suggest that kernel.org be modified, as 
> it refers to them as *stable*
> as of 9:18PM PDT, direct copy & paste from kernel.org page:
> 
> The latest stable version of the Linux kernel is: 2.4.8 2001-08-11 04:13 
> UTC Changelog 
> 
> The latest prepatch (alpha) version appears to be: 2.4.9-pre3 2001-08-13 
> 23:56 UTC Changelog

Kernel.org certainly should list the 2.2 status (hey I maintain it I'm
allowed to be biased). Its unfortunate it many ways that people are still so
programmed to the "latest version" obsession of the proprietary world some
times. For most people 2.4 is the right choice but for absolute stability
why change 8)

Re: Are we going too fast?

[Paul G. Allen]

Alan Cox wrote:
> 
> > If this is truely the case, I'd suggest that kernel.org be modified, as
> > it refers to them as *stable*
> > as of 9:18PM PDT, direct copy & paste from kernel.org page:
> >
> > The latest stable version of the Linux kernel is: 2.4.8 2001-08-11 04:13
> > UTC Changelog
> >
> > The latest prepatch (alpha) version appears to be: 2.4.9-pre3 2001-08-13
> > 23:56 UTC Changelog
> 
> Kernel.org certainly should list the 2.2 status (hey I maintain it I'm
> allowed to be biased). Its unfortunate it many ways that people are still so
> programmed to the "latest version" obsession of the proprietary world some
> times. For most people 2.4 is the right choice but for absolute stability
> why change 8)

Agreed. 2.2.x works just fine for us on our servers (some have been up for over a year, some maybe longer, but the longer they're up without problems, the
easier it is to forget they even exist ;) I am using 2.4 because my personal MoBo is so new, it's the only kernel that will work worth a darn on it. I am also
wanting to upgrade some servers as soon as a more stable kernel is available because there are some improvements in the newer kernels that I feel could be of
great benefit (but then that's my personal view, and not necessarily a company view). It has been long known that even numbered kernels are stable kernels, not
necessarily bug free (nothing is, escept for what I write ;-), and odd numbered are development kernels. By this definition, 2.4.x kernels are stable (in most
cases it seems it's the hardware that's not).

PGA

-- 
Paul G. Allen
UNIX Admin II/Programmer
Akamai Technologies, Inc.
www.akamai.com
Work: (858)909-3630
Cell: (858)395-5043

Re: Are we going too fast?

[John Weber]

Alan Cox wrote:

>>of them have suffered from one malady or another - from the dual PIII with
>>the VIA chipset and Matrox G400 card, which locks up nicely when I switch
>>
> 
> Welcome to wacky hardware. To get a G400 stable on x86 you need at least
> 
> XFree86 4.1 if you are running hardware 3D (and DRM 4.1)
> 2.4.8 or higher with the VIA fixes
> Preferably a very recent BIOS update for the VIA box
> 


I'm sorry, but what "VIA fixes" are we referring to?

My hardware:
- VIA  Apollo Pro 133A - VIA VT82C686A South, VIA VT82C693A North

The only problem I have ever had with my system had to do with the 

onboard sound (via82cxxx_audio driver specifically), and Mr. Jeff
Garzik promptly issued a patch which corrected my problem.

I'm currently running linux kernel 2.4.8 with no problems whatsoever.

Re: Are we going too fast?

[Petr Vandrovec]

On 13 Aug 01 at 10:55, Francois Romieu wrote:
> 
> Try and send specific bug-reports to the maintainers. 
> l-k archives may give you some light on issues with VIA chipsets.
> 
> I'm not convinced that gaining stability on a VIA + G400 + X + smp 
> combo is an easy task anyway.

VIA (694X) (Gigabyte 6VXD7), G450, XF4.0/XF4.1, SMP (2xPIII/833) works 
fine if you
(1) do not use matrox module from Matrox and
(2) there is not PCI activity which targets G400 when X initialize
    hardware (during start or console switch) and
(3) it is highly unrecommended to use DRI (as it touches G400 hardware
    even when X are not on foreground)

If it is too limiting for you, look for another chipset. With i440BX
you'll get at least 2x faster PCI->AGP transfers than with VIA: i440BX
can handle 60MBps (32bpp full PAL) without any problems, while 694x has 
problems with 30MBps (16bpp full PAL) (IDE disk accesses are visible
as dropouts on picture).

There is nothing Linux kernel can do for stability of such box.
                                            Best regards,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

Re: Are we going too fast?

[Per Jessen]

>On Mon, 13 Aug 2001 14:11:32 +0100 (BST), Alan Cox wrote:
>
>If you want maximum stability you want to be running 2.2 or even 2.0. Newer
>less tested code is always less table. 2.4 wont be as stable as 2.2 for a
>year yet.

Couldn't have put that any better. On mission-critical systems, this is
exactly what people do. Personally, my experience is from the big-iron
world of S390 -  if you're a bleeding-edge organisation, you'll be out
there applying the latest PTFs, you'll be running the latest OS/390 etc. 
If you're conservative, you're at least 2, maybe 3 releases (in todays 
OS390 this means about 18-24 months) behind. If you're ultra-conservative,
you'll wait for the point where you can no longer avoid an upgrade.


regards,
Per Jessen


regards,
Per Jessen, Zurich
http://www.enidan.com - home of the J1 serial console.

Windows 2001: "I'm sorry Dave ...  I'm afraid I can't do that."

Re: Are we going too fast?

[Andrew Scott]

On 13 Aug 2001, at 20:46, Per Jessen wrote:

> >On Mon, 13 Aug 2001 14:11:32 +0100 (BST), Alan Cox wrote:
> >
> >If you want maximum stability you want to be running 2.2 or even 2.0. Newer
> >less tested code is always less table. 2.4 wont be as stable as 2.2 for a
> >year yet.
> 
> Couldn't have put that any better. On mission-critical systems, this is
> exactly what people do. Personally, my experience is from the big-iron
> world of S390 -  if you're a bleeding-edge organisation, you'll be out
> there applying the latest PTFs, you'll be running the latest OS/390 etc. 
> If you're conservative, you're at least 2, maybe 3 releases (in todays 
> OS390 this means about 18-24 months) behind. If you're ultra-conservative,
> you'll wait for the point where you can no longer avoid an upgrade.

We've only just now moved from 2.0.36 to 2.2.18, and cautiously at 
that. We've started to run into applications that won't run on the 
older kernel/lib combinatons that we need.


                      _
                     / \   / ascott@casdn.neu.edu
                    / \ \ /
                   /   \_/

Re: Are we going too fast?

[David Ford]

Per Jessen wrote:

>>On Mon, 13 Aug 2001 14:11:32 +0100 (BST), Alan Cox wrote:
>>
>>If you want maximum stability you want to be running 2.2 or even 2.0. Newer
>>less tested code is always less table. 2.4 wont be as stable as 2.2 for a
>>year yet.
>>
>
>Couldn't have put that any better. On mission-critical systems, this is
>exactly what people do. Personally, my experience is from the big-iron
>world of S390 -  if you're a bleeding-edge organisation, you'll be out
>there applying the latest PTFs, you'll be running the latest OS/390 etc. 
>If you're conservative, you're at least 2, maybe 3 releases (in todays 
>OS390 this means about 18-24 months) behind. If you're ultra-conservative,
>you'll wait for the point where you can no longer avoid an upgrade.
>

Unfortunately, this methodology also introduces another important 
factor.  You are the most likely target for exploits and 
vulnerabilities.  As is ever so strongly evidenced by the great numbers 
of people being exploited because the version of software they have is 
outdated.

It's a gross measure of risks; where does the risk come from, how can it 
affect you, and what can you do about it.

Some of the most common questions asked on support areas is (take IIS 
for example) "My server is being exploited, how can I stop it?" and the 
most common answer to that is "Upgrade and install all necessary patches."

Save for the rare occasion of issue, I run a few different server farms 
and they all perform very well and are all rock solid stable.  I should 
also note that they are all 2.4 kernels.  For servers I seem to have 
really good success stories, for my workstation I tend to have issues 
which is fairly natural, my workstation has numerous accessory cards and 
features.

To be honest, save for either power outtage or kernel upgrade, I rarely 
have to deal with reboots.  I tend to keep my servers within a few 
releases of the current code.  Due to this policy I rarely have exploit 
and vulnerability issues.  One particular server (which has a VIA 
chipset...is it jinxed? :) has problems now and then but they get fixed.

David

Re: Are we going too fast?

[PinkFreud]

> On Mon, 13 Aug 2001, PinkFreud wrote:
>
> > Please CC me in any replies, I am not subscribed to this list.

This still holds true - I'm not subscribed to this list right now.

> >
> > Please forgive me if I seem incoherent.  It's after 3:30 AM here.
>
> So, you will be forgiven, otherwise ... :-)

Thanks.  :)

> You may want to elaborate on the ncr53c8xx problems (I maintain this
> driver). More generally, you must not ignore the thousands of bugs in the
> hardware you are using, but software developpers haven't access to all
> errata descriptions since hardware vendors donnot like to make this
> information freely available.

I have elaborated.  See below.

>
> About ncr53c8xx problem reports, I cannot reply to all of them. You may
> also send them to LSILOGIC support. They also want Linux to work with the
> ncr/sym/lsi/53c8xx PCI-SCSI controllers, even with old NCR ones. Some
> other vendors seem to just ignore old hardwares. For example NVIDIA that
> killed (bought?) 3DFX, does not seem interested in maintaining drivers for
> the 3DFX graphic chips.

Have a contact address for LSILOGIC?  I'll be happy to CC them in any
future bug reports.  It may also be useful to place this address in
comments at the top of the ncr53c8xx driver as well.

> I use Linux since some 0.99.x (was yygdrasil distribution). My experience
> has been that 1.2.13, 2.0.27 and 2.2.13 worked reliable enough for me.

I've used all three of those kernels, and I tend to agree - except for the
nasty security hole in 2.2.13 (but that happens with any OS - look at
Windows!).

> 'Stable' does not means reliable for any workload. It means that we stop
> developping (implies changing large portions of code or modifying
> interfaces) but only focus on fixing the software with it current design
> (implies only changing what is proven to be broken).  This applies to all

I think I've proven a number of things to be broken in the 2.4.x series -
but they doesn't seem to be getting fixed.  My point was, perhaps more
effort should be put into fixing these bugs, rather than adding new
features to a supposedly stable series.

> softwares, not only to Linux. As a result, early stable releases still
> have numerous bugs that may prevent numerous systems from working
> reliably. It is up to user to check releases and switch to the one that
> fits his expectations.

If Linux is trying to prove itself usable for the business world, how is
that going to help?  I'm not implying that I'm a business in any way,
shape, or form - but given that I think the majority of us want to see
Linux in the server rooms, and even on the desktop, what does this mean
for those users?

> > This brings me to the subject of this rant: are we going too fast?  New
> > drivers are still showing up in each successive kernel, and yet no one
> > seems to be able to fix the old bugs that already exist.  Are we looking
> > to have the reliability of Windows?  It's starting to seem so - each
> > successive kernel series just seems to crash more and more often.  When
> > will we reach the point where Windows, on the average, will have greater
> > uptime than Linux systems?  Perhaps it's time to slow down, and do some
> > debugging.
>
> The reliabity of Windows seems to be just fine for most users since it is
> the O/S most of them want to use.:-)

I know plenty of Windows users who are quite upset at the lack of
stability.  They either don't know/understand that there are alternatives,
or feel it's too hard to switch to an alternative.

> > Should development continue on the latest and supposedly greatest
> > drivers?  Or should the existing bugs be fixed first?  I've got at least
> > three up there that need taking care of, and I'm sure others on this list
> > have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> > boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> > what are others seeing?
>
> Hopefully you aren't a typical computer user or you just have bad luck
> with computers. :-)

Certainly the case with the former, and sadly, you're not the first to
suggest the latter.  :)

> All software developpers and maintainers want their software to work and
> thus bugs to be fixed. This is just sometimes hard to know what is
> actually broken. My experience is that no more than 10% bug reports about
> a software are due to a bug in the software that is pointed out by the
> report. And for these less than 10% relevant reports, maintainers must
> find what is broken... not simple as you can imagine...

I definintely believe this (the random panic) to be a bug in your
ncr53c8xx driver.  ksymoops seemed to believe it to be the case, and
NetBSD seems to be working fine, which means it's not faulty hardware.

> Btw, I use SYM-2 driver under Linux, FreeBSD and NetBSD 1.5. I have no
> problem with it. If you plan to use Ultra-160 LSI53C1010 chips, the NetBSD
> SIOP driver may be sub-optimal and, btw, it does not seem to know about
> C1010 chips erratas.

I'll keep that in mind.  However, the box in question is an older system,
so I doubt it'll ever see one of those.

By the way, the driver seems to work with 2.2.14 on an Alpha.  On this
system, though, 2.4.x just manages to blow up.

> You donnot seem to have given a try with FreeBSD. Were there some strong
> reasons for that ?

Actually, I was considering both Free- and NetBSD.  I just chose NetBSD.

> > sauron@rivendell:~$ uptime
> >  3:17AM  up 12 days, 15:20, 2 users, load averages: 1.48, 0.66, 0.31
> > sauron@rivendell:~$ uname -a
> > NetBSD rivendell 1.5.1 NetBSD 1.5.1 (RIVENDELL) #0: Tue Jul 31 22:58:54
> > EDT 2001     root@rivendell:/usr/src/sys/arch/i386/compile/RIVENDELL i386
> > sauron@rivendell:~$ dmesg | grep -i sym
> > siop0 at pci0 dev 6 function 0: Symbios Logic 53c810 (fast scsi)
> >
> > (The controller is old - it was made by NCR before it became Symbios Logic
> > - hence, why I was using the NCR driver for it, rather than the Symbios
> > driver, in Linux.)
> >
> > Working on 13 days uptime.  That's well over twice the uptime for Linux on
> > that box.  That's what happens when the kernel has bugs.
>
> You seem so sure it is the ncr53c8xx driver that breaks your Linux ...
> If it was so broken, may be I would have heared about. :-)

You should have heard about it.  The last two messages were sent to the
address you have listed in your driver.


Date: Fri, 20 Jul 2001 13:26:12 -0400 (EDT)
From: PinkFreud <pf-kernel@mirkwood.net>
To: linux-kernel@vger.kernel.org
Subject: two seperate 2.4.x problems...
Message-ID: <Pine.LNX.4.20.0107201305350.5411-100000@eriador.mirkwood.net>

                                                                          
Date: Mon, 23 Jul 2001 14:11:35 -0400 (EDT)
From: PinkFreud <pf-kernel@mirkwood.net>
To: linux-kernel@vger.kernel.org
cc: Gerard Roudier <groudier@club-internet.fr>
Subject: 2.4.6 NCR53C8XX bug?  (was: 2.4.x problems (this is *not* a
    distribution
 related question!))
Message-ID: <Pine.LNX.4.20.0107231347060.5411-100000@eriador.mirkwood.net>


Date: Sat, 28 Jul 2001 22:20:20 -0400 (EDT)
From: PinkFreud <pf-kernel@mirkwood.net>
To: linux-kernel@vger.kernel.org
cc: Gerard Roudier <groudier@club-internet.fr>
Subject: 2.4.7 oops + panic in ncr53c8xx (ncr_wakeup_done)
Message-ID: <Pine.LNX.4.20.0107282207180.316-100000@eriador.mirkwood.net>


Would you like me to re-send the ksymoops output?

> > Take this rant for what you will.  Personally, I switched from Windows to
> > Linux 5 years ago for the stability.  If I need to switch OSs again to
> > continue to have stability, I will.  Somehow, I suspect, if kernel
> > development continues down this path, many others will wind up switching
> > to other OSs as well.
>
> If NetBSD fits your need, then let me encourage you to use it.

It is for the moment.  I hoped Linux would fit my need, though.

> > I like Linux.  I'd like to stick with it.  But if it's going to
> > continually crash, I'm going to jump ship - and I'll start recommending to
> > others that they do the same.
>
> That's unclever recommendation, in my opinion.
> For example, my children are happy using Windows 98 and I donnot want to
> recommend them anything else.

I recommend using what I feel is usable (which includes stability) - which
is why I never recommend using Windows.  But that's just me.


	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: Are we going too fast?

[Gérard Roudier]

On Mon, 13 Aug 2001, PinkFreud wrote:

> > On Mon, 13 Aug 2001, PinkFreud wrote:
> >

[...]

> > About ncr53c8xx problem reports, I cannot reply to all of them. You may
> > also send them to LSILOGIC support. They also want Linux to work with the
> > ncr/sym/lsi/53c8xx PCI-SCSI controllers, even with old NCR ones. Some
> > other vendors seem to just ignore old hardwares. For example NVIDIA that
> > killed (bought?) 3DFX, does not seem interested in maintaining drivers for
> > the 3DFX graphic chips.
>
> Have a contact address for LSILOGIC?  I'll be happy to CC them in any
> future bug reports.  It may also be useful to place this address in
> comments at the top of the ncr53c8xx driver as well.

It is in fact Pamela Delaney, a LSILOGIC employee, who added support for
the 53C1010 in the sym53c8xx driver version 1.6. This allowed me time for
porting version 1.5 (without C1010 support) to FreeBSD (sym driver) and to
add my own variant of C1010 support to sym. Pamela didn't seem to want to
add her name and address in the source.  Anyway, you may want to have a
look at the LSILOGIC web and ftp site for the Linux support. I would be
surprised if you cannot find Pamela's email address.

> > I use Linux since some 0.99.x (was yygdrasil distribution). My experience
> > has been that 1.2.13, 2.0.27 and 2.2.13 worked reliable enough for me.
>
> I've used all three of those kernels, and I tend to agree - except for the
> nasty security hole in 2.2.13 (but that happens with any OS - look at
> Windows!).
>
> > 'Stable' does not means reliable for any workload. It means that we stop
> > developping (implies changing large portions of code or modifying
> > interfaces) but only focus on fixing the software with it current design
> > (implies only changing what is proven to be broken).  This applies to all
>
> I think I've proven a number of things to be broken in the 2.4.x series -
> but they doesn't seem to be getting fixed.  My point was, perhaps more
> effort should be put into fixing these bugs, rather than adding new
> features to a supposedly stable series.

Matter of opinion. I would say that Linux-2.4 has been way long to come
and wasn't quite ready for stable status. There are numerous other O/Ses
that have had to suffer such a problem in their long life, especially
commercial ones. Nothing that only applies to Linux here, in my
experience.

> > softwares, not only to Linux. As a result, early stable releases still
> > have numerous bugs that may prevent numerous systems from working
> > reliably. It is up to user to check releases and switch to the one that
> > fits his expectations.
>
> If Linux is trying to prove itself usable for the business world, how is
> that going to help?  I'm not implying that I'm a business in any way,
> shape, or form - but given that I think the majority of us want to see
> Linux in the server rooms, and even on the desktop, what does this mean
> for those users?

Btw, we are using some Linux machines at the company I work to. They
donnot seem to run 2.4 kernels for the moment. As I am the only guy that
also uses FreeBSD, I donnot want to risk FreeBSD 5 for real work for the
same reason. :)
OTOH, we have software that explodes Solaris 8 in a millisecond but that
works reliably on previous Solaris releases, but Solaris 8 is not that
young an OS release as we know. Just an example that applies to a
commercial Unix O/S...

> > > This brings me to the subject of this rant: are we going too fast?  New
> > > drivers are still showing up in each successive kernel, and yet no one
> > > seems to be able to fix the old bugs that already exist.  Are we looking
> > > to have the reliability of Windows?  It's starting to seem so - each
> > > successive kernel series just seems to crash more and more often.  When
> > > will we reach the point where Windows, on the average, will have greater
> > > uptime than Linux systems?  Perhaps it's time to slow down, and do some
> > > debugging.
> >
> > The reliabity of Windows seems to be just fine for most users since it is
> > the O/S most of them want to use.:-)
>
> I know plenty of Windows users who are quite upset at the lack of
> stability.  They either don't know/understand that there are alternatives,
> or feel it's too hard to switch to an alternative.

A windows machine is generally some melting pot of [an O/S + broken
hardwares + broken drivers + broken applications + viruses] driven by
unaware users. It is a miracle for such a thing to work enough for real
work to be possible. Personnaly, I haven't problems with Windows. It runs
games just fine and since I donnot use it for anything else, it just fit
my needs. :-)

> > > Should development continue on the latest and supposedly greatest
> > > drivers?  Or should the existing bugs be fixed first?  I've got at least
> > > three up there that need taking care of, and I'm sure others on this list
> > > have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> > > boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> > > what are others seeing?
> >
> > Hopefully you aren't a typical computer user or you just have bad luck
> > with computers. :-)
>
> Certainly the case with the former, and sadly, you're not the first to
> suggest the latter.  :)
>
> > All software developpers and maintainers want their software to work and
> > thus bugs to be fixed. This is just sometimes hard to know what is
> > actually broken. My experience is that no more than 10% bug reports about
> > a software are due to a bug in the software that is pointed out by the
> > report. And for these less than 10% relevant reports, maintainers must
> > find what is broken... not simple as you can imagine...
>
> I definintely believe this (the random panic) to be a bug in your
> ncr53c8xx driver.  ksymoops seemed to believe it to be the case, and
> NetBSD seems to be working fine, which means it's not faulty hardware.

I have retrieved your bug report (emailed on 28 July 2001). I was in
vacation at this date until yesterday. I cannot read thousands of emails
in a couple of hours, sorry.

The problem is due to a NULL pointer being read from the driver DONE
queue. This queue uses 0xfffffff as a tag for empty entries and valid
addresses for entries pointing to completed CCBs. Since this driver is
actually stable since years (only sym53c8xx was under development) it is
likely the driver data structures that are screwed up from some other
place rather than a driver bug, in my opinion. If this also happens on
2.2.x (x>=18) kernel release, it will be another story, obviously.

[...]

Regards,
  Gérard.

Are we going too fast?

[PinkFreud]

Please CC me in any replies, I am not subscribed to this list.

Please forgive me if I seem incoherent.  It's after 3:30 AM here.


I have installed various 2.4.x kernels on 3 seperate systems here.  *ALL*
of them have suffered from one malady or another - from the dual PIII with
the VIA chipset and Matrox G400 card, which locks up nicely when I switch
from X to a text console and back to X (but NOT under a uniprocessor
kernel!), to the system with the NCR 53c810 SCSI board, which suffered
random kernel panics anywhere from 2 hours to 5 days after booting, due to
the ncr53c8xx driver, to YET ANOTHER system which has shown a penchant for
crashing (read: no response on console, can use magic sysrq, but fails to
emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
(ls comes up fine, then system crashes - nothing sent to syslog, no errors
on screen, nothing!) - and this latest is with 2.4.8!

I've used Linux for over 5 years now.  In all the time I've used it, I
have never seen this much instability in a single kernel
series - though I've noticed each successive 'stable' series having
more bugs than the last (2.2.x crashed once a week with SMP 
until 2.2.10!).  Furthermore, I have had a HELL of a time trying
to get responses to the first two problems (this is the first report for
the third).  It used to be that I could ask a question on this list, and
receive responses.  Not anymore.  I can't seem to get the time of day from
anyone on this list now.

This brings me to the subject of this rant: are we going too fast?  New
drivers are still showing up in each successive kernel, and yet no one
seems to be able to fix the old bugs that already exist.  Are we looking
to have the reliability of Windows?  It's starting to seem so - each
successive kernel series just seems to crash more and more often.  When
will we reach the point where Windows, on the average, will have greater
uptime than Linux systems?  Perhaps it's time to slow down, and do some
debugging.

This is supposed to be a 'stable' kernel series?  I see nothing stable
about it.

Should development continue on the latest and supposedly greatest
drivers?  Or should the existing bugs be fixed first?  I've got at least
three up there that need taking care of, and I'm sure others on this list
have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
boxes - that's 100% failure rate.  If I get 100% failure on my installs,
what are others seeing?

To those of you who would tell me to fix them myself: I am an
administrator.  I know Perl.  I am not all that familiar with C, nor with
kernel programming.  They're not my bugs, but I would fix them if I were
able to.  I'd hope the authors of said bugs would be willing to fix them -
but given the track record I've seen for the first two problems, I'm not
holding my breath for the third to be fixed any time soon.

I don't know about the rest of you, but I'm going to give up soon and
switch to NetBSD.  I've already done it on the system with the NCR 53c810
board - and it's proven to be far more stable than 2.4.x kernels have ever
managed to be on it.  What does that say?

sauron@rivendell:~$ uptime
 3:17AM  up 12 days, 15:20, 2 users, load averages: 1.48, 0.66, 0.31
sauron@rivendell:~$ uname -a
NetBSD rivendell 1.5.1 NetBSD 1.5.1 (RIVENDELL) #0: Tue Jul 31 22:58:54
EDT 2001     root@rivendell:/usr/src/sys/arch/i386/compile/RIVENDELL i386
sauron@rivendell:~$ dmesg | grep -i sym
siop0 at pci0 dev 6 function 0: Symbios Logic 53c810 (fast scsi)

(The controller is old - it was made by NCR before it became Symbios Logic
- hence, why I was using the NCR driver for it, rather than the Symbios
driver, in Linux.)

Working on 13 days uptime.  That's well over twice the uptime for Linux on
that box.  That's what happens when the kernel has bugs.

Take this rant for what you will.  Personally, I switched from Windows to
Linux 5 years ago for the stability.  If I need to switch OSs again to
continue to have stability, I will.  Somehow, I suspect, if kernel
development continues down this path, many others will wind up switching
to other OSs as well.

I like Linux.  I'd like to stick with it.  But if it's going to
continually crash, I'm going to jump ship - and I'll start recommending to
others that they do the same.


	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: Are we going too fast?

[Brian]

4:30am here.  I'm sure it won't seem quite as diplomatic in the morning.

Back on 2.2, up until ~.12 or so, I could hang an Intel NIC in a day and a 
half.  A 3Com or a tulip held out for three.  Considering I run web 
servers and kinda needed network access, that was a problem.  I actually 
had a burn of FreeBSD sitting on my desk when the bugs finally got swashed.

Around that time, I was in IRC with a couple of *BSDers.  One commented 
that Linux's eagarness to support anything and everything is exactly what 
made Windows the Swiss cheese we know today.  I laughed it off at the 
time, but it rang brutally true this evening.

I rolled our 2.4.7-based web server back to 2.2.19 tonight.  As if I 
needed further convincing, 2.4.7 apparently panicked on its way out (I was 
logged in from remote, but the symptoms are all too familiar).  That 
leaves our squid servers as the only 2.4-based servers left; they all run 
test12 since the 'stable' 2.4s didn't do very well at the time (of course, 
they've been up for 67-140 days, so that may not be the case anymore).

This is about what my situation was when 2.3 branched off.  I can't say I 
care for it, but at least there's precedent that the wrinkles may iron out.
	-- Brian

On Monday 13 August 2001 03:43 am, PinkFreud wrote:
> Please CC me in any replies, I am not subscribed to this list.
>
> Please forgive me if I seem incoherent.  It's after 3:30 AM here.
>
>
> I have installed various 2.4.x kernels on 3 seperate systems here. 
> *ALL* of them have suffered from one malady or another - from the dual
> PIII with the VIA chipset and Matrox G400 card, which locks up nicely
> when I switch from X to a text console and back to X (but NOT under a
> uniprocessor kernel!), to the system with the NCR 53c810 SCSI board,
> which suffered random kernel panics anywhere from 2 hours to 5 days
> after booting, due to the ncr53c8xx driver, to YET ANOTHER system which
> has shown a penchant for crashing (read: no response on console, can use
> magic sysrq, but fails to emergency sync) when attempting to use 'ls' on
> a mounted QNX filesystem (ls comes up fine, then system crashes -
> nothing sent to syslog, no errors on screen, nothing!) - and this latest
> is with 2.4.8!
>
> I've used Linux for over 5 years now.  In all the time I've used it, I
> have never seen this much instability in a single kernel
> series - though I've noticed each successive 'stable' series having
> more bugs than the last (2.2.x crashed once a week with SMP
> until 2.2.10!).  Furthermore, I have had a HELL of a time trying
> to get responses to the first two problems (this is the first report for
> the third).  It used to be that I could ask a question on this list, and
> receive responses.  Not anymore.  I can't seem to get the time of day
> from anyone on this list now.
>
> This brings me to the subject of this rant: are we going too fast?  New
> drivers are still showing up in each successive kernel, and yet no one
> seems to be able to fix the old bugs that already exist.  Are we looking
> to have the reliability of Windows?  It's starting to seem so - each
> successive kernel series just seems to crash more and more often.  When
> will we reach the point where Windows, on the average, will have greater
> uptime than Linux systems?  Perhaps it's time to slow down, and do some
> debugging.
>
> This is supposed to be a 'stable' kernel series?  I see nothing stable
> about it.
>
> Should development continue on the latest and supposedly greatest
> drivers?  Or should the existing bugs be fixed first?  I've got at least
> three up there that need taking care of, and I'm sure others on this
> list have found more.  3 seperate crashes on 3 seperate installs on 3
> seperate boxes - that's 100% failure rate.  If I get 100% failure on my
> installs, what are others seeing?
>
> To those of you who would tell me to fix them myself: I am an
> administrator.  I know Perl.  I am not all that familiar with C, nor
> with kernel programming.  They're not my bugs, but I would fix them if I
> were able to.  I'd hope the authors of said bugs would be willing to fix
> them - but given the track record I've seen for the first two problems,
> I'm not holding my breath for the third to be fixed any time soon.
>
> I don't know about the rest of you, but I'm going to give up soon and
> switch to NetBSD.  I've already done it on the system with the NCR
> 53c810 board - and it's proven to be far more stable than 2.4.x kernels
> have ever managed to be on it.  What does that say?
>
> sauron@rivendell:~$ uptime
>  3:17AM  up 12 days, 15:20, 2 users, load averages: 1.48, 0.66, 0.31
> sauron@rivendell:~$ uname -a
> NetBSD rivendell 1.5.1 NetBSD 1.5.1 (RIVENDELL) #0: Tue Jul 31 22:58:54
> EDT 2001     root@rivendell:/usr/src/sys/arch/i386/compile/RIVENDELL
> i386 sauron@rivendell:~$ dmesg | grep -i sym
> siop0 at pci0 dev 6 function 0: Symbios Logic 53c810 (fast scsi)
>
> (The controller is old - it was made by NCR before it became Symbios
> Logic - hence, why I was using the NCR driver for it, rather than the
> Symbios driver, in Linux.)
>
> Working on 13 days uptime.  That's well over twice the uptime for Linux
> on that box.  That's what happens when the kernel has bugs.
>
> Take this rant for what you will.  Personally, I switched from Windows
> to Linux 5 years ago for the stability.  If I need to switch OSs again
> to continue to have stability, I will.  Somehow, I suspect, if kernel
> development continues down this path, many others will wind up switching
> to other OSs as well.
>
> I like Linux.  I'd like to stick with it.  But if it's going to
> continually crash, I'm going to jump ship - and I'll start recommending
> to others that they do the same.
>
>
> 	Mike Edwards
>
> Brainbench certified Master Linux Administrator
> http://www.brainbench.com/transcript.jsp?pid=158188
> -----------------------------------
> Unsolicited advertisments to this address are not welcome.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Are we going too fast?

[Francois Romieu]

PinkFreud <pf-kernel@mirkwood.net> :
[...]
> kernel!), to the system with the NCR 53c810 SCSI board, which suffered
> random kernel panics anywhere from 2 hours to 5 days after booting, due to
> the ncr53c8xx driver, to YET ANOTHER system which has shown a penchant for

The (ksymoops processed-) oopses may help. You can give a try at the
sym53c8xx driver. It performs well here:
- 53c875 adapter + BX + 2.4.3/2.4.7-ac11/2.4.8 + raid1 (small server)
- 53c810 + VP3 + 2.4.2 (instant reboot at startup with 2.4.8, I guess I
fscked some option).

[...]
> until 2.2.10!).  Furthermore, I have had a HELL of a time trying
> to get responses to the first two problems (this is the first report for
> the third).  It used to be that I could ask a question on this list, and
> receive responses.  Not anymore.  I can't seem to get the time of day from
> anyone on this list now.

Try and send specific bug-reports to the maintainers. 
l-k archives may give you some light on issues with VIA chipsets.

I'm not convinced that gaining stability on a VIA + G400 + X + smp 
combo is an easy task anyway.

-- 
Ueimor

Re: Are we going too fast?

[Pete Toscano]

I'm running a SMP (2xPIII 600) on a Tyan Tiger mobo (Via Apollo Pro 133a
chipset) with a G400 and it runs fine, when I do the following:

	- disable APIC ("noapic" as a boot parameter).  Then again, the
	  system won't boot without APIC disabled.
	- use the ALSA drivers for my SoundBlaster Live.  (I haven't
	  tried the kernel-based drivers for a few version now, so this
	  situation might have changes, but up until I switched to ALSA,
	  I had crashes all the time during medium to high I/O.
	- use the uhci USB driver when I'm using a USB printer.  If I
	  use the usb-uhci driver with my USB printer, the whole system
	  locks.  This has been reported a few times on LKML,
	  linux-usb-users, and linux-usb-developers and nobody helped,
	  but a few people wrote back with "me too"s.  It was broken in
	  the trasnition from 2.4.3 to 2.4.4 and only seems to affect
	  SMP systems.  I just gave up on USB printing and went back to
	  my parallel port.

Finally, I'm using RedHat 7.1.  This system has no stability problems
now (after a long series of all kinds of stability problems).  Maybe
it's a load thing, I don't know, but it now runs stable.  

pete

On Mon, 13 Aug 2001, Francois Romieu wrote:

> I'm not convinced that gaining stability on a VIA + G400 + X + smp 
> combo is an easy task anyway.

Re: Are we going too fast?

[Alan Cox]

> 	- use the uhci USB driver when I'm using a USB printer.  If I
> 	  use the usb-uhci driver with my USB printer, the whole system
> 	  locks.  This has been reported a few times on LKML,
> 	  linux-usb-users, and linux-usb-developers and nobody helped,
> 	  but a few people wrote back with "me too"s.  It was broken in
> 	  the trasnition from 2.4.3 to 2.4.4 and only seems to affect
> 	  SMP systems.  I just gave up on USB printing and went back to
> 	  my parallel port.

usb-uhci seems to not be SMP safe. Ultimately we don't need both uhci
drivers so that hasnt been one that worried me.  Probably we should drop
the other uhci driver over time (2.5 maybe)

Alan

Re: Are we going too fast?

[Paul G. Allen]

Alan Cox wrote:
> 
> >       - use the uhci USB driver when I'm using a USB printer.  If I
> >         use the usb-uhci driver with my USB printer, the whole system
> >         locks.  This has been reported a few times on LKML,
> >         linux-usb-users, and linux-usb-developers and nobody helped,
> >         but a few people wrote back with "me too"s.  It was broken in
> >         the trasnition from 2.4.3 to 2.4.4 and only seems to affect
> >         SMP systems.  I just gave up on USB printing and went back to
> >         my parallel port.
> 
> usb-uhci seems to not be SMP safe. Ultimately we don't need both uhci
> drivers so that hasnt been one that worried me.  Probably we should drop
> the other uhci driver over time (2.5 maybe)
> 

When I first installed RH 7.1 on my Tyan K7, the system would lock upon boot when the USB module was loaded. I disabled the USB controller in the BIOS and all
was fine. After compiling 2.4.7-ac10 and running it for some time reliably, I re-enabled USB and re-compiled making sure the USB modules were included. They now
load just fine.

Note that I do not (yet) have any USB devices.

PGA
-- 
Paul G. Allen
UNIX Admin II/Programmer
Akamai Technologies, Inc.
www.akamai.com
Work: (858)909-3630
Cell: (858)395-5043

Re: Are we going too fast?

[Gérard Roudier]

On Mon, 13 Aug 2001, PinkFreud wrote:

> Please CC me in any replies, I am not subscribed to this list.
>
> Please forgive me if I seem incoherent.  It's after 3:30 AM here.

So, you will be forgiven, otherwise ... :-)

> I have installed various 2.4.x kernels on 3 seperate systems here.  *ALL*
> of them have suffered from one malady or another - from the dual PIII with
> the VIA chipset and Matrox G400 card, which locks up nicely when I switch
> from X to a text console and back to X (but NOT under a uniprocessor
> kernel!), to the system with the NCR 53c810 SCSI board, which suffered
> random kernel panics anywhere from 2 hours to 5 days after booting, due to
> the ncr53c8xx driver, to YET ANOTHER system which has shown a penchant for
> crashing (read: no response on console, can use magic sysrq, but fails to
> emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> on screen, nothing!) - and this latest is with 2.4.8!

You may want to elaborate on the ncr53c8xx problems (I maintain this
driver). More generally, you must not ignore the thousands of bugs in the
hardware you are using, but software developpers haven't access to all
errata descriptions since hardware vendors donnot like to make this
information freely available.

About ncr53c8xx problem reports, I cannot reply to all of them. You may
also send them to LSILOGIC support. They also want Linux to work with the
ncr/sym/lsi/53c8xx PCI-SCSI controllers, even with old NCR ones. Some
other vendors seem to just ignore old hardwares. For example NVIDIA that
killed (bought?) 3DFX, does not seem interested in maintaining drivers for
the 3DFX graphic chips.

> I've used Linux for over 5 years now.  In all the time I've used it, I
> have never seen this much instability in a single kernel
> series - though I've noticed each successive 'stable' series having
> more bugs than the last (2.2.x crashed once a week with SMP
> until 2.2.10!).  Furthermore, I have had a HELL of a time trying
> to get responses to the first two problems (this is the first report for
> the third).  It used to be that I could ask a question on this list, and
> receive responses.  Not anymore.  I can't seem to get the time of day from
> anyone on this list now.

I use Linux since some 0.99.x (was yygdrasil distribution). My experience
has been that 1.2.13, 2.0.27 and 2.2.13 worked reliable enough for me.
'Stable' does not means reliable for any workload. It means that we stop
developping (implies changing large portions of code or modifying
interfaces) but only focus on fixing the software with it current design
(implies only changing what is proven to be broken).  This applies to all
softwares, not only to Linux. As a result, early stable releases still
have numerous bugs that may prevent numerous systems from working
reliably. It is up to user to check releases and switch to the one that
fits his expectations.

> This brings me to the subject of this rant: are we going too fast?  New
> drivers are still showing up in each successive kernel, and yet no one
> seems to be able to fix the old bugs that already exist.  Are we looking
> to have the reliability of Windows?  It's starting to seem so - each
> successive kernel series just seems to crash more and more often.  When
> will we reach the point where Windows, on the average, will have greater
> uptime than Linux systems?  Perhaps it's time to slow down, and do some
> debugging.

The reliabity of Windows seems to be just fine for most users since it is
the O/S most of them want to use.:-)
I use Win98/SE, Win/NT 4.0, Linux-2.2.19, FreeBSD-4.2, and sometimes
NetBSD-1.5 on my personnal machine. They all work reliably enough for my
personnal usage. But, indeed, this is a station and not a server, even if
I use to sometimes stress the system under Linux and *BSDs.

> This is supposed to be a 'stable' kernel series?  I see nothing stable
> about it.
>
> Should development continue on the latest and supposedly greatest
> drivers?  Or should the existing bugs be fixed first?  I've got at least
> three up there that need taking care of, and I'm sure others on this list
> have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> what are others seeing?

Hopefully you aren't a typical computer user or you just have bad luck
with computers. :-)

> To those of you who would tell me to fix them myself: I am an
> administrator.  I know Perl.  I am not all that familiar with C, nor with
> kernel programming.  They're not my bugs, but I would fix them if I were
> able to.  I'd hope the authors of said bugs would be willing to fix them -
> but given the track record I've seen for the first two problems, I'm not
> holding my breath for the third to be fixed any time soon.

All software developpers and maintainers want their software to work and
thus bugs to be fixed. This is just sometimes hard to know what is
actually broken. My experience is that no more than 10% bug reports about
a software are due to a bug in the software that is pointed out by the
report. And for these less than 10% relevant reports, maintainers must
find what is broken... not simple as you can imagine...

> I don't know about the rest of you, but I'm going to give up soon and
> switch to NetBSD.  I've already done it on the system with the NCR 53c810
> board - and it's proven to be far more stable than 2.4.x kernels have ever
> managed to be on it.  What does that say?

You can break any O/S given an appropriate workload. Add to this all the
hidden/unknown hardware bugs that can be randomly triggerred ...

Btw, I use SYM-2 driver under Linux, FreeBSD and NetBSD 1.5. I have no
problem with it. If you plan to use Ultra-160 LSI53C1010 chips, the NetBSD
SIOP driver may be sub-optimal and, btw, it does not seem to know about
C1010 chips erratas.

You donnot seem to have given a try with FreeBSD. Were there some strong
reasons for that ?

> sauron@rivendell:~$ uptime
>  3:17AM  up 12 days, 15:20, 2 users, load averages: 1.48, 0.66, 0.31
> sauron@rivendell:~$ uname -a
> NetBSD rivendell 1.5.1 NetBSD 1.5.1 (RIVENDELL) #0: Tue Jul 31 22:58:54
> EDT 2001     root@rivendell:/usr/src/sys/arch/i386/compile/RIVENDELL i386
> sauron@rivendell:~$ dmesg | grep -i sym
> siop0 at pci0 dev 6 function 0: Symbios Logic 53c810 (fast scsi)
>
> (The controller is old - it was made by NCR before it became Symbios Logic
> - hence, why I was using the NCR driver for it, rather than the Symbios
> driver, in Linux.)
>
> Working on 13 days uptime.  That's well over twice the uptime for Linux on
> that box.  That's what happens when the kernel has bugs.

You seem so sure it is the ncr53c8xx driver that breaks your Linux ...
If it was so broken, may be I would have heared about. :-)

> Take this rant for what you will.  Personally, I switched from Windows to
> Linux 5 years ago for the stability.  If I need to switch OSs again to
> continue to have stability, I will.  Somehow, I suspect, if kernel
> development continues down this path, many others will wind up switching
> to other OSs as well.

If NetBSD fits your need, then let me encourage you to use it.

> I like Linux.  I'd like to stick with it.  But if it's going to
> continually crash, I'm going to jump ship - and I'll start recommending to
> others that they do the same.

That's unclever recommendation, in my opinion.
For example, my children are happy using Windows 98 and I donnot want to
recommend them anything else.

> 	Mike Edwards
>
> Brainbench certified Master Linux Administrator
> http://www.brainbench.com/transcript.jsp?pid=158188
> -----------------------------------
> Unsolicited advertisments to this address are not welcome.

Regards,
  Gérard.

Re: Are we going too fast?

[Justin Guyett]

On Mon, 13 Aug 2001, Gérard Roudier wrote:

> You may want to elaborate on the ncr53c8xx problems (I maintain this
> driver). More generally, you must not ignore the thousands of bugs in the
> hardware you are using, but software developpers haven't access to all
> errata descriptions since hardware vendors donnot like to make this
> information freely available.

I've got a quick unrelated question.

Why not change the name (or at least the description) of sym53c8xx to
include the 53c1010 chips, which this driver seems to work on (and on a
SMP box, no less)?


justin

Re: Are we going too fast?

[Andrzej Krzysztofowicz]

"Justin Guyett wrote:"
> Why not change the name (or at least the description) of sym53c8xx to
> include the 53c1010 chips, which this driver seems to work on (and on a
> SMP box, no less)?

For backward compatibility reasons ?
We are in a stable kernels series.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk

Re: Are we going too fast?

[Gérard Roudier]

On Mon, 13 Aug 2001, Justin Guyett wrote:

> On Mon, 13 Aug 2001, Gérard Roudier wrote:
>
> > You may want to elaborate on the ncr53c8xx problems (I maintain this
> > driver). More generally, you must not ignore the thousands of bugs in the
> > hardware you are using, but software developpers haven't access to all
> > errata descriptions since hardware vendors donnot like to make this
> > information freely available.
>
> I've got a quick unrelated question.
>
> Why not change the name (or at least the description) of sym53c8xx to
> include the 53c1010 chips, which this driver seems to work on (and on a
> SMP box, no less)?

I have an SMP box and a C1010 chip. I like the 'way' this hardware
combination 'seems' to work for me. :-)

About the driver name, I have changed it to just 'sym' for the port to
FreeBSD. Software modules are usually named using a short name under this
O/S. At the time I did the port, LSI had bought SYMBIOS, but they seemed
to want to keep with SYMBIOS name for the 53C8XX PCI-SCSI family.

Then they (LSI) invented the 53C1010, called it LSI53C1010 and designed it
in a way that made possible to use a single driver for the SYM53C8xx
series (NCR+SYMBIOS) and this one.

The current LSI53C10xx family consists in 2 different architectures that
require 2 different software drivers:

- [PCI host interface + SCSI Ultra-160 interface + SCSI scripts
  processor] that are supported by the sym53c8xx driver, the
  derivated 'sym' under FreeBSD and the latest SYM-2 (derived from sym)
  that wants to be portable.

- [PCI/X host interface + SCSI Ultra-320 interface + ARM based IO
  processor] that requires a new driver. I heared that LSILOGIC want to
  provide a driver for Linux. Note that the LSI FC controllers and those
  ones should possibly share the same software drivers.

Then, what better name for the sym53c8xx driver?

- sym has been obsoleted by lsi.
- sym53c8,10xx is confusing, given the 10xx family weirdness (see above).
- lsi is too vague a name, given the numerous chips supplied by LSI.
- siop (SCSI IO PROCESSOR) is already used and looks to me more vague
  than all other names that have ever been used for an HBA driver.:)

In my taste, sym53c8xx is still quite good name for the following reasons:

1) It is the SYMBIOS company that made the greatest development for the
   53C8XX family, in my opinion.
2) The 53C10xx chips that can be driven by the sym* drivers use a 53C1010
   core, even if then may be named 53C1000, etc..., for marketing reasons.
3) All future 53C10xx HBAs will probably be based on PCI/X + U320 + ARM
   and so will not be supported by sym* (same for SIOP, btw).

Now, we could change everything that wants to describe this driver.
Here is my current one (from sym-2 that also supports NCR53C8xx chips):

 * Device driver for the SYMBIOS/LSILOGIC 53C8XX and 53C1010 family
 * of PCI-SCSI IO processors.

Just my 0.02 euro. :)

  Gérard.

Re: Are we going too fast?

[Chris Wilson]

> > until 2.2.10!).  Furthermore, I have had a HELL of a time trying
> > to get responses to the first two problems (this is the first report
for
> > the third).  It used to be that I could ask a question on this list,
and
> > receive responses.  Not anymore.  I can't seem to get the time of day
from
> > anyone on this list now.
> 
> Try and send specific bug-reports to the maintainers. 
> l-k archives may give you some light on issues with VIA chipsets.
> 
> I'm not convinced that gaining stability on a VIA + G400 + X + smp 
> combo is an easy task anyway.

Certainly seems to be moving backwards in that respect - from 2.4.6
onwards the bog standard PS/2 keyboard does not work (at all from bootup -
"keyboard: Timeout - AT keyboard not present?(ed)") on my SMP VIA w. G400
(although I've not got as far as loading X on it without the keyboard!) :(

I can't even see what's changed in 2.4.6 that might cause this - soft_irq?
or is that completely unrelated to the keyboard???


Chris

Re: Are we going too fast?

[szonyi calin]

--- Chris Wilson <jakdaw@lists.jakdaw.org> wrote:

> Certainly seems to be moving backwards in that
> respect - from 2.4.6
> onwards the bog standard PS/2 keyboard does not work
> (at all from bootup -
> "keyboard: Timeout - AT keyboard not present?(ed)")
> on my SMP VIA w. G400
> (although I've not got as far as loading X on it
> without the keyboard!) :(
> 
> I can't even see what's changed in 2.4.6 that might
> cause this - soft_irq?
> or is that completely unrelated to the keyboard???
> 
> 
> Chris
> -

I have too a PS/2 keyboard and no problem at all with
2.4.x kernels. 2.4.0-2.4.8
Cx486 UP 


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Re: Are we going too fast?

[Alan Cox]

> of them have suffered from one malady or another - from the dual PIII with
> the VIA chipset and Matrox G400 card, which locks up nicely when I switch

Welcome to wacky hardware. To get a G400 stable on x86 you need at least

XFree86 4.1 if you are running hardware 3D (and DRM 4.1)
2.4.8 or higher with the VIA fixes
Preferably a very recent BIOS update for the VIA box

Of those only the XFree hardware 3d stuff is software bug related.

> emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> on screen, nothing!) - and this latest is with 2.4.8!

The qnxfs code is experimental - so I can believe it might fail in 2.4. I'd
be very interested in info on that one.

> Should development continue on the latest and supposedly greatest
> drivers?  Or should the existing bugs be fixed first?  I've got at least
> three up there that need taking care of, and I'm sure others on this list
> have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> what are others seeing?

Near enough 0%. But then I try and avoid buying broken chipsets.

> I like Linux.  I'd like to stick with it.  But if it's going to
> continually crash, I'm going to jump ship - and I'll start recommending to

If you want maximum stability you want to be running 2.2 or even 2.0. Newer
less tested code is always less table. 2.4 wont be as stable as 2.2 for a
year yet.

Alan

Re: Are we going too fast?

[Anders Larsen]

On 2001-08-13 15:11 Alan Cox wrote:
> > emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> > (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> > on screen, nothing!) - and this latest is with 2.4.8!
> 
> The qnxfs code is experimental - so I can believe it might fail in 2.4. I'd
> be very interested in info on that one.

The qnxfs code is really quite stable - that's the first time in more than a
year that I hear of any problem reading a qnx file-system; actually, I've been
considering removing the 'experimental' tag, but now I'll reconsider...

Incidentally, I use the qnxfs in a production environment here (tried'em all
up to 2.4.7 - guess I'll better switch to 2.4.8 right now to check, although
the qnxfs code has not changed from 2.4.7)

I'll be very interested in hearing what you find out.

cheers
  Anders (maintainer, qnx4fs)
-- 
"In theory there is no difference between theory and practice.
 In practice there is." - Yogi Berra

Re: Are we going too fast?

[Anders Larsen]

Anders Larsen wrote:
> 
> On 2001-08-13 15:11 Alan Cox wrote:
> > > emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> > > (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> > > on screen, nothing!) - and this latest is with 2.4.8!
> >
> > The qnxfs code is experimental - so I can believe it might fail in 2.4. I'd
> > be very interested in info on that one.
> 
> The qnxfs code is really quite stable - that's the first time in more than a
> year that I hear of any problem reading a qnx file-system; actually, I've been
> considering removing the 'experimental' tag, but now I'll reconsider...

Come to think of it...
Mike didn't mention any details of the hardware where he's experiencing this
bug, but is it possibly a multiprocessor machine?
Since I only have UP's to test on, the qnxfs might have SMP issues.

Could someone please glance through the code in fs/qnx4 to check if there
are any obvious problems?

cheers
  Anders (maintainer, qnx4fs)
-- 
"In theory there is no difference between theory and practice.
 In practice there is." - Yogi Berra

Re: Are we going too fast?

[hugang]

On Mon, 13 Aug 2001 03:43:05 -0400 (EDT)
PinkFreud <pf-kernel@mirkwood.net> wrote:

> 
> I have installed various 2.4.x kernels on 3 seperate systems here.  *ALL*
> of them have suffered from one malady or another - from the dual PIII with
> the VIA chipset and Matrox G400 card, which locks up nicely when I switch
> from X to a text console and back to X (but NOT under a uniprocessor
> kernel!), to the system with the NCR 53c810 SCSI board, which suffered
> random kernel panics anywhere from 2 hours to 5 days after booting, due to
> the ncr53c8xx driver, to YET ANOTHER system which has shown a penchant for
> crashing (read: no response on console, can use magic sysrq, but fails to
> emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> on screen, nothing!) - and this latest is with 2.4.8!
> 

> sauron@rivendell:~$ uptime
>  3:17AM  up 12 days, 15:20, 2 users, load averages: 1.48, 0.66, 0.31
> sauron@rivendell:~$ uname -a
> NetBSD rivendell 1.5.1 NetBSD 1.5.1 (RIVENDELL) #0: Tue Jul 31 22:58:54
> EDT 2001     root@rivendell:/usr/src/sys/arch/i386/compile/RIVENDELL i386
> sauron@rivendell:~$ dmesg | grep -i sym
> siop0 at pci0 dev 6 function 0: Symbios Logic 53c810 (fast scsi)
> 
> (The controller is old - it was made by NCR before it became Symbios Logic
> - hence, why I was using the NCR driver for it, rather than the Symbios
> driver, in Linux.)
> 
> Working on 13 days uptime.  That's well over twice the uptime for Linux on
> that box.  That's what happens when the kernel has bugs.
> 
> Take this rant for what you will.  Personally, I switched from Windows to
> Linux 5 years ago for the stability.  If I need to switch OSs again to
> continue to have stability, I will.  Somehow, I suspect, if kernel
> development continues down this path, many others will wind up switching
> to other OSs as well.
> 

	I think this problem can fix if your can report the crash message . (Oops,...)
Beacuse the netbsd can work fine on it , So I true the linux kernel also can  work fine on it.

-- 
Best Regard!
礼！
----------------------------------------------------
hugang : 胡刚 	GNU/Linux User
email  : gang_hu@soul.com.cn linuxbest@soul.com.cn
Tel    : +861068425741/2/3/4
Web    : http://www.soul.com.cn

	Beijing Soul technology Co.Ltd.
	   北京众志和达科技有限公司
----------------------------------------------------

Re: Are we going too fast?

[Anton Altaparmakov]

At 14:11 13/08/01, Alan Cox wrote:
> > Should development continue on the latest and supposedly greatest
> > drivers?  Or should the existing bugs be fixed first?  I've got at least
> > three up there that need taking care of, and I'm sure others on this list
> > have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> > boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> > what are others seeing?
>
>Near enough 0%. But then I try and avoid buying broken chipsets.

0% here. Admittedly I have only one VIA box and only as of this weekend but 
it works great with all kernels tried. [Epox 8KTA3 mobo, KT133A chipset 
running 266MHz FSB and 1.33GHz Athlon Thunderbird, PC133 CL2 RAM from 
Micron, active PFC power supply, BIOS setup to the fastest settings it 
allows me to set it to while stayin in spec (i.e. no o/c of CPU or 
busses!), IBM Ericson ATA100 41GiB HD attached to the VIA controller].

Tried kernels are 2.4.4-4GB (from SuSE 7.1 binary install Pentium 
optimizations I believe), 2.4.8 and 2.4.8-ac1 (the latter two both compiled 
with Athlon optimizations) and the system is absolutely fine. bonnie 
scores >30MiB/s (in mostly 34-39 MiB/s) on intelligent read/write tests 
with DMA enabled and a working set 2x size of RAM (i.e. 512MiB test size on 
256MiB RAM). Even when using fsync after every operation i/o speed is 
almost unaffected (it drops a bit but only by about 1-2MiB/s).

Copying 15 GiB of data from one partition to the other on the same disk 
worked fine. Compiling kernels works fine (Admittedly it only takes just 
over 3 minutes to compile the kernel with make -j 2 bzImage, so it's not 
too much of a stress test).

Oh and the VIA AC97 audio codec seems to work beautifully, too. As does X 
(both 3.3.x and 4.0.3) is fine, too. (I use an ancient ET6000 PCI gfx card.)

So, basically no problems here. I was quite worried about buying a VIA 
chipset but now it seems like a great buy. (-:

The only thing that's slightly annoying is that during boot three of the 
PCI resources from the VIA chipset are reported as "unknown, treating 
transparently" (or some simillar msg), don't have box handy to say what 
they were exactly... if anyone is intersted in exact messages I can provide 
dmesg + lspci -vvv output once I get home tonight.

> > I like Linux.  I'd like to stick with it.  But if it's going to
> > continually crash, I'm going to jump ship - and I'll start recommending to
>
>If you want maximum stability you want to be running 2.2 or even 2.0. Newer
>less tested code is always less table. 2.4 wont be as stable as 2.2 for a
>year yet.

Or alternatively buy quality components that other people have tested under 
Linux with kernel 2.4...

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: Are we going too fast?

[Stephen Satchell]

At 02:11 PM 8/13/01 +0100, Alan Cox wrote:
> > Should development continue on the latest and supposedly greatest
> > drivers?  Or should the existing bugs be fixed first?  I've got at least
> > three up there that need taking care of, and I'm sure others on this list
> > have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> > boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> > what are others seeing?
>
>Near enough 0%. But then I try and avoid buying broken chipsets.

Back in the old 2.0 days there was a couple of HOWTOs that discussed what 
hardware worked and didn't work under Linux.  I remember using the 
Ethernet-HOWTO as a "shopping list" when going to ham fests, "Wierd Stuff", 
and similar consignment/surplus/boneyard houses.  Have these HOWTOs been 
maintained?

(I've noticed that a number of very, very useful HOWTOs have fallen into 
the "unmaintained" category.)

I happen to think that "stories around the campfire" are fine, but with an 
OS like Linux we should have the "Campfire FAQ"...  :)

Satch

ext3-2.4-0.9.4

[Andrew Morton]

An update to the ext3 filesystem for 2.4 kernels is available at

	http://www.uow.edu.au/~andrewm/linux/ext3/

The diffs are against linux-2.4.7 and linux-2.4.6-ac5.

The changelog is there.  One rarely-occurring but oopsable bug
was fixed and several quite significant performance enhancements
have been made.  These are in addition to the performance fixes
which went into 0.9.3.

Ted has put out a prelease of e2fsprogs-1.23 which supports
filesystem type `auto' in /etc/fstab, so it is now possible to
switch between ext3- and non-ext3-kernels without changing
any configuration.

It is recommended that users of earlier ext3 releases upgrade
to 0.9.4.

For people who are undertaking performance testing, it is perhaps
useful to point out that ext3 operates in one of three different
journalling modes, and that these modes have very different
functionality and very different performance characteristics.
Really, you need to test all three and balance the functionality
which each mode offers against the throughput which you obtain
in your application.


The modes are:

data=writeback

  This is classic metadata-only journalling.  File data is written
  back to the main fs lazily.  After a crash+recovery the fs's
  structural integrity is preserved, but the *contents* of files
  can and will contain old, stale data.  Potentially hundreds of
  megabytes of it.

  This is the fastest mode for normal filesystem applications.

data=ordered

  The fs ensures that file data is written into the main fs prior
  to committing its metadata.  Hence after a crash+recovery, your
  files will contain the correct data.

  This is the default operating mode and throughput is good. It
  adds about one second to a four minute kernel compile when
  compared with ext2.   Under heavier loads the difference
  becomes larger.

data=journal

  All data (as well as to metadata) is written to the journal
  before it is released to the main fs for writeback.
  
  This is a specialised mode - for normal fs usage you're better
  off using ordered data, which has the same benefits of not corrupting
  data after crash+recovery.  However for applications which require
  synchronous operation such as mail spools and synchronously exported
  NFS servers, this can be a performance win.  I have seen dbench
  figures in this mode (where the files were opened O_SYNC) running
  at ten times the throughput of ext2.  Not that this is the expected
  benefit for other applications!


Looking at the above issues, one may initially think that the
post-recovery data corruption is a serious issue with writeback mode,
and that there are big advantages to using journalled or ordered data.

However, even in these modes the affected files may be shorter-than-expected
after recovery, because the app hadn't finished writing them yet.  And
usually, a truncated file is just as useless as one which contains
garbage - it needs to be deleted.

It's not really as simple as that - for small (< a few hundred k) files,
it tends to be the case that either the whole file is intact after a crash,
or none of it is.  This is because the journalling mechanism starts a
new transaction every five seconds, and a typical open/write/close operation
usually fits entirely inside this window.

There is also a security issue to be considered: a recovered writeback-mode
filesystem will expose other people's old data to unintended recipients.


Hopefully this description will help people make their deployment choices.
If not, assistance is available on the ext3-users@redhat.com mailing list.

-

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Thu, 26 Jul 2001, Andrew Morton wrote:

> data=journal
> 
>   All data (as well as to metadata) is written to the journal
>   before it is released to the main fs for writeback.
>   
>   This is a specialised mode - for normal fs usage you're better
>   off using ordered data, which has the same benefits of not corrupting
>   data after crash+recovery.  However for applications which require
>   synchronous operation such as mail spools and synchronously exported
>   NFS servers, this can be a performance win.  I have seen dbench

In ordered and journal mode, are meta data operations, namely creating a
file, rename(), link(), unlink() "synchronous" in the sense that after
the call has returned, the effect of this call is never lost, i. e., if
link(2) has returned and the machine crashes immediately, will the next
recovery ALWAYS recover the link?

Or will ext3 still need chattr +S?

Does it still support chattr +S at all?

Synchronous meta data operations are crucial for mail transfer agents
such as Postfix or qmail. Postfix has up until now been setting
chattr +S /var/spool/postfix, making original (esp. soft-updating) BSD
file systems significantly faster for data (payload) writes in this
directory than ext2.

Note: I'm not on the ext3-users list. Please Cc: back replies.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Andrew Morton]

Matthias Andree wrote:
> 
> On Thu, 26 Jul 2001, Andrew Morton wrote:
> 
> > data=journal
> >
> >   All data (as well as to metadata) is written to the journal
> >   before it is released to the main fs for writeback.
> >
> >   This is a specialised mode - for normal fs usage you're better
> >   off using ordered data, which has the same benefits of not corrupting
> >   data after crash+recovery.  However for applications which require
> >   synchronous operation such as mail spools and synchronously exported
> >   NFS servers, this can be a performance win.  I have seen dbench
> 
> In ordered and journal mode, are meta data operations, namely creating a
> file, rename(), link(), unlink() "synchronous" in the sense that after
> the call has returned, the effect of this call is never lost, i. e., if
> link(2) has returned and the machine crashes immediately, will the next
> recovery ALWAYS recover the link?

No, they're not synchronous by default.  After recovery they
will either be wholly intact, or wholly absent.

> Or will ext3 still need chattr +S?

Yes, if the app doesn't support O_SYNC or fsync().  I believe
that MTA's *do* support those things.
 
> Does it still support chattr +S at all?

Yes.

> Synchronous meta data operations are crucial for mail transfer agents
> such as Postfix or qmail. Postfix has up until now been setting
> chattr +S /var/spool/postfix, making original (esp. soft-updating) BSD
> file systems significantly faster for data (payload) writes in this
> directory than ext2.

If postfix is capable of opening the files O_SYNC or of doing
fsync() on them then the `chattr +s' is no longer necessary - unlike
ext2, when the O_SYNC write() or the fsync() return, the directory
contents (as well as the inode, bitmaps, data, etc) will all be tight on
disk and will be restored after a crash.

This should speed things up considerably, especially with journalled-data
mode.  I need to test and characterise this some more to come up with some
quantitative results and configuration recommendations.


BTW, if you have more-than-modest throughput requirements, don't
even *think* of mounting the fs with `mount -o sync'. Our performance
in this mode is terrible :(

I have a hack somewhere which fixes this as much as it can be fixed, but
I didn't even bother committing it.  It's feasible, but tiresome.

A better solution is to fix some lock inversion problems in the core
kernel which prevent optimal implementation of data-journalling
filesystems.  I don't really expect this to occur medium-term or ever.

A middle-ground solution may be to add an fs-private `osync' mount
option, so all files are treated similarly to O_SYNC, which would
work well.

-

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Thu, 26 Jul 2001, Andrew Morton wrote:

> > In ordered and journal mode, are meta data operations, namely creating a
> > file, rename(), link(), unlink() "synchronous" in the sense that after
> > the call has returned, the effect of this call is never lost, i. e., if
> > link(2) has returned and the machine crashes immediately, will the next
> > recovery ALWAYS recover the link?
> 
> No, they're not synchronous by default.  After recovery they
> will either be wholly intact, or wholly absent.
> 
> > Or will ext3 still need chattr +S?
> 
> Yes, if the app doesn't support O_SYNC or fsync().  I believe
> that MTA's *do* support those things.
>  
> > Does it still support chattr +S at all?
> 
> Yes.
> 
> > Synchronous meta data operations are crucial for mail transfer agents
> > such as Postfix or qmail. Postfix has up until now been setting
...
> A middle-ground solution may be to add an fs-private `osync' mount
> option, so all files are treated similarly to O_SYNC, which would
> work well.

You seem to be missing the point, because I wasn't verbose enough, so I
will try to rephrase this and explain. This may turn out to be a feature
request. :-}

Before going into detail, MTAs do know about fsync(). ext3 synching
relevant directory parts as part of fsync() is a great achievement.
Finally, more than five years after initial complaints, Linux is SLOWLY
getting somewhere for speeding up reliable MTA operation.

But that's the smaller piece. Common MTAs such as Postfix or qmail
rename or link files into place (their queues, the mail spool). With the
advent of journalling came the atomicity of rename operations. That's
also a great achievement.

However, the remaining problem is being synchronous with respect to open
(fixed for ext3 with your fsync() as I understand it), rename, link and
unlink. With ext2, and as you write it, with ext3 as well, there is
currently no way to tell when the link/rename has been committed to
disk, unless you set mount -o sync or chattr +S or call sync() (the
former is not an option because it's far too expensive).


The official statement by Dr. Wietse Venema (who wrote Postfix) is,
Postfix REQUIRES synchronous directory updates (open, rename, link,
unlink, in order of decreasing importance). Wietse refuses to wrap all
these calls for Linux.

Similar assumptions hold for qmail.


So, what would help the common MTA? osync wouldn't, MTAs know how to use
fsync().  dirsync or bsdstyle or however it's called, as chattr and
mount options, would help. This option should make all directory
operations (open/creat/fsync, rename, link, unlink, symlink, possibly
close) synchronous in respect to affected directory and meta data while
leaving application data (payload) operations asynchronous (applications
can then choose when to call fsync() to flush the data to disk).

A much better file system for an MTA might be ext3fs with
data=journalled and dirsync mount/chattr option. Would you deem it
possible to get such an option done before ext3fs 1.0.0?

I hope this makes the requirements of this particular group of
applications clear.

Thanks again to everyone involved with the ext3fs development.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Thu, 26 Jul 2001, Matthias Andree wrote:

> So, what would help the common MTA?

Not relying on non-supported semantics to save your ass.

Rename() is atomic in the sense that you either see the
old name or the new name, but I don't know of systems
which guarantee atomicity across a system crash.

In fact, knowing how hard disks work mechanically, only
journaling filesystems could have an extention to make
this work.  Ie. this is NOT something you can rely on ;)

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Thu, 26 Jul 2001, Rik van Riel wrote:

> In fact, knowing how hard disks work mechanically, only
> journaling filesystems could have an extention to make
> this work.  Ie. this is NOT something you can rely on ;)

This is not about failing hard disks. It is about premature
acknowledgment of something which has not happened at that time.

Linux cannot possibly fix all incomplete protocols, specifications and
implementation, but it can fix its own behaviour.

Everything is about speed, and allowing the MTA to use a (weaker)
dirsync rather than allsync option would speed things up without
sacrificing reliability.

MTA reliability is NOT about failing disk drives. If it falls over, you
notice that. If files are in the wrong directory or not there at all,
you don't necessarily notice until someone complains.

Please don't get in the way of finally fixing things just because
someone might have a broken item that could endanger your data. I have a
huge magnet here...

The competition is there and it has names: BSD + ufs + softupdates,
Solaris + logging ufs. Read MTA mailing lists before obstructing.

Thanks.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Thu, 26 Jul 2001, Matthias Andree wrote:
> On Thu, 26 Jul 2001, Rik van Riel wrote:
>
> > In fact, knowing how hard disks work mechanically, only
> > journaling filesystems could have an extention to make
> > this work.  Ie. this is NOT something you can rely on ;)
>
> This is not about failing hard disks. It is about premature
> acknowledgment of something which has not happened at that time.

So you didn't read what I was writing.

Let me explain it to you slowly:

Disks.  Write.  One.  Write.  At.  A.  Time.

A rename often needs as many as 4 or 5 writes,
ergo, you CANNOT do a rename atomically without
journaling and transactions.

> The competition is there and it has names: BSD + ufs + softupdates,
> Solaris + logging ufs. Read MTA mailing lists before obstructing.

BSD + softupdates is physically incapable of doing what
you suggest it does.  This can be proven from the lack
of transactions and the way hard disks work physically.

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Thu, 26 Jul 2001, Rik van Riel wrote:

> On Thu, 26 Jul 2001, Matthias Andree wrote:
> > On Thu, 26 Jul 2001, Rik van Riel wrote:
> >
> > > In fact, knowing how hard disks work mechanically, only
> > > journaling filesystems could have an extention to make
> > > this work.  Ie. this is NOT something you can rely on ;)
> >
> > This is not about failing hard disks. It is about premature
> > acknowledgment of something which has not happened at that time.
> 
> So you didn't read what I was writing.

Sorry.

> Let me explain it to you slowly:
> 
> Disks.  Write.  One.  Write.  At.  A.  Time.
> 
> A rename often needs as many as 4 or 5 writes,
> ergo, you CANNOT do a rename atomically without
> journaling and transactions.

You're missing the point, with this as the previous mail. The MTA is not
going to change from one unsupported/incompatible interface (that only
Linux suffers from) and if it did, it would still do the wrong thing.

MTAs often run multiple processes, and if these all open the same
directory and sync it while others have changes open that don't need a
sync at that time and will sync later, you're getting no further than
with chattr +S or mount -o sync.

It's not about atomicity itself, but about
first. write. all. required. blocks. for. a. certain. change.
physically. to. disc.   and. only. after. this. do. return. from.
rename, link, unlink. function. calls.

I'm aware of phase-tree concepts ("single block write switches from one
consistent state to another") and I'm aware that ext3fs and reiserfs do
feature atomic renames (after crash recovery).

That a drive might fall over or the power might fail before all writes
of a certain rename operation have completed is harmless UNLESS you lied
to someone that the operation was already complete (when it wasn't).

> > The competition is there and it has names: BSD + ufs + softupdates,
> > Solaris + logging ufs. Read MTA mailing lists before obstructing.
> 
> BSD + softupdates is physically incapable of doing what
> you suggest it does.  This can be proven from the lack
> of transactions and the way hard disks work physically.

You misunderstood me. I'm not talking about atomicity.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Alan Cox]

> On Thu, 26 Jul 2001, Rik van Riel wrote:
> > In fact, knowing how hard disks work mechanically, only
> > journaling filesystems could have an extention to make
> > this work.  Ie. this is NOT something you can rely on ;)
> 
> This is not about failing hard disks. It is about premature
> acknowledgment of something which has not happened at that time.

Rik is right. It isnt just about premature notification - its about 
atomicity. At the point you are notified the data has been queued for disk
I/O. Even on traditional BSD ufs with synchronous metadata you still had
points where a crash left the rename partially complete and nothing but a
log or an atomic update system is going to fix that.

> The competition is there and it has names: BSD + ufs + softupdates,
> Solaris + logging ufs. Read MTA mailing lists before obstructing.

All of which are - not unsuprisingly - using a log. In fact Solaris logging
ufs and ext3 are very similar ideas - adding a log to an existing fs.

Alan

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Thu, 26 Jul 2001, Alan Cox wrote:

> > The competition is there and it has names: BSD + ufs + softupdates,
> > Solaris + logging ufs. Read MTA mailing lists before obstructing.
>
> All of which are - not unsuprisingly - using a log. In fact
> Solaris logging ufs and ext3 are very similar ideas - adding a
> log to an existing fs.

Softupdates isn't using logging.  Furthermore, even
the journaling filesystems won't all guarantee that
the various parts of a rename() operation will all
be in the same transaction.

An MTA which relies on this is therefore Broken(tm).

cheers,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Andrew Morton]

Rik van Riel wrote:
> 
> 
> Furthermore, even the journaling filesystems won't all guarantee that
> the various parts of a rename() operation will all be in the same
> transaction.

umm..  I'd certainly hope that they do guarantee this.

The only operations which can't trivially fit into a single
transaction are write() and truncate().
 
-

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Thu, 26 Jul 2001, Rik van Riel wrote:

> An MTA which relies on this is therefore Broken(tm).

MTAs rely on TRULY, ULTIMATELY AND DEFINITELY SYNCHRONOUS directory
updates, nothing else. And because they do so, and most systems have
them, and MTAs are portable, they choose chattr +S on Linux. And that's
a performance problem because it doesn't come for free, but also with
synchronous data updates, which are unnecessary because there is
fsync().

That's already the complete story about MTAs on Linux.

If Linux HAD a mode (it doesn't) to have just synchronous directory
updates, MTAs could stop using chattr +S and be faster.


MTAs do NOT care how the file system is internally managed, they only
rely on the rename operation having completed physically on disk before
the "my rename call has returned 0" event. They expect that with the
call returning the rename operation has completed ultimately, finally,
for good, definitely and the old file will not reappear after a crash.

(Note that the atomicity addressed in the man pages and Unix
specifications is a different one: it deals with the visibility of the
changes in the system, not with the functioning of the file system.)

That's why *BSD + softupdates is still recommended over Linux for pure
mail transfer agents by people.

This still implies the drive doesn't lie to the OS about the completion
of write requests: write cache == off.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Christoph Hellwig]

In article <20010726164516.R17244@emma1.emma.line.org> you wrote:
> On Thu, 26 Jul 2001, Rik van Riel wrote:
>
>> An MTA which relies on this is therefore Broken(tm).

> MTAs rely on TRULY, ULTIMATELY AND DEFINITELY SYNCHRONOUS directory
> updates, nothing else.

And thus they are broken, all caps don't make that less true.

> And because they do so, and most systems have them,

"and most systems have them"...

> MTAs do NOT care how the file system is internally managed, they only
> rely on the rename operation having completed physically on disk before
> the "my rename call has returned 0" event. They expect that with the
> call returning the rename operation has completed ultimately, finally,
> for good, definitely and the old file will not reappear after a crash.

So they rely on undocumented and non standadisized semantics of some
implementations.  I'd call this buggy.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: ext3-2.4-0.9.4

[Matthias Andree]

Christoph Hellwig schrieb am Donnerstag, den 26. Juli 2001:

> > MTAs do NOT care how the file system is internally managed, they only
> > rely on the rename operation having completed physically on disk before
> > the "my rename call has returned 0" event. They expect that with the
> > call returning the rename operation has completed ultimately, finally,
> > for good, definitely and the old file will not reappear after a crash.
> 
> So they rely on undocumented and non standadisized semantics of some
> implementations.  I'd call this buggy.

If each in the set of "supported systems" document this behaviour for
themselves, there is no bug. I didn't check however for systems other
than FreeBSD 4.x and Linux. And "Linux support" forces these semantics
with chattr +S, at a high price.

Go tell your opinion to those people that refuse to wrap their
rename/link calls with open()/fsync() calls to the respective parents,
particularly Daniel J. Bernstein, Wietse Z. Venema, among others. I
don't possibly know all MTAs.

You will encounter these or similar questions/objections:

1. what systems apart from Linux need this kind of Pampers?

2. manual lookups of parent directories cause additional overhead better
avoided in performance critical systems.

You would not be the first one to tell them...

Re: ext3-2.4-0.9.4

[Alan Cox]

> Go tell your opinion to those people that refuse to wrap their
> rename/link calls with open()/fsync() calls to the respective parents,
> particularly Daniel J. Bernstein, Wietse Z. Venema, among others. I
> don't possibly know all MTAs.

I've pointed things out to Mr Bernstein before. His normal replies are not
helpful and generally vary between random ravings and threatening to sue
people who publish things on web pages he disagrees with.

Alan

Re: ext3-2.4-0.9.4

[Linus Torvalds]

In article <E15PnTJ-0003z0-00@the-village.bc.nu>,
Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
>> Go tell your opinion to those people that refuse to wrap their
>> rename/link calls with open()/fsync() calls to the respective parents,
>> particularly Daniel J. Bernstein, Wietse Z. Venema, among others. I
>> don't possibly know all MTAs.
>
>I've pointed things out to Mr Bernstein before. His normal replies are not
>helpful and generally vary between random ravings and threatening to sue
>people who publish things on web pages he disagrees with.

Now, now, Alan. He has strong opinions, I'll agree, but I've never see
him threaten to _sue_.

Also, I think he eventually agreed on the logic of fsync() on the
directory, and we even had a bug report (quickly fixed) for reiserfs
because it got confused by it.

Of course, knowing Dan, I suspect the fsync() is accompanied by several
lines of derogatory comments about the need for it (not that I've
checked). 

Everybody tends to agree that synchronous IO is stupid and slow, but
some people are just so fixated with "That is how it has been done for
20 years..".

Logging filesystems together with explicit logging points (namely,
"fsync()") are very obviously a superior answer from a technical
standpoint, but that doesn't impact the emotional arguments ("but I want
things to stay the same!"). 

		Linus

Re: ext3-2.4-0.9.4

[Alan Cox]

> >I've pointed things out to Mr Bernstein before. His normal replies are not
> >helpful and generally vary between random ravings and threatening to sue
> >people who publish things on web pages he disagrees with.
> 
> Now, now, Alan. He has strong opinions, I'll agree, but I've never see
> him threaten to _sue_.

Ask Alexey about the end of the syncookie "debate"

Re: ext3-2.4-0.9.4

[Larry McVoy]

On Thu, Jul 26, 2001 at 04:18:59PM +0000, Linus Torvalds wrote:
> In article <E15PnTJ-0003z0-00@the-village.bc.nu>,
> Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
> >> Go tell your opinion to those people that refuse to wrap their
> >> rename/link calls with open()/fsync() calls to the respective parents,
> >> particularly Daniel J. Bernstein, Wietse Z. Venema, among others. I
> >> don't possibly know all MTAs.
> >
> >I've pointed things out to Mr Bernstein before. His normal replies are not
> >helpful and generally vary between random ravings and threatening to sue
> >people who publish things on web pages he disagrees with.
> 
> Now, now, Alan. He has strong opinions, I'll agree, but I've never see
> him threaten to _sue_.

In the for what it is worth department, I spent the day with Daniel after
the kernel summit meeting a while back, we talked file systems for about
6 or 7 hours.  While I'll plead guilty to getting mad at him (his ego
is up there with mine :-), I came away impressed with his knowledge.
I get the feeling that he thinks deeply about the problems he works on,
he's probably right a lot of the time, *and* as with many deep thinkers,
he has a problem communicating his ideas.

This is a common problem, and I'm not sure Daniel is fully aware of it.
One cannot expect other people to have done the same thinking and have
the same context, and when they do not, it is easy to get frustrated.
I think that some of Daniel's "ravings" are probably just frustration
that the other person "doesn't get it".

That doesn't mean that Daniel is the right hand of God or anything, I've
seen him do some stupid things but I've seen all of us do some stupid
things, so that doesn't mean much.  I think Daniel does way more smart
things than stupid things, and not all of us can claim that (sort of
like half of the drivers are below average, noone likes that idea either).

What I'm trying to say is that I think Daniel is one of the good guys,
even though his user interface could stand improvement (a common thing
amongst smart people) and it looks like it would be smart to figure out
how to work with him.

Just my opinion...
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: ext3-2.4-0.9.4

[Andre Pang]

On Thu, Jul 26, 2001 at 09:54:52AM -0700, Larry McVoy wrote:

> What I'm trying to say is that I think Daniel is one of the good guys,
> even though his user interface could stand improvement (a common thing
> amongst smart people) and it looks like it would be smart to figure out
> how to work with him.

there's a work-in-progress called ReiserSMTP[1] which rewrites
some bits of qmail so it works better with ReiserFS, although i
can imagine that it would improve things on Linux as a whole.

this is getting off-topic, but since the various parties involved
(Linux vs djb/Wietse/etc[2]) are probably never going to agree
on semantics, i'm wondering if it's possible to ask them to
write the software in such a way that it's possible to 'drop in'
your own functions relevant for sync'ing.  then the MTA writers
can go and use their traditional filesystem assumptions and
Linux users can produce very small patches to support the
correct behaviour under Linux.

it would be _nice_ if the ext3 guys would be more willing to
implement directory-syncing on link/rename/etc, though, even as
an option.  a 'mount -o dirsync' would be enough; no need for
chattr +D stuff.  Linux tends to have a bad name as a platform
as an MTA just because of all this, which is a shame.  it would be
nice if a fix is possible.  *nudge nudge Mr. Morton* :)

    [1] http://www.jedi.claranet.fr/reisersmtp.html

    [2] hey, this might be the first time they agree on
        anything!


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save

Re: ext3-2.4-0.9.4

[Hans Reiser]

Andre Pang wrote:
> 
> On Thu, Jul 26, 2001 at 09:54:52AM -0700, Larry McVoy wrote:
> 
> > What I'm trying to say is that I think Daniel is one of the good guys,
> > even though his user interface could stand improvement (a common thing
> > amongst smart people) and it looks like it would be smart to figure out
> > how to work with him.
> 
> there's a work-in-progress called ReiserSMTP[1] which rewrites
> some bits of qmail so it works better with ReiserFS, although i
> can imagine that it would improve things on Linux as a whole.

It stopped due to flakiness on the part of all parties including myself, the programmer, and the
sponsor, but it would be nice if a sponsor and programmer came along to restart it.

> 
> this is getting off-topic, but since the various parties involved
> (Linux vs djb/Wietse/etc[2]) are probably never going to agree
> on semantics, i'm wondering if it's possible to ask them to
> write the software in such a way that it's possible to 'drop in'
> your own functions relevant for sync'ing.  then the MTA writers
> can go and use their traditional filesystem assumptions and
> Linux users can produce very small patches to support the
> correct behaviour under Linux.
> 
> it would be _nice_ if the ext3 guys would be more willing to
> implement directory-syncing on link/rename/etc, though, even as
> an option.  a 'mount -o dirsync' would be enough; no need for
> chattr +D stuff.  Linux tends to have a bad name as a platform
> as an MTA just because of all this, which is a shame.  it would be
> nice if a fix is possible.  *nudge nudge Mr. Morton* :)
> 
>     [1] http://www.jedi.claranet.fr/reisersmtp.html
> 
>     [2] hey, this might be the first time they agree on
>         anything!
> 
> --
> #ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


No, Linus is right and the MTA guys are just wrong.  The mailers are the place to fix things, not
the kernel.  If the mailer guys want to depend on the kernel being stupidly designed, tough. 
Someone should fix their mailer code and then it would run faster on Linux than on any other
platform.

Hans

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Thu, 26 Jul 2001, Hans Reiser wrote:

> No, Linus is right and the MTA guys are just wrong.  The mailers are
> the place to fix things, not the kernel.  If the mailer guys want to
> depend on the kernel being stupidly designed, tough.  Someone should
> fix their mailer code and then it would run faster on Linux than on
> any other platform.

Well, some systems are even documented that way, so there's nothing with
"depend on the kernel being stupidly designed", but "depend on what
mount(8) says".

MTA authors don't play games, they also write that their software relies
on this behaviour, as laid out.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Sun, 29 Jul 2001, Matthias Andree wrote:
> On Thu, 26 Jul 2001, Hans Reiser wrote:
>
> > No, Linus is right and the MTA guys are just wrong.  The mailers are
> > the place to fix things, not the kernel.  If the mailer guys want to
> > depend on the kernel being stupidly designed, tough.  Someone should
> > fix their mailer code and then it would run faster on Linux than on
> > any other platform.
>
> Well, some systems are even documented that way, so there's nothing
> with "depend on the kernel being stupidly designed", but "depend on
> what mount(8) says".

The key word here is "some systems".

> MTA authors don't play games, they also write that their software
> relies on this behaviour, as laid out.

"MTA authors don't play games" ?!?!

I wonder how that explains things like QMQP or the
next-to-useless bounce messages generated by Notes ;)

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

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: ext3-2.4-0.9.4

[Hans Reiser]

Matthias Andree wrote:
> 
> On Thu, 26 Jul 2001, Hans Reiser wrote:
> 
> > No, Linus is right and the MTA guys are just wrong.  The mailers are
> > the place to fix things, not the kernel.  If the mailer guys want to
> > depend on the kernel being stupidly designed, tough.  Someone should
> > fix their mailer code and then it would run faster on Linux than on
> > any other platform.
> 
> Well, some systems are even documented that way, so there's nothing with
> "depend on the kernel being stupidly designed", but "depend on what
> mount(8) says".
> 
> MTA authors don't play games, they also write that their software relies
> on this behaviour, as laid out.
> 
> --
> Matthias Andree
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
Documenting their code won't make it fast or well designed.

Hans

Re: ext3-2.4-0.9.4

[Andrew Morton]

Andre Pang wrote:
> 
> it would be _nice_ if the ext3 guys would be more willing to
> implement directory-syncing on link/rename/etc, though, even as
> an option.  a 'mount -o dirsync' would be enough; no need for
> chattr +D stuff.  Linux tends to have a bad name as a platform
> as an MTA just because of all this, which is a shame.  it would be
> nice if a fix is possible.  *nudge nudge Mr. Morton* :)

Perhaps I didn't understand the requirement.

I believe that `dirsync' would provide synchronous metadata
operations (ie: the metadata is crashproofed on-disk when
the syscall returns), but non-sync data.  Correct?

Whereas `mount -o sync' or `chattr +S' would provide synchronous
metadata operations PLUS synchronous data, so when write()
returns, the data which was written is crashproofed.

Is that your understanding of the difference?

If so, then with `dirsync', the application would have to
open the file O_SYNC (which would make the whole thing pointless!)
or it would run fsync() when it had finished writing the file.

So what it boils down to is that dirsync will improve the
efficiency of applications which do a bunch of small writes
and then an fsync.

If, however, the application is capable of doing a nice big
write() (setvbuf!) then really, the two things will be pretty
much the same.

Wait and see how the benchmarks turn out, yes?


One problem at present is that an application could be in the
middle of a nice big write(), but another thread comes up and
does a synchronous creat().  That will force a commit right in the middle
of the write().  It would be better (I think) if the write's transaction
were allowed to run to completion and the creat() caller blocks until
the write() finishes - this way the write(), the creat() and anything
else which happened during the write() would all be written out in a
single compound transaction.

Alas, we cannot run a transaction handle for more than a single
page in write() because of locking inversion problems with i_sem
and the lock_page outside ->writepage().  i_sem is trivial to fix,
but writepage is not.  It has not really proven to be a problem
yet, but it would be nice to be able to _guarantee_ that writes
up to a particular size (100k, say) were 100% atomic.

-

Re: ext3-2.4-0.9.4

[Stephen C. Tweedie]

Hi,

On Fri, Jul 27, 2001 at 02:28:03PM +1000, Andrew Morton wrote:

> I believe that `dirsync' would provide synchronous metadata
> operations (ie: the metadata is crashproofed on-disk when
> the syscall returns), but non-sync data.  Correct?

Not quite: dirsync would provide synchronous metadata operations on
directories, but would make no guarantees about other file types.
That way we don't have the cost of doing sync updates to the inodes or
indirect blocks of regular files --- fsync() is adequate to do that on
demand.

Of course, fsync() is also sufficient to do syncing of directory
operations on demand, but it's a bit heavyweight for that purpose,
hence the request for dirsync (either as a chattr flag or as a mount
option.)

> If, however, the application is capable of doing a nice big
> write() (setvbuf!) then really, the two things will be pretty
> much the same.

Almost --- it's the same for create+write+close+fsync, but not for
rename or for unlink (in which case there's not necessarily going to
be a data fsync to force the directory operation out to disk.)

Cheers,
 Stephen

Re: ext3-2.4-0.9.4

[Lawrence Greenfield]

Hi,

I'm one of those icky application programmers attempting to make
reliable software across different versions of Unix.

We need to get data to disk portably, quickly, and reliably.

I love it when I see things like:  "No, Linus is right and the MTA
guys are just wrong."

This sort of attitude is just ridiculous.  Unix had a defined set of
semantics.  This might have been stupid semantics, but it had them.
Then journalling filesystems, softupdates, and Linux async updates
came along and destroyed those semantics, preventing those of us who
want to write reliable applications using the filesystem from doing
so.  At least Oracle doesn't change the definition of COMMIT.

When I contacted the Linux JFS team about the semantics of link(), I
was told that there is _no way_ of forcing a link() to disk.  Not an
fsync() on the file, not an fsync() on the directory, just _not
possible_.

Great.

Then we come to ext2.  "Oh, just call fsync() on the directory and
you'll be fine."  Well, wait, a second, if ext2 isn't ordering the
metadata writes, a crash at the wrong time (whether or not I've called
fsync()) may lose directory entries---even directory entries unrelated
to the files I'm doing operations on!  Greeeeat.

Thus why all reasonably paranoid MTAs and other mail programs say "use
chattr +S on ext2"---we need ordered metadata writes.

Ok, journalled filesystems are better.  At least crashes aren't going
to affect random files on disk.  But since link() and the like don't
force a commit, we need some way---some reasonably portable way---of
getting that on disk.  On softupdates, calling fsync() on a file
forces all directory entries pointing to that file to disk.  This is
pretty reasonable.  1 fsync() call.

Why do we all cringe when we're told to call fsync() on the directory?
Several reasons:
. not needed on any other variety of Unix
. two fsync() calls force two different syncronization points: the
  application is forcing ordering on the OS that may not be needed.
  (Thus performance doesn't "fly" when you need multiple fsyncs.)
. directory may have other modifications going on that we're not
  interested in

You want to help performance?  Give us an fsync() that works on
multiple file descriptors at once, or an async fsync() call.  Don't
make us fight the OS on getting data to disk.

Larry

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Fri, 27 Jul 2001, Lawrence Greenfield wrote:

> I'm one of those icky application programmers attempting to make
> reliable software across different versions of Unix.
>
> We need to get data to disk portably, quickly, and reliably.
>
> I love it when I see things like:  "No, Linus is right and the MTA
> guys are just wrong."
>
> This sort of attitude is just ridiculous.  Unix had a defined set of
> semantics.  This might have been stupid semantics, but it had them.

The stuff you people seem to insist on, however, most
definately isn't part of the defined set of semantics.

If you believe otherwise, feel free to point out the
relevant sections in POSIX / SuS / ...

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Fri, 27 Jul 2001, Rik van Riel wrote:

> The stuff you people seem to insist on, however, most
> definately isn't part of the defined set of semantics.

And even if it's "inherited wisdom", you cannot simply tell those people
"don't rely on that" if - as claimed - you can't even force a link() to
disk.

> If you believe otherwise, feel free to point out the
> relevant sections in POSIX / SuS / ...

The standard is only useful if it specifies how to get data safely on
disk - it is quite explicit for fsync(), but you evidently cannot
fsync() a link().

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Sun, 29 Jul 2001, Matthias Andree wrote:

> The standard is only useful if it specifies how to get data safely on
> disk - it is quite explicit for fsync(), but you evidently cannot
> fsync() a link().

As Linus said, fsync() on the directory.

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

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Sat, 28 Jul 2001, Rik van Riel wrote:

> > The standard is only useful if it specifies how to get data safely on
> > disk - it is quite explicit for fsync(), but you evidently cannot
> > fsync() a link().
> 
> As Linus said, fsync() on the directory.

Relying on that to work on other operating systems is no better than
demanding synchronous meta data writes: relying on undocumented
behaviour.

If we spake about Linux-specific applications, that'd be okay, but we
speak about portable applications, and the diversity is bigger than
useful. Speed is not the only problem the OS has to solve.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Mike Touloumtzis]

On Sun, Jul 29, 2001 at 02:08:12AM +0200, Matthias Andree wrote:
> On Sat, 28 Jul 2001, Rik van Riel wrote:
> 
> > As Linus said, fsync() on the directory.
> 
> Relying on that to work on other operating systems is no better than
> demanding synchronous meta data writes: relying on undocumented
> behaviour.

You are blurring the boundaries between "undocumented behavior" and
"OS-specific behavior".  fsync() on a directory to sync metadata is a
defined (according to my copy of fsync(2)), Linux-specific behavior.
It is also very reasonable IMHO and in keeping with the traditional
Unix notion of directories as lists of files.

I argue that using defined Linux behavior to implement what you want
on Linux systems _is_ better than relying on undocumented behavior,
and I think most people would agree.  If you don't do this you have
not really ported the software to Linux; you instead have some
standards compliant software that "kinda usually works on Linux".
You could argue that no one should localize their software to
different versions of Unix, but you would be by far in the minority.

http://www.google.com/search?q=autoconf

Writing portable Unix software has always meant some degree
of system-specific accomodation.  It's a bummer but it's life;
otherwise Unix wouldn't evolve.

miket

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Sat, 28 Jul 2001, Mike Touloumtzis wrote:

> You are blurring the boundaries between "undocumented behavior" and
> "OS-specific behavior".  fsync() on a directory to sync metadata is a
> defined (according to my copy of fsync(2)), Linux-specific behavior.
> It is also very reasonable IMHO and in keeping with the traditional
> Unix notion of directories as lists of files.

No-one claims that fsync() the directory is a bad interface - it's
non-portable however. Actually, chattr +S is well-documented - it just
doesn't work on ReiserFS or Minix for now, and it may be unnecessarily
slow on ext2.

As pointed out more than once, "synchronous meta data" is documented e.
g.  for FreeBSD, so in at least these two cases, the box relies on
documented behaviour.

> http://www.google.com/search?q=autoconf
> 
> Writing portable Unix software has always meant some degree
> of system-specific accomodation.  It's a bummer but it's life;
> otherwise Unix wouldn't evolve.

How can autoconf figure if you need to fsync() the directory? Apart from
that, which Unix MTA uses autoconf?

Remember, the whole discussion is about getting rid of the need for
chattr +S and offering the admin the chance to mount or flag a directory
for synchronous meta data updates.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Sun, 29 Jul 2001, Matthias Andree wrote:

> How can autoconf figure if you need to fsync() the directory? Apart
> from that, which Unix MTA uses autoconf?

Zmailer uses autoconf, Exim also has some nice
tool to make itself build for the right OS using
the right interfaces.

regards,

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

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: ext3-2.4-0.9.4

[Mike Touloumtzis]

On Sun, Jul 29, 2001 at 11:28:10AM +0200, Matthias Andree wrote:
> 
> How can autoconf figure if you need to fsync() the directory? Apart from
> that, which Unix MTA uses autoconf?

My point was not that they should be using autoconf;
I don't know if they are or not.  My point was that
they should use existing published interfaces that are
reasonable, rather than push for guarantees that impose
new requirements on filesystems.  And even without
autoconf it's not hard to figure out what system you're
running on.

    rename(tmpfile, spoolfile);
#ifdef __linux___
    fsync(tmpdir);
    fsync(spooldir);
#endif
    /* transaction is complete */

> 
> Remember, the whole discussion is about getting rid of the need for
> chattr +S and offering the admin the chance to mount or flag a directory
> for synchronous meta data updates.

Right; and I'm arguing that the way to get rid of the need
for chattr +S is to incorporate directory fsync() in the
MTAs, not to cram more features into the filesystems.

Problem: MTA needs to know when rename() has been forced
to disk.

Solution 1: MTA authors use fsync(dirfd) on Linux.

Analysis: This is not the most portable solution, but it
should work on any FS that supports Linux semantics.  You
can't expect such semantics on FAT and other filesystems
that are just supported for compatibility reasons.  But you
could, say, switch filesystems for performance reasons, and
not have your MTA start mysteriously failing, because you
are using the official, documented API to do what you want
to do (at the very least you would be in a much stronger
position when pushing a bug fix :-).

Solution 2: Linux semantics are changed so that rename()
returns only when the data hits the disk.  All filesystems
are expected to implement this change.

Analysis: This sucks.  It precludes some filesystem design
choices, prevents users from making a speed/reliability
tradeoff, and makes each filesystem more complex.

Solution 3: Some filesystems implement synchronous
directory updates for renames, using filesystem-specific
feature flags, chattr, etc.

Analysis: I wouldn't want to try to dictate anything to
the FS authors, but this solution seems inferior to me.
Each filesystem would have to implement such a flag to
become "MTA compatible".  Why add a complex feature to the
filesystem when it can already be accessed via a userspace
API?  It will be more complex for administrators too --
they will have to know which filesystems implement the
synchronous directory metadata.

There are lots of filesystems out there.  Why not use
an interface they should all support rather than ask for
per-filesystem, filesystem-specific improvements?

miket

Re: ext3-2.4-0.9.4

[Ketil Froyn]

On Sun, 29 Jul 2001, Matthias Andree wrote:

> On Sat, 28 Jul 2001, Mike Touloumtzis wrote:
>
> > You are blurring the boundaries between "undocumented behavior" and
> > "OS-specific behavior".  fsync() on a directory to sync metadata is a
> > defined (according to my copy of fsync(2)), Linux-specific behavior.
> > It is also very reasonable IMHO and in keeping with the traditional
> > Unix notion of directories as lists of files.

> > http://www.google.com/search?q=autoconf
> >
> > Writing portable Unix software has always meant some degree
> > of system-specific accomodation.  It's a bummer but it's life;
> > otherwise Unix wouldn't evolve.
>
> How can autoconf figure if you need to fsync() the directory?

Simple! Grep the fsync(2) manpage ;)

Ketil the joker

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Sun, 29 Jul 2001, Matthias Andree wrote:
> On Sat, 28 Jul 2001, Rik van Riel wrote:
>
> > > The standard is only useful if it specifies how to get data safely on
> > > disk - it is quite explicit for fsync(), but you evidently cannot
> > > fsync() a link().
> >
> > As Linus said, fsync() on the directory.
>
> Relying on that to work on other operating systems is no better than
> demanding synchronous meta data writes: relying on undocumented
> behaviour.
>
> If we spake about Linux-specific applications, that'd be okay, but we
> speak about portable applications, and the diversity is bigger than
> useful. Speed is not the only problem the OS has to solve.

I guess many MTAs have a small libc inside of them exactly
in order to handle things like this without fouling up the
core code too much.

Time to make your favorite MTA use link_slowly()  ;)

cheers,

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

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: ext3-2.4-0.9.4

[Bill Rugolsky Jr.]

On Fri, Jul 27, 2001 at 12:24:56PM -0400, Lawrence Greenfield wrote:
> I love it when I see things like:  "No, Linus is right and the MTA
> guys are just wrong."
> 
> This sort of attitude is just ridiculous.  Unix had a defined set of
> semantics.  This might have been stupid semantics, but it had them.
> Then journalling filesystems, softupdates, and Linux async updates
> came along and destroyed those semantics, preventing those of us who
> want to write reliable applications using the filesystem from doing
> so.  At least Oracle doesn't change the definition of COMMIT.

First off, would you care to quote chapter and verse of these
"defined semantics" ?   Do you mean the BSD source?

Traditional FFS/UFS achieves "safety" at a terrible cost to
performance.  I can barely stand the wait to untar XFree86 on Solaris8
on a PII-333, even with UFS logging -- I'd rather use my Pentium 166
laptop running Linux!  ext2 solved this performance issue many years
ago by recognizing that the FFS metadata scheme was not really safe
either; instead the intelligence was put into e2fsck, and where
necessary, the applications.  (Do I hear faint echoes of the
"lint" v. "cc" design criterion ... ?)

The infrastructure is now in place to solve these problems in ext3,
without imposing a least-common-denominator approach that degrades
overall system performance.  In these instances "Linus is right" when
he notes that (1) the proposed immediate solution does not really solve
the problem, and (2) once in there, developers will rely on its precise
semantics, making them difficult to get right later on, and providing
no incentive to do so.  In many such instances "undefined" behavior is
the best intermediate solution.

As one can see from the "gkernel-commit" traffic, Andrew Morton has
not only taken away useful information from this thread, he's already
halfway to a solution, in just a day, because  Matthias Andree took
the time to describe the functional requirements instead of just
whining that "it's not like BSD."
 
> Thus why all reasonably paranoid MTAs and other mail programs say "use
> chattr +S on ext2"---we need ordered metadata writes.

And that's precisely the type of thing we want -- unused features should
not impact the rest of the system.
 
Regards,

   Bill Rugolsky

Re: ext3-2.4-0.9.4

[Larry McVoy]

Arrg, I take it all back, I'm taking about Daniel Phillips not Daniel
Bernstein.  I tend to agree with Alan about Mr Bernstein.

Thanks to Richard Gooch for pointing out that I'm asleep at the switch.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Thursday 26 July 2001 18:54, Larry McVoy wrote:
> On Thu, Jul 26, 2001 at 04:18:59PM +0000, Linus Torvalds wrote:
> > In article <E15PnTJ-0003z0-00@the-village.bc.nu>,
> >
> > Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
> > >> Go tell your opinion to those people that refuse to wrap their
> > >> rename/link calls with open()/fsync() calls to the respective
> > >> parents, particularly Daniel J. Bernstein, Wietse Z. Venema,
> > >> among others. I don't possibly know all MTAs.
> > >
> > >I've pointed things out to Mr Bernstein before. His normal replies
> > > are not helpful and generally vary between random ravings and
> > > threatening to sue people who publish things on web pages he
> > > disagrees with.
> >
> > Now, now, Alan. He has strong opinions, I'll agree, but I've never
> > see him threaten to _sue_.
>
> In the for what it is worth department, I spent the day with Daniel
> after the kernel summit meeting a while back, we talked file systems
> for about 6 or 7 hours.  While I'll plead guilty to getting mad at
> him (his ego is up there with mine :-), I came away impressed with
> his knowledge. I get the feeling that he thinks deeply about the
> problems he works on, he's probably right a lot of the time, *and* as
> with many deep thinkers, he has a problem communicating his ideas.
>
> This is a common problem, and I'm not sure Daniel is fully aware of
> it. One cannot expect other people to have done the same thinking and
> have the same context, and when they do not, it is easy to get
> frustrated. I think that some of Daniel's "ravings" are probably just
> frustration that the other person "doesn't get it".
>
> That doesn't mean that Daniel is the right hand of God or anything,
> I've seen him do some stupid things but I've seen all of us do some
> stupid things, so that doesn't mean much.  I think Daniel does way
> more smart things than stupid things, and not all of us can claim
> that (sort of like half of the drivers are below average, noone likes
> that idea either).
>
> What I'm trying to say is that I think Daniel is one of the good
> guys, even though his user interface could stand improvement (a
> common thing amongst smart people) and it looks like it would be
> smart to figure out how to work with him.
>
> Just my opinion...

Heh, very interesting, but you seem to have created a collage of two
different Daniels ;-)

--
Daniel

Re: ext3-2.4-0.9.4

[Richard A Nelson]

On Thu, 26 Jul 2001, Linus Torvalds wrote:

> In article <E15PnTJ-0003z0-00@the-village.bc.nu>,
> Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
> >> Go tell your opinion to those people that refuse to wrap their
> >> rename/link calls with open()/fsync() calls to the respective parents,
> >> particularly Daniel J. Bernstein, Wietse Z. Venema, among others. I
> >> don't possibly know all MTAs.

[snip]
> Also, I think he eventually agreed on the logic of fsync() on the
> directory, and we even had a bug report (quickly fixed) for reiserfs
> because it got confused by it.

In looking at the synchronous directory options, I'm unsure as to
the 'real' status wrt fsync() on a directory:
	1) Does fsync() of a directory work on most/all current FS?
	2) Does it work on 2.2.x as well as 2.4.x?
-- 
Rick Nelson
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
	-- found in the .sig of Rob Riggs, rriggs@tesser.com

Re: ext3-2.4-0.9.4

[Linus Torvalds]

On Thu, 26 Jul 2001, Richard A Nelson wrote:
>
> In looking at the synchronous directory options, I'm unsure as to
> the 'real' status wrt fsync() on a directory:
> 	1) Does fsync() of a directory work on most/all current FS?

Modulo bugs, yes.

Now, there's another issue, of course: if you have an important mail-spool
on some of the less tested filesystems, I would consider you crazy
regardless of fsync() working ;). I don't think anybody has ever verified
that fsync() (or much anything else wrt writing) does the right thing on
NTFS, for example.

> 	2) Does it work on 2.2.x as well as 2.4.x?

Yes. However, there may be performance issues. As with just about
anything, we didn't start optimizing things until it became a real issue,
and in some cases at least historically the filesystems fell back on just
doing a whole "fsync_dev()" if they had nothing better to do.

I think later 2.2.x kernels (ie the ones past the point where Alan took
over) probably have the fsync() optimizations at least for ext2.

		Linus

Re: ext3-2.4-0.9.4

[Richard A Nelson]

On Thu, 26 Jul 2001, Linus Torvalds wrote:

> > 	1) Does fsync() of a directory work on most/all current FS?
>
> Modulo bugs, yes.

Great, that was a big concern

> Now, there's another issue, of course: if you have an important mail-spool
> on some of the less tested filesystems, I would consider you crazy
> regardless of fsync() working ;). I don't think anybody has ever verified
> that fsync() (or much anything else wrt writing) does the right thing on
> NTFS, for example.

Caveat Emptor ;-)

> > 	2) Does it work on 2.2.x as well as 2.4.x?
>
> Yes. However, there may be performance issues. As with just about
> anything, we didn't start optimizing things until it became a real issue,
> and in some cases at least historically the filesystems fell back on just
> doing a whole "fsync_dev()" if they had nothing better to do.
>
> I think later 2.2.x kernels (ie the ones past the point where Alan took
> over) probably have the fsync() optimizations at least for ext2.

That should be recent enough - I push 2.2.19 for shm support and security
reasons anyway - though I see alot of folk on 2.2.16/17.

Are the optimizations more than writing out only changed blocks?
Has anyone any information on the performance differences between
optimized vs non-optimized?

Thanks, I'm feeling much better about getting this support added
-- 
Rick Nelson
Life'll kill ya                         -- Warren Zevon
Then you'll be dead                     -- Life'll kill ya

Re: ext3-2.4-0.9.4

[Anton Altaparmakov]

At 20:37 26/07/2001, Linus Torvalds wrote:
>On Thu, 26 Jul 2001, Richard A Nelson wrote:
> > In looking at the synchronous directory options, I'm unsure as to
> > the 'real' status wrt fsync() on a directory:
> >       1) Does fsync() of a directory work on most/all current FS?
>
>Modulo bugs, yes.
>
>Now, there's another issue, of course: if you have an important mail-spool
>on some of the less tested filesystems, I would consider you crazy
>regardless of fsync() working ;). I don't think anybody has ever verified
>that fsync() (or much anything else wrt writing) does the right thing on
>NTFS, for example.

NTFS doesn't even have an fsync() operation defined so calling fsync() 
system call won't do anything at all. A quick look at 
fs/buffer.c::sys_fsync() shows it will return -EINVAL straight away.

But considering the fsync, even if present may well trash the file or the 
whole partition's data, it's just as well it doesn't happen...

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Thu, 26 Jul 2001, Matthias Andree wrote:
> Christoph Hellwig schrieb am Donnerstag, den 26. Juli 2001:
>
> > So they rely on undocumented and non standadisized semantics of some
> > implementations.  I'd call this buggy.
>
> If each in the set of "supported systems" document this
> behaviour for themselves, there is no bug.

The MTA depends on behaviour which is undefined. Now you
want to go blame the OS ?

> Go tell your opinion to those people that refuse to wrap their
> rename/link calls with open()/fsync() calls to the respective parents,
> particularly Daniel J. Bernstein, Wietse Z. Venema, among others. I
> don't possibly know all MTAs.

If you care about your email, probably you should either
teach these people about standards like POSIX or SuS
(and tell them to not rely on undefined behaviour) or
switch to an MTA which isn't broken in various ways ;)

cheers,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Alan Cox]

> If you care about your email, probably you should either
> teach these people about standards like POSIX or SuS
> (and tell them to not rely on undefined behaviour) or
> switch to an MTA which isn't broken in various ways ;)

POSIX and SuS are actually not helpful here. They don't cover how to force
namespace to disk, only data and metadata for the file. So you can portably
stick your data onto disk, portably be sure its on disk, but not portably be
sure the directory entries are on disk.

Alan

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Thu, 26 Jul 2001, Rik van Riel wrote:

> The MTA depends on behaviour which is undefined. Now you
> want to go blame the OS ?

No, the behaviour is defined on certain systems. Not sure if that
comprises all supported systems.

I'm not blaming anybody besides Linux which does not offer the "noasync"
(FreeBSD) compromise between sync and async. I don't see any reason why
this option cannot be there. Is it too expensive too implement? No-one
said so.

I cannot tell if and how the MTA authors checked all their supported OSs
how they handle metadata updates.

> If you care about your email, probably you should either
> teach these people about standards like POSIX or SuS
> (and tell them to not rely on undefined behaviour) or
> switch to an MTA which isn't broken in various ways ;)

Wee. And then, I tell the system to comply with that as well, don't I?
;)

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Alan Cox]

> them, and MTAs are portable, they choose chattr +S on Linux. And that's
> a performance problem because it doesn't come for free, but also with
> synchronous data updates, which are unnecessary because there is
> fsync().

chattr +S and atomic updates hitting disk then returning to the app will
give the same performance. You can also fsync() the directory. 

> the "my rename call has returned 0" event. They expect that with the
> call returning the rename operation has completed ultimately, finally,
> for good, definitely and the old file will not reappear after a crash.

Actually the old file re-appearing after the crash is irrelevant. It will
have a previously logged message id. And if you are not doing message id
histories then you have replay races at the SMTP level anyway

> This still implies the drive doesn't lie to the OS about the completion
> of write requests: write cache == off.

Write cache off is not a feature available on many modern disks. You
already lost the battle before you started.

Alan

Re: ext3-2.4-0.9.4

[Gérard Roudier]

On Thu, 26 Jul 2001, Alan Cox wrote:

> > them, and MTAs are portable, they choose chattr +S on Linux. And that's
> > a performance problem because it doesn't come for free, but also with
> > synchronous data updates, which are unnecessary because there is
> > fsync().
>
> chattr +S and atomic updates hitting disk then returning to the app will
> give the same performance. You can also fsync() the directory.
>
> > the "my rename call has returned 0" event. They expect that with the
> > call returning the rename operation has completed ultimately, finally,
> > for good, definitely and the old file will not reappear after a crash.
>
> Actually the old file re-appearing after the crash is irrelevant. It will
> have a previously logged message id. And if you are not doing message id
> histories then you have replay races at the SMTP level anyway
>
> > This still implies the drive doesn't lie to the OS about the completion
> > of write requests: write cache == off.
>
> Write cache off is not a feature available on many modern disks. You
> already lost the battle before you started.

Losing the battle of brain-dead hardware is not a problem... :-)

SCSI hard disks are expected to follow the specifications. But, may be,
you are referring to IDE disks, only ...

With SCSI, you can enable write caching and also ask the device to signal
completion of actual write to the media by setting the FUA bit in the SCSI
command block (not available in WRITE(6), but available in WRITE(10)).

  Gérard.

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Thu, 26 Jul 2001, Alan Cox wrote:

> Rik is right. It isnt just about premature notification - its about 
> atomicity. At the point you are notified the data has been queued for disk
> I/O. Even on traditional BSD ufs with synchronous metadata you still had
> points where a crash left the rename partially complete and nothing but a
> log or an atomic update system is going to fix that.

No. Atomic update systems and logs can by no means fix premature
acknowledgements:

Proof:

Assume the OS has a phase tree kind of thing or log that requires
just a single-block write for an atomic rename.

Assume an MTA calls rename(), and the OS by whatever means notifies it of
completion, but actually, the data is only queued, not written.

Assume The MTA receives the acknowledgement (e. g. rename call
returned), sends a "250 mail action complete" packet across the network.

Assume the machine sends the network packed, but not the queued disk
block and then crashes.

--> The single block is lost, the rename operation is lost, but the
operation had been acknowledged. Consequence: the mail is lost. q. e. d.

All this boils down to: 

1. The OS _MUST_ know when a write operation has been physically
committed to non-volatile storage.

2. The OS _MUST_ _NOT_ acknowledge the (assumedly synchronous operation)
any earlier. (This may well include switching off drive write
buffering.)

If the OS cannot fulfill these two basic requirements, I can save all
the log or FS atomicity efforts because they don't get me anywhere.

The problem is not that the operation can fail, the problem IS premature
acknowledgement. Even with atomic updates, as shown above.

Note, of course there is no premature acknowledgement for the
Linux-default asynchronous directory update. There IS for -o sync or
chattr +S -- and that's what MTAs to to guarantee data integrity, and
that's why I'm still suggesting dirsync or something to remedy the
negative data write performance of full-sync.

If the OS tell me "write completed" when it means "I queued your data
for writing", it is BROKEN.

That's my point.

And since the common POSIX OS lacks a dedicated notification feature for
e. g. rename, MTAs have no other choice than to rely on "has completed
when the syscall returns".

BTW, my Linux rename(2) man page doesn't document EIO condition, FreeBSD
4.3-STABLE and SUS v2 do.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Thursday 26 July 2001 16:32, Matthias Andree wrote:
> On Thu, 26 Jul 2001, Alan Cox wrote:
> > Rik is right. It isnt just about premature notification - its about
> > atomicity. At the point you are notified the data has been queued
> > for disk I/O. Even on traditional BSD ufs with synchronous metadata
> > you still had points where a crash left the rename partially
> > complete and nothing but a log or an atomic update system is going
> > to fix that.
>
> No. Atomic update systems and logs can by no means fix premature
> acknowledgements:
>
> Proof:
>
> Assume the OS has a phase tree kind of thing or log that requires
> just a single-block write for an atomic rename.
>
> Assume an MTA calls rename(), and the OS by whatever means notifies
> it of completion, but actually, the data is only queued, not written.
>
> Assume The MTA receives the acknowledgement (e. g. rename call
> returned), sends a "250 mail action complete" packet across the
> network.
>
> Assume the machine sends the network packed, but not the queued disk
> block and then crashes.
>
> --> The single block is lost, the rename operation is lost, but the
> operation had been acknowledged. Consequence: the mail is lost. q. e.
> d.
>
> All this boils down to:
>
> 1. The OS _MUST_ know when a write operation has been physically
> committed to non-volatile storage.

We're working on that, see the "[PATCH] 64 bit scsi read/write" thread 
on linux-fsdevel.  About half of it is devoted to investigating the 
detailed semantics of physical write completion.

> 2. The OS _MUST_ _NOT_ acknowledge the (assumedly synchronous
> operation) any earlier. (This may well include switching off drive
> write buffering.)

Yes, for now that's how you have to do it.

> If the OS cannot fulfill these two basic requirements, I can save all
> the log or FS atomicity efforts because they don't get me anywhere.
>
> The problem is not that the operation can fail, the problem IS
> premature acknowledgement. Even with atomic updates, as shown above.

Right now the interface for determining that the operation has actually 
completed is "sync".  Yes, that sucks but with journalling or atomic 
commit it's not nearly as expensive as you might think.  My early flush 
patch does nearly the equivalent of sync, 10 times a second and it 
actually improves performance (it does not attempt to do this under 
high load of course).

We *should* have something like sys_sync_dev(majorminor) or 
sys_sync_fs(mountpoint) (whatever that would look like).  For 
phase-tree the semantics are that the call doesn't return until the 
metaroot of the then-current "branching" tree is known to be safely on 
disk.  (Side note: it's ok to allow subsequent updates on the same 
filesystem to procede while an outstanding sync_dev is waiting for 
confirmation from the block layer, because these don't affect the 
filesystem state the sync_fs is waiting on.)

As I understand it, Ext2 allows much the same semantics.  While we do 
need to do something about exposing a more elegant interface, with Ext3 
you should be ok with +S and a "sync" just before you report to the 
world that the mail transaction is complete.  Ext3 does *not* leave a 
lot of dirty blocks hanging around in normal operation, so sync is not 
nearly as slow as it is with good old Ext2.

> Note, of course there is no premature acknowledgement for the
> Linux-default asynchronous directory update. There IS for -o sync or
> chattr +S -- and that's what MTAs to to guarantee data integrity, and
> that's why I'm still suggesting dirsync or something to remedy the
> negative data write performance of full-sync.
>
> If the OS tell me "write completed" when it means "I queued your data
> for writing", it is BROKEN.
>
> That's my point.
>
> And since the common POSIX OS lacks a dedicated notification feature
> for e. g. rename, MTAs have no other choice than to rely on "has
> completed when the syscall returns".
>
> BTW, my Linux rename(2) man page doesn't document EIO condition,
> FreeBSD 4.3-STABLE and SUS v2 do.

Sounds like a man page bug.

--
Daniel

Re: ext3-2.4-0.9.4

[Andrew Morton]

Daniel Phillips wrote:
> 
> Ext3 does *not* leave a
> lot of dirty blocks hanging around in normal operation, so sync is not
> nearly as slow as it is with good old Ext2.

eek.

In fully-journalled data mode, we write everything to the journal
in a linear chunk, wait on it, write a commit block, wait on that
and then release all the just-journalled data into the main
filesystem for conventional bdflush/kupdate writeback in twenty
seconds time.

Calling anything which uses fsync_dev() would cause all that writeback
data to be written out and waited on, with the consequential seeking
storm.  Disastrous.

Note that fsync() is OK - in full data journalling mode nothing
is ever attached to i_dirty_buffers.

-

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Thursday 26 July 2001 17:49, Andrew Morton wrote:
> Daniel Phillips wrote:
> > Ext3 does *not* leave a
> > lot of dirty blocks hanging around in normal operation, so sync is
> > not nearly as slow as it is with good old Ext2.
>
> eek.
>
> In fully-journalled data mode, we write everything to the journal
> in a linear chunk, wait on it, write a commit block, wait on that
> and then release all the just-journalled data into the main
> filesystem for conventional bdflush/kupdate writeback in twenty
> seconds time.
>
> Calling anything which uses fsync_dev() would cause all that
> writeback data to be written out and waited on, with the
> consequential seeking storm.  Disastrous.

Whoops, ok, no, this is not particularly sync-friendly.  On the other
hand, I don't think your seek storm would be as bad as all that.  You
can still feed enough blocks to the elevator to give it something to
chew on.  On the third hand, since you are still using the generic
flushing machinery I can see you'd have quite a lot of work to do to
control the flushing accurately in this way.

> Note that fsync() is OK - in full data journalling mode nothing
> is ever attached to i_dirty_buffers.

Somewhere in there is a beautiful optimization trying to get out...

--
Daniel

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Thu, 26 Jul 2001, Daniel Phillips wrote:

> As I understand it, Ext2 allows much the same semantics.  While we do 
> need to do something about exposing a more elegant interface, with Ext3 
> you should be ok with +S and a "sync" just before you report to the 
> world that the mail transaction is complete.  Ext3 does *not* leave a 
> lot of dirty blocks hanging around in normal operation, so sync is not 
> nearly as slow as it is with good old Ext2.

That wasn't my impression, particularly not with data=journalling which
can drop data into the log. It's just: why sync the world if synching
directories does the job and relevant data is synched manually with
fsync()?

However, how big are chances that these interfaces will spread outside
of Linux? That's the crucial point for portable applications. If it's a
kernel <-> libc interface, OK, no problem, but if it's a user-space
interface, it might easily become a useless invention because no-one
uses it in real life. You don't support multiple interfaces in a
portable application because that's a maintenance disaster and often
causes reliability problems because on different platforms, code takes
different paths, so applications won't usually choose limited-use
interfaces (such as sendfile).

BTW, your Message-ID is unqualified == on a collision course in mail
duplicate killers.

Re: ext3-2.4-0.9.4

[Andrew Morton]

Matthias Andree wrote:
>  
> A much better file system for an MTA might be ext3fs with
> data=journalled and dirsync mount/chattr option.

OK, I've taken a closer look at this.  ext3 has picked up some
cruft from ext2's sync handling which it does not need in the
least.

It will be fairly straightforward and a useful cleanup to
provide the following semantics for either synchronous
mounts or `chattr +S' directories:

* All metadata operations (rename, unlink, link, symlink, etc)
  will be synchronous.  So when the system call returns, the data
  is crash-proofed.

* All write()s will be synchronous.  So when the write() system
  call returns, the data written and all associated metadata
  will be crash-proofed.

  O_SYNC and fsync() will not be necessary - in fact they'll
  slow things down slightly by forcing an unnecessary and
  probably empty commit.

If you crash in the middle of a write, you may end up with a truncated
file on recovery.

This is in fact the behaviour right now, but the performance is
not good.

The performance problem at present is that large write()s have unnecessary
commits in the middle of them.  This is due to the abovementioned
cruft in ext3_get_block() and the things it calls.

> Would you deem it
> possible to get such an option done before ext3fs 1.0.0?

We'd prefer not - we're trying to stabilise things quite
sternly at present. However that doesn't prevent work
on 1.1.0 :)

Seems like a worthwhile thing to do - I'll cut a branch
and do this.  It'll take a couple of weeks - as usual, most
of the work is in development and use of test tools...
But I can't predict at this time when we'll merge it into
the mainline fs.

> I hope this makes the requirements of this particular group of
> applications clear.

Yes, it was useful - thanks.

-

RFC: chattr/lsattr +DS? was: ext3-2.4-0.9.4

[Matthias Andree]

On Fri, 27 Jul 2001, Andrew Morton wrote:

> > Would you deem it
> > possible to get such an option done before ext3fs 1.0.0?
> 
> We'd prefer not - we're trying to stabilise things quite
> sternly at present. However that doesn't prevent work
> on 1.1.0 :)
> 
> Seems like a worthwhile thing to do - I'll cut a branch
> and do this.  It'll take a couple of weeks - as usual, most
> of the work is in development and use of test tools...
> But I can't predict at this time when we'll merge it into
> the mainline fs.

So the summary of all this is, as I understand it: for ext3fs 1.0, treat
it with chattr +S and the like as if it was ext2fs, it may or may not be
faster with "mount -o data=journalled" and is well worthwhile for an MTA
to try, a weaker sync option may be introduced after ext3fs 1.0.

Sounds good.

I'm dropping the ext3-users mailing list for now since this is getting
more general.


However, since the ReiserFS team also showed interest in a similar
functionality, and they don't yet support chattr, would it be useful to
specify a "D" option for chattr already?

I have a suggestion: if D is set, but S isn't, no effect. If S is set,
but D is unset, treat S as in the past. If S is set, and D is set,
directory updates are synchronous like with S, but data updates are
asynchronous in spite of S.

This way, booting a kernel without chattr "D" flag support or mounting
the file system as ext2 would have it default to the safer
everything-synchronously mode.

-- 
Matthias Andree

Re: RFC: chattr/lsattr +DS? was: ext3-2.4-0.9.4

[Andrew Morton]

Matthias Andree wrote:
> 
> On Fri, 27 Jul 2001, Andrew Morton wrote:
> 
> > > Would you deem it
> > > possible to get such an option done before ext3fs 1.0.0?
> >
> > We'd prefer not - we're trying to stabilise things quite
> > sternly at present. However that doesn't prevent work
> > on 1.1.0 :)
> >
> > Seems like a worthwhile thing to do - I'll cut a branch
> > and do this.  It'll take a couple of weeks - as usual, most
> > of the work is in development and use of test tools...
> > But I can't predict at this time when we'll merge it into
> > the mainline fs.
> 
> So the summary of all this is, as I understand it: for ext3fs 1.0, treat
> it with chattr +S and the like as if it was ext2fs, it may or may not be
> faster with "mount -o data=journalled" and is well worthwhile for an MTA
> to try, a weaker sync option may be introduced after ext3fs 1.0.
> 
> Sounds good.
> 
> I'm dropping the ext3-users mailing list for now since this is getting
> more general.
> 
> However, since the ReiserFS team also showed interest in a similar
> functionality, and they don't yet support chattr, would it be useful to
> specify a "D" option for chattr already?

chattr is an ext[23]-specific thing.  reiserfs could certainly
support a similar thing if they have a few bits spare in the
inode.

> I have a suggestion: if D is set, but S isn't, no effect. If S is set,
> but D is unset, treat S as in the past. If S is set, and D is set,
> directory updates are synchronous like with S, but data updates are
> asynchronous in spite of S.

I don't think this would be needed until really proven necessary - for
data, fsync() should work for all filesystems.

There would be one benefit in splitting sync from datasync,
and that is for applications which do not write() their
data in large enough chunks.

When I fix the get_block thing, O_SYNC, `chattr +S' and `mount
-o sync' will provide good, fast synchronous write()s - the
fs will run a commit at the end of the write().  That's just fine as long
as the app is writing its data in goodly chunks.  If it is is using 4k
or 8k chunks (eg: default stdio) then throughput will suffer.  That
would be rather silly of it though.

-

Re: ext3-2.4-0.9.4

[Linus Torvalds]

In article <20010726143002.E17244@emma1.emma.line.org>,
Matthias Andree  <matthias.andree@stud.uni-dortmund.de> wrote:
>
>However, the remaining problem is being synchronous with respect to open
>(fixed for ext3 with your fsync() as I understand it), rename, link and
>unlink. With ext2, and as you write it, with ext3 as well, there is
>currently no way to tell when the link/rename has been committed to
>disk, unless you set mount -o sync or chattr +S or call sync() (the
>former is not an option because it's far too expensive).

Congratulations. You have been brainwashed by Dan Bernstein.

Use fsync() on the directory. 

Logical, isn't it?

		Linus

Re: ext3-2.4-0.9.4

[Matti Aarnio]

On Thu, Jul 26, 2001 at 03:51:35PM +0000, Linus Torvalds wrote:
> To:	linux-kernel@vger.kernel.org
> From:	torvalds@transmeta.com (Linus Torvalds)
> Subject: Re: ext3-2.4-0.9.4
> Date:	Thu, 26 Jul 2001 15:51:35 +0000 (UTC)
....
> Use fsync() on the directory. 
> 
> Logical, isn't it?

  No.  I don't see why I should opendir() a directory, fsync()
that handle, and closedir() the handle.  I would definitely prefer:

       lsync(dirpath)

This could, even, behave like  lstat()  with the path: if the last name
segment is symlink, the sync is done on the i-node data of symlink, not
on what it (possibly) points to.

I didn't check if POSIX folks have thought of that.

> 		Linus

/Matti Aarnio

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Tue, 31 Jul 2001, Matti Aarnio wrote:
> On Thu, Jul 26, 2001 at 03:51:35PM +0000, Linus Torvalds wrote:

> > Use fsync() on the directory.
> >
> > Logical, isn't it?
>
>   No.  I don't see why I should opendir() a directory, fsync()
> that handle, and closedir() the handle.

And it wouldn't even be enough.  Who guarantees you that
the parent directory of this directory has been written
to disk and we won't lose the entry pointing to this
directory on a crash ?

> I would definitely prefer:
>
>        lsync(dirpath)

Nice idea.  Of course, fsync(file) also has the obligation
to make sure all the metadata of the file is written to
disk. Lots of people seem to be convinced this also includes
the metadata needed to _reach_ the file all the way from the
root of the filesystem...

> I didn't check if POSIX folks have thought of that.

Nice addition.  Easier to use than fsync() - no need to
open the file - and probably easier to implement in the
kernel because this way we'll be handing the whole path
to the kernel, whereas fsync() would have the dubious
task of finding out how this file can be traced all the
way down from the root of the filesystem.

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Lawrence Greenfield]

   Date: 	Mon, 30 Jul 2001 22:23:29 -0300 (BRST)
   From: Rik van Riel <riel@conectiva.com.br>
[...]
   > I would definitely prefer:
   >
   >        lsync(dirpath)
[...]
   Nice addition.  Easier to use than fsync() - no need to
   open the file - and probably easier to implement in the
   kernel because this way we'll be handing the whole path
   to the kernel, whereas fsync() would have the dubious
   task of finding out how this file can be traced all the
   way down from the root of the filesystem.

It's not as good as fsync() just doing what it's suppose to do.
You'll force applications that want to issue multiple link()s to issue
multiple lsync()s, forcing the kernel to serialize all of the disk
writes when the application just wants one file (and all of it's
associated filenames) to disk.

Yes, I understand that implementing fsync() so that it syncs all names
to reach the file is difficult.  But if you want the best performance,
you don't want to make applications issue multiple calls each of which
force their own synchronous writes.

Not to mention us whiny application writers won't be happy throwing
lsync()s all over the place.

Larry

Re: ext3-2.4-0.9.4

[Matti Aarnio]

  The thing about filesystems, and how dimmly MTAs (should) consider
  some performance tweaks is something I have tried to describe at
  ZMailer's manual in part about its the queue:

      http://www.zmailer.org/zman/zadm-queues.html

On Tue, Jul 31, 2001 at 01:25:06AM -0400, Lawrence Greenfield wrote:
...
> It's not as good as fsync() just doing what it's suppose to do.
> You'll force applications that want to issue multiple link()s to issue
> multiple lsync()s, forcing the kernel to serialize all of the disk
> writes when the application just wants one file (and all of it's
> associated filenames) to disk.
> 
> Yes, I understand that implementing fsync() so that it syncs all names
> to reach the file is difficult.  But if you want the best performance,
> you don't want to make applications issue multiple calls each of which
> force their own synchronous writes.
> 
> Not to mention us whiny application writers won't be happy throwing
> lsync()s all over the place.
> 
> Larry

   I quite agree.

   Filesystems are not, unfortunately, rollbackfull logged and committable
   databases, even if we like to use them often in that way.

   An MTA with a fundamental design point of not using any privileged
   programs (no suid anything!) and least esoteric technology possible
   (for wide portability) can only use message submission means available
   to it everywhere -- implementing the queue inside a database system
   is definitely a possibility.   Possibly yielding higher performance
   than one using filesystem for it, but at what cost ??
   (I am thinking of SleepyCat DB multiaccess transaction supported
    version.)

/Matti Aarnio

Re: ext3-2.4-0.9.4

[Anton Altaparmakov]

On Tue, 31 Jul 2001, Matti Aarnio wrote:

>   The thing about filesystems, and how dimmly MTAs (should) consider
>   some performance tweaks is something I have tried to describe at
>   ZMailer's manual in part about its the queue:
> 
>       http://www.zmailer.org/zman/zadm-queues.html
> 
> On Tue, Jul 31, 2001 at 01:25:06AM -0400, Lawrence Greenfield wrote:
> ...
> > It's not as good as fsync() just doing what it's suppose to do.
> > You'll force applications that want to issue multiple link()s to issue
> > multiple lsync()s, forcing the kernel to serialize all of the disk
> > writes when the application just wants one file (and all of it's
> > associated filenames) to disk.
> > 
> > Yes, I understand that implementing fsync() so that it syncs all names
> > to reach the file is difficult.  But if you want the best performance,
> > you don't want to make applications issue multiple calls each of which
> > force their own synchronous writes.
> > 
> > Not to mention us whiny application writers won't be happy throwing
> > lsync()s all over the place.
> > 
> > Larry
> 
>    I quite agree.
> 
>    Filesystems are not, unfortunately, rollbackfull logged and committable
>    databases, even if we like to use them often in that way.

Well it depends on which file system you are talking about. NTFS is for
all intents and purposes a rollbackfull logged and committable
(relational) database and a file system at the same time. It's a shame M$
don't release the specs for it, otherwise it would be just what you are
looking for. - It will take us forever to reverse engineer the
journalling part of NTFS. You can see how long it is taking us just to
get the actual file system part.. and journalling on top of that is going
to be even worse. (Of course once we have the file system part there is
nothing to stop us doing our own thing with respect to journalling but
that's a different discussion.)

Anton

> 
>    An MTA with a fundamental design point of not using any privileged
>    programs (no suid anything!) and least esoteric technology possible
>    (for wide portability) can only use message submission means available
>    to it everywhere -- implementing the queue inside a database system
>    is definitely a possibility.   Possibly yielding higher performance
>    than one using filesystem for it, but at what cost ??
>    (I am thinking of SleepyCat DB multiaccess transaction supported
>     version.)
> 
> /Matti Aarnio
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Best regards,

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

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Tue, 31 Jul 2001, Lawrence Greenfield wrote:

> Not to mention us whiny application writers won't be happy throwing
> lsync()s all over the place.

Not portable -> won't happen usually.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Mon, 30 Jul 2001, Rik van Riel wrote:

> > I didn't check if POSIX folks have thought of that.
> 
> Nice addition.  Easier to use than fsync() - no need to
> open the file - and probably easier to implement in the
> kernel because this way we'll be handing the whole path
> to the kernel, whereas fsync() would have the dubious
> task of finding out how this file can be traced all the
> way down from the root of the filesystem.

If I understand SUS v2 correctly, fsync() must sync meta data
corresponding to the file.

If Linux ext2 doesn't to that, it might be a good idea to change that so
it does.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Mike Castle]

On Tue, Jul 31, 2001 at 11:29:47PM +0200, Matthias Andree wrote:
> If I understand SUS v2 correctly, fsync() must sync meta data
> corresponding to the file.


Where can I find a common definition for "meta data."

For example, I consider meta data to be things kept in the inode only
(size, timestamps, permissions).  Indirect blocks, maybe.  But, considering
how, in the unix world, file names are NOT associated with files, I have
never considered file names to be meta data.  Instead, file names is a set
of data associated with special files known as "directories."  So, it is
obvious, to me, that expecting fsync to sync changes to directory entries
is silly.

Obviously, however, you have a different definition of what meta data is.

Does SUS2 provide a definition for meta data?

A quick glance at the webside didn't turn anything up for me, but I would
not be surprised that I may have missed it.

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: ext3-2.4-0.9.4

[Chris Wedgwood]

On Tue, Jul 31, 2001 at 11:29:47PM +0200, Matthias Andree wrote:

    If I understand SUS v2 correctly, fsync() must sync meta data
    corresponding to the file.

    If Linux ext2 doesn't to that, it might be a good idea to change
    that so it does.

Define 'meta-data' --- linux sync's any inode and/or bitmap changes,
fsyn on a file will ensure it is intact but not that it can't get
lost.



  --cw

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Wed, 1 Aug 2001, Chris Wedgwood wrote:
> On Tue, Jul 31, 2001 at 11:29:47PM +0200, Matthias Andree wrote:
>
>     If I understand SUS v2 correctly, fsync() must sync meta data
>     corresponding to the file.
>
>     If Linux ext2 doesn't to that, it might be a good idea to change
>     that so it does.
>
> Define 'meta-data' --- linux sync's any inode and/or bitmap
> changes, fsyn on a file will ensure it is intact but not that it
> can't get lost.

Syntactically correct, but quite useless IMHO ;)

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Linus Torvalds]

On Tue, 31 Jul 2001, Matti Aarnio wrote:
> >
> > Logical, isn't it?
>
>   No.  I don't see why I should opendir() a directory, fsync()
> that handle, and closedir() the handle.  I would definitely prefer:
>
>        lsync(dirpath)

Btw, you don't have to do opendir() - that just wastes time. Just do
something like

	int lsync(char *path)
	{
	        int err, fd;
	        fd = open(path, 0);
	        if (fd >= 0) {
	                err = fsync(fd);
	                close(fd);
	        }
	        return err;
	}

and you're done. But it won't do the symlink thing...

		Linus

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Thu, 26 Jul 2001, Linus Torvalds wrote:

> In article <20010726143002.E17244@emma1.emma.line.org>,
> Matthias Andree  <matthias.andree@stud.uni-dortmund.de> wrote:
> >
> >However, the remaining problem is being synchronous with respect to open
> >(fixed for ext3 with your fsync() as I understand it), rename, link and
> >unlink. With ext2, and as you write it, with ext3 as well, there is
> >currently no way to tell when the link/rename has been committed to
> >disk, unless you set mount -o sync or chattr +S or call sync() (the
> >former is not an option because it's far too expensive).
> 
> Congratulations. You have been brainwashed by Dan Bernstein.

No, I asked Wietse Venema what assumptions Postfix makes. Since he
refuses to fsync() directories, he has Postfix set chattr +S to enforce
the semantics he expects. No problem here.

> Use fsync() on the directory. 
> 
> Logical, isn't it?

Why go all the lengths to look up each single directory path component
again just to fsync() stuff that doesn't belong to you and that you
don't want synched, possibly the entire device?

Chase up to the root manually, because Linux' ext2 violates SUS v2
fsync() (which requires meta data synched BTW), as has been pointed out
(and fixed in ReiserFS and ext3)?

Admittedly, MTAs are (supposed to be) (per command of RFC-1123) more
paranoid than the average application - and per lack of standard whether
rename/link & Co. need to be synchronous or asynchronous, this is a
problem for the MTA.

So, please tell my why Single Unix Specification v2 specifies EIO for
rename. Asynchronous I/O cannot possibly trigger immediate EIO.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Tue, 31 Jul 2001, Matthias Andree wrote:
> On Thu, 26 Jul 2001, Linus Torvalds wrote:
>
> > Congratulations. You have been brainwashed by Dan Bernstein.

[snip fsync() on directory ... on second thought this isn't enough]

> Chase up to the root manually, because Linux' ext2 violates SUS
> v2 fsync() (which requires meta data synched BTW), as has been
> pointed out (and fixed in ReiserFS and ext3)?

Agreed.  fsync() on the file needs to write the meta
data, this includes the directory and (if needed)
the parent directories all the way up to the root.

> So, please tell my why Single Unix Specification v2 specifies EIO for
> rename. Asynchronous I/O cannot possibly trigger immediate EIO.

Crap. An asynchronous rename() can hit the situation
where it cannot read the disk when searching for the
directory it wants to move the file to.

rename(/from/a/b/file, /to/d/f/file) can fail when
the system gets an IO access on reading "d".

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Mike Castle]

On Tue, Jul 31, 2001 at 02:57:00AM +0200, Matthias Andree wrote:
> So, please tell my why Single Unix Specification v2 specifies EIO for
> rename. Asynchronous I/O cannot possibly trigger immediate EIO.

It also specifies EIO as possible for write().

Are you saying that, since SUS2 specifies that write() is capable of
returning EIO, and asynchronous I/O cannot possibly trigger immediate EIO, 
that all calls to write() should by synchronous?

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Mon, 30 Jul 2001, Mike Castle wrote:

> On Tue, Jul 31, 2001 at 02:57:00AM +0200, Matthias Andree wrote:
> > So, please tell my why Single Unix Specification v2 specifies EIO for
> > rename. Asynchronous I/O cannot possibly trigger immediate EIO.
> 
> It also specifies EIO as possible for write().
> 
> Are you saying that, since SUS2 specifies that write() is capable of
> returning EIO, and asynchronous I/O cannot possibly trigger immediate EIO, 
> that all calls to write() should by synchronous?

No, I'm wondering about the semantics. Of course, write() can be
synchronous (O_SYNC or fs mounted sync e. g.).

Re: ext3-2.4-0.9.4

[Stephen C. Tweedie]

Hi,

> Chase up to the root manually, because Linux' ext2 violates SUS v2
> fsync() (which requires meta data synched BTW)

Please quote chapter and verse --- my reading of SUS shows no such
requirement.  

fsync is required to force "all currently queued I/O operations
associated with the file indicated by file descriptor fildes to the
synchronised I/O completion state."  But as you should know, directory
entries and files are NOT the same thing in Unix/SUS.  

Are we expected to fsync the metadata belonging to just the file
itself?  Or all symlinks to the file?  Or all hard links?  Answer, as
best I can determine --- just the file.  That's all SUS talks about.
There can be many ways of reaching that file in the directory
hierarchy, or there can be none, but fsync() doesn't talk at all about
the status of those dirents after the sync.

> , as has been pointed out
> (and fixed in ReiserFS and ext3)?

ext3 happens to provide the guarantee, but that's coincidental and
does not imply that I think of it as being "fixed".  It's just changed
behaviour relative to ext2.

> So, please tell my why Single Unix Specification v2 specifies EIO for
> rename. Asynchronous I/O cannot possibly trigger immediate EIO.

Yes it can --- we may need to read metadata to complete the rename,
and such reads can fail.  

Cheers,
 Stephen

Re: ext3-2.4-0.9.4

[Kurt Roeckx]

On Wed, Aug 01, 2001 at 05:02:30PM +0100, Stephen C. Tweedie wrote:
> Hi,
> 
> > Chase up to the root manually, because Linux' ext2 violates SUS v2
> > fsync() (which requires meta data synched BTW)
> 
> Please quote chapter and verse --- my reading of SUS shows no such
> requirement.  
> 
> fsync is required to force "all currently queued I/O operations
> associated with the file indicated by file descriptor fildes to the
> synchronised I/O completion state."  But as you should know, directory
> entries and files are NOT the same thing in Unix/SUS.  

It goed on with "All I/O operations are completed as defined for
synchronised I/O file integrity completion.", whatever it all
means.

For fdatasync() it says:
"The fdatasync() function forces all currently queued I/O
operations associated with the file indicated by file descriptor
fildes to the synchronised I/O completion state.", which is just
the same as it says for fsync().

It also says:
"The functionality is as described for fsync() (with the symbol
_XOPEN_REALTIME defined), with the exception that all I/O
operations are completed as defined for synchronised I/O data
integrity completion."

It doesn't mention meta-data.

I have no idea what it all means.


Kurt

Re: ext3-2.4-0.9.4

[Andrew McNamara]

>Please quote chapter and verse --- my reading of SUS shows no such
>requirement.  
>
>fsync is required to force "all currently queued I/O operations
>associated with the file indicated by file descriptor fildes to the
>synchronised I/O completion state."  But as you should know, directory
>entries and files are NOT the same thing in Unix/SUS.  

But does fsync() have any meaning if it doesn't ensure the file is
visible within the filesystem? 

This all comes back to the fact that old UFS's made directory
operations syncronous, at a substantial cost in performance. Writing
the directory data wasn't necessary for them, because it was already
commited when the creat() call returned.

I can easily understand people's asthetic objection to having fsync
touch the directory object as well as the file, however what meaning
does fsync() have it it doesn't - under linux, it tells usermode "yes,
your object is committed, but it might be in lost+found next time you
want it", and with the syncronous UFS implementations, it tells
usermode "yes, your object is committed, you can find it where you left
it (unless the directory was corrupted)".

 ---
Andrew McNamara (System Architect)

connect.com.au Pty Ltd
Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia
Phone: +61 2 9409 2117, Fax: +61 2 9409 2111

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Wed, 01 Aug 2001, Stephen Tweedie wrote:

> > Chase up to the root manually, because Linux' ext2 violates SUS v2
> > fsync() (which requires meta data synched BTW)
> 
> Please quote chapter and verse --- my reading of SUS shows no such
> requirement.  
> 
> fsync is required to force "all currently queued I/O operations
> associated with the file indicated by file descriptor fildes to the
> synchronised I/O completion state."  But as you should know, directory
> entries and files are NOT the same thing in Unix/SUS.  

Read on: "All I/O operations are completed as defined for synchronised
I/O _file_ integrity completion.". To show what that means, see the
glossary.

http://www.opengroup.org/onlinepubs/007908799/xbd/glossary.html#tag_004_000_291

  "synchronised I/O data integrity completion

  [...]

  * For write, when the operation has been completed or diagnosed if
  unsuccessful.  The write is complete only when the data specified in
  the write request is successfully transferred and all file system
  information required to retrieve the data is successfully transferred.

  File attributes that are not necessary for data retrieval (access
  time, modification time, status change time) need not be successfully
  transferred prior to returning to the calling process.

  synchronised I/O file integrity completion

  Identical to a synchronised I/O data integrity completion with the
  addition that all file attributes relative to the I/O operation
  (including access time, modification time, status change time) will be
  successfully transferred prior to returning to the calling process."

As I understand it, the directory entry's st_ino is a file attribute
necessary for data retrieval and also contains the m/a/ctime, so it must
be flushed to disk on fsync() as well.

> There can be many ways of reaching that file in the directory
> hierarchy, or there can be none, but fsync() doesn't talk at all about
> the status of those dirents after the sync.

Well, if there's not a single dirent, you cannot retrieve the data, so
I'd assume at least one dirent needs to be flushed as well. If there's a
simple way to get unflushed dentries to disk (hard links included),
flush them. Not sure about symlinks, but since they don't share the
inode number, that might be rather difficult for the kernel (I didn't
check):

touch 1 ; ln 1 2 ; ln -s 1 3 ; ls -li

 303464 -rw-r--r--   2 emma     users           0 Aug  2 10:56 1
 303464 -rw-r--r--   2 emma     users           0 Aug  2 10:56 2
 303466 lrwxrwxrwx   1 emma     users           1 Aug  2 10:56 3 -> 1

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Christoph Hellwig]

In article <20010802110341.B17927@emma1.emma.line.org> you wrote:
>
> http://www.opengroup.org/onlinepubs/007908799/xbd/glossary.html#tag_004_000_291
>
>   "synchronised I/O data integrity completion
>
>   [...]
>
>   * For write, when the operation has been completed or diagnosed if
>   unsuccessful.  The write is complete only when the data specified in
>   the write request is successfully transferred and all file system
>   information required to retrieve the data is successfully transferred.
>
>   File attributes that are not necessary for data retrieval (access
>   time, modification time, status change time) need not be successfully
>   transferred prior to returning to the calling process.

NOTE: _file_ attributes

>
>   synchronised I/O file integrity completion
>
>   Identical to a synchronised I/O data integrity completion with the
>   addition that all file attributes relative to the I/O operation
>   (including access time, modification time, status change time) will be
>   successfully transferred prior to returning to the calling process."
>
> As I understand it, the directory entry's st_ino is a file attribute
> necessary for data retrieval and also contains the m/a/ctime, so it must
> be flushed to disk on fsync() as well.
>

As long as you have an open fd, no directory entry is needed for
data retrieval.  In fact some fds never have a directory entry
(e.g. sockets - but these don't support fsync anyway) or do not have a
directory entry in their user-visble interface (e.g. posix shm).

And m/a/ctime is in the inode of the file, not in the directory enrty.
(at least for usual UNIX filesystems).

> Well, if there's not a single dirent, you cannot retrieve the data,

Of course you can, you can pass and fd for an unliked file everywhere
using AF_LOCAL descriptor passing.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Thu, 2 Aug 2001, Christoph Hellwig wrote:

> > Well, if there's not a single dirent, you cannot retrieve the data,
>
> Of course you can, you can pass and fd for an unliked file
> everywhere using AF_LOCAL descriptor passing.

But this assumes the system doesn't crash, while
fsync() seems meant more as a protection against
the system going down unexpectedly ...

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

Re: ext3-2.4-0.9.4

[Eric W. Biederman]

Rik van Riel <riel@conectiva.com.br> writes:

> On Thu, 2 Aug 2001, Christoph Hellwig wrote:
> 
> > > Well, if there's not a single dirent, you cannot retrieve the data,
> >
> > Of course you can, you can pass and fd for an unliked file
> > everywhere using AF_LOCAL descriptor passing.
> 
> But this assumes the system doesn't crash, while
> fsync() seems meant more as a protection against
> the system going down unexpectedly ...

There is something to that.  However taking this argument to
it's logical extreme I have you have to not only sync every directory
in the current path of the file.  You have to sync your online file
index, because search engines is how we find things right?  

Since the filename in unix is not part of the files metadata it is a
perfectly sane semantic for fsck to drop the file into /lost+found, if
no one cared enough about the index/directory to update it.

In the general case if you have the guarantee that a filesystem does
safe directory updates.  So unless someone does an unlink you won't
loose your old link.  For most cases it doesn't matter as your
directory entry for the file is much older than the file itself, and
has been already synched.  MTA's are the exception to this where there
good filename is written only after the file is written.

The only other argument that seems to come from the MTA case is that
syscalls are slow, and a pain and programmers don't want to make two
or three syscalls just to do this.  Heck if you are doing a sync you
are waiting for a disk which is slow.  So speed doesn't really count.

There is probably an argument in there somewhere about batching up
I/O, so you have to wait a minimum amount of time for your sync.  But
until someone benchmarks, and tries a few different approatches I
won't believe that you need a kernel change even for that.

My question is what does fsync do on directories in other unix's.  It
would be really strange if it didn't behave similiarly to linux.
If forget wether it was AIX or HP-UX where doing a grep foo * would
also grep through "." .  So at least open works on other peoples directores.

Eric

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Thursday 02 August 2001 11:03, Matthias Andree wrote:
> On Wed, 01 Aug 2001, Stephen Tweedie wrote:
> > Matthias Andree wrote:
> > > Chase up to the root manually, because Linux' ext2 violates SUS
> > > v2 fsync() (which requires meta data synched BTW)
> >
> > Please quote chapter and verse --- my reading of SUS shows no such
> > requirement.
> >
> > fsync is required to force "all currently queued I/O operations
> > associated with the file indicated by file descriptor fildes to the
> > synchronised I/O completion state."  But as you should know,
> > directory entries and files are NOT the same thing in Unix/SUS.
>
> Read on: "All I/O operations are completed as defined for
> synchronised I/O _file_ integrity completion.". To show what that
> means, see the glossary.
>
> http://www.opengroup.org/onlinepubs/007908799/xbd/glossary.html#tag_0
>04_000_291
>
>   "synchronised I/O data integrity completion
>
>   [...]
>
>   * For write, when the operation has been completed or diagnosed if
>   unsuccessful.  The write is complete only when the data specified
> in the write request is successfully transferred and all file system
> information required to retrieve the data is successfully
> transferred.
>
>   File attributes that are not necessary for data retrieval (access
>   time, modification time, status change time) need not be
> successfully transferred prior to returning to the calling process.
>
>   synchronised I/O file integrity completion
>
>   Identical to a synchronised I/O data integrity completion with the
>   addition that all file attributes relative to the I/O operation
>   (including access time, modification time, status change time) will
> be successfully transferred prior to returning to the calling
> process."
>
> As I understand it, the directory entry's st_ino is a file attribute
> necessary for data retrieval and also contains the m/a/ctime, so it
> must be flushed to disk on fsync() as well.

I believed you've summarized the SUS requirements very well.  Apart 
from legalistic arguments, SUS quite clearly states that fsync should 
not return until you are sure of having recorded not only the file's 
data, but the access path to it.  I interpret this as being able to 
"access the file by its name", and being able to guess by looking in 
lost+found doesn't count.  I don't see the point in niggling about that.

So, it seems clear that an fsync which leaves any window of 
vulnerability where an interruption can leave a file unlinked is not 
SUS-compliant.

> > There can be many ways of reaching that file in the directory
> > hierarchy, or there can be none, but fsync() doesn't talk at all
> > about the status of those dirents after the sync.

This is a legalistic argument.  I don't think we should be looking for 
loopholes in SUS here.  To achieve SUS compliance there are two 
reasonable courses: "fix SUS" or "fix sys_fsync".  Since what SUS 
clearly wants here seems emminently reasonable, I'd suggest putting the 
energy that's currently going into this thread into fixing fsync 
instead.

> Well, if there's not a single dirent, you cannot retrieve the data,
> so I'd assume at least one dirent needs to be flushed as well. If
> there's a simple way to get unflushed dentries to disk (hard links
> included)...

*All* hard links?  No, there is no general way to do that.  However, 
any hard links[1] in the path used to open the file - yes.  There is 
always a chain of parent dentries held locked in the dcache for any 
open file.

I don't know why it is hard or inefficient to implement this at the VFS 
level, though I'm sure there is a reason or this thread wouldn't 
exist.  Stephen, perhaps you could explain for the record why sys_fsync 
can't just walk the chain of dentry parent links doing fdatasync?  Does 
this create VFS or Ext3 locking problems?  Or maybe it repeats work 
that Ext3 is already supposed to have done?

> ...flush them. Not sure about symlinks, but since they don't
> share the inode number, that might be rather difficult for the kernel
> (I didn't check)

The prescription for symlinks is, if you want them safely on disk you 
have to explicitly fsync the containing directory.

[1] In Ext2, all filename dirents are "hard links", i.e., there is no 
way to tell which of the two names is the original after creating a new 
hard link.

--
Daniel

intermediate summary of ext3-2.4-0.9.4 thread

[Matthias Andree]

On Thu, 02 Aug 2001, Daniel Phillips wrote:

[file name must be flushed on fsync()]
> I don't know why it is hard or inefficient to implement this at the VFS 
> level, though I'm sure there is a reason or this thread wouldn't 
> exist.  Stephen, perhaps you could explain for the record why sys_fsync 
> can't just walk the chain of dentry parent links doing fdatasync?  Does 
> this create VFS or Ext3 locking problems?  Or maybe it repeats work 
> that Ext3 is already supposed to have done?

Well, the course was that I asked whether ext3 would do synchronous
directory updates, and some people jumped in and said that one should
fsync() the parent directory, however, since we figure from SUS, that's
invalid.

After some forth and back, we finally figured that at least ext2 is
implementing fsync() improperly.

So this part is covered.

The other thing is, that Linux is the only known system that does
asynchronous rename/link/unlink/symlink -- people have claimed it might
not be the only one, but failed to name systems.

So we need to assume that Linux is the only system that does
asynchronous rename/link/unlink/symlink, however a directory fsync() is
believed to be rather expensive.

Still, some people object to a dirsync mount option. But this has been
the actual reason for the thread - MTA authors are refusing to pamper
Linux and use chattr +S instead which gives unnecessary (premature) sync
operations on write() - but MTAs know how to fsync().

> The prescription for symlinks is, if you want them safely on disk you 
> have to explicitly fsync the containing directory.

Yes, and it doesn't matter, since MTAs don't use symlinks (symlinks
waste inodes on most systems).

-- 
Matthias Andree

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Alexander Viro]

On Thu, 2 Aug 2001, Matthias Andree wrote:

> asynchronous rename/link/unlink/symlink, however a directory fsync() is
> believed to be rather expensive.

How the fuck it's expensive? It does _exactly_ the same as file fsync() -
literally the same code. It doesn't write blocks that don't belong to
directory. It doesn't write blocks that are clean. IOW, it does the
minimal work possible.

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Matthias Andree]

On Thu, 02 Aug 2001, Alexander Viro wrote:

> How the fuck it's expensive? It does _exactly_ the same as file fsync() -
> literally the same code. It doesn't write blocks that don't belong to
> directory. It doesn't write blocks that are clean. IOW, it does the
> minimal work possible.

fsync()ing the dir is not the minimal work possible, if e. g. temporary
files are open that don't need their names synched. Fsync()ing the
directory syncs also these temporary file NAMES that other processes may
have open (but that they unlink rather than fsync()).

Assume:

open -> asynchronous, but filename synched on fsync()
rename/link/unlink(/symlink) -> synchronous

This way, you never need to fsync() the directory, so you never sync()
entries of temporary files. You never lose important files (because the
application uses fsync() and the OS synchs rename/link etc.).

-- 
Matthias Andree

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Andreas Dilger]

Matthais Andree writes:
> fsync()ing the dir is not the minimal work possible, if e. g. temporary
> files are open that don't need their names synched. Fsync()ing the
> directory syncs also these temporary file NAMES that other processes may
> have open (but that they unlink rather than fsync()).
> 
> Assume:
> 
> open -> asynchronous, but filename synched on fsync()
> rename/link/unlink(/symlink) -> synchronous
> 
> This way, you never need to fsync() the directory, so you never sync()
> entries of temporary files. You never lose important files (because the
> application uses fsync() and the OS synchs rename/link etc.).

Do you read what you are writing?  How can a "synchronous" operation for
rename/link/unlink/symlink NOT also write out "temporary" files in the
same directory?  How does calling fsync() on the directory IF YOU REQUIRE
SYNCHRONOUS DIRECTORY OPERATIONS differ from making the specific operations
synchronous from within the kernel???

The only difference I can see is that making these specific operations
ALWAYS be synchronous hurts the common case when they can be async (see
Solaris UFS vs. Linux benchmark elsewhere in this thread), while requiring
an fsync() on the directory == only synchronous operation when it is
actually needed, and no "extra" performance hit.

The only slight point of contention is if you have very large directories
which span several filesystem blocks, in which case it _would_ be possible
to write out some blocks synchronously, while leaving other blocks dirty.
In practise however, you will either only be modifying a small number of
blocks (at the end of the directory) because an MTA usually only creates
files and doesn't delete them, and the actual speed of syncing several
blocks at one time is not noticably different than syncing only one.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Matthias Andree]

On Thu, 02 Aug 2001, Andreas Dilger wrote:

> > open -> asynchronous, but filename synched on fsync()
> > rename/link/unlink(/symlink) -> synchronous
> > 
> > This way, you never need to fsync() the directory, so you never sync()
> > entries of temporary files. You never lose important files (because the
> > application uses fsync() and the OS synchs rename/link etc.).
> 
> Do you read what you are writing?  How can a "synchronous" operation for
> rename/link/unlink/symlink NOT also write out "temporary" files in the
> same directory?  How does calling fsync() on the directory IF YOU REQUIRE
> SYNCHRONOUS DIRECTORY OPERATIONS differ from making the specific operations
> synchronous from within the kernel???

Can people please try to understand? Can people please start to THINK
before flaming?

I did not say that open() is to be synchronous. I did not write ANYTHING
of fsync()ing directories, I'm trying to get rid of this requirement.

Thus, if the kernel does rename/link synchronously, you'd never ever
fsync() a directory. To synch a filename to disk, you'd just fsync() the
filedescriptor (with a SUS compliant system, that is, i. e. ext3 or
reiserfs, but not ext2).

Now, if someone opens a temporary file, and nukes it later -- unlink()
--, and doesn't want it visible, he never calls fsync() for the file.

However, if some other process then fsync()s the directory, you start
synching the temporary file dirent -> unnecessary, is nuked later on
with an unlink().

That's why fsync() on the directory is on no account the minimum work.

> The only difference I can see is that making these specific operations
> ALWAYS be synchronous hurts the common case when they can be async (see
> Solaris UFS vs. Linux benchmark elsewhere in this thread), while requiring
> an fsync() on the directory == only synchronous operation when it is
> actually needed, and no "extra" performance hit.

In case you haven't noticed, this is about reliability without need to
fsync() the directory that doesn't all belong to your single, stupid
process but may have lots of asynchronous data of other processes -
temporary files for instance. You synch() that as well, which is
unnecessary and brings down other processes' performance.

In case you haven't noticed the other issue:

The whole thread is a FEATURE REQUEST for a dirsync mount option, for
MTAs and other software which requires reliable file systems, where the
name is negotiable. It aims to REDUCE OVERHEAD since chattr +S which is
the only workaround for synch-dirs - and it synchs synchronous files and
writes as well, and rendering things slower than necessary, since
write() can be buffered until you fsync() (and you want that to cut off
seek times).

Call the option bsd_slow_dirs if you like, I don't care. Given the
option, the administrator/user has the choice, currently, he hasn't. He
cannot possibly change all applications ported from other Unices.

Note: hindering this option doesn't get Linux anywhere. Pure file
system benchmarks are not worth a single bit of entropy unless Linux is
benchmarked chattr +S -- it's unreliable otherwise.

I cannot remember how often I explained this during the course of this
thread. Every other day, some ignorant comes out of its cavern and
discusses the whole thing over and over again.

And, once again, fsync()ing the directory is not an option for portable
applications. It's unnecessary on every other system (until someone
shows a production-ready system which by default has asynchronous
directory updates as well, but no-one has so far.)

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Matthias Andree]

On Fri, 03 Aug 2001, Anton Altaparmakov wrote:

[dirsync chattr/mount options]
> Me neither. With regards to the parallel discussion on SUS compliance it is 
> probably a good idea to have such a thing in some form anyway (although if 
> I understood the discussion correctly, we really want this to happen by 
> default, not just when some flag is set but then again I never read the 
> standards...).

The standard doesn't really command the behaviour, as it seems, but we
might want to look again after SUS v3 has been released (supposed to
happen later this year) - the SUS compliance was rather on fsync than on
rename/link.

However, I'd rather not choose the default for somebody else, because he
may have different requirements, a compile-time switch to set the
default should be fine, THIS one might indeed default to dirsync/noasync
unless changed by make {x,menu,}config.

Assuming that the chattr +S is accompanied by a corresponding -o sync
mount option, I'd expect that the dirsync option be available as chattr
option and as mount option, and choosing default mount options should be
rather easy.

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Jan Harkes]

On Fri, Aug 03, 2001 at 02:14:06AM +0200, Matthias Andree wrote:
> On Fri, 03 Aug 2001, Anton Altaparmakov wrote:
> > filedescriptor to be synced to disk, the ONLY possible way to do this it to 
> > sync the parent directory in order to commit the file name to disk. On some 
> 
> Do I really need to sync the WHOLE parent directory? Not just the
> relevant part? My directories hardly have only 1 disk block.

Only dirty blocks are written back to disk, i.e. the parts of the
directory that were modified by adding/removing names. It should be
pretty efficient.

> > to explicitly sync the directory filedescriptor afterwards.
> 
> Which is non-portable and will not be done by many application
> programmers which just use chattr +S instead (makes things S)afe and
> S)low) - and spoil performance that way since it makes not only
> directory writes synchronous, but file (data) writes as well.

"chattr +S" is about as portable as adding fsync(parent), or even worse
as it only works on an ext2 file system. So I'm assuming that this is
just a nice exercise in annoying people.

Jan

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Andreas Dilger]

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Bill Rugolsky Jr.]

On Thu, Aug 02, 2001 at 07:37:50PM +0200, Matthias Andree wrote:
> The other thing is, that Linux is the only known system that does
> asynchronous rename/link/unlink/symlink -- people have claimed it might
> not be the only one, but failed to name systems.
> 
> So we need to assume that Linux is the only system that does
> asynchronous rename/link/unlink/symlink, however a directory fsync() is
> believed to be rather expensive.
> 
> Still, some people object to a dirsync mount option. But this has been
> the actual reason for the thread - MTA authors are refusing to pamper
> Linux and use chattr +S instead which gives unnecessary (premature) sync
> operations on write() - but MTAs know how to fsync().

Let's inject a little reality into this discussion.  Filesystems are used
for something other than running MTA's written by stubborn "purists".

Solaris: Dell 600 MHz PIII 128MB RAM, largely quiescent:
         Solaris 8 mu4, UFS with logging

Linux:   VA Linux 800 MHZ PIII, 128MB RAM, largely quiescent
         RedHat Linux 7.1 w/ kernel-2.4.6-2.4 (2.4.6-ac5 + ext3-0.9.3).

660MB XFree86-4.1 build tree, cache primed with du -s in each case.

Here's something that we developers probably all do frequently: copy a
tree using hard links, so that we can patch it.

[solaris] find . | wc     
   33027   33027 1251671
[solaris] time find . -depth | cpio -pdul ../foo
0 blocks
 363.46s real    0.84s user   10.13s system 

Plain ext2:

[linux]# time find . -depth | cpio -pdul ../foo
0 blocks

real    0m3.823s user    0m0.240s sys     0m3.570s

Mounted ext3, ordered data mode.

[linux] time find . -depth | cpio -pdul ../foo
0 blocks

real    0m5.106s user    0m0.200s sys     0m3.700s

Mounted ext3, -o sync:

[root@ead51 bar]# time find . -depth | cpio -pdul ../foo
0 blocks

real    1m28.483s user    0m0.470s sys     0m4.410s 

=====================================================

Solaris8 UFS:   363.5 seconds
ext2:             3.8 seconds
ext3:             5.1 seconds
ext3 -o sync:    88.5 seconds

Got it?

Obviously, the last is the result of the poor interaction
of ext3+sync in 0.9.3, but Andrew Morton has already fixed that.
I will try again with 0.9.5 when I have a chance to upgrade that
machine.

I have no idea where BSD falls, but the basic point stands:  unused
features should not penalize other applications.  Andrew Morton has
figured out how to do this efficiently with ext3, and many kudos to him
for doing the work.  Absent that, why should I have to go get a cup of
coffee every time I want to patch a tree, just so some MTA can make
naive assumptions?

Regards,

   Bill Rugolsky

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Matthias Andree]

On Thu, 02 Aug 2001, Bill Rugolsky Jr. wrote:

> I have no idea where BSD falls, but the basic point stands:  unused
> features should not penalize other applications.  Andrew Morton has
> figured out how to do this efficiently with ext3, and many kudos to him
> for doing the work.  Absent that, why should I have to go get a cup of
> coffee every time I want to patch a tree, just so some MTA can make
> naive assumptions?

The whole idea is to have a switch to turn on BSD-style synchronous
directory update semantics. Nothing more, nothing you would not be able
to get rid off. In fact, you can mount file systems async on BSD as
well, but you'd better not have the machine crash. Irrecoverable file
system damage can result. As a compromise, softupdates are nearly as
fast as async, but FS damage is guaranteed to be recoverable.

In either case (async or soft-updates), files can end up in lost+found
after the control had been returned to the application that called open
or link.

-- 
Matthias Andree

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Eric W. Biederman]

Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:

> On Fri, 03 Aug 2001, Paul Jakma wrote:
> 
> > if the prime directive of MTAs is data integrity paranoia, then
> > surely the best assumption for an MTA to make is that
> > rename/link/unlink/symlink /are/ asynchronous in the general case?
> 
> They do on Linux, use chattr +S, and are much slower than e. g. on
> FreeBSD. Well. Not that I'd written THAT for the first time...

Actually given that this thread keeps coming up, but no one does anything
about it.  I'm tempted to suggest we remove chatrr +S support from ext2.
Then there will be enough pain that someone will fix the MTA instead of
moaning that kernel is slow...

That should be an easy patch to make...

Eric

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Matthias Andree]

On Fri, 03 Aug 2001, Eric W. Biederman wrote:

> Actually given that this thread keeps coming up, but no one does anything
> about it.  I'm tempted to suggest we remove chatrr +S support from ext2.
> Then there will be enough pain that someone will fix the MTA instead of
> moaning that kernel is slow...

They'd just drop Linux from the list of supported OS's, Linux will
disappoint people who trusted it, nothing is gained. Deliberate breakage
will not happen, because it would not help anyone except people with
twisted minds.

NO-ONE, including you, has come up with SERIOUS objections against a
dirsync option, except "is it really so much slower than chattr +S? show
figures" -- ext3 is being tuned to be fast in spite of chattr +S.

Reconsider your position.

Stop trolling please.

-- 
Matthias Andree

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Christoph Hellwig]

In article <20010803103954.A11584@emma1.emma.line.org> you wrote:
> They'd just drop Linux from the list of supported OS's, Linux will
> disappoint people who trusted it, nothing is gained. Deliberate breakage
> will not happen, because it would not help anyone except people with
> twisted minds.

Who cares?  There are more than enough sane mailer around..

> NO-ONE, including you, has come up with SERIOUS objections against a
> dirsync option, except "is it really so much slower than chattr +S? show
> figures" -- ext3 is being tuned to be fast in spite of chattr +S.

Talk is cheap.  Code up a non-invasive dirsync option and submit it to
Linus.  I don't see any reason why it won't be accepted..

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Eric W. Biederman]

Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:

> On Fri, 03 Aug 2001, Eric W. Biederman wrote:
> 
> > Actually given that this thread keeps coming up, but no one does anything
> > about it.  I'm tempted to suggest we remove chatrr +S support from ext2.
> > Then there will be enough pain that someone will fix the MTA instead of
> > moaning that kernel is slow...
> 
> They'd just drop Linux from the list of supported OS's, Linux will
> disappoint people who trusted it, nothing is gained. Deliberate breakage
> will not happen, because it would not help anyone except people with
> twisted minds.

There are some other uses for a fully synchronous disk accesses so I'm
not going to run out and do it.  The point is that work arounds for
strange programs is not a right, it is a nice optional feature.
 
> NO-ONE, including you, has come up with SERIOUS objections against a
> dirsync option, except "is it really so much slower than chattr +S? show
> figures" -- ext3 is being tuned to be fast in spite of chattr +S.

Clear objects against dirsync.  
- Extra code maintenance, makes the fs less reliable 
  (A reason for removing even synchrouns fs operations BTW).
- Unnecessary. fsync(dir) works today.
- dirsync is unlikely to be faster than fsync(file); fsync(dir) [not chattr +S]
  You really need something that can say remember these 5 syscalls,
  and sync the all their changes to disk togeter to really get an
  improvement in sync speed.
- I don't see anyone volunteering to write the code.

> Reconsider your position.

Nope.  Right now I would rather
a) Patch the mail programs to do the needed fsync(dir)
b) Totally remove synchrous disk updates from my OS, and
   make life really painful.
Before adding a dirsync option.

> Stop trolling please.

It wasn't trying to troll, just get this conversation on some productive
grounds.  I think supporting the MTA's is good, so long as it is a two
way relationship.

If someone went out and tried using fsync(dir) and then saying it
sucked we could definentily have more peace.

Using dirsync, and chattr +S hide the real problems that need to get
fixed.  Getting a good reliable, and high performance way to commit
actions to a filesystem.  

We already have one work around on linux that will work reliably.  So
now let's see if we can get a functional high performance solution.

And oh btw, new, functional high performance solutions are not
portable because they haven't been implemented in every operating
system.  Full understanding of the problem, and the solutions are two
new for the implementations to have gotten around.

Eric

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Stephen C. Tweedie]

Hi,

On Thu, Aug 02, 2001 at 07:37:50PM +0200, Matthias Andree wrote:

> So this part is covered.
> 
> The other thing is, that Linux is the only known system that does
> asynchronous rename/link/unlink/symlink -- people have claimed it might
> not be the only one, but failed to name systems.

Not true.  There are tons of others.

The issue was that synchronous directory updates are *optional* on
many systems (Linux included), but that Linux's support for that is
really inefficient since it ends up syncing file metadata updates too
(and it's much more efficient to use fsync for that.)

> Still, some people object to a dirsync mount option.

Who?  People who have discussed this in the past have certainly not
objected to my knowledge.  It would clearly help situations like this
(as would a dirsync chattr option.)

> > The prescription for symlinks is, if you want them safely on disk you 
> > have to explicitly fsync the containing directory.
> 
> Yes, and it doesn't matter, since MTAs don't use symlinks (symlinks
> waste inodes on most systems).

Irrelevant.   We're talking about what makes sensible semantics, not
what assumptions any specific application makes.  It makes no sense to
say that dirsync won't affect symlinks just because some existing
applications don't rely on that!

Cheers,
 Stephen

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Matthias Andree]

On Fri, 03 Aug 2001, Stephen Tweedie wrote:

> > > The prescription for symlinks is, if you want them safely on disk you 
> > > have to explicitly fsync the containing directory.
> > 
> > Yes, and it doesn't matter, since MTAs don't use symlinks (symlinks
> > waste inodes on most systems).
> 
> Irrelevant.   We're talking about what makes sensible semantics, not
> what assumptions any specific application makes.  It makes no sense to
> say that dirsync won't affect symlinks just because some existing
> applications don't rely on that!

It's rather my imagination that tracking hard links might be easier than
symlinks because hard links share the inode number. A more advanced (and
complex) implementation might prove the imagination wrong. I don't want
to consider which one is more efficient.

-- 
Matthias Andree

Re: intermediate summary of ext3-2.4-0.9.4 thread

[David Weinehall]

On Thu, Aug 02, 2001 at 07:37:50PM +0200, Matthias Andree wrote:
> On Thu, 02 Aug 2001, Daniel Phillips wrote:
> 
> [file name must be flushed on fsync()]
> > I don't know why it is hard or inefficient to implement this at the VFS 
> > level, though I'm sure there is a reason or this thread wouldn't 
> > exist.  Stephen, perhaps you could explain for the record why sys_fsync 
> > can't just walk the chain of dentry parent links doing fdatasync?  Does 
> > this create VFS or Ext3 locking problems?  Or maybe it repeats work 
> > that Ext3 is already supposed to have done?
> 
> Well, the course was that I asked whether ext3 would do synchronous
> directory updates, and some people jumped in and said that one should
> fsync() the parent directory, however, since we figure from SUS, that's
> invalid.
> 
> After some forth and back, we finally figured that at least ext2 is
> implementing fsync() improperly.
> 
> So this part is covered.

Yup, and this should be fixed imho.

> The other thing is, that Linux is the only known system that does
> asynchronous rename/link/unlink/symlink -- people have claimed it might
> not be the only one, but failed to name systems.

And this is a feature, not a bug.

> So we need to assume that Linux is the only system that does
> asynchronous rename/link/unlink/symlink, however a directory fsync() is
> believed to be rather expensive.

A directory fsync() might be expensive on non-Linux filesystems...

> Still, some people object to a dirsync mount option. But this has been
> the actual reason for the thread - MTA authors are refusing to pamper
> Linux and use chattr +S instead which gives unnecessary (premature) sync
> operations on write() - but MTAs know how to fsync().

So what you mean is that MTA authors refuse to pamper Linux through use
of fsync of the directory, but can accept to "pamper" Linux through use
of chattr +S?! This seem ridiculous.  It seems equally ridiculous to
demand that Linux should pamper for MTA authors that can't implement
fsync on the directory instead of writing BSD-specific code.

[snip]

To me this seems mostly like a way of saying "Hey, we've finally found
a way to make Linux look really bad compared to BSD-systems; let's
complain instead of writing alternative code that suits Linux systems
better than this code does." A lot like all the discussions on threads,
ueally.

Then again, I'm probably just extra grouchy today because it rained when
I rode my bike to work.


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Matthias Andree]

On Fri, 03 Aug 2001, David Weinehall wrote:

> On Thu, Aug 02, 2001 at 07:37:50PM +0200, Matthias Andree wrote:
> > Still, some people object to a dirsync mount option. But this has been
> > the actual reason for the thread - MTA authors are refusing to pamper
> > Linux and use chattr +S instead which gives unnecessary (premature) sync
> > operations on write() - but MTAs know how to fsync().
> 
> So what you mean is that MTA authors refuse to pamper Linux through use
> of fsync of the directory, but can accept to "pamper" Linux through use
> of chattr +S?! This seem ridiculous.  It seems equally ridiculous to
> demand that Linux should pamper for MTA authors that can't implement
> fsync on the directory instead of writing BSD-specific code.

It's a maintenance issue.

You effectively start wrapping up all relevant syscalls and have
system-specific interfaces. One wants the directory fsync()ed, the other
offers a special other trick to get the data flushed... what useful is
portability then if systems are so different?

> To me this seems mostly like a way of saying "Hey, we've finally found
> a way to make Linux look really bad compared to BSD-systems; let's

No wonder if the application chooses fully-synchronous operation on
Linux.

-- 
Matthias Andree

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Albert D. Cahalan]

David Weinehall writes:
> On Thu, Aug 02, 2001 at 07:37:50PM +0200, Matthias Andree wrote:

>> Still, some people object to a dirsync mount option. But this has been
>> the actual reason for the thread - MTA authors are refusing to pamper
>> Linux and use chattr +S instead which gives unnecessary (premature) sync
>> operations on write() - but MTAs know how to fsync().
>
> So what you mean is that MTA authors refuse to pamper Linux through use
> of fsync of the directory, but can accept to "pamper" Linux through use
> of chattr +S?! This seem ridiculous.  It seems equally ridiculous to
> demand that Linux should pamper for MTA authors that can't implement
> fsync on the directory instead of writing BSD-specific code.
>
> [snip]
>
> To me this seems mostly like a way of saying "Hey, we've finally found
> a way to make Linux look really bad compared to BSD-systems; let's
> complain instead of writing alternative code that suits Linux systems
> better than this code does." A lot like all the discussions on threads,
> ueally.

This is just completely true. One wonders why we seem to enjoy
getting screwed this way. We shouldn't be patching these MTAs or
hacking Linux to act like BSD. We should be avoiding these MTAs.

Somebody can create a big MTA list, listing the good and bad ones.
Then we get the Linux-hostile MTAs out of the Linux distributions,
demanding compliance like we do for filesystem layout. We also hunt
down Linux-related web pages that mention these MTAs and get the
pages changed or removed. The point is to make these MTAs just
disappear, never to be seen again. Nice MTAs get promoted.

Re: intermediate summary of ext3-2.4-0.9.4 thread

[Gregory Maxwell]

On Fri, Aug 03, 2001 at 03:59:02PM -0400, Albert D. Cahalan wrote:
[snip]
> Somebody can create a big MTA list, listing the good and bad ones.
> Then we get the Linux-hostile MTAs out of the Linux distributions,
> demanding compliance like we do for filesystem layout. We also hunt
> down Linux-related web pages that mention these MTAs and get the
> pages changed or removed. The point is to make these MTAs just
> disappear, never to be seen again. Nice MTAs get promoted.

Think we could just get their authors to 'disappear'? It might be more cost
effective, and I can think of at least one example where removing the author
would have other benefits beyond MTAs. :) :)

don't feed the trolls (was: intermediate summary of ext3-2.4-0.9.4 thread)

[Matthias Andree]

On Fri, 03 Aug 2001, Albert D. Cahalan wrote:

> This is just completely true. One wonders why we seem to enjoy
> getting screwed this way. We shouldn't be patching these MTAs or
> hacking Linux to act like BSD. We should be avoiding these MTAs.

Oh, you should make a start avoiding any MTAs because that way, this
list would get rid of one trouble maker after all.

Don't feed the trolls.

Re: don't feed the trolls (was: intermediate summary of ext3-2.4-0.9.4 thread)

[Albert D. Cahalan]

Matthias Andree writes:
> On Fri, 03 Aug 2001, Albert D. Cahalan wrote:

>> This is just completely true. One wonders why we seem to enjoy
>> getting screwed this way. We shouldn't be patching these MTAs or
>> hacking Linux to act like BSD. We should be avoiding these MTAs.
>
> Oh, you should make a start avoiding any MTAs because that way, this
> list would get rid of one trouble maker after all.
>
> Don't feed the trolls.

That wasn't intended to be a troll, though I do realize that it
could cause some noise -- including your post. Plenty of noise is
already being generated trying to accommodate hostile MTA authors.

Seriously, consider:

1. there are MTA authors that actively promote BSD over Linux
2. Linux users and distributions promote their MTA software

There is no sense in this. It is masochism and suicide.
It is worse than a waste of time to accommodate these MTAs.

Getting back on topic... while non-inherited ext2 attributes might
be nice, I'm sure the ext2/VFS authors don't need to be pestered
about it, and certainly not because of some lame software making
non-standard assumptions about filesystem behavior.

Re: don't feed the trolls (was: intermediate summary of ext3-2.4-0.9.4 thread)

[Matthias Andree]

On Sat, 04 Aug 2001, Albert D. Cahalan wrote:

> Seriously, consider:
> 
> 1. there are MTA authors that actively promote BSD over Linux
> 2. Linux users and distributions promote their MTA software

I do not endorse this behaviour (particularly, qmail not supporting
softupdates is rather ridiculous), but I understand that MTA authors
would rather want to rely on fsync() also bringing related meta data do
disk (as ext3 and reiserfs for Linux 2.4 already do even across a
rename()!) than to add dir=open("directory"); fsync(dir); close(dir) all
over the place.

> Getting back on topic... while non-inherited ext2 attributes might

What would they be good for? Make MTA that have in the past achieved
reliable behaviour with chattr +S unreliable?

> be nice, I'm sure the ext2/VFS authors don't need to be pestered
> about it, and certainly not because of some lame software making
> non-standard assumptions about filesystem behavior.

Well, the software documents its requirements and assumptions. I don't
see anything nonstandard with relying on fsync(). If ext2fs doesn't meet
the assumptions without chattr +S or mount -o sync, but allows to
enforce this behaviour chattr +S, deliberately breaking ext2 attributes
inheritance will make Linux deliberately unsuitable for this MTA -- or
at least, slow it down through the need to use mount -o sync.

Deliberately breaking things just to show somebody else "you cannot even
rely that chattr behaviour is invariant" is ridiculous and definitely
not the right way to go.

If the MTA author chooses chattr +S over fsync-directory, what's wrong
with that?

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Alexander Viro]

On Thu, 2 Aug 2001, Daniel Phillips wrote:

> I don't know why it is hard or inefficient to implement this at the VFS 
> level, though I'm sure there is a reason or this thread wouldn't 
> exist.  Stephen, perhaps you could explain for the record why sys_fsync 
> can't just walk the chain of dentry parent links doing fdatasync?  Does 
> this create VFS or Ext3 locking problems?  Or maybe it repeats work 
> that Ext3 is already supposed to have done?
 
Parent directory can be renamed. Which grandparent should we sync?
New one? Old one? Both? BTW, how about file itself getting renamed during
fsync()?

See the problem? And no, blocking all renames while fsync() happens is
not an answer - it's a DoS.
 
> [1] In Ext2, all filename dirents are "hard links", i.e., there is no 
> way to tell which of the two names is the original after creating a new 
> hard link.

s/Ext2/UNIX/.

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Thursday 02 August 2001 19:54, Alexander Viro wrote:
> On Thu, 2 Aug 2001, Daniel Phillips wrote:
> > I don't know why it is hard or inefficient to implement this at the
> > VFS level, though I'm sure there is a reason or this thread
> > wouldn't exist.  Stephen, perhaps you could explain for the record
> > why sys_fsync can't just walk the chain of dentry parent links
> > doing fdatasync?  Does this create VFS or Ext3 locking problems? 
> > Or maybe it repeats work that Ext3 is already supposed to have
> > done?
>
> Parent directory can be renamed. Which grandparent should we sync?
> New one? Old one? Both?

Either one, or both, it doesn't matter since the application has not 
forced any serialization on this and can't assume any.

> BTW, how about file itself getting renamed during fsync()?

It doesn't matter.  If the application wants to race that way, let it.  
We're talking about ensuring access to the fsynced fd's inode.

> See the problem? And no, blocking all renames while fsync() happens
> is not an answer - it's a DoS.

We would have done our duty by fsyncing the inodes one at a time 
working up the dentry chain towards the root, and not trying to lock 
the whole chain.  If something happens while we're doing that it's an 
application race.

--
Daniel

Re: ext3-2.4-0.9.4

[Stephen C. Tweedie]

Hi,

On Thu, Aug 02, 2001 at 07:26:16PM +0200, Daniel Phillips wrote:

> I believed you've summarized the SUS requirements very well.  Apart 
> from legalistic arguments,

Umm, this is a specification.  It is *supposed* to be interpreted
legalistically!

> SUS quite clearly states that fsync should 
> not return until you are sure of having recorded not only the file's 
> data, but the access path to it.  I interpret this as being able to 
> "access the file by its name", and being able to guess by looking in 
> lost+found doesn't count.

But that is just an interpretation.  There's nothing in the spec which
forces that interpretation.

fsync forces the data to disk.  There may be one or more pathnames
which the application also relies on, and if the application does care
about those, the application will have to ensure that they are synced
too.

Look, I agree that your interpretation is useful.  It's just not an
unambiguous requirement of the spec.

Cheers,
 Stephen

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Friday 03 August 2001 11:06, Stephen C. Tweedie wrote:
> Hi,
>
> On Thu, Aug 02, 2001 at 07:26:16PM +0200, Daniel Phillips wrote:
> > I believe you've summarized the SUS requirements very well.  Apart
> > from legalistic arguments,
>
> Umm, this is a specification.  It is *supposed* to be interpreted
> legalistically!

I'm saying that, when the intent is clear as it is in this case then 
trying to find loopholes in the form of expression is not useful.  
Better to argue that SUS is wrong than to pretend it didn't say what it 
did.

> > SUS quite clearly states that fsync should
> > not return until you are sure of having recorded not only the
> > file's data, but the access path to it.  I interpret this as being
> > able to "access the file by its name", and being able to guess by
> > looking in lost+found doesn't count.
>
> But that is just an interpretation.  There's nothing in the spec
> which forces that interpretation.

Well, look at the name "lost+found".  It's lost, maybe we found the 
data but the name is gone for good.  On the other hand, if we start 
with the same on-disk state that fsck had before creating the 
lost+found, but use a journal to recover the name, it *does* count 
because we have a deterministic mechanism for making fsync's promise 
come true.

> fsync forces the data to disk.  There may be one or more pathnames
> which the application also relies on, and if the application does
> care about those, the application will have to ensure that they are
> synced too.
>
> Look, I agree that your interpretation is useful.  It's just not an
> unambiguous requirement of the spec.

OK, fine, this damn English language and all that.  Do we agree that 
"access" means "be able to open by name"?

--
Daniel

Re: ext3-2.4-0.9.4

[Stephen C. Tweedie]

On Fri, Aug 03, 2001 at 04:08:20PM +0200, Daniel Phillips wrote:

> I'm saying that, when the intent is clear as it is in this case then 
> trying to find loopholes in the form of expression is not useful. 

The intent is perfectly clear regarding the data.  It is totally
undefined regarding names. 
 
> Well, look at the name "lost+found".  It's lost, maybe we found the 
> data but the name is gone for good.

That's fine --- it satisfies the SUS requirements.

> On the other hand, if we start 
> with the same on-disk state that fsck had before creating the 
> lost+found, but use a journal to recover the name, it *does* count 
> because we have a deterministic mechanism for making fsync's promise 
> come true.

That's an implementation decision, not a comment on the spec.

> > Look, I agree that your interpretation is useful.  It's just not an
> > unambiguous requirement of the spec.
> 
> OK, fine, this damn English language and all that.  Do we agree that 
> "access" means "be able to open by name"?

The word "access" isn't used there in the spec, so it doesn't matter.
The spec only refers to "all file system information required to
retrieve the data."  Integrity of the data is the only thing
guaranteed, not integrity of the namespace.

Cheers,
 Stephen

Re: ext3-2.4-0.9.4

[David S. Miller]

Stephen C. Tweedie writes:
 > The word "access" isn't used there in the spec, so it doesn't matter.
 > The spec only refers to "all file system information required to
 > retrieve the data."  Integrity of the data is the only thing
 > guaranteed, not integrity of the namespace.

In fact this interpretation would have a severe performance impact
for any implementation.

If you include "metadata of the 'path'" in "all filesystem
information..." then you have to basically sync each and every element
on the path(s) to that file.  This means walking each dentry in the
alias list for the inode, and then walk from each of those to the root
sync'ing along the way.

That would be a rediculious requirement.

Later,
David S. Miller
davem@redhat.com

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Friday 03 August 2001 17:11, David S. Miller wrote:
> Stephen C. Tweedie writes:
>  > The word "access" isn't used there in the spec, so it doesn't matter.
>  > The spec only refers to "all file system information required to
>  > retrieve the data."  Integrity of the data is the only thing
>  > guaranteed, not integrity of the namespace.
>
> In fact this interpretation would have a severe performance impact
> for any implementation.
>
> If you include "metadata of the 'path'" in "all filesystem
> information..." then you have to basically sync each and every element
> on the path(s) to that file.  This means walking each dentry in the
> alias list for the inode, and then walk from each of those to the root
> sync'ing along the way.
>
> That would be a rediculious requirement.

As I read the (excerpts from the) SUS, this isn't required, only that
at least one namespace path from the root to the fsynced file is
preserved.  I can imagine an efficient implementation for this.

--
Daniel

Re: ext3-2.4-0.9.4

[Bill Rugolsky Jr.]

On Fri, Aug 03, 2001 at 05:25:09PM +0200, Daniel Phillips wrote:
> As I read the (excerpts from the) SUS, this isn't required, only that
> at least one namespace path from the root to the fsynced file is
> preserved.  I can imagine an efficient implementation for this.

I might be way off base here; if so tell me.
Let's litter some sample code with fsync():

	fd = open("tmp/x",O_CREAT|O_WRONLY);
	...
	fsync(fd);
	rename("tmp/x","spool/x");
	fsync(fd);
	close(fd);

This looks safe and correct, given your semantics.  It is, unless the
link count of that file rises above 1, from say a mail admin quite
reasonably doing

	ln tmp/x peek/x

in the interval specified by "...".  In that case, it's not required
that "tmp/x" or "spool/x" ever hit disk.  So the code is only correct
if the file only has a single link, or we specify ordered meta-data
updates for open/rename/link/...  Following Stephen's argument, is 
"peek/x" any better than "lost+found"?  With more than one admin?

On older non-BSD systems (SYS3?,SYSV 3.x?) that don't do rename(), files can't
be moved without bumping their link counts:

	fd = open("tmp/x",O_CREAT|O_WRONLY);
	...
	fsync(fd);
	link("tmp/x","spool/x");
	fsync(fd);  /* <- possibly a NOP with your semantics */
	unlink("tmp/x");
	fsync(fd);
	close(fd);

Again, this will fail to preserve your desired semantics on crash,
unless we have ordered meta-data updates, or the stronger synchronous
link() requirement.

I think the semantics that you propose might be marginally useful, but
I don't think SUS requires it; my understanding (and that of a
close friend and former POSIX reviewer) has always been that inodes are
distinct from directory entries, and that fsync() preserves the fields
that stat() returns: mode, uid, gid, size, {a,c,m}time.

Regards,

   Bill Rugolsky

Re: ext3-2.4-0.9.4

[Bill Rugolsky Jr.]

On Fri, Aug 03, 2001 at 01:06:01PM -0400, Bill Rugolsky Jr. wrote:
> 	ln tmp/x peek/x

In fact, make that

	ln tmp/x peek/x
			<- MTA does the fsync()
	less peek/x
			<- MTA closes the file.
	rm peek/x
		     (peek gets written asynchronously to disk)
	*CRASH*
                           
Then we are back to "lost+found", nothing gained.

Regards,

   Bill Rugolsky

Re: ext3-2.4-0.9.4

[Jan Harkes]

On Fri, Aug 03, 2001 at 04:08:20PM +0200, Daniel Phillips wrote:
> > fsync forces the data to disk.  There may be one or more pathnames
> > which the application also relies on, and if the application does
> > care about those, the application will have to ensure that they are
> > synced too.
> >
> > Look, I agree that your interpretation is useful.  It's just not an
> > unambiguous requirement of the spec.
> 
> OK, fine, this damn English language and all that.  Do we agree that 
> "access" means "be able to open by name"?

No, until recently the device/inode number pair used to work very nicely
for both Coda and knfsd when they wanted to access a file. But it only
works from within the kernel where you can use iget. It's just that with
some of the newer filesystems the inode numbers are no longer unique, so
it became something more like device/inum/opaque handle (i.e. iget4).

As far as the fsync semantics are concerned. Yeah, they would be useful,
but only to avoid one directory fsync call that will tell the kernel
_exactly_ what the process wants instead of letting it figure it out by
itself. The argument I saw in this thread that fsync(dir) has too much
overhead because it might sync unrelated data is not very useful,
because that unrelated data will be synced anyways when it's not a
journalling fs.

Name to file object mapping is not part of the metadata associated with
a file. It is the contents of the directory and can only be modified by
directory operations, not operations on the file or filehandle.
open(file, O_CREAT) is really split up into create(parent, file) an
operation on the parent directory, and an open(file) operation which
returns the filehandle.

I also don't see why a rename operation, which operates on the source
and destination parent directories would have to not only look up the
file object but also somehow register with all open filehandles for that
object that both olddir and newdir need to be written back to disk
during the fsync as well. Or should that go the other way around, where
the filehandle has to chase down which directory it was renamed to?

Taken from another part of this thread Alexander and Daniel,
> > That there isn't THE directory in which the file resides. There might
> > be several, and setting the bit on one of them at random and expect
> > it to work is a _lot_ of work. For no real use.
>
> There is only one chain of directories from the fd's dentry up to the
> root, that's the one to sync.

Using the dentry chain is not reliable, for instance instead of moving
dentries around Coda simply unhashes dentries when state on the server
changes. Another process (perhaps on a different machine) might have
moved one of the ancestor directories from one location to another, or
even relinked/unlinked the file that we're working with (ln old new; rm
old) in which case the dentry path is lost, but ideally you'd expect
fsync to sync the 'new' name if it supposedly keeps the namespace
consistent.

Working on a distributed filesystem with somewhat weaker than UNIX
semantics might have skewed my vision. In Coda not every client will be
able to figure out which are all of the possibly paths that can lead to
a file object. And although we currently try our best to block
hardlinked directories they could possibly exist, making the problems
even worse.

Jan

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Friday 03 August 2001 17:18, Jan Harkes wrote:
> On Fri, Aug 03, 2001 at 04:08:20PM +0200, Daniel Phillips wrote:
> > > fsync forces the data to disk.  There may be one or more pathnames
> > > which the application also relies on, and if the application does
> > > care about those, the application will have to ensure that they are
> > > synced too.
> > >
> > > Look, I agree that your interpretation is useful.  It's just not an
> > > unambiguous requirement of the spec.
> >
> > OK, fine, this damn English language and all that.  Do we agree that
> > "access" means "be able to open by name"?
>
> No, until recently the device/inode number pair used to work very nicely
> for both Coda and knfsd when they wanted to access a file. But it only
> works from within the kernel where you can use iget. It's just that with
> some of the newer filesystems the inode numbers are no longer unique, so
> it became something more like device/inum/opaque handle (i.e. iget4).

We are talking about "after waking up from an unexpected interruption".
So, is this still relevant?

> As far as the fsync semantics are concerned. Yeah, they would be useful,
> but only to avoid one directory fsync call that will tell the kernel
> _exactly_ what the process wants instead of letting it figure it out by
> itself.

No, it's not just that.  It's not enough to fsync just the parent, the
parent's parent may have been relinked and not comitted.  Also, the
kernel has the advantage of the locked chain of dcache entries
available to it.  Finally, there is the saving of multiple syscall
overhead, which I didn't mention first time around because it's not a
lot compared to media access overhead.

> The argument I saw in this thread that fsync(dir) has too much
> overhead because it might sync unrelated data is not very useful,
> because that unrelated data will be synced anyways when it's not a
> journalling fs.

Yes, and I gave a detailed explanation earlier of why such overhead
will not amount to much.

> Name to file object mapping is not part of the metadata associated with
> a file. It is the contents of the directory and can only be modified by
> directory operations, not operations on the file or filehandle.

SUS doesn't just pronounce on the file metadata.  Quoting from earlier
in the thread:

----------
>   "synchronised I/O data integrity completion
>
>   [...]
>
>   * For write, when the operation has been completed or diagnosed if
>   unsuccessful.  The write is complete only when the data specified in
>   the write request is successfully transferred and all file system
>   information required to retrieve the data is successfully transferred.
----------

> open(file, O_CREAT) is really split up into create(parent, file) an
> operation on the parent directory, and an open(file) operation which
> returns the filehandle.
>
> I also don't see why a rename operation, which operates on the source
> and destination parent directories would have to not only look up the
> file object but also somehow register with all open filehandles for that
> object that both olddir and newdir need to be written back to disk
> during the fsync as well.

They don't both have to, either one will be good enough.  However,
"neither" is not good enough, according to SUS.

> Or should that go the other way around, where
> the filehandle has to chase down which directory it was renamed to?
>
> Taken from another part of this thread Alexander and Daniel,
>
> > > That there isn't THE directory in which the file resides. There might
> > > be several, and setting the bit on one of them at random and expect
> > > it to work is a _lot_ of work. For no real use.
> >
> > There is only one chain of directories from the fd's dentry up to the
> > root, that's the one to sync.
>
> Using the dentry chain is not reliable, for instance instead of moving
> dentries around Coda simply unhashes dentries when state on the server
> changes.

Could you be more specific about this, are you saying there are cases
where there is no valid parent link from a dcache entry?

> Another process (perhaps on a different machine) might have
> moved one of the ancestor directories from one location to another, or
> even relinked/unlinked the file that we're working with (ln old new; rm
> old) in which case the dentry path is lost, but ideally you'd expect
> fsync to sync the 'new' name if it supposedly keeps the namespace
> consistent.

I doesn't matter which one it syncs.

> Working on a distributed filesystem with somewhat weaker than UNIX
> semantics might have skewed my vision. In Coda not every client will be
> able to figure out which are all of the possibly paths that can lead to
> a file object. And although we currently try our best to block
> hardlinked directories they could possibly exist, making the problems
> even worse.

We don't need all the paths, and not any specific path, just a path.

--
Daniel

Re: ext3-2.4-0.9.4

[Stephen C. Tweedie]

Hi,

On Fri, Aug 03, 2001 at 05:47:17PM +0200, Daniel Phillips wrote:

> > As far as the fsync semantics are concerned. Yeah, they would be useful,
> > but only to avoid one directory fsync call that will tell the kernel
> > _exactly_ what the process wants instead of letting it figure it out by
> > itself.
> 
> No, it's not just that.  It's not enough to fsync just the parent, the
> parent's parent may have been relinked and not comitted.  Also, the
> kernel has the advantage of the locked chain of dcache entries
> available to it.

Not necessarily.  If the file has been hard-linked and then the
original link removed, we don't have a valid dcache entry any more
(and yes, this is a common construct for some applications --- it is
often used to work around NFS atomicity problems.)

An MTA using such a construct and expecting fsync to do the right
thing will *not* work if you follow the dcache chain on fsync as you
propose here.

> We don't need all the paths, and not any specific path, just a path.

Exactly, because fsync makes absolutely no gaurantees about the
namespace.  So a lost+found path is quite sufficient.

Cheers,
 Stephen

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Friday 03 August 2001 17:50, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, Aug 03, 2001 at 05:47:17PM +0200, Daniel Phillips wrote:
> > > As far as the fsync semantics are concerned. Yeah, they would be
> > > useful, but only to avoid one directory fsync call that will tell the
> > > kernel _exactly_ what the process wants instead of letting it figure it
> > > out by itself.
> >
> > No, it's not just that.  It's not enough to fsync just the parent, the
> > parent's parent may have been relinked and not comitted.  Also, the
> > kernel has the advantage of the locked chain of dcache entries
> > available to it.
>
> Not necessarily.  If the file has been hard-linked and then the
> original link removed, we don't have a valid dcache entry any more
> (and yes, this is a common construct for some applications --- it is
> often used to work around NFS atomicity problems.)

But in that case, the file was opened using the hard link, then the link
was deleted.  Fine.  The user is trying to tell us it's ok to lose the
linked file.  Whether or not it can be accessed through another path
is irrelevant.

> An MTA using such a construct and expecting fsync to do the right
> thing will *not* work if you follow the dcache chain on fsync as you
> propose here.

OK, this case where the walk to the root should fail is a "duh", and
exposes a corner case SUS didn't cover (at least not in the excerpts
I saw).  But this case is a userland race, the right thing to do is
just stop the walk.  This doesn't detract from the value of doing
the walk in the important case that the chain is intact.

> > We don't need all the paths, and not any specific path, just a path.
>
> Exactly, because fsync makes absolutely no gaurantees about the
> namespace.  So a lost+found path is quite sufficient.

Dunno, I think that's a statement that should be held up for further
scrutiny.

--
Daniel

Re: ext3-2.4-0.9.4

[Matthias Andree]

On Fri, 03 Aug 2001, Stephen Tweedie wrote:

> > We don't need all the paths, and not any specific path, just a path.
> 
> Exactly, because fsync makes absolutely no gaurantees about the
> namespace.  So a lost+found path is quite sufficient.

MTA authors don't share this. lost+found is "invisible" for the
application that created the file.

I have yet to meet a distribution which scans lost+found at boot time
and syslogs found files or sends root a mail.

So, effectively, lost+found will NOT be sufficient. Discarding file
names at will is not a good thing.

-- 
Matthias Andree

Re: ext3-2.4-0.9.4

[Zilvinas Valinskas]

On Fri, Aug 03, 2001 at 08:11:12PM +0200, Matthias Andree wrote:
> On Fri, 03 Aug 2001, Stephen Tweedie wrote:
> 
> > > We don't need all the paths, and not any specific path, just a path.
> > 
> > Exactly, because fsync makes absolutely no gaurantees about the
> > namespace.  So a lost+found path is quite sufficient.
> 
> MTA authors don't share this. lost+found is "invisible" for the
> application that created the file.
> 
> I have yet to meet a distribution which scans lost+found at boot time
> and syslogs found files or sends root a mail.

Debian Woody ...
> 
> So, effectively, lost+found will NOT be sufficient. Discarding file
> names at will is not a good thing.
> 
> -- 
> Matthias Andree
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Zilvinas Valinskas

Re: ext3-2.4-0.9.4

[Jan Harkes]

On Fri, Aug 03, 2001 at 05:47:17PM +0200, Daniel Phillips wrote:
> On Friday 03 August 2001 17:18, Jan Harkes wrote:
> > No, until recently the device/inode number pair used to work very nicely
> > for both Coda and knfsd when they wanted to access a file. But it only
> > works from within the kernel where you can use iget. It's just that with
> > some of the newer filesystems the inode numbers are no longer unique, so
> > it became something more like device/inum/opaque handle (i.e. iget4).
> 
> We are talking about "after waking up from an unexpected interruption".
> So, is this still relevant?

The NFS client hasn't been interrupted, and it's filehandle will still
identifies the file object by device/inode.

> > Name to file object mapping is not part of the metadata associated with
> > a file. It is the contents of the directory and can only be modified by
> > directory operations, not operations on the file or filehandle.
> 
> SUS doesn't just pronounce on the file metadata.  Quoting from earlier
> in the thread:
> 
> ----------
> >   "synchronised I/O data integrity completion
> >
> >   [...]
> >
> >   * For write, when the operation has been completed or diagnosed if
> >   unsuccessful.  The write is complete only when the data specified in
> >   the write request is successfully transferred and all file system
> >   information required to retrieve the data is successfully transferred.
> ----------

So that would be the file data, and it's on-disk inode information,
indirect blocks etc. All the information that the file system needs to
retrieve the data is then available, i.e. what is required for iget()
to succeed.

Ok, iget isn't exported to userspace, but fsck will place the file in a
user reachable location.

> > I also don't see why a rename operation, which operates on the source
> > and destination parent directories would have to not only look up the
> > file object but also somehow register with all open filehandles for that
> > object that both olddir and newdir need to be written back to disk
> > during the fsync as well.
> 
> They don't both have to, either one will be good enough.  However,
> "neither" is not good enough, according to SUS.

Ehh, sync only olddir and you just lost any path leading to the file.
Sync only newdir and the file is reachable from two locations, but it's
linkcount is too low.

> > Using the dentry chain is not reliable, for instance instead of moving
> > dentries around Coda simply unhashes dentries when state on the server
> > changes.
> 
> Could you be more specific about this, are you saying there are cases
> where there is no valid parent link from a dcache entry?

No the dcache entry could have a 'stale' fileobject associated with it
that has been superceded by a different object. This dentry is unhashed,
so that the next lookup will instantiate a new dentry which references
the new object. So syncing the stale object is useless, because it
doesn't really exist anymore, but the kernel (and actually the userspace
daemon on the client) doesn't know what the new object is until it is
accessed.

> > Working on a distributed filesystem with somewhat weaker than UNIX
> > semantics might have skewed my vision. In Coda not every client will be
> > able to figure out which are all of the possibly paths that can lead to
> > a file object. And although we currently try our best to block
> > hardlinked directories they could possibly exist, making the problems
> > even worse.
> 
> We don't need all the paths, and not any specific path, just a path.

Even if that path leads to a name that got removed, thereby forcing the
object into lost+found? I thought the MTA did something like,

fd = open(tmp/file)
write(fd)
fsync(fd)
link(tmp/file, new/file)
fsync(fd)		*1
unlink(tmp/file)

*1 If this fsync only syncs the path leading to tmp/file, and the unlink
tmp/file is written back to disk, which is likely because we're only
creating/syncing stuff in tmp.  Now, until new/file is written there is
no path information leading to the file anymore which makes this as
'safe' as not syncing path name information at all.

Now if the application would use the directory sync, it can actually
tell the kernel that that new/file name is the interesting one to keep
and that tmp doesn't even need to be written to disk at all.

Jan

Re: ext3-2.4-0.9.4

[Daniel Phillips]

On Friday 03 August 2001 18:16, Jan Harkes wrote:
> On Fri, Aug 03, 2001 at 05:47:17PM +0200, Daniel Phillips wrote:
> > On Friday 03 August 2001 17:18, Jan Harkes wrote:
> > > No, until recently the device/inode number pair used to work very
> > > nicely for both Coda and knfsd when they wanted to access a file. But
> > > it only works from within the kernel where you can use iget. It's just
> > > that with some of the newer filesystems the inode numbers are no longer
> > > unique, so it became something more like device/inum/opaque handle
> > > (i.e. iget4).
> >
> > We are talking about "after waking up from an unexpected interruption".
> > So, is this still relevant?
>
> The NFS client hasn't been interrupted, and it's filehandle will still
> identifies the file object by device/inode.

Interesting, but at best relevant only to network mounts.

> > > Name to file object mapping is not part of the metadata associated with
> > > a file. It is the contents of the directory and can only be modified by
> > > directory operations, not operations on the file or filehandle.
> >
> > SUS doesn't just pronounce on the file metadata.  Quoting from earlier
> > in the thread:
> >
> > ----------
> >
> > >   "synchronised I/O data integrity completion
> > >
> > >   [...]
> > >
> > >   * For write, when the operation has been completed or diagnosed if
> > >   unsuccessful.  The write is complete only when the data specified in
> > >   the write request is successfully transferred and all file system
> > >   information required to retrieve the data is successfully
> > > transferred.
> >
> > ----------
>
> So that would be the file data, and it's on-disk inode information,
> indirect blocks etc. All the information that the file system needs to
> retrieve the data is then available, i.e. what is required for iget()
> to succeed.

In spite of your interesting network filesystem example I'm not willing
to accept that access by inode is enough.  It's going pretty far out on
a limb, don't you agree?  I doubt that SUS explicitly allows the inum to
be interpreted as "information that the file system needs to retrieve
the data".

> Ok, iget isn't exported to userspace, but fsck will place the file in a
> user reachable location.

Hmmph.  It used to have a name, now it doesn't, and somebody did an fsync
on the file, which returned indicating success.  Do you think that's
right?

> > > I also don't see why a rename operation, which operates on the source
> > > and destination parent directories would have to not only look up the
> > > file object but also somehow register with all open filehandles for
> > > that object that both olddir and newdir need to be written back to disk
> > > during the fsync as well.
> >
> > They don't both have to, either one will be good enough.  However,
> > "neither" is not good enough, according to SUS.
>
> Ehh, sync only olddir and you just lost any path leading to the file.

You sync the one the dcache entry points at.

> Sync only newdir and the file is reachable from two locations, but it's
> linkcount is too low.

SUS didn't say the filesystem integrity had to be perfect, just that
"all file system information required to retrieve the data is
successfully transferred".

> > > Using the dentry chain is not reliable, for instance instead of moving
> > > dentries around Coda simply unhashes dentries when state on the server
> > > changes.
> >
> > Could you be more specific about this, are you saying there are cases
> > where there is no valid parent link from a dcache entry?
>
> No the dcache entry could have a 'stale' fileobject associated with it
> that has been superceded by a different object. This dentry is unhashed,
> so that the next lookup will instantiate a new dentry which references
> the new object. So syncing the stale object is useless, because it
> doesn't really exist anymore, but the kernel (and actually the userspace
> daemon on the client) doesn't know what the new object is until it is
> accessed.

This happens because the dentry was unlinked, but not when it is renamed,
right?  In that case it's ok to fail the walk IMHO, the user explicitly
left a window when it's ok to interpret the fsynced file as "gone".

> > > Working on a distributed filesystem with somewhat weaker than UNIX
> > > semantics might have skewed my vision. In Coda not every client will be
> > > able to figure out which are all of the possibly paths that can lead to
> > > a file object. And although we currently try our best to block
> > > hardlinked directories they could possibly exist, making the problems
> > > even worse.
> >
> > We don't need all the paths, and not any specific path, just a path.
>
> Even if that path leads to a name that got removed, thereby forcing the
> object into lost+found? I thought the MTA did something like,

We'd better get confirmation from the MTA expert in the thread.

> fd = open(tmp/file)
> write(fd)
> fsync(fd)
> link(tmp/file, new/file)
> fsync(fd)		*1
> unlink(tmp/file)
>
> *1 If this fsync only syncs the path leading to tmp/file, and the unlink
> tmp/file is written back to disk, which is likely because we're only
> creating/syncing stuff in tmp.  Now, until new/file is written there is
> no path information leading to the file anymore which makes this as
> 'safe' as not syncing path name information at all.

Nice clear example!  Yes, in essence we would have synced the original
path twice.  If this is what the MTA is really doing I'm willing to join
the "MTA is broken" camp.

> Now if the application would use the directory sync, it can actually
> tell the kernel that that new/file name is the interesting one to keep
> and that tmp doesn't even need to be written to disk at all.

Yep.  Or if it used rename, which updates the dcache entries, instead
of link/unlink.

--
Daniel

Re: ext3-2.4-0.9.4

[Rik van Riel]

On Fri, 3 Aug 2001, Daniel Phillips wrote:
> On Friday 03 August 2001 11:06, Stephen C. Tweedie wrote:
> > On Thu, Aug 02, 2001 at 07:26:16PM +0200, Daniel Phillips wrote:

> > Look, I agree that your interpretation is useful.  It's just not an
> > unambiguous requirement of the spec.
>
> OK, fine, this damn English language and all that.  Do we agree that
> "access" means "be able to open by name"?

If we didn't agree on this, Linux would have had an
open_by_inode() system call long ago.

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

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: ext3-2.4-0.9.4

[Chris Wedgwood]

On Thu, Jul 26, 2001 at 09:42:37PM +1000, Andrew Morton wrote:

    If postfix is capable of opening the files O_SYNC or of doing
    fsync() on them then the `chattr +s' is no longer necessary -
    unlike ext2, when the O_SYNC write() or the fsync() return, the
    directory contents (as well as the inode, bitmaps, data, etc) will
    all be tight on disk and will be restored after a crash.

    This should speed things up considerably, especially with
    journalled-data mode.  I need to test and characterise this some
    more to come up with some quantitative results and configuration
    recommendations.

Postfix does an fsync on file before closing them, it then does a
rename and expects once rename as returned, the renamed actually
occured --- even if the fs crashes.  It also expects if you fsync a
file, then it will appear in the parent directory with certainty and
not say /lost+found after fsck on reboot.

Without +s under ext2, you can loose file(s) in /lost+found because
open+write+fsync+close works and ensures the data is on disk, but the
parent directory doesn't get synced to disk, so it might get lost.




  --cw

Strange remount behaviour with ext3-2.4-0.9.4

[Sean Hunter]

Following the announcement on lkml, I have started using ext3 on one of my
servers.  Since the server in question is a farily security-sensitive box, my
/usr partition is mounted read only except when I remount rw to install
packages.

I converted this partition to run ext3 with the mount options
"nodev,ro,data=writeback,defaults" figuring that when I need to install new
packages etc, that I could just mount rw as before and that metadata-only
journalling would be ok for this partition as it really sees very little write
activity.

When I try to remount it r/w I get a log message saying:
Jul 27 09:54:29 henry kernel: EXT3-fs: cannot change data mode on remount

...even if I give the full mount option list with the remount instruction.

I can, however, remount it as ext2 read-write, but when I try to remount as
ext3 (even read only) I get the same problem.

Wierdly, "mount" lists it as being still an ext3 partition even though it has
been remounted as ext2.  I can't umount /usr because kjournald is currently
listed as using the partition.

The box in question is more-or-less RedHat 7.1, with ext3-2.4-0.9.4, kernel
2.4.7 and with the following relevant package versions:

mount-2.11g-4
util-linux-2.11f-3
e2fsprogs-1.22-2

...all from rawhide rpms.

Sean

Re: Strange remount behaviour with ext3-2.4-0.9.4

[Andrew Morton]

Sean Hunter wrote:
> 
> Following the announcement on lkml, I have started using ext3 on one of my
> servers.  Since the server in question is a farily security-sensitive box, my
> /usr partition is mounted read only except when I remount rw to install
> packages.
> 
> I converted this partition to run ext3 with the mount options
> "nodev,ro,data=writeback,defaults" figuring that when I need to install new
> packages etc, that I could just mount rw as before and that metadata-only
> journalling would be ok for this partition as it really sees very little write
> activity.
> 
> When I try to remount it r/w I get a log message saying:
> Jul 27 09:54:29 henry kernel: EXT3-fs: cannot change data mode on remount
> 
> ...even if I give the full mount option list with the remount instruction.

hmm..  The mount option handling there is a bit bogus.

What we *should* do on remount is check that the requested
journalling mode is equal to the current mode.  ext3 won't
allow you to change the journalling mode on-the-fly.

So...  you will have to omit the `data=xxx' portion of the
mount options when remounting.  It's being invisibly added
by /bin/mount.

/bin/mount tries to be smart.  If, for example you have

	/dev/hdf12 /mnt/hdf12 ext3 noauto,ro,data=writeback 1

in /etc/fstab and then type

	mount /dev/hdf12 -o remount,rw

then /bin/mount runs off and looks up the fstab entry and
inserts the mount options.  However if you instead type

	mount /dev/hdf12 /mnt/hdf12 -o remount,rw          (1)

then /bin/mount does *not* look up the fstab entry, and
the remount succeeds.

ho-hum.  For the while you'll have to fiddle with the mount
usage to get things working right.   Equation (1) above will
work fine.  Or apply the appended patch.

> I can, however, remount it as ext2 read-write, but when I try to remount as
> ext3 (even read only) I get the same problem.

You can't switch between ext2 and ext3 with a remount - unmount
is needed.

> Wierdly, "mount" lists it as being still an ext3 partition even though it has
> been remounted as ext2.  I can't umount /usr because kjournald is currently
> listed as using the partition.

That sounds very weird.  Could you please describe the steps
you took to create this state?

Sometimes /etc/mtab gets out of sync - especially for the
root fs.  It's more reliable to look in /proc/mounts



Here's the fix for the data= handling on remount:



Index: fs/ext3/super.c
===================================================================
RCS file: /cvsroot/gkernel/ext3/fs/ext3/super.c,v
retrieving revision 1.31
diff -u -r1.31 super.c
--- fs/ext3/super.c	2001/07/19 14:43:08	1.31
+++ fs/ext3/super.c	2001/07/27 10:14:48
@@ -513,12 +513,6 @@
 
 			if (want_value(value, "data"))
 				return 0;
-			if (is_remount) {
-				printk ("EXT3-fs: cannot change data mode "
-						"on remount\n");
-				return 0;
-			}
-
 			if (!strcmp (value, "journal"))
 				data_opt = EXT3_MOUNT_JOURNAL_DATA;
 			else if (!strcmp (value, "ordered"))
@@ -529,9 +523,18 @@
 				printk ("EXT3-fs: Invalid data option: %s\n",
 					value);
 				return 0;
+			}
+			if (is_remount) {
+				if ((*mount_options & EXT3_MOUNT_DATA_FLAGS) !=
+							data_opt) {
+					printk("EXT3-fs: cannot change data "
+						"mode on remount\n");
+					return 0;
+				}
+			} else {
+				*mount_options &= ~EXT3_MOUNT_DATA_FLAGS;
+				*mount_options |= data_opt;
 			}
-			*mount_options &= ~EXT3_MOUNT_DATA_FLAGS;
-			*mount_options |= data_opt;
 		} else {
 			printk ("EXT3-fs: Unrecognized mount option %s\n",
 					this_char);

Re: Strange remount behaviour with ext3-2.4-0.9.4

[Sean Hunter]

On Fri, Jul 27, 2001 at 08:24:14PM +1000, Andrew Morton wrote:
> Sean Hunter wrote:
> > 
> > Following the announcement on lkml, I have started using ext3 on one of my
> > servers.  Since the server in question is a farily security-sensitive box, my
> > /usr partition is mounted read only except when I remount rw to install
> > packages.
> > 
> > I converted this partition to run ext3 with the mount options
> > "nodev,ro,data=writeback,defaults" figuring that when I need to install new
> > packages etc, that I could just mount rw as before and that metadata-only
> > journalling would be ok for this partition as it really sees very little write
> > activity.
> > 
> > When I try to remount it r/w I get a log message saying:
> > Jul 27 09:54:29 henry kernel: EXT3-fs: cannot change data mode on remount
> > 
> > ...even if I give the full mount option list with the remount instruction.
> 
> hmm..  The mount option handling there is a bit bogus.
> 
> What we *should* do on remount is check that the requested
> journalling mode is equal to the current mode.  ext3 won't
> allow you to change the journalling mode on-the-fly.

Indeed.

> 
> So...  you will have to omit the `data=xxx' portion of the
> mount options when remounting.  It's being invisibly added
> by /bin/mount.

Thought so.  I tried both ways just to be sure.

> /bin/mount tries to be smart.  If, for example you have
> 
> 	/dev/hdf12 /mnt/hdf12 ext3 noauto,ro,data=writeback 1
> 
> in /etc/fstab and then type
> 
> 	mount /dev/hdf12 -o remount,rw
> 
> then /bin/mount runs off and looks up the fstab entry and
> inserts the mount options.  However if you instead type
> 
> 	mount /dev/hdf12 /mnt/hdf12 -o remount,rw          (1)
> 
> then /bin/mount does *not* look up the fstab entry, and
> the remount succeeds.

Interesting, and (almost) 100% true

sean@henry:~$  sudo mount /dev/sda8 /usr -oro,nodev,data=writeback,remount
mount: you must specify the filesystem type
sean@henry:~$ sudo mount /dev/sda8 /usr -oro,nodev,data=writeback,remount -text3
mount: /usr not mounted already, or bad option
sean@henry:~$ sudo mount /dev/sda8 /usr -oro,nodev,remount -text3
sean@henry:~$ mount
/dev/sdb6 on / type ext3 (rw)
none on /proc type proc (rw)
/dev/sda1 on /boot type ext2 (ro,nosuid,nodev)
/dev/sdc6 on /home type ext3 (rw,nosuid,nodev,data=ordered)
/dev/sda8 on /usr type ext3 (ro,nodev)
/dev/sda5 on /var type ext3 (rw,nosuid,nodev,sync,data=journal)
none on /dev/pts type devpts (rw,gid=5,mode=620)

It succeeds as long as I don't specify the journal type.

> 
> ho-hum.  For the while you'll have to fiddle with the mount
> usage to get things working right.   Equation (1) above will
> work fine.  Or apply the appended patch.
> 
> > I can, however, remount it as ext2 read-write, but when I try to remount as
> > ext3 (even read only) I get the same problem.
> 
> You can't switch between ext2 and ext3 with a remount - unmount
> is needed.

Wierd.  This certainly looked to all the world as though it worked for me.  Thus:

sean@henry:~$ sudo mount /dev/sda8 /usr -oro,nodev,remount -text2

...doesn't give me an error, but:

sean@henry:~$ mount 
/dev/sdb6 on / type ext3 (rw)
none on /proc type proc (rw)
/dev/sda1 on /boot type ext2 (ro,nosuid,nodev)
/dev/sdc6 on /home type ext3 (rw,nosuid,nodev,data=ordered)
/dev/sda8 on /usr type ext3 (ro,nodev)
                       ^^^^
/dev/sda5 on /var type ext3 (rw,nosuid,nodev,sync,data=journal)
none on /dev/pts type devpts (rw,gid=5,mode=620)


> > Wierdly, "mount" lists it as being still an ext3 partition even though it has
> > been remounted as ext2.  I can't umount /usr because kjournald is currently
> > listed as using the partition.
> 
> That sounds very weird.  Could you please describe the steps
> you took to create this state?

See above.

> Sometimes /etc/mtab gets out of sync - especially for the
> root fs.  It's more reliable to look in /proc/mounts

sean@henry:~$ cat /proc/mounts
/dev/root / ext3 rw 0 0
/proc /proc proc rw 0 0
/dev/sda1 /boot ext2 ro,nosuid,nodev 0 0
/dev/sdc6 /home ext3 rw,nosuid,nodev 0 0
/dev/sda8 /usr ext3 ro,nodev 0 0
/dev/sda5 /var ext3 rw,nosuid,nodev,sync 0 0
none /dev/pts devpts rw 0 0

sean@henry:~$ cat /etc/mtab   
/dev/sdb6 / ext3 rw 0 0
none /proc proc rw 0 0
/dev/sda1 /boot ext2 ro,nosuid,nodev 0 0
/dev/sdc6 /home ext3 rw,nosuid,nodev,data=ordered 0 0
/dev/sda8 /usr ext3 ro,nodev 0 0
/dev/sda5 /var ext3 rw,nosuid,nodev,sync,data=journal 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0

Its almost as if mount is just silently ignoring the "-t" option when I specify
ext2.

> 
> 
> Here's the fix for the data= handling on remount:

I'll try this when its safe to reboot the box.

Thanks very much for your help.

Sean 

Re: Strange remount behaviour with ext3-2.4-0.9.4

[Michal Jaegermann]

On Fri, Jul 27, 2001 at 10:32:21AM +0100, Sean Hunter wrote:
> Following the announcement on lkml, I have started using ext3 on one of my
> servers.  Since the server in question is a farily security-sensitive box, my
> /usr partition is mounted read only except when I remount rw to install
> packages.

Regardless of possible weirdness in a "smart" behaviour of 'mount' what
one exactly buys running a journaling file system on a _read only_
partition?  fsck times will be the same (unless you crashed when
installing new software :-).

  Michal

Re: Strange remount behaviour with ext3-2.4-0.9.4

[Alan Cox]

> Regardless of possible weirdness in a "smart" behaviour of 'mount' what
> one exactly buys running a journaling file system on a _read only_
> partition?  fsck times will be the same (unless you crashed when
> installing new software :-).

Several things:

1.	The simple case of remounting an fs read-only is easy, since no
	writes means no journal

2.	The software suspend case is horrible. Right now mixing a
	journalling fs and swsuspend tends to cause disk corruption because
	journalling fs's write to disk when told to mount read only

3.	Failed drives. Here the journalling mount overrides the read only
	request and the machine locks up preventing data recovery except
	by copying the whole 80Gb disk image to another disk

	Been there, it sucks

4.	Snapshots. Making read only snapshots can be very useful, and there
	you want the replay of the log to be into the page cache but not
	written back to physical media until its marked read-write

Alan

Re: Strange remount behaviour with ext3-2.4-0.9.4

[Chris Wedgwood]

On Fri, Jul 27, 2001 at 09:46:57PM +0100, Alan Cox wrote:

    2.	The software suspend case is horrible. Right now mixing a
    	journalling fs and swsuspend tends to cause disk corruption because
    	journalling fs's write to disk when told to mount read only

this is hard to fix... the fs needs to replay things to make things
consistent, and in many cases doing an 'in-memory' replay isn't an
option (ie. remember which stuff needs to replayed and read from the
journal instead of disk when required to do so)

    4.	Snapshots. Making read only snapshots can be very useful, and there
    	you want the replay of the log to be into the page cache but not
    	written back to physical media until its marked read-write

R/O snapshots are best done in the fs if possible, al la
WAFL. Something like that for resierfs or TUX2 would rule so much (you
more-or-less need need a tree-based fs and reference counting for all
the magic bits).  In fact, doing it as the fs layer means you could
have r/w snapshots with COW semantics.



  --cw

Re: Strange remount behaviour with ext3-2.4-0.9.4

[Alan Cox]

> more-or-less need need a tree-based fs and reference counting for all
> the magic bits).  In fact, doing it as the fs layer means you could
> have r/w snapshots with COW semantics.

You dont want r/w snapshots for archiving. An archive of a previous date is
worthless if it can't be absolutely utterly and definitively read only.

It is hard to do well, but its an important item. One possiiblity is to do
it by replaying the log to a r/w snapshot (in ram) over a r/o snapshot (on
stable media)

Re: Strange remount behaviour with ext3-2.4-0.9.4

[Chris Wedgwood]

On Fri, Jul 27, 2001 at 10:23:44PM +0100, Alan Cox wrote:

    You dont want r/w snapshots for archiving. An archive of a
    previous date is worthless if it can't be absolutely utterly and
    definitively read only.

sure, for archiving you don't, but for other purposes you might

RO is easier and what most people want, this is all WAFL gives right now

RW has it's uses too, especially if you can clone /foo/bar to
/foo/blem and such like, a cheaper more elegant way of cp -Rupdl I
guess

    It is hard to do well, but its an important item. One possiiblity
    is to do it by replaying the log to a r/w snapshot (in ram) over a
    r/o snapshot (on stable media)

you can probably get away without the need for replay... just build
and in-memory extent list of blocks to would otherwise have been
rewritten and the journal offsets, before you read a block, you check
to see if you need to get from journal first

obviously you need to make sure you get the last insatce of each block
in the journal should there be more than one



  --cw

Re: Strange remount behaviour with ext3-2.4-0.9.4

[Kai Henningsen]

alan@lxorguk.ukuu.org.uk (Alan Cox)  wrote on 27.07.01 in <E15QF5E-0006ZL-00@the-village.bc.nu>:

> > more-or-less need need a tree-based fs and reference counting for all
> > the magic bits).  In fact, doing it as the fs layer means you could
> > have r/w snapshots with COW semantics.
>
> You dont want r/w snapshots for archiving.

Not for archiving, but when you want to run something and then throw it  
away again, for example. You could do that by just holding onto a ro  
snapshot and then replacing the rw tree with it later, but by having two  
rw trees you don't need to stop your regular operations.

For this to really be useful, you'd want it as an inheritable per-process  
thing, similar to aviro's namespace thing.

MfG Kai

Re: ext3-2.4-0.9.4

[Philipp Matthias Hahn]

On Thu, 26 Jul 2001, Andrew Morton wrote:

> An update to the ext3 filesystem for 2.4 kernels is available at
>
> 	http://www.uow.edu.au/~andrewm/linux/ext3/
I'm using ext3-0.9.4 with linux-2.4.7 / 2.4.8-pre1 and get some hangs on
my dual P2-350:
>From time to time I will have multiple CRON-Daemons in D-state and login
hangs when logging in. It even happens during boot before my MTA is
started.

I have a single ext3 partition which is exported by kernel-nfs-server.

As soon as I do an Alt-SysRq-S forced sync the hang goes away and
everything works normal.

If you need further information send me an eMail. SGIs kdb is already
compiled in so if we need it ...

BYtE
Philipp
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

Re: ext3-2.4-0.9.4

[Stephen C. Tweedie]

Hi,

On Mon, Jul 30, 2001 at 08:37:07AM +0200, Philipp Matthias Hahn wrote:
> On Thu, 26 Jul 2001, Andrew Morton wrote:
> 
> > An update to the ext3 filesystem for 2.4 kernels is available at
> >
> > 	http://www.uow.edu.au/~andrewm/linux/ext3/
> I'm using ext3-0.9.4 with linux-2.4.7 / 2.4.8-pre1 and get some hangs on
> my dual P2-350:
> >From time to time I will have multiple CRON-Daemons in D-state and login
> hangs when logging in. It even happens during boot before my MTA is
> started.

Interesting.  Do you have the ability to hook up a serial console?  If
so, "alt-sysrq-T" to capture a backtrace of all the blocked processes
would be a great help.  Thanks.

Cheers,
 Stephen