Re: How to auto-boot from an alternate disk
Brian Somers wrote: > > Hi, > > I have a machine with 3 IDE disks and 2 SCSI disks and I want to boot > from the first SCSI disk *but* my BIOS won't boot it. > > How are you supposed to do this ? > > I've currently done > > # boot0cfg -v -t 10 -B -s 5 ad0 > # boot0cfg -v -t 1 -B -s 5 -m 0 ad1 > # boot0cfg -v -t 1 -B -s 5 -m 0 ad2 > > Which causes things to merrily skip across my IDE disks 'till it > finds the first SCSI disk, loads /boot/loader from there, finds my > kernel and then drops into a dumb ``manual mount'' prompt that makes > me say ``ufs:/dev/da0s1a''. > > What I'd *REALLY* like is some way to just say ``default to > 3:da(0,a)/boot/loader''. > > Any suggestions ? I'm not completely sure, but when you would create a file boot.loader on da0s1a containing: 3:da(0,a)/boot/loader the bootloader should be loaded from da3s1a. (for more info see man 8 boot) - Willem To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to transfer data from netgraph node to user program?
Roman V. Palagin writes: > I've wrote netgraph node which collects some information from network. Now > I want to transfer collected data into user program. I've NGM_XXX_STAT > message which initiates data transfer and program which uses libnetgraph > to communicate with node. When I send NGM_XXX_STAT message node must > starts data transfer but I don't know exactly how much data should be > transfered so I can't use synhronous reply. Also, NgSendMsg(..., > NGM_XXX_STAT, ...) doesn't return until handler of NGM_XXX_STAT is > finished, so I can't use ng_send_msg() in NGM_XXX_STAT handler - nobody > will read sended messages and I finished up with "No buffer space > available". > > The question is: how I can initiate smth. like asynchronous reply (so I > can get data via NgRecvMsg later in my prgram)? Or I'm going wrong way and > should use another scheme for data transfer? Data size ranges from 10Kb to > 500Kb. Whenever you're ready to send the reply, just create one and send it. You'll want the same 'token' value in the reply and you'll want to set the NGF_REPLY bit in the flags word to indicate it's a reply. For an exmple of doing this, see pppoe_send_event() in ng_pppoe.c (this is not a reply but shows how to create and send a message). -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
Re: FreeBSD 4.3 crashing with USB hub attached...
It starts to look like memory trampling. I changed the code a bit and all of a sudden the device was accepted and no error 'no report descriptor' was displayed. :-( Try and add 'err' to the print statement that prints 'no report descriptor' in uhid.c. That should give you an indication in what part of that subroutine the code breaks (if it displays that error at all). So, I'll start looking for an error like that. *sigh* I HATE those bugs. They are so hard to find and in the end it is always some stupid little typo or off-by-one error. Dfr found an off-by-one error 'implemented' by me the other day (buffer[sizeof(buffer)] = '\0'). The symptoms were that the code would crash within throw, which made him chase through the gcc sources and Fred knows what else. Took him about 3 hours to, by chance, notice the problem. That cost me a round of beers :-) Nick > > I believe I had a similar problem back on 4.2-RELEASE with a PSX->USB adapter. > > >http://www.geocrawler.com/mail/thread.php3?subject=Broken-by-design+USB+device%3F&list=159 > > > > I sent the offending hardware off to Nick Hibma for him to look at, uh, 4 > > months ago. Is he back from vacation yet? > > Did you send him crash details? Would you mind sharing them with me if > you did? I want to do the same on my system and compare them. Might be > helpful to compare the two incidents. > > I've so far been unable to trigger a kernel panic with any other USB > hardware. I have another force feedback device to try and that's > pretty much it for me. > > After that I will submit a more detailed bug report if possible. > > -- > [EMAIL PROTECTED] _ > __/ armchairrocketscientistgraffitiexenstentialist > "And in billows of might swell the Saxons before her,-- Unite, oh > unite! Or the billows burst o'er her!" -- Downfall of the Gael > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD 4.3 crashing with USB hub attached...
If you could compile a kernel with debugging and debugger makeoptions DEBUG=-g options DDB and then type trace show registers and take it from there, that would be appreciated. Typing panic at the debugger prompt creates a crashdump which you can then fish out of swap space if you have dumpdev set in rc.conf. Nick On Mon, 14 May 2001, Chris Dillon wrote: > On Mon, 14 May 2001, Shannon Hendrix wrote: > > > Did you notice, before the crash, that the kernel had some trouble > > querying the offending device? That happens with me, and then a > > little while later in the boot it crashes. > > Yes, the symptoms were the same as yours. The initial probing during > boot took quite a while, and generated a few errors if I remember > correctly, then a panic shortly afterwards. I'm going to try my USB > joypad on my own 4.3-STABLE box tonight and see if I encounter any > problems, since I just got a new OHCI USB controller for it (I was > having what I can only explain as EMI/RFI problems with my on-board > USB controller). > > I'll be going to my friend's place this weekend, so I can get details > on what is happening with the joystick in question. > > > -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] >FreeBSD: The fastest and most stable server OS on the planet. >For IA32 and Alpha architectures. IA64, PPC, and ARM under development. >http://www.freebsd.org > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
From Senthil, Sydney
Hi Can you please suggest me from where can I download the API for Cd burning? I will be very thankful if you give me the details. You can reply me to [EMAIL PROTECTED] Regards Senthil To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD 4.3 crashing with USB hub attached...
On Thu, 17 May 2001, Nick Hibma wrote: > If you could compile a kernel with debugging and debugger > > makeoptions DEBUG=-g > options DDB > > and then type > > trace > show registers > > and take it from there, that would be appreciated. Typing panic at the > debugger prompt creates a crashdump which you can then fish out of swap > space if you have dumpdev set in rc.conf. No problem, I'll do this tomorrow night or Saturday, hopefully. Luckily he's on a cable modem, so moving a big crashdump around shouldn't be a big problem (I'll set MAXMEM on the debug kernel to a much more reasonable amount than 256MB, too). :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
De-setgid-ifying ipcs(1)
Hi folks,
ipcs(1) is currently installed as setgid kmem. This isn't good for
obvious reasons. Moreover, the information it needs is easily
exported via sysctl. Below is a patch which adds the necessary sysctl
oids and changes ipcs(1) to use them. I had to export msgids,
msginfo, sema, seminfo, shmsegs, and shminfo. The *info variables
were exported via SYSCTL_STRUCT, and the rest via SYSCTL_PROC. All
read-only by anyone. I'm not particuarly sure it's appropriate to
export the *info variables like that--at least one of them has most
(all?) of its members already exported via SYSCTL_INT, but that would
be a pain to use in this case. The patch preserves ipcs(1)'s ability
to operate on a saved kernel and core. In addition, I also added a -y
command line flag that will cause it to use kvm(3) instead of
sysctl(3), even on a running system.
Comments? Particuarly, I'd like comments on whether I exported
everything correctly.
Thanks in advance,
Dima Dorfman
[EMAIL PROTECTED]
Index: sys/kern/sysv_msg.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/sysv_msg.c,v
retrieving revision 1.30
diff -u -r1.30 sysv_msg.c
--- sys/kern/sysv_msg.c 2001/02/21 06:39:54 1.30
+++ sys/kern/sysv_msg.c 2001/05/18 04:41:24
@@ -1166,3 +1166,17 @@
p->p_retval[0] = msgsz;
return(0);
}
+
+static int
+sysctl_msqids(SYSCTL_HANDLER_ARGS)
+{
+
+ return (SYSCTL_OUT(req, msqids,
+ sizeof(struct msqid_ds) * msginfo.msgmni));
+}
+
+SYSCTL_DECL(_kern_ipc);
+SYSCTL_STRUCT(_kern_ipc, OID_AUTO, msginfo, CTLFLAG_RD, &msginfo, msginfo,
+"System V message info");
+SYSCTL_PROC(_kern_ipc, OID_AUTO, msqids, CTLFLAG_ANYBODY | CTLFLAG_RD,
+NULL, 0, sysctl_msqids, "", "Message queue IDs");
Index: sys/kern/sysv_sem.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/sysv_sem.c,v
retrieving revision 1.32
diff -u -r1.32 sysv_sem.c
--- sys/kern/sysv_sem.c 2001/02/21 06:39:54 1.32
+++ sys/kern/sysv_sem.c 2001/05/18 04:41:24
@@ -28,6 +28,7 @@
static int sysvsem_modload __P((struct module *, int, void *));
static int semunload __P((void));
static void semexit_myhook __P((struct proc *p));
+static int sysctl_sema __P((SYSCTL_HANDLER_ARGS));
#ifndef _SYS_SYSPROTO_H_
struct __semctl_args;
@@ -148,6 +149,9 @@
SYSCTL_INT(_kern_ipc, OID_AUTO, semusz, CTLFLAG_RD, &seminfo.semusz, 0, "");
SYSCTL_INT(_kern_ipc, OID_AUTO, semvmx, CTLFLAG_RW, &seminfo.semvmx, 0, "");
SYSCTL_INT(_kern_ipc, OID_AUTO, semaem, CTLFLAG_RW, &seminfo.semaem, 0, "");
+SYSCTL_STRUCT(_kern_ipc, OID_AUTO, seminfo, CTLFLAG_RD, &seminfo, seminfo, "");
+SYSCTL_PROC(_kern_ipc, OID_AUTO, sema, CTLFLAG_RD | CTLFLAG_ANYBODY,
+NULL, 0, sysctl_sema, "", "");
#if 0
RO seminfo.semmap /* SEMMAP unused */
@@ -1065,4 +1069,12 @@
#endif
suptr->un_proc = NULL;
*supptr = suptr->un_next;
+}
+
+static int
+sysctl_sema(SYSCTL_HANDLER_ARGS)
+{
+
+ return (SYSCTL_OUT(req, sema,
+ sizeof(struct semid_ds) * seminfo.semmni));
}
Index: sys/kern/sysv_shm.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/sysv_shm.c,v
retrieving revision 1.55
diff -u -r1.55 sysv_shm.c
--- sys/kern/sysv_shm.c 2001/05/04 18:43:19 1.55
+++ sys/kern/sysv_shm.c 2001/05/18 04:41:24
@@ -101,6 +101,7 @@
static int shmunload __P((void));
static void shmexit_myhook __P((struct proc *p));
static void shmfork_myhook __P((struct proc *p1, struct proc *p2));
+static int sysctl_shmsegs __P((SYSCTL_HANDLER_ARGS));
/*
* Tuneable values
@@ -141,6 +142,9 @@
SYSCTL_INT(_kern_ipc, OID_AUTO, shmseg, CTLFLAG_RD, &shminfo.shmseg, 0, "");
SYSCTL_INT(_kern_ipc, OID_AUTO, shmall, CTLFLAG_RW, &shminfo.shmall, 0, "");
SYSCTL_INT(_kern_ipc, OID_AUTO, shm_use_phys, CTLFLAG_RW, &shm_use_phys, 0, "");
+SYSCTL_STRUCT(_kern_ipc, OID_AUTO, shminfo, CTLFLAG_RD, &shminfo, shminfo, "");
+SYSCTL_PROC(_kern_ipc, OID_AUTO, shmsegs, CTLFLAG_ANYBODY | CTLFLAG_RD,
+NULL, 0, sysctl_shmsegs, "", "");
static int
shm_find_segment_by_key(key)
@@ -702,6 +706,13 @@
shm_committed = 0;
shmexit_hook = &shmexit_myhook;
shmfork_hook = &shmfork_myhook;
+}
+
+static int
+sysctl_shmsegs(SYSCTL_HANDLER_ARGS)
+{
+
+ return (SYSCTL_OUT(req, shmsegs, shmalloced * sizeof(shmsegs[0])));
}
static int
Index: usr.bin/ipcs/ipcs.1
===
RCS file: /st/src/FreeBSD/src/usr.bin/ipcs/ipcs.1,v
retrieving revision 1.11
diff -u -r1.11 ipcs.1
--- usr.bin/ipcs/ipcs.1 2000/12/14 11:49:46 1.11
+++ usr.bin/ipcs/ipcs.1 2001/05/18 04:41:24
@@ -37,7 +37,7 @@
.Nd report System V interprocess communication facilities status
.Sh SYNOPSIS
.Nm
-.Op Fl abcmopqstMQST
+.Op Fl abcmopqstMQSTy
.Op Fl C Ar system
.Op Fl N Ar core
.Sh DESCRIPTION
@@ -1
Re: De-setgid-ifying ipcs(1)
* Dima Dorfman <[EMAIL PROTECTED]> [010518 01:05] wrote:
> Hi folks,
>
> ipcs(1) is currently installed as setgid kmem. This isn't good for
> obvious reasons. Moreover, the information it needs is easily
> exported via sysctl. Below is a patch which adds the necessary sysctl
> oids and changes ipcs(1) to use them. I had to export msgids,
> msginfo, sema, seminfo, shmsegs, and shminfo. The *info variables
> were exported via SYSCTL_STRUCT, and the rest via SYSCTL_PROC. All
> read-only by anyone. I'm not particuarly sure it's appropriate to
> export the *info variables like that--at least one of them has most
> (all?) of its members already exported via SYSCTL_INT, but that would
> be a pain to use in this case. The patch preserves ipcs(1)'s ability
> to operate on a saved kernel and core. In addition, I also added a -y
> command line flag that will cause it to use kvm(3) instead of
> sysctl(3), even on a running system.
>
> Comments? Particuarly, I'd like comments on whether I exported
> everything correctly.
Probably not the commentary you're looking for, however the
getopt parsing shouldn't be done like this:
> - while ((i = getopt(argc, argv, "MmQqSsabC:cN:optT")) != -1)
> + use_sysctl = 1;
> + while ((i = getopt(argc, argv, "MmQqSsabC:cN:optTy")) != -1)
> switch (i) {
> case 'M':
> display = SHMTOTAL;
> @@ -184,39 +187,45 @@
> case 't':
> option |= TIME;
> break;
> + case 'y':
> + use_sysctl = !use_sysctl;
> + break;
> default:
> usage();
> }
Multiple -y options will invert the sense of the flag right?
Might as well inialize it to 1 in the DATA segment and replace
!use_sysctl with just 0.
I'm glad you kept kmem backwards compatibility, as this is required
for post mortem analysis of crashdumps.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Should I worryy?
I have a cdrom that defies logic: 1:14am harmony:/cdrom[51]> df /cdrom Filesystem 1024-blocks UsedAvail Capacity Mounted on /dev/acd0a 54 540 100%/cdrom 1:14am harmony:/cdrom[52]> du /cdrom 325460 /cdrom/chujiten/data 146 /cdrom/chujiten/gaiji 325608 /cdrom/chujiten 1089/cdrom/mac 1077/cdrom/win31 1425/cdrom/win95 329203 /cdrom 1:14am harmony:/cdrom[53]> Anything to worry about? Notice du says 329M, whild df says 54k. This is 4.3-stable as of the first of the month. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wint_t
"Daniel C. Sobral" wrote: > Terry Lambert wrote: > > Internationalization, in general, is the process of > > taking code, and making it so that it is possible to > > localize it into a particular -- monolingual -- locale. > > > > You need spacial software to deal with multilingual > > text; the vast majority of software doesn't have to > > do that (about the only place you will see it is in > > a translator-used application). > > Funny. I use it on e-mail. Perhaps if you lived in a country > that used a language other than English you would have a > different perception of this issue... I think you missed something when you cut out the part about "round trip" character sets. I'm rather certain that you aren't using Chinese and Japanese in the same email (or, if you are, that they are seperately encoded MIME attachments). If I use JIS-208 + JIS-212, I can actually encode any of 21 human languages in that single character set (it has a prefix of ISO-8859-1). The point is that a locale inclides a character set, that is not really specific to a single language. I'm also rather certain that your email client, when you make an error, gives you the error message in just a single language. Yeah, I use ISO 8859-1 for most of my email... it gets encoded as US ASCII, if I don't use high-bit-set characters. I could write English, German, Italian, French, Icelandic, etc., etc. That _doesn't_ mean I'm using more than a single locale, though. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ifindex
Hi, why is ifindex used for an interface.i know it is said itz for unique identification of device.Can we not do that using interfac name ?what is significance of ifindex for an interface. itz just a number associated with an interface. TIA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
