* Re: [9front] ahci led: reset spins.
@ 2019-11-17 21:19 ori
0 siblings, 0 replies; 3+ messages in thread
From: ori @ 2019-11-17 21:19 UTC (permalink / raw)
To: cinap_lenrek, 9front
> the whole code in ledkproc() looks rather suspect to me.
>
> for example, the map[] is NCtlr sized, so i would
> assume that the index is the controller number,
> but later, we index into it by the driver number.
Yes. What was going on there seemed odd. especially
the 'j += c->enctype' bit. I was planning on asking
wtf was going on with it on IRC before trying to
make changes, since it wasn't part of my current
problem.
> theres also a microdelay() loop in blink() that
> could be spinning forever. theres no reason to use
> delay() or microdelay() as well as we run on behalf
> of a kproc so we can properly sleep and not burn
> cpu cycles.
This diff definitely looks better, and works on my
machines -- thanks!
>
> diff -r 874554781a81 sys/src/9/pc/sdiahci.c
> --- a/sys/src/9/pc/sdiahci.c Sun Nov 17 19:04:38 2019 +0100
> +++ b/sys/src/9/pc/sdiahci.c Sun Nov 17 21:04:51 2019 +0100
> @@ -1215,14 +1215,19 @@
> ahciencreset(Ctlr *c)
> {
> Ahba *h;
> + int i;
>
> if(c->enctype == Eesb)
> return 0;
> h = c->hba;
> h->emctl |= Emrst;
> - while(h->emctl & Emrst)
> - delay(1);
> - return 0;
> + for(i = 0; i < 1000; i++){
> + if((h->emctl & Emrst) == 0)
> + return 0;
> + esleep(1);
> + }
> + print("%s: ahciencreset: hung ctlr\n", Tname(c));
> + return -1;
> }
>
> /*
> @@ -1301,9 +1306,11 @@
> return 0;
> c = d->ctlr;
> h = c->hba;
> +
> /* ensure last message has been transmitted */
> - while(h->emctl & Tmsg)
> - microdelay(1);
> + if(h->emctl & Tmsg)
> + return -1;
> +
> switch(c->enctype){
> default:
> panic("%s: bad led type %d", dnam(d), c->enctype);
> @@ -1403,30 +1410,34 @@
> memset(map, 0, sizeof map);
> for(i = 0; i < niactlr; i++)
> if(iactlr[i].enctype != 0){
> - ahciencreset(iactlr + i);
> + if(ahciencreset(iactlr + i) == -1)
> + continue;
> map[i] = 1;
> j++;
> }
> if(j == 0)
> pexit("no work", 1);
> for(i = 0; i < niadrive; i++){
> - iadrive[i]->nled = 3; /* hardcoded */
> - if(iadrive[i]->ctlr->enctype == Eesb)
> - iadrive[i]->nled = 3;
> - iadrive[i]->ledbits = -1;
> + d = iadrive[i];
> + d->nled = 3; /* hardcoded */
> + if(d->ctlr->enctype == Eesb)
> + d->nled = 3;
> + d->ledbits = -1;
> }
> for(i = 0; ; i++){
> t0 = Ticks;
> for(j = 0; j < niadrive; ){
> - c = iadrive[j]->ctlr;
> - if(map[j] == 0)
> - j += c->enctype;
> - else if(c->enctype == Eesb){
> + d = iadrive[j];
> + c = d->ctlr;
> + if(map[c - iactlr] == 0)
> + j++;
> + else
> + if(c->enctype == Eesb){
> blinkesb(c, i);
> j += c->ndrive;
> }else{
> - d = iadrive[j++];
> blink(d, i);
> + j++;
> }
> }
> t1 = Ticks;
>
> --
> cinap
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9front] ahci led: reset spins.
@ 2019-11-17 20:10 cinap_lenrek
0 siblings, 0 replies; 3+ messages in thread
From: cinap_lenrek @ 2019-11-17 20:10 UTC (permalink / raw)
To: 9front
the whole code in ledkproc() looks rather suspect to me.
for example, the map[] is NCtlr sized, so i would
assume that the index is the controller number,
but later, we index into it by the driver number.
theres also a microdelay() loop in blink() that
could be spinning forever. theres no reason to use
delay() or microdelay() as well as we run on behalf
of a kproc so we can properly sleep and not burn
cpu cycles.
diff -r 874554781a81 sys/src/9/pc/sdiahci.c
--- a/sys/src/9/pc/sdiahci.c Sun Nov 17 19:04:38 2019 +0100
+++ b/sys/src/9/pc/sdiahci.c Sun Nov 17 21:04:51 2019 +0100
@@ -1215,14 +1215,19 @@
ahciencreset(Ctlr *c)
{
Ahba *h;
+ int i;
if(c->enctype == Eesb)
return 0;
h = c->hba;
h->emctl |= Emrst;
- while(h->emctl & Emrst)
- delay(1);
- return 0;
+ for(i = 0; i < 1000; i++){
+ if((h->emctl & Emrst) == 0)
+ return 0;
+ esleep(1);
+ }
+ print("%s: ahciencreset: hung ctlr\n", Tname(c));
+ return -1;
}
/*
@@ -1301,9 +1306,11 @@
return 0;
c = d->ctlr;
h = c->hba;
+
/* ensure last message has been transmitted */
- while(h->emctl & Tmsg)
- microdelay(1);
+ if(h->emctl & Tmsg)
+ return -1;
+
switch(c->enctype){
default:
panic("%s: bad led type %d", dnam(d), c->enctype);
@@ -1403,30 +1410,34 @@
memset(map, 0, sizeof map);
for(i = 0; i < niactlr; i++)
if(iactlr[i].enctype != 0){
- ahciencreset(iactlr + i);
+ if(ahciencreset(iactlr + i) == -1)
+ continue;
map[i] = 1;
j++;
}
if(j == 0)
pexit("no work", 1);
for(i = 0; i < niadrive; i++){
- iadrive[i]->nled = 3; /* hardcoded */
- if(iadrive[i]->ctlr->enctype == Eesb)
- iadrive[i]->nled = 3;
- iadrive[i]->ledbits = -1;
+ d = iadrive[i];
+ d->nled = 3; /* hardcoded */
+ if(d->ctlr->enctype == Eesb)
+ d->nled = 3;
+ d->ledbits = -1;
}
for(i = 0; ; i++){
t0 = Ticks;
for(j = 0; j < niadrive; ){
- c = iadrive[j]->ctlr;
- if(map[j] == 0)
- j += c->enctype;
- else if(c->enctype == Eesb){
+ d = iadrive[j];
+ c = d->ctlr;
+ if(map[c - iactlr] == 0)
+ j++;
+ else
+ if(c->enctype == Eesb){
blinkesb(c, i);
j += c->ndrive;
}else{
- d = iadrive[j++];
blink(d, i);
+ j++;
}
}
t1 = Ticks;
--
cinap
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9front] ahci led: reset spins.
@ 2019-11-17 4:52 ori
0 siblings, 0 replies; 3+ messages in thread
From: ori @ 2019-11-17 4:52 UTC (permalink / raw)
To: 9front
> On one of my machines, there was aa fairly constant load from the
> ialed kproc, because it was stuck in a loop resetting the ahci
> controller. The controller never came back.
Oh, and obviously, if anyone has ideas on how to convince the
controller to come back, that would be even better :)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-11-17 21:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-17 21:19 [9front] ahci led: reset spins ori
-- strict thread matches above, loose matches on Subject: below --
2019-11-17 20:10 cinap_lenrek
2019-11-17 4:52 ori
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).