Re: patch for test: /etc/shells - /usr/local/etc/shells
On Fri, 26 Jan 2001 14:13:42 -0800 (PST)
John Baldwin [EMAIL PROTECTED] wrote:
JB 1) All parsing of /etc/shells should move off into libutil under a
JBsuitable API.
There is one in libc/gen that would do fine. The catch is that it
is not used everywhere and some of the code that fails to use it is in contrib
and I am not too sure of the wisdom of changing it.
JB 2) The implementation of this API should allow for multiple files that it
JBchecks. One way might be to add a '.include' keyword or something so
JBthat /etc/shells could have '.include /usr/local/etc/shells' that the
JBadmin could adjust should he/she choose to change ${LOCALBASE} to
JBsomething other than /usr/local.
I did consider an include mechanism and making _PATH_SHELLS a path list.
I was leaning in the direction of an include mechanism when the (bad) idea of
changing _PATH_SHELLS to point to /usr/local which removed any need to patch
roken, adduser.pl and sendmail.
JB This is more work than your patch, but this patch doesn't really solve
JB the problem, it merely moves it. It also breaks for ${LOCALBASE}
JB != /usr/local, so I don't think it should go in.
Good points, agreed.
Thoughts please on the wisdom of patching the above areas to handle
an include syntax, my worry is maintenance since most of it is contib. I don't
know if I would be introducing the first changes to them (in which cas I will
not) or just one of many (in which case I'll start coding). ?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
kernel threading: the first steps [patch]
Here's a first step.
I've broken the proc structure into 4 structures. At this moment the proc
structure includes
the other three, so there is no problem with allocation, and there is always
a 1:1 correlation between them at this time so this is safe.
SOme of the fields are probably in the wrong structs but it doesn't matter for
his patch.
The aim of this patch is to make people think about which fields go to which
structures and what new fields are needed.
Remarkably the kernel compiles and runs!
The purposes of the structs in this setting are:
1/ The kse struct is known to the scheduler, associated with a CPU and scheduled
whenever there
as a context to run.
2/The ksec is a stored context that is associated with a kse, but for some
reason cannot be running now.
3/The KSEG has a priority, nice value, etc. KSECs tha complete may be reported
back to the
userland scheduler on he next KSE within the same KSEG. Timers are in KSEG
scope.
Signals are in KSEG scope too?
4/Al resorces and permissions are owned by the original proc sruct.
these definitions are open for discussion but they give some grounds to work on
regarding which fields go where
After deciding what the semantics are and assigning fields to structures,
(and how they are linked), we can then work out which functions in the kernel
take which structure as arguments, and them work towards divorcing them so that
the 1:1 relationship is broken.
At that stage we have threads.
thoughts?.
--
__--_|\ Julian Elischer
/ \ [EMAIL PROTECTED]
( OZ) World tour 2000-2001
--- X_.---._/
v
Index: kern/kern_fork.c
===
RCS file: /unused/cvs/freebsd/src/sys/kern/kern_fork.c,v
retrieving revision 1.94
diff -u -r1.94 kern_fork.c
--- kern/kern_fork.c2001/01/24 10:47:14 1.94
+++ kern/kern_fork.c2001/01/27 03:53:12
@@ -371,6 +371,24 @@
bcopy(p1-p_startcopy, p2-p_startcopy,
(unsigned) ((caddr_t)p2-p_endcopy - (caddr_t)p2-p_startcopy));
+ bzero(p2-kse0.kse_startzero,
+ (unsigned) ((caddr_t)p2-kse0.kse_endzero
+ - (caddr_t)p2-kse0.kse_startzero));
+ bcopy(p1-kse0.kse_startcopy, p2-kse0.kse_startcopy,
+ (unsigned) ((caddr_t)p2-kse0.kse_endcopy
+ - (caddr_t)p2-kse0.kse_startcopy));
+
+ bzero(p2-ksec0.ksec_startzero,
+ (unsigned) ((caddr_t)p2-ksec0.ksec_endzero
+ - (caddr_t)p2-ksec0.ksec_startzero));
+ bcopy(p1-ksec0.ksec_startcopy, p2-ksec0.ksec_startcopy,
+ (unsigned) ((caddr_t)p2-ksec0.ksec_endcopy
+ - (caddr_t)p2-ksec0.ksec_startcopy));
+
+ bcopy(p1-kseg0.kseg_startcopy, p2-kseg0.kseg_startcopy,
+ (unsigned) ((caddr_t)p2-kseg0.kseg_endcopy
+ - (caddr_t)p2-kseg0.kseg_startcopy));
+
mtx_init(p2-p_mtx, "process lock", MTX_DEF);
p2-p_aioinfo = NULL;
Index: sys/proc.h
===
RCS file: /unused/cvs/freebsd/src/sys/sys/proc.h,v
retrieving revision 1.141
diff -u -r1.141 proc.h
--- sys/proc.h 2001/01/24 09:41:03 1.141
+++ sys/proc.h 2001/01/27 03:52:53
@@ -141,18 +141,157 @@
* m - Giant
* n - not locked, lazy
*/
+struct proc; /* forward decl. */
+
+/*
+ * The schedulable entity that can be given a context to run.
+ * A process may have several of these. Probably one per processor
+ * but posibly a few more. In this universe they are grouped
+ * with a KSEG that contains the priority and niceness
+ * for the group.
+ */
+struct kse {
+ /* individualy set up */
+ struct pstats *kse_stats; /* (bk) Accounting/statistics (CPU). */
+#define kse_startzero kse_estcpu
+ /* start zero */
+ u_int kse_estcpu; /* (jk) Time averaged value of kse_cpticks. */
+ int kse_cpticks;/* (jk) Ticks of cpu time. */
+ fixpt_t kse_pctcpu; /* (jk) %cpu during p_swtime. */
+ u_int64_t kse_uu; /* (jk) Previous user time in microsec. */
+ u_int64_t kse_su; /* (jk) Previous system time in microsec. */
+ u_int64_t kse_iu; /* (jk) Previous interrupt time in microsec. */
+ u_int64_t kse_uticks; /* (jk) Statclock hits in user mode. */
+ u_int64_t kse_sticks; /* (jk) Statclock hits in system mode. */
+ u_int64_t kse_iticks; /* (jk) Statclock hits processing intr. */
+ u_int kse_slptime;/* (jk) Time since last blocked. */
+ u_char kse_oncpu; /* (jk) Which cpu we are on. */
+ charkse_rqindex;/* (jk) Run queue index. */
+ register_t kse_retval[2]; /* (kk) Syscall aux returns. */
+ /* end zero */
+#define kse_endzero kse_priority
+#define kse_startcopy kse_priority
+ /* start copy */
+ u_char kse_priority; /* (jk) Process priority. */
+ u_char kse_usrpri; /* (jk) User
Re: kernel threading: the first steps [patch]
In message [EMAIL PROTECTED], Root Dude writes: Here's a first step. I've broken the proc structure into 4 structures. [...] Uhm Julian, You are aware that other people are working on this stuff too ? -- 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-current" in the body of the message
OpenSSL 0.9.6-STABLE snapshot
Please test the code at http://www.freebsd.org/~kris/openssl-0.9.6-stable.tgz - it's the latest snapshot of the OpenSSL 0.9.6-STABLE branch, containing lots of bugfixes against 0.9.6 etc. Just blat it over the top of your existing files from /usr/src. I especially want people to test it for binary compatability with ports etc - when I imported 0.9.6 no-one bothered to tell me about the broken binary compat, until AFTER I merged it into 4.x. Kris PGP signature
Re: patch for test: /etc/shells - /usr/local/etc/shells
On Sat, 27 Jan 2001 00:27:13 -0800 (PST) John Baldwin [EMAIL PROTECTED] wrote: JB How many contrib'd apps need to look at /etc/shells? The biggest one I think JB is sendmail, and Greg Shapiro is a very reasonable fellow, and can probably JB assist in getting sendmail at least to use the API as long as it isn't too JB inconvenient. I feel encouraged. The other are it turns up is in the crypto section crypto/heimdal/lib/roken/getusershell.c and /crypto/kerberosIV/lib/roken/getusershell.c I think these are the same. The getusershell seems to be the API to use. It will probably have to be redone in perl for adduser.perl but that's no great problem. Now for the bikeshed question .include or #include ? BTW: I did consider cpp or m4 *briefly*. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel threading: the first steps [patch]
On Sat, Jan 27, 2001 at 12:33:23AM -0800, Root Dude wrote: Here's a first step. This is very disappointing, Julian. You've duplicated work that I've already done, and if you've been paying attention at all, you know that it was already done. Even if you haven't been paying attention, I find it particularly telling that you never even sent me email about this. This is the single most flagrant lack of cooperation I have experienced while working with the FreeBSD Project. I'm truly dumbfounded. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells - /usr/local/etc/shells
On Sat, 27 Jan 2001 00:27:13 -0800 (PST) John Baldwin [EMAIL PROTECTED] wrote: JB How many contrib'd apps need to look at /etc/shells? The biggest one I think JB is sendmail, and Greg Shapiro is a very reasonable fellow, and can probably JB assist in getting sendmail at least to use the API as long as it isn't too JB inconvenient. Life is better than I thought the crypto stuff just has it as a fallback conditional on HAVE_GETUSERSHELL so that uses the one from libc. Which leaves only sendmail which is similar but for some reason does not have HASGETUSERSHELL set for FreeBSD (I think - the conf is convoluted). Meanwhile I am building with a getusershell(3) that knows how to follow a #include (it was already looking for # which pushed the bikeshed marginally that way). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XXX driver didn't initialize queue mtx
# dmesg ... xl0 XXX: driver didn't initialize queue mtx lo0 XXX: driver didn't initialize queue mtx isp0 XXX: driver didn't initialize queue mtx isp1 XXX: driver didn't initialize queue mtx isp2 XXX: driver didn't initialize queue mtx isp3 XXX: driver didn't initialize queue mtx ... Anything to worry about? 5.0-CURRENT as of today. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
Blaz Zupan [EMAIL PROTECTED] writes: xl0 XXX: driver didn't initialize queue mtx [...] Nothing to worry about, it's just a reminder for us kernel jocks. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
Oh, yeah- can someone say *which* queue mtx it's referring to? On 27 Jan 2001, Dag-Erling Smorgrav wrote: Blaz Zupan [EMAIL PROTECTED] writes: xl0 XXX: driver didn't initialize queue mtx [...] Nothing to worry about, it's just a reminder for us kernel jocks. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic on last night's kernel
Hi, cvsup at Sat Jan 27 04:04:26 GMT 2001 While booting, just after the message: faith0 XXX: driver didn't initialize queue mtx panic: malloc(M_WAITOK) in interrupt context DDB gives: panic() malloc() exit1() kthread_suspend() ithd_loop() fork_exit() fork_trampoline() -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
LyX 1.1.5.2 dumping core
I just rebuilt my -current system yesterday, and now LyX is throwing up all over itself. It starts up fine, but if I try to load a document or create a new one, it immediately dumps core. The problem seems to be occuring the the xforms library. I have a fresh copy of the compat3x distribution from 4.2-RELEASE installed, but LyX is still unhappy. Does anyone have any suggestions on how I might fix this? I'm not opposed to reverting back to a version of -current from earlier this month. The previous version I was running was from approximately January 5. -Patrick Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
Matthew Jacob [EMAIL PROTECTED] writes:
Oh, yeah- can someone say *which* queue mtx it's referring to?
des@des ~% current "driver didn.t initialize"
src/sys/net/if.c: printf("%s%d XXX: driver didn't initialize
queue mtx\n",
des@des ~% grep -C "driver didn.t initialize" /sys/net/if.c
/* XXX This is an access violation of the mutex internals. */
if (ifp-if_snd.ifq_mtx.mtx_flags == 0) {
printf("%s%d XXX: driver didn't initialize queue mtx\n",
ifp-if_name, ifp-if_unit);
mtx_init(ifp-if_snd.ifq_mtx, "unknown", MTX_DEF);
That wasn't so hard, was it?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells - /usr/local/etc/shells
On Sat, Jan 27, 2001 at 01:57:40PM +0100, Steve O'Hara-Smith wrote: Life is better than I thought the crypto stuff just has it as a fallback conditional on HAVE_GETUSERSHELL so that uses the one from libc. Which leaves only sendmail which is similar but for some reason does not have HASGETUSERSHELL set for FreeBSD (I think - the conf is convoluted). Meanwhile I am building with a getusershell(3) that knows how to follow a #include (it was already looking for # which pushed the bikeshed marginally that way). You could just use the nsdispatch() API that is in -CURRENT, and that getusershell() uses. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells - /usr/local/etc/shells
On Sat, 27 Jan 2001 13:17:22 -0600 "Jacques A. Vidrine" [EMAIL PROTECTED] wrote: JV You could just use the nsdispatch() API that is in -CURRENT, and that JV getusershell() uses. I'm not sure what for, the changes I've made fit just as smoothly into _local_initshells as they do into initshells. Is there an include chain follower in there that I've missed ? That's what I've added. It's working in the test harness and awaiting buildworld. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
Oh, I suppose, I did find that... well, mainly I wanted the person who made
the change to actually broadcast to NIC maintainers what the expectations
were...
Matthew Jacob [EMAIL PROTECTED] writes:
Oh, yeah- can someone say *which* queue mtx it's referring to?
des@des ~% current "driver didn.t initialize"
src/sys/net/if.c: printf("%s%d XXX: driver didn't initialize
queue mtx\n",
des@des ~% grep -C "driver didn.t initialize" /sys/net/if.c
/* XXX This is an access violation of the mutex internals. */
if (ifp-if_snd.ifq_mtx.mtx_flags == 0) {
printf("%s%d XXX: driver didn't initialize queue mtx\n",
ifp-if_name, ifp-if_unit);
mtx_init(ifp-if_snd.ifq_mtx, "unknown", MTX_DEF);
That wasn't so hard, was it?
DES
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote: Oh, I suppose, I did find that... well, mainly I wanted the person who made the change to actually broadcast to NIC maintainers what the expectations were... The code that prints these warnings out has existed for a while. However, whoever added it made a bad assumption about the internals of the mutex implementation, so the code never got executed. I "fixed" it last week, so the warnings get printed now. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
Shouldn't ether_ifattach initialize the mutex? Or do expect all drivers to initialize these prior to calling ether_ifattach? Look- I just want to know what the people who put the check in *want*. On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote: Oh, I suppose, I did find that... well, mainly I wanted the person who made the change to actually broadcast to NIC maintainers what the expectations were... The code that prints these warnings out has existed for a while. However, whoever added it made a bad assumption about the internals of the mutex implementation, so the code never got executed. I "fixed" it last week, so the warnings get printed now. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI changes break HP Docking Station
This is weird; the bridge appears to be clearly misconfigured, and unless there's something funky in the datasheet (looking for it now) I'm not quite sure what the "right" thing to do is here. 8( Please let me know if you need anything more from me to help debug this. This is enough for now; if I'm really lucky I might have some suggested changes for you... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
On Sat, Jan 27, 2001 at 12:48:36PM -0800, Matthew Jacob wrote: Somewhere in between, Jason Evans wrote: On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote: Oh, I suppose, I did find that... well, mainly I wanted the person who made the change to actually broadcast to NIC maintainers what the expectations were... The code that prints these warnings out has existed for a while. However, whoever added it made a bad assumption about the internals of the mutex implementation, so the code never got executed. I "fixed" it last week, so the warnings get printed now. Shouldn't ether_ifattach initialize the mutex? Or do expect all drivers to initialize these prior to calling ether_ifattach? Look- I just want to know what the people who put the check in *want*. cvs annotate is your friend. The code was added in revision 1.95 of src/sys/net/if.c by Jonathan Lemon. Please talk to him about what should be done to fix the drivers. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
cvs annotate is your friend. The code was added in revision 1.95 of src/sys/net/if.c by Jonathan Lemon. Please talk to him about what should be done to fix the drivers. Yes, and I shall... but this came up in a public forum. I'm making a point here (that apparently you and others don't get). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote:
Oh, I suppose, I did find that... well, mainly I wanted the person who made
the change to actually broadcast to NIC maintainers what the expectations
were...
The code that prints these warnings out has existed for a while. However,
whoever added it made a bad assumption about the internals of the mutex
implementation, so the code never got executed. I "fixed" it last week, so
the warnings get printed now.
Actually, I think it was correct at the time I added it. Anything
that calls if_attach (or ether_ifattach) will automatically have the
mutex correctly initialized, so the driver doesn't have to do anything
extra.
e.g.:
ifp-if_name = "lo";
ifp-if_unit = i++;
ifp-if_snd.ifq_maxlen = ifqmaxlen;
if_attach(ifp);
if_attach(ifp)
{
mtx_init(ifp-if_snd.ifq_mtx, ifp-if_name, MTX_DEF);
...
}
I'm not up-to-date with -current at the moment, so I'm not sure
why things aren't working any more.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
On Sat, Jan 27, 2001 at 01:05:58PM -0800, Jason Evans wrote:
On Sat, Jan 27, 2001 at 12:48:36PM -0800, Matthew Jacob wrote:
Somewhere in between, Jason Evans wrote:
On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote:
Oh, I suppose, I did find that... well, mainly I wanted the person who made
the change to actually broadcast to NIC maintainers what the expectations
were...
The code that prints these warnings out has existed for a while. However,
whoever added it made a bad assumption about the internals of the mutex
implementation, so the code never got executed. I "fixed" it last week, so
the warnings get printed now.
Shouldn't ether_ifattach initialize the mutex? Or do expect all drivers to
initialize these prior to calling ether_ifattach?
Look- I just want to know what the people who put the check in *want*.
cvs annotate is your friend. The code was added in revision 1.95 of
src/sys/net/if.c by Jonathan Lemon. Please talk to him about what should
be done to fix the drivers.
Actually, the new check appears to be incorrect, as seen by the code
fragments below:
#define MTX_DEF 0x0 /* Default (spin/sleep) */
mtx_init(ifp-if_snd.ifq_mtx, ifp-if_name, MTX_DEF);
mtx_init(... , flag)
{
...
m-mtx_flags = flag;
...
}
if (ifp-if_snd.ifq_mtx.mtx_flags == 0) {
So the warning will always be printed out even though the mutex is
correctly initialized.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Fixed: LyX 1.1.5.2 dumping core
Patrick Hartling [EMAIL PROTECTED] wrote: } I just rebuilt my -current system yesterday, and now LyX is throwing up } all over itself. It starts up fine, but if I try to load a document or } create a new one, it immediately dumps core. The problem seems to be } occuring the the xforms library. I have a fresh copy of the compat3x } distribution from 4.2-RELEASE installed, but LyX is still unhappy. Does } anyone have any suggestions on how I might fix this? I'm not opposed to } reverting back to a version of -current from earlier this month. The } previous version I was running was from approximately January 5. Making a symlink from /usr/lib/libc.so.5 to /usr/lib/libc.so.3 seems to have fixed my LyX problems. I'm guessing libc.so.5 and libc.so.3 were causing conflicts, especially with the recent changes to libc, but I'm no expert. Whatever the case, I can get back to work on my thesis now. :) -Patrick Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel hangs initializing Soundblaster AWE 64 midi driver
Hi, I'm tracking -CURRENT and build a kernel yesterday with the following options (edited): device sbc # Soundblaster Bridge-Code to pcm device pcm # PnP/PCI Sound Cards #device midi# Midi interfaces #device seq # Sequencer The corresponding hints are: none Without midi device, this is the relevant dmesg part: [...] vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b \ irq 5 drq 1,5 on isa0 pcm1: SB16 DSP 4.16 on sbc0 unknown: PNP0401 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0303 can't assign resources ed0 XXX: driver didn't initialize queue mtx lp0 XXX: driver didn't initialize queue mtx lo0 XXX: driver didn't initialize queue mtx ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable [...] and the kernel happily boots. Sound is usable as before. Now, adding midi (either alone or together with seq) produces the following messages: sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b \ irq 5 drq 1,5 on isa0 pcm1: SB16 DSP 4.16 on sbc0 midi0: SB Midi Interface on sbc0 midi1: SB OPL FM Synthesizer on sbc0 midi2: CTL0022 WaveTable Synthesizer at port 0x620-0x623 on isa0 exactly here, the system hangs completely. What I'm I missing? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells - /usr/local/etc/shells
On Sat, Jan 27, 2001 at 08:48:59PM +0100, Steve O'Hara-Smith wrote: On Sat, 27 Jan 2001 13:17:22 -0600 "Jacques A. Vidrine" [EMAIL PROTECTED] wrote: JV You could just use the nsdispatch() API that is in -CURRENT, and that JV getusershell() uses. I'm not sure what for, the changes I've made fit just as smoothly into _local_initshells as they do into initshells. Is there an include chain follower in there that I've missed ? That's what I've added. It's working in the test harness and awaiting buildworld. I thought you might add it as a different source, so that it need not be the default. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
On 27-Jan-01 Matthew Jacob wrote: Oh, yeah- can someone say *which* queue mtx it's referring to? The if queues. Ones with the IFQ_ENQUEUE() etc. macros. On 27 Jan 2001, Dag-Erling Smorgrav wrote: Blaz Zupan [EMAIL PROTECTED] writes: xl0 XXX: driver didn't initialize queue mtx [...] Nothing to worry about, it's just a reminder for us kernel jocks. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CD Extra disks on atapi-cd
Hi.
I've found that -current kernel couldn't mount CD-Extra disks on
ATAPI CD drives.
For example:
Starting track = 1, ending track = 14, TOC size = 122 bytes
track start duration block length type
-
1 0:02.00 0:11.52 0 727 audio
2 0:11.52 3:58.55 727 17755 audio
3 4:08.32 2:15.55 18482 10030 audio
4 6:22.12 3:10.50 28512 14150 audio
5 9:30.62 3:02.13 42662 13513 audio
6 12:31.00 2:54.00 56175 12900 audio
7 15:23.00 3:50.40 69075 17140 audio
8 19:11.40 2:59.12 86215 13287 audio
9 22:08.52 3:04.30 99502 13680 audio
10 25:11.07 2:06.05 1131829305 audio
11 27:15.12 2:54.35 122487 12935 audio
12 30:07.47 3:17.13 135422 14638 audio
13 33:22.60 12:53.27 150060 57852 audio
14 46:14.12 20:50.58 207912 93658 data
170 67:02.70 - 301570 - -
Tracks 1-13 are normal CD-DA in the first session,
and track 14 is the ISO9660 filesystem which consists of
XA Mode 2 Form 1 sectors (2048bytes/sector) in the second session.
This disk can be mounted on my SCSI CD drive,
but not on my ATAPI CD drive (with EINVAL).
I applied the following patch,
and then I can successfully mount the disk.
Is this a right treatment?
--- sys/dev/ata/atapi-cd.c Fri Jan 19 06:01:25 2001
+++ sys/dev/ata/atapi-cd.c.new Sun Jan 28 08:15:37 2001
@@ -1227,7 +1227,7 @@
static void
acd_read_toc(struct acd_softc *cdp)
{
-int ntracks, len;
+int ntracks, len, t;
int8_t ccb[16];
bzero(cdp-toc, sizeof(cdp-toc));
@@ -1275,7 +1275,14 @@
cdp-info.volsize = ntohl(cdp-info.volsize);
cdp-info.blksize = ntohl(cdp-info.blksize);
-cdp-block_size = (cdp-toc.tab[0].control 4) ? 2048 : 2352;
+
+cdp-block_size = 2352;
+for (t = 0; t cdp-toc.hdr.ending_track; t++) {
+if (cdp-toc.tab[t].control 4) {
+ cdp-block_size = 2048;
+ break;
+}
+}
bzero(cdp-disklabel, sizeof(struct disklabel));
strncpy(cdp-disklabel.d_typename, " ",
--
Motomichi Matsuzaki [EMAIL PROTECTED]
Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Building -STABLE on -CURRENT
On Mon, Jan 22, 2001 at 03:46:51PM -0500, Benjamin Lewis wrote:
Robert,
You wrote:
For the last few days (not sure when it started) I've been unable to build
-STABLE on a -CURRENT machine. This has proven a problem for recent
RELENG_3 MFC's of security fixes; I've tried upgrading to the most recent
-CURRENT on the box, making sure /usr/include is updated, et al. I'm
guessing this is /usr/include pollution in the /usr/src build, but won't
speculate too much more as I'm travelling tomorrow. Attached below is the
breakage from buildworld.
[...]
cd /usr/src/share/syscons/scrnmaps; make build-tools
cc -static -O -pipe -I/usr/src/share/syscons/scrnmaps
-DFIL=\"koi8-r2cp866\"
-o koi8-r2cp866.mk /usr/src/share/syscons/scrnmaps/mkscrfil.c
In file included from /usr/src/share/syscons/scrnmaps/mkscrfil.c:28:
/usr/include/machine/console.h:3: #error "this file includes
machine/console.h
which is deprecated, use sys/{kb,cons,fb}io.h instead"
I've seen the same thing. I hacked up the -stable source to include the
correct -current include files to get past this, but that strikes me as
extremely non-optimal. I tried hacking up the Makefile in
/usr/src/share/syscons/scrnmaps to use a different include path, but don't
have the know-how or mojo to get that working.
I've just hit the same problem... Has anybody got a real fix for this?
--
Sean Kelly | PGP KeyID: 77042C7B
[EMAIL PROTECTED] | http://www.zombie.org
For PGP key, send e-mail with subject "send pgp key"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
HEADSUP: WITNESS adn modules == bad juju
Boris reminded me of someething I had forgotten to mention: currently unloading a module that uses mutexes with WITNESS enabled in the kernel will panic the kernel, cause witness tries to look at the string of the mutex name which is usually a constant in the module later on. This leads to a kernel page fault basically, so until I get this fixed, you really can't unload modules with WITNESS right now. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
On Sat, Jan 27, 2001 at 03:19:04PM -0600, Jonathan Lemon wrote: Actually, the new check appears to be incorrect, as seen by the code fragments below: Whoops. I obviously looked at the wrong #define when making the change. Thanks for pointing out the mistake. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells - /usr/local/etc/shells
On Sat, 27 Jan 2001 16:59:41 -0600 "Jacques A. Vidrine" [EMAIL PROTECTED] wrote: JV I thought you might add it as a different source, so that it need not be JV the default. As I read it that is still a complementary possibility. The nsdispatch stuff could move the start point from /etc/shells to some other path. The include chain mechanism allows the config to be spread. Have I correctly understood what the nsdispatch stuff can do ? Is it expected to MFC or wait for 5.0 ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells - /usr/local/etc/shells
Steve O'Hara-Smith wrote: On Fri, 26 Jan 2001 16:21:01 -0500 (EST) Garrett Wollman [EMAIL PROTECTED] wrote: GW On Fri, 26 Jan 2001 22:08:20 +0100, "Steve O'Hara-Smith" [EMAIL PROTECTED] said: GW GWThe patch below (against 4-stable but it will probably apply easily GW to -current) moves /etc/shells to /usr/local/etc/shells. GW GW Bad idea. No base component (never mind libc!) should hard-code a GW pathname in /usr/local. I'll consider it flamed to death then :) It was intended to prevent port installs having to write in /etc without having to change libc/gen, roken and sendmail which I rather suspect is also a bad thing to do. Perhaps /etc/shells is the least of all evils here. There is a difference between a port creating a config file in /etc, and a port adding to a standard config file in etc. The former is a bad idea, the latter necessary. The other solution would be to allow a PATH of shells files, but that seems rather messy for something this simple. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
