5.0R did (bad) things to my previous FS on ad0s1x
I installed 5.0R on a set of SCSI disks that ran in my box side by side with the 4.7 installed on the IDE drives. I switched in the BIOS to boot the SCSI disks and installed 5.0R there. Then I fsck'ed /dev/ad0s1a,e,f,g and mounted them. Already noticed that - although I shut down the machine smoothly - 5.0 didn't find ad0s1g clean and did a salvage on summary or something. For some reason I booted back into 4.7 on the IDE drives and 4.7 suddenly found all filesystems bad and forced into a filesystem check where on every FS it had to search for an alternate superblock since it detected a mismatch in the summary information on the standard and first alternate superblock. Strange. And I had no backup which I'm doing now quickly :-) -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
300 Modelos de Cartas comerciais, avisos, convites, propostas, etc.
COMUNICADO IMPORTANTE!! Estamos lançando o KIT DE CARTAS COMERCIAIS, que sana suas dúvidas na elaboração de: agradecimentos, atestados e declarações, avisos, cartas de cobrança, cartas em inglês, comunicados, convites, contratos, propostas, empregos, solicitações e pedidos, telegramas, cartas por e-mail, etc. Composto de 02 (dois) disquetes com 150 modelos de documentos cada um, mais livreto 20 páginas, com técnicas de redação comercial. Indicado para: secretárias em geral, gerências, Rh, executivos, estudantes e empresas de toda ordem. Este kit possui um preço ínfimo em relação ao que poderá gerar no aperfeiçoamento da comunicação de sua empresa. Acesse nossa Home Page para mais detalhes: http://www.redacaocartas.ihp.com.br Ps: Caso não queira receber novas mensagens e novidades sobre esse assunto, acesse: http://www.remova-me.ihp.com.br To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: first parameter to select
In message: [EMAIL PROTECTED]
David Cuthbert [EMAIL PROTECTED] writes:
: Given that a poll() descriptor is 12 bytes and fd_set is usually at
: least 128 bytes (does select() copy the entire fd_set? I believe this
: is the case, but don't have access to the source atm), the savings kicks
: in at 12 descriptors.
That's not the case. The source clearly says so, and has been this
way since 4.2BSD.
int
kern_select(struct thread *td, int nd, fd_set *fd_in, fd_set *fd_ou,
fd_set *fd_ex, struct timeval *tvp)
{
...
/*
* Allocate just enough bits for the non-null fd_sets. Use the
* preallocated auto buffer if possible.
*/
nfdbits = roundup(nd, NFDBITS);
ncpbytes = nfdbits / NBBY;
...
#define getbits(name, x) \
do {\
if (name == NULL) \
ibits[x] = NULL;\
else { \
ibits[x] = sbp + nbufbytes / 2 / sizeof *sbp; \
obits[x] = sbp; \
sbp += ncpbytes / sizeof *sbp; \
error = copyin(name, ibits[x], ncpbytes); \
if (error != 0) \
goto done_nosellock;\
} \
} while (0)
getbits(fd_in, 0);
getbits(fd_ou, 1);
getbits(fd_ex, 2);
So clearly only the part of the select set that's passed in with fd is
used. Most programs I've seen actually pass in fn as max(fd,...) + 1.
So if you have only a few sockets, or less than 96/N (N is the number
of fd_sets you are using), select's copyin/out mechanism moves fewer
bits accross the kernel transom.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: first parameter to select
On Fri, Mar 14, 2003 at 05:35:16PM +1100, Peter Jeremy wrote:
On Thu, Mar 13, 2003 at 06:50:18PM +0200, Enache Adrian wrote:
I have no benchmarks, but judging after the way things are implemented
in the FreeBSD kernel, select() is definitely faster.
Can you explain what leads you to make this statement please.
But poll() swaps a _LOT_ more data between the kernel and userland !
Please someone explain me what is meant in select(2) by:
If nfds is greater than the number of open files, select() is not guaran-
teed to examine the unused file descriptors. For historical reasons,
select() will always examine the first 256 descriptors.
The second sentence appears to be an error. I can't find anything in
the current code (or previous versions) that suggests select() would
ever examine more than nfd FDs. The only reference to 256 is can find
is that FD_SETSIZE used to be 256 and select() used to return EINVAL if
nfd FD_SETSIZE.
It probably wants to say ( in a manner quite confusing for a non
english speaker like me ) that select(2) won't bother to return EINVAL
for bad file descriptors which are in the bitmaps and are both greater
than the greatest open file descriptor and greater than 255.
That's only half wrong. :-)
select() won't bother to check them even if they are 256. It's
only the greatest open file descriptor that matters.
-- from kern/sys_generic.c:751 - kern_select()
if (nd td-td_proc-p_fd-fd_nfiles)
nd = td-td_proc-p_fd-fd_nfiles; /* forgiving; slightly wrong */
---
Take a look at this little program:
#include sys/select.h
#include unistd.h
int main()
{
fd_set set;
FD_ZERO(set);
FD_SET(0,set);
FD_SET(20,set);
if (select(FD_SETSIZE,set,0,0,0) == -1)
err(1,select);
return 0;
}
change 20 to 19 and select() will return EBADF.
Linux will return EBADF even if you put FD_SETSIZE-1 there.
I find FreeBSD's behaviour reasonable - and I wonder what
'historical' programs pass dummy, never opened fds to select()
in the hope of getting EBADF in return.
Regards
Adi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
variable size too large?
Hi all, I'm writing a little multithread program: in my thread function, I allocated a char variable of IP_MAXPACKET size; when I try to compile it, everything goes well, but when I run it, it dies, making a core file. Assume that: 1) the same code, with only one thread, linked to libc, runs normally 2) the same code, with a smaller variable size, linked to libc_r, runs normally 3) I tried to allocate two variables of 64000 bytes in this function (IP_MAXPACKET is equal to 65535), linked to libc_r and runs normally Where am I wrong? :)) Regards, Ferruccio To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: variable size too large?
default size of thread stack is 65536 bytes you can change it by pthread_attr_setstacksize Naje To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: variable size too large?
On Fri, Mar 14, 2003 at 03:37:29PM +0100, Ferruccio Vitale wrote: Hi all, I'm writing a little multithread program: in my thread function, I allocated a char variable of IP_MAXPACKET size; when I try to compile it, everything goes well, but when I run it, it dies, making a core file. Assume that: 1) the same code, with only one thread, linked to libc, runs normally 2) the same code, with a smaller variable size, linked to libc_r, runs normally 3) I tried to allocate two variables of 64000 bytes in this function (IP_MAXPACKET is equal to 65535), linked to libc_r and runs normally Where am I wrong? :)) It would be very hard to say, without seeing your program and, if possible, the output of a gdb session which shows where exactly the program dies. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If you think this sentence is confusing, then change one pig. pgp0.pgp Description: PGP signature
Disk utilization command
Hi, Can anyone please tell me what is the command and syntax of it that can display how much time in percentage a disk is busy? iostat is supposed to do that, but I could not figure out the syntax. Thanks, -Zhihui -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Disk utilization command
systat -vm gives that, along other useful info. A. On Fri Mar 14, 2003 at 12:47:53PM -0500, Zhihui Zhang wrote: Hi, Can anyone please tell me what is the command and syntax of it that can display how much time in percentage a disk is busy? iostat is supposed to do that, but I could not figure out the syntax. Thanks, -Zhihui -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Quantum bigfoot drive doesn't like DMA?
I recently installed an old Quantum bigfoot drive (CY4320A) in my SMP box running 4.6.2 just to get a little extra space. If I write heavily to it when using WDMA2, the box silently crashes (no panic, just a silent reboot). The box has an DFI motherboard with an Intel BX chipset. It seems similar to problems others have had with this drive (or maybe the combination of this drive and the PIIX4 controller). From the linux-kernel mailing list: http://groups.google.com/groups?hl=enlr=ie=UTF-8th=efa3cf2a3a198ae0seekm=fa.l5mj6dv.i2akim%40ifi.uio.no and also with freebsd (though this guy did not actually suffer a crash): http://www.freebsd.org/cgi/getmsg.cgi?fetch=17576+23166+/usr/local/www/db/text/1999/freebsd-current/19990214.freebsd-current I did run across a Compaq patch for windows 95 and this drive that says it detects the problem and turns off DMA if it happens... It seems to work okay in PIO4 mode. Are there any possible solutions, or am I just stuck with PIO on this drive? I didn't see any commits to the ata code since 4.6.2 whose log message look like they might workaround this problem. thanks, andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
per-open device private data, mmap
To work properly, the DRM needs an area of memory per open of the device which stores information on whether that fd is authenticated and also to have a unique identifier for use in the lock. Currently we use drm_find_file_by_proc to get the private data and use the pid as the unique identifier, but for example this causes problems if a fork occurs (threaded linux programs). This information is needed in the entry points (open, close, ioctl). (read, write, and poll from the current code are being stubbed out because they are unnecessary). To do this, I'm working on following what dev/streams/streams.c does in creating a new struct file and setting its own fileops and using the f_data field for the pointer to the private data. This looks pretty good for open/close/ioctl, but there's a problem with mmap. Currently we use drm_find_file_by_proc in the mmap handler to see if that process is authenticated, but there's no way from the mmap handler to get the private data because the struct file * isn't passed in. My initial thought was to instead check the authentication in the DRM(mapbufs) ioctl, where the vm_mmap is done by the X Server or clients. The problem with this is that a process could still do an mmap() on the fd and avoid the authentication check. What I'm wondering at this point is, is there any way to prevent the mmap() from succeeding (nothing legitimate uses mmap -- it's all done with the mapbufs ioctl), or a way to make it so from the device's mmap handler I can detect whether mmap() or mapbufs made the mapping, or to have different mmap handlers for those two vm_mmap callers. What's the best way to do this? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: per-open device private data, mmap
On Fri, 2003-03-14 at 13:59, Eric Anholt wrote: To work properly, the DRM needs an area of memory per open of the device which stores information on whether that fd is authenticated and also to have a unique identifier for use in the lock. Currently we use drm_find_file_by_proc to get the private data and use the pid as the unique identifier, but for example this causes problems if a fork occurs (threaded linux programs). This information is needed in the entry points (open, close, ioctl). (read, write, and poll from the current code are being stubbed out because they are unnecessary). To do this, I'm working on following what dev/streams/streams.c does in creating a new struct file and setting its own fileops and using the f_data field for the pointer to the private data. This looks pretty good for open/close/ioctl, but there's a problem with mmap. Currently we use drm_find_file_by_proc in the mmap handler to see if that process is authenticated, but there's no way from the mmap handler to get the private data because the struct file * isn't passed in. My initial thought was to instead check the authentication in the DRM(mapbufs) ioctl, where the vm_mmap is done by the X Server or clients. The problem with this is that a process could still do an mmap() on the fd and avoid the authentication check. What I'm wondering at this point is, is there any way to prevent the mmap() from succeeding (nothing legitimate uses mmap -- it's all done with the mapbufs ioctl), or a way to make it so from the device's mmap handler I can detect whether mmap() or mapbufs made the mapping, or to have different mmap handlers for those two vm_mmap callers. What's the best way to do this? Gah, and the instant I hit 'send' I realize that things /do/ use mmap and mapbufs is only for agp/sg memory. I guess it'll be okay to keep drm_find_file_by_proc and grab authentication information from there; it shouldn't be too big of an issue. The unique identifier is the big problem and the fileops trick should work for that. However, is this going to get easier some day? Are there any plans to pass the struct file down to the drivers and have a void * in there for private data? Also, we need to be blocking SIGSTOP and such things while the lock is held so that people don't hang the X Server by suspending a client while it holds the lock. Does anyone know about how to do this? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: per-open device private data, mmap
Eric Anholt writes:
shouldn't be too big of an issue. The unique identifier is the big
problem and the fileops trick should work for that.
However, is this going to get easier some day? Are there any plans to
pass the struct file down to the drivers and have a void * in there for
private data?
I think that phk is working on this for 6.x
In the meantime, I have a new driver Im developing which uses the
fileops trick you describe, but takes it a step further and conjurs up
a new vnode. That makes it work with mmap. I've not run into
any problems yet, but it is lightly tested.
Cheers,
Drew
/*
* Conjure up our own vnode out of thin air. We need the
* vnode so that we can stash a pointer to the per-connection
* priv struct for use in open/close/ioctl and mmap. This is
* tricky, because we need make it look enough like the device
* vnode so that VOP_GETATTR() works on the slave vnode in mmap()
*/
static int
xxx_conjur_vnode(dev_t dev, struct thread *td)
{
int error, fd;
struct filedesc *fdp;
struct file *fp;
struct vnode *vn = NULL, *vd = NULL;
struct cdev *rdev;
fdp = td-td_proc-p_fd;
if (fdp == NULL)
return (0);
if (td-td_dupfd = 0)
return ENODEV;
rdev = xxx_malloc(sizeof(*rdev), M_WAITOK);
if ((error = falloc(td, fp, fd)) != 0)
goto abort_with_rdev;
vd = SLIST_FIRST(dev-si_hlist);
if ((error = getnewvnode(none, vd-v_mount, vd-v_op, vn)))
goto abort_with_falloc;
vn-v_type = VCHR;
/* really should clone v_vdata not copy pointer */
vn-v_data = vd-v_data;/* for VTOI in devfs_getattr() */
/* copy our cdev info */
vn-v_rdev = rdev;
bcopy(vd-v_rdev, vn-v_rdev, sizeof(*rdev));
/* finally, save the data pointer (our softc) */
vn-v_rdev-si_drv2 = 0;
fp-f_data = (caddr_t)vn;
fp-f_flag = FREAD|FWRITE;
fp-f_ops = xxx_fileops;
fp-f_type = DTYPE_VNODE; /* so that we can mmap */
/*
* Save the new fd as dupfd in the proc structure, then we have
* open() return the special error code (ENXIO). Returning with a
* dupfd and ENXIO causes magic things to happen in kern_open().
*/
td-td_dupfd = fd;
return 0;
abort_with_rdev:
xxx_free(rdev);
abort_with_falloc:
FILEDESC_LOCK(fdp);
fdp-fd_ofiles[fd] = NULL;
FILEDESC_UNLOCK(fdp);
fdrop(fp, td);
return (error);
}
static int
xxx_fileclose(struct file *fp, struct thread *td)
{
int ready_to_close;
struct vnode *vn;
struct cdev *rdev;
xxx_port_state_t *ps;
vn = (struct vnode *)fp-f_data;
rdev = vn-v_rdev;
ps = rdev-si_drv2;
rdev-si_drv2 = NULL;
/* replace the vnode ops so that devfs doesn't try to reclaim
anything */
vn-v_op = spec_vnodeop_p;
vn-v_type = VNON; /* don't want to freedev() in vgonel()*/
vgone(vn);
/* free our private rdev */
xxx_free(rdev);
if (ps) {
xxx_mutex_enter(ps-sync);
/* Close the port if there are no more mappings */
ready_to_close = ps-ref_count == 0;
XXX_DEBUG_PRINT (XXX_DEBUG_OPENCLOSE,
(Board %d, port %d closed\n, ps-is-id, ps-port));
xxx_mutex_exit(ps-sync);
if (ready_to_close) {
xxx_common_close (ps);
} else {
XXX_INFO ((Application closed file descriptor while
mappings still alive: port destruct delayed\n));
}
}
return (0);
}
static int
xxx_mmap(dev_t dev, vm_offset_t offset,
#if MMAP_RETURNS_PINDEX == 0
vm_offset_t *paddr,
#endif
int nprot)
{
int status;
xxx_port_state_t *ps;
void *kva;
#if MMAP_RETURNS_PINDEX
vm_offset_t phys;
vm_offset_t *paddr = phys;
#endif
ps = (xxx_port_state_t *)dev-si_drv2;
...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: per-open device private data, mmap
In message [EMAIL PROTECTED], Eric Anholt writes: To work properly, the DRM needs an area of memory per open of the device which stores information on whether that fd is authenticated and also to have a unique identifier for use in the lock. I have some plans for this for 6.x but we would have multiple respiratory failures in the re@ team if I even think about it until the RELENG_5 branch has been laid down, so for now you're on your own. -- 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
increasing KVA_PAGES and broken pthreads
Hello, I'm brand new to this list so feel free to tell me to search the archives if this question has already been answered. I have already done some searching and only found limited and/or antiquated information on the subject, though, so I'm pretty sure this hasn't been addressed yet. Does anyone know if a PR was ever submitted for the issue at: http://www.mail-archive.com/[EMAIL PROTECTED]/msg38532.html I know from reading the thread that a patch was created and sent to this list. Was that patch ever made a part of the CVS tree? If so, what branch would I have to track to pick up that patch? I'd like to avoid adding patches that CVSup will clobber later. I've seen this same issue with FreeBSD 4.5-RELEASE running on a heavily loaded web/mail/database server with dual CPU and 4GB of RAM and 8GB of available swap (no swapping activity). Setting KVA_PAGES=512 rather than the default 256 caused MySQL to die repeatedly with signal 6 as fast as it could respawn itself. The MySQL daemon was compiled on another FreeBSD 4.x system and was part of a prepackaged application from a commercial vendor. I've already tuned the system quite a bit to get around a lot of the large memory issues. However, because of all the tuning to avoid running out of various kernel resources before we ran out of physical RAM, we're now running out of KVM or will very soon. %sysctl -a |grep kvm vm.kvm_size: 1065353216 vm.kvm_free: 4194304 %sysctl kern.maxusers kern.maxusers: 384 (the autoscale max) In particular, we had to take PMAP_SHPGPERPROC up to 1500 from the default of 200 due to the large amount of shared memory pages that Apache needs to do its job efficiently. That puts KVM usage by PV Entries alone to nearly 300MB. We were getting kernel panics every time we ran out of available PV Entries (vm.zone: PV ENTRY), so this was very necessary. We also had to increase NMBCLUSTERS to 12800 (higher than the autoscale max). This also put some pressure on free KVM. We're now tracking RELENG_4_7 (FreeBSD 4.7-RELEASE + security fixes). I haven't tried changing KVA_PAGES since version 4.5 and I'm a little gun-shy on changing that particular tunable since it has so many potential application gotchas, like with pthreads. The RELENG_4_7 CVS tree (updated yesterday) doesn't appear to have the patch mentioned in the thread I referenced in the URL at the beginning of my message. Our version string for that file: * $FreeBSD: src/lib/libc_r/uthread/uthread_init.c,v 1.23.2.7 2001/11/03 00:33:07 peter Exp $ IMHO, this issue could be a royal pain in the butt when I start working on quad processor systems with 32GB of RAM (not unrealistic at this company). I'd like to stay with FreeBSD, but the issues with large memory support are rapidly becoming more prominent due to the *huge* memory systems in use here, with even larger memory systems on the way in the near future. I came from the Linux camp (back when 2.0/2.2 kernels were the newest in use) and I don't want to have to go back, though I no longer have any clue how those boys handle large memory systems. Maybe they're not any better in that department. I just happen to like FreeBSD better and would prefer to stick with it if possible. So, to recap my questions, what branch would I have to track to pick up that patch to pthreads? If there is no branch with that patch, has a PR been submitted so it can eventually be included in the source? If so, what is the PR number? If not, what's the best way to submit a PR? Thanks in advance for any assistance in this matter. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: increasing KVA_PAGES and broken pthreads
On Fri, 14 Mar 2003, Andrew Kinney wrote: Hello, I'm brand new to this list so feel free to tell me to search the archives if this question has already been answered. I have already done some searching and only found limited and/or antiquated information on the subject, though, so I'm pretty sure this hasn't been addressed yet. Does anyone know if a PR was ever submitted for the issue at: http://www.mail-archive.com/[EMAIL PROTECTED]/msg38532.html That patch is in the RELENG_4 tree and will be included in 4.8 I know from reading the thread that a patch was created and sent to this list. Was that patch ever made a part of the CVS tree? If so, what branch would I have to track to pick up that patch? I'd like to avoid adding patches that CVSup will clobber later. yes it was.. but not in RELENG_4_7 because that is for security patches. We're now tracking RELENG_4_7 (FreeBSD 4.7-RELEASE + security fixes). I haven't tried changing KVA_PAGES since version 4.5 and I'm a little gun-shy on changing that particular tunable since it has so many potential application gotchas, like with pthreads. The RELENG_4_7 CVS tree (updated yesterday) doesn't appear to have the patch mentioned in the thread I referenced in the URL at the beginning of my message. Our version string for that file: * $FreeBSD: src/lib/libc_r/uthread/uthread_init.c,v 1.23.2.7 2001/11/03 00:33:07 peter Exp $ 4.7 is being left behind.. look at 4.8 IMHO, this issue could be a royal pain in the butt when I start working on quad processor systems with 32GB of RAM (not unrealistic at this company). Well we can't USE 32GB od RAM yet.. I doubt that 4.x will ever be able to do that (though I could be proven wrong). I'd like to stay with FreeBSD, but the issues with large memory support are rapidly becoming more prominent due to the *huge* memory systems in use here, with even larger memory systems on the way in the near future. I came from the Linux camp (back when 2.0/2.2 kernels were the newest in use) and I don't want to have to go back, though I no longer have any clue how those boys handle large memory systems. Maybe they're not any better in that department. I just happen to like FreeBSD better and would prefer to stick with it if possible. track RELENG_4 So, to recap my questions, what branch would I have to track to pick up that patch to pthreads? If there is no branch with that patch, has a PR been submitted so it can eventually be included in the source? If so, what is the PR number? If not, what's the best way to submit a PR? Thanks in advance for any assistance in this matter. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: increasing KVA_PAGES and broken pthreads
On 14 Mar 2003, at 16:08, Julian Elischer wrote: That patch is in the RELENG_4 tree and will be included in 4.8 Great! Thanks for the info. yes it was.. but not in RELENG_4_7 because that is for security patches. I'm showing my newbieness here. :-) Apologies. I knew that, but for some reason it didn't occur to me that patches such as this would only occur on the development branches. 4.7 is being left behind.. look at 4.8 I guess I'll just wait for 4.8 to reach RELEASE level then and work on reducing the workload of the system in the meantime, though the hardware is nowhere near overloaded. I wish I could track CURRENT, but I'm squeamish about that for a production system such as this. IMHO, this issue could be a royal pain in the butt when I start working on quad processor systems with 32GB of RAM (not unrealistic at this company). Well we can't USE 32GB od RAM yet.. I doubt that 4.x will ever be able to do that (though I could be proven wrong). Really? I was under the impression that FreeBSD was capable of addressing 8TB of RAM if the hardware supports it. Don't remember which FreeBSD list archive I read that in, but it's not a topic that seems to come up often since most hardware is limited to 4GB of address space. I've got access to hardware that can address 32GB of RAM. Not sure of the exact details of how it works (multiple external memory managers?), but it's a quad Xeon board by SuperMicro. If it's a question of is there any application that can ever use that much RAM, we're certainly testing the limits here. :-) We're not swapping at all with 4GB, but on several occasions we've gotten close or swapped a few hundred KB. Our two little 2GHz CPUs are humming right along, but most of the time they're better than 60% idle. I imagine that if we pushed the CPUs a bit harder or got hit with a big traffic spike, we'd probably start swapping and want to start thinking about a system that can handle more RAM. Of course, that's assuming that the OS or applications don't break before the hardware gets up to a decent load. Hence, I'm hoping to get a lot of the large memory OS issues resolved (many are by tuning) so we can at least get what we paid for out of the hardware. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: increasing KVA_PAGES and broken pthreads
On Fri, 14 Mar 2003, Andrew Kinney wrote: On 14 Mar 2003, at 16:08, Julian Elischer wrote: That patch is in the RELENG_4 tree and will be included in 4.8 Great! Thanks for the info. yes it was.. but not in RELENG_4_7 because that is for security patches. I'm showing my newbieness here. :-) Apologies. I knew that, but for some reason it didn't occur to me that patches such as this would only occur on the development branches. 4.7 is being left behind.. look at 4.8 I guess I'll just wait for 4.8 to reach RELEASE level then and work on reducing the workload of the system in the meantime, though the hardware is nowhere near overloaded. I wish I could track CURRENT, but I'm squeamish about that for a production system such as this. look at RELENG_4 NOW because that will become 4.8. if you have problems with it then now is the time ot speak up before 4.8 is frozen in stone. IMHO, this issue could be a royal pain in the butt when I start working on quad processor systems with 32GB of RAM (not unrealistic at this company). Well we can't USE 32GB od RAM yet.. I doubt that 4.x will ever be able to do that (though I could be proven wrong). Really? I was under the impression that FreeBSD was capable of addressing 8TB of RAM if the hardware supports it. On a ia64 machine I think (which i386 is not) Don't remember which FreeBSD list archive I read that in, but it's not a topic that seems to come up often since most hardware is limited to 4GB of address space. I've got access to hardware that can address 32GB of RAM. Not sure of the exact details of how it works (multiple external memory managers?), but it's a quad Xeon board by SuperMicro. If it's a question of is there any application that can ever use that much RAM, we're certainly testing the limits here. :-) We're not swapping at all with 4GB, but on several occasions we've gotten close or swapped a few hundred KB. Our two little 2GHz CPUs are humming right along, but most of the time they're better than 60% idle. I imagine that if we pushed the CPUs a bit harder or got hit with a big traffic spike, we'd probably start swapping and want to start thinking about a system that can handle more RAM. There is a possibility that it could be done but not right now.. There are other things that are higher on the lists. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
style of sysctl description strings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While trying to write a small script that would help Tom Rhodes to extract the list of sysctl names and descriptions from a running kernel, I noticed the following (pardon the long lines): hw.pci.enable_io_modes: Enable I/O and memory bits in the config register. Some BIOSes do not enable these bits correctly. We'd like to do this all the time, but there are some peripherals that this causes problems with. hw.pci.allow_unsupported_io_range: Allows the PCI Bridge to pass through an unsupported memory range assigned by the BIOS. The description of hw.pci.enable_io_modes uses embedded '\n' characters to keep the length of the description below 80 columns. It works fine. But only for the description text, which doesn't appear in the output of: % sysctl -dna | cut -c 80- | grep -v '^[[:space:]]*$' Strangely, this is the only sysctl that I could spot in the entire tree with '\n' characters in the description. The next sysctl in the output of sysctl -ad is hw.pci.allow_unsupported_io_range as shown above, which doesn't make any effort to keep the text below 80 columns. Is there a reason for wrapping with '\n'? If yes, what would that be? I'm only asking because it would make my life simpler if the sysctl descriptions didn't have embedded newlines, and this is a good opportunity to learn something too :-) - - Giorgos -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+cjBf1g+UGjGGA7YRAic3AJ0SgcgupeQiEqoOiBUWHbqzcMq1igCePFvC 9yg+XSZaqtXCpN3cKyyRjzU= =6IkN -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
locale setup, automagically ?
Hi, this is more a whish ... Sometime ago I was discussing with some friends about localization and we arrive to ask why not having all the locale settings configured in one place only. I'll try to explain better... I am italian. If I want to take advantage of everything the italian locale have to offer in FreeBSD I have to config a lot of files. using a right terminal i.e: cons25l1 /etc/rc.conf: keymap=it.iso font8x8=iso15-8x8 font8x14=iso15-8x14 font8x16=iso15-8x16 ~/.login_conf me:\ :charset=iso-8859-15:\ :lang=it_IT.ISO8859-15: /etc/ttys put cons25i (or 30i) in the ttys line while I can have a db (like pccard.conf i.e) that can be set to exec all this tasks in one shot: vidcontrol -f 8x16 iso15-8x16.fnt kbdcontrol -l it.iso.kbd setenv LANG it_IT.ISO8859-15 setenv MM_CHARSET iso-8859-15 setenv TERM cons25l1 so in my /etc/rc.conf I can have i.e: locale=italy and the during boot everything automagically is setup. Thanks for attention. Best Regards, Gianmarco Giovannelli , Unix expert since yesterday http://www.gufi.org/~gmarco To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
