9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Miller's 9pi image (rpi4) problems
@ 2021-06-10 18:59 adr via 9fans
  2021-06-11  9:05 ` Richard Miller
  2021-06-13 17:22 ` [9fans] " adr via 9fans
  0 siblings, 2 replies; 13+ messages in thread
From: adr via 9fans @ 2021-06-10 18:59 UTC (permalink / raw)
  To: 9fans

First of all, hello to everyone.

I've been using 9front attracted by the aarch64 support, not so
much by the 64 bit words but by the registers at hand.

I got problems with cwfs: the name length limit hardcoded at
compile time, impossibility of disk usage statistics for the "other"
partition (in a file system which is going to crash when full...)
and some file corruption when halting in a usb disk still reading
from the buffer. I don't feel comfortable using an experimental fs
like hjfs.

I used Plan9 almost a decade ago. I remember using fossil+venti
and been quite happy (after some bug was discovered). I'm using
only arm computers now and is great to see the rpi4 supported, and
Richard Miller's image is almost a lab's distribution. So I renounced
to those precious free registers and gave it a try.

The biggest problem to me is the usb code.

First I'm using a kvm switch so there are a lot of attachments-detachments.
At a certain point it will end with "No slots available" and the
usb will became unusable. For me is a labyrinth, but I'm pretty sure
someone with more experience with the system could fix it.

There is something wrong with the code responsible of managing and
monitoring the power of the ports. This is going to be more
complicated. It is impossible to use any usb disk. I managed to
make one appear connecting it to one of the usb2 ports and powering
the usb disk externally before turning on the pi (the system crashed
several times when I powered the disk with the os running), but it
was useless:

usb/disk: startdevs: opening #0 /dev/usb/ep5.0
usb/disk: devmain: disk: endpoints not found
usb/disk: no unhandled devices found

The other issue important to me is with webfs:
webfs: tlsClient: fd out of range or not open

So no abaco for me, almost every page I try to load ends up with
this error. I installed a recent go and compiled opossum, but
at this point is unusable, at least for me.

I've had horrible usb related experiences with openbsd and netbsd
since the beginning of time, so it really surprised me the stability
of the 9front usb system.

Sorry I can only report this at the moment.

Regards,
adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M542f01bc62388a7ac295c914
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-10 18:59 [9fans] Miller's 9pi image (rpi4) problems adr via 9fans
@ 2021-06-11  9:05 ` Richard Miller
  2021-06-11  9:14   ` Richard Miller
  2021-06-13 17:22 ` [9fans] " adr via 9fans
  1 sibling, 1 reply; 13+ messages in thread
From: Richard Miller @ 2021-06-11  9:05 UTC (permalink / raw)
  To: 9fans

To be pedantic, the troubles you describe are not strictly "9pi image problems",
you will likely find that 4e Plan 9 on any architecture will behave the same.

The usb subsystem is known to be pretty rudimentary, and indeed with respect
to power management /sys/src/cmd/usb/usbd/usbd.c:/^portattach is headed by
this comment:
 * BUG: does not consider max. power avail.

Having said that, "It is impossible to use any usb disk" is possibly an
overstatement. Some disks will work, some won't. That's not necessarily
a power management problem. Steve Simon might want to comment here on
his experience with usb3 sata adapters. Some modern disks use the "UASP"
protocol in preference to the traditional bulk-only mass storage protocol
supported by the Plan 9 usbdisk driver. Even if the disk also supports
bulk-only, the existing driver won't try to pick an alternate configuration
to force the disk to fall back to that protocol. Below is a patch (tested on
only one drive, as far as I know) which will make it do that.

As for your reported problem with webfs:
> webfs: tlsClient: fd out of range or not open
what exactly did you do which raised this error? I don't usually use webfs, but
I've just tried it and made a successful tls connection to github with abaco.

--- /n/sources/plan9/sys/src/cmd/usb/lib/parse.c        Fri Jan  8 18:00:43 2010
+++ ./parse.c   Tue Mar 23 16:19:20 2021
@@ -66,6 +66,11 @@
        }
        if(c->iface[ifid] == nil)
                c->iface[ifid] = emallocz(sizeof(Iface), 1);
+       else{
+               /* hack to avoid unsupported uasp disk interface */
+               if(dip->bInterfaceClass == Clstorage && dip->bInterfaceProtocol != 0x50)
+                       return 0;
+       }
        ip = c->iface[ifid];
        class = dip->bInterfaceClass;
        subclass = dip->bInterfaceSubClass;
@@ -164,6 +169,7 @@
        Ep      *ep;
        Altc    *altc;
        char    *hd;
+       int     ok;
 
        assert(d != nil && c != nil);
        tot = 0;
@@ -174,6 +180,7 @@
                if(d->ddesc[nd] == nil)
                        break;
 
+       ok = 1;
        while(n > 2 && b[0] != 0 && b[0] <= n){
                len = b[0];
                if(usbdebug>1){
@@ -189,7 +196,7 @@
                        ddprint(2, "%s\tparsedesc: %r", argv0);
                        break;
                case Diface:
-                       if(parseiface(d, c, b, n, &ip, &altc) < 0){
+                       if((ok = parseiface(d, c, b, n, &ip, &altc)) < 0){
                                ddprint(2, "%s\tparsedesc: %r\n", argv0);
                                return -1;
                        }
@@ -199,6 +206,8 @@
                                werrstr("unexpected endpoint descriptor");
                                break;
                        }
+                       if(!ok)
+                               break;
                        if(parseendpt(d, c, ip, altc, b, n, &ep) < 0){
                                ddprint(2, "%s\tparsedesc: %r\n", argv0);
                                return -1;


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M6dab6711f8f1fe8c3d355322
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-11  9:05 ` Richard Miller
@ 2021-06-11  9:14   ` Richard Miller
  2021-06-11 14:38     ` adr via 9fans
  0 siblings, 1 reply; 13+ messages in thread
From: Richard Miller @ 2021-06-11  9:14 UTC (permalink / raw)
  To: 9fans

> Below is a patch ...

Something in the 9fans pathway has expanded the tabs in my patch into
8 spaces. Irritating. If you want to apply the patch, it will probably
be necessary to turn them back into tabs.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-Mb4b9ab27e18e7e91ce80002f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-11  9:14   ` Richard Miller
@ 2021-06-11 14:38     ` adr via 9fans
  2021-06-11 16:00       ` Richard Miller
  2021-06-11 16:13       ` adr via 9fans
  0 siblings, 2 replies; 13+ messages in thread
From: adr via 9fans @ 2021-06-11 14:38 UTC (permalink / raw)
  To: 9fans

> The usb subsystem is known to be pretty rudimentary, and indeed with respect
> to power management /sys/src/cmd/usb/usbd/usbd.c:/^portattach is headed by
> this comment:
>  * BUG: does not consider max. power avail.
> 
> Having said that, "It is impossible to use any usb disk" is possibly an
> overstatement.

Of course! I was talking about _me_ and  _my_disks_.

> Some disks will work, some won't. That's not necessarily
> a power management problem.

They are only recognized when powering them externally, and with
risk of freezing the system. Note also that usb3 devices are not
recognized on the usb3 ports (again...  I mean my usb3 devices).

> Some modern disks use the "UASP"
> protocol in preference to the traditional bulk-only mass storage protocol
> supported by the Plan 9 usbdisk driver. Even if the disk also supports
> bulk-only, the existing driver won't try to pick an alternate configuration
> to force the disk to fall back to that protocol. Below is a patch (tested on
> only one drive, as far as I know) which will make it do that.

Thanks, I'll give it a try.

> As for your reported problem with webfs:
> > webfs: tlsClient: fd out of range or not open
> what exactly did you do which raised this error? I don't usually use webfs, but
> I've just tried it and made a successful tls connection to github with abaco.

I can connect to github too, and some other places. But if you surf the web
you'll end up with this error. Just a few If you want to do a test:

https://developer.arm.com
https://wikipedia.org
https://marc.info
https://www.perseus.tufts.edu
http://mars.jpl.nasa.gov

Regards,
adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M3f483ca41f647ce8f0ff0d0a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-11 14:38     ` adr via 9fans
@ 2021-06-11 16:00       ` Richard Miller
  2021-06-11 16:13       ` adr via 9fans
  1 sibling, 0 replies; 13+ messages in thread
From: Richard Miller @ 2021-06-11 16:00 UTC (permalink / raw)
  To: 9fans

> I can connect to github too, and some other places. But if you surf the web
> you'll end up with this error. Just a few If you want to do a test:
> 
> https://developer.arm.com
> https://wikipedia.org
> https://marc.info
> https://www.perseus.tufts.edu
> http://mars.jpl.nasa.gov

Thanks, I did a test:

term% hget https://wikipedia.org
tlsClient: could not negotiate acceptable security parameters

What most of these sites have in common is that they allow only ECDHE key exchange
for tls1.2, which I think is not currently implemented in either 4e or 9legacy.

Any volunteers?

The last example is a weird one:

term% hget https://mars.jpl.nasa.gov
tlsClient: devtls expected ver=303, saw (len=2) type=15 ver=0 '\x15'

I'll let somebody else try to diagnose that!


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M6c2f870f7a6a43355b2f2cf1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-11 14:38     ` adr via 9fans
  2021-06-11 16:00       ` Richard Miller
@ 2021-06-11 16:13       ` adr via 9fans
  2021-06-11 16:26         ` Richard Miller
  1 sibling, 1 reply; 13+ messages in thread
From: adr via 9fans @ 2021-06-11 16:13 UTC (permalink / raw)
  To: 9fans

> > Some modern disks use the "UASP"
> > protocol in preference to the traditional bulk-only mass storage protocol
> > supported by the Plan 9 usbdisk driver. Even if the disk also supports
> > bulk-only, the existing driver won't try to pick an alternate configuration
> > to force the disk to fall back to that protocol. Below is a patch (tested on
> > only one drive, as far as I know) which will make it do that.
> 
> Thanks, I'll give it a try.

No luck!, although the end points appear now after manually executing
usb/disk.

kprint when attaching the disk:
usb/disk... usb/hub... /boot/usbd: disk: disk: endpoints not found
usb/disk... 

; cat /dev/usb/ctl
ep1.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 0 port 0 rootport 0 addr 0 busy
roothub csp 0x000009 ports 1 xhci
ep2.0 enabled control rw speed super maxpkt 512 pollival 0 samplesz 0 hz 0 hub 0 port 0 rootport 0 addr 0 busy
roothub csp 0x000009 ports 4 xhci
ep3.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 0 port 1 rootport 1 addr 1 busy
hub csp 0x010009 ports 4 none <nil> xhci
ep8.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 1 port 3 rootport 1 addr 6 busy
hub csp 0x020009 ports 4 'VIA Labs, Inc.         ' 'USB2.0 Hub             ' xhci
ep5.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 1 port 4 rootport 1 addr 3 busy
hub csp 0x010009 ports 4 'USB Device  ' 'USB 2.0 Hub            ' xhci
ep6.0 enabled control rw speed low maxpkt 8 pollival 0 samplesz 0 hz 0 hub 3 port 1 rootport 1 addr 4 busy
hid csp 0x020103 vid 0x1c4f did 0x0078 SIGMACHIP 'SG 2.4G Wireless Mouse' xhci
ep6.2 enabled interrupt r speed low maxpkt 8 pollival 10 samplesz 0 hz 0 hub 3 port 1 rootport 1 addr 4 busy
ep7.0 enabled control rw speed low maxpkt 8 pollival 0 samplesz 0 hz 0 hub 3 port 2 rootport 1 addr 5 busy
hid csp 0x010103 csp 0x000003 vid 0x0c45 did 0x9510 S U xhci
ep7.1 enabled interrupt r speed low maxpkt 8 pollival 10 samplesz 0 hz 0 hub 3 port 2 rootport 1 addr 5 busy
ep9.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 6 port 3 rootport 1 addr 8 idle
storage csp 0x500608 csp 0x620608 vid 0x0bc2 did 0xaa14 Seagate Basic xhci

; usb/disk -dD /dev/usb/ep9.0
usb/disk: fsioproc pid 332
<- Tversion tag 65535 msize 8216 version '9P2000'
-> Rversion tag 65535 msize 8216 version '9P2000'
<- Tauth tag 12 afid 394 uname adr aname 
-> Rerror tag 12 ename permission denied
<- Tattach tag 12 fid 394 afid -1 uname adr aname 
-> Rattach tag 12 qid (0000000000000000 0 d)
usb/disk: startdevs: opening #0 /dev/usb/ep9.0
usb/disk: opendev 0x4e5d8 /dev/usb/ep9.0
usb/disk: /dev/usb/ep9.0 csp storage.6.80 vid 0xbc2 did 0xaa14 refs 1
        Seagate Basic 00000000NABC5SSF
        conf: cval 1 attrib 80 500 mA
                iface csp storage.6.80
                  alt 0 attr 2 ival 0
disk: ep ids: in 1 out 2
usb/disk: opendev 0x50d98 /dev/usb/ep9.1
usb/disk: /dev/usb/ep9.1: maxpkt 512
usb/disk: /dev/usb/ep9.1: ntds 1
usb/disk: opendev 0x50e58 /dev/usb/ep9.2
usb/disk: /dev/usb/ep9.2: maxpkt 512
usb/disk: /dev/usb/ep9.2: ntds 1
disk: ep in /dev/usb/ep9.1 out /dev/usb/ep9.2
disk: /dev/usb/ep9.0: maxlun 0
disk: cmd: tag 0x1:  12 00 00 00 ff 00 datalen: 255
disk: data: 76 bytes
disk: status: 00 residue: 179
disk: cmd: tag 0x2:  1b 00 00 00 01 00 datalen: 0
disk: status: 00 residue: 0
disk: cmd: tag 0x3:  25 00 00 00 00 00 00 00 00 00 datalen: 8
disk: data: 8 bytes
disk: status: 00 residue: 0
disk: cmd: tag 0x4:  9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00 datalen: 32
disk: data: 32 bytes
disk: status: 00 residue: 0
disk: logical block size 512, # blocks 7814037167
usb/disk: fsadd sdU9.0

; ls /dev/sd*
/dev/sdM0/ctl
/dev/sdM0/data
/dev/sdM0/dos
/dev/sdM0/fossil
/dev/sdM0/nvram
/dev/sdM0/plan9
/dev/sdM0/raw
/dev/sdctl

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M8ba5098a8a830998e7df9632
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-11 16:13       ` adr via 9fans
@ 2021-06-11 16:26         ` Richard Miller
  2021-06-11 17:57           ` adr via 9fans
  0 siblings, 1 reply; 13+ messages in thread
From: Richard Miller @ 2021-06-11 16:26 UTC (permalink / raw)
  To: 9fans

> No luck!, although the end points appear now after manually executing
> usb/disk.
> ...
> disk: logical block size 512, # blocks 7814037167
> usb/disk: fsadd sdU9.0

Once you've reached that point, it looks like the driver is handling the disk ok.
But despite the message you won't see it in /dev/sdU9.0 when starting usb/disk
manually, because the usb device namespace appears someplace else ... I can't
recall where just now. (9front does this in a different and better way.)

What I would do is update /$objtype/bin/usb/usbd from the patched source and
rebuild the kernel with that.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-Mae77f41e7bae7351d33d0b4a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-11 16:26         ` Richard Miller
@ 2021-06-11 17:57           ` adr via 9fans
  2021-06-11 18:18             ` Richard Miller
  0 siblings, 1 reply; 13+ messages in thread
From: adr via 9fans @ 2021-06-11 17:57 UTC (permalink / raw)
  To: 9fans

On Fri, Jun 11, 2021 at 05:26:46PM +0100, Richard Miller wrote:
> > No luck!, although the end points appear now after manually executing
> > usb/disk.
> > ...
> > disk: logical block size 512, # blocks 7814037167
> > usb/disk: fsadd sdU9.0
> 
> Once you've reached that point, it looks like the driver is handling the disk ok.
> But despite the message you won't see it in /dev/sdU9.0 when starting usb/disk
> manually, because the usb device namespace appears someplace else ... I can't
> recall where just now. (9front does this in a different and better way.)
> 
> What I would do is update /$objtype/bin/usb/usbd from the patched source and
> rebuild the kernel with that.

I did it, now the sd disk appears in /dev, but I can't set up the
plan9 partitions:

; diskparts /dev/sdU0.0
; ls /dev/sdU0.0
/dev/sdU0.0/ctl
/dev/sdU0.0/data
/dev/sdU0.0/raw

; fdisk /dev/sdU0.0/data
cylinder = 8225280 bytes
   p1                       0 50            (50 cylinders, 392.21 MB) FAT32
   p2                      50 219051        (219001 cylinders, 1.63 TB) PLAN9
   empty               219051 486401        (267350 cylinders, 2.00 TB) 

; fdisk -p /dev/sdU0.0/data
part dos 63 803250
part plan9 803250 3519064769

; fdisk -p /dev/sdU0.0/data >/dev/sdU0.0/ctl
; ls /dev/sdU0.0
/dev/sdU0.0/ctl
/dev/sdU0.0/data
/dev/sdU0.0/raw

Thanks anyway.
adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-Mfef8a206570c443d88f25eaf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-11 17:57           ` adr via 9fans
@ 2021-06-11 18:18             ` Richard Miller
  2021-06-11 18:50               ` a
                                 ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Richard Miller @ 2021-06-11 18:18 UTC (permalink / raw)
  To: 9fans

I said:
> But despite the message you won't see it in /dev/sdU9.0 when starting usb/disk

I remember now: just do 'usb/disk -m /dev' to get the sdUX.Y mounted where you want.

adr said:
>now the sd disk appears in /dev, but I can't set up the
>plan9 partitions:
> ...
>Thanks anyway.

If you're used to 9front, you'll be having all sorts of little surprises.
It may be easy to jump to the conclusion "9front can do X, plan 9 can't",
but sometimes the situation is "9front does it this way, plan 9 does it that way".

This usb/disk doesn't have its own partition manager, because there's an
independent one which does the job: see partfs(8) for how to use it.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-Md4334ead3aa0f65f028a8a80
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-11 18:18             ` Richard Miller
@ 2021-06-11 18:50               ` a
  2021-06-11 19:10               ` hiro
  2021-06-11 21:07               ` adr via 9fans
  2 siblings, 0 replies; 13+ messages in thread
From: a @ 2021-06-11 18:50 UTC (permalink / raw)
  To: 9fans

FWIW, here's an excerpt from my /cfg/sysname/termrc which i use to
start an extra fossil. The disk is a large (10TB from memory) WD Elements
connected to one of the USB2 ports. I don't yet start the venti
automatically because i keep remaking it to try different
configurations, but it runs fine.


# If the big WD Elements is attached, make it available.
# Not sure this is the best thing to grep for.
if (grep -s 25A3 /dev/sdU0.0/ctl) {
        disk/partfs /dev/sdU0.0/data
        disk/fdisk -p /dev/sdXX/data > /dev/sdXX/ctl
        disk/prep -p /dev/sdXX/plan9 > /dev/sdXX/ctl
        fossil/fossil -f /dev/sdXX/fossil
        # pending: venti/venti -c /dev/sdXX/arenas
} &

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M056ecea764cfb32c59c223ea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-11 18:18             ` Richard Miller
  2021-06-11 18:50               ` a
@ 2021-06-11 19:10               ` hiro
  2021-06-11 21:07               ` adr via 9fans
  2 siblings, 0 replies; 13+ messages in thread
From: hiro @ 2021-06-11 19:10 UTC (permalink / raw)
  To: 9fans

> It may be easy to jump to the conclusion "9front can do X, plan 9 can't",
> but sometimes the situation is "9front does it this way, plan 9 does it that
> way".

yep, and sometimes 9front does it some way, while 4e doesn't do it in any way.
and sometimes 4e does it some way and 9front doesn't do it at all due
to unmaintainable unstable code (that's why we went back to cwfs).

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-Me3bd29c91ff40fcfa8d8dc75
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [9fans] Miller's 9pi image (rpi4) problems
  2021-06-11 18:18             ` Richard Miller
  2021-06-11 18:50               ` a
  2021-06-11 19:10               ` hiro
@ 2021-06-11 21:07               ` adr via 9fans
  2 siblings, 0 replies; 13+ messages in thread
From: adr via 9fans @ 2021-06-11 21:07 UTC (permalink / raw)
  To: 9fans

Now all is making sense. The tricky part will be configuring it at
boot time to make it the root file system...

Thanks a lot to both of you for the help, specially to you Richard.

Regards,
adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-Mb753391a9ced7ec824874c59
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [9fans] Re: Miller's 9pi image (rpi4) problems
  2021-06-10 18:59 [9fans] Miller's 9pi image (rpi4) problems adr via 9fans
  2021-06-11  9:05 ` Richard Miller
@ 2021-06-13 17:22 ` adr via 9fans
  1 sibling, 0 replies; 13+ messages in thread
From: adr via 9fans @ 2021-06-13 17:22 UTC (permalink / raw)
  To: 9fans

> The biggest problem to me is the usb code.
> 
> First I'm using a kvm switch so there are a lot of attachments-detachments.
> At a certain point it will end with "No slots available" and the
> usb will became unusable. For me is a labyrinth, but I'm pretty sure
> someone with more experience with the system could fix it.

I found how 9front fixed this:

--- /n/sources/contrib/miller/9/bcm/devusb.c    Wed Sep 18 16:02:39 2019
+++ devusb.c    Sun Jun 13 16:21:28 2021
@@ -389,6 +389,10 @@
                if(ep->ep0 != ep){
                        putep(ep->ep0);
                        ep->ep0 = nil;
+               } else if(d != nil){
+                       if(d->free != nil)
+                               (*d->free)(d->aux);
+                       free(d);
                }
                free(ep->info);
                free(ep->name);

I can't understand the code yet, but my impression is that the
original intention was to not free the slot by default when a device
is detached, not allocate a new one if the same device is reconnected
but reused the old one, and free the unused slots when some time
has passed or if there is no one available.  But what the code is
doing is allocating a new slot every time a new device is attached
and what this hack does is free the corresponded slot every time
a device is detached.

Regards,
adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M5713a1f8ec63663d9aeae58e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-06-13 17:22 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-10 18:59 [9fans] Miller's 9pi image (rpi4) problems adr via 9fans
2021-06-11  9:05 ` Richard Miller
2021-06-11  9:14   ` Richard Miller
2021-06-11 14:38     ` adr via 9fans
2021-06-11 16:00       ` Richard Miller
2021-06-11 16:13       ` adr via 9fans
2021-06-11 16:26         ` Richard Miller
2021-06-11 17:57           ` adr via 9fans
2021-06-11 18:18             ` Richard Miller
2021-06-11 18:50               ` a
2021-06-11 19:10               ` hiro
2021-06-11 21:07               ` adr via 9fans
2021-06-13 17:22 ` [9fans] " adr via 9fans

9fans - fans of the OS Plan 9 from Bell Labs

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/9fans

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9fans 9fans/ http://inbox.vuxu.org/9fans \
		9fans@9fans.net
	public-inbox-index 9fans

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9fans


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git