Summary: | forcedeth on mcp55 shows bad behaviour with Mediatomb uPnP Server and Sony PS3 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ron <wordas> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED NEEDINFO | ||
Severity: | major | CC: | duaneg |
Priority: | High | ||
Version: | 2006.1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info on system 1
emerge --info on system 2 lspci -v from system 1 lspci -v from system 2 config-linux-2.6.20-gentoo-r8.intel dmesg from system 2 |
Description
Ron
2007-06-02 17:50:36 UTC
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... |