Re: max phy mem known working with FreeBSD 4.x
Matt wrote: Anyone knows the max physical mem that can be used with FreeBSD4.3? [ ... ] any chance going more than 4G? Sure, if you want to install it to warm things up. No, if you want to access it; access is limited to 4G, because that's 32 bits of address space, and your machine is a 32 bit machine. Unless you run IA-64 or SPARC-64, or run Alpha, and fix several of the drivers to use bus space properly. Of course, for these platforms, you wouldn't be running 4.3. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max phy mem known working with FreeBSD 4.x
On Tue, 5 Nov 2002, Terry Lambert wrote: Matt wrote: Anyone knows the max physical mem that can be used with FreeBSD4.3? [ ... ] any chance going more than 4G? Sure, if you want to install it to warm things up. No, if you want to access it; access is limited to 4G, because that's 32 bits of address space, and your machine is a 32 bit machine. Well, the P4 does have an address extension that allows addressing of up to 64GB, EPA or something like that. However, it requires some work. Would be nice in large Samba servers, though, to be able to cache enormous amounts of file data :-) Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], http://www.richardsharpe.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max phy mem known working with FreeBSD 4.x
Julian Elischer wrote: The hardware changes to do 32 bit physical addresses include a redefinition of how page tables and page directories are layed out and to be able to use it we'd have to define and turn on code for that differnt mode. iIt has not yet been written. It wouldn't be hard to make a system that ONLY ran in that mode but one that can run on new systems withthat mode and also run on old 486 machines is much harder. It's easier to do it with PSE-36 than PAE, actually. The double indirect is also easy to setup, and then not use, if it comes to that, and 4K vs. 8K allocated in assembly is pretty much nothing. The big issue is the 2M vs. 4M jumbo pages: you have to expect that, and FreeBSD, if PSE is present, will try to set up a 4M page for the kernel. What's really needed is a remap4kto4m() function that gets used for that; there's a trick you have to pull with CR3, CR0, and CR4 to make it not break, though, because there's a CPU bug, and it leaves you with a chicken-and-egg problem, otherwise. This would work for 2M pages, as well (just use two of them). If you understand the code, you should be able to write it in about two weeks (including the CPU bug workaround), once you have your head around things. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max phy mem known working with FreeBSD 4.x
Richard Sharpe wrote: Well, the P4 does have an address extension that allows addressing of up to 64GB, EPA or something like that. This is useless to discuss in the context of 4.3, or even 4.x, unless Paul Saab is doing his work in 4.7, and it makes it into 4.8. Given that we are pretty much forced to do all new work 0n -current in order to get committed (or everyone would be working on 4.x instead), it'll end up a forward port with no back-port (expect it after the 5.x release, if Yahoo gives it back to FreeBSD). However, it requires some work. Would be nice in large Samba servers, though, to be able to cache enormous amounts of file data :-) It would be useless for this purpose. Specifically, you would need to guarantee a locality of reference for clients that you could not guarantee, for this to be useful at all. Mostly, you would be swapping the PSE window around all the time, shooting down TLB's and cache lines, and you would burn up any benefits of having the data in main RAM instead of in RAM on the disk controller or the disk itself, very quickly. In addition, you would not be able to use sendfile or similar interfaces, and you would not be able to use scatter/gather DMA, unless you knew for certain that the card doing the DMA had 64 bit access to physical RAM. Otherwise, you would need to copy all data to be DMA'ed to/from any physical RAM above 4G to bounce buffers below 4G. The extra copying might as well be from the controller RAM or the RAM on the disk itself, than from/to RAM above 4G. The 2G limit on Alpha is basically the same issue, where the data needs to be bounced through lower memory in order to be accessible to the hardware DMA engines on the other side of the PCI bus (hence the need to convert the drivers to bus space to be able to use more than 2G in an Alpha box). Basically, the extra RAM makes assumptions about code that make us all realize that hardware designers don't really ask software designers why they ask for things like the ability to access more than 4G of RAM. 8-). If you want to discuss this further, please read the archives of the last 3 times the issue was discusees, on the -current and -arch lists. No matter how you look at it, though, unless you pay some schmuck to do the work, you're never going to see this in 4.3 anyway, so you might as well move the discussion over to the -current list. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max phy mem known working with FreeBSD 4.x
PS: Richard Sharpe wrote: Well, the P4 does have an address extension that allows addressing of up to 64GB, EPA or something like that. It has segments, too. We don't use those, either. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dgb driver update
Thus spake Nate Lawson [EMAIL PROTECTED]: The best way is to send a pr and then followup on mailing lists as appropriate or perhaps by contacting the maintainer. The PR provides history for a given problem and patch and the followup initiates action on behalf of the committers. It's important to get someone to take up the responsible field before any action can happen. This idea works if the components in question have maintainers. The bits that are in most need of patching do not, so obvious one-line patches go un-committed because nobody thinks themselves to be familiar enough with the code. BTW, the number of PRs is not totally the fault of committers. I've been scanning through the DB with about 50% of my FreeBSD-time and fixing things that I find there. However, it has taken about 3x as long as I expected to commit a patch because almost all of them are very incomplete and actually are more a suggestion on an area that needs improvement, not a fix. I applaud you, but the PR problem won't be solved until the other 90% of the committer base chips in as well. It is *not* always the case that closing PRs requires extra work. On several occasions, people have reinvented the wheel and committed patches identical (or nearly so) to ones I submitted six months earlier. I'm sure others have noticed the same thing. It's even worse when the patch that's actually applied is bogus, as in the case of some changes to renice(1). I don't have a whole lot of free time, but when I spend some of it getting something right, I don't care to wait for months and then have to explain to someone else why they got it wrong. Admittedly the majority of PRs, even some of the ones with patches, are nontrivial to address. But so little attention is given to the PR database that even the straightforward PRs get overlooked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
closing all fd's in ng_device before node removal
In a kernel driver, is is possible to get the list of open fd's on a dev_t entry? I can probably do it using a double administration by storing all accesses to open() and close() but I would rather not. Any input appreciated! Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Fw: Kerenl Panic on FreeBSD 4.7 release
Hi to all , I am in desperate need of help . I have no debugging knowledge I have a server with postfix+imap+apache+mysql+php4 that keeps rebooting . I managed to get the last messege of it before the reboot. --- Fatal trap 12:page fault while in kernel mode Fault virtual address = 0xc0907640 Fault code = write,page not present Instruction pointer= 0x8:0xc01819e3 Stack pointer = 0x10:-xc88bce30 Frame pointer = 0x10:-xc88bce54 Code segment = base 0x0,limit 0xf,type 0x1b = DPLO,pres1,def32,1gran1, = interupt enabled resume,IODL = 0 Current process = 299(sshd) Interupt mask = net Kernel :type12tra[ code=0 stopped at sosend-0x43f:incb --- I think ( after a lot of testing ) that this happens when writng files from net to local disk ( w.g using ftp, scp or rsync ) . this is my first ever freebsd problem and i would be greatfull if any one can assist . some more info : FreeBSD 4.7-RELEASE #0: Mon Nov 4 11:45:43 EST 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/DEBUG Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 498854327 Hz CPU: Pentium III/Pentium III Xeon/Celeron (498.85-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV, PAT,PSE36,MMX,FXSR,SSE real memory = 134217728 (131072K bytes) avail memory = 127569920 (124580K bytes) Preloaded elf kernel kernel at 0xc0308000. - Moti be careful what you wish for ... - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fw: Kerenl Panic on FreeBSD 4.7 release
On Tue, Nov 05, 2002 at 09:30:40AM -0500, Moti Levy wrote: Hi to all , I am in desperate need of help . I have no debugging knowledge I have a server with postfix+imap+apache+mysql+php4 that keeps rebooting . I managed to get the last messege of it before the reboot. --- Fatal trap 12:page fault while in kernel mode Take a look at the FreeBSD FAQ at http://www.FreeBSD.org/, specifically questions 5.9. and 18.13., and come back with some more data :) G'luck, Peter -- Peter Pentchev [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 I am the thought you are now thinking. msg37819/pgp0.pgp Description: PGP signature
USB ethernet problem
Hi! I am running FreeBSD 4.7-release and try to use ATEN UC10T USB-to-Ethernet adapter. Unfortunately it causes my system to print something like: kue0: watchdog timeout kue0: usb error on tx: TIMEOUT following by freeze. I got this problem while forwarding 50pps/64kbit UDP packet stream which comes from Cisco ATA186 voice gateway in several minutes after call starts. Same time, OpenBSD 3.2 with a similar if_kue.c driver works fine at least under one day voice traffic load. I tried original driver and altq modifed with no success. Could someone suggest me a way to fix my problem? Anton L. Vinokurov, CCNA [EMAIL PROTECTED] NeTAMS Development Team To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
GDB auto enter/detach patch
I've put together a patch that enables a kernel on the target machine to detect a GDB packet and automatically enter GDB mode. When the debugger detaches, it also continues execution. This speeds up debugging, especially when the target is in a remote location. The patch plus more explanation is at: http://www.root.org/~nate/freebsd/ Thanks, Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: GDB auto enter/detach patch
Nate Lawson writes:
I've put together a patch that enables a kernel on the target machine to
detect a GDB packet and automatically enter GDB mode. When the debugger
detaches, it also continues execution. This speeds up debugging,
especially when the target is in a remote location. The patch plus more
explanation is at:
http://www.root.org/~nate/freebsd/
Neat. A couple of comments:
1. I think a better abstraction of the GDB packet protocol would
be something like this:
struct gdb_parse {
int state; /* opaque state value */
u_int len;/* current packet length */
u_int maxlen; /* maximum packet length */
u_char data[0];/* packet data */
};
extern void gdb_parse_init(struct gdb_parse *p);
extern int gdb_parse_byte(struct gdb_parse *p);
That is, if you're doing the state machine, why not go ahead
and decode the packet data as well?
2. You need to handle the escape mechanism for packets containing
raw data.: '$', '#', and '~' are escaped with '~' characters
in case the the 'X' command is used.
3. I think GDB_AUTO_DETACH should be mandatory, i.e., the current
state of affairs is a bug IMHO.
4. Does FreeBSD use the 'O' command to send ordinary serial port output
when GDB mode is active? Haven't looked but this would be nice to
have if it's not already there.
5. Receipt of a '$' character should always reset the state, no?
(modulo the '~' escape mechanism mentioned above).
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
load time module parameters?
I'm a newbie to FreeBSD and am wondering if there is a way to pass loadable kernel modules parameters. Under Linux, if a module had configurable parameters a and b, you can do something like insmod module.o parameters=a:10 b:5 I noticed that some of the drivers grabed information from the environment using getenv_int(), but I couldn't seem to get this to work. Thanks for any thoughts. -- Chuck Tufflichuck_tuffli at agilent dot com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: GDB auto enter/detach patch
On Tue, 5 Nov 2002, Archie Cobbs wrote:
Nate Lawson writes:
I've put together a patch that enables a kernel on the target machine to
detect a GDB packet and automatically enter GDB mode. When the debugger
detaches, it also continues execution. This speeds up debugging,
especially when the target is in a remote location. The patch plus more
explanation is at:
http://www.root.org/~nate/freebsd/
Neat. A couple of comments:
1. I think a better abstraction of the GDB packet protocol would
be something like this:
struct gdb_parse {
int state; /* opaque state value */
u_int len;/* current packet length */
u_int maxlen; /* maximum packet length */
u_char data[0];/* packet data */
};
extern void gdb_parse_init(struct gdb_parse *p);
extern int gdb_parse_byte(struct gdb_parse *p);
That is, if you're doing the state machine, why not go ahead
and decode the packet data as well?
The first version of the patch collected the data in a small static buffer
with the idea that I'd send the command to the gdb stub once it was
assembled. However, gdb on attach retries multiple times with different
commands before giving up so I just discard the first complete gdb frame
and let the retries hit gdb once I call breakpoint()
2. You need to handle the escape mechanism for packets containing
raw data.: '$', '#', and '~' are escaped with '~' characters
in case the the 'X' command is used.
Escapes should be added but I haven't done that yet because all the
commands currently used to attach to the stub don't need them.
3. I think GDB_AUTO_DETACH should be mandatory, i.e., the current
state of affairs is a bug IMHO.
I've always wondered why that wasn't the case. I'd also like to catch the
$k command (kill) which is sent on typing quit into gdb while still
attached and do something useful. Should that also restart the kernel
like an explicit detach?
4. Does FreeBSD use the 'O' command to send ordinary serial port output
when GDB mode is active? Haven't looked but this would be nice to
have if it's not already there.
No, it uses gdb remote chat which prefixes commands with
5. Receipt of a '$' character should always reset the state, no?
(modulo the '~' escape mechanism mentioned above).
Yeah, I should add this. Basically the state machine is a little lax at
the moment and it's possible (although unlikely) that data transferred
over the serial port could trigger a breakpoint(). It matches
$ + up to 12 chars + # + [0-F] + [0-F]
If you're worried about this, just use the sysctl to turn off
debug.gdb_auto_enter while transferring binary data over the gdb port.
Even when I implement stricter protocol matching, relying on inband
signalling is inherently unreliable. If you need to debug a serial port
driver, you can use a 2nd serial port.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: load time module parameters?
In the last episode (Nov 05), Chuck Tuffli said: I'm a newbie to FreeBSD and am wondering if there is a way to pass loadable kernel modules parameters. Under Linux, if a module had configurable parameters a and b, you can do something like insmod module.o parameters=a:10 b:5 I noticed that some of the drivers grabed information from the environment using getenv_int(), but I couldn't seem to get this to work. Thanks for any thoughts. You can use /usr/bin/kenv to set kernel env variables, or you can have your module register a dynamic sysctl variable that the user can tweak after the module has been loaded. I've used the sysctl method myself and it works fine. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Atheros 802.11a chipset driver
Hi, Does anyone know if someone is working on the driver for Atheros 802.11a chipset? I heard from Atheros there're people actively developing driver for Linux/FreeBSD and would probably be ready in a few months, but couldn't get any more detail. A few more months is probably more than I'm willing to wait. So I'd like to get in touch with people who are working on this and maybe help to speed up the process. If there is no such person, I've have to start writing one on my own. Thanks -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max phy mem known working with FreeBSD 4.x
On Tue, 5 Nov 2002, Richard Sharpe wrote: Well, we have 4GB in a 4.6.2 system, and I think that we ran 4.3 on those systems for a while. However, you lose anywhere between 128M and 512M because of the PCI address space. what PCI address space ? could someone explain about this loss ? curiousity beckons. :) Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: load time module parameters?
In message: [EMAIL PROTECTED] Chuck Tuffli [EMAIL PROTECTED] writes: : I'm a newbie to FreeBSD and am wondering if there is a way to pass : loadable kernel modules parameters. Under Linux, if a module had : configurable parameters a and b, you can do something like : :insmod module.o parameters=a:10 b:5 : : I noticed that some of the drivers grabed information from the : environment using getenv_int(), but I couldn't seem to get this to : work. Thanks for any thoughts. You can generally do this with hints and/or kernel environment variables. However, you can't easily edit these things once you boot. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: load time module parameters?
In message: [EMAIL PROTECTED] Dan Nelson [EMAIL PROTECTED] writes: : In the last episode (Nov 05), Chuck Tuffli said: : I'm a newbie to FreeBSD and am wondering if there is a way to pass : loadable kernel modules parameters. Under Linux, if a module had : configurable parameters a and b, you can do something like : : insmod module.o parameters=a:10 b:5 : : I noticed that some of the drivers grabed information from the : environment using getenv_int(), but I couldn't seem to get this to : work. Thanks for any thoughts. : : You can use /usr/bin/kenv to set kernel env variables, or you can have : your module register a dynamic sysctl variable that the user can tweak : after the module has been loaded. I've used the sysctl method myself : and it works fine. Hmmm, if you can use kenv to set variables, then you can use the TUNABLE_FOO interface. I didn't know that setting had been added... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Atheros 802.11a chipset driver
In message: [EMAIL PROTECTED] Luoqi Chen [EMAIL PROTECTED] writes: : Does anyone know if someone is working on the driver for Atheros : 802.11a chipset? Many people want this. When this has come up in the past, no one has come forward with claims that they are working on an open source driver for the Atheros chipset. A few people that have the source to the windows drivers have tried to port it to FreeBSD. Even if they were successful, the NDA they got the Windows drivers under would barely let them acknowledge that they ported it to FreeBSD. So far as I know, most of these sorts of efforts have dried up and blown away. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max phy mem known working with FreeBSD 4.x
Dinesh Nair wrote: On Tue, 5 Nov 2002, Richard Sharpe wrote: Well, we have 4GB in a 4.6.2 system, and I think that we ran 4.3 on those systems for a while. However, you lose anywhere between 128M and 512M because of the PCI address space. what PCI address space ? could someone explain about this loss ? curiousity beckons. :) Short answer Memory on devices on the PCI bus is mappes into the physical memory address space, and so covers up RAM in the window in which it is mapped. Good chipsets will only map in memory that actually exists for devices which are actually installed. Bad chipsets will reserve the entire window, and therefore take a much larger chunk out. Long answer --- See http://www.pcisig.com/specifications/ordering_information The CDROM and a full set of the specifications will run you US$1500, plus US$15 shipping in the US, or US$40 shipping, international. The price goes from $1500 to $75, if you can order through a company which is already a member of the PCI SIG. Your company can join the PCI SIG for a US$3000 per year fee, if it is not already a member. See http://www.pcisig.com/membership/join_pci_sig/new_member_forms/ for membership information. FWIW, I got my copy when I was an employeed of a member company; it's the way to go, if you can do it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max phy mem known working with FreeBSD 4.x
In message: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] writes: : The CDROM and a full set of the specifications will run you US$1500, : plus US$15 shipping in the US, or US$40 shipping, international. : : The price goes from $1500 to $75, if you can order through a company : which is already a member of the PCI SIG. The cdrom was $50 when I ordered it with only the PCI 2.2 spec on paper. Now that 3.0 is out, looks like they have jacked up the price again. Looks like it costs a lot more now. The mindshare PCI book has a good explaination. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max phy mem known working with FreeBSD 4.x
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] writes: : The CDROM and a full set of the specifications will run you US$1500, : plus US$15 shipping in the US, or US$40 shipping, international. : : The price goes from $1500 to $75, if you can order through a company : which is already a member of the PCI SIG. The cdrom was $50 when I ordered it with only the PCI 2.2 spec on paper. Now that 3.0 is out, looks like they have jacked up the price again. Looks like it costs a lot more now. The mindshare PCI book has a good explaination. I paid $150 in the 2.x era, but I got the full boxed set, with the PCI-PCI bridge specifications, etc.. I think the thing that's bloating it now is that they have the PCI-X and some other stuff that no one will really use much. I've already spent a little over 2 feet of shelf space, just in Microsoft MSDN CDROM's and Windows SDK's and DDK's (~300 CDROMs). I expect the printed versions of the PCI specifications would probably come in around a foot now, if they are hard bound, when before they were around 4 inches wide. I've noticed that most people who sell standards sell them cheap to start, and then jump the price up after they get adopted as standards, thinking they have a captive market. One I can recommend is the ECMA standards CDROM; the ECMA people seem to actually be interested in people complying with their standards, so there was no cost for the CDROM, as long as you have a business address to get it sent to... As far as PCI goes (or anything they publish, for that matter), the MindShare books are very, very good. But for the particular question of how much physical address space is eaten, you really have to go to the chipset spec. sheets to get the right answer these days. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
