Re: smbfs broken?
On Tue, 22 Oct 2002, Vitaly Markitantov wrote: > When i tries to copy a file from smbfs share mounted by mount_smbfs > i get an error: > cp: ./filename: Bad address > > But when i copy a file to share i get kernel panic like this: > > Fatal trap 12: page fault while in kernel mode Early started set of changes is not finished yeat and that panic might be caused by this. I'm sorry for leaving things broken for such long time, but really can't help right now. BTW, I'm looking for smbfs co-maintainer and if anyone interested in this, please mail me (obviously one are supposed to have knowledge of kernel and smbfs internals). -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On (2002/10/23 11:31), Terry Lambert wrote: > AHA! > > The reason an FFS write resulted in an SMBFS read is that > you had mmap()'ed an SMBFS file, and then wrote a mapped > but-not-in-core page to the target FFS file. Well, a similar problem occurred with cat(1), which doesn't use mmap(). However, I should have included in my message that the following messages are received from the kernel: Oct 23 17:53:02 axl kernel: smbfs_getpages: error 60 Oct 23 17:53:02 axl kernel: vm_fault: pager read error, pid 8022 (cp) Oct 23 17:58:18 axl kernel: smbfs_getpages: error 4 Oct 23 17:58:18 axl kernel: vm_fault: pager read error, pid 8087 (cp) This supports your theory. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Wed, Oct 23, 2002 at 11:31:50AM -0700, Terry Lambert wrote: > AHA! > > The reason an FFS write resulted in an SMBFS read is that > you had mmap()'ed an SMBFS file, and then wrote a mapped > but-not-in-core page to the target FFS file. > > Knowing that the code involved is in the paging path of the > SMBFS code is important. > > What happens if you: > > dd if=/smb/urchin/pub/bytes/8145 of=8145 > > ? I expect that it works, no problem. Yes, it works fine in both direction - copy from and to SMBFS. cp still not works correctly (nor reads nor writes to SMBFS) -- Vitaly Markitantov mailto: [EMAIL PROTECTED] icq: 117438950 phone: (062)332-23-90 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Wed, 23 Oct 2002, John Baldwin wrote:
> On 23-Oct-2002 Terry Lambert wrote:
> > Sheldon Hearn wrote:
> >> [client]
> >> $ for i in `jot 512 7680`; do
> >> cp /smb/urchin/pub/bytes/$i . || break;
> >> done
> >> cp: ./8145: Bad address
> >>
> >> If I truss the cp process, I get this:
> >>
> >> [...]
> >> open("/smb/urchin/pub/bytes/8145",0x0,00) = 3 (0x3)
> >> open("./8145",0x401,00) = 4 (0x4)
> >> mmap(0x0,8145,0x1,0x1,3,0x0) = 671461376 (0x2805b000)
> >>
> >> I don't have my laptop set up as a serial debugging client now, so
> >> that's as far as I can go. :-(
> >
> > AHA!
> >
> > The reason an FFS write resulted in an SMBFS read is that
> > you had mmap()'ed an SMBFS file, and then wrote a mapped
> > but-not-in-core page to the target FFS file.
> >
> > Knowing that the code involved is in the paging path of the
> > SMBFS code is important.
> >
> > What happens if you:
> >
> > dd if=/smb/urchin/pub/bytes/8145 of=8145
> >
> > ? I expect that it works, no problem.
> >
> > This localizes the problem to the VOP_GETPAGES that gets hit
> > in the SMBFS case.
>
> Umm, terry. Did you even read all of this thread? He did a
> simple cat(1) later which used read(2) and it got an actual
> error back from read(2). Also, Sheldon is not the original
> submitter of the problem report.
cp(1) uses mmap, hence the syscall.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
John Baldwin wrote: > > What happens if you: > > > > dd if=/smb/urchin/pub/bytes/8145 of=8145 > > > > ? I expect that it works, no problem. > > > > This localizes the problem to the VOP_GETPAGES that gets hit > > in the SMBFS case. > > Umm, terry. Did you even read all of this thread? He did a > simple cat(1) later which used read(2) and it got an actual > error back from read(2). Also, Sheldon is not the original > submitter of the problem report. I didn't see the read problem until after I had sent this. Just like you didn't see this posting until after you sent yours. 8-). You can't read "all of" a thread that's in progress, unless there is absolutlely zero latency on email delivery, and your opening a response to some email in a thread could lock out the ability of anyone else to do so. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On 23-Oct-2002 Terry Lambert wrote:
> Sheldon Hearn wrote:
>> [client]
>> $ for i in `jot 512 7680`; do
>> cp /smb/urchin/pub/bytes/$i . || break;
>> done
>> cp: ./8145: Bad address
>>
>> If I truss the cp process, I get this:
>>
>> [...]
>> open("/smb/urchin/pub/bytes/8145",0x0,00) = 3 (0x3)
>> open("./8145",0x401,00) = 4 (0x4)
>> mmap(0x0,8145,0x1,0x1,3,0x0) = 671461376 (0x2805b000)
>>
>> I don't have my laptop set up as a serial debugging client now, so
>> that's as far as I can go. :-(
>
> AHA!
>
> The reason an FFS write resulted in an SMBFS read is that
> you had mmap()'ed an SMBFS file, and then wrote a mapped
> but-not-in-core page to the target FFS file.
>
> Knowing that the code involved is in the paging path of the
> SMBFS code is important.
>
> What happens if you:
>
> dd if=/smb/urchin/pub/bytes/8145 of=8145
>
> ? I expect that it works, no problem.
>
> This localizes the problem to the VOP_GETPAGES that gets hit
> in the SMBFS case.
Umm, terry. Did you even read all of this thread? He did a
simple cat(1) later which used read(2) and it got an actual
error back from read(2). Also, Sheldon is not the original
submitter of the problem report.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
Sheldon Hearn wrote:
> [client]
> $ for i in `jot 512 7680`; do
> cp /smb/urchin/pub/bytes/$i . || break;
> done
> cp: ./8145: Bad address
>
> If I truss the cp process, I get this:
>
> [...]
> open("/smb/urchin/pub/bytes/8145",0x0,00) = 3 (0x3)
> open("./8145",0x401,00) = 4 (0x4)
> mmap(0x0,8145,0x1,0x1,3,0x0) = 671461376 (0x2805b000)
>
> I don't have my laptop set up as a serial debugging client now, so
> that's as far as I can go. :-(
AHA!
The reason an FFS write resulted in an SMBFS read is that
you had mmap()'ed an SMBFS file, and then wrote a mapped
but-not-in-core page to the target FFS file.
Knowing that the code involved is in the paging path of the
SMBFS code is important.
What happens if you:
dd if=/smb/urchin/pub/bytes/8145 of=8145
? I expect that it works, no problem.
This localizes the problem to the VOP_GETPAGES that gets hit
in the SMBFS case.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Wed, Oct 23, 2002 at 06:21:44PM +0300, Vitaly Markitantov <[EMAIL PROTECTED]> wrote: > On Wed, Oct 23, 2002 at 10:51:07AM -0400, John Baldwin wrote: > > > > Umm, guys. The code was dereferencing NULL pointers in the mbchain > > code which was fixed yesterday. Please test it out with the fixed > > mbchains code. > > Yes, it not panics now, but again, when i copy to/from > smbfs share i get: > > cp /share/someFile ./ > cp: ./someFile: Bad address Something weird happened also when I tried to copy directory from smb mount using 'pax -rw /share/somedir /tmp'. Pax complained about ~3 files that they changed size during copy operation and the target files got zero size. In reality these are the most static files I know on this NT server :) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On (2002/10/23 18:00), Sheldon Hearn wrote:
> Confirmed with rev 1.9 of subr_mchain.c.
>
> However, I notice that this only happens with files of 8145 bytes size
> or larger.
>
> [server]
> # for i in `jot 512 7680`; do
> dd if=/dev/zero of=$i bs=$i count=1
> done 2>/dev/null
>
> [client]
> $ for i in `jot 512 7680`; do
> cp /smb/urchin/pub/bytes/$i . || break;
> done
> cp: ./8145: Bad address
>
> If I truss the cp process, I get this:
>
> [...]
> open("/smb/urchin/pub/bytes/8145",0x0,00) = 3 (0x3)
> open("./8145",0x401,00) = 4 (0x4)
> mmap(0x0,8145,0x1,0x1,3,0x0) = 671461376 (0x2805b000)
Actually, cat(1) is a simpler test case, and more accurately reflects
the problem:
open("/smb/urchin/pub/bytes/8145",0x0,00) = 3 (0x3)
fstat(1,0xbfbff620) = 0 (0x0)
read(0x3,0x805e000,0x2000) ERR#60 'Operation timed out'
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On (2002/10/23 18:21), Vitaly Markitantov wrote:
> > Umm, guys. The code was dereferencing NULL pointers in the mbchain
> > code which was fixed yesterday. Please test it out with the fixed
> > mbchains code.
>
> Yes, it not panics now, but again, when i copy to/from
> smbfs share i get:
>
> cp /share/someFile ./
> cp: ./someFile: Bad address
Confirmed with rev 1.9 of subr_mchain.c.
However, I notice that this only happens with files of 8145 bytes size
or larger.
[server]
# for i in `jot 512 7680`; do
dd if=/dev/zero of=$i bs=$i count=1
done 2>/dev/null
[client]
$ for i in `jot 512 7680`; do
cp /smb/urchin/pub/bytes/$i . || break;
done
cp: ./8145: Bad address
If I truss the cp process, I get this:
[...]
open("/smb/urchin/pub/bytes/8145",0x0,00) = 3 (0x3)
open("./8145",0x401,00) = 4 (0x4)
mmap(0x0,8145,0x1,0x1,3,0x0) = 671461376 (0x2805b000)
I don't have my laptop set up as a serial debugging client now, so
that's as far as I can go. :-(
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Wed, Oct 23, 2002 at 10:51:07AM -0400, John Baldwin wrote: > > Umm, guys. The code was dereferencing NULL pointers in the mbchain > code which was fixed yesterday. Please test it out with the fixed > mbchains code. Yes, it not panics now, but again, when i copy to/from smbfs share i get: cp /share/someFile ./ cp: ./someFile: Bad address -- Vitaly Markitantov mailto: [EMAIL PROTECTED] icq: 117438950 phone: (062)332-23-90 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On 23-Oct-2002 Terry Lambert wrote:
> Vallo Kallaste wrote:
>> > I don't understand, then. There should be no other way that an ffs_write
>> > call can trap to needing an SMBFS page:
>> >
>> > #22 0xc03902a8 in calltrap () at {standard input}:99
>> > #23 0xc033af01 in ffs_write (ap=0xd66ebbe8) at ../../../ufs/ffs/ffs_vnops.c:810
>> > #24 0xc029b74d in vn_write (fp=0xc40341a4, uio=0xd66ebc68,
>> > active_cred=0xc4251d00, flags=0, td=0xc13534e0) at vnode_if.h:417
>> > #25 0xc0259a75 in dofilewrite (td=0xc13534e0, fp=0xc40341a4, fd=4,
>> > buf=0x2805b000, nbyte=0, offset=0, flags=0) at file.h:215
>> > #26 0xc0259909 in write (td=0xc13534e0, uap=0xd66ebd10)
>> > at ../../../kern/sys_generic.c:329
>> > ---
>> >
>> > You *must* be doing something that causes an SMBFS object to act as
>> > backing store for an FFS.
>>
>> You know better, sure, but nevertheless I'm not doing anything what
>> can cause it. Perhaps a bug somewhere.
>
> My guess is in the "?" routines that you didn't backtrace for us;
> perhaps what happened was that the stack frame screwed up, and
> implicated code that was not a fault.
Umm, guys. The code was dereferencing NULL pointers in the mbchain
code which was fixed yesterday. Please test it out with the fixed
mbchains code.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Tue, Oct 22, 2002 at 02:51:43PM -0400, John Baldwin <[EMAIL PROTECTED]> wrote: [snip] > As someone else has pointed out, it is executing at a garbage > address which is why it panic'd. My guess is that smb_smb_readx() > called some function which had a buffer overflow of a variable on > the stack and trashed the return address. > > Actually, there are some bugs in the mbchains code. I've just > committed a possible fix. Can you cvsup and try out revision > 1.9 of subr_mchain.c and see if it works better? Thanks. The crash is gone, thanks. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
Vallo Kallaste wrote:
> > I don't understand, then. There should be no other way that an ffs_write
> > call can trap to needing an SMBFS page:
> >
> > #22 0xc03902a8 in calltrap () at {standard input}:99
> > #23 0xc033af01 in ffs_write (ap=0xd66ebbe8) at ../../../ufs/ffs/ffs_vnops.c:810
> > #24 0xc029b74d in vn_write (fp=0xc40341a4, uio=0xd66ebc68,
> > active_cred=0xc4251d00, flags=0, td=0xc13534e0) at vnode_if.h:417
> > #25 0xc0259a75 in dofilewrite (td=0xc13534e0, fp=0xc40341a4, fd=4,
> > buf=0x2805b000, nbyte=0, offset=0, flags=0) at file.h:215
> > #26 0xc0259909 in write (td=0xc13534e0, uap=0xd66ebd10)
> > at ../../../kern/sys_generic.c:329
> > ---
> >
> > You *must* be doing something that causes an SMBFS object to act as
> > backing store for an FFS.
>
> You know better, sure, but nevertheless I'm not doing anything what
> can cause it. Perhaps a bug somewhere.
My guess is in the "?" routines that you didn't backtrace for us;
perhaps what happened was that the stack frame screwed up, and
implicated code that was not a fault.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Tue, Oct 22, 2002 at 01:21:09PM -0700, Terry Lambert
<[EMAIL PROTECTED]> wrote:
> > No, I'm doing exactly what I describe. Usual boot to multiuser, then
> > kill all of the processes not strictly necessary (seti, fetchmail,
> > sendmail, you-name-it), mount the smb share -ro from NT4 server, cd
> > /some/mountpoint and cp thisfile.xls /tmp. That's it.
>
> I don't understand, then. There should be no other way that an ffs_write
> call can trap to needing an SMBFS page:
>
> #22 0xc03902a8 in calltrap () at {standard input}:99
> #23 0xc033af01 in ffs_write (ap=0xd66ebbe8) at ../../../ufs/ffs/ffs_vnops.c:810
> #24 0xc029b74d in vn_write (fp=0xc40341a4, uio=0xd66ebc68,
> active_cred=0xc4251d00, flags=0, td=0xc13534e0) at vnode_if.h:417
> #25 0xc0259a75 in dofilewrite (td=0xc13534e0, fp=0xc40341a4, fd=4,
> buf=0x2805b000, nbyte=0, offset=0, flags=0) at file.h:215
> #26 0xc0259909 in write (td=0xc13534e0, uap=0xd66ebd10)
> at ../../../kern/sys_generic.c:329
> ---
>
> You *must* be doing something that causes an SMBFS object to act as
> backing store for an FFS.
You know better, sure, but nevertheless I'm not doing anything what
can cause it. Perhaps a bug somewhere.
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
Vallo Kallaste wrote:
> > It would be nice if you could give us more information as to exactly
> > what it is you are doing, logically, to cause this problem; as things
> > sit, it seems you are doing some evil things.
>
> No, I'm doing exactly what I describe. Usual boot to multiuser, then
> kill all of the processes not strictly necessary (seti, fetchmail,
> sendmail, you-name-it), mount the smb share -ro from NT4 server, cd
> /some/mountpoint and cp thisfile.xls /tmp. That's it.
I don't understand, then. There should be no other way that an ffs_write
call can trap to needing an SMBFS page:
---
#16 0xc03c8307 in smb_read (ssp=0xc424eb00, fid=2048, uio=0xd66eb7fc,
scred=0xd66eb850) at ../../../netsmb/smb_smb.c:795
#17 0xc01f2deb in smbfs_getpages (ap=0x0) at ../../../fs/smbfs/smbfs_io.c:486
#18 0xc0362fad in vnode_pager_getpages (object=0x0, m=0x0, count=0, reqpage=0)
at vnode_if.h:1265
#19 0xc034ca13 in vm_fault (map=0xc4030198, vaddr=671461376,
fault_type=1 '\001', fault_flags=0) at vm_pager.h:124
#20 0xc03a74b5 in trap_pfault (frame=0xd66eba94, usermode=0, eva=671461376)
at ../../../i386/i386/trap.c:736
---Type to continue, or q to quit---
#21 0xc03a7032 in trap (frame=
{tf_fs = -697434088, tf_es = -1070268400, tf_ds = -1006436336, tf_edi =
-823279616,
tf_esi = 671461376, tf_ebp = -697386216, tf_isp = -697386304, tf_ebx = 16384,
tf_edx =
671477760, tf_ecx = 4096, tf_eax = -697385728, tf_trapno = 12, tf_err = 0,
tf_eip =
-1069917698, tf_cs = 8, tf_eflags = 66054, tf_esp = -697385880, tf_ss =
-697385892}) at
../../../i386/i386/trap.c:446
#22 0xc03902a8 in calltrap () at {standard input}:99
#23 0xc033af01 in ffs_write (ap=0xd66ebbe8) at ../../../ufs/ffs/ffs_vnops.c:810
#24 0xc029b74d in vn_write (fp=0xc40341a4, uio=0xd66ebc68,
active_cred=0xc4251d00, flags=0, td=0xc13534e0) at vnode_if.h:417
#25 0xc0259a75 in dofilewrite (td=0xc13534e0, fp=0xc40341a4, fd=4,
buf=0x2805b000, nbyte=0, offset=0, flags=0) at file.h:215
#26 0xc0259909 in write (td=0xc13534e0, uap=0xd66ebd10)
at ../../../kern/sys_generic.c:329
---
You *must* be doing something that causes an SMBFS object to act as
backing store for an FFS.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Tue, Oct 22, 2002 at 12:15:09PM -0700, Terry Lambert <[EMAIL PROTECTED]> wrote: > > #14 0xc455a66e in ?? () > > #15 0xc455a072 in ?? () > > #16 0xc4559e87 in ?? () > > #17 0xc45609f8 in ?? () > > If you are running the smbfs.ko, either load the module symbols into > gdb before asking for the traceback, or statically compile SMBFS into > the kernel. We need the intermediate code. Yes, sorry about that. I seem to remember similar procedures needed for debugging the vinum kld. > > #18 0xc035947d in vnode_pager_getpages (object=0x0, m=0x0, count=0, reqpage=0) > > ...though the fact that this happened agains the vn device on > an SMBFS from a file write is pretty indicative that you are running > a vnconfig'ed device on top of an SMBFS file. This is probably not a > good thing to do. No, I'm not doing such thing, never even tried it. > It would be nice if you could give us more information as to exactly > what it is you are doing, logically, to cause this problem; as things > sit, it seems you are doing some evil things. No, I'm doing exactly what I describe. Usual boot to multiuser, then kill all of the processes not strictly necessary (seti, fetchmail, sendmail, you-name-it), mount the smb share -ro from NT4 server, cd /some/mountpoint and cp thisfile.xls /tmp. That's it. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
Vallo Kallaste wrote:
> On Tue, Oct 22, 2002 at 04:23:20AM -0700, Maxime Henrion
> <[EMAIL PROTECTED]> wrote:
>
> [snip]
> > It would help a lot if you could provide a traceback.
>
> This is the one I'm seeing everytime while trying to copy file from
> ro smbfs mount. -current is about four days old, smbfs.ko _is_
> compiled with -DSMP and in sync with kernel.
[ ... ]
Everyone is reporting a bug similar to this; it is probably a problem
in the memory allocator.
> #11 0xc039b272 in trap_pfault (frame=0xdf9b6724, usermode=0, eva=2)
> at ../../../i386/i386/trap.c:760
> #12 0xc039ace2 in trap (frame=
> {tf_fs = -1053753320, tf_es = 16, tf_ds = -543490032, tf_edi = -1001077964,
>tf_esi = -543463582, tf_ebp = -543463580, tf_isp = -543463600, tf_ebx = 0, tf_edx =
>-543461984, tf_ecx = 0, tf_eax = 14, tf_trapno = 12, tf_err = 0, tf_eip = 2, tf_cs =
>8, tf_eflags = 66178, tf_esp = -543463520, tf_ss = -1001019794})
> at ../../../i386/i386/trap.c:446
> #13 0xc0383f58 in calltrap () at {standard input}:99
> #14 0xc455a66e in ?? ()
> #15 0xc455a072 in ?? ()
> #16 0xc4559e87 in ?? ()
> #17 0xc45609f8 in ?? ()
If you are running the smbfs.ko, either load the module symbols into
gdb before asking for the traceback, or statically compile SMBFS into
the kernel. We need the intermediate code.
> #18 0xc035947d in vnode_pager_getpages (object=0x0, m=0x0, count=0, reqpage=0)
...though the fact that this happened agains the vn device on
an SMBFS from a file write is pretty indicative that you are running
a vnconfig'ed device on top of an SMBFS file. This is probably not a
good thing to do.
It would be nice if you could give us more information as to exactly
what it is you are doing, logically, to cause this problem; as things
sit, it seems you are doing some evil things.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On 22-Oct-2002 Vallo Kallaste wrote:
> On Tue, Oct 22, 2002 at 10:48:58AM -0400, John Baldwin <[EMAIL PROTECTED]> wrote:
>
>> Can you compile smbfs into your kernel 'options SMBFS' instead of as a
>> module and then get a dump and provide a trace?
>
>> >#13 0xc0383f58 in calltrap () at {standard input}:99
>> >#14 0xc455a66e in ?? ()
>> >#15 0xc455a072 in ?? ()
>> >#16 0xc4559e87 in ?? ()
>> >#17 0xc45609f8 in ?? ()
>>
>> These frames are in smbfs and are where the bug is, but we obviously
>> can't figure out much with just ??'s.
>
> I had all but SMBFS in kernel, mostly because it has been working
> only occasionally in the near past. Here's the improved backtrace,
> for more information you'll need to step me down your own path, I
> have no debugging skills.
>
>
> Script started on Tue Oct 22 20:57:11 2002
> bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/crash/vmc
>ore.0
> GNU gdb 5.2.1 (FreeBSD)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-undermydesk-freebsd"...
> panic: bdwrite: buffer is not busy
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; lapic.id =
> fault virtual address = 0x2
> fault code= supervisor read, page not present
> instruction pointer = 0x8:0x2
As someone else has pointed out, it is executing at a garbage
address which is why it panic'd. My guess is that smb_smb_readx()
called some function which had a buffer overflow of a variable on
the stack and trashed the return address.
Actually, there are some bugs in the mbchains code. I've just
committed a possible fix. Can you cvsup and try out revision
1.9 of subr_mchain.c and see if it works better? Thanks.
>#14 0xc03c8aee in smb_smb_readx (ssp=0xc424d034, fid=2048, len=0xd66eb756,
> rresid=0xd66eb7f8, uio=0xd66eb868, scred=0x0)
> at ../../../netsmb/smb_smb.c:636
md_get_uint16le(mdp, NULL);
The md_get_* functions didn't all handle the case of the second
argument being NULL properly.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Tue, Oct 22, 2002 at 10:48:58AM -0400, John Baldwin <[EMAIL PROTECTED]> wrote:
> Can you compile smbfs into your kernel 'options SMBFS' instead of as a
> module and then get a dump and provide a trace?
> >#13 0xc0383f58 in calltrap () at {standard input}:99
> >#14 0xc455a66e in ?? ()
> >#15 0xc455a072 in ?? ()
> >#16 0xc4559e87 in ?? ()
> >#17 0xc45609f8 in ?? ()
>
> These frames are in smbfs and are where the bug is, but we obviously
> can't figure out much with just ??'s.
I had all but SMBFS in kernel, mostly because it has been working
only occasionally in the near past. Here's the improved backtrace,
for more information you'll need to step me down your own path, I
have no debugging skills.
Script started on Tue Oct 22 20:57:11 2002
bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/crash/vmc ore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x2
fault code = supervisor read, page not present
instruction pointer = 0x8:0x2
stack pointer = 0x10:0xd66eb758
frame pointer = 0x10:0xd66eb758
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 700 (cp)
trap number = 12
panic: page fault
cpuid = 0; lapic.id =
boot() called on cpu#0
syncing disks... panic: bdwrite: buffer is not busy
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 18m27s
pfs_vncache_unload(): 2 entries remaining
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:223
223 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:223
#1 0xc02367ea in boot (howto=260) at ../../../kern/kern_shutdown.c:355
#2 0xc0236aa7 in panic () at ../../../kern/kern_shutdown.c:508
#3 0xc027e76d in bdwrite (bp=0xce36b3b8) at ../../../kern/vfs_bio.c:950
#4 0xc032663b in ffs_update (vp=0xc42665c8, waitfor=0)
at ../../../ufs/ffs/ffs_inode.c:125
#5 0xc033a4e2 in ffs_fsync (ap=0xd66eb558) at ../../../ufs/ffs/ffs_vnops.c:315
#6 0xc0339609 in ffs_sync (mp=0xc3fac600, waitfor=2, cred=0xc1341e80,
td=0xc0435c00) at vnode_if.h:612
#7 0xc0293328 in sync (td=0xc0435c00, uap=0x0)
at ../../../kern/vfs_syscalls.c:130
#8 0xc02363cb in boot (howto=256) at ../../../kern/kern_shutdown.c:264
#9 0xc0236aa7 in panic () at ../../../kern/kern_shutdown.c:508
#10 0xc03a7912 in trap_fatal (frame=0xd66eb718, eva=0)
at ../../../i386/i386/trap.c:846
#11 0xc03a75c2 in trap_pfault (frame=0xd66eb718, usermode=0, eva=2)
at ../../../i386/i386/trap.c:760
#12 0xc03a7032 in trap (frame=
{tf_fs = -1004273640, tf_es = 16, tf_ds = -697434096, tf_edi = -1004220364,
tf_esi = -697387178, tf_ebp = -697387176, tf_isp = -697387196, tf_ebx = 0, tf_edx =
-697385568, tf_ecx = 0, tf_eax = 14, tf_trapno = 12, tf_err = 0, tf_eip = 2, tf_cs =
8, tf_eflags = 66194, tf_esp = -697387116, tf_ss = -1069774098})
at ../../../i386/i386/trap.c:446
#13 0xc03902a8 in calltrap () at {standard input}:99
#14 0xc03c8aee in smb_smb_readx (ssp=0xc424d034, fid=2048, len=0xd66eb756,
rresid=0xd66eb7f8, uio=0xd66eb868, scred=0x0)
at ../../../netsmb/smb_smb.c:636
#15 0xc03c84f2 in smb_smb_read (ssp=0xc424eb00, fid=2048, len=0xd66eb7fc,
rresid=0xd66eb7f8, uio=0xd66eb868, scred=0x0)
at ../../../netsmb/smb_smb.c:739
#16 0xc03c8307 in smb_read (ssp=0xc424eb00, fid=2048, uio=0xd66eb7fc,
scred=0xd66eb850) at ../../../netsmb/smb_smb.c:795
#17 0xc01f2deb in smbfs_getpages (ap=0x0) at ../../../fs/smbfs/smbfs_io.c:486
#18 0xc0362fad in vnode_pager_getpages (object=0x0, m=0x0, count=0, reqpage=0)
at vnode_if.h:1265
#19 0xc034ca13 in vm_fault (map=0xc4030198, vaddr=671461376,
fault_type=1 '\001', fault_flags=0) at vm_pager.h:124
#20 0xc03a74b5 in trap_pfault (frame=0xd66eba94, usermode=0, eva=671461376)
at ../../../i386/i386/trap.c:736
---Type to continue, or q to quit---
#21 0xc03a7032 in trap (frame=
{tf_fs = -697434088, tf_es = -1070268400, tf_ds = -1006436336, tf_edi =
-823279616, tf_esi = 671461376, tf_ebp = -697386216, tf_isp = -697386304, tf_ebx =
16384, tf_edx = 671477760, tf_ecx = 4096, tf_eax = -697385728, tf_trapno = 12, tf_err
= 0, tf_eip = -1069917698, tf_cs = 8, tf_eflags = 66054, tf_esp = -697385880, tf_ss =
-697385892}) at ../../../
Re: smbfs broken?
On (2002/10/22 10:48), John Baldwin wrote: > > This is the one I'm seeing everytime while trying to copy file from > > ro smbfs mount. -current is about four days old, smbfs.ko _is_ > > compiled with -DSMP and in sync with kernel. > > Can you compile smbfs into your kernel 'options SMBFS' instead of as a > module and then get a dump and provide a trace? Just to save some time in the feedback round-trip, I'd recommend adding all of these options, in case the bug is in an smbfs dependency: options SMBFS #SMB/CIFS filesystem options NETSMB #SMB/CIFS requester options NETSMBCRYPTO#encrypted password support for SMB options LIBICONV#optional internationalization options LIBMCHAIN #mbuf management library Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On 22-Oct-2002 Vallo Kallaste wrote:
> On Tue, Oct 22, 2002 at 04:23:20AM -0700, Maxime Henrion
> <[EMAIL PROTECTED]> wrote:
>
> [snip]
>> It would help a lot if you could provide a traceback.
>
> This is the one I'm seeing everytime while trying to copy file from
> ro smbfs mount. -current is about four days old, smbfs.ko _is_
> compiled with -DSMP and in sync with kernel.
Can you compile smbfs into your kernel 'options SMBFS' instead of as a
module and then get a dump and provide a trace?
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; lapic.id = 0100
> fault virtual address = 0x2
> fault code= supervisor read, page not present
> instruction pointer = 0x8:0x2
>#11 0xc039b272 in trap_pfault (frame=0xdf9b6724, usermode=0, eva=2)
> at ../../../i386/i386/trap.c:760
>#12 0xc039ace2 in trap (frame=
> {tf_fs = -1053753320, tf_es = 16, tf_ds = -543490032, tf_edi = -1001077964,
>tf_esi =
> -543463582, tf_ebp = -543463580, tf_isp = -543463600, tf_ebx = 0, tf_edx =
>-543461984, tf_ecx =
> 0, tf_eax = 14, tf_trapno = 12, tf_err = 0, tf_eip = 2, tf_cs = 8, tf_eflags =
>66178, tf_esp =
> -543463520, tf_ss = -1001019794})
> at ../../../i386/i386/trap.c:446
>#13 0xc0383f58 in calltrap () at {standard input}:99
>#14 0xc455a66e in ?? ()
>#15 0xc455a072 in ?? ()
>#16 0xc4559e87 in ?? ()
>#17 0xc45609f8 in ?? ()
These frames are in smbfs and are where the bug is, but we obviously
can't figure out much with just ??'s.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Tue, Oct 22, 2002 at 04:23:20AM -0700, Maxime Henrion
<[EMAIL PROTECTED]> wrote:
[snip]
> It would help a lot if you could provide a traceback.
This is the one I'm seeing everytime while trying to copy file from
ro smbfs mount. -current is about four days old, smbfs.ko _is_
compiled with -DSMP and in sync with kernel.
Script started on Tue Oct 22 17:21:53 2002
bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/crash/vm
core.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x2
fault code = supervisor read, page not present
instruction pointer = 0x8:0x2
stack pointer = 0x10:0xdf9b6764
frame pointer = 0x10:0xdf9b6764
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 641 (cp)
trap number = 12
panic: page fault
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks... panic: bdwrite: buffer is not busy
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 6m44s
pfs_vncache_unload(): 1 entries remaining
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:223
223 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:223
#1 0xc022ccba in boot (howto=260) at ../../../kern/kern_shutdown.c:355
#2 0xc022cf77 in panic () at ../../../kern/kern_shutdown.c:508
#3 0xc0274c3d in bdwrite (bp=0xce3bfaf4) at ../../../kern/vfs_bio.c:950
#4 0xc031cb0b in ffs_update (vp=0xc458e4a0, waitfor=0)
at ../../../ufs/ffs/ffs_inode.c:125
#5 0xc03309b2 in ffs_fsync (ap=0xdf9b6564) at ../../../ufs/ffs/ffs_vnops.c:315
#6 0xc032fad9 in ffs_sync (mp=0xc3fa8a00, waitfor=2, cred=0xc1324e80,
td=0xc041cfc0) at vnode_if.h:612
#7 0xc02897f8 in sync (td=0xc041cfc0, uap=0x0)
at ../../../kern/vfs_syscalls.c:130
#8 0xc022c89b in boot (howto=256) at ../../../kern/kern_shutdown.c:264
#9 0xc022cf77 in panic () at ../../../kern/kern_shutdown.c:508
#10 0xc039b5c2 in trap_fatal (frame=0xdf9b6724, eva=0)
at ../../../i386/i386/trap.c:846
#11 0xc039b272 in trap_pfault (frame=0xdf9b6724, usermode=0, eva=2)
at ../../../i386/i386/trap.c:760
#12 0xc039ace2 in trap (frame=
{tf_fs = -1053753320, tf_es = 16, tf_ds = -543490032, tf_edi = -1001077964,
tf_esi = -543463582, tf_ebp = -543463580, tf_isp = -543463600, tf_ebx = 0, tf_edx =
-543461984, tf_ecx = 0, tf_eax = 14, tf_trapno = 12, tf_err = 0, tf_eip = 2, tf_cs =
8, tf_eflags = 66178, tf_esp = -543463520, tf_ss = -1001019794})
at ../../../i386/i386/trap.c:446
#13 0xc0383f58 in calltrap () at {standard input}:99
#14 0xc455a66e in ?? ()
#15 0xc455a072 in ?? ()
#16 0xc4559e87 in ?? ()
#17 0xc45609f8 in ?? ()
#18 0xc035947d in vnode_pager_getpages (object=0x0, m=0x0, count=0, reqpage=0)
---Type to continue, or q to quit---
at vnode_if.h:1265
#19 0xc0342ee3 in vm_fault (map=0xc3ff70cc, vaddr=671461376,
fault_type=1 '\001', fault_flags=0) at vm_pager.h:124
#20 0xc039b165 in trap_pfault (frame=0xdf9b6a94, usermode=0, eva=671461376)
at ../../../i386/i386/trap.c:736
#21 0xc039ace2 in trap (frame=
{tf_fs = -543490024, tf_es = -1070333936, tf_ds = -1006698480, tf_edi =
-796884992, tf_esi = 671461376, tf_ebp = -543462632, tf_isp = -543462720, tf_ebx =
16384, tf_edx = 671477760, tf_ecx = 4096, tf_eax = -543462144, tf_trapno = 12, tf_err
= 0, tf_eip = -1069967698, tf_cs = 8, tf_eflags = 66054, tf_esp = -543462296, tf_ss =
-543462308}) at ../../../i386/i386/trap.c:446
#22 0xc0383f58 in calltrap () at {standard input}:99
#23 0xc03313d1 in ffs_write (ap=0xdf9b6be8) at ../../../ufs/ffs/ffs_vnops.c:810
#24 0xc0291c1d in vn_write (fp=0xc4b4, uio=0xdf9b6c68,
active_cred=0xc4337d80, flags=0, td=0xc3fbd9c0) at vnode_if.h:417
#25 0xc024ff45 in dofilewrite (td=0xc3fbd9c0, fp=0xc4b4, fd=4,
buf=0x2805b000, nbyte=0, offset=0, flags=0) at file.h:215
#26 0xc024fdd9 in write (td=0xc3fbd9c0, uap=0xdf9b6d10)
at ../../../kern/sys_generic.c:329
#27 0xc039b9ec in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 4, tf_esi = 671461376, tf_ebp =
-1077937512, tf_isp = -543462028, tf_ebx = 84480, tf_edx = 0, tf_ecx = 134672640,
tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 134524975, tf_cs = 31, tf_eflags =
531, tf_esp = -107793758
RE: smbfs broken?
On 22-Oct-2002 Vitaly Markitantov wrote: > When i tries to copy a file from smbfs share mounted by mount_smbfs > i get an error: > cp: ./filename: Bad address > > But when i copy a file to share i get kernel panic like this: > > Fatal trap 12: page fault while in kernel mode > fault virtual address= 0x0 Null pointer dereference. Can you compile DDB into the kernel and get a stack trace? > fault code = supervisor write, page not present > > current process = 531 (cp) > trap number = 12 > panic: page fault > > Share mounted from SAMBA server (FreeBSD 4.7-RELEASE) > > Last cvsup + buildworld was about 16-17 October 2002 > uname -a > FreeBSD neo.del.local 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Oct 17 19:19:49 EEST >2002 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEO i386 > > -- > Vitaly Markitantov mailto: [EMAIL PROTECTED] > icq: 117438950 phone: (062)332-23-90 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
Vitaly Markitantov wrote: > When i tries to copy a file from smbfs share mounted by mount_smbfs > i get an error: > cp: ./filename: Bad address > > But when i copy a file to share i get kernel panic like this: > > Fatal trap 12: page fault while in kernel mode > fault virtual address= 0x0 > fault code = supervisor write, page not present > > current process = 531 (cp) > trap number = 12 > panic: page fault It would help a lot if you could provide a traceback. Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Tue, Oct 22, 2002 at 02:01:35PM +0300, Vitaly Markitantov <[EMAIL PROTECTED]> wrote: > When i tries to copy a file from smbfs share mounted by mount_smbfs > i get an error: > cp: ./filename: Bad address > > But when i copy a file to share i get kernel panic like this: > > Fatal trap 12: page fault while in kernel mode > fault virtual address= 0x0 > fault code = supervisor write, page not present > > current process = 531 (cp) > trap number = 12 > panic: page fault > > Share mounted from SAMBA server (FreeBSD 4.7-RELEASE) > > Last cvsup + buildworld was about 16-17 October 2002 > uname -a > FreeBSD neo.del.local 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Oct 17 19:19:49 EEST >2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEO i386 My observations indicate same, I got instant panic while trying to copy any file from ro mounted smb share (NT4). First suspected Openoffice (xls file), but later found the real. For now sharity-light gives me chanche to get work done. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
smbfs broken?
When i tries to copy a file from smbfs share mounted by mount_smbfs i get an error: cp: ./filename: Bad address But when i copy a file to share i get kernel panic like this: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present current process= 531 (cp) trap number= 12 panic: page fault Share mounted from SAMBA server (FreeBSD 4.7-RELEASE) Last cvsup + buildworld was about 16-17 October 2002 uname -a FreeBSD neo.del.local 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Oct 17 19:19:49 EEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEO i386 -- Vitaly Markitantov mailto: [EMAIL PROTECTED] icq: 117438950 phone: (062)332-23-90 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE settling in (smbfs broken) again
On Fri, 5 Oct 2001, Sheldon Hearn wrote: > > I need to look at it again.. (I figured I just didn't have the time to try > > understand it all AND do the rest of the kernel.) Of course the best woudl > > be if Mr. Popov did the conversion but I believe he's incredibly busy at > > the moment.. Certainly if someone else wants to make an effort at it. > > they are welcome to do it.. otherwise I will eventually get to it. > > (but I have no way to test them). > > Boris goes through phases, like the rest of us. :-) Yes, this is correct. Doing hardware stuff consumes a lot of my time :( > His last round of changes from Mac OS X sorted out my panics quite > nicely. Good to hear. I've selected most critical bugfixes and there is still big diffs to merge. > It sounds like the message is "I'd like to help with smbfs, but don't > have time right now, and it'd make a whole lot more sense for someone > closer to the code to take a look." Obviously, I'll do the job at some moment. If someone can do it before - feel free to do this. This may even include import of userland part in the /contrib hierarchy. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE settling in (smbfs broken) again
On Fri, 05 Oct 2001 11:48:55 MST, Julian Elischer wrote: > I need to look at it again.. (I figured I just didn't have the time to try > understand it all AND do the rest of the kernel.) Of course the best woudl > be if Mr. Popov did the conversion but I believe he's incredibly busy at > the moment.. Certainly if someone else wants to make an effort at it. > they are welcome to do it.. otherwise I will eventually get to it. > (but I have no way to test them). Boris goes through phases, like the rest of us. :-) His last round of changes from Mac OS X sorted out my panics quite nicely. It sounds like the message is "I'd like to help with smbfs, but don't have time right now, and it'd make a whole lot more sense for someone closer to the code to take a look." Thanks for the reply. So long as I know not to hold my breath. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
KSE settling in (smbfs broken)
Hi Julian, I didn't realize that smbfs was a KSE casualty, but it's nice that you made this obvious with the following in sys/modules/Makefile: #removed while KSE settles in: # smbfs \ So at least it didn't take me long to figure out what was going on. My question is what sort of timeframe this "settling in" is likely to involve? I would have thought that a disconnected module would rot, but your settling in comment suggests that you have plans to reconnect it yourself? Or is this another way of saying "dead unless someone else fixes for KSE"? I copied the -current list because I doubt I'm the only one who's wondering how this is all going to work. Basically, I think a lot of us are wondering whether we can sit back and wait for you to fix the stuff that stopped working after the KSE import, or whether you're sitting back and waiting for us to do it. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
