Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Andre Hedrick]

On Fri, 24 Nov 2000, Alexander Viro wrote:

>  I don't see any attempts to tag you (or ATA subsystem, for that matter)
> in that thread. And thread is hardly bogus... I agree that changes in

We agree that the "thread" is valid, trust that point.
There was a quick pointed question that present, "Is it an IDE disk?" to
paraphase the statement.

> drivers/ide/* are very unlikely to be the source of that, but information
> of that kind can help to weed out some of the changes in ll_rw_blk.c.

What may be even more helpful is when I get arround to making an option, 
for some outstanding patches for 2.5, that would allow for user-space
pattern pushing through the driver that gets properly inserted in to the
list/buffer-head to make it pass through the block layer.  This kind of
testing will allow for nibble level tracing through everything, I hope.

Cheers,

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

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

vm in 2.2.18pre23 - behaving worse

[Michal Jaegermann]

I was busy with other things and did not track 2.2.18pre kernels very
carefuly, but now I tried 2.2.18pre23 on Alpha and got an impression
that a situation with a virtual memory handling is worse than it was,
say, in 2.2.18pre15.  I can now see in /var/log/messages entries like
"VM: killing process sh" or "VM: killing process emacs" because I was
compiling a kernel.  This does not happen consistently, predictably, or
very often but it does happen and I should not be oom.  Nothing else
crashes, or leaves any traces in log files, and a machine continues
apparently not disturbed, but a process is gone.

Applying patches from Andrea and the one from Rik, posted some week
ago under "blindingly stupid 2.2 VM bug" subject, does not seem
to help very much.  Sigh!

Am I isolated in this experience?

  Michal

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

Re: [PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1

[Michael Elkins]

On Thu, Nov 23, 2000 at 06:06:31PM -0500, Jeff Garzik wrote:
> Michael Elkins wrote:
> > 
> > On Thu, Nov 23, 2000 at 05:49:52PM +0100, Georg Acher wrote:
> > It hangs in start_uhci():
> > 
> > /* disable legacy emulation */
> > pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);
> > 
> > The loop that the call is in gets iterated 5 times.  For i < 4, the
> > if (!(dev->resource[i].flags & 1))
> > is TRUE, but on i==4, it drops into the bottom of the loop to execute
> > check_region() and then pci_write_config_word(), where it hangs.
> 
> It may not make a difference, but that check is flat out wrong.

The loop still exhibits the same behavior.

/usr/include/linux/ioport.h:#define IORESOURCE_IO   0x0100 /* Resource 
type */

Definitely a different value, however.

> Apply this patch...  (untested, you may need to include ioport.h)

fyi, ioport.h isn't required.

On Thu, Nov 23, 2000 at 03:53:27PM -0800, Linus Torvalds wrote:
> Try changing the thing around a bit: make the above place say
> 
>   /* disable legacy emulation */
>   pci_write_config_word (dev, USBLEGSUP, 0);
> 
> and then AFTER we have successfully done a request_irq() call, we 
> can enable PCI interrupts with
> 
>   /* Enable PIRQ */
>   pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);
> 
> Does that make it happier?

Yep! That seems to have fixed it.  Added the pci_write_config_word() after
the request_irq() in alloc_uhci().

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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Alexander Viro]

On Thu, 23 Nov 2000, Andre Hedrick wrote:

[I wrote]
> > ?
> > If you have a l-k feed from future - please share. I'm not saying that
> 
> Date: Thu, 23 Nov 2000 04:37:21 -0500 (EST)
> 
> > fs/* is not the source of that stuff, but I sure as hell had not said
> > that it is. I simply don't know yet.
> 
> You were pointing out changes to reproduce the effect.

Erm... Since then the problem had been reproduced on the patched tree, so
we apparently have something else. Behaviour on disk/quota overflow is
a separate story - even with fixes for that problem stays.

> > > Since there have been not kernel changes to the driver that effect the
> > > code since 2.4.0-test5 or test6 and it now randomly shows up after five or
> > > six revisions out from the change, and the changes were chipset only.
> > 
> > generic_unplug_device() was changed more or less recently. I doubt that
> > it is relevant, but...
> 
> Cool, the issue was that I get tried of people blaming the ATA subsystem
> for things that it does not do or has control over.  Basically, I kill
> bogus threads that try to tag me with an old problem of the past that was
> a hardware issue.

 I don't see any attempts to tag you (or ATA subsystem, for that matter)
in that thread. And thread is hardly bogus... I agree that changes in
drivers/ide/* are very unlikely to be the source of that, but information
of that kind can help to weed out some of the changes in ll_rw_blk.c.

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

Re: gcc-2.95.2-51 is buggy

[Alexander Viro]

On Fri, 24 Nov 2000, Neil Brown wrote:

> Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the same
> bug.
> Debian applies a total of 49 patches to gcc and the libraries.
> 
> I am tempted to write a little script which discards the patches one
> by one and re-builds and re-tests each time, and leave it going all
> night but I'm not sure if I actually will.

Not all of them are applied on x86:
%  cat stamps/02-patch-stamp-*|less
bootstrap patches applied.
cpp-dos-newlines patches applied.
cpp-macro-doc patches applied.
gcc-cvs-updates-2220 patches applied.
gcc-default-arch patches applied.
gcc-empty-struct-init patches applied.
gcc-manpage patches applied.
gcc-pointer-arith patches applied.
gcj-debian-policy patches applied.
gcj-vs-iconv patches applied.
gpc-2.95 patches applied.
gpc-updates patches applied.
libg++-update patches applied.
libobjc patches applied.
libstdc++-bastring patches applied.
libstdc++-out-of-mem patches applied.
libstdc++-wall3 patches applied.
libstdc++-wstring patches applied.
reporting patches applied.

And only 4 have any chance to be relevant: gcc-cvs-updates-2220,
gcc-default-arch, gcc-empty-struct-init. Unfortunately, the first one
is ~100Kb worth of changes. Hmmm... After some cleaning the whole thing
boils down to 11Kb. And I seriously suspect that relevant bits are
in cse.c, loop.c or toplev.c, with the first two being the most likely
candidates (all coming from the -cvs-updates-2220)...

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

Re: 2.2.18pre, usb mouse messages

[Peter Samuelson]

> > usb-uhci.c: interrupt, status 3, frame# 212
> > hub.c: already running port 2 disabled by hub (EMI?), re-enabling...

[Greg KH]
> The messages are harmless debug messages.  Anyone want to whip up a
> patch to turn them off (like was recently done for 2.4.0-test)?

Is this what you mean?

Peter


diff -urk.bak 2.2.18-19/drivers/usb/hub.c.bak 2.2.18-19/drivers/usb/hub.c
--- 2.2.18-19/drivers/usb/hub.c.bak Fri Nov  3 19:20:45 2000
+++ 2.2.18-19/drivers/usb/hub.c Fri Nov 24 00:29:50 2000
@@ -530,11 +530,8 @@
// be shutdown by the hub, this hack enables them 
again.
// Works at least with mouse driver. 
if (!(portstatus & USB_PORT_STAT_ENABLE) && 
-   (portstatus & USB_PORT_STAT_CONNECTION) && 
(dev->children[i])) {
-   err("already running port %i disabled by hub 
(EMI?), re-enabling...",
-   i + 1);
+   (portstatus & USB_PORT_STAT_CONNECTION) && 
+(dev->children[i]))
usb_hub_port_connect_change(dev, i);
-   }
}
 
if (portstatus & USB_PORT_STAT_SUSPEND) {
diff -urk.bak 2.2.18-19/drivers/usb/usb-uhci.c.bak 2.2.18-19/drivers/usb/usb-uhci.c
--- 2.2.18-19/drivers/usb/usb-uhci.c.bakFri Nov  3 19:20:46 2000
+++ 2.2.18-19/drivers/usb/usb-uhci.cFri Nov 24 00:21:16 2000
@@ -2538,16 +2538,10 @@
 
dbg("interrupt");
 
-   if (status != 1) {
-   warn("interrupt, status %x, frame# %i", status, 
-UHCI_GET_CURRENT_FRAME(s));
+   // remove host controller halted state
+   if ((status&0x20) && (s->running))
+   outw (USBCMD_RS | inw(io_addr + USBCMD), io_addr + USBCMD);
 
-   // remove host controller halted state
-   if ((status&0x20) && (s->running)) {
-   outw (USBCMD_RS | inw(io_addr + USBCMD), io_addr + USBCMD);
-   }
-   //uhci_show_status (s);
-   }
/*
 * traverse the list in *reverse* direction, because new entries
 * may be added at the end.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Andre Hedrick]

On Fri, 24 Nov 2000, Alexander Viro wrote:

> 
> 
> On Thu, 23 Nov 2000, Andre Hedrick wrote:
> 
> > What the F*** does that have to do with the price of eggs in china, heh?
> > Just maybe if you could follow a thread, you would see that that Alex Viro
> > has pointed out that changes in the FS layer as dorked things.
> 
> ?
> If you have a l-k feed from future - please share. I'm not saying that

Date: Thu, 23 Nov 2000 04:37:21 -0500 (EST)

> fs/* is not the source of that stuff, but I sure as hell had not said
> that it is. I simply don't know yet.

You were pointing out changes to reproduce the effect.

> > Since there have been not kernel changes to the driver that effect the
> > code since 2.4.0-test5 or test6 and it now randomly shows up after five or
> > six revisions out from the change, and the changes were chipset only.
> 
> generic_unplug_device() was changed more or less recently. I doubt that
> it is relevant, but...

Cool, the issue was that I get tried of people blaming the ATA subsystem
for things that it does not do or has control over.  Basically, I kill
bogus threads that try to tag me with an old problem of the past that was
a hardware issue.

Given the latest stats that more than 90% of the linux install base is
hinged on me getting the low-level engine core correct, I go on benders
when cheap shots are take across the bow.

Now the only issue that is even on the radar map is a potential 1GB cross
copy execution where I have a single report that md5sums do not match.
I have yet to reproduce it even with the identical hardware sent to me.

I questioned _A_ about this and there may be a case that is OS independent
which is more important to me than other.  This is a non-fixable for
6->12 months, until I kick some tail in the standards committee meetings
over this point.  If it is a reality, Linux and Microsoft will join as the
OS's represented there and force the change.  Only because there are
potentical side-bars that NT is effected also in these rare cases.

Cheers,

Andre Hedrick
Linux ATA Development


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

lseek patch for 2.2.18pre23

[H . J . Lu]

2.2.18pre23 allows lseek to negative offsets in ext2 and has no checks
for proc. Here is a patch.

BTW, ext2 2.4-test10 is ok. 

-- 
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/ext2/file.c.lseek  Sat Nov 18 17:18:49 2000
+++ linux/fs/ext2/file.cThu Nov 23 21:54:58 2000
@@ -120,6 +120,8 @@ static long long ext2_file_lseek(
case 1:
offset += file->f_pos;
}
+   if (offset < 0)
+   return -EINVAL;
if (((unsigned long long) offset >> 32) != 0) {
 #if BITS_PER_LONG < 64
return -EINVAL;
--- linux/fs/proc/mem.c.lseek   Tue Jan  4 10:12:23 2000
+++ linux/fs/proc/mem.c Sat Nov 18 17:19:28 2000
@@ -196,14 +196,17 @@ static long long mem_lseek(struct file *
 {
switch (orig) {
case 0:
-   file->f_pos = offset;
-   return file->f_pos;
+   break;
case 1:
-   file->f_pos += offset;
-   return file->f_pos;
+   offset += file->f_pos;
+   break;
default:
return -EINVAL;
}
+   if (offset < 0)
+   return -EINVAL;
+   file->f_pos = offset;
+   return offset;
 }
 
 /*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Alexander Viro]

On Thu, 23 Nov 2000, Andre Hedrick wrote:

> What the F*** does that have to do with the price of eggs in china, heh?
> Just maybe if you could follow a thread, you would see that that Alex Viro
> has pointed out that changes in the FS layer as dorked things.

?
If you have a l-k feed from future - please share. I'm not saying that
fs/* is not the source of that stuff, but I sure as hell had not said
that it is. I simply don't know yet.
 
> Since there have been not kernel changes to the driver that effect the
> code since 2.4.0-test5 or test6 and it now randomly shows up after five or
> six revisions out from the change, and the changes were chipset only.

generic_unplug_device() was changed more or less recently. I doubt that
it is relevant, but...

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

Re: gcc 2.95.2 is buggy

[Peter Samuelson]

[Chris Wedgwood]
> taking away -O2 is a 'fix' for now... not a very good one though.

Not if you want function inlining to work.  The kernel *won't compile*
without optimization.

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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Andre Hedrick]

On Thu, 23 Nov 2000, Ion Badulescu wrote:

> > Yesterday I had a diff -r showing that the old version
> > was corrupted and the new was OK. Of course a second
> > look showed that the old version also was OK, the corruption
> > must have been in the buffer cache, not on disk.)
> 
> Are these disks IDE disks by any chance?

What the F*** does that have to do with the price of eggs in china, heh?
Just maybe if you could follow a thread, you would see that that Alex Viro
has pointed out that changes in the FS layer as dorked things.

Since there have been not kernel changes to the driver that effect the
code since 2.4.0-test5 or test6 and it now randomly shows up after five or
six revisions out from the change, and the changes were chipset only.

Please make your point.

Andre Hedrick
Linux ATA Development

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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Alexander Viro]

On Fri, 24 Nov 2000, Mohammad A. Haque wrote:

> I got the error while I was compiling XFree86 4 CVS and kernel. So
> that's what I've been doing in multiples along witha couple otehr things
> thrown inthe mix to generate lots of disk i/o.

Error messages would be interesting... So far we have _both_ 2.95 and 2.91
involved, raid and non-raid alike. Just fscking peachy... OK, let's try
to eliminate ext2 changes (if that helps we have a big problem somewhere,
but that's at least something):

patch -p1 -R i_sb;
-   inode->i_sb = sb;
-   inode->i_flags = 0;
lock_super (sb);
es = sb->u.ext2_sb.s_es;
 repeat:
@@ -430,9 +428,6 @@
mark_buffer_dirty(sb->u.ext2_sb.s_sbh);
sb->s_dirt = 1;
inode->i_mode = mode;
-   inode->i_sb = sb;
-   inode->i_nlink = 1;
-   inode->i_dev = sb->s_dev;
inode->i_uid = current->fsuid;
if (test_opt (sb, GRPID))
inode->i_gid = dir->i_gid;
EOF

Notice that if reverting that change stops the fs corruption we _still_
have a problem - the only case when it could help is if something touches
an inode allocated by get_empty_inode() before it gets included into the
hash.

BTW, folks, while we are looking at the configurations - how about highmem
and SMP vs. UP?

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

Re: gcc-2.95.2-51 is buggy

[Neil Brown]

On Friday November 24, [EMAIL PROTECTED] wrote:
> >> ... RedHat's GCC snapshot "2.96" handles this case just fine.
> 
> > Now, if you can isolate the relevant part of the diff between
> > 2.95.2 and RH 2.96...
> 
> Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".
> 
> I just installed gcc 2.95.2 freshly ftp'ed from ftp.gnu.org, and
> 
...
> 
> So, not all versions of gcc 2.95.2 are equal.
> 
> % rpm -qf /usr/bin/gcc
> gcc-2.95.2-51
> 
> This is from a SuSE distribution, I forget which, not very recent.
> Revised summary: gcc-2.95.2-51 from SuSE is buggy.

Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the same
bug.
Debian applies a total of 49 patches to gcc and the libraries.

I am tempted to write a little script which discards the patches one
by one and re-builds and re-tests each time, and leave it going all
night but I'm not sure if I actually will.

NeilBrown


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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Mohammad A. Haque]

I got the error while I was compiling XFree86 4 CVS and kernel. So
that's what I've been doing in multiples along witha couple otehr things
thrown inthe mix to generate lots of disk i/o.

Nothing yet, but I'm pretty sure my machine hates me for putting it
through this.

Alexander Viro wrote:
> Bloody interesting. I don't see anything recent that could affect the
> areas in question. Intersting versions to check: 11-pre5 and 11-pre6.
> It smells like buffer cache corruption, but I don't see anything
> relevant. __generic_unplug_device() change loock pretty innocent,
> ditto for bh_kmap() ones in raid5 and on ext2 side we had two obviously
> equivalent replacements (pre5->pre6). No buffer.c changes, no VM ones.
> Urgh.

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Mohammad A. Haque]

Yep. Unless of course they are SCSI with an identity crisis =P

Ion Badulescu wrote:
> 
> Are these disks IDE disks by any chance?
> 
> Ion
> 

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Alexander Viro]

On Fri, 24 Nov 2000, Neil Brown wrote:

> I ran my test script, which builds a variety of raid5 arrays with
> varying numbers of drives and chunk sizes, and runs mkfs/bonnie/dbench
> on each array, and it got through about 8 file systems but choked on
> the 9th by trying to allocate lots of blocks in the system zone (after
> running for about an hour). 

Bloody interesting. I don't see anything recent that could affect the
areas in question. Intersting versions to check: 11-pre5 and 11-pre6.
It smells like buffer cache corruption, but I don't see anything
relevant. __generic_unplug_device() change loock pretty innocent,
ditto for bh_kmap() ones in raid5 and on ext2 side we had two obviously
equivalent replacements (pre5->pre6). No buffer.c changes, no VM ones.
Urgh.

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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Guest section DW]

On Thu, Nov 23, 2000 at 08:58:39PM -0800, Ion Badulescu wrote:

> > (I am reorganizing my disks, copying large trees from
> > one place to the other. Always doing a diff -r between
> > old and new before removing the old version.
> > Yesterday I had a diff -r showing that the old version
> > was corrupted and the new was OK. Of course a second
> > look showed that the old version also was OK, the corruption
> > must have been in the buffer cache, not on disk.)
> 
> Are these disks IDE disks by any chance?

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

gcc-2.95.2-51 is buggy

[Andries . Brouwer]

>> ... RedHat's GCC snapshot "2.96" handles this case just fine.

> Now, if you can isolate the relevant part of the diff between
> 2.95.2 and RH 2.96...

Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".

I just installed gcc 2.95.2 freshly ftp'ed from ftp.gnu.org, and

% /usr/bin/gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
% /usr/bin/gcc -Wall -O2 -o bug bug.c; ./bug
0x8480
% /usr/gcc/aeb/bin/gcc -v
Reading specs from /usr/gcc/aeb/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)
% /usr/gcc/aeb/bin/gcc -Wall -O2 -o nobug bug.c; ./nobug
0x0

So, not all versions of gcc 2.95.2 are equal.

% rpm -qf /usr/bin/gcc
gcc-2.95.2-51

This is from a SuSE distribution, I forget which, not very recent.
Revised summary: gcc-2.95.2-51 from SuSE is buggy.

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

Re: NFSD dentry manipulation (was Re: d_move())

[Chip Salzenberg]

According to Neil Brown:
>  You suggest that d_move (or it's caller) must be able to deal with
>  the [second parameter] being an "root" dentry (x->d_parent == x).
>  However, I cannot see that this could possibly happen.

Hmph.  It seems you're right; my d_move changes [1][2] were apparently
not required after all.  However...

The sum of my recent NFS patches incontrovertably turned a totally
unstable server into the very model of stability.  Why?

Let's assume that d_move was a red herring.  What else in the old code
could have cause dentry bugs?  My first thought on that is that the
old code (1) created multiple disconnected dentries for a given inode,
and yet (2) assumed that multiple disconnected dentries would never be
found.  I invite others' opinions.  And I've included a copy of my
recent patches (less d_move) below.

[1] I still think it would be reasonable for d_move() to handle root
dentries, or at least oops on them for debugging.
[2] One bit of the d_splice patches is unrelated to d_move, namely,
the move of 'dput(tdentry)' to the bottom of d_splice, allowing
the 'parent' flag manipulation to finish before calling dput(),
which can sleep.  But knfsd uses the big kernel lock, so I guess
that's probably no issue either.

Index: fs/nfsd/nfsfh.c
--- fs/nfsd/nfsfh.c.prev
+++ fs/nfsd/nfsfh.c Mon Nov 20 22:31:52 2000
@@ -108,4 +108,15 @@ static int get_ino_name(struct dentry *d
}
 
+   if (!error) {
+   /*
+* Check for a fs-specific hash function. Note that we must
+* calculate the standard hash first, as the d_op->d_hash()
+* routine may choose to leave the hash value unchanged.
+*/
+   name->hash = full_name_hash(name->name, name->len);
+   if (dentry->d_op && dentry->d_op->d_hash)
+   error = dentry->d_op->d_hash(dentry, name);
+   }
+
 out_close:
if (file.f_op->release)
@@ -115,4 +126,35 @@ out:
 }
 
+/* Arrange a dentry for the given inode:
+ *  1. Prefer an existing connected dentry.
+ *  2. Settle for an existing disconnected dentry.
+ *  3. If necessary, create a (disconnected) dentry.
+ */
+static struct dentry *nfsd_arrange_dentry(struct inode *inode)
+{
+   struct list_head *lp;
+   struct dentry *result;
+
+   result = NULL;
+   for (lp = inode->i_dentry.next; lp != >i_dentry ; lp=lp->next) {
+   result = list_entry(lp,struct dentry, d_alias);
+   if (! (result->d_flags & DCACHE_NFSD_DISCONNECTED))
+   break;
+   }
+   if (result) {
+   dget(result);
+   iput(inode);
+   } else {
+   result = d_alloc_root(inode, NULL);
+   if (!result) {
+   iput(inode);
+   return ERR_PTR(-ENOMEM);
+   }
+   result->d_flags |= DCACHE_NFSD_DISCONNECTED;
+   d_rehash(result); /* so a dput won't loose it */
+   }
+   return result;
+}
+
 /* this should be provided by each filesystem in an nfsd_operations interface;
  * iget isn't really the right interface
@@ -121,6 +163,4 @@ static struct dentry *nfsd_iget(struct s
 {
struct inode *inode;
-   struct list_head *lp;
-   struct dentry *result;
 
inode = iget(sb, ino);
@@ -149,23 +189,6 @@ static struct dentry *nfsd_iget(struct s
return ERR_PTR(-ESTALE);
}
-   /* now to find a dentry.
-* If possible, get a well-connected one
-*/
-   for (lp = inode->i_dentry.next; lp != >i_dentry ; lp=lp->next) {
-   result = list_entry(lp,struct dentry, d_alias);
-   if (! (result->d_flags & DCACHE_NFSD_DISCONNECTED)) {
-   dget(result);
-   iput(inode);
-   return result;
-   }
-   }
-   result = d_alloc_root(inode, NULL);
-   if (result == NULL) {
-   iput(inode);
-   return ERR_PTR(-ENOMEM);
-   }
-   result->d_flags |= DCACHE_NFSD_DISCONNECTED;
-   d_rehash(result); /* so a dput won't loose it */
-   return result;
+
+   return nfsd_arrange_dentry(inode);
 }
 
@@ -228,43 +245,21 @@ int d_splice(struct dentry *target, stru
 struct dentry *nfsd_findparent(struct dentry *child)
 {
-   struct dentry *tdentry, *pdentry;
-   tdentry = d_alloc(child, &(const struct qstr) {"..", 2, 0});
-   if (!tdentry)
+   struct dentry *dotdot, *parent;
+
+   dotdot = d_alloc(child, &(const struct qstr) {"..", 2, 0});
+   if (!dotdot)
return ERR_PTR(-ENOMEM);
+   parent = child->d_inode->i_op->lookup(child->d_inode, dotdot);
+   d_drop(dotdot); /* we never want ".." hashed */
 
-   /* I'm going to assume that if the returned dentry is different, then
-* it is well connected.  But nobody returns different dentrys do they?
-*/
-   pdentry = 

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Ion Badulescu]

On Thu, 23 Nov 2000 13:52:52 +0100, Guest section DW <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 23, 2000 at 05:03:00PM +1100, Neil Brown wrote:
> 
>> Oh, good.  It's not just me and Tigran then.
> 
> You have it all backwards. It would be good if it were
> just you and Tigran. Unfortunately it also hits me.
> 
> (I am reorganizing my disks, copying large trees from
> one place to the other. Always doing a diff -r between
> old and new before removing the old version.
> Yesterday I had a diff -r showing that the old version
> was corrupted and the new was OK. Of course a second
> look showed that the old version also was OK, the corruption
> must have been in the buffer cache, not on disk.)

Are these disks IDE disks by any chance?

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc 2.95.2 is buggy

[Alexander Viro]

On Thu, 23 Nov 2000, Gregory Maxwell wrote:

> On Fri, Nov 24, 2000 at 02:57:45AM +0100, [EMAIL PROTECTED] wrote:
> > but in the meantime there is good confirmation.
> > This really is a bug in gcc 2.95.2.
> 
> ... RedHat's GCC snapshot "2.96" handles this case just fine. 

Now, if you can isolate the relevant part of the diff between 2.95.2 and
RH 2.96...

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

Re: PATCH: More PCI ID's for linux-2.4.0-test11/include/linux/pci_ids.h

[Peter Samuelson]

[Adam J. Richter]
> +#define PCI_VENDOR_ID_ELSA   0x1048
> +#define PCI_DEVICE_ID_ELSA_MIRCOLINK 0x1000
> +#define PCI_DEVICE_ID_ELSA_QS30000x3000

Oh, don't propagate the typo.  Spell it MICROLINK here and in
hisax/elsa.c.

>  #define PCI_VENDOR_ID_PLX0x10b5
> +#define PCI_DEVICE_ID_SATSAGEM_NICCY 0x1016
> +#define PCI_DEVICE_ID_PLX_R685   0x1030

SATSAGEM_NICCY is misplaced.

> @@ -561,15 +568,20 @@
>  #define PCI_DEVICE_ID_WINBOND_83769  0x0001
>  #define PCI_DEVICE_ID_WINBOND_82C105 0x0105
>  #define PCI_DEVICE_ID_WINBOND_83C553 0x0565
> +#define PCI_DEVICE_ID_WINBOND_6692   0x6692

This one needs to go under PCI_VENDOR_ID_WINBOND2 (and hisax/w6692.c
should be changed accordingly).

Here is my pending pci_ids.h patch, with your changes merged in.  (It
is longer than it needs to be, thanks to some space->tab conversions.)

Peter


--- include/linux/pci_ids.h.bak Mon Nov 13 01:43:49 2000
+++ include/linux/pci_ids.h Thu Nov 23 22:33:55 2000
@@ -119,6 +119,10 @@
 
 /* Vendors and devices.  Sort key: vendor first, device next. */
 
+/* Should be Dynalink - same company? */
+#define PCI_VENDOR_ID_ASUSCOM  0x0675
+#define PCI_DEVICE_ID_ASUSCOM_TA1  0x1702
+
 #define PCI_VENDOR_ID_COMPAQ   0x0e11
 #define PCI_DEVICE_ID_COMPAQ_TOKENRING 0x0508
 #define PCI_DEVICE_ID_COMPAQ_1280  0x3033
@@ -191,8 +195,8 @@
 
 #define PCI_VENDOR_ID_NS   0x100b
 #define PCI_DEVICE_ID_NS_87415 0x0002
-#define PCI_DEVICE_ID_NS_87560_LIO  0x000e
-#define PCI_DEVICE_ID_NS_87560_USB  0x0012
+#define PCI_DEVICE_ID_NS_87560_LIO 0x000e
+#define PCI_DEVICE_ID_NS_87560_USB 0x0012
 #define PCI_DEVICE_ID_NS_87410 0xd001
 
 #define PCI_VENDOR_ID_TSENG0x100c
@@ -254,9 +258,17 @@
 #definePCI_DEVICE_ID_IBM_405GP 0x0156
 #define PCI_DEVICE_ID_IBM_MPIC_2   0x
 
+#define PCI_VENDOR_ID_COMPEX2  0x101a // pci.ids says "AT GIS (NCR)"
+#define PCI_DEVICE_ID_COMPEX2_100VG0x0005
+
 #define PCI_VENDOR_ID_WD   0x101c
 #define PCI_DEVICE_ID_WD_7197  0x3296
 
+#define PCI_VENDOR_ID_AMI  0x101e
+#define PCI_DEVICE_ID_AMI_MEGARAID30x1960
+#define PCI_DEVICE_ID_AMI_MEGARAID 0x9010
+#define PCI_DEVICE_ID_AMI_MEGARAID20x9060
+
 #define PCI_VENDOR_ID_AMD  0x1022
 #define PCI_DEVICE_ID_AMD_LANCE0x2000
 #define PCI_DEVICE_ID_AMD_LANCE_HOME   0x2001
@@ -272,6 +284,8 @@
 #define PCI_DEVICE_ID_AMD_VIPER_740C   0x740C
 
 #define PCI_VENDOR_ID_TRIDENT  0x1023
+#define PCI_DEVICE_ID_TRIDENT_4DWAVE_DX0x2000
+#define PCI_DEVICE_ID_TRIDENT_4DWAVE_NX0x2001
 #define PCI_DEVICE_ID_TRIDENT_9320 0x9320
 #define PCI_DEVICE_ID_TRIDENT_9388 0x9388
 #define PCI_DEVICE_ID_TRIDENT_9397 0x9397
@@ -298,10 +312,10 @@
 #define PCI_DEVICE_ID_MATROX_MIL_2 0x051b
 #define PCI_DEVICE_ID_MATROX_MIL_2_AGP 0x051f
 #define PCI_DEVICE_ID_MATROX_MGA_IMP   0x0d10
-#define PCI_DEVICE_ID_MATROX_G100_MM0x1000
-#define PCI_DEVICE_ID_MATROX_G100_AGP   0x1001
-#define PCI_DEVICE_ID_MATROX_G200_PCI   0x0520
-#define PCI_DEVICE_ID_MATROX_G200_AGP   0x0521
+#define PCI_DEVICE_ID_MATROX_G100_MM   0x1000
+#define PCI_DEVICE_ID_MATROX_G100_AGP  0x1001
+#define PCI_DEVICE_ID_MATROX_G200_PCI  0x0520
+#define PCI_DEVICE_ID_MATROX_G200_AGP  0x0521
 #definePCI_DEVICE_ID_MATROX_G400   0x0525
 #define PCI_DEVICE_ID_MATROX_VIA   0x4536
 
@@ -365,8 +379,8 @@
 #define PCI_DEVICE_ID_PCTECH_SAMURAI_1 0x3010
 #define PCI_DEVICE_ID_PCTECH_SAMURAI_IDE 0x3020
 
-#define PCI_VENDOR_ID_DPT   0x1044   
-#define PCI_DEVICE_ID_DPT   0xa400  
+#define PCI_VENDOR_ID_DPT  0x1044
+#define PCI_DEVICE_ID_DPT  0xa400
 
 #define PCI_VENDOR_ID_OPTI 0x1045
 #define PCI_DEVICE_ID_OPTI_92C178  0xc178
@@ -380,6 +394,10 @@
 #define PCI_DEVICE_ID_OPTI_82C861  0xc861
 #define PCI_DEVICE_ID_OPTI_82C825  0xd568
 
+#define PCI_VENDOR_ID_ELSA 0x1048
+#define PCI_DEVICE_ID_ELSA_MICROLINK   0x1000
+#define PCI_DEVICE_ID_ELSA_QS3000  0x3000
+
 #define PCI_VENDOR_ID_SGS  0x104a
 #define PCI_DEVICE_ID_SGS_2000 0x0008
 #define PCI_DEVICE_ID_SGS_1764 0x0009
@@ -406,6 +424,8 @@
 #define PCI_DEVICE_ID_TI_1251B 0xac1f
 #define PCI_DEVICE_ID_TI_1420  0xac51
 
+#define PCI_VENDOR_ID_SONY 0x104d
+#define PCI_DEVICE_ID_SONY_CXD3222 0x8039
 
 #define PCI_VENDOR_ID_OAK  0x104e
 #define PCI_DEVICE_ID_OAK_OTI107   0x0107
@@ -414,6 +434,7 @@
 #define PCI_VENDOR_ID_WINBOND2 0x1050
 #define PCI_DEVICE_ID_WINBOND2_89C940  0x0940
 #define PCI_DEVICE_ID_WINBOND2_89C940F 0x5a5a
+#define PCI_DEVICE_ID_WINBOND2_66920x6692
 
 #define PCI_VENDOR_ID_EFAR 0x1055
 #define PCI_DEVICE_ID_EFAR_SLC90E66_1  0x9130
@@ -503,9 +524,10 @@
 #define PCI_VENDOR_ID_LEADTEK  0x107d
 #define PCI_DEVICE_ID_LEADTEK_805  

Re: gcc 2.95.2 is buggy

[Gregory Maxwell]

On Fri, Nov 24, 2000 at 02:57:45AM +0100, [EMAIL PROTECTED] wrote:
> but in the meantime there is good confirmation.
> This really is a bug in gcc 2.95.2.

... RedHat's GCC snapshot "2.96" handles this case just fine. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

ohci1394 PCI device ID's

[Adam J. Richter]

Sorry for the rather lengthy email list.  I am not sure exactly
which of you it would be appropriate to put this question to.

I am writing a pci_device_id table for ohci1394.c.  This will
allow a userland program to automatically load the module when an
ohci1394 card is present.  There is a PCI device class for ohci1394
controllers (pci_dev->class == 0x0c0310).  So, is there some reason
why linux-2.4.0-test11/drivers/ieee1394/ohci1934.c contains a list
of vendor_id/device_id pairs?

If ohci1394.c really needs to match based on vendor_id and
device_id, then I will generate a pci_device_id table accordingly.
On the other hand, if ohci1394.c really does not need to care about
vendor_id/device_id pairs, I will add the generic pci_device_id table
for an ohci1394 controller, and I would also be happy to generate
a patch for you folks that eliminates the use of the vendor_id / device_id
pairs, and, if you want, ports the driver to the new hotplug PCI
interface, which might be useful, considering that I see ieee1394
CardBus cards everywhere.

Any feedback would be appreciated.  Thanks in advance.

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

More info about de USB HP 8230e and problems]

[Drizzt]

I have using the next software:

a) test11 + storage checkout from linux-usb at sourceforge ( without 
   this checkout fails too).

b) cdrecord 1.10a6

If I start to burn a CD at x4 speed, I have always the next error from
cdrecord:
Track 01: 102 of 109 MB written (fifo 100%)./opt/schily/bin/cdrecord:
Input/output error. write_g1: scsi sendcmd: retryable error
CDB:  2A 00 00 00 CD 03 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 03 00 00 00 00 12 00 00 00 00 0C 09 00 00
Sense Key: 0x3 Medium Error, Segment 0
Sense Code: 0x0C Qual 0x09 (write error - loss of streaming) Fru 0x0
Sense flags: Blk 0 (not valid)

Well the size of track varies in function that have buring.

With the storage-usb debug active I have the next log:

usb-storage: Command WRITE_10 (10 bytes)
usb-storage: 2a 00 00 00 cd 03 00 00 1f 00 ff bf
usb-storage: Transferred out 38 of 38 bytes
usb-storage: Transferred out 32768 of 32768 bytes
usb-storage: Transferred out 30720 of 30720 bytes
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Transferred out 14 of 14 bytes
usb-storage: Waited not busy for 0 steps
usb-storage: Transferred out 12 of 12 bytes
usb-storage: Waited not busy for 2 steps
usb-storage: Transferred in 18 of 18 bytes
usb-storage: 70 00 03 00 00 00 00 12 00 00 00 00 0C 09 00 00
usb-storage: 00 00
usb-storage: -- Result from auto-sense is 0
usb-storage: -- code: 0x70, key: 0x3, ASC: 0xc, ASCQ: 0x9
usb-storage: Medium Error: (unknown ASC/ASCQ)
usb-storage: scsi cmd done, result=0x2
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called

Thesis a i810 based computer.

If I burning the CD with the same software at x2 speed with these computer I
have no problem burning the CD.

But, if I test the CDRW in a laptop with a VIA chipset, I can burn nothing nor
x1 speed :(. The chipset of the laptop have I VT82C586B as USB device. The
kernel here it's test10.


Saludos
Drizzt
-- 
... Los viejos ecologistas nunca mueren, simplemente son reciclados.

Drizzt Do'UrdenThree rings for the Elves Kings under the Sky   
[EMAIL PROTECTED]   Seven for the Dwarf_lords in their  
   hall of stone
   Nine for the Mortal Men doomed to die 

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

[PATCH] for ReiserFS 3.5.27 on 2.2.18pre23

[Steven Cole]

For those of you who may want to run ReiserFS
on 2.2.18pre23 using reiserfs-3.5.27,
you may find as I did that the main reiserfs patch,
linux-2.2.17-reiserfs-3.5.27-patch, fails like this:

patching file linux/include/linux/fs.h
Hunk #1 FAILED at 279.
Hunk #2 FAILED at 393.
Hunk #3 FAILED at 516.
Hunk #4 FAILED at 560.
4 out of 4 hunks FAILED -- saving rejects to file linux/include/linux/fs.h.rej

Here is a temporary fix. The following will patch linux/include/linux/fs.h 
correctly.  I am currently running 2.2.18pre23 with reiserfs 3.5.27 using 
this patch:

diff -u linux/include/linux/fs.h.orig linux/include/linux/fs.h
--- linux/include/linux/fs.h.orig   Thu Nov 23 18:25:10 2000
+++ linux/include/linux/fs.hThu Nov 23 18:38:15 2000
@@ -280,6 +280,7 @@
 #include 
 #include 
 #include 
+#include 

 /*
  * Attribute flags.  These should be or-ed together to figure out what
@@ -395,6 +396,7 @@
struct adfs_inode_info  adfs_i;
struct qnx4_inode_info  qnx4_i;
struct usbdev_inode_infousbdev_i;
+   struct reiserfs_inode_info  reiserfs_i;
struct socket   socket_i;
void*generic_ip;
} u;
@@ -520,6 +522,7 @@
 #include 
 #include 
 #include 
+#include 

 extern struct list_head super_blocks;

@@ -564,6 +567,7 @@
struct adfs_sb_info adfs_sb;
struct qnx4_sb_info qnx4_sb;
struct usbdev_sb_info   usbdevfs_sb;
+   struct reiserfs_sb_info reiserfs_sb;
void*generic_sbp;
} u;
/*

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

Re: RFC: Modularize /proc/partitons (was Re: /proc/partitions for LVM)

[Peter Samuelson]

[Brian Kress]
> 1)  Add a function pointer to struct gendisk called hd_name.
> 
> 2)  Make disk_name in fs/partitions/check.c use that function
> pointer if its non-null.
> 
> 3)  Change the following drivers to use this method. (adding the
> driver specific method and removing the old code in check.c)

Looks good to me ... except that cpqarray.c, cciss.c and DAC960.c have
basically duplicate functions.  Would this be a net win:

  char *typical_disk_name(struct gendisk *, int major_base, int minor, char *buf);

...exported from check.c?

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

Re: Alpha SMP problem

[Andrea Arcangeli]

On Tue, Nov 07, 2000 at 10:57:49PM -0800, Richard Henderson wrote:
> On Tue, Nov 07, 2000 at 10:09:34AM -0800, Reto Baettig wrote:
> > I have a problem whith Alpha SMP's which seems to be kernel-related. I
> > discussed this on the bug-glibc list but everybody seems to agree that
> > it cannot be a libc problem.
> 
> Indeed it does seem to be some sort of tlb flushing problem,

Yes it was.

> but I've been unable to figure out exactly what.

There were a few SMP races that could trigger only using threads:

1) flush_tlb_other could happen after we read the mm->context and we could
   miss a tlb flush
2) flush_tlb_current could bump up the asn of the current cpu and in turn
   change the asn version after we acquired a new context leading to
   an alias between our asn and a later one
3) a PAL_swpctx can't be done in the middle of alpha_switch_to

ppc/sparc64 may have similar issues and I didn't checked them (from a fast read
it looks like sparc64 is just safe but I don't know the sparc hardware
well enough to be sure).

I also noticed the horrible implementation of ASN in SMP so while I was
there I rewrote it.

The rewrote is based on the fact that mm->context makes no sense. It must be an
array of mm->context[NR_CPUS]. Almost certainly mips wants an array of NR_CPUS
too. Anyways for mips it's not a big deal since SMP isn't supported in 2.2.x ;).

In 2.2.x I added:

#ifdef __alpha__

in the mm.h code, so that people can apply this patch kernel without breaking
compiles of all other architectures.

For 2.4.x I'd like to know what sparc64 and ppc wants as mm->context, alpha
definitely wants a per-CPU array (probably mips too).

With a single mm->context with threads both cpus was going to overwrite
the same field at the same time. This just made mm->context useless
and it leads to overflow of asn even if there's only 1 MM running in the
system.

And the old implementation wasn't only bad for threads but it was bad
also for regular processes. Every time a task was changing CPU an ASN
was wasted. After 512 changes of CPU of the same task the tlb was flushed
on both cpus even if there was only 1 or two programs running.

With this new design up to 256 different MM (they could belong to 10 threads
each or to a single task each) can run in a SMP system without generating any
tlb flush (aka ASN overflow) in any CPU regardless of the MM migration between
cpus or of the context switches between task and threads.

--- 2.2.18pre21aa2/arch/alpha/kernel/smp.c.~1~  Wed Nov 22 02:32:53 2000
+++ 2.2.18pre21aa2/arch/alpha/kernel/smp.c  Thu Nov 23 04:48:24 2000
@@ -95,8 +95,7 @@
 smp_store_cpu_info(int cpuid)
 {
cpu_data[cpuid].loops_per_jiffy = loops_per_jiffy;
-   cpu_data[cpuid].last_asn
- = (cpuid << WIDTH_HARDWARE_ASN) + ASN_FIRST_VERSION;
+   cpu_data[cpuid].last_asn = ASN_FIRST_VERSION;
 
 cpu_data[cpuid].irq_count = 0;
 cpu_data[cpuid].bh_count = 0;
@@ -905,6 +904,8 @@
struct mm_struct *mm = (struct mm_struct *) x;
if (mm == current->mm)
flush_tlb_current(mm);
+   else
+   flush_tlb_other(mm);
 }
 
 void
@@ -912,10 +913,17 @@
 {
if (mm == current->mm) {
flush_tlb_current(mm);
-   if (atomic_read(>count) == 1)
+   if (atomic_read(>count) == 1) {
+   int i, cpu, this_cpu = smp_processor_id();
+   for (i = 0; i < smp_num_cpus; i++) {
+   cpu = cpu_logical_map(i);
+   if (cpu == this_cpu)
+   continue;
+   mm->context[cpu] = 0;
+   }
return;
-   } else
-   flush_tlb_other(mm);
+   }
+   }
 
if (smp_call_function(ipi_flush_tlb_mm, mm, 1, 1)) {
printk(KERN_CRIT "flush_tlb_mm: timed out\n");
@@ -932,8 +940,12 @@
 ipi_flush_tlb_page(void *x)
 {
struct flush_tlb_page_struct *data = (struct flush_tlb_page_struct *)x;
-   if (data->mm == current->mm)
-   flush_tlb_current_page(data->mm, data->vma, data->addr);
+   struct mm_struct * mm = data->mm;
+
+   if (mm == current->mm)
+   flush_tlb_current_page(mm, data->vma, data->addr);
+   else
+   flush_tlb_other(mm);
 }
 
 void
@@ -944,10 +956,17 @@
 
if (mm == current->mm) {
flush_tlb_current_page(mm, vma, addr);
-   if (atomic_read(>mm->count) == 1)
+   if (atomic_read(>mm->count) == 1) {
+   int i, cpu, this_cpu = smp_processor_id();
+   for (i = 0; i < smp_num_cpus; i++) {
+   cpu = cpu_logical_map(i);
+   if (cpu == this_cpu)
+   continue;
+   mm->context[cpu] = 0;
+   }
  

Re: beware of dead string constants

[Peter Samuelson]

[Jeff Garzik]
> If you mean preferring 'if ()' over 'ifdef'... Linus.  :) And I agree
> with him: code looks -much- more clean without ifdefs.  And the
> compiler should be smart enough to completely eliminate code inside
> an 'if (0)' code block.

Plus the advantage/disadvantage of making the compiler parse almost
everything, which should eliminate syntax errors, variable name
misspellings, etc in little-used config options.  The disadvantage is
that compilation speed goes down.

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

imsttfb.c PCI ID's?

[Adam J. Richter]

In writing a pci_device_id table for
linux-2.4.0-test11/drivers/video/imsttfb.c, I see that that driver
theoretically attepts to bind to any PCI video display with
a vendor ID set to PCI_VENDOR_ID_IMS, although the code does
mention device ID's 0x9128 and 0x9135.  Does anybody know if
there are other device ID's besides 0x9128 and 0x9135 that
imsttfb.c is interested in, or is it OK to write the
pci_device_id table to just specify those two rather than all
PCI video cards made by IMS?

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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Neil Brown]

On Thursday November 23, [EMAIL PROTECTED] wrote:
> 
> 
> On Thu, 23 Nov 2000, Alexander Viro wrote:
> 
> > On Thu, 23 Nov 2000, Neil Brown wrote:
> > 
> > > which enabled ext2_notify_change, however ext2_notify_change has a
> > > bug.
> > > It sets attributes from iattr->ia_attr_flags even
> > > if ATTR_ATTR_FLAG is NOT SET in iattr->ia_valid.
> > 
> > Arrrgh. Could you try that:
> 
> OK, I really need more coffee - wrong patch. My apologies. Correct (OK,
> intended) one follows:

Hmmm. either you need more coffee, or I need a new compiler.
I'm using 2.95.2, and there seems to be some question marks over that.

Unfortunately debian/potato doesn't seem to offer anything else
(Except 2.7.2), so I'll try to download and compile egcs-1.1.2 and see
how that works.

I ran my test script, which builds a variety of raid5 arrays with
varying numbers of drives and chunk sizes, and runs mkfs/bonnie/dbench
on each array, and it got through about 8 file systems but choked on
the 9th by trying to allocate lots of blocks in the system zone (after
running for about an hour). 

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

Re: [PATCH] 2.2.18: d_move() with self-root dentries (Dentry Corruption!)

[Neil Brown]

On Tuesday November 21, [EMAIL PROTECTED] wrote:
> This may be 2.2.18 material after all  I wrote last night:
> > Making nfsd's d_splice() compensate for d_move's limitations is not
> > only a kludge, but also it harder to keep nfsd correct.
> > someday, nfsd may not be the only creator of this kind of dentry.
> 
> Sure enough, there is just such a bug *already* in nfsd.  Nfsd's
> cleanup after d_move is incomplete: It handles one of the dentries
> being parentless, but not the other one.  This bug *will* cause dentry
> corruption.[1]  It may well be what's been causing the hangs that my
> recent patches seem to have fixed.
> 
> Therefore, in the mainline kernel, we need either the below patch to
> d_move (along with a trivial simplifcation of nfsd's use of it), or an
> expansion of the kludge in nfsd.  You can guess which one I favor
> 
> [1] The bug can only show up when reconstructing pruned dentries, and
> only under a specific pattern of client requests, so it's not
> surprising that it is rarely observed in the wild.

Hi Chip,
 I am trying to understand what might be going on and why this fix
 might be needed, and I'm not making much progress.

 You suggest that d_move (or it's caller) must be able to deal with
 the target being an "root" dentry (x->d_parent == x). However I
 cannot see that this could possibly happen.

 (looking at 2.2.18pre21 which should be much the same as any othe
 2.2 knfsd..)

 The only place that knfsd calls d_move is in d_splice.
 Here the "dentry" argument is "target" (just to confuse the innocent)
 and this is almost certainly an "root" entry passed in from "splice".
 However the "target" argument is "tdentry" which was just created
 with d_alloc which has given a parent which is certainly non-NULL,
 otherwise we would have an oops much earlier.
 So the parent of the "target" is "parent", which is certainly
 different from "tdentry", so d_move is *not* being asked to
 move something onto a "root" dentry, so the change is not needed.
 

 Did I miss something in the above, or can you in some other way
 convince me that d_move needs to handle is_root targets.

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

gcc 2.95.2 is buggy

[Andries . Brouwer]

Yesterday night I wrote

> Note: this is not yet a confirmed compiler bug

but in the meantime there is good confirmation.
This really is a bug in gcc 2.95.2.

>From [EMAIL PROTECTED] Thu Nov 23 10:45:07 2000
> Please, could you send me ...

>From [EMAIL PROTECTED] Thu Nov 23 18:00:48 2000
> Can we get a show of hands?

Below a demo program.

Andries

 bug.c -
/*
 * bug.c - aeb, 001124
 *
 * This program shows a bug in gcc 2.95.2.
 * It should print 0x0 and exit.
 * For me it prints 0x8480.
 *
 * Compile with:
 *gcc -Wall -O2 -o bug bug.c
 */
#include 

struct inode {
long long   i_size;
struct super_block  *i_sb;
};

struct file {
long long   f_pos;
};

struct super_block {
int s_blocksize;
unsigned char   s_blocksize_bits;
int s_hs;
};

static char *
isofs_bread(unsigned int block)
{
printf("0x%x\n", block);
exit(0);
}

static int
do_isofs_readdir(struct inode *inode, struct file *filp)
{
int bufsize = inode->i_sb->s_blocksize;
unsigned char bufbits = inode->i_sb->s_blocksize_bits;
unsigned int block, offset;
char *bh = NULL;
int hs;

if (filp->f_pos >= inode->i_size)
return 0;
 
offset = filp->f_pos & (bufsize - 1);
block = filp->f_pos >> bufbits;
hs = inode->i_sb->s_hs;

while (filp->f_pos < inode->i_size) {
if (!bh)
bh = isofs_bread(block);

hs += block << bufbits;

if (hs == 0)
filp->f_pos++;

if (offset >= bufsize)
offset &= bufsize - 1;

if (*bh)
filp->f_pos++;

filp->f_pos++;
}
return 0;
}

struct super_block s;
struct inode i;
struct file f;

int
main(int argc, char **argv){
s.s_blocksize = 512;
s.s_blocksize_bits = 9;
i.i_size = 2048;
i.i_sb = 
f.f_pos = 0;

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

Re: kernel_thread bogosity

[Andrea Arcangeli]

On Thu, Nov 23, 2000 at 11:23:33PM +0100, Pavel Machek wrote:
> Hi!
> 
> You see? Kernel_thread does not check is sys_clone() worked! Aha,

"=" (retval)

> caller is responsible for that, but init/main.c does not seem too
> carefull. Maybe kernel_thread should at least print a warning?

If clone fails during start_kernel that's the last of your problems so nobody
cared. If you want to add a check on the retval go ahead, that's right indeed.

> Plus, can someone explain me why it does not need to setup %%ecx with
> either zero or address of stack?

Not necessary because a kernel thread never exit from kernel.

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

Re: 3c59x: Using bad IRQ 0

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Thu, 23 Nov 2000, Tobias Ringstrom wrote:
> > >
> > >  - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code
> > >print out what the pirq table entries are etc.
> >
> > Done. When adding the call to eisa_set_level_irq, the line
> >
> > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl  -> newirq=9 -> 
>assigning IRQ 9 ... OK
> >
> > was changed into
> >
> > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl  -> newirq=9 -> 
>assigning IRQ 9 -> edge ... OK
> 
> Ok.
> 
> The thing was marked as edge-triggered, which is basically always wrong
> for a PCI interrupt. The above printout just means that it now noticed
> that it was edge, and fixed it up in the ELCR.

FWIW Via's PCI to ISA bridge has a PIRQ edge/level register.

Vendor=1106h, Device=686h, PCI config offset 54h, RW
Bits 7-4 reserved, zero.
Bit 3: PIRQA# edge (clear bit for level)
Bit 2: PIRQB# edge (clear bit for level)
Bit 1: PIRQC# edge (clear bit for level)
Bit 0: PIRQD# edge (clear bit for level)

The bits are all supposed to default to zero (level).


> > >  - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before
> > >the "return 1;"
> >
> > You certainly know your kernel very well... :-)
> 
> That's why they pay me the big bucks. Good.
> 
> I'll make it do the eisa_set_level_irq() in the generic code: it should
> always be right (we don't do it now in the PIIX4 case, for example, but
> the PIIX documentation actually says that we _should_), and there is no
> need to do it separately for each interrupt router.

So calling eisa_set_level_irq() means nothing will scream if we do not
update [for example] the above register?

Jeff


-- 
Jeff Garzik |
Building 1024   | The chief enemy of creativity is "good" sense
MandrakeSoft|  -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhciand emu10k1

[Linus Torvalds]

On Thu, 23 Nov 2000, Jeff Garzik wrote:
> > 
> > It hangs in start_uhci():
> > 
> > /* disable legacy emulation */
> > pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);

Try changing the thing around a bit: make the above place say

/* disable legacy emulation */
pci_write_config_word (dev, USBLEGSUP, 0);

and then AFTER we have successfully done a request_irq() call, we 
can enable PCI interrupts with

/* Enable PIRQ */
pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);

Does that make it happier?

Linus

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

Re: [NEW DRIVER] firestream

[Rogier Wolff]

Bartlomiej Zolnierkiewicz wrote:
> You may also consider processing firestream.[ch] through indent because
> spacing is inconsistent - sometimes tabs, sometimes 8*space (it would
> be nice too have tabs everywhere).

As far as I know the tabs/spaces are exactly the way I want them. 

There are tabs for the number of indentation levels. From then on
there are only spaces.

Although the "kernel-rules" say that tabs are 8 spaces, if you set
your tabsize to 4, my sources should still be nicely formatted.  If
I'd perform your substitute it wouldn't. 

Roger. 

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

Re: beware of dead string constants

[Jeff Garzik]

Bernd Eckenfels wrote:
> 
> In article <[EMAIL PROTECTED]> you wrote:
> > This is mostly a heads-up to say that in this regard gcc is not ready
> > for prime time, so we really can't get away with using if() as an ifdef
> > yet, at least not without penalty.
> 
> Humm.. whats the Advantage of this?

Advantage of what?

If you mean preferring 'if ()' over 'ifdef'... Linus.  :)  And I agree
with him:  code looks -much- more clean without ifdefs.  And the
compiler should be smart enough to completely eliminate code inside an
'if (0)' code block.

Jeff


-- 
Jeff Garzik |
Building 1024   | The chief enemy of creativity is "good" sense
MandrakeSoft|  -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: Cruft mounting option incorrect in ISOFS code

[Rogier Wolff]

Ben Fennema wrote:
> Rogier Wolff wrote:
> > 
> > Alan Cox wrote:
> > > > under 1 gig in size.  You can exhibit the problem by mounting the dvd movie
> > > > "The World is Not Enough" as it contains a video_ts.vob which is larger than
> > > > 1 gigabyte.  You will see that most of the file lengths are incorrect due to
> > > > the "cruft mounting option" hacking off the high order byte.  There are
> > > > certainly many more movies out there that exhibit this problem so it would
> > > > be a good thing for someone to fix.
> >  
> > > The cruft thing is correct in itself. The size being 4Gb is trivial
> > > to change providing someone can provide a reference to the standards
> > > that say its ok.  So is the limit 4Gig, who documents it ?
> > 
> > Page 137 of DVD Demystified by Jim Taylor says:
> > 
> >   - Individual files must be less than or equal to 1 gigabyte in length.
> 
> The maximum size of a single UDF extent is 2^30-1
> For DVD Video, the data of each file shall be recorded in a single extent.

Hmm. Then the "or equal to" part is "wrong"... 

Yes, My dvd demystified book also says that it needs to be one extent.

Roger. 

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

Re: beware of dead string constants

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> This is mostly a heads-up to say that in this regard gcc is not ready
> for prime time, so we really can't get away with using if() as an ifdef
> yet, at least not without penalty.

Humm.. whats the Advantage of this?

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

2.4.0-test11: unresolved symbols

[Dieter Nützel]

Hello all,

I played around with the 'new' masquerading/network stuff for the first time. 
xDSL is coming to me in some days...:-)

I get the following unresolved symbols with pure 2.4.0-test11.
Am I missing something?

depmod: *** Unresolved symbols in 
/lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_conntrack.o
depmod:  nf_unregister_hook
depmod:  nf_unregister_sockopt
depmod:  nf_register_hook
depmod:  nf_register_sockopt

depmod: *** Unresolved symbols in 
/lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_tables.o
depmod:  nf_unregister_sockopt
depmod:  nf_register_sockopt

depmod: *** Unresolved symbols in 
/lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/iptable_filter.o
depmod:  nf_unregister_hook
depmod:  nf_register_hook

depmod: *** Unresolved symbols in 
/lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/iptable_nat.o
depmod:  nf_unregister_hook
depmod:  nf_register_hook

depmod: *** Unresolved symbols in 
/lib/modules/2.4.0-test11/kernel/net/ipv6/ipv6.o
depmod:  rtnetlink_links
depmod:  sk_run_filter
depmod:  nf_hooks
depmod:  __rta_fill
depmod:  netlink_set_err
depmod:  nf_setsockopt
depmod:  netlink_broadcast
depmod:  rtnetlink_put_metrics
depmod:  nf_getsockopt
depmod:  netlink_unicast
depmod:  rtnl
depmod:  nf_hook_slow

depmod: *** Unresolved symbols in 
/lib/modules/2.4.0-test11/kernel/net/ipv6/netfilter/ip6_tables.o
depmod:  nf_unregister_sockopt
depmod:  nf_register_sockopt

depmod: *** Unresolved symbols in 
/lib/modules/2.4.0-test11/kernel/net/ipv6/netfilter/ip6table_filter.o
depmod:  nf_unregister_hook
depmod:  nf_register_hook

depmod: *** Unresolved symbols in 
/lib/modules/2.4.0-test11/kernel/net/packet/af_packet.o
depmod:  sk_run_filter

Thanks,
 Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

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

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

Re: Too long network device names corrupts kernel

[Michael Richardson]

> "Tobias" == Tobias Ringstrom <[EMAIL PROTECTED]> writes:
Tobias> Btw, does anyone know of a C function that works like strncpy, but does
Tobias> add a terminating null character, event if the string does not fit, ro
Tobias> does one have to do str[5]=0 first, and then strncpy(str,src,4)?

  str[0]=0;
  strncat(str, src, 4);

  Works as you want.

] Train travel features AC outlets with no take-off restrictions|gigabit is no[
]   Michael Richardson, Solidum Systems   Oh where, oh where has|problem  with[
] [EMAIL PROTECTED]   www.solidum.com   the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [



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

Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface

[Jeff Garzik]

Pavel Machek wrote:
> 
> Hi!
> 
> > > I also agree that the ioctl patch is kind of a bandaid over
> > > the problems that you described, and, while Zach Brown can speak
> >
> > The biggest problem is that the current code is gross gross gross.
> > I've been avoiding dealing with it too much in the hopes that moving to
> > oss_audio will make things much more friendly across the board.
> 
> What is oss_audio?

A module I wrote to encapsulate all the OSS logic into a single file. 
There are so many sound drivers that get their ioctls wrong in certain
cases, don't do mmap, etc. that I moved all the logic into one place.

You can obtain include/linux/oss_audio.h and drivers/sound/oss_audio.c
from gkernel CVS.  Check out module 'linux_2_4', tag
'hack_2_4_0_test11'.  (http://sourceforge.net/projects/gkernel/)


> I thought alsa is going in in 2.5...

Yep.

Jeff


-- 
Jeff Garzik |
Building 1024   | The chief enemy of creativity is "good" sense
MandrakeSoft|  -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1

[Jeff Garzik]

Michael Elkins wrote:
> 
> On Thu, Nov 23, 2000 at 05:49:52PM +0100, Georg Acher wrote:
> > On Thu, Nov 23, 2000 at 04:35:33PM +, Rui Sousa wrote:
> > > On Thu, 23 Nov 2000, Michael Elkins wrote:
> > >
> > > Usb controller is sharing a interrupt with the emu10k1.
> > > For what I know the emu10k1 driver doesn't have any problem
> > > sharing irq's, so I would blame the usb driver...
> >
> > usb-uhci doesn't also have any problem with sharing irqs:
> >
> > > cat /proc/interrupts
> >  10:5597981  XT-PIC  aic7xxx, eth0, usb-uhci
> >
> > Hm, no one left to blame...
> > I would debug it as follows:
> > Place various printks in the initialization code (reset_hc(), start_hc() and
> > alloc_uhci) and find out after which printk it hangs. Then it would be
> > possible to investigate this further...
> 
> It hangs in start_uhci():
> 
> /* disable legacy emulation */
> pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);
> 
> The loop that the call is in gets iterated 5 times.  For i < 4, the
> if (!(dev->resource[i].flags & 1))
> is TRUE, but on i==4, it drops into the bottom of the loop to execute
> check_region() and then pci_write_config_word(), where it hangs.

It may not make a difference, but that check is flat out wrong.

Apply this patch...  (untested, you may need to include ioport.h)

-- 
Jeff Garzik |
Building 1024   | The chief enemy of creativity is "good" sense
MandrakeSoft|  -- Picasso

Index: drivers/usb/usb-uhci.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/usb/usb-uhci.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 usb-uhci.c
--- drivers/usb/usb-uhci.c  2000/10/22 23:25:12 1.1.1.9
+++ drivers/usb/usb-uhci.c  2000/11/23 23:04:37
@@ -2886,7 +2886,7 @@
unsigned int io_addr = dev->resource[i].start;
unsigned int io_size =
dev->resource[i].end - dev->resource[i].start + 1;
-   if (!(dev->resource[i].flags & 1))
+   if (!(dev->resource[i].flags & IORESOURCE_IO))
continue;
 
/* Is it already in use? */

Can't mount SCSI CDROM in 2.4.*

[Roland Orre]

Since I started running the 2.4.0-test kernels a couple of months ago
I'm not able to use my scsi cdrom and cdwriter.

Today I installed 2.4.0-test11, still the same problem.

bayes:/dev# ls -l /dev/scd0 
brw-rw1 root cdrom 11,   0 Oct 21 04:53 /dev/scd0

bayes:/dev# mount -t iso9660 /dev/scd0 /cdrom
mount: /dev/scd0 has wrong major or minor number

bayes:/dev# mount -V
mount: mount-2.10o

Each time I want to access the cdrom or cdwriter I have to reboot w 2.2.17
where it works fine.

I've even tried with creating a generic block device
bayes:/dev# ls -l /dev/scg0 
brw-r--r--1 root root  21,   0 Nov 23 23:41 /dev/scg0

byes:/dev# mount -t iso9660 /dev/scg0 /cdrom
mount: /dev/scg0 has wrong major or minor number

Apart from this the 2.4.0-test kernels have been running very stable
for me. My systems are dual PII on ASUS PL97-DS and P2B-DS

According to Documentation/devices.txt nothing has changed according
major numbers for these devices from 2.2 to 2.4.

I'm grateful for any hint.

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

Can't mount SCSI CDROM in 2.4.*

[Roland Orre]

Since I started running the 2.4.0-test kernels a couple of months ago
I'm not able to use my scsi cdrom and cdwriter.

Today I installed 2.4.0-test11, still the same problem.

bayes:/dev# ls -l /dev/scd0 
brw-rw1 root cdrom 11,   0 Oct 21 04:53 /dev/scd0

bayes:/dev# mount -t iso9660 /dev/scd0 /cdrom
mount: /dev/scd0 has wrong major or minor number

bayes:/dev# mount -V
mount: mount-2.10o

Each time I want to access the cdrom or cdwriter I have to reboot w 2.2.17
where it works fine.

I've even tried with creating a generic block device
bayes:/dev# ls -l /dev/scg0 
brw-r--r--1 root root  21,   0 Nov 23 23:41 /dev/scg0

byes:/dev# mount -t iso9660 /dev/scg0 /cdrom
mount: /dev/scg0 has wrong major or minor number

Apart from this the 2.4.0-test kernels have been running very stable
for me. My systems are dual PII on ASUS PL97-DS and P2B-DS

According to Documentation/devices.txt nothing has changed according
major numbers for these devices from 2.2 to 2.4.

I'm grateful for any hint.

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

Re: Kernel bits

[Pavel Machek]

Hi!

> > Can't I run a i386 kernel on a ia64 machine? I know something like this
> > from HP-UX. You can choose between a 32 and a 64 bit kernel when
> > installing, so knowing that you have a 64 bit capable machine does not
> > say that you have a 64 bit kernel.
> > And I want to have the kernel bits, not the processor bits.
> 
>   Solaris runs 32-bit kernels on 64-bit UltraSPARCs
>   (up to Solaris version 2.6)
> 
>   So yes, something like that MAY be possible in case
>   of ia64, but somehow I doubt...

It definitely will be possible to run i386 linux on x86-64.

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

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

Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface

[Pavel Machek]

Hi!

> > I also agree that the ioctl patch is kind of a bandaid over
> > the problems that you described, and, while Zach Brown can speak
> 
> The biggest problem is that the current code is gross gross gross.
> I've been avoiding dealing with it too much in the hopes that moving to
> oss_audio will make things much more friendly across the board.

What is oss_audio? I thought alsa is going in in 2.5...
Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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

Re: *** ANNOUNCEMENT *** LVM 0.8.1 and LVM 0.9 available at www.sistina.com

[Pavel Machek]

Hi!

Perhaps yo should consider lowering number of stars in the subject.

> Linux Logical Volume Manager 0.8.1 (this is 0.8final plus patches)
> and 0.9 are available for download at www.sistina.com.

> Please see further information below, test it and help us
> to make an even better LVM for Linux :-)

Question i'd like to ask: what features are already present in 2.4.0-test11?

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

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

Re: Address translation

[Pavel Machek]

Hi!

> otherwise valid) I think the access macros are unnecessary. I would be
> *very* glad if someone could confirm this, or shoot me down. :)
> 
> For instance, a kernel module I am writing allocates some memory in
> the current process's address space as follows:
> 
> down(>mmap_sem);
> s->table = (void **)get_unmapped_area(0, SIZEOF_TABLE);
> if ( s->table != NULL )
> do_brk((unsigned long)s->table, SIZEOF_TABLE);
> up(>mmap_sem);
> 
> Some questions:
>  (1) In a "top half" thread, can I now access this memory without the
>  access macros (since I know the address range is valid)?
>  (2) Can I also access this memory from an interrupt/exception
>  context, or must I lock it? (ie. can faults be handled from such
>  a context) 

poof! I've shooted you.

You may definitely access such memory from interrupt.

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

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

Re: [PATCH] Reserved root VM + OOM killer

[Pavel Machek]

Hi!

> HOW?
> No performance loss, RAM is always fully utilized (except if no swap),

Handheld machines never have any swap, and alwys have little RAM [trust me,
velo1 I'm writing this on is so tuned that 100KB les and machine is useless].
 Unless reservation  can be turned off, it is not acceptable. Okay, it can
be tuned. Ok, then.

[What about making default reserved space 10% of *swap* size?]

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

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

Do you remember that oops which printed %lx instead of values?

[Pavel Machek]

Hi!

It happened to me today while debugging x86-64. That code probably
likes to fail this way ;-).
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

kernel_thread bogosity

[Pavel Machek]

Hi!

You see? Kernel_thread does not check is sys_clone() worked! Aha,
caller is responsible for that, but init/main.c does not seem too
carefull. Maybe kernel_thread should at least print a warning?

Plus, can someone explain me why it does not need to setup %%ecx with
either zero or address of stack?
Pavel

int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
{
long retval, d0;

__asm__ __volatile__(
"movl %%esp,%%esi\n\t"
"int $0x80\n\t" /* Linux/i386 system call */
"cmpl %%esp,%%esi\n\t"  /* child or parent? */
"je 1f\n\t" /* parent - jump */
/* Load the argument into eax, and push it.  That way,
it does
 * not matter whether the called function is compiled
with
 * -mregparm or not.  */
"movl %4,%%eax\n\t"
"pushl %%eax\n\t"
"call *%5\n\t"  /* call fn */
"movl %3,%0\n\t"/* exit */
"int $0x80\n"
"1:\t"
:"=" (retval), "=" (d0)
:"0" (__NR_clone), "i" (__NR_exit),
 "r" (arg), "r" (fn),
 "b" (flags | CLONE_VM)
: "memory");
return retval;
}

-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1

[Michael Elkins]

On Thu, Nov 23, 2000 at 05:49:52PM +0100, Georg Acher wrote:
> On Thu, Nov 23, 2000 at 04:35:33PM +, Rui Sousa wrote:
> > On Thu, 23 Nov 2000, Michael Elkins wrote:
> > 
> > Usb controller is sharing a interrupt with the emu10k1.
> > For what I know the emu10k1 driver doesn't have any problem
> > sharing irq's, so I would blame the usb driver...
> 
> usb-uhci doesn't also have any problem with sharing irqs:
> 
> > cat /proc/interrupts
>  10:5597981  XT-PIC  aic7xxx, eth0, usb-uhci
> 
> Hm, no one left to blame...
> I would debug it as follows:
> Place various printks in the initialization code (reset_hc(), start_hc() and
> alloc_uhci) and find out after which printk it hangs. Then it would be
> possible to investigate this further...

It hangs in start_uhci():

/* disable legacy emulation */
pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);

The loop that the call is in gets iterated 5 times.  For i < 4, the
if (!(dev->resource[i].flags & 1))
is TRUE, but on i==4, it drops into the bottom of the loop to execute
check_region() and then pci_write_config_word(), where it hangs.

This only seems to be a problem for initialization.  If  I load the
usb-uhci.o module before the emu10k1.o module, everything works perfectly
(no lockups).

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

Re: [PATCH] net drivers cleanup

[Alan Cox]

> - static unsigned char init_ID_done = 0, version_printed = 0;
> - int i, irq, irqval, retval;
> + static unsigned char init_ID_done, version_printed;
> + int i, irq, retval;
> 
> This is wrong because later we depend on assumption that
> these values are equal to 0 (they aren't autoinitialized to 0).

static starts at zero - its defined


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

Re: Address translation

[Bjorn Wesen]

On Thu, 23 Nov 2000, Andreas Bombe wrote:
> > I may be wrong on this, but I thought that copy_{to,from}_user are
> > only necessary if the address range you are accessing might cause a
> > fault which Linux cannot handle (ie. one which would cause the
> > application to segfault if it accessed that memory). If it is only a
> 
> It is wrong.  copy_*_user handle the page faults, whether they are good
> faults (swapped out, copy on write) or bad faults (illegal access).
> Without these macros you get the "unable to handle kernel page fault"
> oops message if a fault occurs.

Yes but only if it's a real fault, not if the address range actually is
a valid VMA which needs paging, COW'ing or related OS ops. copy_*_user
does not do the access in any different way than a "manual" access or
memcpy does, it just adds a .fixup section that tells the do_page_fault
handler that it should not segfault the kernel itself if the copy takes a
big fault at any point, instead it should jump to the fixup which makes
the copy routine return an error message.

However, the fixup stuff is not in-line with the copy code so there should
be absolutely no penalty using copy_*_user instead of a memcpy
(provided the copy_*_user is as optimized as the memcpy code), and it's
dangerous to assume anything about pages visible in user-space, they might
be unmapped by another thread while you're doing that memcpy etc.

> >  (1) In a "top half" thread, can I now access this memory without the
> >  access macros (since I know the address range is valid)?
> 
> The address is valid, the pages probably aren't.  In fact, extending the
> address space only creates read-only mappings to the global zeroed page
> if I remember right.

But it does not matter that the pages aren't there physically, any kind of
access (including an access from kernel-mode) will bring about the same
COW/change-on-write mechanism as copy_to_user or a user-mode access would.

The problem is rather that between your do_brk and when you access the
pages, a thread in the process might do an unmap or brk to remove the
mapping, then you crash the kernel.

> >  (2) Can I also access this memory from an interrupt/exception
> >  context, or must I lock it? (ie. can faults be handled from such
> >  a context) 
> 
> You can't even use copy_*_user in this context (since the current user
> space might be any process, even kernel threads that have no user space
> at all).
> 
> For access to user memory from interrupt context at all and to access
> user memory without the uaccess macros, you have to lock them down in
> memory, with map_user_kiobuf().  This is only recommended if you want
> hardware to DMA to/from buffers provided by user space.

Yup, if you are in the wrong context or in an interrupt context you'll die
horribly if you try to access user-pages that aren't there:

if (in_interrupt() || !mm)
goto no_context;

So you need to 1) make sure the pages are in physical memory and 2) make
sure the pages won't get removed from under your feet at any time and 3)
access them using their physical address

> >  (3) Is the above code sensible at all, or barking? It took me a while
> >  to figure that the above would work, and I think/hope it is the
> >  most elegant way to share memory between kernel and a process.
> 
> It will fail quickly, probably taking the kernel down with it.
> 
> The most elegant way to share memory between user and kernel is to
> allocate the memory in the kernel and map it to user space (by
> implementing mmap  on the kernel side for the file used for
> communication).

Agreed, but that does not cut it for some applications. For example, let's
say you want to grab 16 MB of video frames without copying them from that
mmap area to your malloc'ed 16 MB (let's say your CPU takes a pretty big
hit doing that extra memcpy) and you'd like to DMA directly into the
user-pages. 

You can of course make the kernel grab 16 MB worth of pages for you and
then mmap them into the process, but the kernel driver would be pretty
hooked to that demanding user process then.. 

Actually I'm trying to figure out the best way to do a similar thing for
some hardware we have - I have incoming DMA data containing JPG grabs, and
I want to cache images in a user-mode daemon, which will send pictures
from the cache out on TCP. The images might be generated with many
different JPG settings so they need right tags in the cache etc. 

Before when we ran on a chip without MMU this was easy - that user-mode
buffer was a contigous physical area which I could DMA directly in. But
now when we're going to a CPU with MMU, it gets more complicated of course
:) 

I have figured the options are

1) let the kernel driver have a buffer big enough for a single grab, mmap
this into user-space and do the memcpy into the cache (might be fast
enough, but our chip isn't super on memcpy's..)

2) let the kernel driver lock down the user-pages in an access and DMA
directly 

Re: [PATCH] net drivers cleanup

[Bartlomiej Zolnierkiewicz]

Hi

patch-3c503:
@@ -307,11 +307,12 @@
 {
ei_status.tx_start_page = EL2_MB1_START_PG;
ei_status.rx_start_page = EL2_MB1_START_PG + TX_PAGES;
-   printk("\n%s: %s, %dkB RAM, using programmed I/O (REJUMPER for SHARED 
MEMORY).\n",
-  dev->name, ei_status.name, (wordlength+1)<<3);
+   printk( KERN_ERR "\n%s: %s, %dkB RAM, using programmed I/O (REJUMPER for 
+SHARED MEMORY).\n",
-->   ^^ superfluous
+   dev->name, ei_status.name, (wordlength+1)<<3);

Either remove this '\n' or change to ("\n" KERN_ERR "%s...\n").


patch-3c507:
@@ -323,8 +323,8 @@
 
 static int __init el16_probe1(struct net_device *dev, int ioaddr)
 {
-   static unsigned char init_ID_done = 0, version_printed = 0;
-   int i, irq, irqval, retval;
+   static unsigned char init_ID_done, version_printed;
+   int i, irq, retval;

This is wrong because later we depend on assumption that
these values are equal to 0 (they aren't autoinitialized to 0).


patch-lne390:
@@ -121,14 +121,14 @@
 
if (!EISA_bus) {
 #if LNE390_DEBUG & LNE390_D_PROBE
-   printk("lne390-debug: Not an EISA bus. Not probing high ports.\n");
+   printk(kern_debug "lne390-debug: Not an EISA bus. Not probing high 
+ports.\n");
   ^^ should be KERN_DEBUG of course ;)


patch-wd:
@@ -124,7 +124,7 @@
int ancient = 0;/* An old card without config 
registers. */
int word16 = 0; /* 0 = 8 bit, 1 = 16 bit */
const char *model_name;
-   static unsigned version_printed = 0;
+   static unsigned version_printed;

This is wrong because later we depend on assumption that
version_printed is equal to 0 (it isn't autoinitialized to 0).


Regards
--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>

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

Re: [NEW DRIVER] firestream

[Bartlomiej Zolnierkiewicz]

Hi!

Just a few hints on __init/__exit stuff...

On Wed, 22 Nov 2000, Patrick van de Lageweg wrote:

> +struct reginit_item PHY_NTC_INIT[] = {

Can be marked __initdata

> +void undocumented_pci_fix (struct pci_dev *pdev)

Can be marked __init

> +void write_phy (struct fs_dev *dev, int regnum, int val)

Can be marked __init

> +int init_phy (struct fs_dev *dev, struct reginit_item *reginit)

Can be marked __init

> +void *aligned_kmalloc (int size, int flags, int alignment)

Can be marked __init

> +int init_q (struct fs_dev *dev, 
> + struct queue *txq, int queue, int nentries, int is_rq)

Can be marked __init

> +int init_fp (struct fs_dev *dev, 
> +  struct freepool *fp, int queue, int bufsize, int nr_buffers)

Can be marked __init

> +void free_queue (struct fs_dev *dev, struct queue *txq)

Can be marked __exit

> +void free_freepool (struct fs_dev *dev, struct freepool *fp)

Can be marked __exit


You may also consider processing firestream.[ch] through indent because
spacing is inconsistent - sometimes tabs, sometimes 8*space (it would
be nice too have tabs everywhere).

Regards
--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>


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

2.2.18pre, usb mouse messages

[f5ibh]

Hi,

I use an USB mouse, it works perfectly both with 'gpm' and with X-window but
time to time, I've this kind of message stream :

[root@debian-f5ibh] ~ # usb-uhci.c: interrupt, status 3, frame# 20
usb-uhci.c: interrupt, status 3, frame# 44
usb-uhci.c: interrupt, status 3, frame# 68
usb-uhci.c: interrupt, status 3, frame# 92
usb-uhci.c: interrupt, status 3, frame# 116
usb-uhci.c: interrupt, status 3, frame# 140
usb-uhci.c: interrupt, status 3, frame# 164
usb-uhci.c: interrupt, status 3, frame# 188
usb-uhci.c: interrupt, status 3, frame# 212
hub.c: already running port 2 disabled by hub (EMI?), re-enabling...

This message appears with most (all ?) of the 2.2.18pre releases, the actual
one is 2.2.18pre23.

Computer is pentium 200MMX, 64Mb SDRAM.

Relevant CONFIG bits :
--
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_HOTPLUG=y
# CONFIG_USB_BANDWIDTH is not set

#
# USB Controllers
#
CONFIG_USB_UHCI=m
# CONFIG_USB_UHCI_ALT is not set
# CONFIG_USB_OHCI is not set

#
# USB Devices
#
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_PLUSB is not set
# CONFIG_USB_PEGASUS is not set
#
# USB HID
#
CONFIG_USB_HID=m
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_WMFORCE is not set
# CONFIG_INPUT_KEYBDEV is not set
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set


boot messages :
---
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb.c: registered new driver hid
usb-uhci.c: $Revision: 1.237 $ time 23:53:07 Nov 23 2000
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: USB UHCI at I/O 0x6100, IRQ 11
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
usb.c: USB new device connect, assigned device number 1
hub.c: USB hub found
hub.c: 2 ports detected
mice: PS/2 mouse device common for all mice
usb.c: USB new device connect, assigned device number 2
mouse0: PS/2 mouse device for input0
input0: USB HID v1.00 Mouse [Cypress Sem. Cypress USB Mouse] on usb1:2.0
hub.c: already running port 2 disabled by hub (EMI?), re-enabling...
usb.c: USB disconnect on device 2
usb.c: USB new device connect, assigned device number 2
mouse0: PS/2 mouse device for input0
input0: USB HID v1.00 Mouse [Cypress Sem. Cypress USB Mouse] on usb1:2.0


Regards

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

Re: {PATCH} isofs stuff

[Alexander Viro]

On Thu, 23 Nov 2000, Matti Aarnio wrote:

> On Thu, Nov 23, 2000 at 12:38:55PM -0800, Linus Torvalds wrote:
> ... 
> > In fact, almost all filesystems do this at some point. ext2 does it for
> > directories too, for some very similar reasons that isofs does. See
> > fs/ext2/dir.c:
> > 
> > blk = (filp->f_pos) >> EXT2_BLOCK_SIZE_BITS(sb);
> > 
> > (and don't ask me about the extraneous parenthesis. I bet some LISP
> > programmer felt alone and decided to make it a bit more homey).
> > 
> > Linus
> 
>Propably some programmer has been bitten once too many times with
>C's operator precedence rules, which only affect more complicated
>expressions -- and thus are used rarely, and not remembered well.

Come again?  Precedence or not, how in hell could anything be stronger than
-> or . on the _right_ side? Field names are atoms, you can't have an
expression there...

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

Recent ide patches and DMA

[Kafu Nagai]

With recent ide patches, the ide driver seems to try to use DMA mode even for a drive 
which dosen't support it. CONFIG_IDEDMA_PCI_AUTO is enabled but even so with the stock 
kernel this dosen't happen. older patches didn't have this behavior either. Is this 
change intentional ?

hdc: 333630 sectors (171 MB) w/32KiB Cache, CHS=1011/15/22, DMA
Partition check:
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >
 hdc:hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x04 { DriveStatusError }
hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x04 { DriveStatusError }
hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x04 { DriveStatusError }
hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x04 { DriveStatusError }
hdc: DMA disabled
ide1: reset: success
 hdc1

~ $ hdparm -i /dev/hdc
 
/dev/hdc:
 
 Model=QUANTUM ELS170A, FwRev=4.20, SerialNo=166304085456
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>5Mbs RotSpdTol>.5% }
 RawCHS=1011/15/22, TrkSize=11264, SectSize=512, ECCbytes=4
 BuffType=3(DualPortCache), BuffSize=32kB, MaxMultSect=8, MultSect=off
 DblWordIO=no, OldPIO=2, DMA=no
 CurCHS=1011/15/22, CurSects=333629, LBA=no 


This may not be a major problem, as nobody probably uses such an obsolete drive 
nowadays.
 
The following patches have been tried:

ide.2.2.18-22.all.20001120
ide.2.4.0-t11.1120.patch


Free Web space and web based email @EASYNEWS.COM


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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Mohammad A. Haque]

I'm still trying to reproduce the darn thing w/o the patch. No luck so
far.

Maybe I'll put some mission critical stuff on my machine. Then it'll pop
up like clock works. Thats the way everythign is supposed to work right?
=)

Tigran Aivazian wrote:
> However, I can't say that _without_ your patch the above did _not_
> survive. The corruptions usually come from real useful work and not from
> articfical tests (unfortunately)

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Raising MAX_UNITS in net drivers oopses kernel reproducibly

[Pekka Savola]

Hello all,

Using RHL 2.2.16-3 kernel on i686.

Raising MAX_UNITS define from 8 to 16 or 32 in net drivers (tested
tulip.c) causes reproducible oops.  The latest Don Becker driver also does
this.  Using DFE-570TX quad ethernet cards.

So, why change MAX_UNITS?  Interfaces 9-> can't be passed options=,
full_duplex= or similar parameters otherwise.  The actual interfaces
should work in autonegotiation though.

I've gotten this crash every time.  It can be done as follows:

1) recompile a new tulip module with changed MAX_UNITS.
2) insmod the module
3) take one interface up, with e.g. ifup eth0. [note: traffic doesn't go
anywhere]
4) try to take the interface down, with e.g. ifconfig eth0
5) watch oops in your syslog.

Previous message on syslog was 'Trying to free free IRQ9'.

See below:
-
Unable to handle kernel paging request at virtual address 109f
current->tss.cr3 = 01d69000, %%cr3 = 01d69000
*pde = 
Oops: 
CPU:0
EIP:0010:[de4x5:de4x5_probe+24259/37172]
EFLAGS: 00010282
eax: c4056f00   ebx: 1043   ecx: 0246   edx: 
esi: 1043   edi: c38cc5a0   ebp: c103deb4   esp: c103deac
ds: 0018   es: 0018   ss: 0018
Process ifconfig (pid: 1924, process nr: 7, stackpage=c103d000)
Stack:  c38cc480 1042 c014fe92 c38cc5a0 1043 c38cc5a0 c0150980
   c38cc5a0 c29c6300 1042 c29c6324 c103df40 c0170f9c c38cc5a0 1042
   8914 8914 b9f4 c2671740 8913  c103df40 c0150ee9
Call Trace: [dev_close+78/156] [dev_change_flags+80/268] [devinet_ioctl+620/1404] 
[dev_ioctl+337/792] [inet_ioctl+294/412] [free_pages+36/40] [sock_ioctl+29/36]
   [sys_ioctl+421/448] [system_call+52/56]
Code: 8b 56 5c 31 c0 0f ab 46 24 19 c0 85 c0 74 29 a1 80 47 21 c0
-

Note! EIP shows de4x5 for some reason.  Please note that de4x5 driver
also "works" with this card.  The driver is _really_ buggy with it though.
With Don Becker drivers the output is about the same; EIP is
__insmod_tulip_S and Call Trace: begins with dev_deactivate.


Any ideas?  _Should_ raising MAX_UNITS work as I described or are there
any known problems with it?

Please Cc:.

-- 
Pekka Savola "Tell me of difficulties surmounted,
[EMAIL PROTECTED]  not those you stumble over and fall"


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

mm->rss modified without the page_table_lock (revisited)

[Rasmus Andersen]

Hi.

Some time ago there was a thread about subject and a patch was posted
(by davej?). It was rejected because of the vmlist_modify_{un}lock
mess (AFAIR) and nothing has been done since. The first patch below 
moves mm->rss inside the page_table_lock in mm/. 

I noticed that mm->rss is also modified in fs/{exec.c,binfmt_aout.c,
binfmt_elf.c} without the lock being held. Am I missing something or
are these buggy too? I have no idea of what assumptions can be made
in these code paths so I have not tried to produce patches for them.

Patch against 240-test11. Please comment.


diff -uar linux-240-t11/mm/memory.c linux/mm/memory.c
--- linux-240-t11/mm/memory.c   Wed Nov 22 22:41:45 2000
+++ linux/mm/memory.c   Thu Nov 23 21:45:58 2000
@@ -369,7 +369,6 @@
address = (address + PGDIR_SIZE) & PGDIR_MASK;
dir++;
} while (address && (address < end));
-   spin_unlock(>page_table_lock);
/*
 * Update rss for the mm_struct (not necessarily current->mm)
 * Notice that rss is an unsigned long.
@@ -378,6 +377,7 @@
mm->rss -= freed;
else
mm->rss = 0;
+   spin_unlock(>page_table_lock);
 }
 
 
@@ -1074,7 +1074,9 @@
flush_icache_page(vma, page);
}
 
+   spin_lock(>page_table_lock);
mm->rss++;
+   spin_unlock(>page_table_lock);
 
pte = mk_pte(page, vma->vm_page_prot);
 
@@ -1113,7 +1115,9 @@
return -1;
clear_user_highpage(page, addr);
entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot)));
+   spin_lock(>page_table_lock);
mm->rss++;
+   spin_unlock(>page_table_lock);
flush_page_to_ram(page);
}
set_pte(page_table, entry);
@@ -1152,7 +1156,9 @@
return 0;
if (new_page == NOPAGE_OOM)
return -1;
+   spin_lock(>page_table_lock);
++mm->rss;
+   spin_unlock(>page_table_lock);
/*
 * This silly early PAGE_DIRTY setting removes a race
 * due to the bad i386 page protection. But it's valid
diff -uar linux-240-t11/mm/mmap.c linux/mm/mmap.c
--- linux-240-t11/mm/mmap.c Wed Nov 22 22:41:45 2000
+++ linux/mm/mmap.c Thu Nov 23 21:45:58 2000
@@ -889,8 +889,8 @@
spin_lock(>page_table_lock);
mpnt = mm->mmap;
mm->mmap = mm->mmap_avl = mm->mmap_cache = NULL;
-   spin_unlock(>page_table_lock);
mm->rss = 0;
+   spin_unlock(>page_table_lock);
mm->total_vm = 0;
mm->locked_vm = 0;
while (mpnt) {
diff -uar linux-240-t11/mm/swapfile.c linux/mm/swapfile.c
--- linux-240-t11/mm/swapfile.c Sat Nov  4 23:27:17 2000
+++ linux/mm/swapfile.c Thu Nov 23 21:45:58 2000
@@ -231,7 +231,9 @@
set_pte(dir, pte_mkdirty(mk_pte(page, vma->vm_page_prot)));
swap_free(entry);
get_page(page);
+   spin_lock(>vm_mm->page_table_lock);
++vma->vm_mm->rss;
+   spin_unlock(>vm_mm->page_table_lock);
 }
 
 static inline void unuse_pmd(struct vm_area_struct * vma, pmd_t *dir,
diff -uar linux-240-t11/mm/vmscan.c linux/mm/vmscan.c
--- linux-240-t11/mm/vmscan.c   Wed Nov 22 22:41:45 2000
+++ linux/mm/vmscan.c   Thu Nov 23 21:45:58 2000
@@ -95,7 +95,9 @@
set_pte(page_table, swp_entry_to_pte(entry));
 drop_pte:
UnlockPage(page);
+   spin_lock(>page_table_lock);
mm->rss--;
+   spin_unlock(>page_table_lock);
flush_tlb_page(vma, address);
deactivate_page(page);
page_cache_release(page);


-- 
Regards,
Rasmus([EMAIL PROTECTED])

Gates' Law: Every 18 months, the speed of software halves
  -- Anonymous
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Tigran Aivazian]

Hi Alexander,

I am "hammering" an ext2 filesystem with all sorts (bonnies, make -j8
bzImage, cp -a dir1 dir2 + all these over localhost NFSv3) for a while and
so far it survives. The system is 2way SMP with 1G RAM.

However, I can't say that _without_ your patch the above did _not_
survive. The corruptions usually come from real useful work and not from
articfical tests (unfortunately)

Regards,
Tigran

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

Re: Address translation

[Andreas Bombe]

On Wed, Nov 22, 2000 at 09:39:51PM +, Keir Fraser wrote:
> > The reason that everyone else uses copy_{to,from}_user is that there
> > is no way to guarantee that the userspace pointer is valid. That
> > memory may have been swapped out. The copy macros are prepared to
> > fault the memory in. The rest of the kernel is not.
> >
> > Jeff
> 
> I may be wrong on this, but I thought that copy_{to,from}_user are
> only necessary if the address range you are accessing might cause a
> fault which Linux cannot handle (ie. one which would cause the
> application to segfault if it accessed that memory). If it is only a
> matter of paging the memory in (and you are _sure_ the address range is
> otherwise valid) I think the access macros are unnecessary. I would be
> *very* glad if someone could confirm this, or shoot me down. :)

It is wrong.  copy_*_user handle the page faults, whether they are good
faults (swapped out, copy on write) or bad faults (illegal access).
Without these macros you get the "unable to handle kernel page fault"
oops message if a fault occurs.

> For instance, a kernel module I am writing allocates some memory in
> the current process's address space as follows:
> 
> down(>mmap_sem);
> s->table = (void **)get_unmapped_area(0, SIZEOF_TABLE);
> if ( s->table != NULL )
> do_brk((unsigned long)s->table, SIZEOF_TABLE);
> up(>mmap_sem);
> 
> Some questions:
>  (1) In a "top half" thread, can I now access this memory without the
>  access macros (since I know the address range is valid)?

The address is valid, the pages probably aren't.  In fact, extending the
address space only creates read-only mappings to the global zeroed page
if I remember right.

>  (2) Can I also access this memory from an interrupt/exception
>  context, or must I lock it? (ie. can faults be handled from such
>  a context) 

You can't even use copy_*_user in this context (since the current user
space might be any process, even kernel threads that have no user space
at all).

For access to user memory from interrupt context at all and to access
user memory without the uaccess macros, you have to lock them down in
memory, with map_user_kiobuf().  This is only recommended if you want
hardware to DMA to/from buffers provided by user space.

>  (3) Is the above code sensible at all, or barking? It took me a while
>  to figure that the above would work, and I think/hope it is the
>  most elegant way to share memory between kernel and a process.

It will fail quickly, probably taking the kernel down with it.

The most elegant way to share memory between user and kernel is to
allocate the memory in the kernel and map it to user space (by
implementing mmap  on the kernel side for the file used for
communication).

-- 
 Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: {PATCH} isofs stuff

[Matti Aarnio]

On Thu, Nov 23, 2000 at 12:38:55PM -0800, Linus Torvalds wrote:
... 
> In fact, almost all filesystems do this at some point. ext2 does it for
> directories too, for some very similar reasons that isofs does. See
> fs/ext2/dir.c:
> 
>   blk = (filp->f_pos) >> EXT2_BLOCK_SIZE_BITS(sb);
> 
> (and don't ask me about the extraneous parenthesis. I bet some LISP
> programmer felt alone and decided to make it a bit more homey).
> 
>   Linus

   Propably some programmer has been bitten once too many times with
   C's operator precedence rules, which only affect more complicated
   expressions -- and thus are used rarely, and not remembered well.
   (Or perhaps rememberance is felt to be weak, and parenthesis solve it.)

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

Re: {PATCH} isofs stuff

[Linus Torvalds]

On Thu, 23 Nov 2000, Andi Kleen wrote:
> 
> I am actually not sure if the normal kernel contains even a variable
> width long long shift.

Sure it does. The isofs code contains exctly that:

block = filp->f_pos >> bufbits;

In fact, almost all filesystems do this at some point. ext2 does it for
directories too, for some very similar reasons that isofs does. See
fs/ext2/dir.c:

blk = (filp->f_pos) >> EXT2_BLOCK_SIZE_BITS(sb);

(and don't ask me about the extraneous parenthesis. I bet some LISP
programmer felt alone and decided to make it a bit more homey).

Linus

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

Re: [PATCH] Documentacion proc.txt update (2.4.x)

[Mike A. Harris]

On Tue, 21 Nov 2000, Jorge Nerin wrote:

>> How about a working URL?
>>
>> traceroute to skaro.nightcrawler.com (216.186.140.118), 30 hops max, 38 byte packets
>> [...]
>> 11  pos3-0-0-155M.sjc-bb3.cerf.net (134.24.29.26)  66.400 ms  74.860 ms  68.486 ms
>> 12  dslnetworks1.dslnetworks.com (206.19.42.193)  105.303 ms  86.436 ms  68.749 ms
>> 13  206.16.72.114 (206.16.72.114)  79.867 ms  63.365 ms  59.919 ms
>> 14  * * *
>> 15  * * *
>>
>> -Dan
>
>Well, the URL came with the text, it was there before me ;-) I didn't
>work for me either, but I left it because I don't have a URL with the
>updated version online, even I don't have an updated version, I had to
>do it myself.
>
>I have left it because I don't have replies from the author nor from the
>website.

No information is always better than misinformation.

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

And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies.
  -- Linus Torvalds

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

Re: silly [< >] and other excess

[Russell King]

Albert D. Cahalan writes:
> Also, cross-arch debugging is done by people who don't need tools
> like ksymoops anyway. Most likely they have half the opcodes
> memorized already, and they have the CPU manual open on their desk.

I certainly don't have each of the 4 billion opcode combinations on
the ARM memorised, and I've been hacking ARM code for over 12 years
now.

> I threw together a semi-working prototype in a few hours.
> It is the worst code I ever wrote in my life, not even
> excluding stuff I wrote in Atari BASIC. It slurps down log
> files pretty well though, and proves "[<>]" is unneeded.

Oh, how have you proven it?  Have you proven it with that ARM oops
that appeared on this list?  How do you know that it has produced
the right output for the developers?
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: VMWare will not run on kernel 2.4.0-test11

[Alan Cox]

> vmware-2.0.3-786 refused to run.  Running vmware-config.pl resulted in a
> the following message:

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

Re: VMWare will not run on kernel 2.4.0-test11

[Jan Dvorak]

On Thu, Nov 23, 2000 at 12:07:01PM -0800, Phil Stracchino wrote:
> I just compiled and installed kernel 2.4.0-test11.  Upon rebooting,
> vmware-2.0.3-786 refused to run.  Running vmware-config.pl resulted in a
> the following message:
> 
>   "Your processor does not have a Time Stamp Counter. VMware will
>not run on this system."
> 
> Since (1) my hardware has not changed, (2) this VMware release ran
> perfectly on 2.4.0-test10, and (3) I changed nothing but the kernel in
> between 2.4.0-test10 and 2.4.0-test11, I feel quite confident in believing
> that I do indeed possess a Time Stamp Counter (whatever such a fabulous
> beast may be), but for some reason VMware is unable to detect its presence
> when running on kernel 2.4.0-test11.  Evidently there has been some change
> in the kernel which renders VMware unable to detect this mysterious - but
> apparently crucial - feature.
> 
> 
> I would appreciate any insights from either kernel folks or VMware folks
> as to where this problem may lie, with an eventual aim of patching either
> VMware or the kernel to allow VMware to run on this kernel.
>

It's probably due to /proc/cpuinfo change - 'flags' has changed to 'features'.

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

Re: silly [< >] and other excess

[Tuomas Heino]

On Thu, 23 Nov 2000, Charles Cazabon wrote:

> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> > > Thats because too many things get put on a line then.
> > > And because we do [] []  not   [][] ?
> > 
> > In the good old times we had  foo bar  for a total of 8*(8+1) = 72
> > positions. Now we have [] [] which takes 8*(8+1+4) = 104
> > positions. If you turned this into 6 items per line instead of 8,
> > it would certainly improve matters a bit.
> 
> The original poster complained the output lines were too wide for the screen
> on his PC.  Perhaps he should change his console mode to 132 characters wide
> (via SVGATextMode or such) -- voila, no more problem, no broken kernel patches.

Well that 72 characters is also known as the "safe" email line length...
... and besides some people still use the old VT330s and alike ;)

But in practice even those 79 chars would be better than 104.

--
No .sig here... especially no 128x48 .sig here - nor 132xYuch...

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

Re: VMWare will not run on kernel 2.4.0-test11

[Mohammad A. Haque]

Tiny patch for vmware-config.pl

Phil Stracchino wrote:
> 
> I just compiled and installed kernel 2.4.0-test11.  Upon rebooting,
> vmware-2.0.3-786 refused to run.  Running vmware-config.pl resulted in a
> the following message:
> 
> "Your processor does not have a Time Stamp Counter. VMware will
>  not run on this system."
> 

-- 

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

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

--- vmware-config.pl.oldThu Nov 23 15:12:32 2000
+++ vmware-config.plThu Nov 23 15:12:55 2000
@@ -1113,7 +1113,7 @@
   if (direct_command(shell_string($gHelper{'grep'}) . ' ' . shell_string('^cpuid') . 
' /proc/cpuinfo') eq '') {
 error('Your ' . (($gSystem{'smp'} eq 'yes') ? 'processors do' : 'processor does') 
. ' not support the cpuid instruction. VMware will not run on this system.' . "\n\n");
   }
-  if (direct_command(shell_string($gHelper{'grep'}) . ' ' . shell_string('^flags.* 
tsc') . ' /proc/cpuinfo') eq '') {
+  if (direct_command(shell_string($gHelper{'grep'}) . ' ' . shell_string('^features.* 
+tsc') . ' /proc/cpuinfo') eq '') {
 error('Your ' . (($gSystem{'smp'} eq 'yes') ? 'processors do' : 'processor does') 
. ' not have a Time Stamp Counter. VMware will not run on this system.' . "\n\n");
   }
 }

Re: alloc_tty_struct() question.

[Andi Kleen]

On Thu, Nov 23, 2000 at 06:54:48PM +, Tigran Aivazian wrote:
> Hi,
> 
> The sizeof(struct tty_struct) = 3084. Why don't we have a private slab
> cache for it instead of getting a page and wasting some precious bytes at
> the end? Potentially, we can have thousands of tty_struct allocated
> (assuming we have thousands of concurrent users)...

A slab cache could only save significant memory if it allocated in 
order 2 slabs (order 1 would waste exactly the same memory because 
you only had a ~2K gap) Order 2 is nasty and unreliable.


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

Re: {PATCH} isofs stuff

[Andi Kleen]

On Thu, Nov 23, 2000 at 08:59:46AM -0800, Linus Torvalds wrote:
> [ Btw, I noticed that one of my machines _does_ have gcc-2.95.2, so I can
>   look at the isofs code generation myself.  I don't see anything obvious,
>   and the code is hairy. The differences between 2.91.66 and 2.95.2 are
>   big enough that a plain "diff" doesn't show anything clear. Andi, what
>   does your test-case look like? ]

Just a variable width shift of long long with both arguments fetched
from deep indirection via pointers, and that all in a function with
register pressure (extracted from the XFS source, which does all kinds
of nasty things with long long) 

I am actually not sure if the normal kernel contains even a variable
width long long shift.

-Andi (who also sees some strange hangs in 2.4.0test11-pre, but more
suspects his own hacks. no fs corruption, but I do not run dbench normally) 

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

Re: RFC: Modularize /proc/partitons (was Re: /proc/partitions for LVM)

[Brian Kress]

"Heinz J. Mauelshagen" wrote:
> 
> On Wed, Nov 22, 2000 at 04:27:51PM -0500, Brian Kress wrote:
> > "Heinz J. Mauelshagen" wrote:
> > >
> > > On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote:
> > > >   Question about /proc/partitions and LVM.  LVM devices in
> > > > /proc/partitions currently show up as lvma, lvmb, etc, depending on
> > > > their device number.  This breaks things like mount by filesystem
> > > > name.  Back when LVM existed as a patch, I believe there was some
> > > > support in fs/partitions/check.c for showing the proper name for
> > > > the device (something like /).
> > >
> > > Yes.
> > > It actually was /.
> > >
> > > Linus didn't accept it though.
> > >
> > > The code is still available in case he changes his mind.
> >
> >   Yes, I can see that now looking through lvm.c.  (LVM_HD_NAME)
> > I'm guessing why he didn't take it is the minor hack of adding a
> > function pointer to genhd.c as a special case just for LVM.
> >   A general solution to this problem would be nice.  The
> > big switch statement in disk_name in fs/paritions/check.c is kind
> > of ugly as it has generic code have to know things about specific
> > drivers.
> 
> Yep.
> 
> >   How's this for an idea to generalize this.  Put a function
> > pointer in the gendisk structure for a specific function to call
> > for disk_name for disks for that gendisk.
> 
> Sounds resonable to me.
> 
> > That way, LVM gets its
> > /, IDE gets its two disks per major (special cased
> > right now), all the other special cases get what they need and future
> > drivers can call their devices whatever they like without touching
> > this file.  Makes the whole thing more modular.  Make a NULL for
> > this function default to the old a, b, etc.
> >   What to people think about this?  If this sounds reasonable
> > I can come up with a patch.
> 
> Very good. I'ld appreciate it.
> 


OK, here's the patch.  It has three sets of changes:

1)  Add a function pointer to struct gendisk called hd_name.

2)  Make disk_name in fs/partitions/check.c use that function
pointer if its non-null.

3)  Change the following drivers to use this method. (adding the
driver specific method and removing the old code in check.c)

drivers/md/lvm.c
drivers/md/md.c
drivers/ide/ide-probe.c
drivers/scsi/sd.c
drivers/block/cpqarray.c
drivers/block/cciss.c
drivers/block/DAC960.c


Let me know what you think.  Think there's any chance we
can get this in the main kernel tree?


Brian Kress
[EMAIL PROTECTED]

diff -u --recursive linux-2.4.0-test11/drivers/block/DAC960.c 
linux-2.4.0-test11-ppfix/drivers/block/DAC960.c
--- linux-2.4.0-test11/drivers/block/DAC960.c   Mon Nov 20 15:17:25 2000
+++ linux-2.4.0-test11-ppfix/drivers/block/DAC960.c Thu Nov 23 14:29:37 2000
@@ -1885,6 +1885,21 @@
 }
 
 
+char *DAC960_disk_name(struct gendisk *hd, int minor, char *buf)
+
+{
+   int ctlr = hd->major - DAC960_MAJOR;
+   int disk = minor >> hd->minor_shift;
+   int part = minor & ((1 << hd->minor_shift) - 1);
+
+   if (part)
+   sprintf(buf, "%s/c%dd%dp%d", hd->major_name, ctlr, disk, part);
+   else
+   sprintf(buf, "%s/c%dd%d", hd->major_name, ctlr, disk);
+   return buf;
+}
+
+
 /*
   DAC960_RegisterBlockDevice registers the Block Device structures
   associated with Controller.
@@ -1945,6 +1960,7 @@
   Controller->GenericDiskInfo.nr_real = Controller->LogicalDriveCount;
   Controller->GenericDiskInfo.next = NULL;
   Controller->GenericDiskInfo.fops = _BlockDeviceOperations;
+  Controller->GenericDiskInfo.hd_name = DAC960_disk_name;
   /*
 Install the Generic Disk Information structure at the end of the list.
   */
diff -u --recursive linux-2.4.0-test11/drivers/block/cciss.c 
linux-2.4.0-test11-ppfix/drivers/block/cciss.c
--- linux-2.4.0-test11/drivers/block/cciss.cMon Nov 20 15:17:25 2000
+++ linux-2.4.0-test11-ppfix/drivers/block/cciss.c  Thu Nov 23 14:22:55 2000
@@ -1749,6 +1749,20 @@
kfree(size_buff);
 }  
 
+char *cciss_disk_name(struct gendisk *hd, int minor, char *buf)
+
+{
+   int ctlr = hd->major - COMPAQ_CISS_MAJOR;
+   int disk = minor >> hd->minor_shift;
+   int part = minor & ((1 << hd->minor_shift) - 1);
+
+   if (part)
+   sprintf(buf, "%s/c%dd%dp%d", hd->major_name, ctlr, disk, part);
+   else
+   sprintf(buf, "%s/c%dd%d", hd->major_name, ctlr, disk);
+   return buf;
+}
+
 /*
  *  This is it.  Find all the controllers and register them.  I really hate
  *  stealing all these major device numbers.
@@ -1851,6 +1865,7 @@
hba[i]->gendisk.part = hba[i]->hd;
hba[i]->gendisk.sizes = hba[i]->sizes;
hba[i]->gendisk.nr_real = hba[i]->num_luns;
+   hba[i]->gendisk.hd_name = cciss_disk_name;
 
/* Get on the disk list */ 
hba[i]->gendisk.next = gendisk_head;
diff -u --recursive linux-2.4.0-test11/drivers/block/cpqarray.c 

Re: Strange lockup of the timer with 2.4.0-test10 SMP (and older)

[Benjamin Monate]

Dans son message du Thu 23 November, Maciej W. Rozycki ecrit : 
>  Hmm, your BIOS reports the timer IRQ is directly connected...
> > Int: type 0, pol 3, trig 3, bus 2, IRQ 09, APIC ID 2, APIC INT 09
>  This is weird for an ISA IRQ.

Remember that I have TWO PCI buses and one ISA Bus.

>
> > ENABLING IO-APIC IRQs
> > ...changing IO-APIC physical APIC ID to 2 ... ok.
> > BIOS bug, IO-APIC#1 ID 3 is already used!...
> > ... fixing up to 1. (tell your hw vendor)
> > ...changing IO-APIC physical APIC ID to 1 ... ok.
>  This is annoying but Linux recovers from it...

Yes. I had to patch 2.4.0pre2 to be able to boot, but now it boots
unpatched. 
Why do you mean by "annoying" ? I thought this was just an
initialization problem.
By the way, my BIOS has an option to choose between MP 1.4 or older 
specifications. Changing it has not changed anything to the problem.

 
> > ..TIMER: vector=49 pin1=2 pin2=0
> > ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> > ...trying to set up timer (IRQ0) through the 8259A ... 
> > . (found pin 0) ...works.
> 
>  At the moment I can't see any reason of this failure apart from pin1
> being unconnected.  But why would it be?  I'll prepare a debugging patch
> which might help finding the real cause and I'll send it to you soon.

Okay. Thank you very much.

>  BTW, have you checked if there is a BIOS update for your system?

I will check that with Asus. At this time I have BIOS 1002.

-- 
| Benjamin Monate | mailto:[EMAIL PROTECTED] |
| LRI - Bât. 490
| Université de Paris-Sud
| F-91405 ORSAY Cedex

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

Power-off doesn't work in 2.4.0test11

[H.J.Visser]

Hi,

Since I use kernel 2.4.0(test11) the power-off on halt doesn't work 
anymore (I have the same problem with previous 2.4.0 releases).

I use apm to power-off the system (my system doesn't support acpi) and 
with kernel 2.2.17 everything works great. But since I've compiled 
2.4.0test11 with exactly the same configuration, my system doesn't 
power-off anymore.

I use a celeron 266@400MHz with a BX-pro mainboard with an ALi chipset.

Does anyone know how I get my system to power-off again?

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

Re: [patch] O_SYNC patch 3/3, add inode dirty buffer list support to ext2

[Jeff V. Merkey]

On Thu, Nov 23, 2000 at 12:01:35PM +, Stephen C. Tweedie wrote:
> Hi,
> 
> On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote:
> > 
> > I have not implemented O_SYNC in NWFS, but it looks like I need to add it 
> > before posting the final patches.  This patch appears to force write-through 
> > of only dirty inodes, and allow reads to continue from cache.  Is this
> > assumption correct
> 
> Yes: O_SYNC is not required to force reads to be made from disk.
> SingleUnix has an "O_RSYNC" option which does that, but O_SYNC and
> O_DSYNC don't imply that.

Cool.  ORACLE is going to **SMOKE** on EXT2 with this change.

Jeff

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

Re: alloc_tty_struct() question.

[Matti Aarnio]

On Thu, Nov 23, 2000 at 06:54:48PM +, Tigran Aivazian wrote:
> Hi,
> 
> The sizeof(struct tty_struct) = 3084. Why don't we have a private slab
> cache for it instead of getting a page and wasting some precious bytes at
> the end? Potentially, we can have thousands of tty_struct allocated
> (assuming we have thousands of concurrent users)...

Potentially thousands, in practice some 10-30.
Wastage will be worse with 8k pages, of course.

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

alloc_tty_struct() question.

[Tigran Aivazian]

Hi,

The sizeof(struct tty_struct) = 3084. Why don't we have a private slab
cache for it instead of getting a page and wasting some precious bytes at
the end? Potentially, we can have thousands of tty_struct allocated
(assuming we have thousands of concurrent users)...

regards,
Tigran

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

oddity introduced between 2.4.0-test10 & -test11

[Steven Lembark]

hot-pluggable devices are turned off in the config (see below).
-test9 had some problems with depmod arguments, make completed
if i used '-' in the Makefile to ignore the status and went back
to run depmod by hand.

make[1]: Leaving directory `/usr/src/linux-2.4.0-test11/arch/i386/lib'
cd /lib/modules/2.4.0-test11; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.4.0-test11; fi
depmod: depmod.c:482: addksyms: Assertion `n_syms < 1' failed.
make: *** [_modinst_post] Error 134


enjoi,
sl


#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_M686FXSR=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_FXSR=y
CONFIG_X86_XMM=y
# CONFIG_TOSHIBA is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
# CONFIG_PM is not set
# CONFIG_ACPI_INTERPRETER is not set
# CONFIG_ACPI_S1_SLEEP is not set
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play configuration
#
CONFIG_PNP=y
# CONFIG_ISAPNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=16386

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_LVM=m
CONFIG_LVM_PROC_FS=y

#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
# CONFIG_NETLINK_DEV is not set
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set

#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
# CONFIG_IP_NF_MATCH_LIMIT is not set
# CONFIG_IP_NF_MATCH_MAC is not set
# CONFIG_IP_NF_MATCH_MARK is not set
# CONFIG_IP_NF_MATCH_MULTIPORT is not set
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_STATE=y
# CONFIG_IP_NF_MATCH_UNCLEAN is not set
# CONFIG_IP_NF_MATCH_OWNER is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
# CONFIG_IP_NF_TARGET_MIRROR is not set
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
# CONFIG_IP_NF_TARGET_REDIRECT is not set
CONFIG_IP_NF_MANGLE=y
# CONFIG_IP_NF_TARGET_TOS is not set
# CONFIG_IP_NF_TARGET_MARK is not set
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set

#
#  
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set

Re: 3c59x: Using bad IRQ 0

[Linus Torvalds]

On Thu, 23 Nov 2000, Tobias Ringstrom wrote:
> > 
> >  - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code
> >print out what the pirq table entries are etc.
> 
> Done. When adding the call to eisa_set_level_irq, the line
> 
> IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl  -> newirq=9 -> 
>assigning IRQ 9 ... OK
> 
> was changed into
> 
> IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl  -> newirq=9 -> 
>assigning IRQ 9 -> edge ... OK

Ok.

The thing was marked as edge-triggered, which is basically always wrong
for a PCI interrupt. The above printout just means that it now noticed
that it was edge, and fixed it up in the ELCR.

> >  - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before
> >the "return 1;"
> 
> You certainly know your kernel very well... :-)

That's why they pay me the big bucks. Good.

I'll make it do the eisa_set_level_irq() in the generic code: it should
always be right (we don't do it now in the PIIX4 case, for example, but
the PIIX documentation actually says that we _should_), and there is no
need to do it separately for each interrupt router.

One down.

Now just tell me if the problem with the machine that needs warm-booting
from Windows is fixed by the other PCI change, and I'll be a happy camper.

(Or rather, I'd be a happy camper if I knew what the cause of the disk
corruption reports is. That one bugs me).

Linus

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

Re: Cardbus bridge problems

[Tobias Ringstrom]

On Thu, 23 Nov 2000, Linus Torvalds wrote:
> Tobias? Does changing that if-statement that make your bus happier?

I'll try this tomorrow. The sick laptop is at work, and I'm home. The time
difference really slows things down. :-(

/Tobias


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

[PATCH] PCI id list update

[Peter Samuelson]

[Martin Dalecki]
> Just a small trivial obviously correct update...

OK, merged into my pending pci_ids.h patch.  (This is bigger than
necessary because I converted almost all spaces to tabs.)

Peter

--- 2.4.0test11/include/linux/pci_ids.h.bak Mon Nov 13 01:43:49 2000
+++ 2.4.0test11/include/linux/pci_ids.h Thu Nov 23 12:17:07 2000
@@ -191,8 +191,8 @@
 
 #define PCI_VENDOR_ID_NS   0x100b
 #define PCI_DEVICE_ID_NS_87415 0x0002
-#define PCI_DEVICE_ID_NS_87560_LIO  0x000e
-#define PCI_DEVICE_ID_NS_87560_USB  0x0012
+#define PCI_DEVICE_ID_NS_87560_LIO 0x000e
+#define PCI_DEVICE_ID_NS_87560_USB 0x0012
 #define PCI_DEVICE_ID_NS_87410 0xd001
 
 #define PCI_VENDOR_ID_TSENG0x100c
@@ -254,9 +254,17 @@
 #definePCI_DEVICE_ID_IBM_405GP 0x0156
 #define PCI_DEVICE_ID_IBM_MPIC_2   0x
 
+#define PCI_VENDOR_ID_COMPEX2  0x101a // pci.ids says "AT GIS (NCR)"
+#define PCI_DEVICE_ID_COMPEX2_100VG0x0005
+
 #define PCI_VENDOR_ID_WD   0x101c
 #define PCI_DEVICE_ID_WD_7197  0x3296
 
+#define PCI_VENDOR_ID_AMI  0x101e
+#define PCI_DEVICE_ID_AMI_MEGARAID30x1960
+#define PCI_DEVICE_ID_AMI_MEGARAID 0x9010
+#define PCI_DEVICE_ID_AMI_MEGARAID20x9060
+
 #define PCI_VENDOR_ID_AMD  0x1022
 #define PCI_DEVICE_ID_AMD_LANCE0x2000
 #define PCI_DEVICE_ID_AMD_LANCE_HOME   0x2001
@@ -272,6 +280,8 @@
 #define PCI_DEVICE_ID_AMD_VIPER_740C   0x740C
 
 #define PCI_VENDOR_ID_TRIDENT  0x1023
+#define PCI_DEVICE_ID_TRIDENT_4DWAVE_DX0x2000
+#define PCI_DEVICE_ID_TRIDENT_4DWAVE_NX0x2001
 #define PCI_DEVICE_ID_TRIDENT_9320 0x9320
 #define PCI_DEVICE_ID_TRIDENT_9388 0x9388
 #define PCI_DEVICE_ID_TRIDENT_9397 0x9397
@@ -298,10 +308,10 @@
 #define PCI_DEVICE_ID_MATROX_MIL_2 0x051b
 #define PCI_DEVICE_ID_MATROX_MIL_2_AGP 0x051f
 #define PCI_DEVICE_ID_MATROX_MGA_IMP   0x0d10
-#define PCI_DEVICE_ID_MATROX_G100_MM0x1000
-#define PCI_DEVICE_ID_MATROX_G100_AGP   0x1001
-#define PCI_DEVICE_ID_MATROX_G200_PCI   0x0520
-#define PCI_DEVICE_ID_MATROX_G200_AGP   0x0521
+#define PCI_DEVICE_ID_MATROX_G100_MM   0x1000
+#define PCI_DEVICE_ID_MATROX_G100_AGP  0x1001
+#define PCI_DEVICE_ID_MATROX_G200_PCI  0x0520
+#define PCI_DEVICE_ID_MATROX_G200_AGP  0x0521
 #definePCI_DEVICE_ID_MATROX_G400   0x0525
 #define PCI_DEVICE_ID_MATROX_VIA   0x4536
 
@@ -365,8 +375,8 @@
 #define PCI_DEVICE_ID_PCTECH_SAMURAI_1 0x3010
 #define PCI_DEVICE_ID_PCTECH_SAMURAI_IDE 0x3020
 
-#define PCI_VENDOR_ID_DPT   0x1044   
-#define PCI_DEVICE_ID_DPT   0xa400  
+#define PCI_VENDOR_ID_DPT  0x1044
+#define PCI_DEVICE_ID_DPT  0xa400
 
 #define PCI_VENDOR_ID_OPTI 0x1045
 #define PCI_DEVICE_ID_OPTI_92C178  0xc178
@@ -380,6 +390,10 @@
 #define PCI_DEVICE_ID_OPTI_82C861  0xc861
 #define PCI_DEVICE_ID_OPTI_82C825  0xd568
 
+#define PCI_VENDOR_ID_ELSA 0x1048
+#define PCI_DEVICE_ID_ELSA_QS1000  0x1000
+#define PCI_DEVICE_ID_ELSA_QS3000  0x3000
+
 #define PCI_VENDOR_ID_SGS  0x104a
 #define PCI_DEVICE_ID_SGS_2000 0x0008
 #define PCI_DEVICE_ID_SGS_1764 0x0009
@@ -406,6 +420,8 @@
 #define PCI_DEVICE_ID_TI_1251B 0xac1f
 #define PCI_DEVICE_ID_TI_1420  0xac51
 
+#define PCI_VENDOR_ID_SONY 0x104d
+#define PCI_DEVICE_ID_SONY_CXD3222 0x8039
 
 #define PCI_VENDOR_ID_OAK  0x104e
 #define PCI_DEVICE_ID_OAK_OTI107   0x0107
@@ -503,9 +519,10 @@
 #define PCI_VENDOR_ID_LEADTEK  0x107d
 #define PCI_DEVICE_ID_LEADTEK_805  0x
 
-#define PCI_VENDOR_ID_INTERPHASE   0x107e
+#define PCI_VENDOR_ID_INTERPHASE   0x107e
 #define PCI_DEVICE_ID_INTERPHASE_5526  0x0004
 #define PCI_DEVICE_ID_INTERPHASE_55x6  0x0005
+#define PCI_DEVICE_ID_INTERPHASE_5575  0x0008
 
 #define PCI_VENDOR_ID_CONTAQ   0x1080
 #define PCI_DEVICE_ID_CONTAQ_82C5990x0600
@@ -544,8 +561,8 @@
 #define PCI_VENDOR_ID_BROOKTREE0x109e
 #define PCI_DEVICE_ID_BROOKTREE_8480x0350
 #define PCI_DEVICE_ID_BROOKTREE_849A   0x0351
-#define PCI_DEVICE_ID_BROOKTREE_878_1   0x036e
-#define PCI_DEVICE_ID_BROOKTREE_878 0x0878
+#define PCI_DEVICE_ID_BROOKTREE_878_1  0x036e
+#define PCI_DEVICE_ID_BROOKTREE_8780x0878
 #define PCI_DEVICE_ID_BROOKTREE_8474   0x8474
 
 #define PCI_VENDOR_ID_SIERRA   0x10a8
@@ -617,6 +634,7 @@
 #define PCI_DEVICE_ID_AL_M5229 0x5229
 #define PCI_DEVICE_ID_AL_M5237 0x5237
 #define PCI_DEVICE_ID_AL_M5243 0x5243
+#define PCI_DEVICE_ID_AL_M5451 0x5451
 #define PCI_DEVICE_ID_AL_M7101 0x7101
 
 #define PCI_VENDOR_ID_MITSUBISHI   0x10ba
@@ -624,7 +642,7 @@
 #define PCI_VENDOR_ID_SURECOM  0x10bd
 #define PCI_DEVICE_ID_SURECOM_NE34 0x0e34
 
-#define PCI_VENDOR_ID_NEOMAGIC  0x10c8
+#define PCI_VENDOR_ID_NEOMAGIC 0x10c8
 #define 

Re: silly [< >] and other excess

[Russell King]

Albert D. Cahalan writes:
> > they are not only references to
> > kernel functions, but also kernel data and read only data within
> > the kernel text segment.
> 
> 1. this is harmless
> 2. this is useful (you might get a variable's name)

Wrong.  Op-codes on this machine are organised such that bits 31-28
indicate the "condition" that the instruction executes.  All 16
combinations are meaningful.  This means that any 32-bit value can
appear to be an instruction OR data.  It takes human intellect to
decide which it is.  No machine can tell you that.

> Nope. You get the unmolested oops and some symbol data.
> If there isn't any symbol for 0x424a5149, so what? It is
> no big deal to look up a few opcodes in the symbol table
> by accident.

But there could well be a symbol for 0xc0023004, but it also
corresponds to the instruction:

andgt   r3, r2, r4

"Perform a logical AND operation between r2 and r4 and place the result
 in r3 if the condition codes indicate the `Greater Than' condition"

In addition, the kernel may not be compiled to run at address 0xC...
but at address 0x6... or maybe even 0xe...  Guess what 0xE means
in the high nibble of the op-code?  "Always", or "Unconditional".

> That would be trading one design flaw for another.
> 
> The hard part of klogd/ksymoops is decoding the code bytes AFAIK.
> The rest is a just a cross between grep and ps -- you search and
> you do symbol lookups. I could throw it together in a few hours,
> minus the disassembly part.

As far as I am concerned, you are the people who propose to break
something, and therefore you are the people who should provide the
effort to fix what you will be breaking when the brokenness is
highlighted.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: silly [< >] and other excess

[Russell King]

Ragnar Hojland Espinosa writes:
> On Thu, Nov 23, 2000 at 12:26:30AM +, Russell King wrote:
> > Oh, missed this one.  Here you're wrong again.  The numbers in [< >]
> > should be looked up, and no others.  The code can look exactly like
> > a kernel address.  In this case you definitely do NOT want to have
> > them converted.
> 
> Okay.  How about just using some prefix to the hex number, such as '>'?
> It'll still save plenty of space, and would be trivial changes for the
> tools.  

That is more a question for Keith Owens, not me.  Keith is the maintainer
of ksymoops.  He has to be happy with the address highlighting.  I just
have to be happy that we don't loose ksymoops.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 3c59x: Using bad IRQ 0

[Tobias Ringstrom]

On Thu, 23 Nov 2000, Linus Torvalds wrote:
> > > Tobias, can you confirm that calling pci_enable_device before reading
> > > dev->irq fixes the 3c59x.c problem for you?
> > 
> > Nope. The interrupts do not seem to get through. Packets are transmitted,
> > but that's it. I've copied the interesting parts from dmesg:
> > 
> > 3c59x.c:LK1.1.11 13 Nov 2000  Donald Becker and others. 
>http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
> > See Documentation/networking/vortex.txt
> > PCI: Enabling device 00:0a.0 (0014 -> 0017)
> > PCI: Assigned IRQ 9 for device 00:0a.0
> > eth0: 3Com PCI 3c905C Tornado at 0xa400,  00:01:02:b4:18:e4, IRQ 9
> 
> Ok, the VIA stuff is happy, and enables the irq routing. The fact that the
> irq's don't actually seem to ever actually appear means that the enable
> sequence is probably slightly buggy.
> 
> Can you do two things?
> 
>  - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code
>print out what the pirq table entries are etc.

Done. When adding the call to eisa_set_level_irq, the line

IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl  -> newirq=9 -> 
assigning IRQ 9 ... OK

was changed into

IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl  -> newirq=9 -> 
assigning IRQ 9 -> edge ... OK

>  - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before
>the "return 1;"

You certainly know your kernel very well... :-)

That did the trick, and the 3Com card works just fine.  Now the only
question is why this happened, but I leave that in you capable hands.

/Tobias


Linux version 2.4.0-test11 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 
19990314/Linux (egcs-1.1.2 release)) #29 Thu Nov 23 18:58:29 CET 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009e800 @  (usable)
 BIOS-e820: 1800 @ 0009e800 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 0feec000 @ 0010 (usable)
 BIOS-e820: 3000 @ 0ffec000 (ACPI data)
 BIOS-e820: 0001 @ 0ffef000 (reserved)
 BIOS-e820: 1000 @ 0000 (ACPI NVS)
 BIOS-e820: 0001 @  (reserved)
On node 0 totalpages: 65516
zone(0): 4096 pages.
zone(1): 61420 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz ide=reverse 1
ide_setup: ide=reverse : Enabled support for IDE inverse scan order.
Initializing CPU#0
Detected 1009.006 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 2011.96 BogoMIPS
Memory: 255116k/262064k available (1624k kernel code, 6556k reserved, 101k data, 220k 
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , 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: 0183f9ff c1c7f9ff  
CPU: After generic, caps: 0183f9ff c1c7f9ff  
CPU: Common caps: 0183f9ff c1c7f9ff  
CPU: AMD Athlon(tm) Processor stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: BIOS32 Service Directory structure at 0xc00f92a0
PCI: BIOS32 Service Directory entry at 0xf0ef0
PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=01
PCI: PCI BIOS revision 2.10 entry at 0xf10f0, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: IDE base address fixup for 00:04.1
PCI: Scanning for ghost devices on bus 0
PCI: Scanning for ghost devices on bus 1
Unknown bridge resource 0: assuming transparent
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00f16c0
00:0c slot=01 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8
00:0b slot=02 0:02/1eb8 1:03/1eb8 2:05/1eb8 3:01/1eb8
00:0a slot=03 0:03/1eb8 1:05/1eb8 2:01/1eb8 3:02/1eb8
00:09 slot=04 0:05/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8
00:0d slot=05 0:05/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8
00:04 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8
00:01 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8
00:11 slot=00 0:02/1eb8 1:03/1eb8 2:05/1eb8 3:01/1eb8
00:12 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8
PCI: Using IRQ router VIA [1106/0686] at 00:04.0
PCI: IRQ fixup
00:0a.0: ignoring bogus IRQ 255
00:0b.0: ignoring bogus IRQ 255
IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl  ... failed
IRQ for 00:0b.0(0) via 00:0b.0 -> PIRQ 02, mask 1eb8, excl  -> got IRQ 10
PCI: Found IRQ 10 for device 00:0b.0
PCI: The same IRQ used for device 00:11.0
PCI: Allocating resources
PCI: Resource e000-e7ff (f=1208, d=0, p=0)
PCI: Resource d800-d80f (f=101, d=0, p=0)

Re: PROBLEM: Cruft mounting option incorrect in ISOFS code

[Ben Fennema]

Rogier Wolff wrote:
> 
> Alan Cox wrote:
> > > under 1 gig in size.  You can exhibit the problem by mounting the dvd movie
> > > "The World is Not Enough" as it contains a video_ts.vob which is larger than
> > > 1 gigabyte.  You will see that most of the file lengths are incorrect due to
> > > the "cruft mounting option" hacking off the high order byte.  There are
> > > certainly many more movies out there that exhibit this problem so it would
> > > be a good thing for someone to fix.
>  
> > The cruft thing is correct in itself. The size being 4Gb is trivial
> > to change providing someone can provide a reference to the standards
> > that say its ok.  So is the limit 4Gig, who documents it ?
> 
> Page 137 of DVD Demystified by Jim Taylor says:
> 
>   - Individual files must be less than or equal to 1 gigabyte in length.

The maximum size of a single UDF extent is 2^30-1
For DVD Video, the data of each file shall be recorded in a single extent.

So thats where the limit comes from :)

Ben

-- 
Linux UDF - http://linux-udf.sourceforge.net
Latest Is - udf-0.9.2.1 (http://www.csc.calpoly.edu/~bfennema/udf.html)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: {PATCH} isofs stuff

[Ragnar Hojland Espinosa]

On Thu, Nov 23, 2000 at 09:20:15AM -0800, Linus Torvalds wrote:
> Can you check whether the single patch of _just_ removing the extra "f_pos
> >= i_size" test in do_isofs_readdir() fixes it? The other changes of
> Andries patch look like they should not affect code generation at all, but
> I'd still like to verify that it's only that part. If so, it definitely

Verified, it does.

-- 
/|  Ragnar Højland Freedom - Linux - OpenGL  Fingerprint  94C4B
\ o.O|   2F0D27DE025BE2302C
 =(_)=  "Thou shalt not follow the NULL pointer for  104B78C56 B72F0822
   U chaos and madness await thee at its end."   hkp://keys.pgp.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Cardbus bridge problems

[Linus Torvalds]

[ Tobias: thanks for an excellent report, btw ]

On Wed, 22 Nov 2000, Tobias Ringstrom wrote:
> On Wed, 22 Nov 2000, Tobias Ringstrom wrote:
> 
> > Not that I like it, but I need to boot Win98, and then warm boot into
> > Linux, or the Cardbus is not working.  This is using Linux-2.4.0-test11 on
> > a Mitac 7233 laptop.
> > 
> > Using lspci, I can see that the secondary and subordinate busses of the
> > Cardbus bridges are unconfigured/incorrect. I have attached dmesg and
> > lspci -vvvxxx output from the two cases (ok=Win98+warm-boot and
> > fail=cold-boot). I have enabled all PCI debug things I could find. Bw, it
> > would be really nice to have ONE place to enable the PCI debug info.

You have a really sick system, the following is absolute garbage:

00:08.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
Subsystem: Mitac: Unknown device 7233
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001

That bus setup is horribly wrong, and says that the CardBus bridge no bus
numbers, which is obviously not correct. It somehow got through the bridge
scanning without being fixed up..

Now, the reason for why it seems to be so unhappy is apparently

Scanning behind PCI bridge 00:08.0, config 40, pass 1
Scanning behind PCI bridge 00:08.1, config 40, pass 1

Note the "config 40". It basically seems to imply that the cardbus
bridge has been set up as bus 0x40, ie 64. With no secondary bus behind
it. Which looks completely and utterly bogus.

I bet the thing works for you if you change the magic constant 0xff in
pci_scan_bridge() to the new magic constant 0x00. Basically, we don't
much care what it reports for the primary bus number: but we _do_ care
that a PCI bridge should have a secondary bus number.

Martin, What say you? I think 0x00 makes more sense here anyway. And I
bet(*) it will also fix the problem Tobias is seeing.

Tobias? Does changing that if-statement that make your bus happier?

Oh, btw, Martin: I suspect the "cardbus bridge already set up" case in
pci_scan_bridge() should also have the logic

unsigned int cmax = child->subordinate;
if (cmax > max) max = cmax;

in addition to setting up the resources. Comments? As it stands now, it
looks like a pre-configured cardbus bridge doesn't count towards "max" at
all..

Linus

(*) But I won't be betting huge amounts of money on it. There may be other
things that aren't initialized correctly.

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

Re: {PATCH} isofs stuff

[Tigran Aivazian]

On Thu, 23 Nov 2000, Linus Torvalds wrote:
> To tie two threads together again: the thread about FS corruption is one
> of my main worries right now. Do people who see this happen to use a gcc
> other than egcs-2.91.66? I know Andries apparently has 2.95.2, and he's
> one of the people who have reported corruption problems...

I am using 2.91.66. Ok, I'll get on with testing Al Viro's latest patch
now.

Regards,
Tigran

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

Re: {PATCH} isofs stuff

[Linus Torvalds]

On Thu, 23 Nov 2000, Ragnar Hojland Espinosa wrote:
> 
> Yup, indeed it solves the dir/namei problem.  

Can you check whether the single patch of _just_ removing the extra "f_pos
>= i_size" test in do_isofs_readdir() fixes it? The other changes of
Andries patch look like they should not affect code generation at all, but
I'd still like to verify that it's only that part. If so, it definitely
looks like a gcc-2.95.2 code generation bug - that single if() statement
does not actually matter for the end result, it's just a (misguided)
early-out optimization.

[ Btw, looking at the generated assembly is quite painful. Ugh. It reminds
  me again why "long long" is to be avoided with gcc. Getting rid of the
  extra test actually improves and speeds up that function probably
  simply because the 64-bit arithmetic just cofuses gcc so badly. ]

Linus

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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Alexander Viro]

On Thu, 23 Nov 2000, Alexander Viro wrote:

> On Thu, 23 Nov 2000, Neil Brown wrote:
> 
> > which enabled ext2_notify_change, however ext2_notify_change has a
> > bug.
> > It sets attributes from iattr->ia_attr_flags even
> > if ATTR_ATTR_FLAG is NOT SET in iattr->ia_valid.
> 
> Arrrgh. Could you try that:

OK, I really need more coffee - wrong patch. My apologies. Correct (OK,
intended) one follows:

diff -urN rc11/fs/buffer.c rc11-ext2/fs/buffer.c
--- rc11/fs/buffer.cMon Nov 20 01:18:59 2000
+++ rc11-ext2/fs/buffer.c   Tue Nov 21 01:14:34 2000
@@ -1527,6 +1527,15 @@
}
return 0;
 out:
+   bh = head;
+   do {
+   if (buffer_new(bh) && !buffer_uptodate(bh)) {
+   memset(bh->b_data, 0, bh->b_size);
+   set_bit(BH_Uptodate, >b_state);
+   mark_buffer_dirty(bh);
+   }
+   bh = bh->b_this_page;
+   } while (bh != head);
return err;
 }
 
diff -urN rc11/fs/ext2/file.c rc11-ext2/fs/ext2/file.c
--- rc11/fs/ext2/file.c Wed Oct  4 03:44:54 2000
+++ rc11-ext2/fs/ext2/file.cTue Nov 21 01:14:34 2000
@@ -25,17 +25,6 @@
 static loff_t ext2_file_lseek(struct file *, loff_t, int);
 static int ext2_open_file (struct inode *, struct file *);
 
-#define EXT2_MAX_SIZE(bits)\
-   (((EXT2_NDIR_BLOCKS + (1LL << (bits - 2)) + \
-  (1LL << (bits - 2)) * (1LL << (bits - 2)) +  \
-  (1LL << (bits - 2)) * (1LL << (bits - 2)) * (1LL << (bits - 2))) *   \
- (1LL << bits)) - 1)
-
-static long long ext2_max_sizes[] = {
-0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
-EXT2_MAX_SIZE(10), EXT2_MAX_SIZE(11), EXT2_MAX_SIZE(12), EXT2_MAX_SIZE(13)
-};
-
 /*
  * Make sure the offset never goes beyond the 32-bit mark..
  */
@@ -56,7 +45,7 @@
if (offset<0)
return -EINVAL;
if (((unsigned long long) offset >> 32) != 0) {
-   if (offset > ext2_max_sizes[EXT2_BLOCK_SIZE_BITS(inode->i_sb)])
+   if (offset >= inode->i_sb->u.ext2_sb.s_max_size)
return -EINVAL;
} 
if (offset != file->f_pos) {
@@ -110,4 +99,5 @@
 
 struct inode_operations ext2_file_inode_operations = {
truncate:   ext2_truncate,
+   setattr:ext2_notify_change,
 };
diff -urN rc11/fs/ext2/inode.c rc11-ext2/fs/ext2/inode.c
--- rc11/fs/ext2/inode.cWed Oct  4 03:44:54 2000
+++ rc11-ext2/fs/ext2/inode.c   Thu Nov 23 14:52:17 2000
@@ -153,11 +153,13 @@
  * This function translates the block number into path in that tree -
  * return value is the path length and @offsets[n] is the offset of
  * pointer to (n+1)th node in the nth one. If @block is out of range
- * (negative or too large) warning is printed and zero returned.
+ * (negative or too large) we return zero. Warning is printed if @block
+ * is negative - that should never happen. Too large value is OK, it
+ * just means that ext2_get_block() should return -%EFBIG.
  *
  * Note: function doesn't find node addresses, so no IO is needed. All
  * we need to know is the capacity of indirect blocks (taken from the
- * inode->i_sb).
+ * @inode->i_sb).
  */
 
 /*
@@ -196,7 +198,7 @@
offsets[n++] = (i_block >> ptrs_bits) & (ptrs - 1);
offsets[n++] = i_block & (ptrs - 1);
} else {
-   ext2_warning (inode->i_sb, "ext2_block_to_path", "block > big");
+   /* Too large, nothing to do here */
}
return n;
 }
@@ -216,7 +218,7 @@
  * i.e. little-endian 32-bit), chain[i].p contains the address of that
  * number (it points into struct inode for i==0 and into the bh->b_data
  * for i>0) and chain[i].bh points to the buffer_head of i-th indirect
- * block for i>0 and NULL for i==0. In other words, it holds the block
+ * block for i>0 and %NULL for i==0. In other words, it holds the block
  * numbers of the chain, addresses they were taken from (and where we can
  * verify that chain did not change) and buffer_heads hosting these
  * numbers.
@@ -230,11 +232,11 @@
  * or when it reads all @depth-1 indirect blocks successfully and finds
  * the whole chain, all way to the data (returns %NULL, *err == 0).
  */
-static inline Indirect *ext2_get_branch(struct inode *inode,
-   int depth,
-   int *offsets,
-   Indirect chain[4],
-   int *err)
+static Indirect *ext2_get_branch(struct inode *inode,
+int depth,
+int *offsets,
+Indirect chain[4],
+int *err)
 {
kdev_t dev = inode->i_dev;
int size = inode->i_sb->s_blocksize;
@@ -505,7 +507,7 @@
 

Re: 3c59x: Using bad IRQ 0

[Linus Torvalds]

On Tue, 21 Nov 2000, Tobias Ringstrom wrote:
> > 
> > Tobias, can you confirm that calling pci_enable_device before reading
> > dev->irq fixes the 3c59x.c problem for you?
> 
> Nope. The interrupts do not seem to get through. Packets are transmitted,
> but that's it. I've copied the interesting parts from dmesg:
> 
> 3c59x.c:LK1.1.11 13 Nov 2000  Donald Becker and others. 
>http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
> See Documentation/networking/vortex.txt
> PCI: Enabling device 00:0a.0 (0014 -> 0017)
> PCI: Assigned IRQ 9 for device 00:0a.0
> eth0: 3Com PCI 3c905C Tornado at 0xa400,  00:01:02:b4:18:e4, IRQ 9

Ok, the VIA stuff is happy, and enables the irq routing. The fact that the
irq's don't actually seem to ever actually appear means that the enable
sequence is probably slightly buggy.

Can you do two things?

 - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code
   print out what the pirq table entries are etc.

 - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before
   the "return 1;"

Jeff, you had complete VIA docs, right? Can you check that whatever 
Tobias' ends up having output from the debug stuff looks sane?

Linus

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

Re: "Hyper-Mount" option possible???

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Robert L Martin <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Not on list just throwing an idea out.
> One thing that "bugs" me is if a given drive has more than one partion
> each partion has to be mounted seperatly.
> With CDs this also means you can not mount "split" cds in full if you
> want to. Soo  Given that Super-Mount is already taken, How about (in
> 2.5??)  hashing out a Hypermount option.
> The way it could work is if you mount a full drive say "hdd" and have
> each partion mounted on a tree from the mount point
> of the drive.
> 

This sounds a lot like cdfs.

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

Re: {PATCH} isofs stuff

[Ragnar Hojland Espinosa]

On Thu, Nov 23, 2000 at 04:50:22AM +0100, [EMAIL PROTECTED] wrote:
> Below a working patch for which the isofs images I got
> all are OK. (There is still a lot of silliness here -
> superfluous parentheses, a rename of isofs_cmp to isofs_comp
> in one file to avoid confusion with the isofs_cmp in another file..)

Yup, indeed it solves the dir/namei problem.  

However, while my ide drive is fine, my mistumi (mcdx) still oopses and/or
aaies when doing dd on it.  Here's what I was able to catch from the trace..
doesn't look too relevant, tho.  I tried oopisng it again, but it spew a
list of hex addresses as long as my arm and couldn't catch the first one. 

__wake_up  ce-28
0xe3c9d34d
handle_scancode
del_timer
handle_scancode
do_SAK
vc_resize

Where  __wake_up:

c0113f95:   89 15 4c 01 22 c0   movl   %edx,0xc022014c
c0113f9b:   ff 05 44 c4 25 c0   incl   0xc025c444
c0113fa1:   89 d8   movl   %ebx,%eax
c0113fa3:   e8 10 fa ff ff  call   c01139b8 
c0113fa8:   57  pushl  %edi
c0113fa9:   9d  popf   
c0113faa:   8b 4d f8movl   0xfff8(%ebp),%ecx
c0113fad:   23 4e 00andl   0x0(%esi),%ecx
c0113fb0:   f6 c1 01testb  $0x1,%cl
c0113fb3:   75 43   jnec0113ff8 <__wake_up+0xd0>
c0113fb5:   8b 45 e8movl   0xffe8(%ebp),%eax
c0113fb8:   39 45 e4cmpl   %eax,0xffe4(%ebp)
c0113fbb:   74 3b   je c0113ff8 <__wake_up+0xd0>
c0113fbd:   8b 75 e4movl   0xffe4(%ebp),%esi
c0113fc0:   8b 55 e4movl   0xffe4(%ebp),%edx
c0113fc3:   83 c6 f8addl   $0xfff8,%esi
c0113fc6:   8b 12   movl   (%edx),%edx
c0113fc8:   89 55 e4movl   %edx,0xffe4(%ebp)
c0113fcb:   8b 5e 04movl   0x4(%esi),%ebx

>>> c0113fce:   8b 03   movl   (%ebx),%eax

c0113fd0:   85 45 fctestl  %eax,0xfffc(%ebp)
c0113fd3:   74 e0   je c0113fb5 <__wake_up+0x8d>
c0113fd5:   83 7d f4 00 cmpl   $0x0,0xfff4(%ebp)
c0113fd9:   74 96   je c0113f71 <__wake_up+0x49>
c0113fdb:   8b 4d f8movl   0xfff8(%ebp),%ecx
c0113fde:   23 4e 00andl   0x0(%esi),%ecx

-- 
/|  Ragnar Højland Freedom - Linux - OpenGL  Fingerprint  94C4B
\ o.O|   2F0D27DE025BE2302C
 =(_)=  "Thou shalt not follow the NULL pointer for  104B78C56 B72F0822
   U chaos and madness await thee at its end."   hkp://keys.pgp.com

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

Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1

[Georg Acher]

On Thu, Nov 23, 2000 at 04:35:33PM +, Rui Sousa wrote:
> On Thu, 23 Nov 2000, Michael Elkins wrote:
> 
> Usb controller is sharing a interrupt with the emu10k1.
> For what I know the emu10k1 driver doesn't have any problem
> sharing irq's, so I would blame the usb driver...

usb-uhci doesn't also have any problem with sharing irqs:

> cat /proc/interrupts
 10:5597981  XT-PIC  aic7xxx, eth0, usb-uhci

Hm, no one left to blame...
I would debug it as follows:
Place various printks in the initialization code (reset_hc(), start_hc() and
alloc_uhci) and find out after which printk it hangs. Then it would be
possible to investigate this further...

-- 
 Georg Acher, [EMAIL PROTECTED] 
 http://www.in.tum.de/~acher/
  "Oh no, not again !" The bowl of petunias  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] silly [< >] and other excess

[Peter Samuelson]

  [Alan Cox]
> > Thats because too many things get put on a line then.
> > And because we do [] []  not   [][] ?

[Andries Brouwer]
> In the good old times we had foo bar for a total of 8*(8+1) = 72
> positions. Now we have [] [] which takes 8*(8+1+4) = 104

I've got it!  Put multiple addresses within one set of [< >].  ksymoops
and klogd will require a small adjustment, of course.

The following show_stack() is 8 addrs per line, 79 columns.  Comments?

Peter

--- arch/i386/kernel/traps.c.orig   Mon Nov 13 01:44:02 2000
+++ arch/i386/kernel/traps.cThu Nov 23 10:10:06 2000
@@ -126,7 +126,6 @@
printk("%08lx ", *stack++);
}
 
-   printk("\nCall Trace: ");
stack = esp;
i = 1;
module_start = VMALLOC_START;
@@ -144,12 +143,17 @@
if (((addr >= (unsigned long) &_stext) &&
 (addr <= (unsigned long) &_etext)) ||
((addr >= module_start) && (addr <= module_end))) {
-   if (i && ((i % 8) == 0))
-   printk("\n   ");
-   printk("[<%08lx>] ", addr);
+   if (i==1)
+   printk("\nCall Trace:  [<");
+   else if ((i % 8)==0)
+   printk(">]\n[<");
+   else
+   printk(" ");
+   printk("%08lx", addr);
i++;
}
}
+   printk(">]\n");
 }
 
 static void show_registers(struct pt_regs *regs)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/