Bekijk de volledige versie : Probleme mit USB-Seriell FTDI Adapter

29-08-2008, 23:41
Hallo, ich habe einen ASUS-wl500gpV2 mit olegs Original FW (2008-03-30). Als USB-Seriell Adapter verwende ich einen mit FTDI Chip.
Dieser wird korrekt erkannt, und lässt sich auch mit stty -F /dev/ttyUSB0 einstellen.

cat /proc/bus/usb/devices
P: Vendor=0403 ProdID=6001 Rev= 4.00
S: Manufacturer=ftdi
S: Product=usb serial converter
S: SerialNumber=ftDXPJB6
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 44mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=serial
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1

Wenn ich nun mit:

cat datei > /dev/ttyUSB0

eine beliebige Textdatei senden will, tritt nach einigen Zeilen korrekter Übertragung ein Fehler auf und rebootet mit "Kernel panic...".

Folgenden Trace konnte ich auf der Konsole /dev/tts/0 mitlauschen:

Scheduling in interrupt

kernel BUG at sched.c:572!

Unable to handle kernel paging request at virtual address 00000000, epc == 8000d
3c0, ra == 8000d3c0

Oops in fault.c::do_page_fault, line 192:

$0 : 00000000 10009c00 0000001b 00000001 81cee000 00000000 00000001 00000000

$8 : 00001beb 8020f319 00000000 00000000 fffffff9 ffffffff 0000000a 00000002

$16: 802f88a0 8162e000 8162e000 00000002 81edd880 00000000 00000000 801d4000

$24: 8162f7fa 00000002 8162e000 8162f930 8162f930 8000d3c0

Hi : 00000000

Lo : 000006c0

epc : 8000d3c0 Tainted: P

Status: 10009c03

Cause : 8000000c

Process dmesg (pid: 150, stackpage=8162e000)

Stack: 801a8b58 801a8b70 0000023c 0000001f 00000000 81edd878 8162e000

00000002 81edd880 81edd820 818172a0 81e21280 00000000 800073e8 c011159c

c011158c 00000000 00000000 00000000 8162e000 81edd880 81edd880 81edd820

81edd800 ffffffea 81edd878 00000000 c0160b94 801f6f28 00000081 81831c18

00000000 81dd0000 00000038 81dd0000 81dd0370 800ad810 80030238 00000000

c01132ec ...

Call Trace: [<801a8b58>] [<801a8b70>] [<800073e8>] [<c011159c>] [<c011158c>]

[<c0160b94>] [<800ad810>] [<80030238>] [<c01132ec>] [<801941fc>] [<800adc68>]

[<800af9c8>] [<c010f8fc>] [<800ae4a4>] [<c010f920>] [<8002750c>] [<c0111134>]

[<c010f8fc>] [<c0113eb0>] [<800acc64>] [<800ace18>] [<c00f4c30>] [<c01693b8>]

[<c0101f60>] [<c010250c>] [<c0110170>] [<c01103a0>] [<c010fa4c>] [<c011021c>]

[<c0111364>] [<c011158c>] [<c0113c54>] [<800ad810>] [<c0113db8>] [<800adc68>]

[<800e011c>] [<c01024a0>] [<c010f8fc>] [<80002134>] [<c010f920>] ...

Code: 24a58b70 0c0043f5 2406023c <080033e9> ac000000 3c04801b 24848b58 3c05
801b 24a58b70

Kernel panic: Aiee, killing interrupt handler!

In interrupt handler - not syncing

<0>Rebooting in 3 seconds..

Fehler tritt auch auf wenn der FTDI als einzigstes Gerät am USB hängt.
Hat jemand schon einen USB-Seriell Adapter an dem wl500gpV2 zum Laufen bekommen? Bzw. kann hier jemand weiterhelfen?

12-02-2013, 14:02
I have the same problem with arduino nano (I am sendind sensor data to serial and then capturing it with script) - from time to time USB connection stops working and event restart didnt help.
System log shows error:

new USB device 01:03.0-2, assigned address 2
USB device not accepting new address=2 (error=-145)

I tried reloading drivers (ftdi_sio,pl2303, usbserial), but with no effect.
Firmware, asus WL 500 gpV2

I am planning to flash newest firmware with 2.6 kernel and then I will let you know.

04-03-2013, 15:54
I'm experiencing the same with Arduino device, even rebooting many times does not fix the issue.
However, it was running for a year more or less without problems. Here the issue is on the wl-hdd.

Any luck with the new kernel? Did you easily find the FTDI drivers modules?

04-03-2013, 15:59
Any luck with the new kernel? Did you easily find the FTDI drivers modules?

With the 2,6 kernel, after power went down recently everything was running OK. There were no problems with kernel not recognizing USB device, but I tried advice from the forum about using USB hub to overcome what is likely timing problem, so I am not sure which one of these solutions (new kernel, USB hub) was right.