Re: [9fans] No Boot from installCD on IBM xserver 305
> and as these are blades you have no chance to plug in a > supported PCI NIC. Hello, I don't know if that's relevant but I had no problem pluging in a supported PCI NIC card in my IBM eserver 325, after I found out the default (broadcom too I think) one was not supported. 3.4.0: net 02.00.00 8086/1229 7 0:fe02 4096 1:3001 64 2:fe00 131072 Intel 82557/8/9/0/1 Fast Ethernet LAN Controller Cheers, Mathieu
Re: [9fans] new usb implementation
Brilliant, that will come in handy. Thanks a lot. Mathieu --- Begin Message --- I've just pushed out to sources a new USB implementation, courtesy of nemo, who debugged and repaired our old UHCI and OHCI drivers, wrote a new EHCI driver for USB 2, converted the user-mode drivers in /bin/usb and tested it all, among other things. Thank you, nemo. I've updated on sources at least /386/9*load* (though they contain no USB code), /386/9pc*, kernel sources, manual pages and a few scripts in /rc/bin. Tomorrow's CD image should incorporate all this. devusb has a new interface, so it is named #u, to distinguish it from the old one, #U. If usbd is compiled into /boot, /boot/boot will run usbd at start up, thus permitting the use of USB keyboards, mice, disks, etc. at boot time. --- End Message ---
[9fans] error while building p9p
Hello, just in case it hasn't been reported yet, I get this error when installing plan9port, I've just pulled with hg. 9c vcat.c vcat.c:50: error: too many arguments to function ‘vtcachealloc’ Thanks a lot for the improvement to page, btw. Mathieu
Re: [9fans] p9p vac issue
Indeed, this works for me as well. I've just migrated the arenas, bloom and isect to another machine with a p9p tree from mid February and I had no problem unvacing my data there. And for what it's worth, checkindex on that machine didn't report any problem while it did on the machine with the recent p9p install (which gives me the same vac/unvac issues as the ones already reported by a few people). So the data seems to be ok, which is already quite a relief. Cheers, Mathieu --- Begin Message --- X-No-Archive: Yes This is not much of a solution to the problem, however I have temporarily resolved my issue by performing vac/unvac using my p9p tree from mid-March, and then resorting to the latest p9p for vacfs/9pfuse in order to mount my archives. For those researching the issue, I think some change between the middle of March and now is causing the inability of vac to write to a venti archive on p9p with the error: create bsize 8192 psize 8160vac: vacfscreate: vacfileroot: read too small: asked for 0 need at least 389 _ Windows Live helps you keep up with all your friends, in one place. http://go.microsoft.com/?linkid=9660826--- End Message ---
Re: [9fans] p9p vac issue
if you can't get an old one from swtch.com, I can tar this mid-february tree I have - or rather only the necessary parts - and serve it to you if you want. Mathieu --- Begin Message --- 2009/6/22 Mathieu L. > Indeed, this works for me as well. > I've just migrated the arenas, bloom and isect to another machine with > a p9p tree from mid February and I had no problem unvacing my data > there. And for what it's worth, checkindex on that machine didn't report > any problem while it did on the machine with the recent p9p install > (which gives me the same vac/unvac issues as the ones already reported > by a few people). OK, so all I need now is to get my hands on an old copy of the p9p binaries... the only old ones I've got are carefully backed up inside the venti that I can't get at :) > So the data seems to be ok, which is already quite a relief. > > Cheers, > Mathieu -- Adrian --- End Message ---
[9fans] dial and buffer overflow
Hello all,
I have this piece of code that looks like this:
for (int i=0; i<5 ; i++){
for (int j=0; jsha1list)[i][j]);
print("\n");
}
print("addr called: %s\n",netmkaddr(address, "tcp", port));
ctlfd = dial(netmkaddr(address, "tcp", port), 0, 0, 0);
if(ctlfd < 0){
fprint(2, "can't dial %s: %r\n", address);
exits("dialing");
}
for (int i=0; i<5 ; i++){
for (int j=0; jsha1list)[i][j]);
print("\n");
}
which gives that kind of input:
f8c3f943edf54d28e3f894e9416d5312a49c3916
5d7a30beaef2b56a06b8aea37cd3263698825ec3
b456f6749bf907233c183c04277569aa0833e386
3e2d9cee1e07d3d770f1a6081a006394cb4b35d3
c43a3bd4caa813a75f58096068309ede6e96cacd
addr called: tcp!127.0.0.1!6895
697034930300eb9803000e000e00
5d7a30bed80802313cc7349303003ffd0100
b456f6749bf907233c183c04277569aa0833e386
3e2d9cee1e07d3d770f1a6081a006394cb4b35d3
c43a3bd4caa813a75f58096068309ede6e96cacd
so it seems like something happens when calling dial which modifies what
I have in memory pointed by tor->sha1list[i], and that is of course not
what I want, as those values should have nothing to do with the call to
dial itself.
the various tor->sha1list[i][j] were allocated and set earlier in the
code, and I don't think I wrote out of their boundaries when I did so
since I can free() them all just before the call to dial() without getting
an error. Although I'm not sure that's a conclusive enough test, is it?
It's on 9vx so I can't use acid or leak since both systematically freeze
9vx here.
Does anyone have an idea on what I'm doing wrong or how to debug that
further?
Thanks,
Mathieu
Re: [9fans] dial and buffer overflow
Thanks for the answer Erik. [...] > the extra () around tor->sha1list are confusing. Noted, thanks, they're gone. I suck at remembering operators precedence so I usually add a few parentheses to be on the safe side. > it is more likely that you have some allocation > error in your code. neither netmkaddr nor > dial do any allocation, so i don't see how memory > on the heap could get corrupted without help. > > the three most common errors that cause this are > (a) not allocating enough memory by, e.g. > malloc(sizeof tor) not malloc(sizeof *tor). or > (b) pointing to a non-static on the stack, > or (c) mistyping of tor->sha1list so that sizeof > tor->sha1list[0][0] != 1. Could you elaborate on (b), or point me to an example please? I don't really understand what it means or how it could happen...
[9fans] btfs, a BitTorrent client (attempt)
Hello 9fans, So I'm following the ericvh school and I'm "releasing" that, because I for one badly need the peer review. However, the program is doing very little at the moment and it should really be considered as some sort of alpha version. The code is neither efficient nor elegant and it definitely is lower quality than what you usually see around here. That does not worry me that much as it's constantly improving thanks to 9fans and the guys on #plan9. What it should be able to do at the current state is: -parse the .torrent file and put everything relevant into mem -call the tracker and parse the reply -call a peer revealed by the tracker -ask that peer for the pieces in order, receive them, and write them to the files they belong to. So if you're lucky enough that the chosen peer is a seeder, you should get the torrent. Anything else, you can assume it can't do. Also, if some files in the torrent are smaller than the typical piece size (262144 bytes), it will probably fail. As you can see, I'd say than less than half of the rfc is there, but I feel like the hardest part so far was to understand the protocol, so I'm confident the rest should follow quite easily. Now I don't expect people to look at the code, but I'd really like some advice for the next steps. What mainly needs to be done, is the capability to contact several peers at the same time, and request different pieces from all of them, as well as to send to those peers the pieces we already have. I've read the docs about the csp style and I've tried some small examples, but I'm not sure what's the best to do for that bt program now. Most of the processes/threads will have to share some info, like the list of pieces we already have, and the list of peers we're already communicating with. So as a first approach I was thinking of having simply one thread for each connection with a peer. And maybe one group of threads (in one process) would be responsible for getting the pieces, while another one (in another process) would be responsbile for sending the pieces we have. How does that sound? Anyway, for those interested enough to try it out, here it is: http://smgl.fr.eu.org/lejatorn/plan9/btfs.tar http://smgl.fr.eu.org/lejatorn/plan9/btfs I should have a contrib when Geoff is back, I'll announce it when it gets there. You'll have to patch webfs so it accepts nuls in urls, because that can happen with tracker infohashs (and it's not illegal according to the rfc). That does not seem to have caused me any trouble but then I only use webfs for btfs. 9vx% diff /sys/src/cmd/webfs/url.c-old /sys/src/cmd/webfs/url.c 543a544 > /* 547a549 > */ There's no documentation yet, so here's how it works: ./btfs [-d datadir] [-m mountpoint] [-v] echo 'add /path/to/the/torrent/file.torrent' > /mnt/btfs/ctl Of course, lots of features and user interaction are planned to happen through the fs mounted at /mnt/btfs/, that will come later on. I've set up a tracker and a peer that you can test against, if you use the .torrent attached to this mail, it should work. I suppose torrents with one full seeder like the ones that can be found on jamendo.com would work as well. Finally, I'd like to thank everyone who helped me with it so far, especially fgb, maht, quintile and cinap. Comments, ideas, criticism all welcome please. Enjoy, Mathieu
Re: [9fans] btfs, a BitTorrent client (attempt)
and of course I forgot to attach the .torrent, so here it is: http://smgl.fr.eu.org/lejatorn/plan9/btfs.torrent --- Begin Message --- Hello 9fans, So I'm following the ericvh school and I'm "releasing" that, because I for one badly need the peer review. However, the program is doing very little at the moment and it should really be considered as some sort of alpha version. The code is neither efficient nor elegant and it definitely is lower quality than what you usually see around here. That does not worry me that much as it's constantly improving thanks to 9fans and the guys on #plan9. What it should be able to do at the current state is: -parse the .torrent file and put everything relevant into mem -call the tracker and parse the reply -call a peer revealed by the tracker -ask that peer for the pieces in order, receive them, and write them to the files they belong to. So if you're lucky enough that the chosen peer is a seeder, you should get the torrent. Anything else, you can assume it can't do. Also, if some files in the torrent are smaller than the typical piece size (262144 bytes), it will probably fail. As you can see, I'd say than less than half of the rfc is there, but I feel like the hardest part so far was to understand the protocol, so I'm confident the rest should follow quite easily. Now I don't expect people to look at the code, but I'd really like some advice for the next steps. What mainly needs to be done, is the capability to contact several peers at the same time, and request different pieces from all of them, as well as to send to those peers the pieces we already have. I've read the docs about the csp style and I've tried some small examples, but I'm not sure what's the best to do for that bt program now. Most of the processes/threads will have to share some info, like the list of pieces we already have, and the list of peers we're already communicating with. So as a first approach I was thinking of having simply one thread for each connection with a peer. And maybe one group of threads (in one process) would be responsible for getting the pieces, while another one (in another process) would be responsbile for sending the pieces we have. How does that sound? Anyway, for those interested enough to try it out, here it is: http://smgl.fr.eu.org/lejatorn/plan9/btfs.tar http://smgl.fr.eu.org/lejatorn/plan9/btfs I should have a contrib when Geoff is back, I'll announce it when it gets there. You'll have to patch webfs so it accepts nuls in urls, because that can happen with tracker infohashs (and it's not illegal according to the rfc). That does not seem to have caused me any trouble but then I only use webfs for btfs. 9vx% diff /sys/src/cmd/webfs/url.c-old /sys/src/cmd/webfs/url.c 543a544 > /* 547a549 > */ There's no documentation yet, so here's how it works: ./btfs [-d datadir] [-m mountpoint] [-v] echo 'add /path/to/the/torrent/file.torrent' > /mnt/btfs/ctl Of course, lots of features and user interaction are planned to happen through the fs mounted at /mnt/btfs/, that will come later on. I've set up a tracker and a peer that you can test against, if you use the .torrent attached to this mail, it should work. I suppose torrents with one full seeder like the ones that can be found on jamendo.com would work as well. Finally, I'd like to thank everyone who helped me with it so far, especially fgb, maht, quintile and cinap. Comments, ideas, criticism all welcome please. Enjoy, Mathieu --- End Message ---
Re: [9fans] Using cwfs
> > if you are simply left with a directory that's been > > deleted. maybe something else is going on? > > Perhaps. The harddisk is a FreeAgent Seagate, > connected via USB. It used to go into sleep mode > every 15 minutes and I would often have to restart > cwfs - this is probably cause for a lot of damage. > > It's no longer an issue, as I recently got access to > a Windows computer with the proper software to > disable this. I've already told Akumar offlist, just writing it to the list for documentation: that auto sleep mode on seagates can be disabled on linux (dunno about *BSD) as well with sdparm. I don't remember the args for sure, but probably something like 'sdparm -c STANDBY /dev/sdX#' then 'sdparm -s /dev/sdX#' to save. Mathieu
[9fans] dial and time out
Hello 9fans, I have a bunch of threads, simply scheduled with yield() at the moment (I'll use alt later on), and each of them is calling dial() at some point. I don't want the other threads to wait for "too long" when one of them is blocked on a dial() that will eventually time out. So I was thinking, for each of them, of creating a proc which would be used as a timer; it would be created just before the call to dial, wait for some time, and then kill the dial()ing thread. And as mechiel suggested, the dial()ing thread would also be set to kill the timer after it successfully dialed, hence not being killed if it was fast enough. Is that the right way to go? If yes, can anyone think of an already existing example I can look at? Mathieu
Re: [9fans] dial and time out
it seemed safer at first if I didn't have to worry about the procs preempting each other (and appart from that dial() bottleneck, I don't need them to), that's why I started with threads. I was thinking of sticking to threads and not using procs until I really do need them. But yeah, no real good reason not to switch to procs if that's the best way to go in that case. Mathieu. --- Begin Message --- > I have a bunch of threads, simply scheduled with yield() at the moment > (I'll use alt later on), and each of them is calling dial() at some > point. I don't want the other threads to wait for "too long" when one > of them is blocked on a dial() that will eventually time out. > So I was thinking, for each of them, of creating a proc which would > be used as a timer; it would be created just before the call to dial, > wait for some time, and then kill the dial()ing thread. And as mechiel > suggested, the dial()ing thread would also be set to kill the timer > after it successfully dialed, hence not being killed if it was fast > enough. what's the reason for not using procs? - erik --- End Message ---
Re: [9fans] dial and time out
Yes, I did mean thread, and I hadn't realized this would kill all the threads. I'll try with ioproc then, thanks for the example. Mathieu --- Begin Message --- If you really mean thread and not proc, then what you suggest won't work. You can't kill a thread that's in the OS without killing the proc conyaining the thread (thereby killing all the other threads as well). You can have the proc catch notes and send a note to the proc which will interrupt any system call, thereby pulling the thread out of the dial. A more elgant way to do this would be to use ioproc(2), or to create procs explicitly to do the dial I/O. Sape > From: lejat...@gmail.com > To: 9fans@9fans.net > Reply-To: 9fans@9fans.net > Date: Thu Sep 10 11:38:50 CES 2009 > Subject: [9fans] dial and time out > > Hello 9fans, > > I have a bunch of threads, simply scheduled with yield() at the moment > (I'll use alt later on), and each of them is calling dial() at some > point. I don't want the other threads to wait for "too long" when one > of them is blocked on a dial() that will eventually time out. > So I was thinking, for each of them, of creating a proc which would > be used as a timer; it would be created just before the call to dial, > wait for some time, and then kill the dial()ing thread. And as mechiel > suggested, the dial()ing thread would also be set to kill the timer > after it successfully dialed, hence not being killed if it was fast > enough. > > Is that the right way to go? If yes, can anyone think of an already > existing example I can look at? > > Mathieu > --- End Message ---
Re: [9fans] 9vx as a perfect proto environment
I've definitely seen it on linux. I'm using 9vx as my primary development platform, and even though it's fantastic to have a Plan 9 environment so easily setup and integrated to the host OS, it has its limits. For example it will crash if your badly written program tries to read on a hanged up connection, or it will freeze if you run a buggy program in acid with truss. Still, it's so convenient compared to dual booting or qemu that I prefer sticking with it. Cheers, Mathieu --- Begin Message --- > I've had less success using it for "real work", at least on MacOS > 10.5 and 10.6 - for example running a venti server eventually > results in something like > 9vx panic: sigsegv on cpu7 I've seen similar on FreeBSD, though I don't think I've see it on Linux. I use 9vx pretty much all the time as my terminal and stand-alone when I'm not connected to my network. In those uses, a crash once or twice a day hasn't been bad enough to make me investigate. BLS --- End Message ---
Re: [9fans] 9vx as a perfect proto environment
Indeed, I've just retried with the latest pull from hg and that problem is gone for me, that's brilliant. That's one less thing to worry about with 9vx, cheers for that. ☺ Mathieu --- Begin Message --- I'm using 9vx as my primary development platform, and even though it's fantastic to have a Plan 9 environment so easily setup and integrated to the host OS, it has its limits. For example it will crash if your badly written program tries to read on a hanged up connection, or it will freeze if you run a buggy program in acid with truss. is this with the latest 9vx or the bin snapshot? I know the snapshot didnt ignore SIGPIPE which would cause the whole vm to shutdown when writing to a socket that shut down. However, that should be fixed in the latest sources. Mathieu Tim Newsham http://www.thenewsh.com/~newsham/ --- End Message ---
