[patch] smbfs cache rewrite for 2.4.1-pre

[patch] smbfs cache rewrite for 2.4.1-pre

[Urban Widmark]

There have been a few reports on oopses in smbfs on 2.4 boxes with highmem
support enabled. This patch tries to fix that.

The patch replaces the smbfs dir cache code with something based on the
ncpfs code. Petr should recognize almost all of it. And the ntfs code has
contributed with new time decoding functions.


It compiles, it mounts and it hasn't crashed yet. No guarantees beyond
that. Tested on 2.4.1-pre3 and pre8, and pre8+HIGHMEM_DEBUG_MERE_MORTALS-1
(allows highmem use on non-highmem box). I have repeated crashes (hangs)
on the old cache code but not the new, so maybe it is better.

The patch is 34k. Those who want to test it or comment on it may download
it from here.
http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.1-pre3-cache.patch

There are a few things that are incomplete. The dates don't consider
timezones (I think), it should only work with win9x/NT/2k servers. And I
suspect the caching part doesn't use any of the things it caches (but I
know that some parts are disabled).

/Urban

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

Is this kernel related (signal 11)?

[Rainer Mager]

Hi all,

	I brought up this issue last month and had some response but as of yet my
particular problem still exists. In brief, X windows dies with signal 11. I
have done quite a bit of testing and this does not seem to be a hardware
issue. Also, I have never managed to get a signal 11 error when not running
X.
	I posted on the X Free86 mailing lists and the consensus there seems to be
that it is likely a hardware or kernel problem. So, my question is, how can
I pin point the problem? Is this likely to be a kernel issue?

	Recently I have been able to reproduce the problem reliably in a few ways.
First, if I use an app that uses ncurses (like 'make menuconfig' on the
Linux kernel) from within Gnome-terminal then X dies instantly. For now I
have gone to using only xterm.
	I can also cause the error from xmms by scrolling the playlist repeatedly.
This will happen within a few seconds but not instantly like above.
	I have also seen the error in other cases but none that I am yet able to
reproduce on demand.


PLEASE, any suggestions?


--Rainer

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

Re: Is this kernel related (signal 11)?

[David Woodhouse]

On Mon, 22 Jan 2001, Rainer Mager wrote:

> 	I brought up this issue last month and had some response but as
> of yet my particular problem still exists. In brief, X windows dies
> with signal 11. I have done quite a bit of testing and this does not
> seem to be a hardware issue. Also, I have never managed to get a
> signal 11 error when not running X.

Would this be an SMP IA32 box with glibc 2.2? I have two such boxen 
showing exactly the same behaviour, although I can't reproduce it at will.

It happens even when I use the same kernel and XFree86 binaries which were
working perfectly before the upgrade. The LDT handling fixes which were
added between 2.4.0-prerelease and the real 2.4.0 appeared to make this
_slightly_ less frequent, but I still rarely have an X server uptime of
more than a few days.

-- 
dwmw2


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

RE: Is this kernel related (signal 11)?

[Rainer Mager]

> Would this be an SMP IA32 box with glibc 2.2? I have two such boxen
> showing exactly the same behaviour, although I can't reproduce it at will.

Close, it is actually an SMP IA32 box with glibc 2.1.3. But you've now
convinced me to not upgrade glibc yet  ;-)

--Rainer

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

Re: Is this kernel related (signal 11)?

[David Ford]

Rainer Mager wrote:

> > Would this be an SMP IA32 box with glibc 2.2? I have two such boxen
> > showing exactly the same behaviour, although I can't reproduce it at will.
>
> Close, it is actually an SMP IA32 box with glibc 2.1.3. But you've now
> convinced me to not upgrade glibc yet  ;-)

Upgrade -past- 2.2, get 2.2.1.  2.2 causes numerous segfaults, notably sendmail
and apache stop working.

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



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

RE: Is this kernel related (signal 11)?

[Rainer Mager]

Thanks for all the info, comments below:

First, I ran X in gdb and got the following via 'bt' after X died. This is
my first experience with gdb so if I should do anything in particular,
please tell me.

#0  0x401addeb in __sigsuspend (set=0xbffff930)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
#1  0x80495a4 in startServer ()
#2  0x804922c in main ()
#3  0x401a79cb in __libc_start_main (main=0x8048ee0 <main>, argc=5,
    argv=0xbffffacc, init=0x8048a64 <_init>, fini=0x8049a44 <_fini>,
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffffac4)
    at ../sysdeps/generic/libc-start.c:92


> David Ford:
>
> Upgrade -past- 2.2, get 2.2.1.  2.2 causes numerous segfaults,
> notably sendmail
> and apache stop working.

I'm willing. Are there any good how-tos on doing this without killing your
system? The last time I manually upgraded libc was about 5 years ago.


> Russell King:
>
>
> In answer to the original posters question, the first step would be
> to grab a copy of memtest86 (iirc its a program that is run from floppy
> disk) and run that on your system.  That /should/ (and I stress should
> there) detect any RAM problems you have.

I'll try this.



> Barry K. Nathan:
>
>
> Does it always happen when you are moving the mouse over a button or
> windowbar or some other on-screen object like that?

Nope. If anything I'd say it happens during blitting (scrolling, screen
refreshing, etc). Also, I'm not overclocking anything.

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

RE: Is this kernel related (signal 11)?

[Rainer Mager]

As per Russell King's suggestion, I ran memtest86 on my system for about 12
hours last night. I found no memory errors. Note that the tests did not
complete because I had to stop them this morning. I'll contiue them tonight.
They got through test 9 of 11.


As per David Ford's suggestion, I am looking into upgrading to glibc 2.2.1.
Can someone please give hints on doing this. I tried to upgrade to 2.2 a few
weeks ago and after the 'make install' and then reboot my system was very
broken and I had to reinstall the RedHat glibc RPM from CD to recover. I
found a howto but it seems pretty old. How do other people do this?


I've also done a strace on X. Now what do I do with this 4 MB log file?


Thanks,

--Rainer

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

RE: Is this kernel related (signal 11)?

[Rainer Mager]

Hi all,

	Well, I upgraded my system to glibc 2.2.1 with few problems. Unfortunately,
there are no improvements in my stability problems. X still dies.


	So, I ask again, how can I debug this? How can I determine if this is a
kernel problem or not?


Thanks,

--Rainer

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

Re: Is this kernel related (signal 11)?

[Rogier Wolff]

Rainer Mager wrote:

> that it is likely a hardware or kernel problem. So, my question is,
> how can I pin point the problem? Is this likely to be a kernel
> issue?

No, not hardware. No not kernel. 

Harware problems are normally not reproducable. Can you attach a
debugger to your X server, and catch it when things go bad? (And
give the Xfree86 people a backtrace)

		Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Is this kernel related (signal 11)?

[Russell King]

Rogier Wolff writes:
> Harware problems are normally not reproducable. Can you attach a
> debugger to your X server, and catch it when things go bad? (And
> give the Xfree86 people a backtrace)

Bad RAM can be extremely reproducable though, and can certainly produce
SEGVs.

Evidence: I recently had a bad 128MB SDRAM which *always* failed at byte
address 0x220068, which was the middle of the mem_map array.  All I
needed to do was 'dd if=/dev/hda of=/dev/null' and the machine would
die within 5 minutes due to an invalid buffer_head pointer.

The SDRAM naturally passed each and every single memory test I could
throw at it.  However, a new SDRAM fixed the problem.

It is quite common for SDRAMs to fail in this way - think about the
failure mode.  Some of the silicon in the SDRAM is damaged.  This isn't
going to move about, so its going to be in a fixed position.  A fixed
position means a specific set of transistors, gate, and therefore
memory location.

In answer to the original posters question, the first step would be
to grab a copy of memtest86 (iirc its a program that is run from floppy
disk) and run that on your system.  That /should/ (and I stress should
there) detect any RAM problems you have.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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

Re: Is this kernel related (signal 11)?

[Paul Jakma]

On Mon, 22 Jan 2001, Russell King wrote:

> Evidence: I recently had a bad 128MB SDRAM which *always* failed at byte
> address 0x220068,

and X is likely to be the biggest process by far on a box, so
statistically will be the process that hits this bad byte the most.
no?

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
The bomb will never go off.  I speak as an expert in explosives.
		-- Admiral William Leahy, U.S. Atomic Bomb Project

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

Re: Is this kernel related (signal 11)?

[Barry K. Nathan]

Rainer Mager wrote:
> particular problem still exists. In brief, X windows dies with signal 11. I
[snip]

Does it always happen when you are moving the mouse over a button or
windowbar or some other on-screen object like that?

Usually, when I have that happen, it's because I'm overclocking the
machine too much... I have no idea if that helps, but I thought I'd go
ahead and throw in my two cents, just in case it does.

-Barry K. Nathan <barryn@pobox.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/