Proper Kernel notification to a user level process
What is the proper or best practice method for the kernel to notify a user level process (or processes) of an event. This event may possibly have data. The processes may or may not exist. The event is generated by some arbitrary kernel event (a counter, a call being made, etc.) Typically I have seen this done as file I/O via a device. syslogd is a program that fits this description. A special device '/dev/klog' was provided for it. What is the best practice these days? Please reply to me directly, I will summarize the results to the list. Dru Nelson San Mateo, California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Quanta tricks
During one of the BayAreaFreebsdUsersGroup meetings, Matt D. and Terry were mentioning that certain do some tricks to hold their quanta (Apache?). What are these tricks? (Just out of curiousity). Please reply to me directly, I will summarize the results to the list. Dru Nelson San Mateo, California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fwd: New soundcard device driver -TurtleBeach Multisound Monterey for 3.x
I offer this new driver to any and all who are interested under the GNU public license. Development was done solely on The Multisound Monterey card (because it's the one I own). The Multisound family also includes the older Classic, the later Pinnacle and Fiji. I would encourage those users to at least try this driver. No guarantees!!! This was also developed on FreeBSD 3.3-Release as I cannot abide -current as a development environment. I have had some testers report success in at least compiling/attaching this driver on 3.1-Release and 3.4-Release. So I also encourage anyone on the 3.x branch to give it a try. For info on capabilities, limitations, prospects , support and "grabbing the goods" see http://www.treefort.org/~bobkat/msm_main.shtml Driver is dual mode. Can be statically compiled into a new kernel or built as a KLD module and dynamically loaded/unloaded from a running kernel. Any and all comments / constructive criticisms / compliments welcome. Have at it. Crank up that mixer volume. Have some fun. Which other FreeBSD lists might be intersted in this notice? Bob Kot Sonoran Desert To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Setting the video mode during boot (was: Re: VGA card (mis)b
On 28-Jan-00 Kazutaka YOKOTA wrote: >>> The word at 0x463 in the BIOS data area tells at which I/O address the >>> CRTC is sitting on. It's 0x3b4 for the monochrome adapter and EGA/VGA >>> in a monochrome mode, and 0x3d4 for CGA and EGA/VGA in a color mode. >>> >>> So, we should try to set the mode 3 when we find 0x3d4 and the mode 7 >>> for 0x3b4. >> >>I knew someone would know. :) I'll try to work on a patch for this tonight >>if I have time. Would it be ok if this was done very early on, like before >>the loader binary itself was started? IOW, do it in btxldr? We might also >>want to do it in boot1. > > There probably isn't much space in boot1. I think we can fit it in boot1, at least I'm going to try. Even boot2 would be before btxldr was run. IMO, here's what we should do: After we run the code to detect a serial console in boot[12], or cdldr, or the forthcoming pxeldr, if it is not a serial console, then reset the video mode to either 3 or 7 based on the word at 0x463. Then it's done at the very beginning of the process before btxldr is started. > While boot2 and loader(8) print string on the video adapter via BIOS, > btxldr appears to assume the video card is in the text mode (whether > it is mono or color) and directly goes to the text buffer address > (0xb8000 for color and 0xb for mono). > > I think we may set the video mode at the very beginning of btxldr. > But, even if we cannot find space to do so in btxldr, I won't moan. > Because I don't think we will loose vital information even if we don't > see btxldr's banner. So, setting the video mode during boot2 or in > loader(8) should be sufficient, I would expect... > > Kazu -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Setting the video mode during boot (was: Re: VGA card (mis)behavior)
>> The word at 0x463 in the BIOS data area tells at which I/O address the >> CRTC is sitting on. It's 0x3b4 for the monochrome adapter and EGA/VGA >> in a monochrome mode, and 0x3d4 for CGA and EGA/VGA in a color mode. >> >> So, we should try to set the mode 3 when we find 0x3d4 and the mode 7 >> for 0x3b4. > >I knew someone would know. :) I'll try to work on a patch for this tonight >if I have time. Would it be ok if this was done very early on, like before >the loader binary itself was started? IOW, do it in btxldr? We might also >want to do it in boot1. There probably isn't much space in boot1. While boot2 and loader(8) print string on the video adapter via BIOS, btxldr appears to assume the video card is in the text mode (whether it is mono or color) and directly goes to the text buffer address (0xb8000 for color and 0xb for mono). I think we may set the video mode at the very beginning of btxldr. But, even if we cannot find space to do so in btxldr, I won't moan. Because I don't think we will loose vital information even if we don't see btxldr's banner. So, setting the video mode during boot2 or in loader(8) should be sufficient, I would expect... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to allocate an alined address for a device?
> "Warner" == Warner Losh writes:
Warner> In a cardbus system, one would force the alignment in the card bus
Warner> bridge. It would reject those things that aren't aligned in a sane
Warner> manner for cardbus. It would try again to get a different range, if
Warner> possible, or would reject the attempt.
I think it is no good to try again to get a different range.
Because, a different system has a different free address range and a device
dirver can not know where is a free address range.
So I change rman_reserve_resource() in @src/sys/kern/subr_rman.c for we can
allocate an aligned address.
My idea is using high bits of flags.
RF_ALIGN_XXX in aflags specifies an alignment request and an alignment
size.
Bad point of my idea is that we need to use a different bit for each an
alignment size.
This is a patch for @src/sys/kern/subr_rman.c (rev. 1.10) and
@src/sys/sys/rman.h (rev. 1.5)
Is my idea good or not?
Thanks,
---
YAMAMOTO ShigeruInternet Initiative Japan Inc.
<[EMAIL PROTECTED]> Network Engineering Div.
--- kern/subr_rman.c.orgTue Nov 16 08:28:57 1999
+++ kern/subr_rman.cThu Jan 27 02:33:03 2000
@@ -227,7 +227,17 @@
continue;
}
rstart = max(s->r_start, start);
- rend = min(s->r_end, max(start + count, end));
+ if (flags & RF_ALIGN_MASK) {
+ /* need to align an address */
+ u_long aligned_rstart;
+
+ aligned_rstart = (rstart & (~((u_long)(flags & RF_ALIGN_MASK))
++ 1u));
+ if ((rstart & (~(~((u_long)(flags & RF_ALIGN_MASK)) + 1u))) !=
+0) {
+ aligned_rstart += ((u_long)(flags & RF_ALIGN_MASK));
+ }
+ rstart = aligned_rstart;
+ }
+ rend = min(s->r_end, max(max(start + count, end), rstart + count));
#ifdef RMAN_DEBUG
printf("truncated region: [%#lx, %#lx]; size %#lx (requested %#lx)\n",
rstart, rend, (rend - rstart + 1), count);
--- sys/rman.h.org Mon Jan 10 08:48:52 2000
+++ sys/rman.h Thu Jan 27 02:36:51 2000
@@ -57,14 +57,33 @@
struct rman *r_rm; /* resource manager from whence this came */
};
-#defineRF_ALLOCATED0x0001 /* resource has been reserved */
-#defineRF_ACTIVE 0x0002 /* resource allocation has been activated */
-#defineRF_SHAREABLE0x0004 /* resource permits contemporaneous sharing */
-#defineRF_TIMESHARE0x0008 /* resource permits time-division sharing */
-#defineRF_WANTED 0x0010 /* somebody is waiting for this resource */
-#defineRF_FIRSTSHARE 0x0020 /* first in sharing list */
+#defineRF_ALLOCATED0x0001 /* resource has been reserved */
+#defineRF_ACTIVE 0x0002 /* resource allocation has been
+activated */
+#defineRF_SHAREABLE0x0004 /* resource permits contemporaneous
+sharing */
+#defineRF_TIMESHARE0x0008 /* resource permits time-division
+sharing */
+#defineRF_WANTED 0x0010 /* somebody is waiting for this
+resource */
+#defineRF_FIRSTSHARE 0x0020 /* first in sharing list */
-#define RF_PCCARD_ATTR 0x1 /* PCCARD attribute memory */
+#define RF_ALIGN_4K0x1000 /* require 4K byte address alignment */
+#define RF_ALIGN_8K0x2000 /* require 8K byte address alignment */
+#define RF_ALIGN_16K 0x4000 /* require 16K byte address alignment */
+#define RF_ALIGN_32K 0x8000 /* require 32K byte address alignment */
+#define RF_ALIGN_64K 0x0001 /* require 64K byte address alignment */
+#define RF_ALIGN_128K 0x0002 /* require 128K byte address alignment */
+#define RF_ALIGN_256K 0x0004 /* require 256K byte address alignment */
+#define RF_ALIGN_512K 0x0008 /* require 512K byte address alignment */
+#define RF_ALIGN_1M0x0010 /* require 1M byte address alignment */
+#define RF_ALIGN_2M0x0020 /* require 2M byte address alignment */
+#define RF_ALIGN_4M0x0040 /* require 4M byte address alignment */
+#define RF_ALIGN_8M0x0080 /* require 8M byte address alignment */
+#if 0 /* XXX Is there a device which requires more large address alignment? */
+#define RF_ALIGN_16M 0x0100 /* require 16M byte address alignment */
+#define RF_ALIGN_32M 0x0200 /* require 32M byte address alignment */
+#define RF_ALIGN_64M 0x0400 /* require 64M byte address alignment */
+#define RF_ALIGN_128M 0x0800 /* require 128M byte address alignment */
+#endif
+#defineRF_ALIGN_MASK 0x00FFF000 /* mask for RF_ALIGN_XX */
+#defineRF_PCCARD_ATTR RF_ALIGN_4K /* PCCARD attribute memory */
enum rman_type { RMAN_UNINIT = 0,
Re: How to write a device-driver?
On Tue, Jan 25, 2000 at 06:54:15PM +0100, Jeroen Ruigrok/Asmodai wrote: > -On [2124 00:00], Joachim Jäckel ([EMAIL PROTECTED]) wrote: > >But how get's the zoran36067_regs structure the information from the > >chip? > > If you were using newbus (on FreeBSD 4.0) I'd say bus_space_read_#() to > get the info in the registers our of your chip. > > >If I change the content of the structure, which function would change > >the registers on the chip accordingly? (Or is it done through the call > >of pci_map_mem? And is everything I change to the structure > >automatically changed on the card?) > > I have to show my lack of 2.2.x and 3.x driver programming. I am > spoiled due to 4.x. I think someone else needs to answer this. Juergen > appears to know 3.x driver programming. Oh i'm sure there are others here that know more than me! But since i see no other followup (huh?), here goes: The bus_space_* are in -stable too (and i just looked, they're even in RELENG_2_2, went in Jan 1988, sys/i386/include/bus.h), they are just not used by all drivers, most(?) simply are older. (sys/pci/es1370.c is one that uses them.) For memory mapped registers on -stable use pci_map_mem, this maps them into memory. then, since you're making a new driver, i'd access them thru the bus_space_* macros too. Whether you need a zoran36067_regs struct to mirror the register contents depends on the card, if there are no special restrictions on accessing registers then there's probably no need for it. (Or do you mean the virtual address returned by pci_map_mem? that will point to the registers themselves, accessing them thru the bus_space_* macros instead of `by hand' is just more portable, and you don't have to remember the `volatile', etc...) The `proper' way to get the first arg (tag) to the bus_space_* for memory mapped io on -stable seems to be something like this, #ifdef __i386__ #define MEM_SPACE_MAPPING I386_BUS_SPACE_MEM #endif #ifdef __alpha__ #define MEM_SPACE_MAPPING ALPHA_BUS_SPACE_MEM #endif the second arg is the virtual address (on -stable from pci_map_mem), the third is the offset... And if you want to know things like what changed in -current in some file when you only have the -stable version of it you can also use cvsweb, bus.h for example would be here: http://www.freebsd.org/cgi-bin/cvsweb.cgi/src/sys/i386/include/bus.h And now i should probably convert the cascade driver to use the bus_space_* too... :) (Note, most(?) of the above is only what i learned from looking at the source myself, if i managed to talk nonsense please someone say so...) HTH, -- Juergen Lock <[EMAIL PROTECTED]> (remove dot foo from address to reply) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VGA card (mis)behavior
On 27-Jan-00 Kazutaka YOKOTA wrote: >>There is a way to detect monochrome or color via one of the 0x3dX registers. >>It's the register that tells you if the rest of the vido registers are at 0x3b >>X >>(mono) or 0x3cX (color). I can't remember which bit in which register that is >>though. If someone can find that out, then we can fix this properly. > > The word at 0x463 in the BIOS data area tells at which I/O address the > CRTC is sitting on. It's 0x3b4 for the monochrome adapter and EGA/VGA > in a monochrome mode, and 0x3d4 for CGA and EGA/VGA in a color mode. > > So, we should try to set the mode 3 when we find 0x3d4 and the mode 7 > for 0x3b4. I knew someone would know. :) I'll try to work on a patch for this tonight if I have time. Would it be ok if this was done very early on, like before the loader binary itself was started? IOW, do it in btxldr? We might also want to do it in boot1. > Kazu -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VGA card (mis)behavior
>There is a way to detect monochrome or color via one of the 0x3dX registers. >It's the register that tells you if the rest of the vido registers are at 0x3b >X >(mono) or 0x3cX (color). I can't remember which bit in which register that is >though. If someone can find that out, then we can fix this properly. The word at 0x463 in the BIOS data area tells at which I/O address the CRTC is sitting on. It's 0x3b4 for the monochrome adapter and EGA/VGA in a monochrome mode, and 0x3d4 for CGA and EGA/VGA in a color mode. So, we should try to set the mode 3 when we find 0x3d4 and the mode 7 for 0x3b4. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Compiling under the linux emulator
I need to compile a program under the freebsd linux emulator. How do I set up an environment where make, cc, etcetera point to the emulator binaries? I am attempting to recompile the xfstt port under the linux emulator to test some stability issues. Many thanks, Gene *==* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice* *==* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VGA card (mis)behavior
Hi Folks, (included Daniel since he had other concerns we discussed elsewhere) I haven't submitted a PR yet, pending the outcome of the discussion; since the right group of people seems to be talking about it, I'll just get out of the way :-) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: VGA card (mis)behavior
On 27-Jan-00 Brian Fundakowski Feldman wrote:
> This really does need to be fixed for 4.0-RELEASE. There exists the problem
> where certain BIOSes will whack a VGA card out of shape, preventing
> FreeBSD from recognizing the card. The proper solution is to whack it
> into shape ASAP, and ASAP here would be the loader: you need to be able
> to interact with the loader, and weird BIOS modes making things impossible
> to read are _bad_. It's been tested for a while here, and works, setting
> the card to the correct mode. What needs work is to have the right
> mode for monochromatic cards set, which it isn't now. Would someone
> in the know review, (fix WRT mono) and commit these diffs? It's very
> important to be done. I originally got these diffs from W. Gerald Hicks.
There is a way to detect monochrome or color via one of the 0x3dX registers.
It's the register that tells you if the rest of the vido registers are at 0x3bX
(mono) or 0x3cX (color). I can't remember which bit in which register that is
though. If someone can find that out, then we can fix this properly.
> --
> Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
> [EMAIL PROTECTED]`--'
>
> Index: i386/libi386/vidconsole.c
> ===
> RCS file: /usr2/ncvs/src/sys/boot/i386/libi386/vidconsole.c,v
> retrieving revision 1.12
> diff -u -r1.12 vidconsole.c
> --- i386/libi386/vidconsole.c 1999/08/28 00:40:16 1.12
> +++ i386/libi386/vidconsole.c 2000/01/19 08:16:17
> @@ -42,6 +42,7 @@
> #endif
> static void vidc_probe(struct console *cp);
> static int vidc_init(int arg);
> +static void vidc_setmode(int mode);
> static void vidc_putchar(int c);
> static int vidc_getchar(void);
> static int vidc_ischar(void);
> @@ -106,6 +107,7 @@
> if (vidc_started && arg == 0)
> return;
> vidc_started = 1;
> +vidc_setmode(3); /* XXX - set 80x25 16 color text mode */
> #ifdef TERM_EMU
> /* Init terminal emulator */
> end_term();
> @@ -117,6 +119,15 @@
> for(i = 0; i < 10 && vidc_ischar(); i++)
> (void)vidc_getchar();
> return(0); /* XXX reinit? */
> +}
> +
> +static void
> +vidc_setmode(int mode)
> +{
> +v86.ctl = 0;
> +v86.addr = 0x10;
> +v86.eax = mode & 0xff; /* AH=0, AL=mode */
> +v86int();
> }
>
> static void
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: aio_read crashing certain kernels.
"Matthew Dillon" <[EMAIL PROTECTED]> wrote:
> This is an incredibly scary program!
OK, so I was facetious in including that program - my basic point was that
it doesn't happen when I'm doing anything weird, it happens with the most
straightforward aio_read program imaginable. Furthermore, it works on the
uniprocessor/EIDE/standard-kernel machine, it doesn't on the
SMP/Adaptec/custom-kernel machine. I've included another version of the
program which I've used to actually kill a machine, repeatedly.
> It's sending an iocb to aio_read
> and then pops the stack and exits. The act of exiting could very
well
> scribble all over the iocb structure while the I/O is in progress
and,
> of course, then the program invalidates the stack and exits.
??? The problem is that I'm locking up the entire box, hard enough this
morning that I had to pull the plug to get it back. If all I got were a
coredump, I'd be over on freebsd-questions trying to figure out how it was
that I misunderstood the problem.
[Actually, I think this did cause my original posting to work right,
because the process exitting probably caused the aio stuff to either error
out or work correctly :-).]
> You could be right about the SMP build --- the aio code is indeed
> doing a fork with RFMEM and that *WILL* break under SMP.
The weird thing is, rfork() on SMP returns ENOTSUPP - it doesn't work, but
it doesn't break, either.
Here's the program. I've found that it actually sometimes works, but I
haven't been able to figure out why. It seems to have something to do with
whether the file might be in the buffer cache or not (so it helps to pass a
file which hasn't been accessed in awhile). Also, if I change the #if 1 to
#if 0, it seems to work just fine. My suspicion is that it could be an SMP
issue, and if I'm lucky, everything executes on a single CPU and works. If
I'm unlucky, BAM! The code that I'm really hacking on does a lot of reads
from widely placed sections of a file, and thus is more likely to hit the
problem (if someone really really really wants that program, I can try to
hack it into postable shape, but the enclosed program does the job for me).
Again, the symptoms of a problem are that the entire box locks up so hard
that you have to power cycle it at best, or pull the plug at worst.
#include
#include
#include
void main( int argc, char **argv)
{
int fd=open( argc>1 ? argv[1] : "/usr/tmp/aiotest.c", O_RDONLY);
char buf[ 1024];
struct aiocb iocb;
sigset_t sigset;
if( fd==-1) {
perror( "opening");
}
bzero( &iocb, sizeof( iocb));
iocb.aio_fildes=fd;
iocb.aio_offset=0;
iocb.aio_buf=buf;
iocb.aio_nbytes=sizeof( buf);
iocb.aio_sigevent.sigev_notify=SIGEV_SIGNAL;
iocb.aio_sigevent.sigev_signo=SIGIO;
#if 1
if( aio_read( &iocb)==-1) {
perror( "aio_read");
}
while( aio_error( &iocb)==EINPROGRESS);
#else
printf( "aio_read\n");
if( aio_read( &iocb)==-1) {
perror( "aio_read");
}
do {
printf( "aio_error\n");
} while( aio_error( &iocb)==EINPROGRESS);
#endif
printf( "en==%d\n", aio_error( &iocb));
printf( "rc==%d\n", aio_return( &iocb));
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
VGA card (mis)behavior
This really does need to be fixed for 4.0-RELEASE. There exists the problem
where certain BIOSes will whack a VGA card out of shape, preventing
FreeBSD from recognizing the card. The proper solution is to whack it
into shape ASAP, and ASAP here would be the loader: you need to be able
to interact with the loader, and weird BIOS modes making things impossible
to read are _bad_. It's been tested for a while here, and works, setting
the card to the correct mode. What needs work is to have the right
mode for monochromatic cards set, which it isn't now. Would someone
in the know review, (fix WRT mono) and commit these diffs? It's very
important to be done. I originally got these diffs from W. Gerald Hicks.
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
Index: i386/libi386/vidconsole.c
===
RCS file: /usr2/ncvs/src/sys/boot/i386/libi386/vidconsole.c,v
retrieving revision 1.12
diff -u -r1.12 vidconsole.c
--- i386/libi386/vidconsole.c 1999/08/28 00:40:16 1.12
+++ i386/libi386/vidconsole.c 2000/01/19 08:16:17
@@ -42,6 +42,7 @@
#endif
static voidvidc_probe(struct console *cp);
static int vidc_init(int arg);
+static voidvidc_setmode(int mode);
static voidvidc_putchar(int c);
static int vidc_getchar(void);
static int vidc_ischar(void);
@@ -106,6 +107,7 @@
if (vidc_started && arg == 0)
return;
vidc_started = 1;
+vidc_setmode(3); /* XXX - set 80x25 16 color text mode */
#ifdef TERM_EMU
/* Init terminal emulator */
end_term();
@@ -117,6 +119,15 @@
for(i = 0; i < 10 && vidc_ischar(); i++)
(void)vidc_getchar();
return(0); /* XXX reinit? */
+}
+
+static void
+vidc_setmode(int mode)
+{
+v86.ctl = 0;
+v86.addr = 0x10;
+v86.eax = mode & 0xff; /* AH=0, AL=mode */
+v86int();
}
static void
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: disappearing mount points after install
On Wed, 26 Jan 2000, Brian D. Moffet wrote: > At 03:59 PM 1/22/00 -0500, you wrote: > >FreeBSD loader does not start up, nor does the kernel (obviously). The > >error message I get back is literally translated as "No O.S." > > on the other versions of Intel Unix I have used dd the master boot block > out... > > If you want to get really daring, look at the first sector of the BIOS and see > if it starts with a "jump" command, e9 or eb or something like that. :-) > > If any of this is incorrect for FreeBSD, I hope someone lets me know, and lets > me know how it is incorrect. > Hi Brian, Through some pointing from others, and trial and error on my part, I discovered that my BIOS requires that my first bootable partition be a bootable DOS partition. What is most strange is that for some reason it is required to be at least 20Megs in size. I only discovered this after trying 2,5,10,15 megabyte partitions. Anyway, it works now as a dual boot machine. Even though I had to give up 20Megs (on an 800MB HD), at least it works... and I discovered I can use that space as FreeBSD swap space so it's not completely wasted. I should end by saying, "Thanks IBM for all the proprietary stuff you force on people" (can you sense the sarcasm!?) ;-) Marwan ps. The machine was an IBM Thinkpad 365XD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: disappearing mount points after install
At 03:59 PM 1/22/00 -0500, you wrote: >FreeBSD loader does not start up, nor does the kernel (obviously). The >error message I get back is literally translated as "No O.S." "No O.S " means that the master boot block has not been written. I have no idea why your version of FreeBSD didn't write one, or if it wrote a corrupted one. The message comes from the BIOS loading code in the machine. Several possibilities exist, install a DOS partition which will boot, and then remove it and install your FreeBSD. That should get you your master boot block. I installed on a 13 Gig EIDE, with the "FreeBSD is the only OS ever on this machine" option (my manuals are elsewhere), and it installed and booted just fine, with no previous OS installed. There is probably a program or option to do this. Usually fdisk on the other versions of Intel Unix I have used dd the master boot block out... If you want to get really daring, look at the first sector of the BIOS and see if it starts with a "jump" command, e9 or eb or something like that. :-) If any of this is incorrect for FreeBSD, I hope someone lets me know, and lets me know how it is incorrect. Good luck Brian Brian D. Moffet www.moffetimages.com [EMAIL PROTECTED] photographer, pilot, musician, programmer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
s/line/list/ NIL is what you test against to determin if you have reached the end of a list. the empty list is just a NIL ( hand wave over all the car and cdr reality in favor of a simpler albeit not-correct description of how it works.) jmb > > In message <[EMAIL PROTECTED]> "Jonathan M. Bresler" writes: > : The terminology is very simple. Anyone that can cope with > : either vi or emacs can learn: > : > : NUL: an ascii character (0x00) > : NIL: a pointer at the end of the line > : NULL pointer: used in C to refer to NIL. > : not to be confused with NUL. > > But NIL is not a poitner at the end of the line in gnu emacs. It is > the empty list. > > Warner > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Success with Dell Poweredge 2400s?
Hi all, a short while ago, there was discussion about problems with Dell Poweredge 2400s. We are currently trying to get a couple of these beasts going (dual processor) and I'd like to know if anyone has had any success so far. Last time I looked, there seemed to be an issue about the Chipset? Regards, Geoff. -- Geoff Rehmet, The Internet Solution - Infrastructure tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 email: [EMAIL PROTECTED], [EMAIL PROTECTED] URL: http://www.is.co.za To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
qpopper and sendmail ports on FreeBSD 3.x : locking process ?
Hi, I was thinking to use qpopper 2.53 port on FreeBSD 3.3 with sendmail 8.9.3 port (mail.local delivery) but I would like to know the impact of the patches added to source files especially concerning the lock process since I want to run a script to expire mail. Why does ..pop stay in /var/mail in the spool even at the end of POP3 session. The usual qpopper process is to remove .pop at the end of POP3 session. How does the lock process work with that port (I saw a flock.c file added to original distribution) ? If I want to expire mail, what should be the locking process in it considering I use sendmail and qpopper ports ? Furthermore, I would like to increase the performances of that server. With that port, is it possible to : - use server mode - put the POP_DROP on another directory (which is on another device) - use HASH_SPOOL=2 Furthermore, is there any patches dependency with sendmail 8.9.3 provided by FreeBSD 3.3 ? Finally, is it possible to use last version of qpopper 3.x without patches to get a correct behaviour especially with locking process. Thanks in advance for your help.Gildas. -- Gildas PERROT, [EMAIL PROTECTED] __o FranceNet, 28 rue Desaix, 75015 Paris ---_ \<,_ http://www.francenet.fr (_)/ (_) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aio_read crashing certain kernels.
On Wed, 26 Jan 2000, Matthew Dillon wrote: > This is an incredibly scary program! It's sending an iocb to aio_read > and then pops the stack and exits. The act of exiting could very well > scribble all over the iocb structure while the I/O is in progress and, > of course, then the program invalidates the stack and exits. Even if that's the case, it's still a userland program that is able to panic the system. So, no matter what the program does, it's still a bug in the way we handle aio. Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: compiler errors (fwd)
Tell him he cannot claim it is not the hardware until he actually replaces the ram and cpu with truely known good ones and un-overclocks if he is oc'ing. Also try underclocking. I mention truely known good ones because I recently went through *3* bad cpu's before finding a useable one from our cpu stash at work. On Wed, 26 Jan 2000, f.johan.beisser wrote: > >oddly enough, i told him this a few days ago, but he insisted that his >hardware was fine.. > >anyhow, thanks for the help you all have given me. > >-- jan > > >On Wed, 26 Jan 2000, Chuck Robey wrote: > >> On Wed, 26 Jan 2000, f.johan.beisser wrote: >> >> > ok, here's the scenario. I didn't install any ports until I went to do the >> > `make buildworld`, when I installed cvsup to get the source updates. >> > >> > full binary+sources install from the 14 Jan 2000 snapshot >> > AMD K6-2 450MHz (corroborated by dmesg output) >> > c. 8 gig Seagate IDE HD >> > 64 megs RAM >> > cheap motherboard with everything built in, and one PCI slot >> > >> > here is the final lines of output from trying to compile the GENERIC kernel >> > (doing a `/usr/sbin/config GENERIC`): >> > --- >> > -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 >> > ../../netinet/in.c >> > cc: Internal compiler error: program cc1 got fatal signal 11 >> > *** Error code 1 >> > cc: Internal compiler error: program cc1 got fatal signal 11 >> >> Signal 11 is usually an artifact of bad hardware, like bad RAM. You don't >> state what version of FreeBSD he's running, either. Did you know that, if >> he's running a system older than about 3 months ago, he CAN'T buildworld >> unless he installs a new kernel first? >> >> >> Chuck Robey| Interests include C & Java programming, FreeBSD, >> [EMAIL PROTECTED] | electronics, communications, and signal processing. >> >> New Year's Resolution: I will not sphroxify gullible people into looking up >> fictitious words in the dictionary. >> >> >> >> >> To Unsubscribe: send mail to [EMAIL PROTECTED] >> with "unsubscribe freebsd-hackers" in the body of the message >> > > +-// f. johan beisser //--+ > email: jan[at]caustic.org web: http://www.caustic.org/~jan > "knowledge is power. power corrupts. study hard, be evil." > > > >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
