* Re: 64-bit and N32 kernel interfaces
From: Kjeld Borch Egevang @ 2002-09-05 10:15 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Jun Sun, Maciej W. Rozycki, linux-mips
In-Reply-To: <20020904204038.D1121@linux-mips.org>
On Wed, 4 Sep 2002, Ralf Baechle wrote:
...
> Several approach to solve that problem. Adding another 1000 entries - which
> will cost 8000 bytes of memory that will be mostly zeros. Having wrappers
> for each function that do the appropriate argument and result convertion
> is another. etc.
Ralf, that's not true. In our current 64-bit kernel we have 234 entries
for N64 which uses 8*234 = 1872 bytes. N32 has 241 entries using 1928
bytes. Even in an embedded environment that's not a lot of memory.
/Kjeld
--
_ _ ____ ___ Mailto:kjelde@mips.com
|\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85
| \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55
TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56
Denmark http://www.mips.com/
^ permalink raw reply
* Re: Desaster Reiser
From: Oleg Drokin @ 2002-09-05 10:09 UTC (permalink / raw)
To: jose; +Cc: reiser
In-Reply-To: <3D776FEF.F34E655B@tridentemonigotes.com>
Hello!
On Thu, Sep 05, 2002 at 10:53:35AM -0400, jose@tridentemonigotes.com wrote:
> -I have a server 2.4.3 and something HD reiserfs. Yesterday one
> of this
> HD started to give me problems this is the message.
2.4.3 kernel is very old ad is filled with known bugs both in reiserfs and other
parts of code. You should consider upgrading.
> After this with reiserfs --check /dev/hdb2 this is the message that gave
> me
What reiserfsprogs version do you have?
If that's not the last one (3.6.3), you should download reiserfsprogs-3.6.3 from
our ftp site.
> I probed with badblocks and reiserfsck --rebuild -sd but was not
> anithing problem and my fear is I wrote that somebody have lose their HD
> with reiserfsck --rebuild -tree because after can't mount their units.I
That was possible because of reiserfsck crash for example, data are still not
lost though partition cannot be mounted.
> think that this is the last option if I have another
> Have another options before my HD is totally crash and all information
> is missing?
Well, if you want to be on safe side, you can create metadata snapshot
(debugreiserfs -p /dev/device | gzip -9c >metadata.gz) and make it available for
us to download. and we can verify that reiserfsprogs will work as expected.
Make sure you use reiserfsprogs 3.6.3 version for that operation.
Or you can download reiserfsprogs 3.6.3 and run reiserfsck --rebuild-tree
from there and only contact us if it will crash. (with metaadta, too).
Also after your problems are over you will need to upgrade the kernel to avoid
future corruptions.
Bye,
Oleg
^ permalink raw reply
* [LARTC] matching classid with iptables and stuff
From: mdew @ 2002-09-05 10:09 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]
# 40.10 Paul 40.11 Mark
tc class add dev imq0 parent 40:1 classid 40:10 htb rate 5Kbps ceil
7Kbps burst 2k
tc class add dev imq0 parent 40:1 classid 40:11 htb rate 5Kbps ceil
6Kbps burst 3k
# 40:12 Mike 40:13 Brian
tc class add dev imq0 parent 40:1 classid 40:12 htb rate 200Kbps ceil
220Kbps burst 4k
tc class add dev imq0 parent 40:1 classid 40:13 htb rate 200Kbps ceil
240Kbps burst 4k
how do i show 40:1x is the ip w.x.y.z (and for the other ip's) ?
Working off the prensentation..
Basically we have a 256Kb connection (yes small fry)
## We Start at the root of the device, eth0
# Install HTB as the root qdisc, names it 1:0.
tc qdisc add dev eth0 root handle 1: htb
# This attaches a shaping HTB to the HTB root, 256kps with a 2k bucket
tc gdisc add dev eth0 parent 1: classid 1:1 htb rate 256Kbps burst 20k
#The first class is guaranteed 5Kbps of the 256Kbps, but can grow to 7
if available
#The second class however can take up to 240kbits (changed)
# 1.10 Paul 1.11 Mark
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5Kbps ceil 7Kbps
burst 2k
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 5Kbps ceil 6Kbps
burst 3k
# 1:12 Mike 1:13 Brian
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 200Kbps ceil
220Kbs burst 4k
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 200Kbps ceil
240Kbs burst 4k
## Filtering to Classify traffic
# When a packet enters the qdisc it needs to be classified. This is done
with 'tc filters':
U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32"
$U32 match ip dport 25 0xffff flowid 1:10
$U32 match ip sport 80 0xffff flowid 1:11
## Shape incoming Traffic (IMQ)
modprobe imq numdevs=1
tc qdisc add dec imq0 root handle 40: htb default 22
tc class add dev imq0 parent 40: classid 40:1 htb rate 256Kbps burst
20k
# 40.10 Paul 40.11 Mark
tc class add dev imq0 parent 40:1 classid 40:10 htb rate 5Kbps ceil
7Kbps burst 2k
tc class add dev imq0 parent 40:1 classid 40:11 htb rate 5Kbps ceil
6Kbps burst 3k
# 40:12 Mike 40:13 Brian
tc class add dev imq0 parent 40:1 classid 40:12 htb rate 200Kbps ceil
220Kbps burst 4k
tc class add dev imq0 parent 40:1 classid 40:13 htb rate 200Kbps ceil
240Kbps burst 4k
tc class add dev imq0 parent 40:10 classid 40:11 htb rate 240Kbps burst
4k
iptables -t mangle -A PREROUTING -i eth0 -j IMQ
# Push all Pauls traffic through IMQ
iptables -t mangle -A PREROUTING -i eth0 -p tcp -d 10.0.0.9 -j IMQ
--todev 0
ip link setup imq0 up
am i close? :)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: attrib +A doesn't work
From: Oleg Drokin @ 2002-09-05 10:01 UTC (permalink / raw)
To: Nikita Danilov; +Cc: Tom Vier, Reiserfs mail-list
In-Reply-To: <15735.10894.167461.158961@laputa.namesys.com>
Hello!
On Thu, Sep 05, 2002 at 01:57:34PM +0400, Nikita Danilov wrote:
> Support for inode attributes was introduced between 2.4.18 and
> 2.4.19. Take latest reiserfsprogs from ftp.namesys.com, run
> /sbin/reiserfsck --clean-attributes /your-device, and after that
> finishes mount with -attrs option.
mount -o attrs in fact.
Bye,
Oleg
^ permalink raw reply
* Re: bandwidth again maybe O T
From: Antony Stone @ 2002-09-05 10:00 UTC (permalink / raw)
To: netfilter
In-Reply-To: <3D773301.9040109@iprimus.com.au>
On Thursday 05 September 2002 11:33 am, Michael wrote:
> Ohh toss....
>
> My appologies, I shall clarify:
>
> If a packet originates from local processes, and is destined for a local
> process, the INPUT chain is traversed only.
That's not *quite* right - a packet from a local process to a local process
traverses both the OUTPUT and INPUT chains (in that order).
Antony
--
Documentation is like sex:
when it's good, it's very very good;
when it's bad, it's still better than nothing.
^ permalink raw reply
* Re: Automount oops - who to report to?
From: Axel H. Siebenwirth @ 2002-09-05 10:04 UTC (permalink / raw)
To: Ian Chard; +Cc: linux-kernel
In-Reply-To: <85FE9CAA6C27954DB82E5BE729EB636D08C787@exmbx01livi.cadence.com>
Ian Chard wrote:
> Sorry for mailing so generically, but I have a recurring problem with
> autofs
> hanging and oopsing, and I can't figure out who the maintainer of this
> bit of
> the kernel is. Can you point me in the right direction?
I'm not sure but I think it's Peter Anvin (hpa@transmeta.com).
Regards,
Axel Siebenwirth
^ permalink raw reply
* Re: attrib +A doesn't work
From: Nikita Danilov @ 2002-09-05 9:57 UTC (permalink / raw)
To: Tom Vier; +Cc: Reiserfs mail-list
In-Reply-To: <20020905034320.GA11951@yzero>
Tom Vier writes:
> i thought 3.6 support attribs (or at least some of them), but A isn't
> working. i ran touch test; chattr +A test; stat test; cat test; stat test;
> the second stat showed an updated atime.
>
> is there some undocumented mount option to enable attribs?
Yes.
Support for inode attributes was introduced between 2.4.18 and
2.4.19. Take latest reiserfsprogs from ftp.namesys.com, run
/sbin/reiserfsck --clean-attributes /your-device, and after that
finishes mount with -attrs option.
>
> --
> Tom Vier <tmv@comcast.net>
> DSA Key ID 0xE6CB97DA
Nikita.
^ permalink raw reply
* Re: libipulog question (again)
From: Harald Welte @ 2002-09-05 9:56 UTC (permalink / raw)
To: Rob McMillen; +Cc: Netfilter Development Mailinglist
In-Reply-To: <Pine.LNX.4.44.0209041924230.2080-100000@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 680 bytes --]
On Wed, Sep 04, 2002 at 07:34:37PM -0400, Rob McMillen wrote:
> Hope this is the right medium. I am really having problems with ULOG. I
> have a simple rule
>
> iptables -A OUTPUT -d 192.168.0.1 -j ULOG
what is the version of ipt_ULOG.c? where did you get libipulog from
(from which iptables package?)
> Thanks in advance,
> Rob
--
Live long and prosper
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: [PATCH] New target: SWITCH
From: Harald Welte @ 2002-09-05 9:55 UTC (permalink / raw)
To: garana; +Cc: Netfilter Development Mailinglist
In-Reply-To: <200209042334.g84NYEg03822@gonzalo.arana>
On Wed, Sep 04, 2002 at 08:34:14PM -0300, garana@uolsinectis.com.ar wrote:
> Hi,
>
> I am developing a new target which should redirect
> packets to a given host, no matter what routing table
> says.
> This, with the aid of the random_patch (written by
> <fabrice@celestix.com>) should enable a Linux box
> to do a layer 3,4 switch work.
> When I try to add a rule with this target:
First of all, thanks for your contribution.
However, if this ever is to be included into patch-o-matic or the
kernel, you _must_ adhere to /usr/src/linux/Documentation/CodingStyle.
This includes indentation and c++ (//) comments.
--
Live long and prosper
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
^ permalink raw reply
* Re: 64-bit and N32 kernel interfaces
From: Maciej W. Rozycki @ 2002-09-05 9:53 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20020904204622.D32519@linux-mips.org>
On Wed, 4 Sep 2002, Ralf Baechle wrote:
> Well, N32 is yet another case. Have to look into details again but some
> MIPS guy recently pointed out to me that there are a few syscalls which
> for N32 cannot be handled by the o32 or N64 syscall entry as they are right
> now.
Which ones? Maybe we might just add some padding to structures.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: [PATCH] Re: missing space after --mss range
From: Harald Welte @ 2002-09-05 9:50 UTC (permalink / raw)
To: Michael Schwendt; +Cc: netfilter-devel
In-Reply-To: <20020904135047.17757.qmail@web14604.mail.yahoo.com>
On Wed, Sep 04, 2002 at 06:50:47AM -0700, Michael Schwendt wrote:
> I forgot to flag the previous reply in this thread with [PATCH] and maybe
> it will be missed then. Here's the flag, and the patch once more.
Thanks, patch applied.
--
Live long and prosper
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
^ permalink raw reply
* Re: aic7xxx sets CDR offline, how to reset?
From: Jeremy Higdon @ 2002-09-05 9:50 UTC (permalink / raw)
To: James Bottomley
Cc: Doug Ledford, Alan Cox, Justin T. Gibbs, linux-kernel, linux-scsi
In-Reply-To: <200209041624.g84GOJC02683@localhost.localdomain>
On Sep 4, 11:24am, James Bottomley wrote:
>
> jeremy@classic.engr.sgi.com said:
> > For example, in Fibrechannel using class 3 (the usual)
>
> > send command (command frame corrupted; device does not receive)
> > send barrier (completes normally)
> > ... (lots of time goes by, many more commands are processed)
> > timeout original command whose command frame was corrupted
>
> This doesn't look right to me from the SCSI angle I don't see how you can get
> a successful disconnect on a command the device doesn't receive (I take it
> this is some type of Fibre magic?). Of course, if the device (or its proxy)
> does receive the command then the ordered queue tag implementation requires
> that the corrupted frame command be processed prior to the barrier, this
> isn't optional if you obey the spec. Thus, assuming the processor does no
> integrity checking of the command until it does processing (this should be a
> big if), then we still must get notification of the failed command before the
> barrier tag is begun. Obviously, from that notification we do then race to
> eliminate the overtaking tags.
You don't have disconnect per se with Fibre (or with other packet based
interfaces). A command is sent as a frame. If the frame is corrupted
or lost on the way to the target, then the target will never know about
the command having been sent. There are obvious problems if that command
has an ordered tag, preceded and followed by simple tags dependent on
the ordered semantics being followed, and where the simple tagged commands
following don't wait for the ordered tag to finish. There are other
failure modes too, of course.
> > There was also the problem of the queue full to the barrier command,
> > etc.
>
> The queue full problem still exists. I've used this argument against the
> filesystem people many times at the various fora where it has been discussed.
> The situation is that everyone agrees that it's a theoretical problem, but
> no-one is convinced that it will actually occur in practice (I think it falls
> into the "risk we're willing to take" category).
I guess it all depends on how sensitive one is to getting it wrong. In
any case, it looks as though you are doing what you can . . . .
> James
thanks
jeremy
^ permalink raw reply
* Re: [reiserfs-dev] Re: [PATCH] sparc32: wrong type of nlink_t
From: Oleg Drokin @ 2002-09-05 9:54 UTC (permalink / raw)
To: David S. Miller
Cc: szepe, mason, reiser, shaggy, marcelo, linux-kernel, reiserfs-dev,
linuxjfs
In-Reply-To: <20020904.223651.79770866.davem@redhat.com>
Hello!
On Wed, Sep 04, 2002 at 10:36:51PM -0700, David S. Miller wrote:
> > Our disk format has link counts > 32k
> Does the internal reiserfs nlink value translate directly
> to what stat() puts in st_nlink?
> It really doesn't matter. Even if you have some huge value that can't
> be represented in st_nlink, you can report to the user that st_nlink
> is NLINK_MAX.
Ok, since I really like this approach, below is the patch (for 2.4) that
demonstrates my solution.
Also it correctly calculates maximal number given type may hold ( does not work
with unsigned long long, though) with my own way ;)
FS compatibility is still intact and older kernel will work.
If nobody will object against this code, then I'll implement something
similar for 2.5 too and we will fix reiserfsck to understand this correct
nlink accounting.
The only downside of this patch is that v3.5 filesystems won't allow to
create more than 64k-2 subdirs in a dir, like old code did, but this is
not an issue I think. (already existent dirs should still work)
Bye,
Oleg
===== fs/reiserfs/inode.c 1.35 vs edited =====
--- 1.35/fs/reiserfs/inode.c Fri Aug 9 19:22:33 2002
+++ edited/fs/reiserfs/inode.c Thu Sep 5 13:43:26 2002
@@ -891,7 +891,8 @@
set_inode_item_key_version (inode, KEY_FORMAT_3_5);
set_inode_sd_version (inode, STAT_DATA_V1);
inode->i_mode = sd_v1_mode(sd);
- inode->i_nlink = sd_v1_nlink(sd);
+ inode->i_nlink = ( sd_v1_nlink(sd) > REISERFS_LINK_MAX ) ? REISERFS_LINK_MAX:sd_v1_nlink(sd);
+ inode->u.reiserfs_i.i_nlink_real = sd_v1_nlink(sd);
inode->i_uid = sd_v1_uid(sd);
inode->i_gid = sd_v1_gid(sd);
inode->i_size = sd_v1_size(sd);
@@ -923,7 +924,8 @@
struct stat_data * sd = (struct stat_data *)B_I_PITEM (bh, ih);
inode->i_mode = sd_v2_mode(sd);
- inode->i_nlink = sd_v2_nlink(sd);
+ inode->i_nlink = (sd_v2_nlink(sd)>REISERFS_LINK_MAX)?REISERFS_LINK_MAX:sd_v2_nlink(sd);
+ inode->u.reiserfs_i.i_nlink_real = sd_v2_nlink(sd);
inode->i_uid = sd_v2_uid(sd);
inode->i_size = sd_v2_size(sd);
inode->i_gid = sd_v2_gid(sd);
@@ -975,7 +977,7 @@
__u16 flags;
set_sd_v2_mode(sd_v2, inode->i_mode );
- set_sd_v2_nlink(sd_v2, inode->i_nlink );
+ set_sd_v2_nlink(sd_v2, inode->u.reiserfs_i.i_nlink_real );
set_sd_v2_uid(sd_v2, inode->i_uid );
set_sd_v2_size(sd_v2, inode->i_size );
set_sd_v2_gid(sd_v2, inode->i_gid );
@@ -1001,7 +1003,7 @@
set_sd_v1_mode(sd_v1, inode->i_mode );
set_sd_v1_uid(sd_v1, inode->i_uid );
set_sd_v1_gid(sd_v1, inode->i_gid );
- set_sd_v1_nlink(sd_v1, inode->i_nlink );
+ set_sd_v1_nlink(sd_v1, inode->u.reiserfs_i.i_nlink_real );
set_sd_v1_size(sd_v1, inode->i_size );
set_sd_v1_atime(sd_v1, inode->i_atime );
set_sd_v1_ctime(sd_v1, inode->i_ctime );
@@ -1537,7 +1539,7 @@
/* fill stat data */
inode->i_mode = mode;
- inode->i_nlink = (S_ISDIR (mode) ? 2 : 1);
+ inode->u.reiserfs_i.i_nlink_real = inode->i_nlink = (S_ISDIR (mode) ? 2 : 1);
inode->i_uid = current->fsuid;
if (dir->i_mode & S_ISGID) {
inode->i_gid = dir->i_gid;
===== fs/reiserfs/namei.c 1.24 vs edited =====
--- 1.24/fs/reiserfs/namei.c Fri Aug 9 19:22:33 2002
+++ edited/fs/reiserfs/namei.c Thu Sep 5 13:34:43 2002
@@ -8,8 +8,16 @@
#include <linux/reiserfs_fs.h>
#include <linux/smp_lock.h>
-#define INC_DIR_INODE_NLINK(i) if (i->i_nlink != 1) { i->i_nlink++; if (i->i_nlink >= REISERFS_LINK_MAX) i->i_nlink=1; }
-#define DEC_DIR_INODE_NLINK(i) if (i->i_nlink != 1) i->i_nlink--;
+#define INC_INODE_NLINK(i) { if (i->i_nlink < REISERFS_LINK_MAX) i->i_nlink++; i->u.reiserfs_i.i_nlink_real++; }
+#define DEC_INODE_NLINK(i) {if ( --i->u.reiserfs_i.i_nlink_real < REISERFS_LINK_MAX) i->i_nlink--;}
+
+// v3.5 files have 16bit nlink_t, v3.6 files have 32bit nlink_t.
+#define CAN_INCREASE_NLINK(i) ( i->u.reiserfs_i.i_nlink_real < ((get_inode_item_key_version (inode) != KEY_FORMAT_3_5)?MAX_UL_INT:MAX_US_INT))
+
+// Compatibility stuff with old trick that allowed to have lots of subdirs in
+// one dir. Such dirs had 1 as their nlink count.
+#define INC_DIR_INODE_NLINK(i) { if (i->i_nlink != 1) INC_INODE_NLINK(i);}
+#define DEC_DIR_INODE_NLINK(i) { if (i->i_nlink != 1) DEC_INODE_NLINK(i);}
// directory item contains array of entry headers. This performs
// binary search through that array
@@ -518,7 +526,7 @@
retval = reiserfs_add_entry (&th, dir, dentry->d_name.name, dentry->d_name.len,
inode, 1/*visible*/);
if (retval) {
- inode->i_nlink--;
+ DEC_INODE_NLINK(inode);
reiserfs_update_sd (&th, inode);
pop_journal_writer(windex) ;
// FIXME: should we put iput here and have stat data deleted
@@ -569,7 +577,7 @@
retval = reiserfs_add_entry (&th, dir, dentry->d_name.name, dentry->d_name.len,
inode, 1/*visible*/);
if (retval) {
- inode->i_nlink--;
+ DEC_INODE_NLINK(inode);
reiserfs_update_sd (&th, inode);
pop_journal_writer(windex) ;
journal_end(&th, dir->i_sb, jbegin_count) ;
@@ -613,7 +621,7 @@
dentry, inode, &retval);
if (!inode) {
pop_journal_writer(windex) ;
- dir->i_nlink-- ;
+ DEC_DIR_INODE_NLINK(dir);
journal_end(&th, dir->i_sb, jbegin_count) ;
return retval;
}
@@ -627,7 +635,7 @@
retval = reiserfs_add_entry (&th, dir, dentry->d_name.name, dentry->d_name.len,
inode, 1/*visible*/);
if (retval) {
- inode->i_nlink = 0;
+ inode->u.reiserfs_i.i_nlink_real = inode->i_nlink = 0;
DEC_DIR_INODE_NLINK(dir);
reiserfs_update_sd (&th, inode);
pop_journal_writer(windex) ;
@@ -711,7 +719,7 @@
if ( inode->i_nlink != 2 && inode->i_nlink != 1 )
printk ("reiserfs_rmdir: empty directory has nlink != 2 (%d)\n", inode->i_nlink);
- inode->i_nlink = 0;
+ inode->u.reiserfs_i.i_nlink_real = inode->i_nlink = 0;
inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME;
reiserfs_update_sd (&th, inode);
@@ -780,14 +788,14 @@
if (!inode->i_nlink) {
printk("reiserfs_unlink: deleting nonexistent file (%s:%lu), %d\n",
kdevname(inode->i_dev), inode->i_ino, inode->i_nlink);
- inode->i_nlink = 1;
+ inode->u.reiserfs_i.i_nlink_real = inode->i_nlink = 1;
}
retval = reiserfs_cut_from_item (&th, &path, &(de.de_entry_key), dir, NULL, 0);
if (retval < 0)
goto end_unlink;
- inode->i_nlink--;
+ DEC_INODE_NLINK(inode);
inode->i_ctime = CURRENT_TIME;
reiserfs_update_sd (&th, inode);
@@ -868,7 +876,7 @@
retval = reiserfs_add_entry (&th, parent_dir, dentry->d_name.name, dentry->d_name.len,
inode, 1/*visible*/);
if (retval) {
- inode->i_nlink--;
+ DEC_INODE_NLINK(inode);
reiserfs_update_sd (&th, inode);
pop_journal_writer(windex) ;
journal_end(&th, parent_dir->i_sb, jbegin_count) ;
@@ -896,7 +904,7 @@
if (S_ISDIR(inode->i_mode))
return -EPERM;
- if (inode->i_nlink >= REISERFS_LINK_MAX) {
+ if (CAN_INCREASE_NLINK(inode)) {
//FIXME: sd_nlink is 32 bit for new files
return -EMLINK;
}
@@ -917,7 +925,7 @@
return retval;
}
- inode->i_nlink++;
+ INC_INODE_NLINK(inode);
ctime = CURRENT_TIME;
inode->i_ctime = ctime;
reiserfs_update_sd (&th, inode);
@@ -1157,9 +1165,9 @@
if (new_dentry_inode) {
// adjust link number of the victim
if (S_ISDIR(new_dentry_inode->i_mode)) {
- new_dentry_inode->i_nlink = 0;
+ new_dentry_inode->u.reiserfs_i.i_nlink_real = new_dentry_inode->i_nlink = 0;
} else {
- new_dentry_inode->i_nlink--;
+ DEC_INODE_NLINK(new_dentry_inode);
}
ctime = CURRENT_TIME;
new_dentry_inode->i_ctime = ctime;
===== include/linux/reiserfs_fs.h 1.22 vs edited =====
--- 1.22/include/linux/reiserfs_fs.h Tue Aug 20 13:40:53 2002
+++ edited/include/linux/reiserfs_fs.h Thu Sep 5 13:42:08 2002
@@ -1163,7 +1163,6 @@
#define INODE_PKEY(inode) ((struct key *)((inode)->u.reiserfs_i.i_key))
#define MAX_UL_INT 0xffffffff
-#define MAX_INT 0x7ffffff
#define MAX_US_INT 0xffff
// reiserfs version 2 has max offset 60 bits. Version 1 - 32 bit offset
@@ -1186,8 +1185,9 @@
#define MAX_FC_NUM MAX_US_INT
-/* the purpose is to detect overflow of an unsigned short */
-#define REISERFS_LINK_MAX (MAX_US_INT - 1000)
+/* Find maximal number, that nlink_t can hold. GCC is able to calculate this
+ value at compile time, so do not worry about extra CPU overhead. */
+#define REISERFS_LINK_MAX ((((nlink_t) -1) > 0)?~0:((1u<<(sizeof(nlink_t)*8-1))-1))
/* The following defines are used in reiserfs_insert_item and reiserfs_append_item */
===== include/linux/reiserfs_fs_i.h 1.8 vs edited =====
--- 1.8/include/linux/reiserfs_fs_i.h Fri Aug 9 19:22:34 2002
+++ edited/include/linux/reiserfs_fs_i.h Thu Sep 5 13:41:01 2002
@@ -53,6 +53,8 @@
** flushed */
unsigned long i_trans_id ;
unsigned long i_trans_index ;
+ unsigned int i_nlink_real; /* We store real nlink number since field in
+ struct inode is too short for us */
};
#endif
^ permalink raw reply
* Re: splitting the libs
From: Harald Welte @ 2002-09-05 9:44 UTC (permalink / raw)
To: John Lenton; +Cc: netfilter-devel
In-Reply-To: <20020902202834.GB29667@vialibre.org.ar>
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
On Mon, Sep 02, 2002 at 05:28:35PM -0300, John Lenton wrote:
> I compiled netfilter 1.2.6a against uclibc, and I found that
> iptables, iptables-save and iptables-restore were all about the
> same size, and while ~300k for the three of them was more or less
> ok, 300k _each_ was out of the question. I looked a bit more and
> found I could split all the functionality into .so files, and
> have the same three binaries (plus these .sos) in the same size.
>
> Is there any reason this later config isn't done by default? or
> at last enableable via the makefile?
The reason is that nobody implemented it yet and send a non-intrusive
patch :)
So if you have done it, please contribute it!
> John Lenton (john@vialibre.org.ar) -- Random fortune:
--
Live long and prosper
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: [reiserfs-dev] Re: [PATCH] sparc32: wrong type of nlink_t
From: Nikita Danilov @ 2002-09-05 9:46 UTC (permalink / raw)
To: David S. Miller
Cc: szepe, mason, reiser, shaggy, marcelo, linux-kernel,
aurora-sparc-devel, reiserfs-dev, linuxjfs, green
In-Reply-To: <20020904.224531.118542066.davem@redhat.com>
David S. Miller writes:
> From: Tomas Szepe <szepe@pinerecords.com>
> Date: Thu, 5 Sep 2002 07:48:58 +0200
>
> And a pretty straightforward one, too. Convert the internal reiserfs
> link stuff to an unsigned short, find NLINK_MAX using the code I posted
> last night (or maybe simply grab it from userspace includes) and add
> a check to your stat() code to return NLINK_MAX if necessary.
>
> Whose stat() code? These go straight to userspace via normal
> syscalls.
In 2.5 is goes through ->getattr() method.
>
> It has to be done generically, in the VFS or reiserfs.
Nikita.
^ permalink raw reply
* Re: aic7xxx sets CDR offline, how to reset?
From: Jeremy Higdon @ 2002-09-05 9:39 UTC (permalink / raw)
To: Justin T. Gibbs, James Bottomley, Alan Cox, linux-kernel,
linux-scsi
In-Reply-To: <12750000.1031158209@aslan.btc.adaptec.com>
On Sep 4, 10:50am, Justin T. Gibbs wrote:
>
> This of course assumes that all transactions have a serial number and
> that requeuing transactions orders them by serial number. With QErr
> set, the device closes the rest if the barrier race for you, but even
> without barriers, full transaction ordering is required if you don't
> want a read to inadvertantly pass a write to the same location during
> recovery.
The original FCP (SCSI commands over Fibre) profile specified that QERR=1
was not available. Unless that is changed, it would appear that you cannot
count on being able to set Qerr.
Qerr was one of those annoying little things in SCSI that forces host
adapter drivers to know a mode page setting.
jeremy
^ permalink raw reply
* RE: transparent proxy whith DNAT
From: MOUDARIR Mohamed @ 2002-09-05 9:35 UTC (permalink / raw)
To: netfilter
Hello,
I find why the proxy respond this error,
Think you for your help,
In fact there is a missing config line in my squid.conf,
The important parameters that should be able are:
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Now, it work fine.
BTW, what is the more efficace and fast :
iptables -t nat -A PREROUTING -i $int_iface -s ! $int_ip -p tcp
--dport 80 -j DNAT --to $int_ip:3128
OR
$IPTABLES -t nat -A PREROUTING -i $int_iface -p tcp --dport 80 -j
REDIRECT --to-port 3128
Best regards.
^ permalink raw reply
* Re: 64-bit and N32 kernel interfaces
From: Tor Arntsen @ 2002-09-05 9:30 UTC (permalink / raw)
To: Maciej W. Rozycki, Carsten Langgaard; +Cc: Ralf Baechle, linux-mips
On Sep 5, 10:23, "Maciej W. Rozycki" wrote:
>On Thu, 5 Sep 2002, Carsten Langgaard wrote:
[...]
>> Please notice, that a 'long' is 32-bit for n32, so we need to do the same
>> conversion for a lot of syscalls, as we already do for o32.
>
> Any reference? AFAIK, long is 64-bit for n32 and only void * is 32-bit.
>It doesn't make sense otherwise.
On SGI/Irix n32 long and void* are 32-bit, only long long is 64-bit.
On SGI/Irix n64 long and void* are 64-bit too.
-Tor
^ permalink raw reply
* Dual Athlon XP hangs using tar
From: Chris Newland @ 2002-09-05 9:27 UTC (permalink / raw)
To: Linux-Smp
[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]
Hi All,
Hardware:
MSI K7D-Master motherboard (supports multiprocessing using Athlon XP CPUs)
2 * AMD Athlon XP 1900+
1 * 512MB PC2100 ECC Registered DDR (Crucial)
Promise Fasttrak TX2000 ATA133 RAID controller
2 * Seagate Barracuda IV 80GB (In RAID 0 stripe configuration)
ATI Radeon 8500LE 128MB AGP4X
10/100 PCI Network card (Realtek)
431W Enermax PSU
Software:
SuSE 8.0 (all rpms updated using SuSE online update)
2.4.18-64GB-SMP kernel (out of the box, not custom)
Reiser filing system
Promise RAID drivers for SuSE 8.0
BIOS Settings:
MP mode 1.1
All APIC settings disabled
dmesg output: attached to email
Problem:
Whenever I try and untar a large tar archive (about 100MB to 500MB not
gzipped) using tar -xf <file> the machine will either hang completely
(keyboard and mouse inoperative) or tar will exit with an error message and
then any further commands I execute will say "program not found" and the
machine will hang 3 or 4 commands later.
I have run memtest86 version 3.0 for over 24 hours straight without a single
memory error. I can run the machine quite happily at high load for hours (2
SETI processes maxing out both CPUs) without any problems. The problem has
only been seen so far when untarring.
The tar files were created on a Pentium 133 running the same version of SuSE
and were transferred using scp (secure copy protocol). I am sure they are
not corrupt because occasionally I can unpack them correctly but mostly they
will hang the machine.
Do you think this could be an SMP problem?
I don't believe it is because they are Athlon XP instead of Athlon MP since
they run stable under high load in Windows 2000 and with any other Linux
programs.
AFAIK, the 1900+ XP is identical silicon to the 1900+ MP but undergoes less
factory testing.
Would upgrading to a later kernel help?
I have seen the problem with and without using the RAID controller so I
don't believe that is the problem.
The reiser errors seen in the attached dmesg output were caused by having to
press the reset button when the machine hung. I have had to do a clean
install several times now due to filesystem corruption caused by these
hangs.
Can anyone help?
Best Regards,
Chris Newland
[-- Attachment #2: boot.message --]
[-- Type: application/octet-stream, Size: 13430 bytes --]
Linux version 2.4.18-64GB-SMP (root@SMP_X86.suse.de) (gcc version 2.95.3 20010315 (SuSE)) #1 SMP Wed Mar 27 13:58:12 UTC 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Scanning bios EBDA for MXT signature
found SMP MP-table at 000f4af0
hm, page 000f4000 reserved twice.
hm, page 000f5000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 131072
zone(0): 4096 pages.
zone(1): 126976 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 Pentium(tm) Pro APIC version 17
Processor #1 Pentium(tm) Pro APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 2
Building zonelist for node : 0
Kernel command line: auto BOOT_IMAGE=linux ro root=803 apm=off acpi=off ide0=0x1f0,0x3f6,14 ide1=0x170,0x376,15 ide2=0 ide3=0 ide4=0 ide5=0 ide6=0 ide7=0 ide8=0 ide9=0
ide_setup: ide0=0x1f0,0x3f6,14
ide_setup: ide1=0x170,0x376,15
ide_setup: ide2=0
ide_setup: ide3=0
ide_setup: ide4=0
ide_setup: ide5=0
ide_setup: ide6=0
ide_setup: ide7=0
ide_setup: ide8=0
ide_setup: ide9=0
Initializing CPU#0
Detected 1600.101 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 3191.60 BogoMIPS
Memory: 512368k/524288k available (1504k kernel code, 11536k reserved, 429k data, 144k init, 0k highmem)
Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0383fbff c1cbfbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0383fbff c1cbfbff 00000000 00000000
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000
CPU0: AMD Athlon(tm) MP 1900+ stepping 02
per-CPU timeslice cutoff: 731.19 usecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 3198.15 BogoMIPS
CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0383fbff c1cbfbff 00000000 00000000
Intel machine check reporting enabled on CPU#1.
CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000
CPU1: AMD Athlon(tm) MP stepping 02
Total of 2 processors activated (6389.76 BogoMIPS).
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-12, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00170011
....... : max redirection entries: 0017
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 003 03 0 0 0 0 0 1 1 39
02 003 03 0 0 0 0 0 1 1 31
03 003 03 0 0 0 0 0 1 1 41
04 003 03 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 003 03 0 0 0 0 0 1 1 51
07 003 03 0 0 0 0 0 1 1 59
08 003 03 0 0 0 0 0 1 1 61
09 003 03 0 0 0 0 0 1 1 69
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 003 03 0 0 0 0 0 1 1 71
0e 003 03 0 0 0 0 0 1 1 79
0f 003 03 0 0 0 0 0 1 1 81
10 003 03 1 1 0 1 0 1 1 89
11 003 03 1 1 0 1 0 1 1 91
12 003 03 1 1 0 1 0 1 1 99
13 003 03 1 1 0 1 0 1 1 A1
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:18
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:16
IRQ11 -> 0:17
IRQ12 -> 0:19
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1600.0655 MHz.
..... host bus clock speed is 266.6774 MHz.
cpu: 0, clocks: 2666774, slice: 888924
CPU0<T0:2666768,T1:1777840,D:4,S:888924,C:2666774>
cpu: 1, clocks: 2666774, slice: 888924
CPU1<T0:2666768,T1:888912,D:8,S:888924,C:2666774>
checking TSC synchronization across CPUs: passed.
Waiting on wait_init_idle (map = 0x2)
All processors have done init_idle
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs
PCI: PCI BIOS revision 2.10 entry at 0xfb130, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router default [1022/700c] at 00:00.0
BIOS failed to enable PCI standards compliance, fixing this error.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16)
apm: disabled on user request.
mxt_scan_bios: enter
Starting kswapd
kinoded started
VFS: Diskquotas version dquot_6.5.0 initialized
ACPI: disabled by cmdline, exiting
vesafb: framebuffer at 0xe0000000, mapped to 0xe080d000, size 131072k
vesafb: mode is 1024x768x16, linelength=2048, pages=84
vesafb: protected mode interface info at c000:5520
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Looking for splash picture... no good signature found.
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI SERIAL_ACPI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10e
block: 128 slots per queue, batch=32
RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD_IDE: IDE controller on PCI bus 00 dev 39
AMD_IDE: chipset revision 4
AMD_IDE: not 100% native mode: will probe irqs later
AMD_IDE: AMD-768 Opus (rev 04) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xb008-0xb00f, BIOS settings: hdc:pio, hdd:pio
hda: LITEON DVD-ROM LTD163D, ATAPI CD/DVD-ROM drive
hdb: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
ide2: ports already in use, skipping probe
ide3: ports already in use, skipping probe
ide4: ports already in use, skipping probe
ide5: ports already in use, skipping probe
ide6: ports already in use, skipping probe
ide7: ports already in use, skipping probe
ide8: ports already in use, skipping probe
ide9: ports already in use, skipping probe
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: no flushcache support
hda: ATAPI 48X DVD-ROM drive, 512kB Cache
Uniform CD-ROM driver Revision: 3.12
ide-floppy driver 0.99
hdb: no flushcache support
hdb: No disk in drive
hdb: 98304kB, 96/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 16 devices)
Cronyx Ltd, Synchronous PPP and CISCO HDLC (c) 1994
Linux port (c) 1998 Building Number Three Ltd & Jan "Yenya" Kasprzak.
ide-floppy driver 0.99
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 131072 bind 65536)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Uncompressing.............done.
Freeing initrd memory: 585k freed
VFS: Mounted root (ext2 filesystem).
PROMISE FastTrak Series Linux Driver Version 1.02.0.22
scsi0 : FastTrak
Vendor: Promise Model: 2+0 Stripe/RAID0 Rev: 1.10
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 312602624 512-byte hdwr sectors (160053 MB)
Partition check:
sda: sda1 sda2 sda3 sda4
fasttrak_ioctl not support the fun (0x5310).
reiserfs: checking transaction log (device 08:03) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
change_root: old root has d_count=2
Trying to unmount old root ... okay
Freeing unused kernel memory: 144k freed
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
LVM version 1.0.3(19/02/2002) module loaded
Adding Swap: 1028152k swap-space (priority 42)
reiserfs: checking transaction log (device 08:04) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
8139too Fast Ethernet driver 0.9.24
eth0: SMC1211TX EZCard 10/100 (RealTek RTL8139) at 0xe89f7000, 00:10:b5:a0:30:90, IRQ 10
eth0: Identified 8139 chip type 'RTL-8139B'
eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1.
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.275 $ time 14:22:59 Mar 27 2002
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
uhci.c: USB Universal Host Controller Interface driver v1.1
usb-ohci.c: USB OHCI at membase 0xe89f9000, IRQ 5
usb-ohci.c: usb-02:06.0, PCI device 1033:0035
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 3 ports detected
usb-ohci.c: USB OHCI at membase 0xe89fb000, IRQ 12
usb-ohci.c: usb-02:06.1, PCI device 1033:0035
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
hub.c: USB new device connect on bus1/1, assigned device number 2
usb.c: USB device 2 (vend/prod 0x45e/0x1e) is not claimed by any active driver.
usb.c: registered new driver hiddev
usb.c: registered new driver hid
input0: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse® Explorer] on usb1:2.0
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
hub.c: USB new device connect on bus2/1, assigned device number 2
hub.c: USB hub found
hub.c: 4 ports detected
is_tree_node: node level 62578 does not match to the expected one 1
vs-5150: search_by_key: invalid format found in block 32400. Fsck?
is_tree_node: node level 62578 does not match to the expected one 1
vs-5150: search_by_key: invalid format found in block 32400. Fsck?
vs-5657: reiserfs_do_truncate: i/o failure occurred trying to truncate [18 22178 0xfffffffffffffff DIRECT]
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
IPv6 v0.8 for NET4.0
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present
^ permalink raw reply
* Re: Scheduler, or task priority problem ... i need help
From: David Woodhouse @ 2002-09-05 9:24 UTC (permalink / raw)
To: Thomas TESTASECCA; +Cc: Mtd
In-Reply-To: <AEEFILJDOOHJLBCFOBJDIEIJDAAA.thomas.testasecca@etictelecom.com>
thomas.testasecca@etictelecom.com said:
> When i upload (by ftp) a file into the jffs2 (for a 200kByte file it
> takes approx 40s) during the upload time the pure-ftpd process really
> loads the system, and my WD task, doesn't run anymore until the end of
> the upload.
That should be fixed in the current CVS code. Can you try it?
I suppose there's something to be said for backporting the cond_resched()
additions to the 2.4 tree too.
--
dwmw2
^ permalink raw reply
* Re: 64-bit and N32 kernel interfaces
From: Maciej W. Rozycki @ 2002-09-05 9:23 UTC (permalink / raw)
To: Carsten Langgaard; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <3D76FC6B.C9AA72F3@mips.com>
On Thu, 5 Sep 2002, Carsten Langgaard wrote:
> > The (n)64 versions seem suitable and the o32 ones do not as n32 only
> > crops addresses to 32-bit -- data may still be 64-bit (e.g. file position
> > pointers).
>
> Please notice, that a 'long' is 32-bit for n32, so we need to do the same
> conversion for a lot of syscalls, as we already do for o32.
Any reference? AFAIK, long is 64-bit for n32 and only void * is 32-bit.
It doesn't make sense otherwise.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Automount oops - who to report to?
From: Ian Chard @ 2002-09-05 9:26 UTC (permalink / raw)
To: linux-kernel
Hi,
Sorry for mailing so generically, but I have a recurring problem with
autofs
hanging and oopsing, and I can't figure out who the maintainer of this
bit of
the kernel is. Can you point me in the right direction?
Many thanks
- Ian
--
Ian Chard, Unix Systems Administrator x5019 Email:
<ichard@cadence.com>
European IT, Cadence Design Systems Ltd Phone: +44 (0)1506
595019
The Alba Campus, Livingston, Scotland EH54 7HH Mobile: +44 (0)7901
855073
^ permalink raw reply
* Re: Interrupt handling....
From: Maciej W. Rozycki @ 2002-09-05 9:17 UTC (permalink / raw)
To: Dominic Sweetman; +Cc: Matthew Dharm, Jun Sun, Linux-MIPS
In-Reply-To: <200209042008.VAA25407@mudchute.algor.co.uk>
On Wed, 4 Sep 2002, Dominic Sweetman wrote:
> Well, next time, get your board designers to think before they map...
>
> It's generally better to map some DRAM low (for boot ROMs and other
> stupid programs you don't want to make big-address aware), then remap
> the whole DRAM to some very high address for Linux. Much better than
> forcing you to use the TLB (or XKPHYS, if you've a 64-bit CPU) to get
> at I/O.
Hmm, what's the deal? Other processors always use MMU to access iomem...
> Bear in mind that there *isn't a 64-bit mode*. Privileged code (which
> is everything except Linux applications) can always run 64-bit
> instructions; all addresses are 64-bits really, it's just the
> sign-extension of the registers which makes you think you've got
> 32-bit pointers. Usually a 64-bit CPU can access XKPHYS any time
> it can access I/O registers.
Well, it's mostly a programming convention. Without going into details,
arch/mips is the 32-bit mode and arch/mips64 is the 64-bit one. The usual
approximation is the state of cp0.kx, even though 64-bit operations do
indeed work when ~cp0.kx.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: [PATCH] Important per-cpu fix.
From: William Lee Irwin III @ 2002-09-05 9:09 UTC (permalink / raw)
To: Dipankar Sarma
Cc: rusty, Linus Torvalds, Andrew Morton, Dave Miller, linux-kernel
In-Reply-To: <20020905144023.A14040@in.ibm.com>
> In article <20020904023535.73D922C12D@lists.samba.org> Rusty Russell wrote:
>> This might explain the wierd per-cpu problem reports from Andrew and
>> Dave, and also that nagging feeling that I'm an idiot...
On Thu, Sep 05, 2002 at 02:40:23PM +0530, Dipankar Sarma wrote:
> Not only does this fix the tasklet BUG with 2.5.32 but it also fixes a serial
> console hang with my 2.5.32 version of Ingo/Davem/Alexey's scalable timers
> code that I have been debugging for the last two days. I use
> a per-cpu tasklet to run the timers, so it was probably killing me
> there.
Are you running on NUMA-Q? Do you also see the tty deadlock?
Thanks,
Bill
^ permalink raw reply
* Re: [BUG] __write_lock_failed() oops
From: William Lee Irwin III @ 2002-09-05 9:08 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
In-Reply-To: <20020905084502.GD888@holomorphy.com>
On Thu, Sep 05, 2002 at 01:42:52AM -0700, Andrew Morton wrote:
>>> That's all the assembly hacks in the rwlock code not having proper
>>> stack frames. You may have to ksymoops it.
>> At a guess: use-after-free bug against an address_space. You may
>>> be able to catch it with slab poisoning.
> On Thu, Sep 05, 2002 at 01:32:40AM -0700, William Lee Irwin III wrote:
>> (gdb) p/x $eax
>> $25 = 0xc0331ca0
>> (gdb) p &tasklist_lock
>> $27 = (rwlock_t *) 0xc0331ca0
On Thu, Sep 05, 2002 at 01:45:02AM -0700, William Lee Irwin III wrote:
> The NMI oopser is going here as well (nmi_watchdog=2 for extra safety)
> so I suspect the tasklist_lock semantics are behaving badly. But it's
> not easily reproducible enough to test a quick attempt at a fix if it
> can't be recognized a priori.
> This is literally so difficult to reproduce it hasn't been seen in 2
> releases. kgdb is still going and dhowells is helping me fish stuff
> off the stack.
Here is the IRC log of the analysis. I'm leaving the machine untouched
so kgdb may be used later on if facts are called into question.
Cheers,
Bill
<wli> $3 = 0xc0331ca0
<wli> (gdb) p/x *(unsigned long *)$eax
<wli> $4 = 0xffffff
<dhowells> unless the code itself is corrupted
<dhowells> it looks reasonable
<wli> what else should I look for?
<wli> Could the NMI oopser possibly oops it in this situation?
<dhowells> what's the oops say at the beginning?
<dhowells> ad which insn did it oops on?
<dhowells> s/ad/and/
<wli> dhowells: I was running kgdb:
<wli> Program received signal SIGSEGV, Segmentation fault.
--> tkks (~kes@rrcs-se-24-129-177-178.biz.rr.com) has joined #kernel
<wli> 0xc0106693 in __write_lock_failed () at semaphore.c:176
<wli> 176 semaphore.c: No such file or directory.
<wli> in semaphore.c
<wli> 0xc0106693 <__write_lock_failed+15>:
<wli> jne 0xc010668b <__write_lock_failed+7>
<dhowells> it oopsed on _jne_?
<wli> dhowells: NFI -- this is all I see.
<wli> dhowells: I've stared at this several times in the past.
<dhowells> load the vmlinux file into gdb and do "disas 0xc0106693"
<wli> dhowells: it matches
--> benh (~benh@m86.net195-132-236.noos.fr) has joined #kernel
<dhowells> do you still have kgdb attached to the dying box?
<-- daniel has quit (Ping timeout: 604 seconds)
<dhowells> if so, dump the bytes at that address, and make sure they're the same as in the vmlinux file
<wli> dhowells: that's where it got it from in the first place -- it's preloaded into gdb
<wli> (gdb) p/x (unsigned char [4])0xc0106693
<wli> $10 = {0x93, 0x66, 0x10, 0xc0}
<wli> dhowells: yes
<dhowells> that didn't work
<dhowells> those four bytes are the address
<wli> (gdb) p/x (unsigned char [4])0xc0106693
<wli> $1 = {0x93, 0x66, 0x10, 0xc0}
<dhowells> p/x (unsigned char [4])*(char*)0xc0106693
<dhowells> or just p/x *(int*)0xc0106693
<wli> kgdb:
<wli> (gdb) p/x (unsigned char [4])*(char*)0xc0106693
<wli> $11 = {0x75, 0xf6, 0xf0, 0x81}
<wli> vmlinux:
<wli> (gdb) p/x (unsigned char [4])*(char*)0xc0106693
<wli> $2 = {0x75, 0xf6, 0xf0, 0x81}
<dhowells> guess so then
<dhowells> hmmm... on mine, I see:
<dhowells> (gdb) p/x (char[4])*(char*)0xc01067c8
<dhowells> $2 = {0xf, 0x85, 0xe2, 0xff}
<dhowells> which should also be a jne:-/
<wli> this is for the jne is __write_lock_failed()?
<dhowells> yes
<wli> What does mine reassemble to?
* dhowells fires up his I386 insn pdf
<dhowells> yours is right
* viro looks at axboe
<wli> ugh
<wli> dhowells: what are the odds it's an NMI oops?
<dhowells> and so is mine
<dhowells> can you access the printk buffer?
<wli> dhowells: (gdb) p log_buf
<wli> $3 = '\0' <repeats 65535 times>
<dhowells> the difference between your disas and mine are JNE rel8 vs JNE rel32
--- dwmw2_gone is now known as dwmw2
<dhowells> wli: p (char*)&log_buf
<dhowells> is that what you did?
<wli> (gdb) p (char*)&log_buf
<wli> $4 = 0xc034cb40 ""
<wli> (no
<wli> What are the odds it's the NMI oopser?
<dhowells> try p (char[256])log_buf
<dhowells> it might be an NMI, I'm just wondering how to tell
<dhowells> wli: what you need to do is to examine the irq_stat[] array
<wli> (gdb) p log_buf
<wli> p/x log_buf
<wli> $12 = "01 (tiotest).\n<3>Out of Memory: Killed process 8902 (tiotest).\n<3>Out of Memory: Killed process 8916 (tiotest).\n<3>Out of Memory: Killed process 8917 (tiotest).\n<3>Out of Memory: Killed process 8918 ("...
<dhowells> or that might be the problem
<dhowells> p/x (unsigned[5])irq_stat
<wli> (gdb) p/x irq_stat[((struct thread_info *)((unsigned long)$esp & ~8191UL))->cpu]
<wli> $19 = {__softirq_pending = 0x0, __syscall_count = 0x0,
<wli> __ksoftirqd_task = 0xcd1adaa0, idle_timestamp = 0xe1ef9f,
<wli> __nmi_count = 0xacd8c3}
<dhowells> did you compile with -g?
<wli> yes
<wli> kgdb implies -g and frame pointers
<dhowells> what about p irq_stat[0]
<wli> (gdb) p irq_stat[0]
<wli> $20 = {__softirq_pending = 0, __syscall_count = 0,
<wli> __ksoftirqd_task = 0xcd1df460, idle_timestamp = 14807014,
<wli> __nmi_count = 12196773}
<dhowells> and again?
<wli> again for what?
<dhowells> do the command again (and watch __nmi_count)
<wli> (gdb)
<wli> $21 = {__softirq_pending = 0, __syscall_count = 0,
<wli> __ksoftirqd_task = 0xcd1df460, idle_timestamp = 14807014,
<wli> __nmi_count = 12196773}
<dhowells> how many CPUs do you have?
<wli> dhowells: it oopsed on cpu 7
<wli> dhowells: 16
* dhowells hates wli
<wli> dhowells: 32 doesn't boot yet, the ioredtbl's are FITH
<wli> dhowells: 48 is beyond my power by several orders of magnitude.
--> kai_ (~kai@pppoe79.swhBachemerstr.Uni-Koeln.DE) has joined #kernel
<wli> dhowells: 64 and I have to borrow quads from another group and figure out the APIC ID remapping trick.
<dhowells> the value in __nmi_count looks weird
* dhowells really hates wli
<wli> dhowells: I will be your testmonkey if you care to debug. =)
* dhowells grins
<dhowells> what's the __nmi_count on cpu7?
<wli> dhowells: 32 can be brought up in 15 minutes or so, maybe 30, depending on how slow the console is.
<wli> (gdb) p irq_stat[7]
<wli> $24 = {__softirq_pending = 0, __syscall_count = 0,
<wli> __ksoftirqd_task = 0xcd1adaa0, idle_timestamp = 14806943,
<wli> __nmi_count = 11327683}
<dhowells> what's p log_end-(u_long)&log_bug
<wli> (gdb) p/x $eax
<wli> $25 = 0xc0331ca0
<wli> (gdb) p &tasklist_lock
<wli> $27 = (rwlock_t *) 0xc0331ca0
<dhowells> you could try p (char[256])*(char*)(log_end-256)
<wli> (gdb) p (char[256])*(char*)(log_end-256)
<wli> Cannot access memory at address 0x284d9
<dhowells> try p log_end
<wli> #kernel> dhowells: 32 doesn't boot yet, the ioredtbl's are FITH
<wli> #kernel> dhowells: 48 is beyond my power by several orders of magnitude.
<wli> *** kai_ (~kai@pppoe79.swhBachemerstr.Uni-Koeln.DE) has joined channel #kernel
<wli> #kernel> dhowells: 64 and I have to borrow quads from another group and figure
<wli> +out the APIC ID remapping trick.
<wli> <dhowells:#kernel> the value in __nmi_count looks weird
<wli> * dhowells:#kernel really hates wli
<wli> #kernel> dhowells: I will be your testmonkey if you care to debug. =)
<wli> * dhowells:#kernel grins
<wli> <dhowells:#kernel> what's the __nmi_count on cpu7?
<wli> argh
<dhowells> try p (char[256])*(char*)(log_buf+log_end-256)
<wli> sorry
<wli> (gdb) p log_end
<wli> $28 = 165337
<wli> (gdb) p (char[256])*(char*)(log_buf+log_end-256)
<wli> $29 = '\0' <repeats 255 times>
<dhowells> try p (char[256])*(char*)(log_buf+(log_end&65535)-256)
<dhowells> log_end needs masking
<wli> (gdb) p (char[256])*(char*)(log_buf+(log_end&65535)-256)
<wli> $30 = "(tiotest).\n<3>Out of Memory: Killed process 9741 (tiotest).\n<3>Out of Memory: Killed process 9743 (tiotest).\n<3>Out of Memory: Killed process 9744 (tiotest).\n<3>Out of Memory: Killed process 9745 (tio"...
<dhowells> hmmm
<dhowells> no obvious oops... but it may have been overwritten
<dhowells> :-/
<wli> tasklist_lock smells of NMI oopsing.
<wli> tasklist_lock hold/wait times are beyond ridiculous and into the realm of flat-out bugginess.
<dhowells> yeah... I think I have to agree
<wli> The tasklist_lock is basically a bug.
<dhowells> can you use some sort of serial console or net console?
<wli> I am using a serial console.
<dhowells> well, if there was an oops, you should've seen it fly past on that
<wli> dhowells: kgdb traps the oops before it comes out there -- this is very difficult to reproduce, so...
<wli> it's more or less "take the one shot we've got or wait a month before it happens again"
<dhowells> so the oops is still pending?
<wli> dhowells: it's been pending since NUMA-Q starting booting again around 2.5.20.
<dhowells> I mean in your current kgdb session
<wli> yes
****
<dhowells> then you should be able to track back up the stack and locate it
<wli> dhowells: I'
<dhowells> do_nmi+N ought to be on the stack
<wli> dhowells: I'm enough sheets to the wind it might take me a few tries to get it right. Can you give me a gdb command to dump out?
<dhowells> do you know what ESP is on the dead task/CPU?
<wli> dhowells: $esp produces what appears to be a proper result.
<dhowells> p $ESP
<wli> (gdb) p $esp
<wli> $38 = (void *) 0xe3dfbf54
<dhowells> (gdb) p/x (0xe3dfbf54 & 0xffffe000) + 0x2000 - 0xe3dfbf54
<dhowells> $4 = 0xac
<dhowells> that's how much stack space is used
<wli> Is that good or bad?
--> andre (~andre@astound-64-85-224-253.ca.astound.net) has joined #kernel
<dhowells> wait
<dhowells> p (void*[0xac/4])*(void**)$esp
<wli> Got a stack-dumping command for me?
<wli> (gdb) p (void*[0xac/4])*(void**)$esp
<wli> A parse error in expression, near `4])*(void**)$esp'.
<dhowells> p (void*[43])*(void**)$esp
<wli> (gdb) p (void*[43])*(void**)$esp
<wli> $39 = {0xc0119011, 0xb89ffbf8, 0xf21, 0xb89ffd24, 0xfffffff2, 0xe3dfbfa0,
<wli> 0xc0118e95, 0xf21, 0xb89ffbf8, 0xe3dfbfc4, 0x0, 0xb89ffc00, 0xe3dfa000, 0x0,
<wli> 0x100070, 0xe3dfa000, 0xb8800000, 0x200000, 0xe3dfa000, 0xe3dfbfbc,
<wli> 0xc0105e39, 0xf21, 0xb89ffbf8, 0xe3dfbfc4, 0x0, 0xb89ffc00, 0x805e2ac,
<wli> 0xc010788f, 0xf21, 0xb89ffbf8, 0xb89ffc00, 0x0, 0xb89ffd24, 0x805e2ac, 0x78,
<wli> 0xc010002b, 0x2b, 0x78, 0x400fa8de, 0x23, 0x292, 0x805e25c, 0x2b}
<dhowells> p do_nmi
<wli> (gdb) p do_nmi
<wli> $40 = {void (struct pt_regs *, long int)} 0xc01090d0 <do_nmi>
<dhowells> i sym 0xc0119011
<dhowells> i sym 0xc0118e95
<dhowells> i sym 0xc0105e39
<wli> (gdb) i sym 0xc0118e95
<wli> do_fork + 33 in section .text
<hch> morning
<dhowells> i sym 0xc010788f
<wli> (gdb) i sym 0xc0119011
<wli> Letext + 191 in section .text
<dhowells> i sym 0xc010002b
<dhowells> hch: morning
<wli> (gdb) i sym 0xc0105e39
<wli> sys_clone + 37 in section .text
<wli> (gdb) i sym 0xc010788f
<wli> syscall_call + 7 in section .text
<dhowells> wli: okay... the exception hasn't appeared on the stack there... it's the other side of the $esp value
<wli> (gdb) i sym 0xc010002b
<wli> startup_32 + 43 in section .text
<wli> dhowells: anything you can tell me is good
<dhowells> p (void*[43])*(void**)($esp-0xac)
<wli> (gdb) p (void*[43])*(void**)($esp-0xac)
<wli> $41 = {0xe3dfbf54, 0xe3dfbf68, 0xf21, 0xb89ffd24, 0xc0106693, 0x87, 0x60,
<wli> 0x68, 0xc0110068, 0x68, 0xffff, 0xffff, 0xe3dfbefc, 0xc0111cb0, 0x2, 0xb,
<wli> 0x0, 0xe3dfbf20, 0xc0d06425, 0xe3dfbf20, 0xb89ffd24, 0xe3dfbf10, 0xc010911b,
<wli> 0xe3dfbf20, 0xc0d06400, 0xf21, 0xe3dfbf68, 0xc0108356, 0xe3dfbf20, 0x0,
<wli> 0xc0d06400, 0x0, 0xe3dfa000, 0xf21, 0xb89ffd24, 0xe3dfbf68, 0xc0331ca0,
<wli> 0xc0110068, 0x68, 0xc0331ca0, 0xc0106693, 0x60, 0x87}
<dhowells> i sym 0xc010911b
<wli> (gdb) i sym 0xc010911b
<wli> do_nmi + 75 in section .text
* dhowells grins
<dhowells> disas 0xc010911b
<dhowells> what's that instruction? a call somewhere?
<wli> 0xc0109116 <do_nmi+70>: call 0xc0111bc4 <nmi_watchdog_tick>
<wli> 0xc010911b <do_nmi+75>: jmp 0xc01091b2 <do_nmi+226>
<wli> 0xc0109120 <do_nmi+80>: push %esi
<wli> 0xc0109121 <do_nmi+81>: movzbl %bl,%eax
<wli> 0xc0109124 <do_nmi+84>: push %eax
<dhowells> does that answer your questions?
<wli> 0xc01091b0 <do_nmi+224>: in $0x71,%al
<wli> 0xc01091b2 <do_nmi+226>: lea 0xfffffff8(%ebp),%esp
<wli> 0xc01091b5 <do_nmi+229>: pop %ebx
<wli> It's an NMI oops.
<dhowells> NMI went off whilst do_fork was spinning on the tasklist_lock
<dhowells> wli: you might also want to note the technique I used for finding it
<wli> dhowells: noted
<dhowells> wli: have fun
<wli> dhowells: I will FTSO the tasklist_lock and the bloody fscking tasklist to boot.
* dhowells grins
<hch> hmm, I should have stayed up longer yesterday
<wli> dhowells: Have you logged it?
<hch> and sent linus the patch
<dhowells> I thought I'd leave that to you
<dhowells> why, do you want me to?
<wli> dhowells: I'm too many sheets to the wind, can you mail me the log?
<dhowells> the log of the xchat session?
<wli> dhowells: I'll settle for that sure.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.