Ralink RT2561/RT61 hangs and freezes Haiku

[Premislaus]

New ticket from #8030

Replying to tqh:

Create a new bug with the new problem. Do you have wireless network adapter in that computer? It could be interrupt related so disabling wifi in bios could check for that. I'd recommend to not disable ACPI if possible, disabling ACPI makes rearranging and trying to fix interrupt handling impossible so it should be avoided,

I guess you're right :-). I have a Edimax EW-7128g( pci card), and can not be disabled in BIOS.

ACPI must be disabled, otherwise I don't install Haiku and run it.

As running the Haiku in Safe Mode, it appears on the Deskbar Network Status( or something like that), and then Haiku hangs. How do I know? After several attempts and restarts, no longer is this run and immediately as the Deskbar replicant.

And now I can normally run Haiku, but ACPI must be disabled.

Now I download wpa_suplicant and see whether the Internet will work.

Sorry for my english.

Best regards and thank you tqh :).

[Premislaus]

BTW my motherboard has recognized as GA-K8N ULTRA-9, but I have GA-K8NF-9. Is possible that the fault of the beta BIOS. More in description #8030.

[tqh]

Please provide a syslog with ACPI enabled.

[tqh]

It seems there is a bios update 12K, which might help. Their description is not very informative "Disable PCI prefetch".

[Premislaus]

Replying to tqh:

Please provide a syslog with ACPI enabled.

In what way? Overwrites the old file...

syslog (214.6 KB) - can here?

When I run Haiku with ACPI, then it is hung. Then I start the computer again, and I run Haiku with disabled ACPI. And then I copy the syslog. There full of junk because of attempts to automatically connect to the Internet.

Replying to tqh:

It seems there is a bios update 12K, which might help. Their description is not very informative "Disable PCI prefetch".

On the page is F12K, and I have F12l( from technical support). The point is that graphics cards with the new PCI-E did not want to work on the previous BIOS's. "Disable PCI prefetch"( Nvidia did not want to pay for a patent) - This in my BIOS is not included.

[Premislaus]

I know what is the problem. ralinkwifi driver is defective( broken, faulty, buggy). I moved file ralinkwifi from /boot/system/add-ons/kernel/drivers/dev/net to Desktop.

And Haiku starts with ACPI and running stably.

Tested on hrev43690 gcc2.

In addition, this driver does not work for me - #8296 ( Haiku running with disabled ACPI).

[diver]

From what I understood:

• Haiku freezes during boot unless you disable ACPI in the bootloader.
  
• With disabled ACPI you are able to see some of the available networks (#8296).
  
• Haiku boots ok with ACPI enabled if you remove ralinkwifi driver.
  

Is that so? Please try to get syslog with both ralinkwifi and ACPI enabled.

[Premislaus]

Replying to diver:

From what I understood:

• Haiku freezes during boot unless you disable ACPI in the bootloader.
  
• With disabled ACPI you are able to see some of the available networks (#8296).
  
• Haiku boots ok with ACPI enabled if you remove ralinkwifi driver.
  

Is that so? Please try to get syslog with both ralinkwifi and ACPI enabled.

Yes. Well you think.

Unfortunately, syslog does not want to save... Saves on the disk, when I disable ACPI, or I will remove the driver.

[luroh]

Your motherboard seems to have a serial COM port (9-pin D-sub connector). That COM port can be used to capture the syslog over to another computer, by means of using a null modem serial cable. In the boot loader menu, go to 'Select debug options' and select 'Enable serial debug output'.

[Premislaus]

Replying to luroh:

Your motherboard seems to have a serial COM port (9-pin D-sub connector). That COM port can be used to capture the syslog over to another computer, by means of using a null modem serial cable. In the boot loader menu, go to 'Select debug options' and select 'Enable serial debug output'.

But which device I do connect to COM? I do not have such a cable, or another computer.

[Premislaus]

Replying to diver:

Is that so? Please try to get syslog with both ralinkwifi and ACPI enabled.

In the KDL I was playing( used) with various commands. I typed thread, returned to me thread 92 and it was ralinkwifi, I entered the suspend 92, then continue, Haiku launched :). I copied the syslog.

[Premislaus]

new

[Premislaus]

new

[Premislaus]

A new observation. ralinkwifi crashes Haiku even with the disabled ACPI. It is often random. Even as it does nothing, even after the start, or only after some time.

KDL command drop thread 91:

KERN: kdebug> drop 91PANIC: _mutex_lock(): called with interrupts disabled for lock 0x82a119a0
KERN: Welcome to Kernel Debugging Land...
KERN: Thread 91 "ral intr handler" running on CPU 0
KERN: stack trace for thread 91 "ral intr handler"
KERN:     kernel stack: 0x81fb0000 to 0x81fb4000
KERN: frame               caller     <image>:function + offset
KERN:  0 81fb33f4 (+  32) 8010412b   <kernel_x86>:arch_debug_stack_trace + 0x000f
KERN:  1 81fb3414 (+  16) 8008252a   <kernel_x86> stack_trace_trampoline(void*: NULL) + 0x000b
KERN:  2 81fb3424 (+  12) 80108c52   <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b
KERN:  3 81fb3430 (+  48) 80082f6e   <kernel_x86>:debug_call_with_fault_handler + 0x0050
KERN:  4 81fb3460 (+  80) 80083bfb   <kernel_x86> kernel_debugger_loop(char const*: [34m0x0[0m [31m"<NULL>"[0m, char const*: [34m0x8017bb60[0m [36m"đ4ű"[0m, char*: [34m0x81fb34f0[0m, int32: [34m-2146943412[0m) + 0x0210
KERN:  5 81fb34b0 (+  64) 80083e77   <kernel_x86> kernel_debugger_internal(char const*: [34m0x0[0m [31m"<NULL>"[0m, char const*: [34m0x81fb36d0[0m [36m""[0m, char*: [34m0x81fb3510[0m, int32: [34m-2146942806[0m) + 0x0108
KERN:  6 81fb34f0 (+  32) 800840be   <kernel_x86>:panic + 0x0023
KERN:  7 81fb3510 (+  80) 8007c1d9   <kernel_x86>:_mutex_lock + 0x0031
KERN:  8 81fb3560 (+  64) 80070b8c   <kernel_x86> BKernel::Thread<[32m0x5b[0m>::GetAndLock(int32: [34m-2114243104[0m) + 0x0076
KERN:  9 81fb35a0 (+  80) 8009a0ca   <kernel_x86>:_user_debug_thread + 0x0011
KERN: 10 81fb35f0 (+  32) 8006f8ca   <kernel_x86> drop_into_debugger(int32: [34m2[0m, char**: [34m0xcce38520[0m) + 0x004b
KERN: 11 81fb3610 (+  32) 80085205   <kernel_x86> invoke_command_trampoline(void*: [34m0x81fb3684[0m) + 0x0015
KERN: 12 81fb3630 (+  12) 80108c52   <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b
KERN: 13 81fb363c (+  48) 80082f6e   <kernel_x86>:debug_call_with_fault_handler + 0x0050
KERN: 14 81fb366c (+  64) 80085409   <kernel_x86>:invoke_debugger_command + 0x00be
KERN: 15 81fb36ac (+  64) 80085542   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: [34m0xcce38030[0m, int32: [34m1[0m, char*: [34m0x2[0m) + 0x006f
KERN: 16 81fb36ec (+  48) 80085626   <kernel_x86>:invoke_debugger_command_pipe + 0x00a6
KERN: 17 81fb371c (+  64) 80089999   <kernel_x86> ExpressionParser<[32m0x81fb37e8[0m>::_ParseCommandPipe(int&: [34m0x81fb37e4[0m) + 0x0b01
KERN: 18 81fb375c (+  96) 8008ed91   <kernel_x86> ExpressionParser<[32m0x81fb37e8[0m>::EvaluateCommand(char const*: [34m0x8017a720[0m [36m"drop 91"[0m, int&: [34m0x81fb37e4[0m) + 0x0b5b
KERN: 19 81fb37bc (+ 208) 80090e7a   <kernel_x86>:evaluate_debug_command + 0x008a
KERN: 20 81fb388c (+  80) 80083cd8   <kernel_x86> kernel_debugger_loop(char const*: [34m0x0[0m [31m"<NULL>"[0m, char const*: [34m0x8017bb60[0m [36m"đ4ű"[0m, char*: [34m0x81fb391c[0m, int32: [34m-2146943412[0m) + 0x02ed
KERN: 21 81fb38dc (+  64) 80083e77   <kernel_x86> kernel_debugger_internal(char const*: [34m0x0[0m [31m"<NULL>"[0m, char const*: [34m0x14[0m [31m"<???>"[0m, char*: [34m0x81fb393c[0m, int32: [34m-2146942806[0m) + 0x0108
KERN: 22 81fb391c (+  32) 800840be   <kernel_x86>:panic + 0x0023
KERN: 23 81fb393c (+  80) 8007c1d9   <kernel_x86>:_mutex_lock + 0x0031
KERN: 24 81fb398c (+  64) 80070b8c   <kernel_x86> BKernel::Thread<[32m0x5b[0m>::GetAndLock(int32: [34m-2104796672[0m) + 0x0076
KERN: 25 81fb39cc (+  80) 8009a0ca   <kernel_x86>:_user_debug_thread + 0x0011
KERN: 26 81fb3a1c (+  32) 8006f8ca   <kernel_x86> drop_into_debugger(int32: [34m2[0m, char**: [34m0xcce381e0[0m) + 0x004b
KERN: 27 81fb3a3c (+  32) 80085205   <kernel_x86> invoke_command_trampoline(void*: [34m0x81fb3ab0[0m) + 0x0015
KERN: 28 81fb3a5c (+  12) 80108c52   <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b
KERN: 29 81fb3a68 (+  48) 80082f6e   <kernel_x86>:debug_call_with_fault_handler + 0x0050
KERN: 30 81fb3a98 (+  64) 80085409   <kernel_x86>:invoke_debugger_command + 0x00be
KERN: 31 81fb3ad8 (+  64) 80085542   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: NULL, int32: [34m1[0m, char*: [34m0x2[0m) + 0x006f
KERN: 32 81fb3b18 (+  48) 80085626   <kernel_x86>:invoke_debugger_command_pipe + 0x00a6
KERN: 33 81fb3b48 (+  64) 80089999   <kernel_x86> ExpressionParser<[32m0x81fb3c14[0m>::_ParseCommandPipe(int&: [34m0x81fb3c10[0m) + 0x0b01
KERN: 34 81fb3b88 (+  96) 8008ed91   <kernel_x86> ExpressionParser<[32m0x81fb3c14[0m>::EvaluateCommand(char const*: [34m0x8017a720[0m [36m"drop 91"[0m, int&: [34m0x81fb3c10[0m) + 0x0b5b
KERN: 35 81fb3be8 (+ 208) 80090e7a   <kernel_x86>:evaluate_debug_command + 0x008a
KERN: 36 81fb3cb8 (+  80) 80083cd8   <kernel_x86> kernel_debugger_loop(char const*: [34m0x0[0m [31m"<NULL>"[0m, char const*: [34m0x8017bb60[0m [36m"đ4ű"[0m, char*: [34m0x81fb3d48[0m, int32: [34m-2146943412[0m) + 0x02ed
KERN: 37 81fb3d08 (+  64) 80083e77   <kernel_x86> kernel_debugger_internal(char const*: [34m0x0[0m [31m"<NULL>"[0m, char const*: [34m0x2[0m [31m"<???>"[0m, char*: [34m0x81fb3d68[0m, int32: [34m-2146942960[0m) + 0x0108
KERN: 38 81fb3d48 (+  32) 80084027   <kernel_x86>:kernel_debugger + 0x0026
KERN: 39 81fb3d68 (+  32) 8008405f   <kernel_x86>:debug_emergency_key_pressed + 0x002a
KERN: 40 81fb3d88 (+  64) 81cbcf1f   </boot/system/add-ons/kernel/bus_managers/ps2> keyboard_handle_int(ps2_dev*: [34m0x81cc225c[0m) + 0x00fa
KERN: 41 81fb3dc8 (+  64) 81cbc5cb   </boot/system/add-ons/kernel/bus_managers/ps2>:ps2_dev_handle_int + 0x0287
KERN: 42 81fb3e08 (+  64) 81cbb87b   </boot/system/add-ons/kernel/bus_managers/ps2> ps2_interrupt(void*: NULL) + 0x00e5
KERN: 43 81fb3e48 (+  64) 8005390e   <kernel_x86>:int_io_interrupt_handler + 0x0051
KERN: 44 81fb3e88 (+  64) 8010547d   <kernel_x86> hardware_interrupt(iframe*: [34m0x81fb3ed4[0m) + 0x007b
KERN: 45 81fb3ec8 (+  12) 80109c0d   <kernel_x86>:int_bottom + 0x003d
KERN: kernel iframe at 0x81fb3ed4 (end = 0x81fb3f24)
KERN:  eax 0x200          ebx 0x82579ca0      ecx 0x3468       edx 0x14
KERN:  esi 0x82a7f000     edi 0xce79e3d0      ebp 0x81fb3f24   esp 0x81fb3f08
KERN:  eip 0x8256246f  eflags 0x13286    
KERN:  vector: 0x21, error code: 0x0
KERN: 46 81fb3ed4 (+  80) 8256246f   </boot/system/add-ons/kernel/drivers/dev/net/ralinkwifi>:bus_space_read_4 + 0x0018
KERN: 47 81fb3f24 (+ 112) 82531f5b   </boot/system/add-ons/kernel/drivers/dev/net/ralinkwifi>:rt2661_intr + 0x008c
KERN: 48 81fb3f94 (+  48) 82561e7a   </boot/system/add-ons/kernel/drivers/dev/net/ralinkwifi>:intr_handler + 0x003a
KERN: 49 81fb3fc4 (+  32) 80072907   <kernel_x86> common_thread_eKERN: ntry(void*: [34m0x81fb3ff0[0m) + 0x007a
KERN: kdebug> suspend 91thread 91 suspended
KERN: kdebug> continuedrop failed
KERN: kdebug> continue[Kdrop failed

I tried to disable in the BIOS everything they could to release an IRQ. It helped a little on Haiku crashes. Sometimes seen an additional, fourth network. One time an alien network, very strongly. Several times I saw own network, but I could not connect.

I have not strength to it. I have no idea what to put here so that you can solve my problem.

hrev44061

[Premislaus]

In the rhrev44323 ACPICA has been updated to the latest version. So I installed hrev44330 gcc4h. But the problem still occurs... :-(

I still need disable ACPI to install Haiku. I can start Haiku with ACPI, but it hangs. Then I use Alt-SysRq-D and suspend thread. Even with disabled ACPI, still happens. Still I do not have Internet. And wrong detects network.

Haiku detects my wi-fi card as EW-7108PCg( PCMCIA card), but I have EW-7128g( PCI card).

Best regards

[diver]

Haiku uses PCI ID database to identify hardware ​http://pciids.sourceforge.net
If you think there is a mistake with your - check their website and correct it if possible.

[Premislaus]

Replying to diver:

Haiku uses PCI ID database to identify hardware ​http://pciids.sourceforge.net
If you think there is a mistake with your - check their website and correct it if possible.

I do not know what to type.

%Edimax7128.DeviceDesc%= EDIMAX.ndi,CI\VEN_1814&DEV_0201&SUBSYS_71281432 %EW-7128.DeviceDesc%=Edimax.ndi,PCI\VEN_1814&DEV_0302&SUBSYS_71281432 %Ralink_0301.DeviceDesc%= RALINK_0301.ndi,PCI\VEN_1814&DEV_0301&SUBSYS_25611814 %Ralink.DeviceDesc%= RALINK.ndi,PCI\VEN_1814&DEV_0201&SUBSYS_25601814

I attach the rest.

[Premislaus]

​http://pci-ids.ucw.cz/read/PC/1814/0301/18142561

[Premislaus]

​http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/network/wlan/ralinkwifi/dev/ral/if_ral_pci.c#n74

IDs in Haiku drivers, looks properly.

[diver]

There are a lot of unhandled apic_timer_interrupt in this attachment:"after freezes, alt + sysrq + d, ints.jpg"​, so it's probably something with the glue code of ralinkwifi driver or with the kernel itself.

[mmlr]

Replying to diver:

There are a lot of unhandled apic_timer_interrupt in this attachment:"after freezes, alt + sysrq + d, ints.jpg"​, so it's probably something with the glue code of ralinkwifi driver or with the kernel itself.

The apic_timer_interrupt unhandled count is normal. As long as it has around as many unhandled as handled ones, everything's fine (should eventually be debugged, but doesn't concern this ticket). The handled count on the wifi driver is rather high though, which probably indicates that there's an interrupt storm due to the driver not actually handling or acknowledging the interrupt.

[Premislaus]

Still occurs in hrevr1alpha4-44609. Is there a possibility that this will be fixed in the alpha4?

[Premislaus]

Still occurs on hrevr1alpha4-44687. :-(

[Premislaus]

Still occurs on hrev45142 (drivers update from FreeBSD).

Probably soon I'll have a new internet connection (Wi-Fi 5 GHz + router). So this ticket will be invalid. I will not have the opportunity to check this bug.

[korli]

The intr handler rt2560_intr() and rt2661_intr() have in common that they don't check if the interrupt is theirs before proceeding. This can certainly pose problems when the interrupt line is shared, which seems the case (USB, SATA, HDMI Audio).

As to why it doesn't pose problem in FreeBSD, they probably only use MSI and don't share interrupts anymore. Just a guess.

[Premislaus]

​http://www.freelists.org/post/haiku-development/Donation-of-hardware-for-the-developer-to-fixed-the-bugs

[luroh]

Premislaus: have you noticed any improvement here or in #8296?

[waddlesplash]

Please retest after hrev52113.

[waddlesplash]

No reply in 5 years, closing as invalid.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed