* usbuhci.c bug?
@ 2016-02-15 22:19 kokamoto
2016-02-16 7:29 ` [9front] " cinap_lenrek
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: kokamoto @ 2016-02-15 22:19 UTC (permalink / raw)
To: 9front
I updated my 9front, and got many of
uhci: 0xfc00: not running uhci bug?
errors.
The source of /sys/src/9/pc/usbuhci.c has a line at 961, like
if((cmd & Crun) == 0){.
Should the line be
if(cmd & Crun == 0){.?
Kenji
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] usbuhci.c bug?
2016-02-16 7:29 ` [9front] " cinap_lenrek
@ 2016-02-15 23:20 ` kokamoto
0 siblings, 0 replies; 6+ messages in thread
From: kokamoto @ 2016-02-15 23:20 UTC (permalink / raw)
To: 9front
> does the usb controller work at all?
Both of older and recent sources work fine, strangely. ☺
I checked by putting the usb stick and to see the /shr directory,
and to read one jpg file.
I got success to see the image in both case.
Kenji
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] usbuhci.c bug?
2016-02-15 22:19 usbuhci.c bug? kokamoto
@ 2016-02-16 7:29 ` cinap_lenrek
2016-02-15 23:20 ` kokamoto
2016-02-16 7:42 ` cinap_lenrek
` (2 subsequent siblings)
3 siblings, 1 reply; 6+ messages in thread
From: cinap_lenrek @ 2016-02-16 7:29 UTC (permalink / raw)
To: 9front
no, the old code was wrong. the == operator has higher precedence than &,
so it would do if(cmd & (Crun == 0)), which becomes if(cmd & 0), which becomes
if(0) which is not what is intended. the intention is to check if the Run
bit is clear, and print a warning in that case.
does the usb controller work at all?
--
cinap
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] usbuhci.c bug?
2016-02-15 22:19 usbuhci.c bug? kokamoto
2016-02-16 7:29 ` [9front] " cinap_lenrek
@ 2016-02-16 7:42 ` cinap_lenrek
2016-02-16 7:49 ` cinap_lenrek
2016-02-16 7:52 ` cinap_lenrek
3 siblings, 0 replies; 6+ messages in thread
From: cinap_lenrek @ 2016-02-16 7:42 UTC (permalink / raw)
To: 9front
if the controller has the run bit always clear, but appears to be working,
we could move the check in the debug case. i can see how printing every time
in the interrupt handler would make your system pretty much unusable.
--
cinap
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] usbuhci.c bug?
2016-02-15 22:19 usbuhci.c bug? kokamoto
2016-02-16 7:29 ` [9front] " cinap_lenrek
2016-02-16 7:42 ` cinap_lenrek
@ 2016-02-16 7:49 ` cinap_lenrek
2016-02-16 7:52 ` cinap_lenrek
3 siblings, 0 replies; 6+ messages in thread
From: cinap_lenrek @ 2016-02-16 7:49 UTC (permalink / raw)
To: 9front
tempted to just remove the whole check. theres already debug
print in there that can be enabled.
--
cinap
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] usbuhci.c bug?
2016-02-15 22:19 usbuhci.c bug? kokamoto
` (2 preceding siblings ...)
2016-02-16 7:49 ` cinap_lenrek
@ 2016-02-16 7:52 ` cinap_lenrek
3 siblings, 0 replies; 6+ messages in thread
From: cinap_lenrek @ 2016-02-16 7:52 UTC (permalink / raw)
To: 9front
removed the print.
--
cinap
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-02-16 8:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-15 22:19 usbuhci.c bug? kokamoto
2016-02-16 7:29 ` [9front] " cinap_lenrek
2016-02-15 23:20 ` kokamoto
2016-02-16 7:42 ` cinap_lenrek
2016-02-16 7:49 ` cinap_lenrek
2016-02-16 7:52 ` cinap_lenrek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).