Mohammed Anees commented on a discussion on bsps/i386/shared/irq/apic.c: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1121#note_153396

 > +
 > +static void wait_ipi(void)
 > +{
 > +  int to, send_status;
 > +  to = 0;
 > +  do {
 > +    UDELAY(100);
 > +    send_status = i386_lapic_base[LAPIC_REGISTER_ICR_LOW] & 
 > LAPIC_ICR_STATUS_PEND;
 > +  } while (send_status && (to++ < 1000));  
 > +}
 > +
 > +void
 > +lapic_clear_errors(void)
 > +{
 > +  i386_lapic_base[LAPIC_REGISTER_ESR] = 0;
 > +  (void) i386_lapic_base[LAPIC_REGISTER_ESR];

![Screenshot 2026-06-27 at 5.09.08 
PM.png](/uploads/b999e789ff82bc5aa18e49ba426997ed/Screenshot_2026-06-27_at_5.09.08_PM.png){width=415
 height=129}

the read is emitted but i think its because i386_lapic_base is declared 
volatile. Removing the volatile qualifier causes the compiler to optimize the 
read away

i looked at the origin implementation from which the code was derived from, I 
dont see any confirmation on the read there either - 
http://www.uruk.org/mps/smp-imps.c

https://cgit.freebsd.org/src/tree/sys/x86/x86/local_apic.c I also checked the  
freebsd implementation, when clearing the ESR during LAPIC setup, it only 
writes 0 to the ESR and does not read it back, the intel

![Screenshot 2026-06-27 at 5.35.03 
PM.png](/uploads/fe0979354c9ba76a055dc8cb8cc036ae/Screenshot_2026-06-27_at_5.35.03_PM.png){width=504
 height=104}

i have built and run the tests without the read and that did not cause any 
problems, the intel developer manual doesnt seem to mention anything explicitly 
about this read either, maybe this read can be removed?

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1121#note_153396
You're receiving this email because of your account on gitlab.rtems.org. 
Unsubscribe from this thread: 
https://gitlab.rtems.org/-/sent_notifications/4-3bu3qgouka87x2vgg2u24zyg5-1d/unsubscribe
 | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | 
Help: https://gitlab.rtems.org/help


_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to