All these issues cropped up after upgrading Fedora 14 64bit to Fedora 19 64bit in a box with Gigabyte GA-890XA-UD3 motherboard with onboard Realtek 8111D NIC and Phenom II 955 CPU. 1. CIFS shares cannot close files. While copying files to Windows machines, the 0 size files get created, process then writes X number of bytes to the file and freezes so that machine has to be rebooted. I can reproduce this 100%. KIO seems to be a bit more stable in a sense that while writing to a network folder in KDE the process still freezes, but operation can be cancelled. Not 100% sure that it can be cancelled at all times, but I observed both behaviours with KDE: freezing to death and cancel button stopping w/o freezing. At the same time the same files can be pulled from a Windows machine using a Samba share on F19 machine. 2. CUPS cannot print to the network printers. The JetDirect HP LJ 4000N that worked fine under F14 now prints one empty sheet and 2nd sheet with error message while LCD displays 'BAD TRANSMISSION' and error LED flashes. I can reproduce this 100% 3. Thunderbird version 17 thru 26 cannot send HTML emails and plain text emails longer than probably 1kB. New plain text emails go out, but replies to plain text emails seem to be affected too. I can reproduce this 100%.
Fedora bug was filed for this as well, but this is apparently more than just CIFS issue: https://bugzilla.redhat.com/show_bug.cgi?id=1042778
Just to clarify: F19 was installed into its own physical HDD, not on top of F14. When booting machine into F14 everything mentioned above works fine.
Copy of the error message printed on the 2dn page of printouts by LJ4000N: ERROR: invalidaccess OFFENDING COMMAND: filter STACK /SubFileDecode endstream 0 --nostringval-- --nostringval-- 9 false
There are lots of differences to consider here but firstly what are the printer, SBM box and the PC on the same network segment with just a bridge or is there stuff between them ? If there is and you plug the two devices directly back to back does it then just work ?
The only difference I can see is that machine is booted into Fedora 14 with 2.6.35-14 kernel where everything works fine, or into Fedora 19 with 3.11.10-200 kernel where the above items not working. The machines are on a 100mbit switch at present (1Gbit switch was tested with the same results). Printer connected to the same switch. SMTP was used on one of the machines connected to the same switch, as well as provider's SMTP over DSL with the same results.
Just copied a file over to Win7 machine mounted with mount.cifs. The copy process is not in 'disk sleep' and cannot be killed. Ultimately I will have to kill reset switch as the system will not shutdown or reboot either. Getting this in dmesg: [ 3697.500814] CIFS VFS: Server 10.10.10.2 has not responded in 120 seconds. Reconnecting... When trying to access the same Win7 box via KDE dolphin now with a hung copy, I am getting timeout while normally it's instant.
Typos correction: Just copied a file over to Win7 machine mounted with mount.cifs. The copy process is now in 'disk sleep' and cannot be killed. Ultimately I will have to hit reset switch as the system will not shutdown or reboot either. Getting this in dmesg: [ 3697.500814] CIFS VFS: Server 10.10.10.2 has not responded in 120 seconds. Reconnecting... When trying to access the same Win7 box via KDE dolphin now with a hung copy, I am getting timeout while normally it's instant.
This actually sounds like some kind of low level/networking problem rather than CIFS (CIFS is just showing up as a symptom)
Then I guess you can compare network code from kernel 2.6 with 3 and get to the bottom of it.
Way too many differences for that. You've got a chance of beign able to do that if you can find which actual kernel version was the first non working and which is the first working, but otherwise no.
I'll put your answer on the wall of my cubicle and leave it at that.
(In reply to infove from comment #11) > I'll put your answer on the wall of my cubicle and leave it at that. It's a bit sad because coercing rpm to install fedora own kernels between F14 and F19 in your F14 disk could help. (I only speak for the r8169 part - you may have both r8169 and CIFS problems) A dmesg or its XID line to identify your 8168d chipset will be welcome too. -- Ueimor
No, this is CIFS only. Everything else works fine.