66 replies to this topic

[kasi]

Hi Zort,

btw this is a nice and helpful tool that i found:
termula

Do I have a déja vu or did I just forget to post the link? Thanks, anyway.

However, I don't know if there really is a significant difference, e.g. in the kernel. I'm not sure if you CAN compile it just for another revision.

Kasi

[zort]

hmmm i found out that there is a g_ether in /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
so in termula i tried this:
(after successfully loading lf1000_ubc.ko)

$ insmod g_ether
Using /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
Segmentation fault

$ insmod g_ether
Using /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
insmod: cannot insert `/lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko': File exists (-1): File exists

i guess something is really b0rken in the firmware 255

[crow_riot]

hmmm i found out that there is a g_ether in /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
so in termula i tried this:
(after successfully loading lf1000_ubc.ko)

$ insmod g_ether
Using /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
Segmentation fault

$ insmod g_ether
Using /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
insmod: cannot insert `/lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko': File exists (-1): File exists

i guess something is really b0rken in the firmware 255

seems they compiled it by themselves and messed it up? i wouldn't be surprised 'bout that ...

[hcf]

Having insmod segfault for any reason is worrisome...

So the reason the serial module works is because for some reason insmod doesn't segfault on it? I wonder what the difference is. They both attach to the same lf1000 driver.

[hiben]

Having insmod segfault for any reason is worrisome...

So the reason the serial module works is because for some reason insmod doesn't segfault on it? I wonder what the difference is. They both attach to the same lf1000 driver.

I experience exactly the same problem here (vev 255) and I did some debugging on the g_ether module.

The problem seems to be that GPH modified the kernel used in revision 255. The alloc_etherdev function does initialize the device but does not allocate the private data structure. This results in a null pointer causing the segfault. After studying the kernel sources I know that this cannot happen: the memory is always allocated. I suspect that GPH modified something (there is a news entry on the official site for some network messaging test) and broke this part of the kernel.

When I allocate the memory 'by hand' the module can be inserted and the device is there. But something is still wrong. ifconfig shows no mac address so 'ifconfig up' does not work. You can assign a mac address and then you can bring up the device but still there is no communication (but at least the pc recognizes the usb interface).

This is very wierd - I hope GPH will release their changes (they actually have to, because that part of the system is GPL) but ... well... you know...

I'll keep on trying to get this working but I guess they damaged the networking stuff to bad...

If anyone wants me to try things with the module on rev 255 I'll be happy to help...

p.s.
First post on this site - just got myself a Wiz. Hello everyone!

[hiben]

I just tried the following:
I compiled pppd for the Wiz and also the needed ppp modules for the kernel.
Then I tried to setup a ppp connection over the usb serial device (g_serial) (USBSerial works really nice btw).

I get a ppp0 device on the wiz but again, no communication is done. Also, the pointtopoint address does not show up in ifconfig. When I tried to set it, the Wiz crashed (not sure, if it was the cause, but interesting).

These strange things make me believe, that GPH definitely messed around with the Kernels networking code at a very low level... (Something that should be punishable by law if you ask me... )

I hope by using pppd I will be able to find out whats going on... maybe I can setup a connection between two pipes on the device and see, if this also fails...

Maybe I'm just missing something very obvious and things will just work... but I have a bad feeling.

*edit*
Just tested pppd over pipes on the Wiz. Does also not work... really broken...
Does any local IP traffic work on the Wiz ?

Edited by hiben, 01 January 2010 - 09:10 PM.

[Jonsul]

Newb here, how useful would this be at this point in it's development for game development?

thanks

[hiben]

Newb here, how useful would this be at this point in it's development for game development?

thanks

Currently, I think this is not useful, as networking with the Wiz is not very common. I personally plan to add Bluetooth and/or Wifi to my Wiz and then there might be opportunities to develop multiplayer games.
For me, I just want to have a network connection for easier debugging and for abusing the Wiz as a remote control for my PC. But rev 255 seems to crush all my dreams... :-|

[hiben]

I did some more testing with the g_ether module and found something curious:

I setup the network on the Wiz using termula by assigning a MAC address and then the IP address. When I setup the network on the PC I see that 4 packets where transferred on the Wiz (interesting... something IS happening).
But when I then try to ping the Wiz, it crashes / hangs.

I'm not sure what to make of this but I'll post further findings here...

*edit*
At least I can now confirm that local IP traffic is still working on the device (two local netcats talking via TCP possible). So the problem must be somewhere at the point where the driver sets up the hooks to get data from the kernel...

Edited by hiben, 08 January 2010 - 10:03 AM.

[kasi]

Hi hiben,

I just can't help asking:
Did you try the new FW 1.2.1 ??

rds

kasi

Edited by kasi, 17 March 2010 - 02:58 PM.

[zort]

I just can't help asking:
Did you try the new FW 1.2.1 ??

i just did it, but it still segfaults ;(
tried both commands:
insmod ./g_ether.ko
insmod g_ether (for the original module)

btw for a storagemount-copyingnewbinary-runit loop i hacked this little tool together -> USBFoo
it just needs some buttons pressed, no reboots

[hmn]

I also have this problem with FW 1.2.1:

lf1000_udc: version 03 Jul 2007
lf1000_udc_probe: base addr = f0018000
Unable to handle kernel NULL pointer dereference at virtual address 0000009c
pgd = c1164000
[0000009c] *pgd=01fde031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
Modules linked in: g_ether lf1000_udc rtc_pollux_m41t80 rtc_core
CPU: 0    Not tainted  (2.6.24 #665)
PC is at eth_bind+0x278/0x6b4 [g_ether]
LR is at alloc_netdev_mq+0xb4/0xd4
pc : [<bf00db30>]    lr : [<c019fb5c>]    psr: a0000013
sp : c1ca1e7c  ip : c1ca1e40  fp : c1ca1ec0
r10: bf00bab4  r9 : bf00ba84  r8 : c1cdf800
r7 : 00000000  r6 : 00000001  r5 : bf012ab6  r4 : 00000002
r3 : 00000000  r2 : 000000a0  r1 : c02739c2  r0 : c1cdf800
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: 01164000  DAC: 00000015
Process insmod (pid: 1074, stack limit = 0xc1ca0258)
Stack: (0xc1ca1e7c to 0xc1ca2000)
1e60:                                                                c028bbaa 
1e80: bf009fc4 c0150ed4 c014fc4c bf00bb58 bf00ba44 00000000 bf0129a0 bf00b9ec 
1ea0: 00000000 bf00bad0 c33a6200 c3374000 00000000 c1ca1ee0 c1ca1ec4 bf008a84 
1ec0: bf00d8c8 c1c2f9c4 c1c2f800 bf012c80 c33a67c8 c1ca1ef0 c1ca1ee4 bf014014 
1ee0: bf0089f8 c1ca1fa4 c1ca1ef4 c00641cc bf014010 00000000 c33a67a0 c33a6430 
1f00: c33a6778 c1ee95a0 c33b7f70 00000023 00000009 00000000 00000000 00000000 
1f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
1f40: 00000000 00000008 00000149 00000149 00000000 c0113fac 00000025 c33a60c6 
1f60: 00000025 bf011d60 c33a6228 bf012c8c 00000025 00000000 00000000 0000000d 
1f80: 00000000 00000000 00000080 c002f044 c1ca0000 00000002 00000000 c1ca1fa8 
1fa0: c002eea0 c0062e58 00000000 00000000 00900080 4021d000 00044b9c 0009d0d0 
1fc0: 0000000d 00000000 00000000 0009d090 00000000 00000000 00000002 00000000 
1fe0: bec6bb54 bec6bb48 00031b78 401b9ec0 60000010 00900080 00000000 00000000 
Backtrace: 
[<bf00d8b8>] (eth_bind+0x0/0x6b4 [g_ether]) from [<bf008a84>] (usb_gadget_register_driver+0x9c/0x1ac [lf1000_udc])
[<bf0089e8>] (usb_gadget_register_driver+0x0/0x1ac [lf1000_udc]) from [<bf014014>] (init+0x14/0x1c [g_ether])
 r7:c33a67c8 r6:bf012c80 r5:c1c2f800 r4:c1c2f9c4
[<bf014000>] (init+0x0/0x1c [g_ether]) from [<c00641cc>] (sys_init_module+0x1384/0x142c)
[<c0062e48>] (sys_init_module+0x0/0x142c) from [<c002eea0>] (ret_fast_syscall+0x0/0x2c)
Code: e598718c e50b202c e51b302c e28720a0 (e587309c) 
---[ end trace 007a4d754b0fcbe1 ]---

[hiben]

I just started playing with my Wiz again after some months of other projects.

Still with the 1.2.1 firmware g_ether does not work for me.
What does work for me is installing a custom kernel with the 1.2.1 firmware and using custom modules for lf1000_udc and g_ether.
In other words: I now have a _working_ usb network connection (just got it to work a few minutes ago but I'm too excited to do a real test (netcat connection works) ;-) ) but it definitely seems to require building a kernel yourself (and then replacing uImage from fw 1.2.1 with your own uImage). (I built my kernel from the wiz branch in the pandora.git).
I'm not yet sure if this brakes something - I'm not going to buy any commercial games for the wiz so I don't care if this part is broken...

If anyone is interested in getting this to work I'll write up the process. So far I was not able to just replace the kernel without updating the whole filesystem from the sd card - this kind of sucks. I guess I'll create a custom bootloader soon that can do this for me...

Now the Wiz got a lot more interesting again for me :-)

[crow_riot]

built my kernel from the wiz branch in the pandora.git

just to note, this is an early version of the firmware - i think it is (almost?) equal to 1.1.0. that's the reason why it's working, because in this kernel GPH didn't ruin it yet

[hcf]

I also have this problem with FW 1.2.1:

Unable to handle kernel NULL pointer dereference at virtual address 0000009c

This looks like the kernel module is trying to dereference a structure member off a NULL pointer.

CPU: 0    Not tainted  (2.6.24 #665)

Edited:

The sources I used to compile the 1.1.0 version of the USBNetwork module is 'linux-2.6.24-pollux'. So it seems they have made further modifications to the kernel beyond what appears in the 'pollux' archive version.

Edited by hcf, 28 July 2010 - 04:09 PM.