Re: [9fans] ahci and intel gbe
what motherboard and model did you use. it would be good to buy something known to work. I am afraid have had less success with 9atom on old hardware. Steve > On 28 Jan 2015, at 05:43, erik quanstrom wrote: > > i'm quite happy to report that this new haswell hardware worked the first time > with nix 64 bit. the ahci stuff should "just work" due to the standard, but > the > i210 gbe was entered speculatively, and it's pretty nice that it just seems to > work. > > so don't let 'em tell you "plan 9 only works with older hardware". :-) > > ; pci -v 0.17.4 0.31.2 > 0.17.4:disk 01.06.01 8086/8d62 11 0:f111 16 1:f101 16 2:f0f1 > 16 3:f0e1 16 4:f021 32 5:fb438000 2048 >Intel CorporationC610/X99 series chipset sSATA Controller [AHCI mode] > 0.31.2:disk 01.06.01 8086/8d02 11 0:f071 16 1:f061 16 2:f051 > 16 3:f041 16 4:f001 32 5:fb432000 2048 >Intel CorporationC610/X99 series chipset 6-Port SATA Controller [AHCI > mode] > > ; pci -v 7.0.0 8.0.0 > 7.0.0:net 02.00.00 8086/1533 11 0:fb20 524288 2:d001 32 > 3:fb28 16384 >Intel CorporationI210 Gigabit Network Connection > 8.0.0:net 02.00.00 8086/1533 10 0:fb10 524288 2:c001 32 > 3:fb18 16384 >Intel CorporationI210 Gigabit Network Connection > > - erik
Re: [9fans] protection against resource exhaustion
> if any one has cleaner solution, i.e., a solution that never kill innocent > process, > I want to see it. I have an almost mathematical certainty that the human factor is by far the greatest contributor to the problem and solving any technical issue would be insignificant by comparison. Like any other form of security, the trade offs are what count. Bloating Plan 9 with feeble attempts to shelter the system against malicious users is, in my opinion, too expensive. Lucio.
Re: [9fans] protection against resource exhaustion
Hello, > nonetheless, i have experience running multi-user plan 9 systems, and users > were not usually the issue. Eric’s users are all gentleman, all careful people and all skillful programmers. If your system is served for university students, you will have different thought. > i think you've turned a problem with bounded recovery time into a > situation where the recovery code itself will inadvertently dos attack its > users. in case that a process failed in getting resource such as memory or process, what it should do is very limited: puts out some message and exits. this is right behavior. I have never seen programs that retry malloc() or fork() until succeed. if all processes retry them, the system will get down. this is what I have observed in current plan9 kernel. if any one has cleaner solution, i.e., a solution that never kill innocent process, I want to see it.
[9fans] ahci and intel gbe
i'm quite happy to report that this new haswell hardware worked the first time with nix 64 bit. the ahci stuff should "just work" due to the standard, but the i210 gbe was entered speculatively, and it's pretty nice that it just seems to work. so don't let 'em tell you "plan 9 only works with older hardware". :-) ; pci -v 0.17.4 0.31.2 0.17.4: disk 01.06.01 8086/8d62 11 0:f111 16 1:f101 16 2:f0f1 16 3:f0e1 16 4:f021 32 5:fb438000 2048 Intel Corporation C610/X99 series chipset sSATA Controller [AHCI mode] 0.31.2: disk 01.06.01 8086/8d02 11 0:f071 16 1:f061 16 2:f051 16 3:f041 16 4:f001 32 5:fb432000 2048 Intel Corporation C610/X99 series chipset 6-Port SATA Controller [AHCI mode] ; pci -v 7.0.0 8.0.0 7.0.0: net 02.00.00 8086/1533 11 0:fb20 524288 2:d001 32 3:fb28 16384 Intel Corporation I210 Gigabit Network Connection 8.0.0: net 02.00.00 8086/1533 10 0:fb10 524288 2:c001 32 3:fb18 16384 Intel Corporation I210 Gigabit Network Connection - erik
Re: [9fans] protection against resource exhaustion
On Tue Jan 27 16:06:49 PST 2015, aris...@ar.aichi-u.ac.jp wrote: > we don’t have perfect solution. > nevertheless, we must protect system. why does limiting forks "protect the system"? why must be "protect the system"? and what does that phrase mean in this context? > if we search ideal (or nearly ideal) solution, we should assign limited > resource to each user. > however this is a big job, I believe. > > current plan9 system is running under shared resource model. > under this model, it is very hard to protect system from evil-minded users. plan 9 has no hope against malicious users. they can fill up your disk, or use all your memory, too. i believe the quote attributed to presotto is "we don't have quotas. ken just yells at anyone who hogs the jukebox." nonetheless, i have experience running multi-user plan 9 systems, and users were not usually the issue. > keeping this model, we can do something that is, of course, imperfect (but > easy to implement, I believe). > for example: > (a) select processes that should keep running. (with resrcwait flag, for > example) > (b) kill processe that failed to be allocated resource if it doesn’t has > resrcwait flag. > > this strategy has following problems: > (1) innocent processes may be killed. > the probability is small if the origin is careless program, but can be large > by evil-mined program. > (2) error return from malloc() and fork() are disabled. i think you've turned a problem with bounded recovery time into a situation where the recovery code itself will inadvertently dos attack its users. - erik
Re: [9fans] 9atom downtime
On Tue Jan 27 07:00:23 PST 2015, 0in...@gmail.com wrote: > > I wonder what the difference is between > > 9atom.iso.bz2 > > and > > +9atom.iso.bz2 > > I think one is more recent than the other. the + one is experimental. - erik
Re: [9fans] protection against resource exhaustion
we don’t have perfect solution. nevertheless, we must protect system. if we search ideal (or nearly ideal) solution, we should assign limited resource to each user. however this is a big job, I believe. current plan9 system is running under shared resource model. under this model, it is very hard to protect system from evil-minded users. keeping this model, we can do something that is, of course, imperfect (but easy to implement, I believe). for example: (a) select processes that should keep running. (with resrcwait flag, for example) (b) kill processe that failed to be allocated resource if it doesn’t has resrcwait flag. this strategy has following problems: (1) innocent processes may be killed. the probability is small if the origin is careless program, but can be large by evil-mined program. (2) error return from malloc() and fork() are disabled. > 2015/01/27 23:10、erik quanstrom のメール： > >>> i think it will go the same way with fork protection. how do you tell >>> which program >>> is at fault? how do you tell a program forking at high frequency, with >>> short lived >>> children from a fork bomb? (such as a busy web server.) >> >> only system administrator knows which processes should keep running. > > do you wake him up in the middle of the night if this happens to arbitrate? > this knowledge of what should be preserved may only be post facto knowledge. > "i'll know what to kill off once i see what's running." which assumes a > working > fork, at least for the administrator. > > in any event, i'd be interested in code that does do a good job, especially > if it passes tests other than the trivial fork bomb, such as many users > contributing > to exhaustion. > >> I have beeb writing codes believing those error return is working. > > do you have tests? did you write a test malloc that will fail when called > at every location, and ensure sane behavior? > > - erik >
Re: [9fans] 9atom downtime
EC2, EC2! :) On Tue, Jan 27, 2015 at 6:06 AM, erik quanstrom wrote: > On Mon Jan 26 23:03:29 PST 2015, rudolf.syk...@gmail.com wrote: > > Hello, > > > > On 24 January 2015 at 20:48, erik quanstrom > wrote: > > > looks like a power even took out the motherboard. hopefully i can find > > > some parts early next week. > > > > > > - erik > > > > does that mean I can't download 9atom now? > > (the web page www.9atom.org is up, but going to 386 iso > > [ftp.9atom.org] doesn't work) > > yes, i'm sorry. motherboard is in the mail. > > - erik > >
Re: [9fans] 9atom downtime
> but the most recent (nonzero) one is then more then half a year old, > > 9atom-2014-07-08 > > What is the logic about when a image is taken? The image is automatically downloaded every day, then it is deleted if the content is identical to the last image. -- David du Colombier
Re: [9fans] 9atom downtime
On 27 January 2015 at 16:03, David du Colombier <0in...@gmail.com> wrote: >> I wonder what the difference is between >> 9atom.iso.bz2 >> and >> +9atom.iso.bz2 > > I think one is more recent than the other. the one with + seems to be always (when it exists) smaller by about 2 MB ... Ruda
Re: [9fans] 9atom downtime
On 27 January 2015 at 16:41, David du Colombier <0in...@gmail.com> wrote: >> I am starting to feel like an idiot again. >> What I can find there seems to have 0 bytes. >> (see the screenshot) >> What am I doing wrong? > > These are the images from today, but the ftp.9atom.org > server is currently down. You have to look in an older > directory. ok :) but the most recent (nonzero) one is then more then half a year old, 9atom-2014-07-08 What is the logic about when a image is taken? I guess there must have been changes in the meanwhile, or am I wrong and you take an image always when the file on 9atom.org changes? If there have been changes, and if I use this (older) image, will I be able to somehow get in sync with 9atom later on? Thanks Ruda
Re: [9fans] 9atom downtime
> I am starting to feel like an idiot again. > What I can find there seems to have 0 bytes. > (see the screenshot) > What am I doing wrong? These are the images from today, but the ftp.9atom.org server is currently down. You have to look in an older directory. -- David du Colombier
Re: [9fans] 9atom downtime
Hi David, >> A mirror of the 9atom CD image is available on: >> >> http://mirror.9grid.fr/ I am starting to feel like an idiot again. What I can find there seems to have 0 bytes. (see the screenshot) What am I doing wrong? Thanks Ruda
Re: [9fans] ssh2 (at least the legacy version) seems incompatible with
> ok, i found some more diagnostic messages in /sys/log/sshdebug: > ... > The problem might be that `dh.c` has an empty implementation of `dh_client142` > ... Ingo, I must admit to being the guilty party for the SSHv2 implementation. Though Geoff gets credit for cleaning up what was some of my uglier code. It's been over a year since I looked at any of it and probably closer to 3 years since touching the crypto part. However, I'll take a look and see if I can get an implementation of the group 14 stuff in place, or at least not have it advertise something it doesn't do. BLS
Re: [9fans] 9atom downtime
> I wonder what the difference is between > 9atom.iso.bz2 > and > +9atom.iso.bz2 I think one is more recent than the other. > And what is kernel.mkfs.bz2? This is a kfs archive of /sys/src/9. -- David du Colombier
Re: [9fans] 9atom downtime
>> http://mirror.9grid.fr/ I wonder what the difference is between 9atom.iso.bz2 and +9atom.iso.bz2 And what is kernel.mkfs.bz2? Thanks Ruda On 27 January 2015 at 15:46, Rudolf Sykora wrote: > Hi David, Erik, > > On 27 January 2015 at 15:22, erik quanstrom wrote: >> On Tue Jan 27 06:13:39 PST 2015, 0in...@gmail.com wrote: >>> A mirror of the 9atom CD image is available on: >>> >>> http://mirror.9grid.fr/ > > good. So I may download and use. :) > > >> the usb image is the primary distribution media these days. > > I confess I don't understand. Is there a difference in the software, > or what do you mean? > > Thanks > Ruda
Re: [9fans] 9atom downtime
Hi David, Erik, On 27 January 2015 at 15:22, erik quanstrom wrote: > On Tue Jan 27 06:13:39 PST 2015, 0in...@gmail.com wrote: >> A mirror of the 9atom CD image is available on: >> >> http://mirror.9grid.fr/ good. So I may download and use. :) > the usb image is the primary distribution media these days. I confess I don't understand. Is there a difference in the software, or what do you mean? Thanks Ruda
Re: [9fans] 9atom downtime
> the usb image is the primary distribution media these days. The USB image is also available. -- David du Colombier
Re: [9fans] 9atom downtime
On Tue Jan 27 06:13:39 PST 2015, 0in...@gmail.com wrote: > A mirror of the 9atom CD image is available on: > > http://mirror.9grid.fr/ the usb image is the primary distribution media these days. - erik
Re: [9fans] 9atom downtime
A mirror of the 9atom CD image is available on: http://mirror.9grid.fr/ -- David du Colombier
Re: [9fans] protection against resource exhaustion
> > i think it will go the same way with fork protection. how do you tell > > which program > > is at fault? how do you tell a program forking at high frequency, with > > short lived > > children from a fork bomb? (such as a busy web server.) > > only system administrator knows which processes should keep running. do you wake him up in the middle of the night if this happens to arbitrate? this knowledge of what should be preserved may only be post facto knowledge. "i'll know what to kill off once i see what's running." which assumes a working fork, at least for the administrator. in any event, i'd be interested in code that does do a good job, especially if it passes tests other than the trivial fork bomb, such as many users contributing to exhaustion. > I have beeb writing codes believing those error return is working. do you have tests? did you write a test malloc that will fail when called at every location, and ensure sane behavior? - erik
Re: [9fans] 9atom downtime
On Mon Jan 26 23:03:29 PST 2015, rudolf.syk...@gmail.com wrote: > Hello, > > On 24 January 2015 at 20:48, erik quanstrom wrote: > > looks like a power even took out the motherboard. hopefully i can find > > some parts early next week. > > > > - erik > > does that mean I can't download 9atom now? > (the web page www.9atom.org is up, but going to 386 iso > [ftp.9atom.org] doesn't work) yes, i'm sorry. motherboard is in the mail. - erik
Re: [9fans] protection against resource exhaustion
> IMO, instead of killing processes, it would be better to keep the hanging > behavior in place, but place limits on the resources used by a subsection > of the process tree. Think ulimit, but applying to entire process heirarchies. doesn't solve the issues of every program needing to deal with failed forks. wouldn't you just love it if a programming error were to put acme in a wierd state? the machine might as well reboot, since you are likely the only user, and the editor is wack. - erik
Re: [9fans] protection against resource exhaustion
On Tue Jan 27 02:49:44 PST 2015, charles.fors...@gmail.com wrote: > On 27 January 2015 at 04:22, erik quanstrom wrote: > > > this isn't because [linux oom killer] isn't thoughtfully and > > well built, > > > > it's actually fairly stupid. the proof that a non-stupid one could be written for me would be in the writing. there are a lot of smart people who care about the matter not doing this. :-) - erik
Re: [9fans] protection against resource exhaustion
On 27 January 2015 at 04:22, erik quanstrom wrote: > this isn't because [linux oom killer] isn't thoughtfully and > well built, > it's actually fairly stupid.
