Re: arc4random() range
On Wed, 19 Feb 2003, Peter Jeremy wrote: On Tue, Feb 18, 2003 at 06:22:37PM -0800, Paul Herman wrote: [...range of arc4random() is twice that of random()...] I see this as a major advantage of arc4random() I see this as an advantage, too. It's also produces random numbers with a very long period. It's also not too slow. But that's not what put the bee in my bonnet. The disadvantage is that it doesn't behave like random()/rand(), like I mistakingly assumed despite reading the manpage. Background: I probably spent an hour trying to figure out why my monte carlo simulations (dealing with concordance of ranking tables) were skewed until I narrowed it down to arc4random() producing random numbers twice as big as random(). So, I was first going to post to -doc about the lack of this fact in the manpage to possibly spare others from a similar tribulation, but it occurred to me to ask on -hackers what people thought about this break from tradition first. Unfortunately, this behavior is inconsistent with random(), perhaps for good reason, but perhaps indeed the strongest argument above any other for *not* changing arc4random() to a drop-in replacement for random()/rand() is legacy: it's already been this way for quite some time now and some code may depend on this behavior now. If no one disagrees, I suggest an addition to the manpage along the lines of: arc4random() returns random numbers in the range of 0 to (2**32)-1, and therefore has twice the range of RAND_MAX. and if we are feeling really generous: EXAMPLES The following produces a drop-in replacement for the traditional random() and rand() functions using arc4random(): #define arc4random31() (arc4random() 0x7FFF) -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
In message [EMAIL PROTECTED], Paul Herma n writes: arc4random() returns random numbers in the range of 0 to (2**32)-1, and therefore has twice the range of RAND_MAX. Good. EXAMPLES The following produces a drop-in replacement for the traditional random() and rand() functions using arc4random(): #define arc4random31() (arc4random() 0x7FFF) Not good. Only true on 32 bit archs. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
On Wed, 19 Feb 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Paul Herma n writes: arc4random() returns random numbers in the range of 0 to (2**32)-1, and therefore has twice the range of RAND_MAX. Good. EXAMPLES The following produces a drop-in replacement for the traditional random() and rand() functions using arc4random(): #define arc4random31() (arc4random() 0x7FFF) Not good. Only true on 32 bit archs. Heh? random(3) produces numbers between 0 and RAND_MAX on my alpha. random(3) produces numbers between 0 and RAND_MAX on my i386. (arc4random() 0x7FFF) produces numbers between 0 and RAND_MAX on my alpha. (arc4random() 0x7FFF) produces numbers between 0 and RAND_MAX on my i386. I must not understand what you mean. OK Poul, I'll bite. :-) Could you please expound? bash-2.05$ uname -rm 4.5-RELEASE alpha bash-2.05b$ uname -rm 4.7-STABLE i386 -Paul. P.S. I hope you aren't nitpicking because of a missing (long) cast. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
In message [EMAIL PROTECTED], Paul Herma n writes: EXAMPLES The following produces a drop-in replacement for the traditional random() and rand() functions using arc4random(): #define arc4random31() (arc4random() 0x7FFF) Not good. Only true on 32 bit archs. Heh? random(3) produces numbers between 0 and RAND_MAX on my alpha. random(3) produces numbers between 0 and RAND_MAX on my i386. Well, I'm right in principle but wrong in current practice, at the very least make it: #define arc4random31() (arc4random() RAND_MAX) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
Thus spake Paul Herman [EMAIL PROTECTED]: On Wed, 19 Feb 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Paul Herma n writes: arc4random() returns random numbers in the range of 0 to (2**32)-1, and therefore has twice the range of RAND_MAX. Good. EXAMPLES The following produces a drop-in replacement for the traditional random() and rand() functions using arc4random(): #define arc4random31() (arc4random() 0x7FFF) Not good. Only true on 32 bit archs. Heh? random(3) produces numbers between 0 and RAND_MAX on my alpha. random(3) produces numbers between 0 and RAND_MAX on my i386. (arc4random() 0x7FFF) produces numbers between 0 and RAND_MAX on my alpha. (arc4random() 0x7FFF) produces numbers between 0 and RAND_MAX on my i386. Your code should work fine, although it assumes RAND_MAX is 2^31-1, rather than using the symbolic constant. But I think if people were really interested in using arc4random() as a drop-in replacement for random(), they would have already written a libc function to mimic random(). Just documenting the range of arc4random() should be sufficient. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
[EMAIL PROTECTED] writes: Well, I'm right in principle but wrong in current practice, at the very least make it: #define arc4random31() (arc4random() RAND_MAX) or rather #define arc4random31() (arc4random() % (RAND_MAX + 1)) to avoid relying on RAND_MAX being one less than a power of two. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
Peter Jeremy [EMAIL PROTECTED] writes: In any case, doesn't the name imply that it's 31-bits... Yes, it's a bad name. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Hi!Dear FreeBSD!
Terry Lambert wrote: None of those maps are clickable. They're actually just *tiny* PNGs of maps-with-pins-in-them, with no obvious correlation to real location data associated with PERL (e.g. number of pins is not equal to number of page entries, in most cases, and the pins for Columbs, Dayton, and other Ohio locations all pops up at the same pixel location, etc.). Can I just point out Terry, that this is a map of Perl user groups? We're not NORAD and they aren't suspected sites of WMD that we need to target. :-) It's really unfortunate that no one seems to be willing to put out the server resources to do real GIS mapping, e.g. using the data specifications at: Right, I'm not sure if you're joking or not, but are you honestly suggesting that somebody writes a GIS based map rendering system using a relatively complicated set of standards so that people can get 3D representations of where the nearest Perl Mongers group is? I'm actually writing a proposal at the moment that might go up to BSDCon or maybe somewhere else entitled Why Open Source Software will Ultimately Fail in a Commercial Context. The core argument is that as OSS developers are unpaid, they'll work on whatever they want - i.e. what they think is cool or what they need to get a particular job done. Nobody here at the age of 15 thought they wanted to write word processors or spreadsheets when they grew up, right? Do you mind if I cite this example anonymously as a re-enforcement of my argument? :-) Seriosuly Terry, I can't tell if you were joking or not, but nobody is going to play with opengis stuff, just because it would be a neat way of showing where user groups are. :-) -- Paul Robinson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hi!Dear FreeBSD!
Paul Robinson wrote: Terry Lambert wrote: None of those maps are clickable. They're actually just *tiny* PNGs of maps-with-pins-in-them, with no obvious correlation to real location data associated with PERL (e.g. number of pins is not equal to number of page entries, in most cases, and the pins for Columbs, Dayton, and other Ohio locations all pops up at the same pixel location, etc.). Can I just point out Terry, that this is a map of Perl user groups? We're not NORAD and they aren't suspected sites of WMD that we need to target. :-) Sure, if you'll let me point out again that the original poster wanted the maps to be clickable. 8-) 8-). It's really unfortunate that no one seems to be willing to put out the server resources to do real GIS mapping, e.g. using the data specifications at: Right, I'm not sure if you're joking or not, but are you honestly suggesting that somebody writes a GIS based map rendering system using a relatively complicated set of standards so that people can get 3D representations of where the nearest Perl Mongers group is? Nope. We could care less about where the Perl groups are, we want the FreeBSD folks. 8-). A GIS map rendering system would be a very nice thing, given that people keep asking for applications which require a GIS map rendering system, instead of calling for the missing tools that would be needed to create such a thing. IMO, it actually would not be that difficult a thing to implement; the big issue to address would be correlation of projections of data points to projection origin coordinates, standard parallels, scale, and projection type. A map wonk could do these rather easily... heck, *I* could do these rather easily, if I wanted to burn the time on it: it's no harder than a ray tracer, for example. I'm actually writing a proposal at the moment that might go up to BSDCon or maybe somewhere else entitled Why Open Source Software will Ultimately Fail in a Commercial Context. The core argument is that as OSS developers are unpaid, they'll work on whatever they want - i.e. what they think is cool or what they need to get a particular job done. Nobody here at the age of 15 thought they wanted to write word processors or spreadsheets when they grew up, right? Do you mind if I cite this example anonymously as a re-enforcement of my argument? :-) Your conclusion is correct, but your argument is flawed (or it at least doesn't agree with any of my arguments 8-)). I don't think this would be a good example, because if you used it, I might have to do the work necessary just to spite you, and because a member of the USGS EROS Data Center suggested it to me once, on a plane trip, and gave me a CDROM of all the Open Source stuff they were already using. 8-). Seriosuly Terry, I can't tell if you were joking or not, but nobody is going to play with opengis stuff, just because it would be a neat way of showing where user groups are. :-) I didn't expect them to; I rather expect that the people who play with it are going to be USGS employees, NOA employees, or NASA employees, where it relates to something they have to do for their day job anyway. The only thing the FreeBSD folks would be giving them is a set of sample coordinates, and a bunch of technical people who would Oohhh! and Aaahhh! at their work after it's done. Add to that the almost criminally insane advocacy of XML for storing all data, everywhere!, and you have the necessary mix for at least a core set of people to involve themselves in a project. FWIW: the important gateing factors on any Open Source project are: 1) Motivation (a problem to solve, that people can agree on) 2) Working code (something that comes close to solving the problem, or from which people can see a solution) 3) Community (communications and peers to provide a context in which the work can take place) A lot of people have #1, so they declare a Source Forge project, try to cookie-cutter #3 (impossible to do), and leverage having #1 and #3 into someone creating #2 (also impossible to do). Mozilla had #1, some of #3, and almost none of #2 for a very, very long time, and it's still suffering the backlash from it (for example). BSD did not take off until Bill Jolitz made it boot. Fetchmail sort of works, but no one cares. Etc.. As a matter of fact, I claim that, given any #2, I can *find* #1, and *create* #3. It's trivially easy to start Open Source projects by the dozens, if you are even a halfway decent coder: just make something good enough to work, but lacking enough to convince a group of people that they could (and should) improve it, rewrite it, or otherwise do better. That sounds like most modern commercial software, to me, since it's got legacy design factors from the 1980's/1990's causing it to need documentation, support, and training materials as part of the (no longer relevent) copy protection systems that grew up around the software
Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Hi,
I have been playing with signals handling and I've found one thing where
FreeBSD differes from other unix systems that I have access to. This test loops
endlessly in FreeBSD but terminates in SunOS 9 and GNU/Linux. It is as test for
what happens when a program raises SIGSEGV in SIGSEGV handler. If this touches
undefined behaviour then I think the behaviour of the other two systems is
saner.
Vaclav Haisman
#include signal.h
#include iostream
int f (int * x);
void handler (int, siginfo_t * info, ucontext_t * uap)
{
std::cerr SIGSEGV caught, dumping core std::endl;
struct sigaction mysig;
mysig.sa_handler = SIG_IGN;
mysig.sa_sigaction = NULL;
mysig.sa_flags = 0;
if (sigaction(SIGSEGV, mysig, NULL) == -1)
{
std::cerr Error in sigaction() std::endl;
return;
}
f((int*)NULL);
mysig.sa_handler = SIG_DFL;
mysig.sa_sigaction = NULL;
mysig.sa_flags = 0;
if (sigaction(SIGSEGV, mysig, NULL) == -1)
{
std::cerr Error in sigaction() std::endl;
return;
}
}
int f (int * x)
{
int y = *x;
return y;
}
int main ()
{
struct sigaction mysig;
mysig.sa_handler = NULL;
mysig.sa_sigaction = (void (*)(int, __siginfo *, void *))handler;
sigemptyset(mysig.sa_mask);
sigaddset(mysig.sa_mask, SIGSEGV);
mysig.sa_flags = SA_SIGINFO;
if (sigaction(SIGSEGV, mysig, NULL) == -1)
{
std::cerr Error in sigaction() std::endl;
return 1;
}
int * x = NULL;
int y;
y = f(x);
return y;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Vaclav Haisman wrote: I have been playing with signals handling and I've found one thing where FreeBSD differes from other unix systems that I have access to. This test loops endlessly in FreeBSD but terminates in SunOS 9 and GNU/Linux. It is as test for what happens when a program raises SIGSEGV in SIGSEGV handler. If this touches undefined behaviour then I think the behaviour of the other two systems is saner. man 2 abort -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
man 2 abort -- Terry logout ~/tmpman 2 abort No entry for abort in section 2 of the manual Besides, this doesn't explain anything. I see I haven't asked any question in my previous post. So, why does FreeBSD behave different? Vaclav Haisman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
changes in tcp6_input.c and tcp6_output.c
Respected Sir I have made some changes to the /usr/kame/kame/kame/sys/netinet6/tcp6_input.c and /usr/kame/kame/kame/netinet6/sys/tcp6_output.c in FreeBSD 4.4 and iam using Kame snap. I have some queries regarding making the changes active. Can anyone please tell me the procedure to recompile or reconfigure the kernel so that the changes come into effect I would be grateful to you, if you could let me know these questions Thanks for the help and sorry for the disturbance. Best Regards Dev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Packet length 1284 instead of 1280
Sir / Madam I am doing my research on fragmentation avoidance technique for mip6. I am using FreeBSD4.4 with kame snap and ethereal to capture packets I have a query regarding the packet length If i am correct , packet length = IPHdr +extHdr+TCPHdr+TCPOpt+Data =IPHdr+Routing Header + Frag Header + TCP Header+ Tcpopt+ Data 40+24+8+20+12+1176=1280 (Which is the MTU of the gif0 interface) But my ethereal capture says the packet length to be 1284 btyes. Can anyone please let me know what that 4 bytes is accounted for? With this mail, i am pasting a capture packet of my experiment Frame 973 (1284 on wire 1284 captured) Arrival Time: Dec 6 2002 39:54.8 Time delta from previous packet: 0.52 seconds Time relative to first packet: 97.69262 seconds Frame Number: 973 Packet Length: 1284 bytes Capture Length: 1284 bytes Null/Loopback Family: IPv6 (0x001c) Internet Protocol Version 6 Version: 6 Traffic class: 0x00 Flowlabel: 0x6017f Payload length: 1240 Next header: IPv6 routing (0x2b) Hop limit: 64 Source address: 2001:618:400::8949:b94 (2001:618:400::8949:b94) Destination address: 3ffe:400b:6004:3:200:39ff:fe11:f32 (3ffe:400b:6004:3:200:39ff:fe11:f32) Routing Header Type 0 Next header: IPv6 fragment (0x2c) Length: 2 (24 bytes) Type: 0 Segments left: 1 address 0:00 3ffe:327e:2:1:200:39ff:fe11:f32 (3ffe:327e:2:1:200:39ff:fe11:f32) Fragmention Header Next header: TCP (0x06) Offset: 0 More fragments: Yes Identification: 0xef9a Transmission Control Protocol Src Port: 49165 -49165 Dst Port: iad2 -1031 Seq: 2.68E+09 Ack: 1.12E+09 Source port: 49165 -49165 Destination port: iad2 -1031 Sequence number: 2.68E+09 Next sequence number: 2.68E+09 Acknowledgement number: 1.12E+09 Header length: 32 bytes Flags: 0x0010 (ACK) 0... = Congestion Window Reduced (CWR): Not set .0.. = ECN-Echo: Not set ..0. = Urgent: Not set ...1 = Acknowledgment: Set 0... = Push: Not set .0.. = Reset: Not set ..0. = Syn: Not set ...0 = Fin: Not set Window size: 16912 Checksum: 0x7783 Options: (12 bytes) NOP NOP Time stamp: tsval 1931258 tsecr 159233 Data (1176 bytes) Here the packet length is 1284 instead of 1280. Can anyone please explain me the situation . Is it because of any header or something else. Best Regards Dev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tyan S4520 GCHE
Brian Buchanan wrote: I'm having problems getting SMP to work on a Tyan S4520 Thunder GCHE motherboard with 4x 1.9GHz Xeon processors: Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 Programming 16 pins in IOAPIC #2 AP #1 (PHY# 2) failed! panic y/n? [y] AP #2 (PHY# 4) failed! panic y/n? [y] AP #3 (PHY# 6) failed! panic y/n? [y] This is under FreeBSD 4.7-RELEASE. I also tried a recent -STABLE build and 5.0-RELEASE, with the same results. I made similar problem known here about middle-January. John Baldwin told me there is standing problem with APICs on 7500SW2 motherboards. Possible solution he suggested was: You can try to change bus_clock from 6600 to 53300 in sys/i386/i386/mpapic.c and see if that helps. This didn't help me (I couldn't even pass panic (y/n) with no). See if it helps you. What really concerns me now is 5.0-RELEASE with all the SMPng can't cope with the problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
IPFW changes.
I would like to make some changes to IPFW, specifically, I would like to add a function that would simulate fwd, but also change the destination address. I know this can be done with natd, but would like to have it native, so I can manipulate the packets in certain ways. My questions are this: 1: What is the best FBSD list for finding out who (if anyone) is also working on IPFW and what new features are planned, and; 2: Where can the source files for IPFW be found on a clean install? I do have IPFW source files on my Thinkpad, but only in the compile directory. (Indicating that they appeared only AFTER I compiled my own custom kernel). Tks, Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
On Wednesday 19 February 2003 04:43, Vaclav Haisman wrote: man 2 abort -- Terry logout ~/tmpman 2 abort No entry for abort in section 2 of the manual Yeah, it's in (3). try _exit(2). Besides, this doesn't explain anything. I see I haven't asked any question in my previous post. So, why does FreeBSD behave different? Because it *is* different? If you want to catch a signal and be able to handle it, the other two are wrong, are they not? The idea here is to catch SEGV and be able to respond to it in some reasonable fashion. What that reasonable fashion might be is left up to the program, that's why we have signal handlers. You might for instance want to close open files or disconnect from a database connection. What if the file close or database socket close yeilds another SEGV? Do you want to just abruptly die, or do you want to at least be able to attempt to log this condition? You can always count the number of SEGVs you've handled with a static counter and modify your behavior accordingly. What would you like to see, a sigaction flag of SA_CRASHON2NDSIG that is set by default? (Ah, Wes, that software comedian.) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
On Tuesday 18 February 2003 22:36, Peter Jeremy wrote: I see this as a major advantage of arc4random() - if I want 32-bit random numbers I don't have to call random() twice and merge the results. I've never understood why random() was specified to return a '0' in the MSB. It probably had something to do with the PDP-11 architecture. This rings a bell, but I can't recall what it was. Greg Lehey might be able to help here, he has far better knowlege of the Good Old Days(tm) than I do. I'd ask Mike Murphy, the resident UNIX graybeard, but he's not in yet. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Packet length 1284 instead of 1280
Audsin wrote: Sir / Madam I am doing my research on fragmentation avoidance technique for mip6. I am using FreeBSD4.4 with kame snap and ethereal to capture packets I have a query regarding the packet length If i am correct , packet length = IPHdr +extHdr+TCPHdr+TCPOpt+Data =IPHdr+Routing Header + Frag Header + TCP Header+ Tcpopt+ Data 40+24+8+20+12+1176=1280 (Which is the MTU of the gif0 interface) But my ethereal capture says the packet length to be 1284 btyes. Can anyone please let me know what that 4 bytes is accounted for? Can't help you with your question, but if you're using 4.4-RELEASE, the KAME -SNAP you're using must be ancient. There have been many fixes, especially to the MIP6 code, so upgrading to a recent -SNAP may simply make the problem go away. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Simply impossible to format disk under current.
I ran into an interesting problem last night ... that was very frustrating. I was recycling SCSI drives from some NetBSD machines (that were client boxes) to add to a RAID server running FreeBSD-5.0-RELEASE. It's simply impossible to format NetBSD drives under current. Let me expand on that. /dev/da2 exists, but you can't say 'fdisk -I da2' ... fdisk says that /dev/da2 doesn't exist. /dev/da2 (and /dev/da2c) isn't writable, so I can't blank the first few sectors. I even tried this in single user mode. The problem appears to be that the FreeBSD-5.0 system sees the NetBSD label ... so things like da2s1 don't exist. da2a, da2b, da2c and da2g do. These are the NetBSD partitions. Writing to them is verboten. I was hoping that da2c would allow me to blank the boot sector, but it doesn't allow me to write. ... under FreeBSD-5.0, fdisk won't write to the disk and disklabel won't change the NetBSD label, either. I had to boot with my FreeBSD-4.7 recovery CD ... which would fdisk and disklabel the disk (note that fdisking wasn't enough ... FreeBSD still accepted the NetBSD label over the fdisk data) just fine. ... although I then ran into the issue that disklabel -e had /mnt2/stand/vi hardcoded into it ... which is wrong. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hi!Dear FreeBSD!
On Wed, Feb 19, 2003 at 11:38:23AM -, Paul Robinson wrote: Terry Lambert wrote: None of those maps are clickable. They're actually just *tiny* PNGs of maps-with-pins-in-them, with no obvious correlation to real location data associated with PERL (e.g. number of pins is not equal to number of page entries, in most cases, and the pins for Columbs, Dayton, and other Ohio locations all pops up at the same pixel location, etc.). Can I just point out Terry, that this is a map of Perl user groups? We're not NORAD and they aren't suspected sites of WMD that we need to target. :-) It's really unfortunate that no one seems to be willing to put out the server resources to do real GIS mapping, e.g. using the data specifications at: Right, I'm not sure if you're joking or not, but are you honestly suggesting that somebody writes a GIS based map rendering system using a relatively complicated set of standards so that people can get 3D representations of where the nearest Perl Mongers group is? I'm actually writing a proposal at the moment that might go up to BSDCon or maybe somewhere else entitled Why Open Source Software will Ultimately Fail in a Commercial Context. The core argument is that as OSS developers are unpaid, they'll work on whatever they want - i.e. what they think is cool or Hmm, an Open Source remote sensing satellite would be the ultimate hack of course.. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Thus spake Wes Peters [EMAIL PROTECTED]: What would you like to see, a sigaction flag of SA_CRASHON2NDSIG that is set by default? (Ah, Wes, that software comedian.) Sure, but let's call it SA_RESETHAND. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Ok, IPC jailed.
Hello hackers... I prepared patches against 4.7-STABLE for secure IPC in jail. Main host and every jail has separated IPC memory zones, etc. I have added some sysctls and set-gid on group kmem for ipcs(1) is nomore needed. I could port those patches against 5.x if someone will review and commit it maybe. So, any volunteers?:) Patches are attached. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg40036/pgp0.pgp Description: PGP signature
Re: Ok, IPC jailed.
Sure, send PRs over :) On Wed, 19 Feb 2003 19:43:19 +0100 Pawel Jakub Dawidek [EMAIL PROTECTED] wrote: Hello hackers... I prepared patches against 4.7-STABLE for secure IPC in jail. Main host and every jail has separated IPC memory zones, etc. I have added some sysctls and set-gid on group kmem for ipcs(1) is nomore needed. I could port those patches against 5.x if someone will review and commit it maybe. So, any volunteers?:) Patches are attached. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ok, IPC jailed.
On Wed, Feb 19, 2003 at 07:43:19PM +0100, Pawel Jakub Dawidek wrote:
+ Patches are attached.
Now!:)
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
diff -ru /sys/compat/linux/linux_ipc.c sys/compat/linux/linux_ipc.c
--- /sys/compat/linux/linux_ipc.c Wed Feb 19 19:29:13 2003
+++ sys/compat/linux/linux_ipc.cWed Feb 19 18:02:21 2003
@@ -25,7 +25,7 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
- * $FreeBSD: src/sys/compat/linux/linux_ipc.c,v 1.17.2.3 2001/11/05 19:08:22 marcel
Exp $
+ * $FreeBSD$
*/
#include sys/param.h
@@ -34,6 +34,7 @@
#include sys/proc.h
#include sys/sem.h
#include sys/shm.h
+#include sys/jail.h
#include machine/../linux/linux.h
#include machine/../linux/linux_proto.h
@@ -222,6 +223,12 @@
int error;
union semun *unptr;
caddr_t sg;
+ struct sempriv *sp;
+
+ if (p-p_prison == NULL)
+ sp = mainsem;
+ else
+ sp = p-p_prison-pr_sem;
sg = stackgap_init();
@@ -278,7 +285,7 @@
sizeof(linux_seminfo) );
if (error)
return error;
- bcopy(seminfo, linux_seminfo, sizeof(linux_seminfo) );
+ bcopy(sp-seminfo, linux_seminfo, sizeof(linux_seminfo) );
/* XXX BSD equivalent?
#define used_semids 10
#define used_sems 10
@@ -289,7 +296,7 @@
sizeof(linux_seminfo) );
if (error)
return error;
- p-p_retval[0] = seminfo.semmni;
+ p-p_retval[0] = sp-seminfo.semmni;
return 0; /* No need for __semctl call */
case LINUX_GETALL:
/* FALLTHROUGH */
diff -ru /sys/kern/kern_exit.c sys/kern/kern_exit.c
--- /sys/kern/kern_exit.c Wed Feb 19 19:29:13 2003
+++ sys/kern/kern_exit.cWed Feb 19 18:38:38 2003
@@ -36,11 +36,12 @@
* SUCH DAMAGE.
*
* @(#)kern_exit.c 8.7 (Berkeley) 2/12/94
- * $FreeBSD: src/sys/kern/kern_exit.c,v 1.92.2.11 2003/01/13 22:51:16 dillon Exp $
+ * $FreeBSD$
*/
#include opt_compat.h
#include opt_ktrace.h
+#include opt_sysvipc.h
#include sys/param.h
#include sys/systm.h
@@ -57,6 +58,7 @@
#include sys/ptrace.h
#include sys/acct.h /* for acct_process() function prototype */
#include sys/filedesc.h
+#include sys/msg.h
#include sys/shm.h
#include sys/sem.h
#include sys/aio.h
@@ -510,6 +512,15 @@
if (p-p_prison !--p-p_prison-pr_ref) {
if (p-p_prison-pr_linux != NULL)
FREE(p-p_prison-pr_linux, M_PRISON);
+#ifdef SYSVMSG
+ msgclear(p-p_prison);
+#endif
+#ifdef SYSVSEM
+ semclear(p-p_prison);
+#endif
+#ifdef SYSVSHM
+ shmclear(p-p_prison);
+#endif
FREE(p-p_prison, M_PRISON);
}
diff -ru /sys/kern/kern_jail.c sys/kern/kern_jail.c
--- /sys/kern/kern_jail.c Wed Feb 19 19:29:13 2003
+++ sys/kern/kern_jail.cWed Feb 19 19:29:09 2003
@@ -6,10 +6,12 @@
* this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
*
*
- * $FreeBSD: src/sys/kern/kern_jail.c,v 1.6.2.3 2001/08/17 01:00:26 rwatson Exp $
+ * $FreeBSD$
*
*/
+#include opt_sysvipc.h
+
#include sys/param.h
#include sys/types.h
#include sys/kernel.h
@@ -21,6 +23,9 @@
#include sys/jail.h
#include sys/socket.h
#include sys/sysctl.h
+#include sys/msg.h
+#include sys/sem.h
+#include sys/shm.h
#include net/if.h
#include netinet/in.h
@@ -39,10 +44,12 @@
jail_socket_unixiproute_only, 0,
Processes in jail are limited to creating UNIX/IPv4/route sockets only);
-intjail_sysvipc_allowed = 0;
+#if defined(SYSVMSG) || defined(SYSVSEM) || defined(SYSVSHM)
+intjail_sysvipc_allowed = 1;
SYSCTL_INT(_jail, OID_AUTO, sysvipc_allowed, CTLFLAG_RW,
jail_sysvipc_allowed, 0,
Processes in jail can use System V IPC primitives);
+#endif
int
jail(p, uap)
@@ -75,7 +82,32 @@
error = chroot(p, ca);
if (error)
goto bail;
-
+#ifdef SYSVMSG
+ error = msginit(pr);
+ if (error != 0)
+ goto bail;
+#endif
+#ifdef SYSVSEM
+ error = seminit(pr);
+ if (error != 0) {
+#ifdef SYSVMSG
+ msgclear(pr);
+#endif
+ goto bail;
+ }
+#endif
+#ifdef SYSVSHM
+ error = shminit(pr);
+ if (error != 0) {
+#ifdef SYSVMSG
+ msgclear(pr);
+#endif
+#ifdef SYSVSEM
+ semclear(pr);
+#endif
+ goto bail;
+ }
+#endif
pr-pr_ref++;
p-p_prison = pr;
Re: Ok, IPC jailed.
On Wed, 19 Feb 2003 19:45:52 +0100 Pawel Jakub Dawidek [EMAIL PROTECTED] wrote: On Wed, Feb 19, 2003 at 07:43:19PM +0100, Pawel Jakub Dawidek wrote: + Patches are attached. Now!:) Please resubmit your patch as PR to ensure it will not get lost. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IPFW changes.
On Wednesday 19 February 2003 10:20 am, IAccounts wrote: 1: What is the best FBSD list for finding out who (if anyone) is also working on IPFW and what new features are planned, and; The IPFW list could help ([EMAIL PROTECTED]). To see who is working on it, look at the commit logs (e.g. http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ipfw.c). Luigi Rizzo does a lot of the work with it. 2: Where can the source files for IPFW be found on a clean install? I do have IPFW source files on my Thinkpad, but only in the compile directory. (Indicating that they appeared only AFTER I compiled my own custom kernel). If you installed a source tree in the standard place (/usr/src), look in /usr/src/sbin/ipfw. -David -- http://www.seektruth.org Astronomy and Astrophysics Center The University of Chicago To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
scan_ffs for UFS2
Hello!
I am trying to learn scan_ffs (original from OpenBSD, ported to FreeBSD
by Robert Watson) about UFS2 on 5-CURRENT, but it will not find the
Superblock and I dont understand exactly both for loops, especially
that 512 byte increment.
Scan_ffs is a system tool from OpenBSD to recover erased disklabels
from your hard drive.
Thanks for your input.
--
/\/\ichael Ranner
[EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED]
--
JAWA Management Software GmbH - http://www.jawa.at/
Liebenauer Hauptstrasse 2oo - A-8041 Graz
Tel +43 316 403274 21 - Fax +43 316 403274 10
--
Mariazell Online - http://www.mariazell.at/
--
-BEGIN GEEK CODE BLOCK-
GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS$ P+$ L-(+)$ E---
W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+++ PE(-) Y+ PGP(-)
t+ 5+ X+++() R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y?
--END GEEK CODE BLOCK--
/* $OpenBSD: scan_ffs.c,v 1.8 2002/07/03 22:32:33 deraadt Exp $ */
/*
* Copyright (c) 1998 Niklas Hallqvist, Tobias Weingartner
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:
*This product includes software developed by Tobias Weingartner.
* 4. The name of the author may not be used to endorse or promote products
*derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include sys/types.h
#include sys/param.h
#include sys/fcntl.h
#ifdef __FreeBSD__
#include ufs/ufs/dinode.h
#endif
#include ufs/ffs/fs.h
#include unistd.h
#include stdlib.h
#include stdio.h
#include string.h
#include time.h
#include err.h
#if 0
#include util.h
#endif
#ifdef __FreeBSD__
#define SBSIZE SBLOCKSIZE
#endif
#define SBCOUNT 64 /* XXX - Should be configurable */
/* Flags to control ourselves... */
#define FLAG_VERBOSE 1
#define FLAG_SMART 2
#define FLAG_LABELS 4
int
ufsscan(int fd, daddr_t beg, daddr_t end, int flags)
{
static char lastmount[MAXMNTLEN];
static u_int8_t buf[SBSIZE * SBCOUNT];
struct fs *sb;
daddr_t blk, lastblk;
int n;
lastblk = -1;
memset(lastmount, 0, MAXMNTLEN);
for (blk = beg; blk = ((end0)?blk:end); blk += (SBCOUNT*SBSIZE/512)){
memset(buf, 0, SBSIZE * SBCOUNT);
if (lseek(fd, (off_t)blk * 512, SEEK_SET) 0)
err(1, lseek);
if (read(fd, buf, SBSIZE * SBCOUNT) 0)
err(1, read);
for (n = 0; n (SBSIZE * SBCOUNT); n += 512){
sb = (struct fs*)(buf[n]);
if ((sb-fs_magic == FS_UFS1_MAGIC) ||
(sb-fs_magic == FS_UFS2_MAGIC)) {
if (flags FLAG_VERBOSE)
printf(block %d id %x,%x size %d\n,
blk + (n/512), sb-fs_id[0],
sb-fs_id[1], sb-fs_size);
if (((blk+(n/512)) - lastblk) == (SBSIZE/512)) {
if (flags FLAG_LABELS ) {
#ifdef __FreeBSD__
printf(X: %lld %lld 4.2BSD %ld %ld %ld # %s\n,
#else
printf(X: %d %d 4.2BSD %d %d %d # %s\n,
#endif
(daddr_t)((off_t)sb-fs_size *
sb-fs_fsize / 512),
blk+(n/512)-(2*SBSIZE/512),
sb-fs_fsize, sb-fs_bsize,
sb-fs_old_cpg, lastmount);
} else {
#ifdef __FreeBSD__
printf(ufs1 at %lld size %lld mount %s time %s\n,
#else
printf(ffs1 at %d size %lld mount %s time %s\n,
#endif
blk+(n/512)-(2*SBSIZE/512),
(long long)(off_t)sb-fs_size *
sb-fs_fsize,
lastmount, ctime((time_t *)sb-fs_time));
}
if (flags FLAG_SMART) {
off_t size = (off_t)sb-fs_size *
sb-fs_fsize;
if ((n + size) (SBSIZE * SBCOUNT))
n +=
Re: scan_ffs for UFS2
Am Mittwoch, 19. Februar 2003 22:20 schrieb Michael Ranner:
Hello!
I am trying to learn scan_ffs (original from OpenBSD, ported to FreeBSD
by Robert Watson) about UFS2 on 5-CURRENT, but it will not find the
Superblock and I dont understand exactly both for loops, especially
that 512 byte increment.
Ok, now scan_ffs can detect a UFS2 filesystem, but scan_ffs does
not calculate the correct offset for the disklabel. Further I do
not unterstand the smart feature of scan_ffs fully at the moment.
Where to I find CPG in an UFS2 superblock? How can I detect, if
scan_ffs should display fs_old_cpg or the new cpg value. Which
fields hold the new cpg value in the superblock?
Regards,
--
/\/\ichael Ranner
[EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED]
--
JAWA Management Software GmbH - http://www.jawa.at/
Liebenauer Hauptstrasse 2oo - A-8041 Graz
Tel +43 316 403274 21 - Fax +43 316 403274 10
--
Mariazell Online - http://www.mariazell.at/
--
-BEGIN GEEK CODE BLOCK-
GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS$ P+$ L-(+)$ E---
W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+++ PE(-) Y+ PGP(-)
t+ 5+ X+++() R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y?
--END GEEK CODE BLOCK--
/* $OpenBSD: scan_ffs.c,v 1.8 2002/07/03 22:32:33 deraadt Exp $ */
/*
* Copyright (c) 1998 Niklas Hallqvist, Tobias Weingartner
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:
*This product includes software developed by Tobias Weingartner.
* 4. The name of the author may not be used to endorse or promote products
*derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include sys/types.h
#include sys/param.h
#include sys/fcntl.h
#ifdef __FreeBSD__
#include ufs/ufs/dinode.h
#endif
#include ufs/ffs/fs.h
#include unistd.h
#include stdlib.h
#include stdio.h
#include string.h
#include time.h
#include err.h
#if 0
#include util.h
#endif
#ifdef __FreeBSD__
#define SBSIZE SBLOCKSIZE
#endif
#define SBCOUNT 64 /* XXX - Should be configurable */
/* Flags to control ourselves... */
#define FLAG_VERBOSE 1
#define FLAG_SMART 2
#define FLAG_LABELS 4
int
ufsscan(int fd, daddr_t beg, daddr_t end, int flags)
{
static char lastmount[MAXMNTLEN];
static u_int8_t buf[SBSIZE * SBCOUNT];
struct fs *sb;
daddr_t blk, lastblk;
int n;
#ifdef __FreeBSD__
int ufs;
#endif
lastblk = -1;
memset(lastmount, 0, MAXMNTLEN);
for (blk = beg; blk = ((end0)?blk:end); blk += (SBCOUNT*SBSIZE/512)){
memset(buf, 0, SBSIZE * SBCOUNT);
if (lseek(fd, (off_t)blk * 512, SEEK_SET) 0)
err(1, lseek);
if (read(fd, buf, SBSIZE * SBCOUNT) 0)
err(1, read);
for (n = 0; n (SBSIZE * SBCOUNT); n += 512){
#ifdef __FreeBSD__
ufs = 0;
#endif
sb = (struct fs*)(buf[n]);
#ifdef __FreeBSD__
if (sb-fs_magic == FS_UFS1_MAGIC)
ufs = 1;
if (sb-fs_magic == FS_UFS2_MAGIC)
ufs = 2;
if (ufs 0) {
#else
if (sb-fs_magic == FS_MAGIC)
#endif
if (flags FLAG_VERBOSE)
printf(block %d id %x,%x size %d\n,
blk + (n/512), sb-fs_id[0],
sb-fs_id[1], sb-fs_size);
#ifdef __FreeBSD__
if (((blk+(n/512)) - lastblk) == (SBSIZE*ufs/512)) {
#else
if (((blk+(n/512)) - lastblk) == (SBSIZE/512)) {
#endif
if (flags FLAG_LABELS ) {
#ifdef __FreeBSD__
printf(X: %lld %lld 4.2BSD %ld %ld %ld # %s\n,
#else
printf(X: %d %d 4.2BSD %d %d %d # %s\n,
#endif
(daddr_t)((off_t)sb-fs_size *
Re: bleh. Re: ufs_rename panic
Just reminder that this problem is local kernel panic DoS (which can do filesystem corruption) with very simple trigger code and it still exists. And it's been almost 2 years since i wrote about it. Workaround (commenting out panic call) doesnt fix the problem. Server still crashes (not so often though) from virtual memory failures like this: panic: vm_fault: fault on nofault entry, addr: d0912000 mp_lock = 0102; cpuid = 1; lapic.id = boot() called on cpu#1 (kgdb) bt #0 0xc0175662 in dumpsys () #1 0xc017542c in boot () #2 0xc0175894 in poweroff_wait () #3 0xc01e7c18 in vm_fault () #4 0xc0219d32 in trap_pfault () #5 0xc021990b in trap () #6 0xc01e008a in ufs_dirrewrite () #7 0xc01e31a4 in ufs_rename () #8 0xc01e4645 in ufs_vnoperate () #9 0xc01a9121 in rename () #10 0xc021a44d in syscall2 () #11 0xc02077cb in Xint0x80_syscall () How can i help to resolve this problem ASAP? Thanks! Matt Dillon wrote: Well, I've gone through hell trying to fix the rename()/rmdir()/remove() races and failed utterly. There are far more race conditions then even my last posting indicated, and there are *severe* problems fixing NFS to deal with even Ian's suggestion... it turns out that NFS's nfs_namei() permanently adjusts the mbuf while processing the path name, making restarts impossible. The only solution is to implement namei cache path locking and formalize the 'nameidata' structure, which means ripping up a lot of code because nearly the entire code base currently plays with the contents of 'nameidata' willy-nilly. Nothing else will work. It's not something that I can consider doing now. In the mean time I am going to remove the panic()'s in question. This means that in ufs_rename() the machine will silently ignore the race (not do the rename) instead of panic. It's all that can be done for the moment. It solve the security/attack issue. We'll have to attack the races as a separate issue. The patch to remove the panics is utterly trivial and I will commit it after I test it. -Matt -- Yevgeniy Aleynikov | Sr. Systems Engineer - USE InfoSpace INC 601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 Tel 425.709.8214 | Fax 425.201.6160 | Mobile 425.418.8924 [EMAIL PROTECTED] | http://www.infospaceinc.com Discover what you can do.TM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Hi!Dear FreeBSD!
On Wed, 19 Feb 2003, Paul Robinson wrote: Seriosuly Terry, I can't tell if you were joking or not, but nobody is going to play with opengis stuff, just because it would be a neat way of showing where user groups are. :-) No, but there are active OSS GIS packages - GRASS comes to mind, and I think UMN's MapServer is also OSS. -- Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] | Snail: PO Box 370 [EMAIL PROTECTED]|Belconnen ACT 2616 Web:http://www.andymac.org/|Australia To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bleh. Re: ufs_rename panic
The potentially slow, but utterly effective way to fix this race is to only allow one rename at a time per filesystem. It is implemented by adding a flag in the mount structure and using it to serialize calls to rename. When only one rename can happen at a time, the race cannot occur. If this proves to be too much of a slow down, it would be possible to only serialize directory renames. As these are (presumably) much rarer the slow down would be less noticable. Kirk McKusick =-=-=-=-=-= Date: Wed, 19 Feb 2003 15:10:09 -0800 From: Yevgeniy Aleynikov [EMAIL PROTECTED] To: Matt Dillon [EMAIL PROTECTED] CC: Kirk McKusick [EMAIL PROTECTED], Ian Dowse [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Ken Pizzini [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: bleh. Re: ufs_rename panic X-ASK-Info: Confirmed by User Just reminder that this problem is local kernel panic DoS (which can do filesystem corruption) with very simple trigger code and it still exists. And it's been almost 2 years since i wrote about it. Workaround (commenting out panic call) doesnt fix the problem. Server still crashes (not so often though) from virtual memory failures like this: panic: vm_fault: fault on nofault entry, addr: d0912000 mp_lock = 0102; cpuid = 1; lapic.id = boot() called on cpu#1 (kgdb) bt #0 0xc0175662 in dumpsys () #1 0xc017542c in boot () #2 0xc0175894 in poweroff_wait () #3 0xc01e7c18 in vm_fault () #4 0xc0219d32 in trap_pfault () #5 0xc021990b in trap () #6 0xc01e008a in ufs_dirrewrite () #7 0xc01e31a4 in ufs_rename () #8 0xc01e4645 in ufs_vnoperate () #9 0xc01a9121 in rename () #10 0xc021a44d in syscall2 () #11 0xc02077cb in Xint0x80_syscall () How can i help to resolve this problem ASAP? Thanks! Matt Dillon wrote: Well, I've gone through hell trying to fix the rename()/rmdir()/remove() races and failed utterly. There are far more race conditions then even my last posting indicated, and there are *severe* problems fixing NFS to deal with even Ian's suggestion... it turns out that NFS's nfs_namei() permanently adjusts the mbuf while processing the path name, making restarts impossible. The only solution is to implement namei cache path locking and formalize the 'nameidata' structure, which means ripping up a lot of code because nearly the entire code base currently plays with the contents of 'nameidata' willy-nilly. Nothing else will work. It's not something that I can consider doing now. In the mean time I am going to remove the panic()'s in question. This means that in ufs_rename() the machine will silently ignore the race (not do the rename) instead of panic. It's all that can be done for the moment. It solve the security/attack issue. We'll have to attack the races as a separate issue. The patch to remove the panics is utterly trivial and I will commit it after I test it. -Matt -- Yevgeniy Aleynikov | Sr. Systems Engineer - USE InfoSpace INC 601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 Tel 425.709.8214 | Fax 425.201.6160 | Mobile 425.418.8924 [EMAIL PROTECTED] | http://www.infospaceinc.com Discover what you can do.TM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bleh. Re: ufs_rename panic
McKusick wrote: The potentially slow, but utterly effective way to fix this race is to only allow one rename at a time per filesystem. Can we serialize unprivileged renames per mount as an alternate work around? Later Mark Hittinger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Vaclav Haisman wrote: man 2 abort -- Terry logout ~/tmpman 2 abort No entry for abort in section 2 of the manual Besides, this doesn't explain anything. I see I haven't asked any question in my previous post. So, why does FreeBSD behave different? Because POSIX mandates that it do so? man 3 signal tells us: The handled signal is unblocked when the function returns and the process continues from where it left off when the signal occurred. Unlike previ- ous signal facilities, the handler func() remains installed after a sig- nal has been delivered. If you want this to not happen, you should explicitly uninstall the handler, or you should call abort(3) (or _exit(2), if you don't want to leave a core dump). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: scan_ffs for UFS2
[ Originally crossposted to -hackers and -fs. This reply Bcc'd to -hackers, followups to -fs. ] On Wed, Feb 19, 2003 at 10:20:12PM +0100, Michael Ranner wrote: Scan_ffs is a system tool from OpenBSD to recover erased disklabels from your hard drive. Forgive me if I'm being dense, but what features does scan_ffs provide that are not a subset of the features provided by gpart[0]? Seems like a duplicate wheel to me. [0] - http://www.stud.uni-hannover.de/user/76201/gpart/ or [1] [1] - ports/sysutils/gpart Brandon D. Valentine -- [EMAIL PROTECTED] http://www.geekpunk.net We've been raised on replicas of fake and winding roads, and day after day up on this beautiful stage we've been playing tambourine for minimum wage, but we are real; I know we are real. -- David Berman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Because POSIX mandates that it do so?
man 3 signal tells us:
The handled signal is unblocked when the function returns and the process
continues from where it left off when the signal occurred. Unlike previ-
ous signal facilities, the handler func() remains installed after a sig-
nal has been delivered.
If you want this to not happen, you should explicitly uninstall the
handler, or you should call abort(3) (or _exit(2), if you don't want
to leave a core dump).
Even though this is probably about my misunderstanding of things I post here
the test I used.
Vaclav Haisman
#include signal.h
#include stdlib.h
#include iostream
int f (int * x);
void handler (int, siginfo_t * info, ucontext_t * uap)
{
std::cerr SIGSEGV has been caught std::endl;
struct sigaction mysig;
mysig.sa_handler = SIG_DFL;
mysig.sa_sigaction = NULL;
mysig.sa_flags = 0;
if (sigaction(SIGSEGV, mysig, NULL) == -1)
{
std::cerr Error in sigaction() std::endl;
abort();
}
f((int*)NULL);
/*mysig.sa_handler = SIG_DFL;
mysig.sa_sigaction = NULL;
mysig.sa_flags = 0;
if (sigaction(SIGSEGV, mysig, NULL) == -1)
{
std::cerr Error in sigaction() std::endl;
return;
}*/
}
int f (int * x)
{
int y = *x;
return y;
}
int main ()
{
struct sigaction mysig;
mysig.sa_handler = NULL;
mysig.sa_sigaction = (void (*)(int, __siginfo *, void *))handler;
sigemptyset(mysig.sa_mask);
sigaddset(mysig.sa_mask, SIGSEGV);
mysig.sa_flags = SA_SIGINFO;
if (sigaction(SIGSEGV, mysig, NULL) == -1)
{
std::cerr Error in sigaction() std::endl;
return 1;
}
int * x = NULL;
int y;
y = f(x);
return y;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Per-jail CPU limits?
Mooneer Salem wrote: Hello, I've been looking at the kernel source, in particular the scheduler in the past few weeks. I found a place in kern_switch.c where per-jail CPU controls could be added (in particular, in the kse_reassign() function). From looking at that function, I could loop through td_runq until I either: 1. Found a thread that isn't jailed, 2. Found a jailed thread, but determine it's safe to let it run because it does not go over sysctl-defined limits, or 3. Find no usable thread, in which case the KSE would theoretically switch over to the idle process until it's time to repeat the process again. This should allow the use of the standard FreeBSD scheduler, except for the jail limits. The question is, how do we determine the total CPU used by the jail? I found the kg_estcpu entry in struct ksegrp, which the thread has a pointer to, but would that be enough? Is there a different approach we could take that would solve this problem? A rudimentary CPU usage limiting on per virtual image basis (virtual image can be considered a jailed environment with its own independent network stack instance) was implemented using an algorithm very similar to what you proposed, so you might check the original patch against 4.7-RELEASE kernel at http://www.tel.fer.hr/zec/BSD/vimage/index.html As I didn't have enough time yet to make a usable port to 5.0, my assumptions regarding programming in -CURRENT might be slightly wrong, but I guess you'll have to: 1) extend the jail structure to hold CPU usage accounting information on per-jail basis; 2) update this field when doing normal per-process CPU accounting in kern/kern_clock.c / statclock(); 3) do some decay filtering to ensure stability and smoothness of the acquired per-jail CPU usage data; 4) in kern/kern_switch.c / chooseproc() implement the steps you originally defined as 1. to 3. 5) on each HZ tick in kern/kern_synch.c / schedclock() check the current process/jail hasn't consumed more CPU time than it was allowed, and if it has, reschedule a new process. This is necessary to ensure acceptable interactive response for processes/jails running with administratively restricted CPU resources, otherwise the process could consume the entire time quantum (10 ms by default), and would than have to wait annoyingly long in order for the average per-jail CPU usage to drop under the defined threshold. 6) optionally, extend procrunnable() in kern/kern_switch.c to return 0 in case there are over-the-CPU-limit processes in active run queue, in order for idle loop to be able to execute the halt instruction, instead of unnecessarily looping endlessly through chooseproc() until the next clock tick. This can be especially useful on laptops where you don't want a process with CPU usage limit to actually burn the battery power in idle loop, and also burn your lap at the same time :) Note: everything I wrote is based on my experience with 4.7-R kernel, in 5.0 many things have changed replacing process with threads as the atomic entities for scheduling, so probably the function naming and some logic has changed also... Marko To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Vaclav Haisman wrote:
If you want this to not happen, you should explicitly uninstall the
handler, or you should call abort(3) (or _exit(2), if you don't want
to leave a core dump).
Even though this is probably about my misunderstanding of things I post here
the test I used.
[ ... ]
void handler (int, siginfo_t * info, ucontext_t * uap)
{
std::cerr SIGSEGV has been caught std::endl;
struct sigaction mysig;
mysig.sa_handler = SIG_DFL;
mysig.sa_sigaction = NULL;
mysig.sa_flags = 0;
if (sigaction(SIGSEGV, mysig, NULL) == -1)
{
std::cerr Error in sigaction() std::endl;
abort();
}
f((int*)NULL);
This is not legal.
/*mysig.sa_handler = SIG_DFL;
[ ... commented out handler reset code ... ]
I don't understand why you do this.
Performing a NULL pointer dereference in a signal handler for a
signal which is generated by a NULL pointer dereference is not
really a good idea. The signal handler, once entered, masks the
signal. It's possible that the signal handler itself is reset
on exit (this is implementation defined).
The main problem here is that signals are not events, they are
persistent conditions. FreeBSD does not support POSIX queued
signals, at this time, so it's not possible to treat them as
events under any circumstances.
Though there may be issues with stack unwinding, with C++, I
don't think that's your problem. You could try implementing the
same program in C, and determine if it has the same symptoms.
You may also try adding:
memset( mysig, 0, sizeof(struct sigaction));
after the declaration, but prior to your use of the stack
variable. Specifically, I do not see you setting the sa_mask
structure member anywhere, and that could be Bad(tm), particularly
if you were setting masking on the signal that triggered the call,
and then re-triggering it. It's conceivable that the implementation
would check the sa_mask before resetting the handler.
Also, note that any use of functions not in this list:
Base Interfaces
exit() access() alarm() cfgetispeed() cfgetospeed() cfsetispeed()
cfsetospeed() chdir() chmod() chown() close()
creat() dup() dup2() execle() execve() fcntl() fork() fpathconf()
fstat() fsync() getegid() geteuid() getgid() getgroups() getpgrp()
getpid() getppid() getuid() kill() link() lseek() mkdir() mkfifo()
open() pathconf() pause() pipe() raise() read() rename() rmdir()
setgid() setpgid() setsid() setuid() sigaction() sigaddset()
sigdelset() sigemptyset() sigfillset () sigismember() signal()
sigpending() sigprocmask() sigsuspend() sleep() stat() sysconf()
tcdrain() tcflow() tcflush() tcgetattr() tcgetpgrp() tcsendbreak()
tcsetattr() tcsetpgrp() time() times() umask() uname()
unlink() utime() wait() waitpid() write()
Realtime Interfaces
aio_error() clock_gettime() sigpause() timer_getoverrun()
aio_return() fdatasync() sigqueue() timer_gettime()
aio_suspend() sem_post() sigset() timer_settime()
are specifically considered unsafe by POSIX, and their behaviour is
undefined. Specifically:
All functions not in the above table are considered to be
unsafe with respect to signals. In the presence of signals,
all functions defined by this specification will behave as
defined when called from or interrupted by a signal-catching
function, with a single exception: when a signal interrupts
an unsafe function and the signal-catching function calls an
unsafe function, the behaviour is undefined.
I'd say that was exactly the case you were testing with the function
f, and by using cout to do I/O in the handler.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: debugging a repeating panic that does not produce a dump
Mike Tancsa [EMAIL PROTECTED] writes: Fatal trap 12: page fault while in kernel mode mp_lock = 0002; cpuid = 0; lapic.id = 0100 fault virtual address = 0xc6efa8e8 Hmm, different fault address this time. (kgdb) up 6 #6 0xc0174830 in makedev (x=28, y=160) at /usr/src/sys/kern/kern_conf.c:207 These numbers look perfectly valid (cuaia0). The only explanation I can think of is some kind of race, or some kind of corruption. Hopefully somebody more clued than myself will be able to figure it out. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: debugging a repeating panic that does not produce a dump
At 08:39 PM 17/02/2003 +0100, Dag-Erling Smorgrav wrote:
Mike Tancsa [EMAIL PROTECTED] writes:
ns4# nm /kernel | grep \^c0174 | sort
[...]
c01747d4 T makedev
c01748f4 T freedev
This is it (makedev)
Does this actually show the location ?
ns4# gdb -k kernel.debug
[...]
(kgdb) list *0xc0174830
0xc0174830 is in makedev (/usr/src/sys/kern/kern_conf.c:208).
203 if (x == umajor(NOUDEV) y == uminor(NOUDEV))
204 Debugger(makedev of NOUDEV);
205 udev = (x 8) | y;
206 hash = udev % DEVT_HASH;
207 LIST_FOREACH(si, dev_hash[hash], si_hash) {
208 if (si-si_udev == udev)
209 return (si);
210 }
211 if (stashed = DEVT_STASH) {
212 MALLOC(si, struct specinfo *, sizeof(*si), M_DEVT,
(kgdb)
Yep. Looks like si is garbage:
fault virtual address = 0x211e6d36
is most likely the value of si at the time of the crash. It's nowhere
near kernel memory (which starts at 0xc000).
If / when you get a dump, show me the backtrace and the value of x, y
and udev (as reported by gdb operating on the recovered core)
OK, got it today.
ns4# gdb -k /usr/obj/usr/src/sys/smp/kernel.debug vmcore.0
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...Deprecated bfd_read
called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 2627 in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 933 in fill_symbuf
SMP 2 cpus
IdlePTD at phsyical address 0x003d4000
initial pcb at physical address 0x0032ebc0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0002; cpuid = 0; lapic.id = 0100
fault virtual address = 0xc6efa8e8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0174830
stack pointer = 0x10:0xdef1dc4c
frame pointer = 0x10:0xdef1dc58
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 91300 (find)
interrupt mask = none - SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0002; cpuid = 0; lapic.id = 0100
boot() called on cpu#0
syncing disks... 2 2
done
Uptime: 1d22h58m21s
dumping to dev #twed/1, offset 524312
dump 767 766 765 764 763 762 761 760 759 758 757 756 755 754 753 752 751
750 749 748 747 746 745 744 743 742 741 740 739 738 737 736 735 734 733 732
731 730 729 728 727 726 725 724 723 722 721 720 719 718 717 716 715 714 713
712 711 710 709 708 707 706 705 704 703 702 701 700 699 698 697 696 695 694
693 692 691 690 689 688 687 686 685 684 683 682 681 680 679 678 677 676 675
674 673 672 671 670 669 668 667 666 665 664 663 662 661 660 659 658 657 656
655 654 653 652 651 650 649 648 647 646 645 644 643 642 641 640 639 638 637
636 635 634 633 632 631 630 629 628 627 626 625 624 623 622 621 620 619 618
617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 602 601 600 599
598 597 596 595 594 593 592 591 590 589 588 587 586 585 584 583 582 581 580
579 578 577 576 575 574 573 572 571 570 569 568 567 566 565 564 563 562 561
560 559 558 557 556 555 554 553 552 551 550 549 548 547 546 545 544 543 542
541 540 539 538 537 536 535 534 533 532 531 530 529 528 527 526 525 524 523
522 521 520 519 518 517 516 515 514 513 512 511 510 509 508 507 506 505 504
503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485
484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466
465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447
446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428
427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409
408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390
389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371
370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352
351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333
332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314
313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295
294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276
275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257
256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240
Re: arc4random() range
Dag-Erling Smorgrav wrote: [EMAIL PROTECTED] writes: Well, I'm right in principle but wrong in current practice, at the very least make it: #define arc4random31() (arc4random() RAND_MAX) or rather #define arc4random31() (arc4random() % (RAND_MAX + 1)) to avoid relying on RAND_MAX being one less than a power of two. DES Nope. Because RAND_MAX is one less than a power of two, you run into integer overflow problems, which PHK's version avoids. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
Hi, At 17:27 19/2/03, Tim Kientzle wrote: Dag-Erling Smorgrav wrote: [EMAIL PROTECTED] writes: Well, I'm right in principle but wrong in current practice, at the very least make it: #define arc4random31() (arc4random() RAND_MAX) or rather #define arc4random31() (arc4random() % (RAND_MAX + 1)) to avoid relying on RAND_MAX being one less than a power of two. DES Nope. Because RAND_MAX is one less than a power of two, you run into integer overflow problems, which PHK's version avoids. #define arc4random31() (arc4random() % ((unsigned)RAND_MAX + 1)) -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: debugging a repeating panic that does not produce a dump
It only happens when periodic runs, but it on occasion skips a day. Eg. yesterday it did not do it. It only started happening post Jan28th. I can brutalize the server with repeated buildworlds (-j2 through 8) and it is always successful. Its only on periodic that it dies and find is always the process running. Its only with SMP as well on this 'oldish' machine ---Mike At 08:30 PM 19/02/2003 +0100, Dag-Erling Smorgrav wrote: Mike Tancsa [EMAIL PROTECTED] writes: Fatal trap 12: page fault while in kernel mode mp_lock = 0002; cpuid = 0; lapic.id = 0100 fault virtual address = 0xc6efa8e8 Hmm, different fault address this time. (kgdb) up 6 #6 0xc0174830 in makedev (x=28, y=160) at /usr/src/sys/kern/kern_conf.c:207 These numbers look perfectly valid (cuaia0). The only explanation I can think of is some kind of race, or some kind of corruption. Hopefully somebody more clued than myself will be able to figure it out. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Simply impossible to format disk under current.
In message [EMAIL PROTECTED], David Gilbert writes: I ran into an interesting problem last night ... that was very frustrating. I was recycling SCSI drives from some NetBSD machines (that were client boxes) to add to a RAID server running FreeBSD-5.0-RELEASE. It's simply impossible to format NetBSD drives under current. Let me expand on that. /dev/da2 exists, but you can't say 'fdisk -I da2' ... fdisk says that /dev/da2 doesn't exist. /dev/da2 (and /dev/da2c) isn't writable, so I can't blank the first few sectors. I even tried this in single user mode. /dev/da2 is always writable unless you have any of the partitions open. I guess you have whacked the disk now, so I won't be able to get any debugging information. In case of disk/GEOM related problems, I need the output from dmesg sysctl -b kern.geom.confxml or I won't really be able to do debugging... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Simply impossible to format disk under current.
phk == phk [EMAIL PROTECTED] writes: phk /dev/da2 is always writable unless you have any of the partitions phk open. The error was that /dev/da2 didn't exist. I was confused too. fdisk da2 # worked, displyed one slice (3) that was NetBSD fdisk -I da2 # error, /dev/da2 doesn't exist ... it seemed like anything that wrote to da2 would fail, but read worked. phk I guess you have whacked the disk now, so I won't be able to get phk any debugging information. In the process of determining that it worked with 4.7-RELEASE I did format the disk, so I'm not sure that the disk itself is useful. phk In case of disk/GEOM related problems, I need the output from phk dmesg sysctl -b kern.geom.confxml or I won't really be able to do phk debugging... I would bet that any NetBSD root disk installed by the NetBSD installer would exhibit the same problems. It should be easy to duplicate. I don't have a spare disk handy right now... but I might be able to do this in a week or two. I would expect that you can do this on your bench, tho. There wasn't anything special about the NetBSD disks ... they had just been formatted through the install process that NetBSD does. 1.5.2, I think. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
modern (usb) webcam support?
My searches for information on webcam have not found much, except for some sites which say FreeBSD does not support USB web cameras. Is anyone currently working on support for this? Does anyone have any ideas about where one could go to get information about where to start if one was to start writing a driver? (I am about to buy a webcam for use in windows, it would be nice if I could choose a webcam which someone is either writing a driver for or knows where i coudl get information on them so that I could try and write one). Any info appreciated! - jacob ___ Jacob RhodenPhone: +61 3 9844 6102 ITS DivisionEmail: [EMAIL PROTECTED] Melbourne University Mobile: +61 403 788 386 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
