Ticket #1689 (closed bug: fixed)

Opened 2 years ago

Last modified 6 months ago

acquire_sem doesn't timeout

Reported by: marcusoverhagen Owned by: marcusoverhagen
Priority: blocker Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Platform: All
Blocking:

Description

acquire_sem doesn't timeout after 100ms in the ide stack.

This is reproduceable with r23209 and earlier, happens with 4 cores, and also when SMP is disabled by boot menu.

Attachments

haiku-smp-prob12.txt Download (109.7 KB) - added by marcusoverhagen 2 years ago.
test with 4 cores active
haiku-smp-prob13.txt Download (67.8 KB) - added by marcusoverhagen 2 years ago.
test with SMP disabled
haiku-smp-prob14.txt Download (97.9 KB) - added by marcusoverhagen 2 years ago.
retest 1 with syslog disabled
haiku-smp-prob15.txt Download (66.8 KB) - added by marcusoverhagen 2 years ago.
retest 2 with syslog disabled
haiku-smp-prob16.txt Download (70.0 KB) - added by marcusoverhagen 2 years ago.
retest 3 with syslog disabled
interrupts.txt Download (6.0 KB) - added by marcusoverhagen 2 years ago.
Interrupts

Change History

Changed 2 years ago by marcusoverhagen

test with 4 cores active

Changed 2 years ago by marcusoverhagen

test with SMP disabled

Changed 2 years ago by axeld

So it's inside dprintf_args() and never returns from there? What the hell is it doing there? Is it possible that writing to the syslog is the problem here?

Changed 2 years ago by marcusoverhagen

retest 1 with syslog disabled

Changed 2 years ago by marcusoverhagen

retest 2 with syslog disabled

Changed 2 years ago by marcusoverhagen

retest 3 with syslog disabled

Changed 2 years ago by marcusoverhagen

I disabled syslog and retried three times. First try was different, but 2 and 3 get stuck at the same point.

Changed 2 years ago by marcusoverhagen

Interrupts

Changed 2 years ago by marcusoverhagen

I think it is quite likely that the IDE stack never acknowleges the IRQ 11, and that is the reason why the system is stuck at the restore_interrupts() after dprintf.

I'll have a look at that.

Changed 2 years ago by axeld

  • owner changed from axeld to marcusoverhagen

Changed 17 months ago by jackburton

Is this still valid ?

Changed 12 months ago by stippi

  • milestone changed from R1/alpha1 to R1

Even if this is still valid, it's certainly an issue on specific hardware, not a general issue. Therefore I don't believe it should be in the R1/alpha1 milestone.

Changed 6 months ago by marcusoverhagen

  • status changed from new to closed
  • resolution set to fixed

this was resolved by switching to ATA stack

Note: See TracTickets for help on using tickets.