Re: [9fans] fossil
Noam Preil: > I have a > branch at https://git.sr.ht/~pixelherodev/plan9 which has fossil > integrated. I took the liberty of having a look at the fossil source in that repo. It seems to be missing the fossil-time-backward patch. That's on the current 9legacy distribution ISO (built 14 April 2023), and probably on several previous ones as it went into the 9legacy git in April 2022. It's a two-line patch which fixes a bug where the periodic sync process can stop working if the system clock goes backwards. The consequences of that are failure to update on-disk file data, and exhaustion of the in-memory cache buffers which results in deadlock. From memory, I think it could also make the sync process go into a 100% cpu loop which might look like deadlock. If you apply that patch, I hope that you will find some of the problems you've been observing will be cleared up. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbbcec90e3dd997e1-M2a3d10ef36b09cf392eda1c2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] fossil [was: List of companies that use Plan 9.]
Noam Preil: > I demonstrated one > of the problems with fossil by (attempting to) install Go, which crashes > the file system _every single time_. This is a useful bit of evidence that needs following up. The go test suite (which begins by installing and completely rebuilding go) is running 24/7 on a cluster of Raspberry Pi machines in my front hall, using fossil from 9legacy source. If you look in the plan9 arm column on https://build.golang.org you can click on any 'ok' entry (and nearly any 'fail' entry) and you'll see a successful installation of go on fossil ... literally thousands of them if you follow the sequence of 'older' pages. If you get in touch with me off list, I'd really like to work with you to find out what is different between my environment and yours which leads to such different observations. My principal reason for running the go tests has been to try to shake out more bugs from Plan 9 and fossil. So any other replicatable data I can get is most welcome. > I have found multiple deadlocks over the last few years, and only > bothered fixing one of them. In a discussion on 9fans in April 2023, the fossil-deadlocks.diff patch on 9legacy.org was mentioned. Have you witnessed any more deadlocks since you applied that one? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-Mfa75a342b512fd72b7c71720 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
Jacob Moody: > I'm very glad we were able to communicate this and thank you for taking > the time to talk about this here in this thread. And thanks to you for pointing me to the GTX 4090 and https://crack.sh Both real eye openers. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M2c85ac49e8d6a52c1732cc2c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] golang dependency on python3
me: >> (OK, I know that's delusional because I've installed go. But maybe >> not for much longer, as google seems determined to introduce python3 >> as a dependency.) Charles Forsyth: > wat!?? citation: https://github.com/golang/go/issues/62025 -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf65bc1d5ccdc425e-M67a81834c7b5494c98da1cfe Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
cro...@gmail.com: > As for the proposed strawman `p9sk3`, I fail to see what advantage > that would have over dp9ik My point was only about the advantage of p9sk3 over p9sk1, not to compare it with anything else. The intent was to counter the implication that p9sk1 is terrible and completely broken, by suggesting that the threat of brute-forcing the entire keyspace can be mitigated with a small, local and very easy to understand variation to the ticket service (with no change to the protocol on-the-wire). Of course it doesn't mitigate the problem of users negligently choosing weak passwords. dp9ik has the extra advantage of doing that too, by removing the opportunity for offline dictionary attacks. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M86b283cc4c651efabdf9c3da Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
me: >> I try to take a >> minimum-intervention approach ... cro...@gmail.com: > Forgive my saying it, Richard, but I think this is a somewhat overly > staid view of things. You're welcome to say it. My minimalist attitude amounts to a religion, and therefore I don't need to justify it ☺. I know I'm at one extreme end of the scale. None of my machines are even running 9legacy, it's all 4th edition with enough hand-picked patches to make it useable for me. I wouldn't dream of pushing anyone else to follow my example. But personally, my Plan 9 network is a refuge from 21st century complexity, where I can in theory read and understand the infrastructure from top to bottom. (OK, I know that's delusional because I've installed go. But maybe not for much longer, as google seems determined to introduce python3 as a dependency.) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M7407b85b6cdcbb4f959b4ae9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
23h...@gmail.com: > ... the server and client keys are the > same in p9sk1 as far as i understood. i would welcome public/private > key system though (is that what you were thinking of when separating > "server key" and "client key". that would add yet another set of > features that are currently missing. Have a look at authsrv(6) in the manual. The authenticator sends a pair of tickets to the client, one encrypted with the client's own key and one encrypted with the server's key. That's what allows both the client and server to authenticate each other. 23h...@gmail.com: > ... it seems to me that > concentrating on 3DES just for the sake of similarity to DES is taking > ocam's razor slightly too far. Yes, I think you're probably right. I was thinking in terms of minimum lines of code to change, but other factors are also important. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-Mbc9a161e11837e5c464b2cd7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
Jacob and Ori, thank you for filling in some more details. Without the specifics I had been making some wrong assumptions about where the exact threat was. I think I now have a clearer picture: It's not particularly p9sk1 which is vulnerable, but the protocol for ticket request / response, which leaks enough information to allow offline exploration of user keys. The contribution of p9sk1 is that its handshake protocol helpfully reveals a valid user name - ie the authid - which can be used by an attacker to make a legitimate ticket request, without any need for eavesdropping or guessing at user names. So, if you have an authentication service exposed to the ipv4 internet (or to the ipv6 internet with a findable address), and your authid or a known or guessable userid has a weak enough password to succumb to a dictionary search, it's probably right to say that a random attacker could make a cpu connection or mount your file service with an afternoon's work on consumer hardware. Nobody needs to have weak passwords, though. Using the !hex attribute instead of !password with factotum, and/or using secstore(1), makes it easy to have a randomly generated DES key with the full 56 bits of entropy. This makes the attacker do more work ... but not all that much more. I hadn't kept up with how powerful commodity GPUs have become. (My most recent experience with High Performance Computing involved transputer arrays and Cray T3Ds. Nowadays I specialise in low performance computing.) It appears that investment of a few thousand dollars and a few days compute time (maybe less if using cloud services) is enough for a full brute-force exploration of the single-DES keyspace. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M2867926d1deafb39060269df Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
23h...@gmail.com: > sorry for ignoring your ideas about a p9sk3, but is your mentioning of > ocam's razor implying that dp9ik is too complicated? > is there any other reason to stick with DES instead of AES in > particular? i'm not a cryptographer by any means, but just curious. My comments are about p9sk1; I'm not implying anything about other algorithms. When working with other people's software, whether professionally or for my own purposes, I try to take a minimum-intervention approach: because it's respectful, because of Occam's Razor, because of Tony Hoare's observation that software can be either so simple that it obviously has no bugs, or so complicated that it has no obvious bugs. I thought of 3DES in the first instance because of this desire to be minimally disruptive. Support for DES is already there and tested. 3DES only needs extra keys in /mnt/keys, and because 3DES encryption with all three keys the same becomes single DES, there's a graceful fallback when users have access only via an older client with unmodified p9sk1. Obviously the server ticket would always be protected by 3DES. This is only the first scratching of an idea, not implemented yet. I've got nothing against AES. I'm not a cryptographer either, but I did once have to build a javacard implementation for a proprietary smartcard which involved a lot of crypto infrastructure, and had to pass EMV certification. Naturally that needed AES, elliptic curves, and plenty of other esoterica to fit in with the existing environment and specifications. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M2003e6b5eb34ea3270a33bec Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] one weird trick to break p9sk1 ?
I'm using a new subject [was: Interoperating between 9legacy and 9front] in the hope of continuing discussion of the vulnerability of p9sk1 without too many other distractions. mo...@posixcafe.org said: > If we agree that: > > 1) p9sk1 allows the shared secret to be brute-forced offline. > 2) The average consumer machine is fast enough to make a large amount of > attempts in a short time, >in other words triple DES is not computationally hard to brute force these > days. > > I don't know how you don't see how this is trivial to do. I agree that 1) is true, but I don't think it's serious. The shared secret is only valid for the current session, so by the time it's brute forced, it may be too late to use. I think the bad vulnerability is that the ticket request and response can be used offline to brute force the (more permanent) DES keys of the client and server. Provided, of course, that the random teenager somehow is able to listen in on the conversation between my p9sk1 clients and servers. On the other hand, it's hard to know whether to agree or disagree with 2), without knowing exactly what is meant by "large amount", "short time", "computationally hard", and "trivial". When Jacob told me at IWP9 in Waterloo that p9sk1 had been broken, not just theoretically but in practice, I was looking forward to seeing publication of the details. Ori's recent claim in 9fans seemed more specific: > From: o...@eigenstate.org > ... > keep in mind that it can literally be brute forced in an > afternoon by a teenager; even a gpu isn't needed to do > this in a reasonable amount of time. I was hoping for a citation to the experimental result Ori's claim was based on. If the "it" which can be brute forced refers to p9sk1, it would be very interesting to learn if there are flaws in the algorithm which will allow it to be broken without breaking DES. My assumption was that "it" was referring simply to brute forcing DES keys with a known-plaintext attack. In that case, a back of the envelope calculation can help us to judge whether the "in an afternoon" claim is plausible. In an afternoon from noon to 6pm, there are 6*60*60 seconds. To crack a single DES key by brute force, we'd expect to have to search on average half the 56-bit key space, performing about 2^55 DES encryptions. So how fast would the teenager's computer have to be? cpu% hoc 2^55/(6*60*60) 1667999861989 1/_ 5.995204332976e-13 1667 billion DES encryptions per second, or less than a picosecond per encryption. I think just enumerating the keys at that speed would be quite a challenge for "the average consumer machine" (even with a GPU). A bit of googling for actual results on DES brute force brings up https://www.sciencedirect.com/science/article/abs/pii/S138376212266 from March 2022, which says: "Our best optimizations provided 3.87 billion key searches per second for Des/3des ... on an RTX 3070 GPU." So even with a GPU, the expected time to crack a random 56-bit key would be something like: cpu% hoc 2^55/3.87e9 9309766.671567 _/(60*60*24) 107.7519290691 More than three months. The same paper mentions someone else's purpose-built machine called RIVYERA which "uses 128 Xilinx Spartan-6 LX150 FPGAs ... can try 691 billion Des keys in a second ... costs around 100,000 Euros". Still not quite fast enough to break a key in an afternoon. When Jacob says "triple DES is not computationally hard to brute force these days", I assume this is just a slip of the keyboard, since p9sk1 uses only single DES. But if we are worried about the shaky foundations of p9sk1 being based on single DES, Occam's Razor indicates that we should look for the minimal and simplest possible extension to p9sk1 to mitigate the brute force threat. The manual entry for des(2) suggests that the Plan 9 authors were already thinking along these lines: BUGS Single DES can be realistically broken by brute-force; its 56-bit key is just too short. It should not be used in new code, which should probably use aes(2) instead, or at least triple DES. Let's postulate a p9sk3 which is identical to p9sk1 except that it encrypts the ticket responses using 3DES instead of DES. The effective keyspace of 3DES is considered to be 112 bits because of the theoretical meet-in-the-middle attack. So brute forcing a 3DES key with commodity hardware (including GPU) would be expected to take something like: cpu% hoc 2^111/3.87e9 6.708393874076e+23 _/(60*60*24*365.25) 2.125761741728e+16 That's quadrillions of years. Not what most people would call "trivial". And that's generously assuming the implementation of meet-in-the-middle is zero cost. Without meet-in-the-middle, we're looking at a 168-bit keyspace and an even more preposterous number of years. I was looking forward to the "proof of concept". Even if we can't see the det
Re: [9fans] Interoperating between 9legacy and 9front
> From: o...@eigenstate.org > ... > keep in mind that it can literally be brute forced in an > afternoon by a teenager; even a gpu isn't needed to do > this in a reasonable amount of time. [citation needed] -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M7d533ce99e6dd4d6b157f0e0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9fat: on rmiller raspberry pi image?
The SD card has a dos partition, not a 9fat partition, so unless your raspberry pi has a usb hard drive the 9fat: command won't work. Instead you can use the c: command, which mounts the first dos partition it finds onto /n/c -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc0393eacdd79b3ac-M5df2016a623e1c67b44cf20f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] disk/prep partitioning issue
> Tried it; output: > syntax error reading partition > 488 > > So my partition count is too much, correct? Correct. The last line has been truncated at the end of the block so it has no newline, which is a syntax error. It's ok to use fdisk to create more than one plan9 partition on a disk. They'll appear as /dev/sd*/plan9, /dev/sd*/plan9.1 etc. Then you can use prep to put some of your arenas on each plan9 partition, to avoid overflowing the partition tables. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T798ae549700d1ad5-M2591dfe674a68c1b200aeca1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] disk/prep partitioning issue
I said: > You might have to split it up > into two fdisk partitions, or shorten some names. Actually, shortening names isn't likely to help much. If you're setting up a new venti, not expanding an existing one, could you make the arena partitions fewer and larger? The original idea behind limiting arena size was so that they could be conveniently backed up onto optical media, but I suspect nobody does that any more. Nowadays large arenas can be backed up onto a big USB flash drive, or onto another venti server. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T798ae549700d1ad5-Ma377c9908c8c5533e3ccca0b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] disk/prep partitioning issue
> ... > the bloom, isect7 and arenas7 partition are gone. > ... > What's causing that? The partition table has to fit in one disk sector. Has yours got bigger than 512 bytes? You might have to split it up into two fdisk partitions, or shorten some names. Try 'disk/prep -p /dev/sdE0/plan9 | wc -c' -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T798ae549700d1ad5-Mffe2a9371294cdca649ead2f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] cmdline.txt for RPi 4 with QHD screen
> We do not provide the binary files ourselves you need to acquire them from > the rasbian ISO. Or look in https://github.com/RPi-Distro/firmware-nonfree/raw/buster/brcm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-Md799ead1babe0a73392e20e7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Thumb compiler oddity
> In the meantime, I turned off "registerization" for files that could > potentially have similar code. If you want a more targeted workaround without a performance cost, in the example you posted you can force the compiler to reload the register by replacing return y; with return *(&y); -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te51716f70e2f8d84-Mba30ec1abcb7b7acbb79cc8b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Thumb compiler oddity
> Is the problem with the compiler or with the C code? It's a compiler error. The function mkvar() in reg.c is keeping track of unique variables without taking address aliasing into account. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf0ca316e4ef39fda-Mf87e4ea6cfb92bad9b8a1d7a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Go arm builder's image
> Last thing about your rpi image Richard, Is this the > one used in the go arm builders? Can I asume that > these are the only patches needed to have a working go? > Yes, and yes. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3dbd3cda56f638ee-M52ab001ba7b43f68f46d09be Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
On Thursday, 14 September 2023, adr via 9fans <9fans@9fans.net> wrote: Hi Richard. I'm surprised by the small number of 9legacy patches you are > using. Any reason in particular that you could share? I'm preparing a new > installation and this is a good time to choose the starting point. > > The 9pi image is intended as a close approximation to the 4th edition, adapted for the Raspberry Pi. For practical daily use I'd recommend the 9legacy SD image instead. The 9legacy.org site has a build script showing how that is made, starting from the 9legacy CD image, The actual 9pi.img.gz on contrib is a "golden" > copy which I've been updating with individual patches since about 2012 > > > Do you mean other patches than the ones you shared with 9legacy? > No, they are the exact same patches. I meant that each patch has been applied only once, so the source file modification times show when the patch was done, not when the SD image was made. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-Mae18a741bedf77dd602953ab Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
> the system loads into the GUI but then hangs moments later and stops > updating the frame buffer, or the system is hung. Any thoughts on why that > might have occurred? Is this to do with the watchdog...? It won't be the watchdog, because this QEMU patch prevents it from being enabled. archbcm2.c: 225c225 < addclock0link(wdogfeed, HZ); --- > //addclock0link(wdogfeed, 1000); -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-Macf52942455e106b08c9cd5b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
> The thing about 9legacy is I'm not sure what patches to pull and what is or > isn't stable do you have any recommendations? I've put a script in contrib/miller/build-9pi.rc which shows the complete process of building (almost) the 9pi image from the 4th edition ISO. You can look at that to see what 9legacy patches are applied. The "almost" is because applying the patches each time the image is built loses some useful metadata. The actual 9pi.img.gz on contrib is a "golden" copy which I've been updating with individual patches since about 2012, so the modification dates on source files can be used to see what has changed an when. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-M6e7469bcf7263ca55ec33053 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
> Based on the diffs you supplied, it looks like my bcm > sources (from the latest r4 ISO) are not the same as yours. I don't use > 9front. What is the best way to make sure my bcm (and 9) kernel trees are > the same as your current tree? A lot has changed in the bcm kernel since the 4th edition ISO, because of the release of newer Raspberry Pi models. Current source is in contrib/miller/9/bcm - just copy those files into /sys/src/9/bcm (or use the 9legacy ISO instead, which is kept up to date and has other useful patches too). -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-Me83a2442fc4a034b67c85cec Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
> I'm using version 8.0.0 of QEMU. What version are you using, Mr. Miller? I've now reinstalled QEMU from debian unstable, which gives me v8.0.4. Using the 9pi2.qemu in my contrib, it still boots for me, without any loop at 0x000c. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-Me1c683349a6d44bfe1f29dca Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
don.bai...@gmail.com: > Hmm, I've applied the patches and built the kernel. I can see the image > loaded at 0x8001, but it is spinning at address 0x000c; is this a > sdmmc load loop? I think that's a trap address. On ARM we re-map the trap vectors away from address 0 to a high segment. > I'm using version 8.0.0 of QEMU. What version are you using, Mr. Miller? Mine is 7.2.4 (just installed it on Debian 12). > Also, since the SD takes seconds to load and not ms/us, how long are you > waiting until you see something printed on the console...? After the 'Multiblock = 0' patch is applied, SD card transfers take about 2 milliseconds on my elderly thinkpad. > Curious if I'm > just running very slow, or if there is still something buggy going on... The trap is a bug which I'm not seeing. Do you get any console messages first? > Thanks for responding and adding some patches. I am trying to follow along > to make it work, if you don't mind a bit of back and forth :-) Maybe do the back & forth off list, unless anyone else is interested? -- Richard -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-M5bb97b8ca2aff6e9f980d601 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
don.bai...@gmail.com:
> So to get this back on the track of RPI emulated in QEMU … has anyone
> successfully used the Miller image with Q?
After a bit of experimentation, I have done so, for some value of
"successfully".
A few tweaks are required first, because QEMU's emulation of Pi hardware and
firmware is not as faithful as it might be:
- binary kernel file is loaded at 0x1, not 0x8000
- the watchdog timer doesn't work (or isn't there)
- system timer behaviour is a bit peculiar
- emulation of the SDMMC in multi-block mode is spectacularly slow
(transfers take not milliseconds but seconds)
After tweaking as shown below, a QEMU-compatible kernel can be built with
mk CONF'='pi2 9pi2.qemu
and run with something like
qemu-system-arm -M raspi2b -kernel 9pi2.qemu -serial stdio \
-drive file=9pi.img,if=sd,format=raw \
-append 'readparts=1 console=1 *ncpu=1 nobootprompt=local!/dev/sdM0/fossil'
For convenience I've put a kernel file on /n/sources/contrib/miller/9pi2.qemu
However ...
- the DWC usb host adapter of the Pi2/3 does not work the way Plan 9 expects
- therefore there's no functioning usb
- therefore I don't know how to attach a keyboard, mouse or network interface
If anybody wants to debug this further I'm happy to collaborate, but I'm
not sufficiently motivated to do it myself.
Diffs against files in /n/sources/contrib/miller/9/bcm, which I think are
identical to 9legacy 9/bcm sources):
mkfile:
85a86,90
> $p$CONF.qemu:DQ: $CONF.$O $OBJ $LIB
> $CC $CFLAGS '-DKERNDATE='`{date -n} $CONF.c
> echo '# linking kernel for QEMU'
> $LD -s -l -o $target -H6 -R4096 -T0x8001 $OBJ $CONF.$O $LIB
>
mem.h:
48c48
< #define KTZERO (KZERO+0x8000) /* kernel text start */
---
> #define KTZERO (KZERO+0x1) /* kernel text start */
archbcm2.c:
225c225
< addclock0link(wdogfeed, HZ);
---
> //addclock0link(wdogfeed, 1000);
sdmmc.c:
25c25
< Multiblock = 1,
---
> Multiblock = 0,
clock.c:
35c35
< MinPeriod = 10,
---
> MinPeriod = 100,
124c124
< u32int t0, t1, tstart, tend;
---
> u32int t0, t1, tstart;
142d141
< tend = tstart + 1;
145c144
< }while(tn->clo != tend);
---
> }while(tn->clo - tstart < 1);
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-M2edf6c6413ee49aaee761281
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] wctl
> ; read -c 72 /dev/wctl Or, if your chosen flavour of Plan 9 doesn't have the 'read -c' option, one of these will do: dd -if /dev/wctl -bs 72 -count 1 -quiet 1 syscall -o read 0 buf 72 [2]/dev/null -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf13f657beb7b12c0-Mdd9f3de6c6653fc343ffc333 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] kencc for 64 bit intel linux?
> Is there a version of kencc somewhere that can be easily built > and installed on Linux and used as a plain C compiler? > > I'd prefer for x86_64 but I'll take one that only compiles 32 bit. https://github.com/inferno-os/inferno-os/tree/master/utils/6c There are also various forks on github which keep the compilers and building utilities and throw away the rest of inferno. But it's reasonably easy just to do a standard inferno install, stopping at the stage where the cross-compiler has been built. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td066fba28f267517-Mc39075a723655a934b476c47 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pi4 USB '/boot/kfs' error
I said: > If you want to boot the pi4 completely from a USB drive, with no > SD card present (I've never tried this), you'll need an alternative > place for a fs(3) configuration (maybe in the built-in bootdir in > the kernel?), or the boot code will need tweaking to get the partfs(8) > partitions re-mounted at the right time. I've done a bit of experimenting, and did manage to boot a pi4 with only a usb drive and no SD card. It turns out that you can use the first part of the mbr sector on the usb drive to store the fs(3) configuration, ie fsconfig=/dev/sdU0.0/data in cmdline.txt -- as long as you don't have so many partitions that the config text overlaps the DOS partition information in the mbr (at offset 0x1be), the pi4 bootrom code will happily boot from the usb drive. I wouldn't suggest that PC users try this - a PC bios might be more strict about what's in the mbr. Booting without an SD card seems to have some rough edges. You get irritating error messages when startup procedures include /dev/sdM0 in the list of disks to look at, and the reboot(8) command doesn't work because the usb disk interface probably needs some soft-reset to be done before the pi bootrom can initialise it again. Even if you are primarily using a usb drive, booting from SD (or netbooting?) might still be preferable. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4cb044b1eee98e3e-M9a9b0a67789e2b67bf4b0cdd Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pi4 USB '/boot/kfs' error
> But many thanks for the fs(3) hint. I’m looking into it.
Apologies. To configure a usb disk using fs(3) at boot time, you need
this change to /sys/src/9/boot/local.c which hasn't gone into the
9legacy tree yet:
/sys/src/9/boot/local.c:277,286 - local.c:277,286
if(bind("#p", "/proc", MREPL) < 0)
fatal("bind #p");
bind("#S", "/dev", MAFTER);
- bind("#k", "/dev", MAFTER);
bind("#u", "/dev", MAFTER);
bind("#æ", "/dev", MAFTER);
mountusbparts();/* make partfs partitions visible again */
+ bind("#k", "/dev", MAFTER); /* /dev/fs config might refer to usb
disks */
if((fd = connectlocalfossil()) < 0)
fd = connectlocalkfs();
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T4cb044b1eee98e3e-M9b4ad2b3c2c1e1add529e1eb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pi4 USB '/boot/kfs' error
ma...@germteig.com: > I am running the Dec 22 9legacy on a machine, and now want to create a > bootable USB on it. > The USB is for a raspberry pi 4 4GB, acting as a standalone auth only. When you say "bootable USB", do you want to boot the pi4 without an SD card, and just a USB drive? If you're happy to have both SD card and USB drive, you can use the SD card to hold a DOS partition (with bootable kernel and cmdline.txt) and a fsconfig partition (to hold a partition configuration for a /dev/fs device (see fs(3)) which maps the USB drive. This is what I do to set up a pi4 file server with fossil on a SSD drive. My pi4 kernel config doesn't have partfs, fdisk and prep in the bootdir section, and does have fs in the dev section. The cmdline.txt is readparts=1 nvram=#S/sdM0/nvram fsconfig=#S/sdM0/fscfg bootargs=local!/dev/sdXX/fossil and the fscfg partition on the SD card looks like this (the fsdev: first line seems to be undocumented) fsdev: part sdXX/nvram /dev/sdU0.0/data 2096640 512 part sdXX/fossil /dev/sdU0.0/data 2097152 819200 part sdXX/swap /dev/sdU0.0/data 8194097152 204800 ... plus some other partitions for venti, etc I use the fs(3) device because I haven't been able to get partfs(8) to work at boot time. I think there may be a bug in /sys/src/9/boot where an extra re-mount is missed out. If you want to boot the pi4 completely from a USB drive, with no SD card present (I've never tried this), you'll need an alternative place for a fs(3) configuration (maybe in the built-in bootdir in the kernel?), or the boot code will need tweaking to get the partfs(8) partitions re-mounted at the right time. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4cb044b1eee98e3e-Mc9962f736d0b6ee6e0c0ad7b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] ramfs bug
Deleting an open file on ramfs(4) can have surpising results.
Here's how it's supposed to behave. When a file is removed, the
Ram struct which represents the in-memory file has its busy flag
reset, so a subsequent i/o will see that it's been deleted.
cpu% ramfs
cpu% echo this is x >/tmp/x
cpu% { sleep 10; cat } : file does not exist
However, before the i/o takes place, it's possible for another
file to be created and re-use the same Ram struct, setting
the busy flag again. The process which had the deleted file open
is now doing i/o to a different file, without any checks on its
permissions, exclusive use flag, etc.
cpu% ramfs
cpu% echo this is x >/tmp/x
cpu% { sleep 10; cat } /tmp/y
cpu% actually this is y
A simple fix is to add a reference count to the Ram struct, to
keep track of how many Fids point to it, and only allow a Ram to
be re-used if both busy==0 and ref==0. The new 9legacy patch
ramfs-refcount makes this change.
Note to 9front users: don't worry, your ramfs is a completely
different program using the 9p(2) library, which doesn't have
this flaw.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tc364b766ff6473bc-M52976e87f40d78ae095f576e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)
> I don't know any reliable server with good bandwidth serving without tls I am able to connect to your example arch.mirror.constant.com using both http and https. Something is going on with usb ethernet and tls which I don't understand. Could it be as simple as different block sizes interacting with the usb packet size? I modified hget -v option to print the number of reads in each second, as well as the original bytes-so-far and bytes-total. My internet wire speed is about 40 megabit/sec. Using the pi4 built-in ethernet, I see this: term% url=//arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2term% 5.hget -v -o /dev/null http:$url 1 1074 513671168 154 236298 513671168 1891 4664898 513671168 1885 9351954 513671168 1952 14040462 513671168 1948 18715902 513671168 1908 23411670 513671168 2035 28095822 513671168 1992 32781426 513671168 1995 37459770 513671168 1945 42146826 513671168 ... term% 5.hget -v -o /dev/null https:$url 1 1670 513671168 136 1113734 513671168 571 5791366 513671168 569 10452614 513671168 571 15130246 513671168 568 19783302 513671168 570 24452742 513671168 569 29113990 513671168 573 33808006 513671168 568 38461062 513671168 542 42901126 513671168 ... Using a 100Mb/s usb2 ether adapter on the same pi4, I see this: term% 5.hget -v -o /dev/null http:$url 1 1074 513671168 662 1261410 513671168 2129 5896194 513671168 2121 10525170 513671168 2259 15167214 513671168 2212 19804902 513671168 2223 24442590 513671168 2195 2911 513671168 2175 33800730 513671168 2197 38479074 513671168 2244 43164678 513671168 ... term% 5.hget -v -o /dev/null https:$url 1 1670 513671168 75 614022 513671168 132 1695366 513671168 2 1711750 513671168 4 1744518 513671168 128 2793094 513671168 10 2875014 513671168 24 3071622 513671168 98 3874438 513671168 4 3907206 513671168 130 4972166 513671168 ... Needs deeper investigation. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-Mbdc3913dcd77a8be18193e66 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)
> By the way Richard, should I take the last rpi image at 9legacy as > the more recent with your work? Are you going to abandon > https://plan9.io/sources/contrib/miller/? 9legacy should always have up to date patches for the Raspberry Pi, and the 9legacy SD card image will usually be fresher than the 9pi.img.gz image in contrib/miller. The only value now in the 9pi image is for historians: I've tried to conserve the metadata so it's possible to see when source files were most recently changed. On 9legacy, patches are re-applied when a distribution image is made, so mtime information is less informative. I will also continue to maintain the Pi kernel source in contrib/miller/9/bcm, where a more complete history can be seen: term% srv -n 9p.io sources post... term% history /n/sources/contrib/miller/9/bcm/etherusb.c Aug 3 13:16:49 BST 2022 /n/sources/contrib/miller/9/bcm/etherusb.c 8872 [miller] Jul 18 13:26:35 BST 2019 /n/sourcesdump/2022/0803/contrib/miller/9/bcm/etherusb.c [miller] Apr 4 17:04:17 BST 2018 /n/sourcesdump/2019/0718/contrib/miller/9/bcm/etherusb.c 8837 [bootes] Mar 4 21:18:17 GMT 2016 /n/sourcesdump/2018/0404/contrib/miller/9/bcm/etherusb.c 7878 [bootes] Jul 2 09:00:28 BST 2015 /n/sourcesdump/2016/0304/contrib/miller/9/bcm/etherusb.c 7838 [bootes] -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M67bb6396df945caf4d9c54df Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)
>> See the difference? That's a little more than 19Mb/s, some 2MiB/s almost 50% >> slower. > > That was a typo, is almost five times slower (~80% slower). Just > to be clear, it is really worst! Unless your "small arm linux machine" is a raspberry pi, you are changing too many variables to make a meaningful comparison. Benchmarking i/o across the internet will also introduce enough variation to suggest an experimental sample size of more than one attempt. An interesting set of experiments might be to run both linux and plan 9 on the pi4, try the built-in ether adapter and the usb dongle, and try fetching both from http:// and https:// (to see how much of the variation is due to tls decode speed). -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M421b620beeed0f3199881e28 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)
> Shouln't the usb type be documented in the ethernet section of plan9ini(8), It should be documented somewhere, but at present it's only implemented for the bcm kernel, and raspberry pi doesn't have a plan9.ini. (It sould be possible to move etherusb.c to /sys/src/9/port and use it on other platforms too. But it's a bit of an ugly hack.) Until rpi4, the built-in ethernet adapter on the raspberry pi was via usb, so 'ether0=type=usb' was the default and didn't need stating explicitly. The rpi4 has proper (non-usb) ethernet, so etherusb shouldn't be needed there except for niche situations (like a network appliance with multiple ethers?). > and noauto in usbd(4)? Yes it should. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M73cd87940d3916d92640771c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)
> So bad maxpkt... etherusb check for maxpkt < 512 which is the max for > bulk transfers in usb2 high speed. Using 1024 instead fixes the problem. Thanks, the code was correct when written but the world has moved on! Is your adapter transmitting packets successfully now? > Should it chek for the speed of the usb device and set the limit accordingly? Actually the limit on maxpkt in that context wasn't strictly necessary anyway. Just remove the check. diff /n/dump/2022/0802/sys/src/9/bcm/etherusb.c /sys/src/9/bcm/etherusb.c 328c328 < if(maxpkt < 8 || maxpkt > 512) --- > if(maxpkt < 8) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M7a798f1d29caac2cbe00034f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)
> Other programs expect the devices mounted in > /net. I'm binding the device inside a directory in /tmp and then > binding this directory to /net. I would appreciate if someone shares > the correct way of doing this. Two ideas come to mind: % mount -a /srv/usb /net (then all usb devices appear in /net as well as /dev) % aux/stub -d /net/etherU0 && bind /dev/etherU0 /net/etherU0 (for a single alias without extra clutter) But I think anything expecting a device in /net can be given an explicit alternative, eg % ip/ipconfig ether /dev/etherU0 [...params] Are there exceptions I'm missing? Note that we can even boot with a fileserver connection via usb ether by passing extra ipconfig args in cmdline.txt eg bootargs='tcp ether /dev/etherU0' (same thing with plan9.ini on other platforms, without the quotes) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M64be1cd32d8d81cd3dfcf1f0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)
What you're trying to do should work. I've just checked an ASIX usb2 ether dongle on a pi4 as '#l1', usbd recognises it and I can mount '#l1' on /net and configure it. I did have to add etherusb to the kernel config and rebuild first, as you did. The tricky part is that the real usb ether driver is /sys/src/cmd/usb/ether, which makes the device appear in /dev because that's the default directory where usbd mounts itself. (Use the -m flag for a different dir if you really want to.) The etherusb 'device' in the kernel is just a stub, which passes packets directly between the usb endpoint to the network interface, without having to go back and forth to the usb driver process. Just a performance shortcut; you can use a usb ether driver without etherusb but it's slower. When you start a usb ether driver, it tries a "bind" command with each of the '#l' ctl files in the kernel to see if one of them works as etherusb. If etherusb is configured in the kernel and enabled by a kernel parameter eg ether1=type=usb, the bind will succeed and link the '#l1' device with the usb ether driver which did the bind. You can then mount '#l1' on /net in the usual way and configure /net/ether1. You should see a kernel message when the etherusb and usb ether drivers link up, with the MAC address of the dongle. For instance I see etherusb asix: 000606e00ae7 This should happen whether usbd starts the driver automatically or you do it by hand with usb/ether. Do you get any interesting error messages if you try 'usb/ether -d' ? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-Mfe74a807004d1901910c0e32 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] LPAE patch for ARM
There's a new patch bcm-lpae which uses the 64-bit page table format to allow 32-bit ARM kernels to support more than 4GB of physical memory. At present this is mainly of interest for the 8GB Raspberry Pi 4, but there's nothing Pi-specific in the MMU code so it may have future application for bigger ARM systems. The LPAE page table format works on the Pi 2 and Pi 3 as well, where it may provide a wee performance improvement from simpler page fault handling. When building a bcm kernel, the choice of page descriptor format is determined by putting either 'mmu' or 'mmu64' in the 'misc' section of the config file. The patch has been applied in the current 9legacy SD card image for Raspberry Pi on http://9legacy.org/download.html, and also in the 9pi SD card image on http://9p.io/sources/contrib/miller (though nowadays for all practical purposes I recommend 9legacy as a better choice). If you just want to update the kernel, source is in http://9p.io/sources/contrib/miller/9/bcm as usual. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2b3e951db9f7c17f-Mbacd4cfcb29eca6dadc2a77a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] acme & sam text selection and delete deletes extra character
Sorry, I seem to have hit Post by accident. Too bad there isn't an Undo for that ... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf6b94eeff34dd2d7-M14a02dd591c5a573d33f2477 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] acme & sam text selection and delete deletes extra character
Hi there- Please pardon the dumb question if this has been covered before. I did some brief searches of the archive and couldn't find it... I'm running plan9port on macOS. I noticed that in acme, (and also sam) if I select part of a string and p delete, the selection gets deleted and also one additional character in front of the selection. For example, if I type "/path/to/file" and double-click file, file gets highlighted, and if I press delete, "/file" gets deleted leaving me with "path/to". This seems counter-intuitive as I expected only what I had highlighted to be deleted. There is a GitHub issue (#424) https://github.com/9fans/plan9port/issues/424 filed for this as well. Just curious, is this by design, or is this a bug? I'm inclined to think it's by design as it occurs within sam as well. As always, thanks!! -Ben -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf6b94eeff34dd2d7-M674a970ef824d9c5094cb3d7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] bluetooth
lyn...@orthanc.ca: > Bluetooth (and BLE) support woould be *very* nice to have. I have a native bluetooth host implementation for Plan 9, not ported from anything (it's written from scratch based on published bt specs.) I don't regard it as sufficiently debugged for a release ... it's missing some important error handling (mandatory retries to recover from poor reception) and it just plain doesn't work for some of the dongles I've tried. I don't know whether it's compatible with BLE (which didn't exist at the time I wrote it). Contact me off list if you'd like a copy. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T69704162cbe0c04a-Mf8839883c089cb58afb527cf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Problems installing 9legacy on bare metal (Thinkpad X60)
> !rc (and the rest of the boot) is one of the first things implemented > uniquely by 9front. I think there's a little bit of confusion about different stages of booting. The 9boot program loads the kernel. The original Plan 9 9boot is driven by configuration variables in a plan9.ini file. Cinap's rewritten 9boot adds the capability of interactively changing configuration variables from the console before loading the kernel. That's really useful, especially when experimenting with new kernels or new hardware. But 9boot does not contain a shell or a built-in file system, so it doesn't allow you to type !rc and get an interactive shell. Once the kernel is loaded, the first thing it does is to execute the command /boot/boot from a small root filesystem which is built into the kernel. The main job of /boot/boot is to attach to the real root filesystem (on a local device or from a network server) and execute /$cputype/init to start the system. Historically the usual case is for /boot/boot to be a specialised program built from C source in /sys/src/9/boot. But it has always been possible to configure a kernel with a shell script as /boot/boot - see for example /sys/lib/sysconfig/ppc/boot for the PowerPC, or /sys/src/9/bcm/bootwifi.rc for a Raspberry Pi accessing its root file server via wifi. So, using a shell script as /boot/boot is not unique to 9front. But with 9front, it has become the default. This means there's always a shell inside the kernel, along with a few commands, ready to use interactively when !rc is invoked - after the kernel is loaded, but before the final root filesystem is attached. The kernel on the 9legacy install CD doesn't have a shell script as /boot/boot with the ability to invoke !rc. Perhaps it should. But that wouldn't have helped in this case. Yakku was stuck at the 'Boot from' prompt within /9boot, unable to find a kernel to boot. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb5aaf646618a421a-M3a252d01292986d2f6699d46 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Problems installing 9legacy on bare metal (Thinkpad X60)
Hello Yakku - I couldn't reply to the email you sent me off-list. The returned error was "User unknown in virtual mailbox table" -- Richard -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb5aaf646618a421a-M6db08da236580ae316905718 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Problems installing 9legacy on bare metal (Thinkpad X60)
> Sorry that doesn't seem to work either. I've tried sdB0, sdB1, > sdC0, sdC1, sdD0, sdD1, sdE0, sdE1 . . . but the issue persists. That appears to be a dead end. To answer your earlier question, you could use dd (or pump(1)) to copy the usb image to your hard drive, if you're happy to sacrifice all the existing partitions on the hard drive. Or, for more control over the final configuration, you could create an empty fossil partition on the hard drive and copy the usb filesystem contents to it, using mkfs | mkext or replica/pull. Alternatively, I have an experimental 4e/9legacy installer which runs from a usb flash drive instead of a cdrom. It's been used successfully on an X230 and an X60s. If you get in touch with me off-list, I can give you a copy and some instructions. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb5aaf646618a421a-M4fcaebc812cb6735b5e11144 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Problems installing 9legacy on bare metal (Thinkpad X60)
> I've tried to boot via CD again (mind it's from a USB CD drive > in case that makes any difference) Yes, that makes a difference. It may appear as sdB0 or sdB1. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb5aaf646618a421a-M55a257ec05c874c88956ab89 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Problems installing 9legacy on bare metal (Thinkpad X60)
> I've also tried to boot it from a CD, but I always get stuck at the 'Boot > from:' prompt Try sdC0!cdboot!9pcflop.gz And local!/boot/bzroot for the root filesystem prompt. If your hard drive is configured in AHCI mode by the BIOS, it should be seen as sdE0. If it's in ATA compatibility mode, it should be sdC0 and the CD might be seen as sdD0. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb5aaf646618a421a-M7d3acb4b97fc1d07b04a2a58 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] tinyemu - riscv emulator
> In the meantime I have some low-level programming work with your compiler > and tinyemu running on a Raspberry Pi 2B. That's good to know. My original motivation for developing the riscv toolchain was to use in "bare metal" programming of riscv soft cores implemented on FPGA. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8096c17a051960c4-Mba98498318cdb17faaa7ceb3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] tinyemu - riscv emulator
> It can't find *9tecpu.bin*. > I presume that it's the Plan9 kernel. > Any suggestions as to what steps to take in order to generate it? Up to now the procedure for getting the 9k riscv kernel source is to ask its author (Geoff Collyer) for a copy. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8096c17a051960c4-Mad6ad16ae13be7e1ec1f1824 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] tinyemu - riscv emulator
> Self-inflicted confusion : I'm running 9vx and forgot that I was mk'ing an > emulator to run within an emulator. Part of the confusion was my fault: I should maybe have removed the Makefile (and other linux-only components) instead of leaving them in as reference material. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8096c17a051960c4-M69bf5c047358c797f99d25a8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] tinyemu - riscv emulator
> The make command failed with dependency on slirp module. I don't think plan 9 has a 'make' command. If you just run 'mk' on plan 9 in the tinyemu directory, it uses the mkfile there and there's no slirp dependency. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8096c17a051960c4-Mb62c7b61c0dab0cb680e446e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] tinyemu - riscv emulator
> I had difficulty in getting tinyEmu from contrib/miller/tinyemu.tar > working. Can you be a bit more specific about your difficulty? How far did you get, what exactly didn't work? To use networking, your Plan 9 kernel needs bridge(3) configured in. In tinyemu.tar there's an example bridge.rc script that shows how to set up a tunnel to bridge the tinyemu simulated network onto the real network. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8096c17a051960c4-M3f93b75a170bf77e91659ea5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (now SOLVED, we hope)
> $ uname -a > Linux dell 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:50:10 UTC > 2021 x86_64 x86_64 x86_64 GNU/Linux That's impressively up to date. I'll see if I can do likewise. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta3cf8a29e292fa6c-M323c53c8e9fbf17e695fdf92 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
> Go built successfully after enabling the v9fs mmap caching on mount! OK, that's good news. What linux kernel are you running? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M8354696be6c4a677c85e819b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
>> 1. Some of the fpga tools are closed-source so I can't check with >> confidence that they will never try to use mmap. > > Um, nm(1) on the binary to see what it calls? If you were distributing closed-source proprietary tools, would you leave the symbol tables intact to assist reverse engineering? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-Md41872c413eede5674473c19 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
> But is it not possible that the FPGA tools don't > have the same issues with mmap that e.g. Go does? 1. Some of the fpga tools are closed-source so I can't check with confidence that they will never try to use mmap. 2. The go compiler is open-source so it was a simple matter to make an experimental variant on linux which uses read/write instead of mmap (as it does on plan 9). I still get the bus error code=0x2 when running this over v9fs. Hence the remaining v9fs problem is not mmap related. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M0976f2cd2ec4588563d4eb11 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
> What, precisely, is your use case? As I said, the go cross-compile was just an example task to test the viability of v9fs. I don't *need* to cross-compile on linux: the 9pi image, for example, comes with native go binaries which I can use for bootstrapping. The real use case is to have some linux-only tools -- fpga circuit compilation toolchains for example -- keeping their data on the plan 9 server, with the benefit of fossil snapshots and much more space than is available on a little thinkpad SSD. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-Mf84f9fa78ba133380f7d058e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
> Skip, did you specify -o cache=mmap when mounting diod service > for the go build experiment? I tried it myself using local diod and cache=mmap. I get a similar SIGBUS on instruction fetch again. Conclusion: as Bakul says, now I'm debugging linux. Not going there, thanks. Going further off-topic for 9fans, sorry: I thought it would be clever to update the linux client to a newer kernel (4.19 was the latest I could find for debian 9). That didn't go well: booting the new kernel fails with the message Failed to find cpu0 device node Does anyone know if it's feasible to do an out-of-tree build of v9fs kernel modules (9p, 9pnet?) from current source [where is it?] and use them with my old 4.9 kernel? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-Mab7f7ef38ebe5fde4c79b0d1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
> I think the question is why mmap works over 9p from linux up to a point but > then fails in some context: what's the difference? Skip, did you specify -o cache=mmap when mounting diod service for the go build experiment? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M3396ce5fa2b6e3ff195f96f5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
> there is a 9P2000.L variant that seems to > kitchen-sink all Linux fs calls into 9P. There's a file server > (https://github.com/chaos/diod) that implements it. It would be > interesting to know if your case fails using it. Sorry, I've cloned & built diod but I can't quite see how to deploy it for my use case, which is to mount fs from Plan 9 file server onto linux client. The server is 4th edition and thus 9P2000 not 9P2000.L. Here's the incantation I've been using to mount atom's fs using v9fs: $ factotum -n $ srv -a atom $ sudo mount -t 9p -o trans=unix.uname=miller,dfltuid=1000,dfltgid=1000,cache=mmap `namespace`/atom /mnt What would be the equivalent using diod? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M4d4bdafae7fc8e1611dfff1d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
> if you just want to make forward > progress in the short term, perhaps consider using the local Linux > filesystem and exporting that to plan9 using a user-space 9p server? Sure, that's what I did years ago to bring up go-plan9 without an existing native go-plan9 to bootstrap from. The cross-compilation is just an example task to see how practical it is to use v9fs to get work done. I'd like to keep as much stuff as possible on the plan 9 server (with fossil/venti backup) and not use local linux file system for anything valuable. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M60cd958084b9c3ecbc1514ab Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
> Can anyone suggest other mount options I should tweak? I have tried cache=fscache and cache=loose. In both cases I see startling cases of incoherency: ie reading file X returns contents of file Y (neither of which has been modified for months). Maybe my linux kernel is too old? (4.9.0-5-amd64) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-Mc9b4b5b29f8c1d0f872db991 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
> what you did was compile pprof (not shown...) great!, and then when you ran
> it,
> it failed... on the same machine?? but surely a cross plan 9, cross
> compiler/lnker/env
> is for getting plan 9 binaries going...
> or is your prompt modified??
I'll annotate the error message a bit for clarification:
> Building packages and commands for host, linux/amd64.
The failure occurred while building all of go for linux, on linux.
> # cmd/vendor/github.com/google/pprof/third_party/d3
This output line reports which package was being built when the failure
occurred.
> unexpected fault address 0x607c60
> fatal error: fault
> [signal SIGBUS: bus error code=0x2 addr=0x607c60 pc=0x607c60]
There was a memory fault related to address 0x607c60 which is the same
as the program counter, suggesting the fault was a failure to fetch
the instruction at that address.
> goroutine 1 [running]:
> runtime.throw({0xce1702, 0xc8d870})
> /sys/lib/go1.17/src/runtime/panic.go:1198 +0x71 fp=0xc8d828
> sp=0xc8d7f8 pc=0x435331
> runtime.sigpanic()
> /sys/lib/go1.17/src/runtime/signal_unix.go:732 +0x125
> fp=0xc8d878 sp=0xc8d828 pc=0x44b325
> cmd/compile/internal/typecheck.(*iexporter).pushDecl(0xc6e9c0,
> 0xca2120)
> /sys/lib/go1.17/src/cmd/compile/internal/typecheck/iexport.go:403
> ...
> cmd/compile/internal/gc.Main(0xd16458)
> /sys/lib/go1.17/src/cmd/compile/internal/gc/main.go:307 +0x105b
> fp=0xc8df20 sp=0xc8dc98 pc=0xc0495b
> main.main()
> /sys/lib/go1.17/src/cmd/compile/main.go:55 +0xdd fp=0xc8df80
The go runtime traceback suggests that the running binary is the go compiler,
which is being executed from the v9fs file system on the Plan 9 server.
The pc value 0x607c60 is within the text segment of the program, so I'm
guessing there was some problem fetching the page, which the linux kernel
reports as a "bus error" (a generic term for "something went wrong related
to memory").
There's plenty of disk space on the server.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-Mb6b34812de6756eda30d2665
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
> adding 'cache=mmap' to the mount options
> makes it work beautifully!
Not quite beautifully, it turns out. The build proceeds a lot further,
but ends with a memory fault as reported below.
Can anyone suggest other mount options I should tweak?
$ GOOS=plan9 GOARCH=386 GOROOT_BOOTSTRAP=/usr/lib/go
GOROOT_FINAL=/sys/lib/go1.17 ./make.bash
Building Go cmd/dist using /usr/lib/go. (go1.7.4 linux/amd64)
Building Go toolchain1 using /usr/lib/go.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for host, linux/amd64.
# cmd/vendor/github.com/google/pprof/third_party/d3
unexpected fault address 0x607c60
fatal error: fault
[signal SIGBUS: bus error code=0x2 addr=0x607c60 pc=0x607c60]
goroutine 1 [running]:
runtime.throw({0xce1702, 0xc8d870})
/sys/lib/go1.17/src/runtime/panic.go:1198 +0x71 fp=0xc8d828
sp=0xc8d7f8 pc=0x435331
runtime.sigpanic()
/sys/lib/go1.17/src/runtime/signal_unix.go:732 +0x125 fp=0xc8d878
sp=0xc8d828 pc=0x44b325
cmd/compile/internal/typecheck.(*iexporter).pushDecl(0xc6e9c0, 0xca2120)
/sys/lib/go1.17/src/cmd/compile/internal/typecheck/iexport.go:403
fp=0xc8d880 sp=0xc8d878 pc=0x607c60
cmd/compile/internal/typecheck.WriteExports(0xcb4000)
/sys/lib/go1.17/src/cmd/compile/internal/typecheck/iexport.go:272
+0x254 fp=0xc8da58 sp=0xc8d880 pc=0x606f34
cmd/compile/internal/gc.dumpexport(0xcae010)
/sys/lib/go1.17/src/cmd/compile/internal/gc/export.go:39 +0x1d5
fp=0xc8dba0 sp=0xc8da58 pc=0xc02d55
cmd/compile/internal/gc.dumpCompilerObj(0xcae010)
/sys/lib/go1.17/src/cmd/compile/internal/gc/obj.go:106 +0x28
fp=0xc8dbc0 sp=0xc8dba0 pc=0xc05748
cmd/compile/internal/gc.dumpobj1({0x7fffdfeb7fde, 0x23}, 0x3)
/sys/lib/go1.17/src/cmd/compile/internal/gc/obj.go:62 +0x178
fp=0xc8dc70 sp=0xc8dbc0 pc=0xc051d8
cmd/compile/internal/gc.dumpobj()
/sys/lib/go1.17/src/cmd/compile/internal/gc/obj.go:43 +0x36
fp=0xc8dc98 sp=0xc8dc70 pc=0xc04ff6
cmd/compile/internal/gc.Main(0xd16458)
/sys/lib/go1.17/src/cmd/compile/internal/gc/main.go:307 +0x105b
fp=0xc8df20 sp=0xc8dc98 pc=0xc0495b
main.main()
/sys/lib/go1.17/src/cmd/compile/main.go:55 +0xdd fp=0xc8df80
sp=0xc8df20 pc=0xc26d9d
runtime.main()
/sys/lib/go1.17/src/runtime/proc.go:255 +0x227 fp=0xc8dfe0
sp=0xc8df80 pc=0x437a07
runtime.goexit()
/sys/lib/go1.17/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc8dfe8
sp=0xc8dfe0 pc=0x466f81
go tool dist: FAILED: /mnt/sys/lib/go1.17/pkg/tool/linux_amd64/go_bootstrap
install -gcflags=all= -ldflags=all= std cmd: exit status 2
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M21962d3e6cc1b1ab472b5700
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (SOLVED)
> Should this be expected to work? Or is mmap not supported over v9fs? OK, found the answer: adding 'cache=mmap' to the mount options makes it work beautifully! I suppose there's a good reason this isn't the default ... (?) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td63f0104f10a7d67-M47ccd8e5fa6376752fc61e3c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] v9fs vs mmap
I'm trying to cross-compile go for plan9-386 using go-linux-amd64 (on a linux laptop) with the source tree mounted from a plan 9 server via v9fs (mount -t 9p). All goes well up to a point, then this happens: /mnt/sys/lib/go1.17/pkg/tool/linux_amd64/link: mapping output file failed: invalid argument It appears the go linker is now using mmap on its output file, so it can write to different object code sections at multiple offsets. Should this be expected to work? Or is mmap not supported over v9fs? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T386b893f614f2b23-Ma99850de6a262031ebd727dc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Codebase navigation and using tags files in acme
> If you really need to work with extremely
> complex codebases you likely won't find success using plan9 at all.
When I need to scrabble around in the go source tree, I usually have
something like this in a window (it could go in an acme guide file)
grep -n 'func XXX' `{du -a | awk '/\.go$/ {print $2}'} .
which I edit and execute as needed.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tf8ceac12df9da674-M6dcc6863b957346e931b418a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] How to setup wifi on raspberry pi 4
> Of course I haven't done this yet, but is there any information on how to > write drivers in Plan 9? Reading the source code of existing drivers is a good way to learn. > And the second question: if there is a second > raspberry already connected to the Internet, how can you distribute the > Internet for the current raspberry from it? 'man 3 ip' should give you what you need to know, /sys/doc/net/net.pdf will help to understand how it all works. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3464a8c7bad3062a-M36479334c7aefbbd44fc22a4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] How to setup wifi on raspberry pi 4
> if there is a usb wifi adapter, how can > it be run in plan 9? By writing a driver to go in /sys/src/cmd/usb/ether ☺ -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3464a8c7bad3062a-M1c77c726db10ebeba6260989 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] How to setup wifi on raspberry pi 4
> I have Raspberry Pi 4B (1 Gb RAM) and how to run wifi (and setup wifi) on > it ? Assuming you're running with root fs on SD card, and no ethernet connected. Assume your wifi ssid is MYSSID and uses wpa2 authentication, and your wifi passwd is MYPASSWORD. In cmdline.txt on the DOS partition, make sure the command line contains ether1=type=4330 and doesn't contain ipconfig=. Then it goes like this: term% cat /net/ipselftab 127.0.0.001 6b 127.0.0.101 6u 255.255.255.255 01 6b 127.255.255.255 01 6b term% bind -a '#l1' /net term% aux/wpa -2p -s MYSSID /net/ether1 !Adding key: essid=MYSSID proto=wpapsk password: MYPASSWORD term% ip/ipconfig ether /net/ether1 term% cat /net/ipselftab 192.168.23.0 01 6b 127.0.0.001 6b 127.0.0.101 6u 192.168.23.110 01 6u 192.168.23.255 01 6b 255.255.255.255 02 6b 127.255.255.255 01 6b term% ndb/dns -r term% ip/ping www.google.com sending 32 64 byte messages 1000 ms apart to icmp!www.google.com!1 1: rtt 119714 µs, avg rtt 119714 µs, ttl = 117 2: rtt 15776 µs, avg rtt 67745 µs, ttl = 117 3: rtt 12913 µs, avg rtt 49467 µs, ttl = 117 ... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3464a8c7bad3062a-M12b5ad87e46b22c5f742ba6a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Urgent Message !!!
Dearly Friend, Ref: Introduction / Curious to know whether you'll be interested to help me? Good day to you, How are you doing today? I hope everything is well with you. Well, i am contacting you based on an important issues that i will like us to discuss. Please, do get back to me first to confirm that this your E-mail address is still valid before giving you any further details. Thanks for your time and welcome a positive response through My private email: richard.mil...@mail2one.com Thanks in anticipation. Mr. Richard Miller
Re: [9fans] full fossil follies
> FWIW in 9front you can jump into rc while booting and fix this sort of > issue. Sure, having an in-kernel file system with rc and some tools for file system exploration and repair is another alternative to having them on a spare partition or usb drive or whatever. One could even imagine a community 9p server in the cloud providing a FSRaaS (file system recovery as a service). What I was suggesting is that it would be simpler if we could just run things like ls, du, and rm from a completely full fossil, without having to reboot or switch into a special environment. It may be as simple as not trying to update file access times if the partition is full. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M1d945cfd3d40324c273d42c8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] full fossil follies
> it just becomes difficult > to do anything when no fossil blocks can be allocated Thinking a bit further about this: intuitively one might expect to be able to reboot using a local file system which is completely full, and use du and ls to find big files and rm to delete them, without the need to allocate new blocks. Something in the way fossil works, makes this impossible at present. I wonder how much work it would be to investigate and fix? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-Mdf35f73131f8dcb668365537 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] p9f mention of 9front
st...@quintile.net: > However if fossil fills up - because more has been written to it than > it can hold or because snapshots have been turned on without a venti > attached, it will crash badly and can (I believe) lose user data. No, it won't lose data (except in the sense that incoming mail, for example, can't be stored anywhere while the disk is full). You can't usually boot from a completely full fossil, but if you have a fallback boot method (from a CD or USB drive, from a network, or a spare recovery fossil partition) you can then start a fossil on the full partition, and run snapclean and/or delete some files, and all will be well. Even if fossil data was damaged, you could recover with flfmt from venti if you had archiving turned on. Also, nowadays it doesn't actually "crash" ... it just becomes difficult to do anything when no fossil blocks can be allocated. If the fossil on a networked server is full, you may not be able to log into it because that would require some fossil blocks. But you can still recover from a client terminal, by importing its /srv/fossil and using that to issue a snapclean command, or a remove command to delete something. > As I have understood it (others may correct me) the difference between > cpu and terminal kernels is only the value one global variable (cpuserver) > in the kernel, and the list of drivers compiled in - traditionally there > was no graphics support in cpu kernels for example. I have a version of the 4e kernel which functions as either cpu or terminal depending on the setting of environment variable 'service' in plan9.ini or cmdline.txt. It requires only a handful of lines to be added in /sys/src/9/boot/boot.c to make that work. Nowadays kernel RAM is plentiful enough that there's no real reason to configure different sets of devices between terminal and cpu. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Md2b7a8425ae0681a784e7451 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] plan9 and touch screens
fde...@fjrhome.net: > Either that or you would need to replace rio with something more > touchscreen-friendly, in the process losing much of what makes the Plan > 9 environment as unique as it is from a user interface perspective. > > Most "modern" phones also lack a suitable keyboard to provide reasonable > interaction with the command line (and it can be difficult to type > efficiently on something that small anyway). Inferno can work quite comfortably with a touchscreen and a virtual "bitsy" keyboard. It's a different user interface from rio, but not horribly worse. Likely Plan 9 could be adapted to do the same. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T93744379e79c6971-M02879a98ecf562634ea3842d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Miller's 9pi image (rpi4) problems
> Some modern disks use the "UASP" protocol in preference to the >> traditional bulk-only mass storage protocol supported by the Plan >> 9 usbdisk driver... > > Richards that patch makes other devices to not work, have you tested > it after compiling all usb and kernel? No, it was an experiment on one particular drive, tested with usb/disk started by hand. I didn't think the patch was ready to be submitted anywhere, and you've confirmed that was right. Thanks for the extra tweak. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M4eb0d439fc3ee6bb394d247f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Miller's 9pi image (rpi4) problems
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
Re: [9fans] Miller's 9pi image (rpi4) problems
> 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
Re: [9fans] Miller's 9pi image (rpi4) problems
> 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 '' 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
Re: [9fans] Miller's 9pi image (rpi4) problems
> 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
Re: [9fans] Miller's 9pi image (rpi4) problems
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.cFri 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
Re: [9fans] Raspberry Pi400 Ethernet
> The really odd part is I just moved the SD card over > from a pi3 that was booting fine with dhcp. Does the MAC address in the dhcp request look right? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M9e2789d215c02cc904dee5ca Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Raspberry Pi400 Ethernet
I have no personal experience of the pi400 but I believe the ethernet hardware is identical to the pi4. Could it be a configuration problem? Can you run snoopy or equivalent on the network segment and see if the dhcp requests are being transmitted? And check the dhcp server log to see if there's a reason for non-response? Also you can try using ipconfig to set a specific ip address and gateway without using dhcp, to see if it's a dhcp problem or a more fundamental ethernet problem. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M78ab0f08080650d55630723e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] amd64 bootstrap file fo go1.16.3
> Is there a list of known to fail tests? All tests should pass, but you may need to set a longer timeout than the default if your virtual environment is slow. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T75ee4ccd407669dd-M3bdeefa6461494ee99a5cba9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] amd64 bootstrap file fo go1.16.3
> go tool dist: Failed: exit status: 'go 6839: 1' > all.rc 165: go 6566: 1 > ===to here== > > It took about half a day to accomplish! Some things that can make go tools and test suite quicker: - use ramfs for /tmp - use a local file server, with local disk or aoe on a fast connection - make sure you have lots of RAM, or swap to a local disk -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T75ee4ccd407669dd-M19b4000ed9c8fed76f7333be Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] amd64 bootstrap file fo go1.16.3
> srv net!9p.io!9fs: mount failed: fossil authCheck: auth protocol not finished > > I have no account on 9p.io... srv -n 9p.io sources /n/sources -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T75ee4ccd407669dd-Mce51912bfe633c8834113c2b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Help
I need my phone rooted.could u hop
Re: [9fans] p9f email address
> is there an email address to contact p9f directly? bo...@p9f.org goes to everyone on the board. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta6a7f3df36695764-M9c6490d4e2b4b5bb43a88ce9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation
>> I declare that the old bcm kernel found in the p9f code is OK >> to be redistributed under the MIT license. > Is the new one in your contrib directory OK to be redistributed under > the MIT license too? That's what it says on the index webpage, and I know no reason to believe otherwise. I'm happy to confirm my permission for the bits which I wrote. I can't personally make a blanket declaration for the whole collection because some files are from other contributors, but it's my belief that all of it is covered by the MIT license -- as I told you two days ago when you asked me the same question by e-mail. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M9e74d8459cc92bff3e38c7bb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation
> Richard Miller being in this very thread, you could presumably get him > to say "I declare that the old bcm kernel found in the p9f code is OK > to be redistributed under the MIT license" and be done with it. I declare that the old bcm kernel found in the p9f code is OK to be redistributed under the MIT license. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-Mf32dea0bd43ef13946d437b7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation
> The code under discussion > in Richard Miller's contributed bcm kernel. The web page http://9p.io/sources/contrib/miller/9/bcm says "Distributed under the MIT License" with a link to the p9f text. Is that not explicit enough? That's the whole bcm kernel (a superset of what appears in an earlier state in the archive tarballs). -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M86c7f2c58f09e4278dfa161c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation
> I'm talking about things like the bcm kernel contributed by Richard Miller in > the 4e-latest tarball, they weren't written at Bell Labs but were contributed > back to Plan 9. I would have thought any third party code in the /sys/src tree is considered to be a "Contribution" as defined in the original Lucent license, and is therefore covered by the new license without the need of a new agreement. As regards the bcm kernel specifically, note that files in what's called "4e-latest" are about 7 years out of date, and the currently maintained source is in contrib/miller/9/bcm. That too is a "Contribution" and covered by the new license. I hope this can be merged in to the ongoing p9f repository if/when one is set up. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-Mc865eb1ceb88c386a05d4cd9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Can compile Plan9 C compiler for windows10?
> I want to use Plan9 compiler (8c) on my windows 10 system. Not possible except by running Plan 9 on a virtual machine. You can, however, use the inferno version of 8c on some windows platforms. I don't know if windows 10 is one of them. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-M0d065fc59956858d02508fb0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] How to use USB in Plan9?
> I'm new to plan9 and don't know Yes, all of us have been at that stage originally. The way to progress is by reading ... man pages, contents of /sys/doc, and if you really want to understand things well, the source code. lookman is a useful command to suggest which man pages might be relevant. You could try 'lookman usb'. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc998fa89a1d92a10-Mbef023b90a415d26c1ff8ac6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] problem with installing plan9 from USB disk image
> 1. Dual booting is not possible > 2. UEFI introduced vulnerabilities ... Don't these two things cancel each other out? Can we not use the same vulnerabilities to induce the firmware to boot our own choice of operating system? It wouldn't be the first time Plan 9 was installed using ... shall we say unofficial methods? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a54d17e4c0f6c20-Me3d1ddf7fff39e3edc1c178c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] problem with installing plan9 from USB disk image
> I want it as a dual booted os on my system The standard CD works best to install Plan 9 as the first or only operating system on a machine. Do you have an empty hard disk? Or an empty primary partition? If installing on a partition of a shared disk, it's safest to use your existing operating system to change the partition type to "Plan 9" (0x39) before installing. Otherwise, if the disk has partitions which are not aligned to cylinder boundaries, the Plan 9 partition editor may damage them. In any case, you will of course need to make a complete backup of anything valuable and be sure you can restore it again, before starting to install any extra dual boot OS. I have an experimental Plan 9 installer which runs directly from a USB flash drive, for use with machines without an optical drive. So far it has only been tried on thinkpads, so I can't guarantee it will work on your machine. You can fetch it from http://www.hamnavoe.com/plan9install.usb.img.bz2 Expand the bz2, and copy the result as a binary image to an empty usb stick starting at sector zero. You should end up with the usb stick reformatted as a single 1GB FAT partition, containing an install kernel 9pcflop and a terminal kernel 9pcf. Mount this and copy the expanded CD image onto the FAT partition as plan9.iso - this should give you a bootable installer. Follow the installation instructions on 9p.io, with these choices in particular: Distribution disk [no default]: /dev/sdXX/dos Location of archives [browse]: / To boot the installed system, you can use the installer usb stick to boot the terminal kernel. You can either interrupt the boot sequence by hitting a key as soon as you see the list of config assignments on the screen, and type new configs before entering "boot" to continue booting; or you can edit plan9.ini on another system to make the new boot configs permanent. Adding "wait" at the end of the plan9.ini will cause it to pause so you don't have to be quick hitting a key. Boot config assignemts to run the installed system instead of the installer: bootfile=sdB0!/9pcf bootargs=local!/dev/sdE0/fossil Use "glenda" as the username until you've set up your own account. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a54d17e4c0f6c20-Mafcbea8352e1bead538bd93e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] problem with installing plan9 from USB disk image
> don't I need to burn it? You need a CD with exactly the contents of plan9.iso beginning at sector zero. How you make that depends on what operating system you're using. (I only know how to do it on Plan 9, which won't help you much.) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a54d17e4c0f6c20-Md34d43bbce6f1bfb6c4998c2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] problem with installing plan9 from USB disk image
> I want to install Plan9. Can you please tell me the right way to do that. The traditional way is from the CD image. If you expand plan9.iso.bz2 with the bunzip2 utility to produce plan9.iso, and make a CD of that expanded image, you should have a bootable installer. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a54d17e4c0f6c20-M7e0ef1356d5b6a968bc739f7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] problem with installing plan9 from USB disk image
> I downloaded the USB Disk image from there > https://9p.io/plan9/download/usbdisk.bz2 I think that's not an installer image. It's a self-contained Plan 9 system (CPU kernel and fossil filesystem) which you can run from a USB flash drive without having to "install" anything ... provided, that is, you have compatible hardware. What are you trying to boot it on? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a54d17e4c0f6c20-M43f8bc818256b2677a6423be Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
