cproto use in the kernel source tree?
I would like to automate generating the prototype list for smbfs. The list in include/linux/smb_fs.h is probably mostly correct ... or not. Does anyone use this type of tool anywhere else in the kernel sources? Any input on how to set it up right is appreciated. Here is what I have right now. arch/i386/math-emu/Makefile has this rule proto: cproto -e -DMAKING_PROTO *.c >fpu_proto.h If I do that in the smbfs Makefile, and run it as: $ make TOPDIR=`pwd` -C fs/smbfs proto I get heaps of errors (some of which I also get for the math-emu rule and fpu_proto.h is definitly hand edited, so I wonder if it is really used). For one thing it goes digging in "/usr/include/asm/" which isn't exactly what I want. I can improve it by changing the rule to: proto: cproto -e -I$(TOPDIR)/include -D__KERNEL__ -DMAKING_PROTO *.c > proto.h And that seems to sort of work. The only thing is that I get wierd errors on some gcc header: "/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h", line 43: parse error at token '__builtin_va_list' Expected: auto char define-name double extern inline register static ... union $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.0) $ rpm -qf `which gcc` gcc-2.96-69 $ rpm -qf `which cproto` cproto-4.6-5 I know it stops working (it misses some functions and complains more :) after I apply some of my non-released patches. But that is probably something I do wrong. Is cproto even a good tool for doing this in the kernel tree? /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] smbfs-2.4.6-pre3 - win95 flush & NetApp lastname
Hej
A less painful workaround than what I added during 2.4.5-pre for the
win9x-lies-about-filesizes-on-open-files problem. Replaces constant
flush'es with seek to end, and only when necessary.
Also, a fix where smbfs doesn't follow protocol and fails to return
'lastname' for all "infolevels", which breaks with NetApps.
Patch vs -pre1, but is fine vs -pre3. Please apply.
/Urban
diff -urN -X exclude linux-2.4.6-pre1-orig/fs/smbfs/ChangeLog
linux-2.4.6-pre1-smbfs/fs/smbfs/ChangeLog
--- linux-2.4.6-pre1-orig/fs/smbfs/ChangeLogWed May 30 21:57:15 2001
+++ linux-2.4.6-pre1-smbfs/fs/smbfs/ChangeLog Tue Jun 12 20:34:32 2001
@@ -1,5 +1,10 @@
ChangeLog for smbfs.
+2001-06-12 Urban Widmark <[EMAIL PROTECTED]>
+
+ * proc.c: replace the win95-flush fix with smb_seek, when needed.
+ * proc.c: readdir 'lastname' bug (NetApp dir listing fix)
+
2001-05-08 Urban Widmark <[EMAIL PROTECTED]>
* inode.c: Fix for changes on the server side not being detected
diff -urN -X exclude linux-2.4.6-pre1-orig/fs/smbfs/file.c
linux-2.4.6-pre1-smbfs/fs/smbfs/file.c
--- linux-2.4.6-pre1-orig/fs/smbfs/file.c Wed May 30 21:57:15 2001
+++ linux-2.4.6-pre1-smbfs/fs/smbfs/file.c Wed Jun 6 23:00:02 2001
@@ -151,6 +151,7 @@
* Update the inode now rather than waiting for a refresh.
*/
inode->i_mtime = inode->i_atime = CURRENT_TIME;
+ inode->u.smbfs_i.flags |= SMB_F_LOCALWRITE;
if (offset > inode->i_size)
inode->i_size = offset;
} while (count);
diff -urN -X exclude linux-2.4.6-pre1-orig/fs/smbfs/inode.c
linux-2.4.6-pre1-smbfs/fs/smbfs/inode.c
--- linux-2.4.6-pre1-orig/fs/smbfs/inode.c Wed May 30 21:57:15 2001
+++ linux-2.4.6-pre1-smbfs/fs/smbfs/inode.c Wed Jun 6 23:00:02 2001
@@ -141,8 +141,8 @@
inode->u.smbfs_i.oldmtime = jiffies;
if (inode->i_mtime != last_time || inode->i_size != last_sz) {
- VERBOSE("%s/%s changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
- DENTRY_PATH(dentry),
+ VERBOSE("%ld changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
+ inode->i_ino,
(long) last_time, (long) inode->i_mtime,
(long) last_sz, (long) inode->i_size);
diff -urN -X exclude linux-2.4.6-pre1-orig/fs/smbfs/proc.c
linux-2.4.6-pre1-smbfs/fs/smbfs/proc.c
--- linux-2.4.6-pre1-orig/fs/smbfs/proc.c Wed May 30 21:57:15 2001
+++ linux-2.4.6-pre1-smbfs/fs/smbfs/proc.c Thu Jun 7 21:20:59 2001
@@ -919,6 +919,31 @@
}
/*
+ * Called with the server locked
+ */
+static int
+smb_proc_seek(struct smb_sb_info *server, __u16 fileid,
+ __u16 mode, off_t offset)
+{
+ int result;
+
+ smb_setup_header(server, SMBlseek, 4, 0);
+ WSET(server->packet, smb_vwv0, fileid);
+ WSET(server->packet, smb_vwv1, mode);
+ DSET(server->packet, smb_vwv2, offset);
+
+ result = smb_request_ok(server, SMBlseek, 2, 0);
+ if (result < 0) {
+ result = 0;
+ goto out;
+ }
+
+ result = DVAL(server->packet, smb_vwv0);
+out:
+ return result;
+}
+
+/*
* We're called with the server locked, and we leave it that way.
*/
static int
@@ -1210,11 +1235,6 @@
if (result >= 0)
result = WVAL(server->packet, smb_vwv0);
- /* flush to disk, to trigger win9x to update its filesize */
- /* FIXME: this will be rather costly, won't it? */
- if (server->mnt->flags & SMB_MOUNT_WIN95)
- smb_proc_flush(server, fileid);
-
smb_unlock_server(server);
return result;
}
@@ -1858,6 +1878,7 @@
result = mask_len;
goto unlock_return;
}
+ mask_len--; /* mask_len is strlen, not #bytes */
first = 1;
VERBOSE("starting mask_len=%d, mask=%s\n", mask_len, mask);
@@ -1946,18 +1967,28 @@
* Note that some servers (win95?) point to the filename and
* others (NT4, Samba using NT1) to the dir entry. We assume
* here that those who do not point to a filename do not need
-* this info to continue the listing. OS/2 needs this, but it
-* talks "infolevel 1"
+* this info to continue the listing.
+*
+* OS/2 needs this and talks infolevel 1
+* NetApps want lastname with infolevel 260
+*
+* Both are happy if we return the data they point to. So we do.
*/
mask_len = 0;
- if (info_level == 1 && ff_lastname > 0 &&
- ff_lastname < resp_data_len) {
[patch][CFT] Re: via-rhine DFE-530TX rev A1
> >Are you sure. What's the version of your driver. Please tell me. It's
> >important.
> >I remember we have fixed it already.
>
> The driver version (dlkfet.sys) is 2.52 from 08/06/2000. this is the lastest
> driver from the original dlink site.
Perhaps Yiping Chen was talking about a D-Link linux driver?
David Vrabel has found a D-Link driver ("1.11") based on Donald Beckers
that fixes the "00:00:00:00:00 after rebooting from win98" problem.
Here is a patch vs 2.4.5-ac4 that may fix this (if I didn't break it).
http://www.hojdpunkten.ac.se/054/via-rhine-2.4.5-ac4-dlink-3.patch
Please test and let me know if it works. It should apply vs any 2.4.5*
kernel. I have added those that I know have reported this problem before
to the Cc list.
What the driver does differently at init time is disable wake-on-lan and
power-management-events and then reload the MAC Address from EEPROM.
The reload code is also in the latest test version (1.10) from Donald
Becker at www.scyld.com, and that is the code I have used with slight
modification. I don't know if reloading from EEPROM alone is enough to fix
the 00:00:00:00:00 bug.
There is also a minor thing with 0x01 being a reserved bit in TxConfig,
that should probably be 0x02 to set it to loopback.
The D-Link driver has some other changes for various things. I have been
unable to find the driver on dlinks site, but I have the copy David sent
me:
http://www.hojdpunkten.ac.se/054/via-rhineb1.zip
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: via-rhine DFE-530TX rev A1
On Wed, 30 May 2001, Rose, Daniel wrote: > It seems as though my card will not reset anymore after running windows 98, > even after a cold boot, and recompiling the kernel. Below is the output of > dmesg, lspci -n and ifconfig. Does anyone have any ideas? (please cc > replies) Have you tried cutting power to the machine? (ie physically unplugging it) Someone has claimed that the chip may not reset otherwise. As it is Wake-On-Lan capable, that sort of makes sense - it needs to be not entirely dead. > via-rhine.c:v1.08b-LK1.1.8 4/17/2000 Written by Donald Becker > http://www.scyld.com/network/via-rhine.html > PCI: Found IRQ 10 for device 00:11.0 > PCI: The same IRQ used for device 00:07.2 > eth0: VIA VT6102 Rhine-II at 0xd000, 00:00:00:00:00:00, IRQ 10. [snip] > 00:11.0 Class 0200: 1106:3065 (rev 42) Are you sure the card is marked rev-A1 and not rev-B1? I was hoping DFE-530TXs with vt6102 were all rev-B1. Can you check what's printed on the card and send me the markings on the main chips? (one is probably marked DL10030, DL10030A or possibly vt6102 with a big VIA logo) /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (via-rhine.c problem) 2.4.5 and pppd/pppoe
On 29 May 2001, Daniel Rose wrote: > Ok, I have decided the problem lays in via-rhine.c, the ethernet driver > for my card. The second boot finds the mac address as 00's all the time, > regardless of whether the driver is compiled as a module, or monolith. Do you boot something else in between? Like win98? There is a known problem with the via-rhine driver not being able to restart some versions of the card after win98 has shut it down. Perhaps some bioses do similar clever things. This seems to only happen with newer chips that have power management support. If you don't boot into win98, perhaps you can play with bios settings until the driver is fixed (or fix the driver of course). Which type of via-rhine do you have? (manufacturer, model of card) When you boot what does dmesg say about eth0? (or lspci -n) D-Link makes a card called DFE-530TX. If you have that it can be one of (at least) 2 different versions. Could you in addition to sending lspci info identify which of these images match best? DFE-530TX REV-A1 (vt3043, PCI ID 1106:3043) http://www.intozgc.com/2001jrsc/200103/200103image/26%B5%DA%B6%FE%D6%D6.jpg DFE-530TX REV-B1 (hopefully vt6102, PCI ID 1106:3065 but I'm not sure) http://www.intozgc.com/2001jrsc/200103/200103image/26%D5%FD%C6%B7.jpg or this which is also called B1 ... but a chip with different markings. http://www.intozgc.com/2001jrsc/200103/200103image/26%B5%DA%D2%BB%D6%D6.jpg This page tries to explain something about card versions, but I don't speak the language (which ever it is). http://www.intozgc.com/2001jrsc/200103/20010326.htm I think the conclusion is DL10030A -> REV-B1, DL10030 -> REV-A1. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Alpha SMP Low Outbound Bandwidth
On 25 May 2001, Jay Thorne wrote: > Netperf is a pretty good idea. Should not be a cpu bottleneck. Thats a > good thing. So pretty much the same results as wu-ftpd: Note that I used > the 466 mhz quad with a via-rhine, since the 400 locked up and was still > fscking when I started this test. > > Recv SendSend > Socket Socket Message Elapsed > Size SizeSize Time Throughput > bytes bytes bytessecs.10^6bits/sec > > To alpha 87380 16384 1638410.02 39.25 > x86 local87380 16384 163849.99 559.46 > alpha local 87380 16384 1638410.01 547.27 > alp to x86 87380 16384 1638410.01 25.77 > another x86 87380 16384 163849.99 553.67 > to same x86 87380 16384 1638410.00 82.79 > and back 87380 16384 1638410.00 93.89 What type of NIC is in the x86'es? If they are not the same, what happens if you put one of those in the alphas? (and what happens with the via-rhine if put in one of the x86'es?) Alphas don't like unaligned memory accesses (not sure how bad those are). I think that you can get some idea on the frequence of those with 'cat /proc/cpuinfo' where it should say "kernel unaligned acc" and then some numbers. If that first number keeps going up then the driver(s) or something isn't being nice. Well, just a though. Oh yes, your original message showed a value of 1646246 for kernel space unaligned accesses. Is that high? The userspace value is 0, so I assume that is high. The value for 'pc=' should give the address of where the last unaligned access took place (look it up in System.map or /proc/ksyms) Does the value grow faster when you run your netperf tests? That still doesn't explain the SMP vs UP difference. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFT] smbfs bugfixes for 2.4.4
On Wed, 23 May 2001, Xuan Baldauf wrote:
> Urban Widmark wrote:
>
> > The only other way I have found so far to get it to return the right file
> > size is to do a "seek-to-end". That still means an extra SMB but it avoids
> > the very painful "sync to disk".
> >
> > Fortunately the seek is only necessary when refreshing inode info, on a
> > "win95" server, on a file that is open and that we have written to.
>
> Maybe it is also a workaround for the problem where changes on the
> windows side are not reflected?
Yes, that was the point of removing the LOCALWRITE flag in the first
place. As far as I can tell this should still fix the file cache/sync
problems that have been found.
> Is it possible to resend the patch in mime format or publish it somewhere accessible
>by an URL? Netscape Messenger
> creates spaces everywhere where tabs should be :-(
Certainly.
/Urban
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/Makefile
linux-2.4.5-pre4-smbfs/fs/smbfs/Makefile
--- linux-2.4.5-pre4-orig/fs/smbfs/Makefile Thu Feb 22 20:52:03 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/MakefileWed May 23 00:19:08 2001
@@ -16,6 +16,7 @@
# SMBFS_PARANOIA should normally be enabled.
EXTRA_CFLAGS += -DSMBFS_PARANOIA
+EXTRA_CFLAGS += -DSMB_WIN95_LOCALWRITE_FIX
#EXTRA_CFLAGS += -DSMBFS_DEBUG
#EXTRA_CFLAGS += -DSMBFS_DEBUG_VERBOSE
#EXTRA_CFLAGS += -DDEBUG_SMB_MALLOC
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/file.c
linux-2.4.5-pre4-smbfs/fs/smbfs/file.c
--- linux-2.4.5-pre4-orig/fs/smbfs/file.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/file.c Tue May 22 23:53:43 2001
@@ -151,6 +151,7 @@
* Update the inode now rather than waiting for a refresh.
*/
inode->i_mtime = inode->i_atime = CURRENT_TIME;
+ inode->u.smbfs_i.flags |= SMB_F_LOCALWRITE;
if (offset > inode->i_size)
inode->i_size = offset;
} while (count);
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/inode.c
linux-2.4.5-pre4-smbfs/fs/smbfs/inode.c
--- linux-2.4.5-pre4-orig/fs/smbfs/inode.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/inode.c Tue May 22 21:02:29 2001
@@ -141,8 +141,8 @@
inode->u.smbfs_i.oldmtime = jiffies;
if (inode->i_mtime != last_time || inode->i_size != last_sz) {
- VERBOSE("%s/%s changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
- DENTRY_PATH(dentry),
+ VERBOSE("%ld changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
+ inode->i_ino,
(long) last_time, (long) inode->i_mtime,
(long) last_sz, (long) inode->i_size);
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/proc.c
linux-2.4.5-pre4-smbfs/fs/smbfs/proc.c
--- linux-2.4.5-pre4-orig/fs/smbfs/proc.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/proc.c Wed May 23 00:19:19 2001
@@ -919,6 +919,31 @@
}
/*
+ * Called with the server locked
+ */
+static int
+smb_proc_seek(struct smb_sb_info *server, __u16 fileid,
+ __u16 mode, off_t offset)
+{
+ int result;
+
+ smb_setup_header(server, SMBlseek, 4, 0);
+ WSET(server->packet, smb_vwv0, fileid);
+ WSET(server->packet, smb_vwv1, mode);
+ DSET(server->packet, smb_vwv2, offset);
+
+ result = smb_request_ok(server, SMBlseek, 2, 0);
+ if (result < 0) {
+ result = 0;
+ goto out;
+ }
+
+ result = DVAL(server->packet, smb_vwv0);
+out:
+ return result;
+}
+
+/*
* We're called with the server locked, and we leave it that way.
*/
static int
@@ -1210,10 +1235,12 @@
if (result >= 0)
result = WVAL(server->packet, smb_vwv0);
+#ifndef SMB_WIN95_LOCALWRITE_FIX
/* flush to disk, to trigger win9x to update its filesize */
/* FIXME: this will be rather costly, won't it? */
if (server->mnt->flags & SMB_MOUNT_WIN95)
smb_proc_flush(server, fileid);
+#endif
smb_unlock_server(server);
return result;
@@ -2246,6 +2273,7 @@
struct smb_fattr *fattr)
{
int result;
+ struct inode *inode = dir->d_inode;
smb_init_dirent(server, fattr);
@@ -2262,6 +2290,22 @@
else
result = smb_proc_getattr_trans2(server, dir, fattr);
}
+
+#ifdef SMB_WIN95_LOCALWRITE_FIX
+ /*
+* None of the getattr versions here can make win95 return the right
+* filesize if there are changes made to it. A seek-to-end does return
+* the right size, but we
Re: [PATCH][RFT] smbfs bugfixes for 2.4.4
On Mon, 21 May 2001, Xuan Baldauf wrote:
> That is annoying, because it heavily slows down bulk transfers of small
> writes, like automatically unzipping a new mozilla build from the linux box to
> the windows box. Every write of say 100 bytes is implemented as
>
> send write req
> recv write ack
> send flush req
> sync to disk (on the windows machine)
> recv flush ack
The only other way I have found so far to get it to return the right file
size is to do a "seek-to-end". That still means an extra SMB but it avoids
the very painful "sync to disk".
Fortunately the seek is only necessary when refreshing inode info, on a
"win95" server, on a file that is open and that we have written to.
This should be significantly better, but still works with my testcases.
patch vs 2.4.5-pre4, please test.
/Urban
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/Makefile
linux-2.4.5-pre4-smbfs/fs/smbfs/Makefile
--- linux-2.4.5-pre4-orig/fs/smbfs/Makefile Thu Feb 22 20:52:03 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/MakefileWed May 23 00:19:08 2001
@@ -16,6 +16,7 @@
# SMBFS_PARANOIA should normally be enabled.
EXTRA_CFLAGS += -DSMBFS_PARANOIA
+EXTRA_CFLAGS += -DSMB_WIN95_LOCALWRITE_FIX
#EXTRA_CFLAGS += -DSMBFS_DEBUG
#EXTRA_CFLAGS += -DSMBFS_DEBUG_VERBOSE
#EXTRA_CFLAGS += -DDEBUG_SMB_MALLOC
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/file.c
linux-2.4.5-pre4-smbfs/fs/smbfs/file.c
--- linux-2.4.5-pre4-orig/fs/smbfs/file.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/file.c Tue May 22 23:53:43 2001
@@ -151,6 +151,7 @@
* Update the inode now rather than waiting for a refresh.
*/
inode->i_mtime = inode->i_atime = CURRENT_TIME;
+ inode->u.smbfs_i.flags |= SMB_F_LOCALWRITE;
if (offset > inode->i_size)
inode->i_size = offset;
} while (count);
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/inode.c
linux-2.4.5-pre4-smbfs/fs/smbfs/inode.c
--- linux-2.4.5-pre4-orig/fs/smbfs/inode.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/inode.c Tue May 22 21:02:29 2001
@@ -141,8 +141,8 @@
inode->u.smbfs_i.oldmtime = jiffies;
if (inode->i_mtime != last_time || inode->i_size != last_sz) {
- VERBOSE("%s/%s changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
- DENTRY_PATH(dentry),
+ VERBOSE("%ld changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
+ inode->i_ino,
(long) last_time, (long) inode->i_mtime,
(long) last_sz, (long) inode->i_size);
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/proc.c
linux-2.4.5-pre4-smbfs/fs/smbfs/proc.c
--- linux-2.4.5-pre4-orig/fs/smbfs/proc.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/proc.c Wed May 23 00:19:19 2001
@@ -919,6 +919,31 @@
}
/*
+ * Called with the server locked
+ */
+static int
+smb_proc_seek(struct smb_sb_info *server, __u16 fileid,
+ __u16 mode, off_t offset)
+{
+ int result;
+
+ smb_setup_header(server, SMBlseek, 4, 0);
+ WSET(server->packet, smb_vwv0, fileid);
+ WSET(server->packet, smb_vwv1, mode);
+ DSET(server->packet, smb_vwv2, offset);
+
+ result = smb_request_ok(server, SMBlseek, 2, 0);
+ if (result < 0) {
+ result = 0;
+ goto out;
+ }
+
+ result = DVAL(server->packet, smb_vwv0);
+out:
+ return result;
+}
+
+/*
* We're called with the server locked, and we leave it that way.
*/
static int
@@ -1210,10 +1235,12 @@
if (result >= 0)
result = WVAL(server->packet, smb_vwv0);
+#ifndef SMB_WIN95_LOCALWRITE_FIX
/* flush to disk, to trigger win9x to update its filesize */
/* FIXME: this will be rather costly, won't it? */
if (server->mnt->flags & SMB_MOUNT_WIN95)
smb_proc_flush(server, fileid);
+#endif
smb_unlock_server(server);
return result;
@@ -2246,6 +2273,7 @@
struct smb_fattr *fattr)
{
int result;
+ struct inode *inode = dir->d_inode;
smb_init_dirent(server, fattr);
@@ -2262,6 +2290,22 @@
else
result = smb_proc_getattr_trans2(server, dir, fattr);
}
+
+#ifdef SMB_WIN95_LOCALWRITE_FIX
+ /*
+* None of the getattr versions here can make win95 return the right
+* filesize if there are changes made to it. A seek-to-end does return
+* the right size, but we only need to do that on files we have written.
+*/
+ if (server->mnt->flags & SMB_MOUNT_WIN95 &&
+ inode &&
+ inode->u.smbfs_i.flags & SMB_F_LOCALWRITE &&
+ smb_is_open(inode))
+ {
+ __u16 fileid = inode->u.smbfs_i.fileid;
+ fattr->f_size = smb_proc_seek(server, fileid, 2, 0);
+ }
+#endif
sm
Re: Background to the argument about CML2 design philosophy
On Mon, 21 May 2001, Eric S. Raymond wrote: > the NEW tag). That phase ended almost a month ago. Nobody who has > actually tried the CML2 tools more recently has reported that the UI > changes present any difficulty. What happened with the discussion on configurable colors in make menuconfig? Darkblue on black as frozen options get isn't exactly optimal ... at least not for my eyes. Being next to a bold, white text doesn't help either. > CML2 drops its configuration results in the same place, in the same > formats, as CML1. So you should in fact be able to type `make menuconfig' > and `make oldconfig' with good results. Have you actually tried this? It works for me, but anyone testing this should know that the CML2 tools read "config.out" if it finds one. So people that do things like: make mrproper ; cp ../.config-2.4 .config ; make oldconfig will have to change to copying config.out instead. Doing like this sort of works* if there is no config.out, otherwise it does not (as it uses the config.out). Saying that the config result ends up in the same place and same format is somewhat misleading, you do get a copy in the CML1 output format but the tools doesn't care about that if it can find a file in the new format. *) "Sort of works", since doing like I do will cause you to get a lot of questions that you have already answered. That appears to be a one-time problem as 'oldconfig' does not read "# CONFIG_FOO is not set" as "no". Would be nice if it did. make mrproper doesn't remove config.out. It should since that's what it does with .config* files. Not sure if it should remove the rules.out file also, but I think it should as the idea(?) with mrproper is to clean up anything that is generated. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFT] smbfs bugfixes for 2.4.4
On Mon, 21 May 2001, Xuan Baldauf wrote:
> Hello Urban,
>
> I've been playing around a while with that patch and so far could not find any
> problems anymore. But I've noticed some other annoying behaviour, which might
Good.
> be caused by trying to work around the initially reported bug where the
> win98se server does not update something (the new file contents after writing
> to a file or the file size?) when something is written by the client: Every
> little SMBwrite is followed by an SMBflush, which is translated by win98se
> into a "commit" of the file, which seems to be an fsync(2) equivalent.
Yes, I know.
>
> That is annoying, because it heavily slows down bulk transfers of small
> writes, like automatically unzipping a new mozilla build from the linux box to
> the windows box. Every write of say 100 bytes is implemented as
>
> send write req
> recv write ack
> send flush req
> sync to disk (on the windows machine)
> recv flush ack
>
> This creates heaviest disk load (on the windows machine) for minimal
> throughput. Is the SMBflush needed anymore, after you seem to have found
> another, better workaround?
SMBflush is the better variant of the workaround I sent you first, as
flush will always work but setting that flag doesn't ("correctness" over
speed, or something like that).
But does it really do that? It will only flush when the page you wrote to
is sent to the fs for writing. The page cache doesn't do that on each
write (I assume, should check) so then a 10 byte write, followed by
another 10 doesn't give 2 flushes but only one when that page is written.
It's still very much a slowdown with win9x servers.
I'll see if I can come up with something better than flush. What I need is
a way to tell the server that the file did change so that it will start
giving back the correct size.
I'm guessing that the win9x smb server caches some values but doesn't
understand that writing changes that. Possibly an assumption that the
client "knows" the correct filesize (but that breaks if someone else
changes the file).
People shouldn't be using win9x as "servers" anyway ... :)
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFT] smbfs bugfixes for 2.4.4
On 7 May 2001, Linus Torvalds wrote: > It has code to do that in smb_revalidate_inode(), but it may be that > something else refreshes the inode size _without_ doing the proper > invalidation checks. Or maybe Urban broke that logic by mistake while > fixing the other one ;) No, I broke it when copying the ncpfs dircache code. That code will reuse an old inode if it already exists (and thus also any pages attached to it), which is what I wanted and should be fine except that it needs to invalidate_inode_pages() if something changed. Xuan and James, you have both seen this bug with smbfs not properly handling changes made on the server. Could you please test this patch vs 2.4.4 and let me know if it helps or not. http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.4-truncate+retry-4.patch (Apply with 'patch -p1' in the linux/ source dir) /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFT] smbfs bugfixes for 2.4.4
On Sun, 6 May 2001, Xuan Baldauf wrote: > it does not fix|work around the bug completely: > > 1. windows: Create a file, e.g. with 741 bytes. > 2. linux: "ls -la" will show you the file with the correct size (741) > 3. linux: read the file into your smbfs cache (e.g. "less file") > 4. windows: add some contents to the file, e.g. so that it is now 896 bytes > long > 5. linux: "ls -la" will show you the file with the correct size (896) > 6. linux: read the file (e.g. "less file") Ah, but now you are talking about a different bug. Your original testcase only contained changes from the smbfs client (the abc/xyz test). For me that is solved by this patch and I wanted you to check if it did in your environment as well. I have one other report of something being broken with changes made on the server side only. There is also yet another problem if you change a file from smbfs and from the server. The smbfs side will remember the wrong filesize. This may be a fix for that: http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.4-truncate+retry-3.patch (-3, not -2) /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hierarchy doesn't solve the problem
On Thu, 3 May 2001, Eric S. Raymond wrote: > In many cases there is no way to define "upper" or "lower". (X86 and > SMP) implies RTC!=n is actually a good example. Here's where they fit > in the tree: > > main 'Linux Kernel Configuration System' > arch 'Processor type' > X86'Intel or compatible 80x86 processor' > generic'Architecture-independent feature selections' > SMP'Symmetric Multi-Processing support' > archihacks 'Architecture-specific hardware hacks' > RTC'Enhanced Real Time Clock Support' > > Yes, that's right -- they're all at the same level. OK, X86 is frozen > by hypothesis. So now give me a rule for telling which of SMP and RTC > is "superior". Note that in order to make the rule usable by the > deducer, it can't know anything about the semantics of the symbols. Doesn't 'make config' still ask the user about config options one-by-one? (If not you can ignore the rest of this, I'd test it but I don't have time to mess with python2 right now). Then it must somehow handle me trying to (incorrectly) answer X86=Y, SMP=Y, RTC=N in some order? The old oldconfig uses the existing .config as default answers, not as initial state (right?). If an answer is missing or invalid then the user gets a question. It never looks at all options at once. Doesn't that work here? When running make config I am guessing that this would happen: The first symbol hit may be X86. The config-input has Y here, so it is answered Y (I assume that is valid, otherwise do whatever the tty version would normally do). The second symbol would be SMP, the config-input says Y so it is set. Since this requires RTC also I don't know what the tty version does, but it must allow me to set it somehow. The third symbol is RTC, the config-input has no defined value but it is required by other settings so we ask. Possibly this is done automatically right after setting SMP to Y. There would be no 3^n problem as there is a defined order between the symbols (whatever order 'make config' wants answers on an empty initial state). Perhaps I have missed something, but I really prefer the old oldconfig over the new oldconfig. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][RFT] smbfs bugfixes for 2.4.4
Hello all
This patch have been building up for a while, without reaching some
undefined level of readiness. I would like some feedback from other smbfs
users before submitting this for 2.4.4-something. Particularly from people
mounting win9x shares.
* win9x will sometimes not give back the right filesize, this can cause
problems when cp'ing a file over an existing one. When truncating the
file to 0 bytes the server keeps reporting the old size and much
confusion arises.
(reported by Xuan Baldauf, could you verify that this fixes it? If it
does it's a much better fix than the workaround you got before.)
* The timeout for a reconnect was only 5 seconds, which may not be enough.
To make it worse, if there is a timeout the mount will be dead.
umount time.
* Allow smbmount to supply a new connection even if the retry attempt has
timed-out. "dead" mounts can then be resurrected ... this allows you to
replace a smbmount that have crashed, or it would if smbmount supported
that.
* Locking bug in smb_newconn, it modifies the "server" struct without
having the server lock.
* Fix theoretical memory leak and the missing smb malloc debug functions.
* fsync now causes a SMBflush to tell the server that we want the data to
hit the disc. (as suggested by Jochen Dolze)
* Don't zero out the superblock flags to allow readonly mounts to be
readonly. If someone knows why sb->s_flags = 0; is a good idea I'd
like to know. (fix&testing by René Scharfe)
Patch vs 2.4.4, if someone prefers 2.4.4-acX it should work (even if the
patch fails on changes to Configure.help).
/Urban
diff -urN -X exclude linux-2.4.4-orig/Documentation/Configure.help
linux-2.4.4-smbfs/Documentation/Configure.help
--- linux-2.4.4-orig/Documentation/Configure.help Wed May 2 20:01:07 2001
+++ linux-2.4.4-smbfs/Documentation/Configure.help Wed May 2 20:44:43 2001
@@ -12081,10 +12081,7 @@
The nls settings can be changed at mount time, if your smbmount
supports that, using the codepage and iocharset parameters.
- Currently no smbmount distributed with samba supports this, it is
- assumed future versions will. In the meantime you can get an
- unofficial patch for samba 2.0.7 from:
- http://www.hojdpunkten.ac.se/054/samba/index.html
+ smbmount from samba 2.2.0 or later supports this.
nls support setting
CONFIG_SMB_NLS_REMOTE
@@ -12096,10 +12093,7 @@
The nls settings can be changed at mount time, if your smbmount
supports that, using the codepage and iocharset parameters.
- Currently no smbmount distributed with samba supports this, it is
- assumed future versions will. In the meantime you can get an
- unofficial patch for samba 2.0.7 from:
- http://www.hojdpunkten.ac.se/054/samba/index.html
+ smbmount from samba 2.2.0 or later supports this.
Coda file system support (advanced network fs)
CONFIG_CODA_FS
diff -urN -X exclude linux-2.4.4-orig/MAINTAINERS linux-2.4.4-smbfs/MAINTAINERS
--- linux-2.4.4-orig/MAINTAINERSWed May 2 20:01:07 2001
+++ linux-2.4.4-smbfs/MAINTAINERS Wed May 2 20:42:24 2001
@@ -1171,7 +1171,7 @@
SMB FILESYSTEM
P: Urban Widmark
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
W: http://samba.org/
L: [EMAIL PROTECTED]
S: Maintained
diff -urN -X exclude linux-2.4.4-orig/fs/smbfs/ChangeLog
linux-2.4.4-smbfs/fs/smbfs/ChangeLog
--- linux-2.4.4-orig/fs/smbfs/ChangeLog Sat Mar 31 19:11:53 2001
+++ linux-2.4.4-smbfs/fs/smbfs/ChangeLogWed May 2 23:48:56 2001
@@ -1,5 +1,18 @@
ChangeLog for smbfs.
+2001-04-25 René Scharfe <[EMAIL PROTECTED]>
+
+ * inode.c: Don't clear s_flags and allow ro mounts
+
+2001-04-21 Urban Widmark <[EMAIL PROTECTED]>
+
+ * dir.c, proc.c: replace tests on conn_pid with tests on state to
+ fix smbmount reconnect on smb_retry timeout and up the timeout to 30s.
+ * proc.c: smb_newconn must have the server locked while updating it.
+ * inode.c, proc.c: need flush after truncate on some servers (win9x)
+ * file.c: add call to send SMBflush on fsync
+ (as suggested by Jochen Dolze <[EMAIL PROTECTED]>)
+
2001-03-06 Urban Widmark <[EMAIL PROTECTED]>
* cache.c: d_add on hashed dentries corrupts d_hash list and
diff -urN -X exclude linux-2.4.4-orig/fs/smbfs/dir.c linux-2.4.4-smbfs/fs/smbfs/dir.c
--- linux-2.4.4-orig/fs/smbfs/dir.c Thu Feb 22 20:52:03 2001
+++ linux-2.4.4-smbfs/fs/smbfs/dir.cWed May 2 20:42:24 2001
@@ -210,10 +210,6 @@
return result;
}
-/*
- * Note: in order to allow the smbmount process to open the
- * mount point, we don't revalidate if conn_pid is NULL.
- */
static int
smb_dir_open(struct inode *dir, struct file *file)
{
@@ -230,14 +226,18 @@
*/
lock_kernel();
server = server_from_dentry(dentry);
- if (server-&
Re: [BUG] smbfs: caching problems
On Sun, 1 Apr 2001, Xuan Baldauf wrote:
> there is something wrong with smbfs caching which makes my
> applications fail. The behaviour happens with
> linux-2.4.3-pre4 and linux-2.4.3-final.
>
> Consider following shell script: (where /mnt/n is a
> smbmounted smb share from a Win98SE box)
Try the attached patch, as a workaround.
Not really sure what is happening, but it seems like win98se isn't
updating the filesize immediately (?).
After truncating the file to 0 bytes the server still returns the old size
(516) when asked (smb_proc_getattr). Somewhere that causes something to
keep the pages for the file (smb_revalidate?) or simply be confused on the
length of the file (508).
I don't understand how as vmtruncate should have thrown out the old stuff
already ... maybe the same page is reused and the last bytes (that
shouldn't be in the file) remain from the last write.
It works with NT4 and Samba, they both return the expected 0 bytes after
truncating to 0. refresh = 0 will not ask and instead run with the 0 byte
length that vmtruncate has set.
/Urban
diff -urN -X exclude linux-2.4.3-orig/fs/smbfs/inode.c
linux-2.4.3-smbfs/fs/smbfs/inode.c
--- linux-2.4.3-orig/fs/smbfs/inode.c Sat Mar 31 19:11:53 2001
+++ linux-2.4.3-smbfs/fs/smbfs/inode.c Thu Apr 5 00:32:07 2001
@@ -234,9 +234,10 @@
last_sz = inode->i_size;
error = smb_refresh_inode(dentry);
if (error || inode->i_mtime != last_time || inode->i_size != last_sz) {
- VERBOSE("%s/%s changed, old=%ld, new=%ld\n",
+ VERBOSE("%s/%s changed, old=%ld, new=%ld, osz=%ld, sz=%ld\n",
DENTRY_PATH(dentry),
- (long) last_time, (long) inode->i_mtime);
+ (long) last_time, (long) inode->i_mtime,
+ (long) last_sz, (long) inode->i_size);
if (!S_ISDIR(inode->i_mode))
invalidate_inode_pages(inode);
@@ -550,7 +551,7 @@
if (error)
goto out;
vmtruncate(inode, attr->ia_size);
- refresh = 1;
+ refresh = 0;
}
/*
Re: [BUG] smbfs: caching problems
On Sun, 1 Apr 2001, Xuan Baldauf wrote: > Hello, > > there is something wrong with smbfs caching which makes my > applications fail. The behaviour happens with > linux-2.4.3-pre4 and linux-2.4.3-final. Any version you know it doesn't happen with? (including 2.2 versions) > Consider following shell script: (where /mnt/n is a > smbmounted smb share from a Win98SE box) Reproducible, but so far only with win98 (SE?). NT4, samba are testing ok with the sizes I have tried, not sure what that means. Thanks a lot for providing a testcase. I have started looking but right now a lot of non-linux things are calling for attention. If it isn't trivial I may need some time to get around to it. (insanely early morning flights to Stockholm and late evening return flights, work, easter holiday preparations, local community stuff ... and that was just today. Sorry, I'm tired and felt like complaining to someone. Pay no attention to me :) You may want to consider looking into it yourself, if you need it fixed quickly. 'tail -f' has previously been depending on smb_revalidate_inode to update inode information properly (I suspect that one right now, will check tomorrow. Possibly that smb open/close changes modification times ... and/or some win95 bug workaround is causing this?) Enabling verbose debug (select parts perhaps) can be useful. Adding debug printouts on inode mtime+size. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Q. about oops backtrace
On Wed, 7 Mar 2001, Pete Zaitcev wrote:
> Trace; c0127414
> Trace; c0136a2d
> Trace; c012722e
> Trace; c0127290
> Trace; c0127414
> Trace; c014cdec
> Trace; c0143f80
> Trace; c0144aae
> Trace; c014cdec
> Trace; c01392c9
> Trace; c0138130
> Trace; c013805d
> Trace; c0148b97
> Trace; c01091c7
>
> What is with those recursive handle_mm_fault calls?
Unless I'm mistaken the call trace in an i386 oops is printed by
arch/i386/kernel/traps.c:show_trace()
And it simply prints any value within certain limits.
if (((addr >= (unsigned long) &_stext) &&
(addr <= (unsigned long) &_etext)) ||
((addr >= module_start) && (addr <= module_end))) {
/* ... print it ... */
If a function is passed as a parameter it will of course be on the stack,
even when it isn't a return value.
The dput entries are strange too, does dput call path_walk?
(is the translation from numbers to symbols correct?)
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] smbfs: d_add + re-open fixes
Hello
Enough details in the ChangeLog I hope.
Patch vs 2.4.2-ac12 but appears to be clean vs 2.4.3-pre2 and the recently
released -ac13. Please apply.
/Urban
diff -urN -X exclude linux-2.4.2-ac12-orig/fs/smbfs/ChangeLog
linux-2.4.2-ac12-smbfs/fs/smbfs/ChangeLog
--- linux-2.4.2-ac12-orig/fs/smbfs/ChangeLogThu Feb 22 20:52:03 2001
+++ linux-2.4.2-ac12-smbfs/fs/smbfs/ChangeLog Tue Mar 6 23:50:06 2001
@@ -1,9 +1,22 @@
ChangeLog for smbfs.
+2001-03-06 Urban Widmark <[EMAIL PROTECTED]>
+
+ * cache.c: d_add on hashed dentries corrupts d_hash list and
+ causes loops in d_lookup. Inherited bug. :)
+ * inode.c: tail -f fix for non-readonly opened files
+ (related to the smb_proc_open change).
+ * inode.c: tail -f fix for fast size changes with the same mtime.
+
+2001-03-02 Michael Kockelkorn <[EMAIL PROTECTED]>
+
+ * proc.c: fix smb_proc_open to allow open being called more than once
+ with different modes (O_RDONLY -> O_WRONLY) without closing.
+
2001-02-10 Urban Widmark <[EMAIL PROTECTED]>
- * dir.c: replace non-bigmem safe cache with cache code from ncpfs
- and fix some other bigmem bugs in smbfs.
+ * dir.c, cache.c: replace non-bigmem safe cache with cache code
+ from ncpfs and fix some other bigmem bugs in smbfs.
* inode.c: root dentry not properly initialized
* proc.c, sock.c: adjust max parameters & max data to follow max_xmit
lots of servers were having find_next trouble with this.
diff -urN -X exclude linux-2.4.2-ac12-orig/fs/smbfs/cache.c
linux-2.4.2-ac12-smbfs/fs/smbfs/cache.c
--- linux-2.4.2-ac12-orig/fs/smbfs/cache.c Thu Feb 22 20:52:03 2001
+++ linux-2.4.2-ac12-smbfs/fs/smbfs/cache.c Tue Mar 6 23:01:17 2001
@@ -167,6 +167,7 @@
struct inode *newino, *inode = dentry->d_inode;
struct smb_cache_control ctl = *ctrl;
int valid = 0;
+ int hashed = 0;
ino_t ino = 0;
qname->hash = full_name_hash(qname->name, qname->len);
@@ -181,9 +182,11 @@
newdent = d_alloc(dentry, qname);
if (!newdent)
goto end_advance;
- } else
+ } else {
+ hashed = 1;
memcpy((char *) newdent->d_name.name, qname->name,
newdent->d_name.len);
+ }
if (!newdent->d_inode) {
smb_renew_times(newdent);
@@ -191,7 +194,9 @@
newino = smb_iget(inode->i_sb, entry);
if (newino) {
smb_new_dentry(newdent);
- d_add(newdent, newino);
+ d_instantiate(newdent, newino);
+ if (!hashed)
+ d_rehash(newdent);
}
} else
smb_set_inode_attr(newdent->d_inode, entry);
diff -urN -X exclude linux-2.4.2-ac12-orig/fs/smbfs/inode.c
linux-2.4.2-ac12-smbfs/fs/smbfs/inode.c
--- linux-2.4.2-ac12-orig/fs/smbfs/inode.c Tue Mar 6 21:14:31 2001
+++ linux-2.4.2-ac12-smbfs/fs/smbfs/inode.c Tue Mar 6 23:05:50 2001
@@ -161,17 +161,15 @@
struct smb_fattr fattr;
error = smb_proc_getattr(dentry, &fattr);
- if (!error)
- {
+ if (!error) {
smb_renew_times(dentry);
/*
* Check whether the type part of the mode changed,
* and don't update the attributes if it did.
*/
- if ((inode->i_mode & S_IFMT) == (fattr.f_mode & S_IFMT))
+ if ((inode->i_mode & S_IFMT) == (fattr.f_mode & S_IFMT)) {
smb_set_inode_attr(inode, &fattr);
- else
- {
+ } else {
/*
* Big trouble! The inode has become a new object,
* so any operations attempted on it are invalid.
@@ -212,18 +210,11 @@
struct smb_sb_info *s = server_from_dentry(dentry);
struct inode *inode = dentry->d_inode;
time_t last_time;
+ loff_t last_sz;
int error = 0;
DEBUG1("smb_revalidate_inode\n");
- /*
-* If this is a file opened with write permissions,
-* the inode will be up-to-date.
-*/
lock_kernel();
- if (S_ISREG(inode->i_mode) && smb_is_open(inode)) {
- if (inode->u.smbfs_i.access != SMB_O_RDONLY)
- goto out;
- }
/*
* Check whether we've recently refreshed the inode.
@@ -236,11 +227,13 @@
/*
* Save the last modified time, then refresh the inode.
-* (Note: a size change should have a different mtime.)
+* (Note: a size change should have a different mtime,
+* or same mtime but different size.)
*/
last_time
d_add on negative dentry?
Is it valid to call d_add on a negative dentry?
(or on a dentry that is already linked in d_hash, but all negative
dentries are, right?)
I'm guessing it isn't because I think that is how I can get my machine to
hang in d_lookup, looping on a corrupt d_hash list.
The problem can be reproduced like this. /mnt/smb is a smbfs mount of
/mnt/samba/export from a samba server on localhost.
/mnt/smb% ls
aa
/mnt/smb% rm aa
/mnt/smb% touch /mnt/samba/export/aa
/mnt/smb% ls
ls: aa: No such file or directory
And shortly after it will lock up completely.
My printk's tell me that a negative dentry is still hashed since d_hash is
non-empty. d_add calls d_instantiate and d_rehash, the later adds it to a
d_hash list without first removing it. But it was already linked so now 2
extra dentries are also pointing to this dentry. And it is then no longer
a list ...
The attached patch fixes things for me. Comments?
Oh, and I *think* ncpfs has the same problem. But that's just from reading
the code.
/Urban
diff -urN -X exclude linux-2.4.2-ac11-orig/fs/smbfs/cache.c
linux-2.4.2-ac11-smbfs/fs/smbfs/cache.c
--- linux-2.4.2-ac11-orig/fs/smbfs/cache.c Thu Feb 22 20:52:03 2001
+++ linux-2.4.2-ac11-smbfs/fs/smbfs/cache.c Mon Mar 5 23:48:12 2001
@@ -167,6 +167,7 @@
struct inode *newino, *inode = dentry->d_inode;
struct smb_cache_control ctl = *ctrl;
int valid = 0;
+ int hashed = 0;
ino_t ino = 0;
qname->hash = full_name_hash(qname->name, qname->len);
@@ -181,9 +182,11 @@
newdent = d_alloc(dentry, qname);
if (!newdent)
goto end_advance;
- } else
+ } else {
+ hashed = 1;
memcpy((char *) newdent->d_name.name, qname->name,
newdent->d_name.len);
+ }
if (!newdent->d_inode) {
smb_renew_times(newdent);
@@ -191,7 +194,10 @@
newino = smb_iget(inode->i_sb, entry);
if (newino) {
smb_new_dentry(newdent);
- d_add(newdent, newino);
+ if (hashed)
+ d_instantiate(newdent, newino);
+ else
+ d_add(newdent, newino);
}
} else
smb_set_inode_attr(newdent->d_inode, entry);
Re: Via-rhine is not finding its interrupts under 2.2.19pre14
On Tue, 27 Feb 2001, Michal Jaegermann wrote: > > After I booted 2.2.19pre14 on a system with two via-rhine cards I see the > following: > > via-rhine.c:v1.08b-LK1.0.0 12/14/2000 Written by Donald Becker > http://www.scyld.com/network/via-rhine.html > eth0: VIA VT3043 Rhine at 0x9400, 00:50:ba:c1:64:d9, IRQ 0. > eth0: MII PHY found at address 8, status 0x7809 advertising 05e1 Link . > eth1: VIA VT3043 Rhine at 0x8800, 00:50:ba:ab:60:64, IRQ 0. > eth1: MII PHY found at address 8, status 0x782d advertising 05e1 Link . > > and a network does not work due to these IRQ 0, I guess. I assume this worked in 2.2.18 or some earlier 2.2.x? Hmm, I'll have to test 2.2.19pre14 (16?) myself tonight. It did work for me in earlier 2.2.19pre versions, and the code is "identical" to other drivers here. This page suggests possible bios problems. http://www.scyld.com/expert/irq-conflict.html You could also try Donalds original via-rhine module. The largest difference between that and the one in the kernel is how it does pci probing. http://www.scyld.com/network/ethercard.html /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Building autofs
On Wed, 28 Feb 2001, Rainer Mager wrote: > Hi all, > > I'm trying to use autofs for the first time and am running into some > problems. First, the documentation seems quite weak, that is, I'm not sure I am sure the maintainer would appreciate if you wrote down what you found difficult/missing from the docs (in the form of a patch to the existing docs perhaps). > if what I have is what I should have. I managed to find an autofs version 4 > pre 9 tarball on the kernel mirrors. This seem the latest but is still a bit > old and the referenced home page doesn't seem any newer. My real problem, > however, is that when I try to build it I get this error: > > lookup_program.c:147: `OPEN_MAX' undeclared (first use in this function) #include gives: #define OPEN_MAX 256/* # open files a process may have */ But autofs is well behaved and doesn't use kernel headers but that makes it fails on newer glibcs (at least I think that was it). Just define it. If autofs4 is doing the same as autofs3 then it is only used for program lookups (where a program generates the map to use) and unless you are going to use those it won't matter at all. There is also some info here, including how to find the autofs mailinglist. http://www.linux-consulting.com/Amd_AutoFS/autofs.html Or google for "autofs OPEN_MAX", "autofs mailinglist archive", ... There appears to be a autofs-open_max.patch somewhere. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH] via-rhine.c: don't reference skb after passing it tonetif_rx
On Mon, 26 Feb 2001, Arnaldo Carvalho de Melo wrote: > thanks, I'll take that into account for the remaining ones and this should > be checked by the driver authors for the ones I've already sent. The pkt_len variant is already in 2.4.1-ac15 and probably before that (changed by Manfred Spraul back in ac4?). Perhaps you should run through the drivers in -acX instead/also? (too late now I guess :) /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] smbfs does not support LFS (2.4.1-ac18)
Hello Unless I misunderstand s_maxbytes it says how large a file can be on the fs. I assume it is enough for a fs to set that and then it knows the vfs will not ask it to go beyond that limit? Is it ok to at mount time set it to non-LFS and then later change it to be something larger? smbfs doesn't actually know what the server and smbmount negotiates until later, but no smbfs operation can take place before that anyway. For smbfs the limit is currently 2G, it does unsigned -> signed internally and it lacks support from smbmount. The later makes the server (tested vs NT4sp6) return errors beyond 2G. Quick patch below to keep it within limits. For people needing LFS in smbfs I have a *very* experimental pair of patches here: http://www.hojdpunkten.ac.se/054/samba/index.html (It worked last night, it may still work today. You need to patch both the kernel and samba ./configure) /Urban diff -ur -X exclude linux-2.4.1-ac18-orig/fs/smbfs/inode.c linux-2.4.1-ac18-smbfs/fs/smbfs/inode.c --- linux-2.4.1-ac18-orig/fs/smbfs/inode.c Sun Feb 18 01:20:31 2001 +++ linux-2.4.1-ac18-smbfs/fs/smbfs/inode.c Sun Feb 18 14:06:15 2001 @@ -399,7 +399,7 @@ sb->s_magic = SMB_SUPER_MAGIC; sb->s_flags = 0; sb->s_op = &smb_sops; - sb->s_maxbytes = ~0;/* Server limited not client */ + sb->s_maxbytes = MAX_NON_LFS; /* client support missing */ sb->u.smbfs_sb.mnt = NULL; sb->u.smbfs_sb.sock_file = NULL; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA Rhine on Alpha bug
On Fri, 9 Feb 2001, Kaj-Michael Lang wrote: > I don't know if it should work or not but using a VIA Rhine compatible card > on my LX164 locks it solid when transfering large packets: > ping -f host.on.100mbit.lan works > ping -f -s 1024 same.host locks it solid as does > untarring to a NFS mount. I have seen at least one similar report of nfs/large ping problems with the via-rhine. The other report was x86 so it is probably not alpha specific (if it should work ... that's another thing). Personally I have not seen (or been able to create) anything like this. What kernel version are you running? If you are not using the latest try that first. I would try 2.4.1-ac9 (or 2.2.19preX if you use 2.2, but there is a fix in "ac9" that is not in the 2.2 driver). To help debug this you could try: Enable SysRq if you haven't already (Documentation/sysrq.txt does not mention alpha ...). Run the ping-test on the console (not X). SysRq-P will dump register contents (eip and stacktrace on x86, only pc on alpha?) that can be written down (pc only) and compared with your System.map. It may be possible to guess where the driver is looping (assuming it is) by getting a few register dumps. If it is looping it should repeat itself (with an address that points to the via-rhine driver, decoding the address is easier if the driver is not compiled as a module). Test SysRq-P before doing the ping-test to make sure it works. The driver takes a debug flag, which defaults to 1. If you load the driver as a module set "options via-rhine debug=?" in /etc/modules.conf where ? is some value between 1 and 7. SysRq-8 makes kernel debug messages appear on the console. The output may aid narrowing it down, for example if it prints that it enters the interrupt handler but never exits. And then there is of course the possibility of hardware bugs ... /Urban - 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.4.x and oops on 'mount -t smbfs'
On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote: > I've compiled a number of 2.4.1 and 2.4.0 kernels (actually supports the 4GB > RAM!!! Yay), and I have only one more problem to sort out. Under > 2.4.x, the mount completes successfully, but 'ls /net' causes an OOPS: . Try http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.1-pre10-cache-2.patch Let me know if it works for you or not. (patch should be ok with 2.4.0 or 2.4.1) /Urban - 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: d-link dfe-530 tx (bug-report)
On Mon, 5 Feb 2001, Manfred Spraul wrote: > 6 ms is quite long: > I added a reset into tx_timeout, and that function should not take more > than 1 ms or so. > Did you find something about the delay in the documentation? Is it > possible to poll for reset completion? I don't know how long. For testing I figured it might be nice with a long delay, and I was hoping 6ms is long enough. If it changes anything, then you can start working on getting it right. :) There is a flag that may indicate reset complete (that's why the while loop is there). It is supposed to do that for normal "CmdReset" so maybe it does the same for "forced reset". I have no idea if it does. But the reset doesn't seem to change much anyway. The MII PHY (miffy?) is not responding but there are a few registers to play with there. One clear difference is the PHY address, 8 vs 31 (and 31 has some special meaning for some other register). The new register dumps needs to be examined for any vt6102 specifics that are disabled. /Urban - 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: d-link dfe-530 tx (bug-report)
On Sun, 4 Feb 2001, Manfred Spraul wrote: > > Oh, that's known already. They haven't released any info on the older > > "VT3043" chip either, afaik. And the vt86c100a.pdf document is just a > > preliminary version. > > > Where can I find that file? > I'll try to implement tx_timeout() http://www.via.com.tw/pdf/productinfo/vt86c100a.pdf /Urban - 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: d-link dfe-530 tx (bug-report)
> This sounds every much like it's related to the problems we're having with > the card not initialising on reboot from Windows. It's not the same problem. Here the card initializes just fine. And it works for a while. The "transmit timed out" message is simply saying that we told the card to send something but it hasn't generated an interrupt or anything allowing the driver to know the packet was actually sent. > What's the bets we're looking at a new revision of the chip which VIA > haven't (publically) released documentation for yet? I'd say they're > pretty high... Oh, that's known already. They haven't released any info on the older "VT3043" chip either, afaik. And the vt86c100a.pdf document is just a preliminary version. /Urban - 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: DFE-530TX with no mac address
On Sat, 3 Feb 2001 [EMAIL PROTECTED] wrote: > I noticed that the mac address was stored in the registers and > eprom. I guess it would not be as easy as just writing the mac > back in the blank eprom and registers? What my changed via-diag tries to do is to tell the chip to reload things from the eeprom (note that the diag program doesn't actually list the eeprom contents). You can always try writing all the registers with "good" values. > Is there a reset 'thing' for thses chips, that sets them back to > factory tests (like switching them off)? [snip] > So.How do I go about playing this game? You find the reset "thing". Maybe there is better documentation somewhere. Maybe your bios allows you to reset something on reboots. The pdf document has a few things that you can play with, SRST, INIT, STRT. /Urban - 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: DFE-530TX with no mac address
On Sat, 3 Feb 2001, Jonathan Morton wrote: > Do you want me to try this again, after first setting the card into > non-working condition? Yes, the idea was to start from non-working, test -I and then ifconfig down/up. Getting the working card to work is a much simpler problem :) /Urban - 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: DFE-530TX with no mac address
On Sat, 3 Feb 2001 [EMAIL PROTECTED] wrote:
> VIA VT3065 Rhine-II chip registers at 0xd400
> 0x000: 0804
>
> 0x020: 0400
>
> 0x040:
> feff
> 0x060: 0e09131f 8100
> 0880 0247
> No interrupt sources are pending ().
> Access to the EEPROM has been disabled (0x80).
> Direct reading or writing is not possible.
> EEPROM contents (Assumed from chip registers):
> 0x100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x110: 00 00 00 00 00 00 00 00 09 0e 00 00 47 02 73 73
> ***WARNING***: No MII transceivers found!
This is intresting. Your card reports that it is stopped while the other
report show normal values on most things. Does this change if you try and
send something (like a ping)?
Common to both reports is that the transceivers don't respond.
The functioning card reports a PHY ID of 0016 f880, wonder which chip that
is ... ?
The attached patch for the via-daig program plays with a few registers.
Run it as 'via-diag -aaeemm -I' then do a 'ifconfig eth0 down; ifconfig
eth0 up' and see if anything happens.
If this doesn't work you may want to play "guess the register". A fun
game for all ages, made more fun by using obfuscated english. There is a
datasheet here for a chip similar to the ones you have.
http://www.via.com.tw/pdf/productinfo/vt86c100a.pdf
/Urban
--- via-diag.c.orig Sat Feb 3 10:14:50 2001
+++ via-diag.c Sat Feb 3 13:00:47 2001
@@ -150,6 +150,8 @@
static int get_media_index(const char *name);
/* Chip-specific options, if any, go here. */
+static int try_to_start = 0, try_to_stop = 0;
+
int
main(int argc, char **argv)
@@ -161,7 +163,7 @@
int card_num = 0;
extern char *optarg;
- while ((c = getopt_long(argc, argv, "#:aA:DeEfF:G:mp:qrRst:vVwWH:BL:S:",
+ while ((c = getopt_long(argc, argv, "#:aA:DeEfF:G:mp:qrRst:vVwWH:BL:S:Ii",
longopts, &longind))
!= -1)
switch (c) {
@@ -205,6 +207,8 @@
case 'B': opt_flash_show++; break;
case 'L': opt_flash_loadfile = optarg; break;
case 'S': opt_flash_dumpfile = optarg; break;
+ case 'I': try_to_start = 1; try_to_stop = 0; break;
+ case 'i': try_to_start = 0; try_to_stop = 1; break;
case '?':
errflag++;
}
@@ -559,6 +563,25 @@
"Perhaps it is set to ACPI power-off mode.\n"
"To examine this device anyway use the '-f' flag.\n");
return 1;
+ }
+
+ /* Experiments with getting the card to stop working ... */
+ if (try_to_stop) {
+ /* This doesn't stop my card :( */
+ for (i=0; i<6; i++)
+ outb(0x00, ioaddr + i);
+ outb(0x01, ioaddr + 0x6c);
+
+ /* this stops things, but ifconfig up/down resets properly */
+ outb(0x80, ioaddr + 0x09);
+ }
+ /* ... and then starting it again */
+ if (try_to_start) {
+ /* we know the PHY is 8 */
+ outb(0x08, ioaddr + 0x6c);
+
+ /* tell the chip to reload from EEPROM */
+ outb(0x20, ioaddr + 0x74);
}
/* Always show the basic status. */
Re: DFE-530TX with no mac address
> >I did this and compiled it into the kernel. It detects it at boot (via- > >rhine v1.08-LK1.1.6 8/9/2000 Donald Becker) but says the > >hardware address (mac address?) is 00-00-00-00-00-00. This is a good example of what is missed by not copying the exact message. For example, mine says: eth0: VIA VT3043 Rhine at 0xd400, 00:50:ba:a4:15:86, IRQ 19. eth0: MII PHY found at address 8, status 0x782d advertising 05e1 Link . Does it say "VIA VT6102 Rhine-II" for both of you? If not, could you do an 'lspci -n'? My VT3043 survives win98, but it may be a new feature in the newer chip. It may be a bios setting or something ... > I have an identical card, which usually works - except when I've rebooted > from Windows, when it shows the above symptoms. After using Windows, I > have to power the machine off, including turning off the "standby power" > switch on the PSU, then turn it back on and boot straight into Linux. Very > occasionally it also loses "identity" and requires a similar reset, even > when running Linux. Yes, the card is in some (for the linux driver) unknown state. Powering off completely resets it. Something that could help someone find out what is going on is running these two commands, both when the card is working and when it is not. via-diag -aaeemm lspci -vvvxxx -d 1106:3065 via-diag is available from http://www.scyld.com/diag/index.html (1106:3065 is the pci id, if lspci -n gives you a different number you use that of course.) /Urban - 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] smbfs cache rewrite - 2nd try
Hello again This patch is more complete than the version posted earlier. It implements support for OS/2 (and possibly things even older than that :) and have been more tested. This borrows a lot from the ncpfs dircache code. Smbfs testers wanted, with or without highmem boxes. Bugs (believed) fixed vs 2.4.1-pre10: + cache code would oops/lockup on highmem machines (too many kmap'ed pages and possibly a few other things) + readpage/writepage could oops on highmem machines (missing kmap) + listing long directories would fail on some dirs on some types of servers (from 2.2.18, has nothing to do with the cache code) Improvements: + new cache code creates dentries and inodes from the "findfirst" data, reducing the number of smb requests needed to list a directory (ls -l) from n/x + n to n/x (where x is the number of entries that fit in one request). + new mount option, ttl, allows control over how long the cache is considered valid, default ttl=1000 (1 second). Bugs introduced: - date conversion may need to do timezone conversion in smbfs - 'd; touch dd; d; rm DD; d', where d is an alias for ls -alF, will crash on the rm if the server is "old", tested vs a samba server configured to talk "LANMAN1". Does not crash when using "NT1". Don't know if this is a new or old bug yet. - more? (this is where you come in ...) Download ~57k from: http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.1-pre10-cache-2.patch (Apply using 'patch -p1' from the linux directory.) /Urban - 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: more via-rhine problems.
On Thu, 18 Jan 2001, Mike A. Harris wrote: > I now believe that it is indeed caused by booting to windows 98 > (by accident). ;o) Don't do that then :) > Doesn't matter if a driver is installed in win or not as I've > tried both. Just booting win at all causes the card to go > berzerk next boot. Must be something missing from the card init > code that should be resetting something on the card at init time, > but which is set by default on power on. I can't reproduce this, but I only have a 1106:3043 (DFE-530TX revA1) and tested this on a rather old P133. I tested 2.2.19pre and not 2.2.18+becker1.08, the biggest difference is the detection code so maybe that could be worth trying. 2.4 is again a little bit different ... You could try playing with bios settings. And dumping register contents from a working and non-working setup, for example: % via-diag -aaeemm (ftp://ftp.scyld.com/pub/diag/via-diag.c) % lspci -vvxxx -d 1106:3065 Maybe CONFIG_PCI_QUIRKS helps? /Urban - 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] smbfs cache rewrite for 2.4.1-pre
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: oops in 2.4.1-pre8
On Thu, 18 Jan 2001, Petr Vandrovec wrote:
> > Rainer Mager reported the same thing yesterday ("Oops with 4GB memory
> > setting in 2.4.0 stable" if you want to read the thread).
>
> I think that I found source of problem. I have no simple solution :-(
>
I think the source of the problem is that this code was changed without
anyone being capable of actively maintaining it (time, knowledge,
motivation, ...). And later maintainers (me) haven't known or seen
anything wrong with it.
> But I'm not 100% sure, as this would mean that you do not
> kunmap/UnlockPage/page_cache_release any >1GB page at all in
> smb_free_cache_blocks(), as page pointer obtained by page_cache_entry()
> points to some random page (to couple just below 1GB boundary) instead
> of to correct one, so smbfs should die as soon as it finds first highmem
> page... Is it possible?
It sounds possible from the reports, where it has died as soon as it is
touched on a highmem mmachine.
> So your system has couple of chances to deadlock - either on out of
> kmaps, or on locked directory cache root (cachep), or on some of locked
> directory cache pages (blocks)...
Thanks for looking. I haven't begun to verify any of your previous
suggestions.
Copying the ncpfs cache code seems so much better. It's possibly a bigger
change (currently 20k diff -u) than to fix the cache.c code to do whatever
is right but the end result should be a lot better (I hope). Fixed size
cache entries makes lookups simpler, creating dentry/inode from the info
returned by the findfirst/findnext smb calls avoids extra calls on some
common(?) usage patterns.
Assuming your code is correct, and I'm sure it is, this should be a faster
way to do it than for me to figure out how the existing smbfs cahce can be
made to work. The differences are not that great between ncpfs and smbfs,
both are networked dos-ish filesystems. :)
My new code oopsed on me last night (and then I realized what time it
was). But so far the ncpfs code is fitting quite nicely.
/Urban
-
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: Oops with 4GB memory setting in 2.4.0 stable
On Thu, 18 Jan 2001, Rainer Mager wrote: > Here is a newly parsed oops, this time using the /var/log/ksymoops method > mentioned by Keith Owens. Does this look better? Yes, and it sort of matches the other oops someone sent. Thanks. I have a changed version now, based on the ncpfs directory cahce code. But it doesn't work at all right now. (and that would be the "based on" bit, the copy and paste bits haven't crashed yet :) Assuming that all meetings have an end, and sometimes they don't seem to have one, there may be something for you to try tomorrow. /Urban - 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: oops in 2.4.1-pre8
On Wed, 17 Jan 2001, Scott A. Sibert wrote:
> I'm consistently getting an oops when accessing any smbfs mount whether
> running 'ls' inside the smbfs mount or hitting TAB for filename
> completion of a directory in an smbfs mount. I have another machine
> (dual P2/300 w/320MB memory) that does not have this problem. The P2
That other machine is not compiled with bigmem, I assume.
> Ethernet is compiled into the kernel as is smbfs (not as modules). I've
> compiled this kernel with 4GB bigmem support (otherwise I only get 8xxMB
> total).
The smbfs cache code in 2.4.0 doesn't work with bigmem. For now disable
bigmem or don't use smbfs, it's oopsing all the time.
Rainer Mager reported the same thing yesterday ("Oops with 4GB memory
setting in 2.4.0 stable" if you want to read the thread).
I am currently looking into this ... what kind of server are you
connecting to? win2k/NT4/9x? It is easier to test with those than the more
exotic OS/2 & NetApp.
/Urban
-
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: Killing process with SIGKILL and ncpfs
On Wed, 17 Jan 2001, Petr Vandrovec wrote:
> Hi,
> Maarten de Boer pointed to me, that if you load some simple program,
> such as 'void main(void) {}', trace into main (break main; run)
> and then quit from gdb (Really exit? yes), child process is then
> killed due to INT3 (probably). Then exit_mmap releases executable
> mapping - and ncp_do_request is entered with SIGKILL pending!
smbfs has a signal problem in it's fs/smbfs/sock.c, possibly related.
SIGKILL or SIGSTOP can be already pending, or perhaps received while
waiting in socket->ops->recvmsg(). recvmsg will then return -ERESTARTSYS
because signal_pending() is true and the smbfs code treats that as a
network problem (causing unnecessary reconnects and sometimes complete
failures requiring umount/mount).
I don't know what happens with ncpfs, I don't think you wrote that, but I
am interested in how it handles this. (Again, I have looked at the ncpfs
code for useful bits to copy :)
Running strace on a multithreaded program causes problems for smbfs.
Someone was nice enough to post a small testprogram for this (you may want
to try it on ncpfs, if you want it I'll find it for you).
These problems go away if all signals are blocked. Of course the smbfs
code would need to be changed to not block on recv, else you may end up
with a program waiting for network input that can't be killed ... (?)
/Urban
-
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: eth1: Transmit timed out, status 0000, PHY status 0000
On Tue, 16 Jan 2001, richard.morgan9 wrote: > I have the same problem as Urban with a recent DLink 530tx > (rhine2). Pulling the power cable from my atx psu (while the > computer was "off") fixed the card, until my next reboot from > win98. I'm not the one with a problem but maybe it has something to do with win98 and/or the driver used there. I intend to test this myself eventually and see if I can do something based on Donald Beckers suggestions on eeprom. Unless someone else feels like playing with this ... anyone? Does everyone seeing this have a Rhine-II, pci id 1106:3065, and not the older chip found in dfe530tx with pci id 1106:3043? /Urban - 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: Oops with 4GB memory setting in 2.4.0 stable
On Tue, 16 Jan 2001, Petr Vandrovec wrote: > If there is new dentry, which is at fpos postion, and it is child of > readdir-ed directory, we should return it anyway, no? There must not be > two ncpfs dentries with same d_parent and d_fsdata if d_fsdata != 0, > as each dentry can be in only one directory. > > This looked as reasonable limitation to me ;-) Right. I chose not to read those tests for some reason ... good. The parent test should be ok. d_fsdata is only set in ncpfs if it is put in the cache and d_alloc sets it to 0. Works for me (whatever that may be worth). Rewriting the smbfs cache code allows for a nice speedup too. In ncpfs when reading a directory you create dentries and inodes at once. I assume that when reading the dir list from the server that you get all the info you need in one go. I think smbfs gets all needed info on all protocol versions it supports, so that should be a nice speedup for readdir() + stat()-each file (ls -l). Currently it only caches name info and then does a remote call for each entry. Too bad this is 2.4.0, the biggest problem may be sneaking it past Linus. oh well ... :) /Urban - 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: Oops with 4GB memory setting in 2.4.0 stable
On Tue, 16 Jan 2001, Petr Vandrovec wrote: > smb_get_dircache looks suspicious to me, as it can try to map unlimited > number of pages with kmap. And kmaps are not unlimited resource... > You have 512 kmaps, but one SMBFS cache page can contain about 504 > pages... So two smbfs cached directories can consume all your kmaps, > dying then in endless loop in mm/highmem.c:map_new_virtual(). The smbfs dircache needs to find/kmap all of its cache pages since the entries in it are variable length and the way it is called. It would be nice to change that. I haven't looked at all your detailed comments yet. They may not matter if the many kmaps are a problem. The ncpfs code puts 'struct dentry *' in it's cache pages. Fixed size entries makes it easy to know which page you need to start reading from, so only one kmap is needed. That looks simpler so I want to steal it, except ... ncpfs ends up calling d_validate to verify that the dentry is sane. But how can it know that the dentry is the right one? I thought that dentries could be removed/reused by someone at will (d_count will be 0 because of the dput in ncp_fill_cache, no?). Why isn't it possible for someone to write a new dentry where the old one was. fs/ncpfs/dir.c:ncp_d_validate() calls valid = d_validate(dentry, dentry->d_parent, dentry->d_name.hash, len); all values are taken from the dentry pointer on the cache page (including len). d_validate verifies that d_hash() points to a list and it searches the list for dentry. How do you know that it is the same dentry that was put in the cache and not someone elses dentry? > But I personally do not use neither smbfs nor PAE, so what I can say... A whole lot, thanks. Especially for the kmap info. Now if someone could explain the dentry pointers ... what am I missing? /Urban - 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: Oops with 4GB memory setting in 2.4.0 stable
On Tue, 16 Jan 2001, Rainer Mager wrote: > Hi all, > > I have a 100% reproducable bug in all of the 2.4.0 kernels including the > latest stable one. The issue is that if I compile the kernel to support 4GB > RAM (I have 1 GB) and then try to access a samba mount I get an oops. This I'll have a look tonight or so. It works for you on non-bigmem? > ALWAYS happens. Usually after this the system is frozen (although the magic > SYSREQ still works). If the system isn't frozen then any commands that > access the disk will freeze. Fortunately GPM worked and I was able to paste > the oops to a file via telnet. smb_rename suggests mv, but the process is ls ... er? What commands where you running on smbfs when it crashed? Could this be a symbol mismatch? Keith Owens suggested a less manual way to get module symbol output. Do you get the same results using that? /Urban - 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: eth1: Transmit timed out, status 0000, PHY status 0000
On Sun, 14 Jan 2001, Mike A. Harris wrote: > Becker's latest via-rhine driver ontop 2.2.18.. > > ... > eth1: Transmit timed out, status , PHY status , > resetting... [snip] > Keeps going nonstop until I ifdown eth1. > > Card worked fine 2 days ago... So what did you change? Has the machine been up since then? Someone else with the same symptoms (in 2.4) http://www.uwsg.iu.edu/hypermail/linux/net/0011.0/0027.html Becker's reply http://www.uwsg.iu.edu/hypermail/linux/net/0011.0/0032.html "Try unplugging the system and doing a really cold boot. A soft-off does not reset the chip. If this solves the problem, we will have to add code to re-load the EEPROM info into the chip." There is no further reply in that thread. /Urban - 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.18: Thread problem with smbfs
On Wed, 20 Dec 2000, Hans-Joachim Baader wrote:
> Then run the program. It should copy the files to the current
> directory. Then run it under gdb. It should hang until you kill
> gdb.
Hello again
(Sorry for the long response time but this really is the busiest time of
the year, or maybe it's the food and drink that is slowing me down :)
Anyway,
gdb is doing strange things to your testprogram on ext2 as well. Does it
work for you? I have not been able to reproduce a gdb hang (you do know
that there is a while(1); in main ... ;-), but it generates a lot of smbfs
messages and in one case made smbfs stop working.
Your program modified to take path as argument and print a message on
entry/exit of the copy function. Here run with files on ext2.
GNU gdb 5.0
...
(gdb) run tmp
Starting program: /home/puw/src/smbfs/thread-test tmp
[New Thread 1024 (LWP 2456)]
[New Thread 2049 (LWP 2463)]
[New Thread 1026 (LWP 2464)]
copy() tmp/file1 -> out/file1
copy() -- exit
[New Thread 2051 (LWP 2465)]
Program exited normally.
(gdb) quit
Hmm, strange. Why does it only copy one file? Looking at the last
process gives a sleeping process in rt_sigsuspend, like you
reported in your strace. Am I using gdb incorrectly?
% ps -lw 2465
F S UID PID PPID C PRI NI ADDRSZ WCHAN TTYTIME CMD
040 S 501 2465 1 0 60 0- 1366 rt_sig pts/3 0:00
/home/puw/src/smbfs/thread-test tmp
The patch below vs 2.2.18 should remove the -512 (-ERESTARTSYS) errors.
But I don't like it at all. It blocks all signals, including SIGKILL, for
a while. The problem is that tcp_recvmsg checks if there is a signal (any
signal) and aborts with -ERESTARTSYS (a comment says it only cares about
SIGURG, maybe that could be changed instead).
Could you test if this fixes the gdb problem? And try gdb with all files
on ext2 too. For me there is no difference between that and smbfs vs a
NT4.
/Urban
--- linux-2.2.18-orig/fs/smbfs/sock.c Wed Dec 13 21:27:44 2000
+++ linux/fs/smbfs/sock.c Tue Jan 2 21:19:03 2001
@@ -30,11 +30,13 @@
static int
_recvfrom(struct socket *socket, unsigned char *ubuf, int size,
- unsigned flags)
+ unsigned rflags)
{
struct iovec iov;
struct msghdr msg;
struct scm_cookie scm;
+ sigset_t old_set;
+ unsigned long flags;
msg.msg_name = NULL;
msg.msg_namelen = 0;
@@ -43,11 +45,33 @@
msg.msg_control = NULL;
iov.iov_base = ubuf;
iov.iov_len = size;
-
+
memset(&scm, 0,sizeof(scm));
- size=socket->ops->recvmsg(socket, &msg, size, flags, &scm);
- if(size>=0)
- scm_recv(socket,&msg,&scm,flags);
+
+ /*
+* block all signals to avoid -ERESTARTSYS problem in recvmsg
+*
+* FIXME: changing the signal mask is done elsewhere too.
+* This code removes the ability to SIGKILL a process that has hung in
+* recvmsg (does it? I'm guessing ...).
+* Use poll/timeout to ensure progress?
+*/
+ spin_lock_irqsave(¤t->sigmask_lock, flags);
+ old_set = current->blocked;
+ siginitsetinv(¤t->blocked, 0);
+ recalc_sigpending(current);
+ spin_unlock_irqrestore(¤t->sigmask_lock, flags);
+
+ size = socket->ops->recvmsg(socket, &msg, size, rflags, &scm);
+ if (size >= 0)
+ scm_recv(socket, &msg, &scm, rflags);
+
+ /* restore old signal mask */
+ spin_lock_irqsave(¤t->sigmask_lock, flags);
+ current->blocked = old_set;
+ recalc_sigpending(current);
+ spin_unlock_irqrestore(¤t->sigmask_lock, flags);
+
return size;
}
@@ -529,7 +553,7 @@
buf_len = server->packet_size;
buf_len = smb_round_length(buf_len);
if (buf_len > SMB_MAX_PACKET_SIZE)
- goto out_no_mem;
+ goto out_too_long;
rcv_buf = smb_vmalloc(buf_len);
if (!rcv_buf)
-
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.18: Thread problem with smbfs
On Tue, 19 Dec 2000, Hans-Joachim Baader wrote: > and so on, endlessly. So, AFAIK, smbfs thinks it has lost connection and > tells smbmount to re-establish it, which succeeds (at least smbmount > thinks so). This happens several times per second. -512 means that the recv was interrupted by a signal, or rather, the current process has a signal maybe the recv was interrupted, maybe there is a problem with the connection, better reconnect. Still, it's better than pre-2.2.18 where smbmount wouldn't stay alive ... I don't really know how signal delivery works within the kernel, but smb_trans2_request tries to disable some signals. That does not work (completely?) so either it needs fixing or the -512 errno needs to be handled. Why so bad in gdb? perhaps it causes more signals. Why does one thread end up in D state? don't know. > Kernel 2.2.18, smbfs as a module. I can provide more info if necessary. A small testprogram that causes this would be nice. The -512 is easy to reproduce but I haven't seen the 'D' before. If someone is interested the relevant code is fs/smbfs/sock.c (smb_trans2_request, ..., _recvfrom) /Urban - 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: D-LINK DFE-530-TX [patch]
On Wed, 13 Dec 2000, Alan Cox wrote: > > > > Becker's site http://www.scyld.com/network. > > > 2.4.x-test has some fixes for via-rhine which don't appear to have made > > > it into the Becker driver yet... > > > > Is either of these likely to make it into the stock 2.2 via-rhine? > > If someone ports them over for an earlyish 2.2.19pre Your wish ... Below a patch that updates the 2.2 via-rhine driver from Becker's 1.08b, except for the pci probing that is unchanged, compatibility macros and dead code that are not needed in 2.2 removed (removing ifdef CARDBUS is from 1.08b) and "clear_tally_counters" from 2.4. It would be nice if people using 2.2 and one of these cards could test this too. Patch includes: + new VT6102 pci id & supporting non-aligned data buffers for that chip + completely untested (by me, that is) big<->little endian stuff + free allocated memory on driver unload + no more writel to 0x7c. + 2 16bit values accessed as one 32bit (why? not sure, pci optimization?) + change transmit ring size and some other more or less minor changes/cleanups. This is mostly a copy&paste operation. If you'd rather get a smaller change for just supporting the VT6102 that is easy to do. However, this is very similar to the 2.4 driver (locking is a major diff) so I hope it is ok. Also, if I don't include most of the 1.08b driver I'm not sure what version name to give it ... :) /Urban diff -ur -X exclude linux-2.2.18-orig/drivers/net/via-rhine.c linux/drivers/net/via-rhine.c --- linux-2.2.18-orig/drivers/net/via-rhine.c Wed Dec 13 21:27:37 2000 +++ linux/drivers/net/via-rhine.c Fri Dec 15 00:03:59 2000 @@ -1,35 +1,44 @@ /* via-rhine.c: A Linux Ethernet device driver for VIA Rhine family chips. */ /* - Written 1998-1999 by Donald Becker. + Written 1998-2000 by Donald Becker. - This software may be used and distributed according to the terms - of the GNU Public License (GPL), incorporated herein by reference. - Drivers derived from this code also fall under the GPL and must retain - this authorship and copyright notice. + This software may be used and distributed according to the terms of + the GNU General Public License (GPL), incorporated herein by reference. + Drivers based on or derived from this code fall under the GPL and must + retain the authorship, copyright and license notice. This file is not + a complete program and may only be used when the entire operating + system is licensed under the GPL. This driver is designed for the VIA VT86c100A Rhine-II PCI Fast Ethernet controller. It also works with the older 3043 Rhine-I chip. - The author may be reached as [EMAIL PROTECTED], or - Donald Becker - 312 Severn Ave. #W302 + The author may be reached as [EMAIL PROTECTED], or C/O + Scyld Computing Corporation + 410 Severn Ave., Suite 210 Annapolis MD 21403 Support and updates available at - http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html + http://www.scyld.com/network/via-rhine.html + + + Linux kernel version history: + + LK1.0.0: + - Urban Widmark: merges from Beckers 1.08b version and 2.4.0 (VT6102) */ -static const char *versionA = -"via-rhine.c:v1.01 2/27/99 Written by Donald Becker\n"; -static const char *versionB = -" http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html\n"; +/* These identify the driver base version and may not be removed. */ +static const char version1[] = +"via-rhine.c:v1.08b-LK1.0.0 12/14/2000 Written by Donald Becker\n"; +static const char version2[] = +" http://www.scyld.com/network/via-rhine.html\n"; -/* A few user-configurable values. These may be modified when a driver - module is loaded.*/ +/* The user-configurable values. + These may be modified when a driver module is loaded.*/ static int debug = 1; /* 1 normal messages, 0 quiet .. 7 verbose. */ static int max_interrupt_work = 20; -static int min_pci_latency = 64; +static int min_pci_latency = 32; /* Set the copy breakpoint for the copy-only-tiny-frames scheme. Setting to > 1518 effectively disables this feature. */ @@ -55,7 +64,8 @@ Making the Tx ring too large decreases the effectiveness of channel bonding and packet priority. There are no ill effects from too-large receive rings. */ -#define TX_RING_SIZE 8 +#define TX_RING_SIZE 16 +#define TX_QUEUE_LEN 10 /* Limit ring entries actually used. */ #define RX_RING_SIZE 16 /* Operational parameters that usually are not changed. */ @@ -64,9 +74,15 @@ #define PKT_BUF_SZ 1536/* Size of each temporary Rx buffer.*/ + +#if !defined(__OPTIMIZE__) +#warning You must compile this file with the correct options! +#warn
Re: [PATCH] Bug in date converting functions DOS<=>UNIX in FAT,NCPFS and SMBFS drivers [second attempt]
On Wed, 13 Dec 2000, Igor Yu. Zhbanov wrote: > I think your testprogram is broken (or else my testprogram is broken :). Yes, you were right. Mine must have been broken (possibly caused by trying to make it readable :). Thanks. Alan, if you still have the patch please apply it to smbfs in 2.2 (and possibly fat too, I assume it is the same). If you don't I'll send it again for 2.2.19pre2 or so. /Urban - 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: test12-pre8
On Sun, 10 Dec 2000, Mohammad A. Haque wrote: > Could someome who knows what they are doing check over the following > patch please? I wouldn't say that I do, but no one else seems to be answering this. list_add_tail does head->prev and making the call with a NULL 'head' looks bad to me. I would prefer: diff -ur -X exclude linux-2.4.0-test12-pre8-orig/fs/smbfs/sock.c linux-2.4.0-test12-pre8-smbfs/fs/smbfs/sock.c --- linux-2.4.0-test12-pre8-orig/fs/smbfs/sock.cSun Dec 10 21:01:16 2000 +++ linux-2.4.0-test12-pre8-smbfs/fs/smbfs/sock.c Sun Dec 10 23:07:15 2000 @@ -163,7 +163,7 @@ found_data(sk); return; } - job->cb.next = NULL; + INIT_LIST_HEAD(&job->cb.list); job->cb.sync = 0; job->cb.routine = smb_data_callback; job->cb.data = job; or just leaving the list as it is. It will be initialized anyway by schedule_task (queue_task), but using the init macro seems like a nice thing to do. /Urban - 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: smbfs writepage & struct file
On Tue, 5 Dec 2000, Linus Torvalds wrote:
> In comparison to these dentry host problems, your patch looks fine. But I
> suspect that you _can_ trigger the BUG() with an empty dentry list due to
> dentry shrinking. So what I did is basically to (a) apply your patch and
> (b) set writepage to NULL in the address space operations, so that shared
> mappings will be disabled for the time being.
A simple fix for this seems to be just not looking at the dentry. Turns
out it is only used to find the inode anyway ...
(and for a debug printout of the filename)
Replaced smb_invent_inos with iunique.
Changed the smb_proc_read to use an inode argument too, for symmetry with
smb_proc_write. smb_readpage_sync needs the dentry since it calls smb_open
(what a strange thing to do ... see below) and needs to find the pathname.
smb_file_open doesn't actually open anything on the remote end. So for
mmap you can open, mmap, write to mem, msync and writepage gets called on
a file the server doesn't consider opened. It will work the first time
since readpage opens the file, but not the second if the page cache
already has the page.
writepage enabled again, although I think there are problems with
reconnections (a file you had open is no longer open after reconnect).
Below a patch for this vs 2.4.0-test12-pre7.
If the aliasing of inodes&pages only affects efficiency of caching in
smbfs I think that may be acceptable. With nothing good to use for ino's I
don't see any simple inexpensive way to map filenames to inodes which
would be necessary to avoid aliases.
(Any smbfs-inode with pages could be placed on a list/hash with the
pathname attached. Lookup would search that list to avoid creating
aliases. Or something clever. Abusing the dcache so that dentries for
smbfs are not dropped while the inode is in use? If that is even
possible.)
Or is it possible to loose data because of aliased pages? even if the
application(s) do proper locking/msync/... Is it possible to get two pages
of the same file but the two pages in the page cache disagree on the
contents, and both can be written to the fs?
/Urban
diff -ur -X exclude linux-2.4.0-test12-pre7-orig/fs/smbfs/dir.c
linux-2.4.0-test12-pre7-smbfs/fs/smbfs/dir.c
--- linux-2.4.0-test12-pre7-orig/fs/smbfs/dir.c Mon Aug 14 22:31:10 2000
+++ linux-2.4.0-test12-pre7-smbfs/fs/smbfs/dir.cThu Dec 7 22:11:09 2000
@@ -124,7 +124,7 @@
qname.len = entry->len;
entry->ino = find_inode_number(dentry, &qname);
if (!entry->ino)
- entry->ino = smb_invent_inos(1);
+ entry->ino = iunique(dentry->d_sb, 2);
}
if (filldir(dirent, entry->name, entry->len,
@@ -325,7 +325,7 @@
goto add_entry;
if (!error) {
error = -EACCES;
- finfo.f_ino = smb_invent_inos(1);
+ finfo.f_ino = iunique(dentry->d_sb, 2);
inode = smb_iget(dir->i_sb, &finfo);
if (inode) {
add_entry:
@@ -362,7 +362,7 @@
goto out_close;
smb_renew_times(dentry);
- fattr.f_ino = smb_invent_inos(1);
+ fattr.f_ino = iunique(dentry->d_sb, 2);
inode = smb_iget(dentry->d_sb, &fattr);
if (!inode)
goto out_no_inode;
diff -ur -X exclude linux-2.4.0-test12-pre7-orig/fs/smbfs/file.c
linux-2.4.0-test12-pre7-smbfs/fs/smbfs/file.c
--- linux-2.4.0-test12-pre7-orig/fs/smbfs/file.cThu Dec 7 20:29:38 2000
+++ linux-2.4.0-test12-pre7-smbfs/fs/smbfs/file.c Sun Dec 10 14:21:32 2000
@@ -48,8 +48,7 @@
DENTRY_PATH(dentry), count, offset, rsize);
result = smb_open(dentry, SMB_O_RDONLY);
- if (result < 0)
- {
+ if (result < 0) {
PARANOIA("%s/%s open failed, error=%d\n",
DENTRY_PATH(dentry), result);
goto io_error;
@@ -59,7 +58,7 @@
if (count < rsize)
rsize = count;
- result = smb_proc_read(dentry, offset, rsize, buffer);
+ result = smb_proc_read(dentry->d_inode, offset, rsize, buffer);
if (result < 0)
goto io_error;
@@ -103,25 +102,27 @@
* Offset is the data offset within the page.
*/
static int
-smb_writepage_sync(struct dentry *dentry, struct page *page,
+smb_writepage_sync(struct inode *inode, struct page *page,
unsigned long offset, unsigned int count)
{
- struct inode *inode = dentry->d_inode;
u8 *buffer = page_address(page) + offset;
- int wsize = smb_get_wsize(server_from_dentry(dentry));
+ int wsize = smb_get_wsize(server_from_inode(inode));
int result, written = 0;
offset += page->index << PAGE_CACHE_SHIFT;
- VERBOSE("file %s/%s, count=%d@%ld, wsize=%d\n",
- DENTRY_PATH(dentry), count, offset, wsiz
Re: [PATCH] Bug in date converting functions DOS<=>UNIX in FAT,NCPFS and SMBFS drivers [second attempt]
On Tue, 5 Dec 2000, Igor Yu. Zhbanov wrote: > Hello! Hello again > As I see now in 2.2.18pre24 NCPFS is fixed but VFAT and SMBFS doesn't. (This > happened because the maintainer of NCPFS resent my patch to Alan Cox but only the > part of patch related to NCPFS). So I resent you patch for VFAT and SMBFS attached > to this letter. Yes. Did you get my letter with questions on day-1? I'll repeat: As I see it you can end up one day before 1980-01-01 if the input is all 0 since days are also numbered from 1. Does that need to be fixed too or is it not a problem? /Urban - 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: Bug in date converting functions DOS<=>UNIX in FAT, NCPFS andSMBFS drivers
On Fri, 24 Nov 2000, Igor Yu. Zhbanov wrote: > Hello! Hello, sorry for the slow response. > I have found a bug in drivers of file systems which use a DOS-like format > of date (16 bit: years since 1980 - 7 bits, month - 4 bits, day - 5 bits). [snip] > 2) VFAT for example have three kinds of dates: creation date, modification date >and access date. Sometimes one of these dates is set to zero (which indicates >that this date is not set). Zero is not a valid date (e.g. months are >numbered from one, not from zero) and can't be properly converted to >UNIX-like format of date (it was converted to date before 1980). Days are also numbered from one (at least smbfs) and this change doesn't do anything about that. An all zero date gives 315446400 (or else my testprogram is broken) and you wanted it to give 315532800 (?). So that should be fixed too, I think. It would be nice if someone would rewrite these shift-and-mask orgies into something with a bit more structure (bitfields? hmm, endianess problems? undefined compiler behaviour? I don't know ... macros?). I'm having trouble following these, but maybe that's just me. /Urban - 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
On Tue, 21 Nov 2000, Peter Samuelson wrote:
[someone wrote, and I am keeping it :) ]
> > > > void foo (void)
> > > > {
> > > > if (0)
> > > > printk(KERN_INFO "bar");
> > > > }
> > > >
[snip]
> Jakub Jelinek claims to have fixed this particular bug in the last week
> or so, although I have not downloaded and compiled recent CVS to verify
> this. (Didn't someone at some point have a cgi frontend to
> CVS-snapshot 'gcc -S'? I can't find it now.)
It is linked from the "Reporting bugs" page on the gcc site.
http://www.codesourcery.com/gcc-compile.shtml
And as far as I can tell the assembly output of compiling "foo" does not
contain the "bar" string (without using any -O at all ...)
GCC: (GNU) 2.97 20001121 (experimental)
/Urban
-
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] fixes for smbfs readdir in 2.2.18-pre18
Hello
The old problem with smbfs and listing directories continue. The change of
infolevel that was thought to fix things in 2.2.14 didn't fix everything.
Here is a patch for another thing smbfs doesn't really do right,
apparently.
There is a mismatch between the negotiated maximum transfer size and the
number of bytes smbfs tells the server it may return. This patch changes
it from using 2 completely magic values to use other magic values based on
the negotiated size.
There are mixed reports on this for some servers (OS/2 & NetApp), no luck
for AS/400 (but they send unicode stuff even when not negotiated). But it
fixes problems vs the much more common NT4 (and win2k?) servers.
I'd love to see this in 2.2.18-pre19.
/Urban
diff -ur -X exclude linux-2.2.18-pre18-orig/fs/smbfs/ChangeLog
linux-2.2.18-pre18-smbfs/fs/smbfs/ChangeLog
--- linux-2.2.18-pre18-orig/fs/smbfs/ChangeLog Sat Nov 4 11:38:56 2000
+++ linux-2.2.18-pre18-smbfs/fs/smbfs/ChangeLog Sat Nov 4 11:59:11 2000
@@ -1,5 +1,11 @@
ChangeLog for smbfs.
+2000-11-04 Urban Widmark <[EMAIL PROTECTED]>
+
+ * proc.c, sock.c: adjust max parameters & max data to follow max_xmit
+ lots of servers were having find_next trouble with this.
+ * proc.c: use documented write method of truncating (NetApp fix)
+
2000-09-01 Urban Widmark <[EMAIL PROTECTED]>
* proc.c: add back lanman2 support (OS/2 and others)
diff -ur -X exclude linux-2.2.18-pre18-orig/fs/smbfs/proc.c
linux-2.2.18-pre18-smbfs/fs/smbfs/proc.c
--- linux-2.2.18-pre18-orig/fs/smbfs/proc.c Sat Nov 4 11:38:56 2000
+++ linux-2.2.18-pre18-smbfs/fs/smbfs/proc.cSat Nov 4 12:07:58 2000
@@ -385,22 +385,16 @@
}
/*
- * Returns the maximum read or write size for the current packet size
- * and max_xmit value.
+ * Returns the maximum read or write size for the "payload". Making all of the
+ * packet fit within the negotiated max_xmit size.
+ *
* N.B. Since this value is usually computed before locking the server,
* the server's packet size must never be decreased!
*/
-static int
+static inline int
smb_get_xmitsize(struct smb_sb_info *server, int overhead)
{
- int size = server->packet_size;
-
- /*
-* Start with the smaller of packet size and max_xmit ...
-*/
- if (size > server->opt.max_xmit)
- size = server->opt.max_xmit;
- return size - overhead;
+ return server->opt.max_xmit - overhead;
}
/*
@@ -751,6 +745,23 @@
server->opt.protocol, server->opt.max_xmit, server->conn_pid,
server->opt.capabilities);
+ /* Make sure we can fit a message of the negotiated size in our
+ packet buffer. */
+ if (server->opt.max_xmit > server->packet_size) {
+ int len = smb_round_length(server->opt.max_xmit);
+ char *buf = smb_vmalloc(len);
+ if (buf) {
+ server->packet = buf;
+ server->packet_size = len;
+ } else {
+ /* else continue with the too small buffer? */
+ PARANOIA("Failed to allocate new packet buffer: "
+"max_xmit=%d, packet_size=%d\n",
+server->opt.max_xmit, server->packet_size);
+ server->opt.max_xmit = server->packet_size;
+ }
+ }
+
out:
#ifdef SMB_RETRY_INTR
wake_up_interruptible(&server->wait);
@@ -1348,17 +1359,16 @@
smb_lock_server(server);
retry:
- p = smb_setup_header(server, SMBwrite, 5, 0);
+ p = smb_setup_header(server, SMBwrite, 5, 3);
WSET(server->packet, smb_vwv0, fid);
WSET(server->packet, smb_vwv1, 0);
DSET(server->packet, smb_vwv2, length);
WSET(server->packet, smb_vwv4, 0);
- *p++ = 4;
- *p++ = 0;
- smb_setup_bcc(server, p);
- if ((result = smb_request_ok(server, SMBwrite, 1, 0)) < 0)
- {
+ *p++ = 1;
+ WSET(p, 0, 0);
+
+ if ((result = smb_request_ok(server, SMBwrite, 1, 0)) < 0) {
if (smb_retry(server))
goto retry;
goto out;
@@ -1487,8 +1497,8 @@
smb_proc_readdir_long(struct smb_sb_info *server, struct dentry *dir, int fpos,
void *cachep)
{
- unsigned char *p;
- char *mask, *lastname, *param = server->temp_buf;
+ unsigned char *p, *lastname;
+ char *mask, *param = server->temp_buf;
__u16 command;
int first, entries, entries_seen;
@@ -1521,7 +1531,7 @@
* Encode the initial path
*/
mask = param + 12;
- mask_len = smb_encode_path(server, mask, dir, &star);
+ mask_len = smb_encode_path(server, mask, dir, &star) - 1;
if (mask_len < 0)
Re: kernel newby help.... What's causing my Oops
On Fri, 27 Oct 2000, David Won wrote: > Oct 22 22:37:20 phlegmish kernel: Process esd (pid: 2356, stackpage=c1715000) [snip] > Oct 22 22:37:20 phlegmish kernel: Call Trace: > [smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-220073/96] > [smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-237584/96] > [smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-245443/96] > [__fput+35/144] [_fput+17/64] [fput+18/24] [filp_close+82/92] It certainly has smbfs printed all over it. But I don't know how to decode the call trace ... "sm+-220073" ? Could you describe what it is you are doing when this happens? Are you perhaps playing sound from a mounted smbfs? (esd) Could you test if this is or isn't related to smbfs? (ie don't mount any smbfs stuff and do the same things you normally do) For reproducing oopses it is nice to use a separate system, either a second installation on the same machine (with none of the normal partitions mounted) or a second machine. You could also try 2.4.0-test10-pre6 which is the latest (but if it is smbfs related it should not make any difference). The second oops I don't know anything about except that it may have been triggered by the first oops. /Urban - 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] fs/nls/Config.in
On Thu, 19 Oct 2000, Tom Rini wrote: > Hello all. The attached patch changes the behavoir of fs/nls/Config.in from: > CONFIG_SMB_FS != n to CONFIG_INET = y && CONFIG_SMB_FS != n. This is neeed > because if CONFIG_INET isn't set, CONFIG_SMB_FS isn't asked about and > therefor isn't set at all, so CONFIG_NLS is set to y. My only question about > this patch is if it shouldn't have depended on CONFIG_SMB_NLS_DEFAULT to start > with? (Maintainer CC'ed). It was supposed to be ok to not have a default nls value set but still be able to activate nls if you want to. Giving it the old no-nls behaviour until you say otherwise. Missing support from smbmount is the main reason for having the default. One solution might be to change the smbfs config to look more like the ncpfs config and force a 'n' value if CONFIG_INET isn't 'y'. Patch for this below, but the second patch you sent looks fine too. You didn't say which kernel version you are using ... You could also try the cml2 config tool. The cml2 config language is much better at handling unset values and the current version has no problems with this (n is the same as undefined, as I understand it). http://www.tuxedo.org/~esr/kbuild (if you test it, kernel-rules.cml may need a search&replace of INTEGRATOR with ARCH_INTEGRATOR) /Urban --- linux-2.4.0-test10-pre4-orig/fs/Config.in Thu Oct 19 21:36:16 2000 +++ linux-2.4.0-test10-pre4-smbfs/fs/Config.in Thu Oct 19 21:44:42 2000 @@ -98,12 +98,17 @@ define_bool CONFIG_LOCKD_V4 y fi - dep_tristate 'SMB file system support (to mount Windows shares etc.)' CONFIG_SMB_FS $CONFIG_INET - if [ "$CONFIG_SMB_FS" != "n" ]; then - bool ' Use a default NLS' CONFIG_SMB_NLS_DEFAULT - if [ "$CONFIG_SMB_NLS_DEFAULT" = "y" ]; then - string ' Default Remote NLS Option' CONFIG_SMB_NLS_REMOTE "cp437" + if [ "$CONFIG_INET" != "n" ]; then + tristate 'SMB file system support (to mount Windows shares etc.)' CONFIG_SMB_FS + if [ "$CONFIG_SMB_FS" != "n" ]; then + bool ' Use a default NLS' CONFIG_SMB_NLS_DEFAULT + if [ "$CONFIG_SMB_NLS_DEFAULT" = "y" ]; then +string ' Default Remote NLS Option' CONFIG_SMB_NLS_REMOTE "cp437" + fi fi + else + # for fs/nls/Config.in + define_bool CONFIG_SMB_FS n fi if [ "$CONFIG_IPX" != "n" -o "$CONFIG_INET" != "n" ]; then tristate 'NCP file system support (to mount NetWare volumes)' CONFIG_NCP_FS - 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: smbfs.o error
On Wed, 4 Oct 2000, Aleksey Cheusov wrote: > 1. error in smbfs.o > > 2. I've SMBMOUNTed NT shared directory //server/sharename. NT4 Service pack ? > SMBMOUNT returns 0 and I see the most of nested directories in > //server/sharename, but >when I "CD" to directory "NTRS" smbfs.o write the following messages > in log file and don't show subdirectories. Could you send me an archive of some sort (zip, tgz) of the files in that directory or, if the files are secret or large or something, a list of the filenames. Preferrably as an archive of empty files. Previous directory listing problems have all been related to what filenames are put in the same dir and I would like to try and reproduce this. Bouns points if you can test that the files in the archive generates problems when moved to a different NT box or to a different directory. > 7.5 > smbmount version is 2.0.7 Thanks for a very complete report. I am looking into a few other reports on dir listings that doesn't always work on various kernel version vs NT4, OS/2, and NetApps. If you feel like looking at the problem, it is almost certainly related to fs/smbfs/proc.c and the smb_proc_readdir_long function. That function was changed for 2.2.14 to fix a dir listing problem with identical error messages as you get. It was changed again for 2.2.16 to remove some code that was believed to be broken, causing lots of complaints from people depending on that code. So it was added back for 2.2.17 or early 2.2.18pre (I forget). Testing these versions might show something. Also, smbclient does something very similar to smbfs, so testing smbclient in 2.0.7 and perhaps some earlier version might help. /Urban - 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 panic: Unable to handle kernel paging request
On Sun, 1 Oct 2000, Niccolo Rigacci wrote: > I have a Debian GNU/Linux 2.2 (kernel 2.2.17) installed on a > Cyrix 6x86, sometimes it panics. As far I can detect the panics > occur when there is much disk activity (updatedb and > checksecurity are in progress). I was able to get the log of the > panic via the serial console. Do you have smbfs mounted when find/updatedb is running? 2.2.18pre fixes an old bug where smbfs didn't check the length of the path it was building vs the buffer used to store the path. Depending on what you have mounted this can cause all sorts of fun things to happen. If you had not used smbfs since booting then that is not it, and then I know nothing about it. /Urban - 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.18pre10: A few warnings less...
On Tue, 26 Sep 2000, Horst von Brand wrote: > - The whole nls stuff is a bunch of tables plus a few functions and > structures that look like boilerplate code to my (untrained) eye. I'd > rewrite the whole lot as the tables plus an #included file that gives the > rest, to reduce the possibility of code skew. They all seem to have a > (minor) bug in that their users (e.g, fs/vfat/namei.c:679)pass a const char > pointer to ->char2uni() (one of the functions replicated in each nls > module) which is declared to take a plain char pointer. This function > doesn't modify anything, so const char pointer is really right. But to > change them all is a mess... I'd prefer to do it as explained earlier. > Comments? The code in 2.4 also repeats the same code between nls tables. Most of them have identical functions, the exceptions are cp932, 936, 949, 950 and possibly some other file. So please change 2.4 too if you do this. And please change it. Changing them all only requires a perl/sed/something script, modifying them to use an #include requires comparing and deciding which to move to an #include. Mechanical work vs a few seconds of thought :) I did think about the duplicated code when I looked at nls in 2.4, but I was trying to reuse the uni2char and char2uni in nls_base (which is never a module) and reuse that (on a binary level) in all modules that could. It didn't work out immediately so I dropped the idea. /Urban - 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: NLS handling in Filesystem code
On Mon, 11 Sep 2000 [EMAIL PROTECTED] wrote:
> ISOFS ignores CONFIG_NLS_DEFAULT, and hardcodes the use of iso8859-1 as
> the default. Is this the correct behaviour?
I don't think so. 2.2 uses CONFIG_NLS_DEFAULT for 'iocharset'. Untested,
obvious patch for 2.4.0-test8 below to do the same as 2.2.
/Urban
--- linux-2.4.0-test8-orig/fs/isofs/inode.c Sat Aug 12 21:04:15 2000
+++ linux/fs/isofs/inode.c Mon Sep 11 19:17:13 2000
@@ -737,7 +737,7 @@
#ifdef CONFIG_JOLIET
if (joliet_level && opt.utf8 == 0) {
- char * p = opt.iocharset ? opt.iocharset : "iso8859-1";
+ char * p = opt.iocharset ? opt.iocharset : CONFIG_NLS_DEFAULT;
s->u.isofs_sb.s_nls_iocharset = load_nls(p);
if (! s->u.isofs_sb.s_nls_iocharset) {
/* Fail only if explicit charset specified */
-
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: Linux 2.2.18pre4 (smbfs config.in patch)
A patch for the Config.in problems with smbfs. /Urban diff -ur -X exclude linux-2.2.18-pre4-orig/Documentation/Configure.help linux/Documentation/Configure.help --- linux-2.2.18-pre4-orig/Documentation/Configure.help Sun Sep 10 20:07:56 2000 +++ linux/Documentation/Configure.help Sun Sep 10 20:13:11 2000 @@ -7948,6 +7948,13 @@ want), say M here and read Documentation/modules.txt. The module will be called smbfs.o. Most people say N, however. +use nls by default +CONFIG_SMB_NLS_DEFAULT + Enabling this will make smbfs use nls translations by default. You + need to specify the local charset (CONFIG_NLS_DEFAULT) in the nls + settings and you need to give the default nls for the SMB server as + CONFIG_SMB_NLS_REMOTE. + nls support setting CONFIG_SMB_NLS_REMOTE This setting allows you to specify a default value for which diff -ur -X exclude linux-2.2.18-pre4-orig/fs/Config.in linux/fs/Config.in --- linux-2.2.18-pre4-orig/fs/Config.in Sun Sep 10 20:08:25 2000 +++ linux/fs/Config.in Sun Sep 10 20:14:18 2000 @@ -92,7 +92,10 @@ fi tristate 'SMB filesystem support (to mount WfW shares etc.)' CONFIG_SMB_FS if [ "$CONFIG_SMB_FS" != "n" ]; then - string 'Default Remote NLS Option' CONFIG_SMB_NLS_REMOTE "" + bool ' Use a default NLS' CONFIG_SMB_NLS_DEFAULT + if [ "$CONFIG_SMB_NLS_DEFAULT" = "y" ]; then +string ' Default Remote NLS Option' CONFIG_SMB_NLS_REMOTE "cp437" + fi fi fi if [ "$CONFIG_IPX" != "n" -o "$CONFIG_INET" != "n" ]; then diff -ur -X exclude linux-2.2.18-pre4-orig/fs/nls/Config.in linux/fs/nls/Config.in --- linux-2.2.18-pre4-orig/fs/nls/Config.in Sun Sep 10 20:08:25 2000 +++ linux/fs/nls/Config.in Sun Sep 10 20:16:26 2000 @@ -5,7 +5,7 @@ # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != n ]; then + -o "$CONFIG_SMB_FS" != "n" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n diff -ur -X exclude linux-2.2.18-pre4-orig/fs/smbfs/inode.c linux/fs/smbfs/inode.c --- linux-2.2.18-pre4-orig/fs/smbfs/inode.c Sun Sep 10 20:08:26 2000 +++ linux/fs/smbfs/inode.c Sun Sep 10 20:14:55 2000 @@ -32,6 +32,13 @@ #include "smb_debug.h" +/* Always pick a default string */ +#ifdef CONFIG_SMB_NLS_REMOTE +#define SMB_NLS_REMOTE CONFIG_SMB_NLS_REMOTE +#else +#define SMB_NLS_REMOTE "" +#endif + static void smb_read_inode(struct inode *); static void smb_put_inode(struct inode *); static void smb_delete_inode(struct inode *); @@ -383,7 +390,7 @@ memcpy(mnt, raw_data, sizeof(struct smb_mount_data)); strncpy(mnt->codepage.local_name, CONFIG_NLS_DEFAULT, SMB_NLS_MAXNAMELEN); - strncpy(mnt->codepage.remote_name, CONFIG_SMB_NLS_REMOTE, + strncpy(mnt->codepage.remote_name, SMB_NLS_REMOTE, SMB_NLS_MAXNAMELEN); /* FIXME: ** temp ** pass config flags in file mode */ - 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: Error in fs/nls/Config.in in 2.2.18-pre3
On Thu, 7 Sep 2000, Marcelo Tosatti wrote: > oldconfig always ask about CONFIG_SMB_NLS_REMOTE in case it > was set CONFIG_SMB_NLS_REMOTE="" in the previous config. > > This is expected? It's certainly annoying, especially for people building packages (At least the rpms specs I have looked at). The reason for having a default of "" was only to make it easy to set the default to nothing (which would be unchanged behaviour, no nls translation). I thought I was clever. Having a separate flag should work better. Something like this perhaps? (except that this is from a non-standard directory level, has no Configure.help and is mostly untested). /Urban --- fs/Config.in.orig Thu Sep 7 23:46:55 2000 +++ fs/Config.inFri Sep 8 00:11:23 2000 @@ -92,7 +92,10 @@ fi tristate 'SMB filesystem support (to mount WfW shares etc.)' CONFIG_SMB_FS if [ "$CONFIG_SMB_FS" != "n" ]; then - string 'Default Remote NLS Option' CONFIG_SMB_NLS_REMOTE "" + bool ' Use a default NLS' CONFIG_SMB_NLS_DEFAULT + if [ "$CONFIG_SMB_NLS_DEFAULT" = "y" ]; then +string ' Default Remote NLS Option' CONFIG_SMB_NLS_REMOTE "cp437" + fi fi fi if [ "$CONFIG_IPX" != "n" -o "$CONFIG_INET" != "n" ]; then --- fs/nls/Config.in.orig Thu Sep 7 18:12:43 2000 +++ fs/nls/Config.inThu Sep 7 23:59:31 2000 @@ -5,7 +5,7 @@ # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != n ]; then + -o "$CONFIG_SMB_FS" != "n" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n --- fs/smbfs/inode.c.orig Thu Sep 7 23:56:31 2000 +++ fs/smbfs/inode.cFri Sep 8 00:18:19 2000 @@ -32,6 +32,14 @@ #include "smb_debug.h" +/* Always pick a default string */ +#ifdef CONFIG_SMB_NLS_REMOTE +#define SMB_NLS_REMOTE CONFIG_SMB_NLS_REMOTE +#else +#define SMB_NLS_REMOTE "" +#endif + + static void smb_read_inode(struct inode *); static void smb_put_inode(struct inode *); static void smb_delete_inode(struct inode *); @@ -383,7 +391,7 @@ memcpy(mnt, raw_data, sizeof(struct smb_mount_data)); strncpy(mnt->codepage.local_name, CONFIG_NLS_DEFAULT, SMB_NLS_MAXNAMELEN); - strncpy(mnt->codepage.remote_name, CONFIG_SMB_NLS_REMOTE, + strncpy(mnt->codepage.remote_name, SMB_NLS_REMOTE, SMB_NLS_MAXNAMELEN); /* FIXME: ** temp ** pass config flags in file mode */ - 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: Error in fs/nls/Config.in in 2.2.18-pre3
On Thu, 7 Sep 2000, G. Hugh Song wrote: > if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ > -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ > -o "$CONFIG_SMB_FS" != n ]; then n vs "n" is my error. However 'make menuconfig' works with just n. I know I should have tested with all types of configs but I probably felt that make oldconfig and menuconfig was enough. make config seems happy too. > I simply thought putting n inside an double-quoting n would solve > the problem. But it did not. It should and does for me when I apply the patch below. Did you do something else? /Urban --- linux/fs/nls/Config.in.orig Thu Sep 7 18:12:43 2000 +++ linux/fs/nls/Config.in Thu Sep 7 18:12:56 2000 @@ -5,7 +5,7 @@ # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != n ]; then + -o "$CONFIG_SMB_FS" != "n" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n - 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: fix: Re: 2.4.0-test8-pre2 compile fails at smbfs
On Sat, 2 Sep 2000, Mohammad A. Haque wrote:
> replace current->signal with current->pending.signal
>
> can anyone verify?
I think so, both from reading what the test8-pre2 patch does and from
looking at what smbfs does with current->signal. But it's late so you may
be better off trying the opposite of what I think. :)
Untested patch below for smbfs. Well, it compiles ...
/Urban
--- linux-2.4.0-test8-pre2-orig/fs/smbfs/sock.c Sun Aug 27 13:10:49 2000
+++ linux/fs/smbfs/sock.c Sun Sep 3 00:58:54 2000
@@ -641,7 +641,7 @@
DEBUG1("len = %d cmd = 0x%X\n", len, buffer[8]);
spin_lock_irqsave(¤t->sigmask_lock, flags);
- sigpipe = sigismember(¤t->signal, SIGPIPE);
+ sigpipe = sigismember(¤t->pending.signal, SIGPIPE);
old_set = current->blocked;
siginitsetinv(¤t->blocked, sigmask(SIGKILL)|sigmask(SIGSTOP));
recalc_sigpending(current);
@@ -659,7 +659,7 @@
/* read/write errors are handled by errno */
spin_lock_irqsave(¤t->sigmask_lock, flags);
if (result == -EPIPE && !sigpipe)
- sigdelset(¤t->signal, SIGPIPE);
+ sigdelset(¤t->pending.signal, SIGPIPE);
current->blocked = old_set;
recalc_sigpending(current);
spin_unlock_irqrestore(¤t->sigmask_lock, flags);
@@ -821,7 +821,7 @@
goto bad_conn;
spin_lock_irqsave(¤t->sigmask_lock, flags);
- sigpipe = sigismember(¤t->signal, SIGPIPE);
+ sigpipe = sigismember(¤t->pending.signal, SIGPIPE);
old_set = current->blocked;
siginitsetinv(¤t->blocked, sigmask(SIGKILL)|sigmask(SIGSTOP));
recalc_sigpending(current);
@@ -841,7 +841,7 @@
/* read/write errors are handled by errno */
spin_lock_irqsave(¤t->sigmask_lock, flags);
if (result == -EPIPE && !sigpipe)
- sigdelset(¤t->signal, SIGPIPE);
+ sigdelset(¤t->pending.signal, SIGPIPE);
current->blocked = old_set;
recalc_sigpending(current);
spin_unlock_irqrestore(¤t->sigmask_lock, flags);
-
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] smbfs update for 2.2.18-pre[12]
Hello Patch vs pre1 but also applies vs pre2: http://www.hojdpunkten.ac.se/054/samba/smbfs-2.2.18-pre1.patch.gz Changes are mostly from 2.4.0-test7: * proc.c: add back lanman2 support (OS/2 and others) * proc.c: check length of paths to avoid buffer overflow * proc.c: don't do interruptable_sleep in smb_retry to avoid signal problem/race. * proc.c: O_RDONLY & smb_revalidate_inode fix (tail -f) * proc.c: add nls support * sock.c: attempt to fix smb_data_callback (avoid infinite loop) The lanman2 is a partial undo of some changes made for 2.2.16 that caused problems for OS/2 users. "attempt to fix" should perhaps now be "appears to fix". A problem with lockups (infinite loop with BKL held?) that appears to go away. But the debug outputs haven't told us why. Doing while(1) after a lock_kernel() seems dangerous anyway. /Urban - 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/
