When browsing shared media with Sony's Playstation 3 it stops working after watching a dozen or so pictures. The uPnP media server is mediatomb (http://mediatomb.cc). This only happens with MCP55 based ethernet nics. Reproducible: Always Steps to Reproduce: 1. Start Mediatomb on a systems with a MCP55 based ethernet nic 2. Share pictures in Mediatomb 3. Browser picture folders in PS3's XMB Actual Results: After viewing several folders/thumbnails/pictures it stops working. The PS3 shows an access denied message, allthough the Mediaserver is still working. Expected Results: Serving media to the uPnP client. Tested on Gentoo 2006.1, 2.6.20-gentoo-r8 System 1: Athlon X2, Asus M2N32 SLI Deluxe, nForce NIC System 2: Core2Duo, Asus P5N32-E SLI, nForce NIC System 3: Athlon X2, Asus M2N32 SLI Deluxe, Intel 82557/8/9 Ether Pro 100 System 1&3: Portage 2.1.2.7 (default-linux/x86/2006.1, gcc-4.1.2, glibc-2.4-r4, 2.6.20-gentoo-r8 i686) ================================================================= System uname: 2.6.20-gentoo-r8 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ Gentoo Base System release 1.12.9 Timestamp of tree: Sat, 02 Jun 2007 09:30:01 +0000 System 2: Portage 2.1.2.7 (default-linux/x86/2006.1, gcc-4.1.2, glibc-2.4-r4, 2.6.20-gentoo-r8 i686) ================================================================= System uname: 2.6.20-gentoo-r8 i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Gentoo Base System release 1.12.9 Timestamp of tree: Fri, 01 Jun 2007 10:00:01 +0000
Created attachment 120958 [details] emerge --info on system 1 added emerge --info from system 1
Created attachment 120960 [details] emerge --info on system 2 added emerge --info from system 2
Created attachment 120961 [details] lspci -v from system 1 Added lspci -v from system 1
Created attachment 120963 [details] lspci -v from system 2 added lspci -v from system 2
I know little about upnp and mediatomb. Mediatomb is installed on the x86 machines? Is the PS3 running gentoo linux/ppc64 or the original OS? I cannot find mediatomb in portage. where did you get it from?
I got Mediatomb from its homepage (www.mediatomb.cc). There is a proposed ebuild at http://bugs.gentoo.org/show_bug.cgi?id=172799 I modified this ebuild to use the newest Mediatomb release 0.9.1 and put this ebuild in my local portage overlay. Mediatomb runs on my x86 Gentoo boxes. The Playstation uses its built-in UPnP Client (since PS3 Firmware 1.80). Its using the "Game OS".
ppc64 team cannot do anything about this then (this has nothing to do with PS3 running linux). And mediatomb is not in portage so there is no maintainer for the package (no ebuild, no maintainer), so I advise you to report this issue upstream. I think this is the only possibility to get the bug solved. Go to mediatomb homepage and file a bug.
(In reply to comment #7) > ppc64 team cannot do anything about this then (this has nothing to do with PS3 > running linux). And mediatomb is not in portage so there is no maintainer for > the package (no ebuild, no maintainer), so I advise you to report this issue > upstream. I think this is the only possibility to get the bug solved. Go to > mediatomb homepage and file a bug. > First I thank you for your support. I am sorry that this bug was routed wrong withing gentoo bugzilla. I have not assigned this bug to the ppc64 team. It is certainly not an upstream problem regarding mediatomb. I already did a debug session with mediatomb devs. They think its an issue with kernel/hardware. So this bug should go to kernel devs at gentoo.
ok. so let's move this on to kernel guys.
Firstly, what exactly do you/they think was happening? For example, does the interface start dropping packets or stop working all together? Do you have a link to the discussion with the mediatomb folks? Next, could you please post the kernel config and dmesg from one of the buggy systems. Finally, could you try booting with pci=nomsi and/or noapic and see if that makes a difference.
My personal skills in tcp/ip are not good enough to describe the problematic behavoiur. I have got wireshark dumps of working and non working "uPnP-SessionS". File size is problematic, but I could give you text dumps of the header information or I try to cut the data segments. I got in contact with the mediatomb devs on irc.freenode.net #mediatomb. I mainly talked to jin^eld. I don't have chat logs. I'll post the kernel config and dmesg output later. The kernel parameters will also be ckecked later this day. I'll keep you updated.
Created attachment 122705 [details] config-linux-2.6.20-gentoo-r8.intel
Created attachment 122708 [details] dmesg from system 2
pci=nomsi and/or noapic as kernel parameters make no difference. This was tested on System 2, because system 1 currently runs with the working Intel NIC (e100).
Thanks for that additional info & testing. Could you do an /sbin/ifconfig eth0 before and after the problem starts occurring and post the results, please. That should tell us if the interface is noticing anything wrong. Also, just to confirm, could you check that there isn't anything new in the dmesg after things start going wrong.
chronos ~ # /sbin/ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1A:92:B2:24:05 inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4781 errors:0 dropped:0 overruns:0 frame:0 TX packets:3926 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3315155 (3.1 Mb) TX bytes:1802587 (1.7 Mb) Interrupt:17 Base address:0x8000 chronos ~ # /sbin/ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1A:92:B2:24:05 inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39042 errors:0 dropped:0 overruns:0 frame:0 TX packets:20832 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:40854301 (38.9 Mb) TX bytes:23022692 (21.9 Mb) Interrupt:17 Base address:0x8000
I forgot to mention that there are no changes in the output from dmesg.
So there are no errors in the logs or reported by the interface. As far as the kernel is concerned everything seems to be working fine. I think we need to understand how the application is failing. Are packets being corrupted or dropped? After the failure occurs does other networking functionality continue to work? Try creating a large random file, checksumming it, transferring it over the problematic interface, and then checksumming it on the other end: > dd if=/dev/urandom of=/tmp/rand bs=1024 count=1M > md5sum /tmp/rand > scp /tmp/rand <system 1>:/tmp/rand > ssh <system 1> > md5sum /tmp/rand Do the checksums match?
Please reopen when you respond to comment #18. I'm also of the opinion that we do not have enough information to pinpoint this as kernel bug here...
