2010-09-28 14:28:35 Windows/Linux SAMBA out of synch?
Wojtek Skulski (UNITED STATES)
Message: 93927
Hi:
so now I have SAMBA working between a WinXP and Blackfin Linux board. An I am seeing the file content is out of synch between the two systems. I created an ASCII file "test.txt" under Windows. I am writing to that file with Notepad. I am adding new text, saving to disk under Windows, closing Notepad just to be sure, and doing cat under Linux. The newly added text not necessarily appears on the Linux side. It seems to appear in "jumps" when I make a more substantial change. I have not identified the exact pattern yet, what exactly needs to be done for the text to appear.
Question: is some sort of buffering implemented between the two systems? If so, how to flush these buffers to regain synchronization between the files?
Here is an example. The content of the file under Windows is shown first, and then the "cat" under Linux.
Windows content copy-pasted from Notepad (freshly opened to make sure it was read from disk):
Line 1. test document for blackfin mounting via smb
Line 2. ===========================================
Line 3.
Line 4. This file lives under Windows in "My documents"\test
Line 5.
Line 6. Now I am adding new text to this file.
Line 7.
Line 8.
Line 9. bla bla bla
Line A.
Now the corresponding "cat" from under Linux shows that "bla bla bla" in Line 9 is missing.
root:/etc/config> cat /mnt/test.txt
Line 1. test document for blackfin mounting via smb
Line 2. ===========================================
Line 3.
Line 4. This file lives under Windows in "My documents"\test
Line 5.
Line 6. Now I am adding new text to this file.
Line 7.
Line 8.
Line 9.
Line A.
root:/etc/config>
QuoteReplyEditDelete
2010-09-28 14:37:10 Re: Windows/Linux SAMBA out of synch?
Mike Frysinger (UNITED STATES)
Message: 93929
you didnt say which system was mounting which. if the blackfin mounts the windows system, only the kernel fs driver is in play, so the userspace versions on the blackfin board are irrelevant.
in general though, we really dont have anything to do with samba's development
QuoteReplyEditDelete
2010-09-28 14:48:38 Re: Windows/Linux SAMBA out of synch?
Wojtek Skulski (UNITED STATES)
Message: 93930
Mike:
I issued the mount from the Linux side as follows. Even though I do not expect you folks doing samba, but the community are reading these messages. Perhaps it is a well-known problem to someone. It looks most weird to me, but perhaps I am not the first one to get bitten. Any hints will be appreciated.
The mount was done as follows. On the Windows side I created a shared folder. Then on the Linux side I edited config file per Wiki instructions. Then I issued the mount command under Linux. The name of the Windows computer was not recognized, but the IP worked. That's fine for now. I started testing and I saw the file content was out of synch. That's not OK.
root:/etc/config> cat smb.conf
[global]
workgroup = MSHOME
encrypt passwords = yes
root:/etc/config>
root:/etc/config> smbmount //169.254.144.144/test /mnt -o username=wsku
Password:
smbfs is deprecated and will be removed from the 2.6.27 kernel. Please migrate to cifs
root:/etc/config>
QuoteReplyEditDelete
2010-09-28 15:43:06 Re: Windows/Linux SAMBA out of synch?
Mike Frysinger (UNITED STATES)
Message: 93932
my point is that the userspace code running on the blackfin board is irrelevant in this setup. it isnt like the samba userspace code needs updating (we arent using the very latest) to resolve the issue.
along those lines, smb.conf has no meaning. it used by the samba server, but you arent running one on the blackfin board.
you could delete all the blackfin caches via /proc/sys/vm/drop_caches on the board, but if that doesnt fix anything, i doubt you'll get anywhere with smbfs. the kernel has marked it as dead and the maintainers arent interested in fixing it.
QuoteReplyEditDelete
2010-09-28 16:22:24 Re: Windows/Linux SAMBA out of synch?
Wojtek Skulski (UNITED STATES)
Message: 93933
Mike:
I went for lunch. After I came back, the "bla bla bla" is now visible at the Linux side. So eventually the cache (or whatever that was) got flushed.
I am not married to smbfs. My goal is to exchange files with Windows. I will experiment with cifs. I read the threads and took home that cifs is having some problems. So I started with samba, which according to the previous discussions was working, while cifs was not. I will use whatever is working. I need to find out what is working and then stick to it.
QuoteReplyEditDelete
2010-09-28 16:27:20 Re: Windows/Linux SAMBA out of synch?
Mike Frysinger (UNITED STATES)
Message: 93934
they probably both have bugs. it's up to you to find out which set you can live with.
QuoteReplyEditDelete
2010-09-28 22:11:05 Re: Windows/Linux SAMBA out of synch?
Wojtek Skulski (UNITED STATES)
Message: 93939
> they probably both have bugs.
That is definitely true. I umounted samba and tried to remount under cifs, in order to test the latter. The result is given below. So I think I will stay with SAMBA for now and stay away from CIFS.
root:/> smbumount /mnt
SMB connection re-established (-5)
root:/> ls /mnt
root:/> mount.cifs //169.254.144.144/test /mnt -o username=wsku
Password:
Data access misaligned address violation
- Attempted misaligned data memory or data cache access.
Kernel OOPS in progress
Deferred Exception context
CURRENT PROCESS:
COMM=cifsd PID=200
CPU = 0
invalid mm
return address: [0x000b2f14]; contents of:
0x000b2ef0: 0024 4f09 3209 6539 5a91 6d2a 9510 5008
0x000b2f00: 0010 0000 3210 e491 0024 4f09 3209 6539
0x000b2f10: 5a91 6d2a [9510] 5008 0010 0000 e142 51eb
0x000b2f20: e102 851f c080 180a c683 5180 c111 860a
ADSP-BF561-0.5 200(MHz CCLK) 100(MHz SCLK) (mpu off)
Linux version 2.6.28.10-ADI-2009R1.1
Built with gcc version 4.1.2 (ADI svn)
SEQUENCER STATUS: Not tainted
SEQSTAT: 00000024 IPEND: 8030 SYSCFG: 0006
EXCAUSE : 0x24
interrupts disabled
physical IVG5 asserted : <0xffa00cd4> { _evt_ivhw + 0x0 }
physical IVG15 asserted : <0xffa00ff8> { _evt_system_call + 0x0 }
logical irq 6 mapped : <0xffa00424> { _timer_interrupt + 0x0 }
logical irq 35 mapped : <0x000e9abc> { _bfin_serial_dma_rx_int + 0x0 }
logical irq 36 mapped : <0x000e9c9c> { _bfin_serial_dma_tx_int + 0x0 }
logical irq 82 mapped : <0x000f1730> { _ax88180_interrupt + 0x0 }
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x03675f10> /* kernel dynamic memory */
RETX: <0x00000480> /* Maybe fixed code section */
RETS: <0x000b24e6> { _checkSMB + 0x1d2 }
PC : <0x000b2f14> { _smbCalcSize_LE + 0x10 }
DCPLB_FAULT_ADDR: <0x03509086> /* kernel dynamic memory */
ICPLB_FAULT_ADDR: <0x000b2f14> { _smbCalcSize_LE + 0x10 }
PROCESSOR STATE:
R0 : 03509040 R1 : 00000049 R2 : 00000001 R3 : 00000b68
R4 : 03509040 R5 : 00000001 R6 : 00000069 R7 : 00000065
P0 : 03509040 P1 : 00000022 P2 : 03509087 P3 : 03674000
P4 : 03674000 P5 : 03509040 FP : 0351f200 SP : 03675e34
LB0: ffa015e8 LT0: ffa015e6 LC0: 00000000
LB1: 000f156a LT1: 000f154a LC1: 00000000
B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 2c00fc14
B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 0351f0bc
B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : 00000000
B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 00000000
A0.w: 00001ce3 A0.x: 00000000 A1.w: 0000000e A1.x: 00000000
USP : 00000000 ASTAT: 02002020
Hardware Trace:
0 Target : <0x00005194> { _trap_c + 0x0 }
Source : <0xffa00716> { _exception_to_level5 + 0xae } CALL pcrel
1 Target : <0xffa00668> { _exception_to_level5 + 0x0 }
Source : <0xffa00524> { _bfin_return_from_exception + 0x18 } RTX
2 Target : <0xffa0050c> { _bfin_return_from_exception + 0x0 }
Source : <0xffa005c0> { _ex_trap_c + 0x6c } JUMP.S
3 Target : <0xffa00554> { _ex_trap_c + 0x0 }
Source : <0xffa007f0> { _trap + 0x68 } JUMP (P4)
4 Target : <0xffa007a8> { _trap + 0x20 }
Source : <0xffa007a4> { _trap + 0x1c } IF !CC JUMP
5 Target : <0xffa00788> { _trap + 0x0 }
Source : <0x000b2f12> { _smbCalcSize_LE + 0xe } 0x6d2a
6 Target : <0x000b2f04> { _smbCalcSize_LE + 0x0 }
Source : <0x000b24e2> { _checkSMB + 0x1ce } CALL pcrel
7 Target : <0x000b24e0> { _checkSMB + 0x1cc }
Source : <0x000b24b8> { _checkSMB + 0x1a4 } IF !CC JUMP
8 Target : <0x000b24b2> { _checkSMB + 0x19e }
Source : <0x000b2462> { _checkSMB + 0x14e } IF !CC JUMP
9 Target : <0x000b2452> { _checkSMB + 0x13e }
Source : <0x000b2386> { _checkSMB + 0x72 } IF !CC JUMP
10 Target : <0x000b2364> { _checkSMB + 0x50 }
Source : <0x000b233e> { _checkSMB + 0x2a } IF CC JUMP
11 Target : <0x000b2314> { _checkSMB + 0x0 }
Source : <0x000a7f16> { _cifs_demultiplex_thread + 0x7b6 } CALL pcrel
12 Target : <0x000a7f02> { _cifs_demultiplex_thread + 0x7a2 }
Source : <0x000b224e> { _dump_smb + 0x102 } RTS
13 Target : <0x000b2246> { _dump_smb + 0xfa }
Source : <0x000b2162> { _dump_smb + 0x16 } IF !CC JUMP
14 Target : <0x000b214c> { _dump_smb + 0x0 }
Source : <0x000a7efe> { _cifs_demultiplex_thread + 0x79e } CALL pcrel
15 Target : <0x000a7efa> { _cifs_demultiplex_thread + 0x79a }
Source : <0x000a7e24> { _cifs_demultiplex_thread + 0x6c4 } IF !CC JUMP
Kernel Stack
Stack info:
SP: [0x03675cb8] <0x03675cb8> /* kernel dynamic memory */
FP: (0x03675fb8)
Memory from 0x03675cb0 to 03676000
03675cb0: 001ddfac 001ddfac [00000000] 00000000 3078303c 35373633 3e386263
202a2f20
03675cd0: 6e72656b 64206c65 6d616e79 6d206369 726f6d65 2f2a2079 78302000
20346336
03675cf0: 03675d80 03675cfc 0000ffff 00000000 03550ca0 0366aa20 0351f200
0351f200
03675d10:<0001110a> 03675d58 00000000 03675e34 000b2f30 000b2f14 03675d50
000b2f30
03675d30: 7fffffff 001bebac 03675d4c 03675d48 <00004958> 0351f200 <0001110a>
03675e34
03675d50: 001d9ef4 03674000 0351f200 <000055e6> 03675e34 001d9ef4 03674000
00000065
03675d70: 00000007 00000013 00000024 03675e34 03675cb8 ffffffff 03550ca0
03550f34
03675d90:<001228ca> 00030001 03674000 <00036152> 03675fb0 00000065 00000065
00000000
03675db0: 00000001 00000000 03674000 03674000 03674000 03674000 03550f50
03674000
03675dd0: 03674000 03674000 000006d6 00000000 00000000 0351f200 <000fb10a>
03675f94
03675df0: 03674000 03674000 00000000 00000000 03675f94 03509040 00015200 <
ffa0071a>
03675e10: ffa00cd4 ffe02014 00000065 0000ffff 00000001 03509040 <000f9196>
00000054
03675e30: 03674000 00000480 00008030 00000024 00000000 03675f10 00000480
000b2f14
03675e50:<000b24e6> 03509040 02002020 000f156a ffa015e8 000f154a ffa015e6
00000000
03675e70: 00000000 0000000e 00000000 00001ce3 00000000 00000000 00000000
00000000
03675e90: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
03675eb0: 00000000 00000000 00000000 0351f0bc 2c00fc14 00000000 0351f200
03509040
03675ed0: 03674000 03674000 03509087 00000022 03509040 00000065 00000069
00000001
03675ef0: 03509040 00000b68 00000001 00000049 03509040 03509040 03509040
00000006
03675f10: 03674000 0351f200 <000a7f02> 00db8080 <000a7f1a> 00db8080 03674000
00000069
03675f30: 00000065 00000065 03675f64 <0000a256> 03675f64 00000001 00000065
00000000
03675f50: 00e79980 0351f278 03674000 03674000 0351f268 03509040 036780c0
001d9600
03675f70: 00000000 03ee98e0 0351f278 03509040 03674000 03674000 03674000
03674000
03675f90: 03674000 03675fcc 00000000 03675fb0 00000001 00000000 00000000
03674000
03675fb0: 035090a9 00000000 (00000000)<00021a3c> 000a7760 00000000 00000000
0351f200
03675fd0: 00000000 00000000 00000000 00000000 00000000 00000000 <0000144e>
00000000
03675ff0: 00000000 00000000 ffffffff 00000006
Return addresses in stack:
address : <0x0001110a> { _printk + 0x12 }
address : <0x00004958> { _dump_bfin_mem + 0xd4 }
address : <0x0001110a> { _printk + 0x12 }
address : <0x000055e6> { _trap_c + 0x452 }
address : <0x001228ca> { _tcp_recvmsg + 0x1e2 }
address : <0x00036152> { _get_page_from_freelist + 0x336 }
address : <0x000fb10a> { _sock_common_recvmsg + 0x32 }
address : <0xffa0071a> { _exception_to_level5 + 0xb2 }
address : <0x000f9196> { _sock_recvmsg + 0x9e }
address : <0x000b24e6> { _checkSMB + 0x1d2 }
address : <0x000a7f02> { _cifs_demultiplex_thread + 0x7a2 }
address : <0x000a7f1a> { _cifs_demultiplex_thread + 0x7ba }
address : <0x0000a256> { _dequeue_task + 0x76 }
frame 1 : <0x00021a3c> { _kthread + 0x50 }
address : <0x0000144e> { _kernel_thread_helper + 0x6 }
Modules linked in:
Kernel panic - not syncing: Kernel exception