RE: MIDI on SB Live! ?
just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Nobody. Our target for nearest future is Audigy/Audigy2 support. Yuriy Tsibizov, http://chibis.persons.gfk.ru/audigy/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gre problems.
Slight problem with FreeBSD 5.0-RELEASE-p4. When the machine is freshly booted, I can create a tunnel fine, it'll ping for a while. When the link fails, it doesn't re-establish the lin. I decided to ifconfig gre0 destroy and create it again, after the tunnel is created again the system barks the following error message: Mar 24 04:04:25 hellraiser kernel: gre0: unable to attach encap Anyone ever got this problem yet ? (4.7 - 5.0) (More information can be provided.) -- -- | Jean-Francois Laforest | --- | http://www.ipv6peer.net/ | IPv6 Peer +01-514-524-8120 | | [EMAIL PROTECTED] | BOFH: What was your usename ? :)| --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: MIDI on SB Live! ?
Am Mo, 2003-03-24 um 07.47 schrieb Yuriy Tsibizov: just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Nobody. Our target for nearest future is Audigy/Audigy2 support. Yuriy Tsibizov, http://chibis.persons.gfk.ru/audigy/ Your page says: 0. It works for SB Live! and Audigy. Not for Audigy2. and MIDI is on the TODO-list So, guess there is still some hope for SB Live! MIDI in the not-so-near future. :) Or are the differences between an EMU10K2 (as seen in the dmesg, I guess Audigy?) and EMU10K1 that big? Regards, Julian Stecklina signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RE: MIDI on SB Live! ?
From: Julian St. [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 3:26 PM just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Nobody. Our target for nearest future is Audigy/Audigy2 support. Your page says: 0. It works for SB Live! and Audigy. Not for Audigy2. and MIDI is on the TODO-list Yes, MIDI I/O is in my TODO list, but I'm not working on it now. So, guess there is still some hope for SB Live! MIDI in the not-so-near future. :) I can't promise that I start to code MIDI I/O in nearest future Mostly because I don't need it. I don't have any MIDI device at home or at work. Or are the differences between an EMU10K2 (as seen in the dmesg, I guess Audigy?) and EMU10K1 that big? EMU10K2=Audigy MIDI I/O should be almost the same between EMU10Kx cards... But I don't have any MIDI devices (other than AudigyDrive remote control, it should act as a MIDI controller on second MIDI port, AFAIK) to check it. Yuriy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV(8) manpage
On Mon, Mar 24, 2003 at 09:40:32AM +0200, Jarkko Santala wrote: On Sun, 23 Mar 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Christian Brueffer writes: now that MAKEDEV has been gone for a while, the manpages (alpha and i386) can be nuked as well, right? Right. Although it might be considered dragging old baggage around, would it make sense to instead of zapping the man page completely write a new one that would at least give a clue on how things are done these days? Otherwise unclued people might just think there's something wrong with their system because the man page is missing and get even more confused. -jake Well, people are supposed to read UPDATING before updating the system. UPDATING already has an entry about this, so has the handbook, the release notes etc. I think we can't really help people that don't read the recommended documentation. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
RE: MIDI on SB Live! ?
Am Mo, 2003-03-24 um 14.02 schrieb Yuriy Tsibizov: MIDI I/O should be almost the same between EMU10Kx cards... But I don't have any MIDI devices (other than AudigyDrive remote control, it should act as a MIDI controller on second MIDI port, AFAIK) to check it. I have several devices to test it on. :) Perhaps until then I have learned enough (sound) driver hacking that I could adapt (with the help of some hardware documentation) your EMU10K2 MIDI code to EMU10K1 boards. It is a bit hard to get started though. Regards, Julian Stecklina signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Linux emulation busted
I had a working Linux world on my laptop. I upgraded my kernel and acroread4 stopped working. Now all I get is: Exited with error code: 0x400e0009. after a whole lot of disk access when I try to run it. This worked on a December kernel for sure. I'm pretty sure it was working as late as a January 15th kernel. It hasn't worked on a March 1st and subsequent kernels. I'm not sure where it broke inbetween. Has anybody else seen this? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
jail(8) setuid-before-exec patch
Hello,
Here is a patch which gives to jail(8) an ability to specify a user
context before execv(3). Comments/suggestions?
P.S. I am aware of bin/44320.
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/jail/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile20 Jul 2001 06:19:52 - 1.8
+++ Makefile21 Mar 2003 14:16:25 -
@@ -2,6 +2,7 @@
PROG= jail
MAN= jail.8
+LDADD= -lutil
WARNS?=2
Index: jail.8
===
RCS file: /home/ncvs/src/usr.sbin/jail/jail.8,v
retrieving revision 1.41
diff -u -r1.41 jail.8
--- jail.8 18 Mar 2003 14:01:02 - 1.41
+++ jail.8 24 Mar 2003 15:06:08 -
@@ -41,11 +41,28 @@
.Nd imprison process and its descendants
.Sh SYNOPSIS
.Nm
+.Op Fl u Ar username
.Ar path hostname ip-number command ...
.Sh DESCRIPTION
The
.Nm
utility imprisons a process and all future descendants.
+.Pp
+The options are as follows:
+.Bl -tag -width .Fl u Ar username
+.It Fl u Ar username
+The user name as whom the
+.Ar command
+should run.
+.It Ar path
+Directory which is to be the root of the prison.
+.It Ar hostname
+Hostname of the prison.
+.It Ar ip-number
+IP number assigned to the prison.
+.It Ar command
+Pathname of the program which is to be executed.
+.El
.Pp
Please see the
.Xr jail 2
Index: jail.c
===
RCS file: /home/ncvs/src/usr.sbin/jail/jail.c,v
retrieving revision 1.8
diff -u -r1.8 jail.c
--- jail.c 22 Apr 2002 13:44:43 - 1.8
+++ jail.c 21 Mar 2003 16:15:15 -
@@ -10,44 +10,97 @@
*
*/
-#include sys/types.h
+#include sys/param.h
#include sys/jail.h
#include netinet/in.h
#include arpa/inet.h
#include err.h
+#include grp.h
+#include login_cap.h
+#include pwd.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
+static voidusage(void);
+
int
main(int argc, char **argv)
{
+ login_cap_t *lcap;
struct jail j;
- int i;
+ struct passwd *pwd;
struct in_addr in;
+ int ch, groups[NGROUPS], i, ngroups;
+ char *username;
+
+ username = NULL;
+
+ while ((ch = getopt(argc, argv, u:)) != -1)
+ switch (ch) {
+ case 'u':
+ username = optarg;
+ break;
+ default:
+ usage();
+ break;
+ }
+ argc -= optind;
+ argv += optind;
+ if (argc 4)
+ usage();
- if (argc 5)
- errx(1, usage: %s path hostname ip-number command ...\n,
- argv[0]);
- i = chdir(argv[1]);
+ if (username != NULL) {
+ pwd = getpwnam(username);
+ if (pwd == NULL)
+ err(1, getpwnam %s, username);
+ lcap = login_getpwclass(pwd);
+ if (lcap == NULL)
+ err(1, getpwclass failed, username);
+ ngroups = NGROUPS;
+ i = getgrouplist(username, pwd-pw_gid, groups, ngroups);
+ if (i)
+ err(1, getgrouplist %s, username);
+ }
+ i = chdir(argv[0]);
if (i)
- err(1, chdir %s, argv[1]);
+ err(1, chdir %s, argv[0]);
memset(j, 0, sizeof(j));
j.version = 0;
- j.path = argv[1];
- j.hostname = argv[2];
- i = inet_aton(argv[3], in);
+ j.path = argv[0];
+ j.hostname = argv[1];
+ i = inet_aton(argv[2], in);
if (!i)
errx(1, Couldn't make sense of ip-number\n);
j.ip_number = ntohl(in.s_addr);
i = jail(j);
if (i)
err(1, Imprisonment failed);
- i = execv(argv[4], argv + 4);
+ if (username != NULL) {
+ i = setgroups(ngroups, groups);
+ if (i)
+ err(1, setgroups failed);
+ i = setgid(pwd-pw_gid);
+ if (i)
+ err(1, setgid failed);
+ i = setusercontext(lcap, pwd, pwd-pw_uid,
+ LOGIN_SETALL ~LOGIN_SETGROUP);
+ if (i)
+ err(1, setusercontext failed);
+ }
+ i = execv(argv[3], argv + 3);
if (i)
- err(1, execv(%s), argv[4]);
+ err(1, execv(%s), argv[3]);
exit (0);
+}
+
+static void
+usage(void)
+{
+
+ errx(1,
+ Usage: jail [-u username] path hostname ip-number command ...);
}
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Linux emulation busted
Mensaje citado por M. Warner Losh [EMAIL PROTECTED]: | I had a working Linux world on my laptop. I upgraded my kernel and | acroread4 stopped working. Now all I get is: | | Exited with error code: 0x400e0009. | | after a whole lot of disk access when I try to run it. This worked on | a December kernel for sure. I'm pretty sure it was working as late as | a January 15th kernel. It hasn't worked on a March 1st and subsequent | kernels. I'm not sure where it broke inbetween. Has anybody else | seen this? Warner, Both acroread4 and 5 work for me with Mar 21 and Mar 18 kernels with today's world. Acroread5 works on another machine with a Mar 10 kernel and today's world don't seem to have 4 here. Hope that helps, ed - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Linux emulation busted
Date: Mon, 24 Mar 2003 08:40:55 -0700 (MST) From: M. Warner Losh [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] I had a working Linux world on my laptop. I upgraded my kernel and acroread4 stopped working. Now all I get is: Exited with error code: 0x400e0009. after a whole lot of disk access when I try to run it. This worked on a December kernel for sure. I'm pretty sure it was working as late as a January 15th kernel. It hasn't worked on a March 1st and subsequent kernels. I'm not sure where it broke inbetween. Has anybody else seen this? My kernel was built on March 21 and acroread V4 is running just fine as is Netscape. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
file removal impossible?
Hello, I just discovered some strange behaviour: jmmr# ls -l rcp -r-sr-xr-x 1 root wheel 251444 24 Mär 17:18 rcp jmmr# rm -f rcp rm: rcp: Operation not permitted jmmr# chmod u+w rcp chmod: rcp: Operation not permitted Ok, I had some crashes which gave background fsck some work, but this problem still remains after doing normal fsck from single-user mode which found nothing wrong on this ufs2 partition. So, how can I delete this file? (Actually there are 20 or so all scattered over the live_cd directories) Regards, Julian Stecklina signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: file removal impossible?
On Mon, Mar 24, 2003 at 05:51:38PM +0100, Julian St. wrote: I just discovered some strange behaviour: jmmr# ls -l rcp -r-sr-xr-x 1 root wheel 251444 24 M?r 17:18 rcp jmmr# rm -f rcp rm: rcp: Operation not permitted jmmr# chmod u+w rcp chmod: rcp: Operation not permitted Ok, I had some crashes which gave background fsck some work, but this problem still remains after doing normal fsck from single-user mode which found nothing wrong on this ufs2 partition. So, how can I delete this file? (Actually there are 20 or so all scattered over the live_cd directories) Its not a bug, its a feature (c) ... Just look at chflags(1). -- Rgdz,/\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: file removal impossible?
[EMAIL PROTECTED] wrote: Hello, I just discovered some strange behaviour: jmmr# ls -l rcp -r-sr-xr-x 1 root wheel 251444 24 Mär 17:18 rcp What's ls -lo telling? Perhaps you need chflags (guessing: noschg) jmmr# rm -f rcp rm: rcp: Operation not permitted jmmr# chmod u+w rcp chmod: rcp: Operation not permitted Ok, I had some crashes which gave background fsck some work, but this problem still remains after doing normal fsck from single-user mode which found nothing wrong on this ufs2 partition. So, how can I delete this file? (Actually there are 20 or so all scattered over the live_cd directories) Regards, Julian Stecklina To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: file removal impossible?
Am Mo, 2003-03-24 um 17.56 schrieb Harald Schmalzbauer: [EMAIL PROTECTED] wrote: Hello, I just discovered some strange behaviour: jmmr# ls -l rcp -r-sr-xr-x 1 root wheel 251444 24 Mär 17:18 rcp What's ls -lo telling? Perhaps you need chflags (guessing: noschg) Yes, you are right. Won't forget that for a while. ;) Thanks for all the fast responses. And sorry for blaming bg fsck. Regards, Julian Stecklina signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: MAKEDEV(8) manpage
Date: Mon, 24 Mar 2003 14:34:57 +0100 From: Christian Brueffer [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Mon, Mar 24, 2003 at 09:40:32AM +0200, Jarkko Santala wrote: On Sun, 23 Mar 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Christian Brueffer w= rites: now that MAKEDEV has been gone for a while, the manpages (alpha and i3= 86) can be nuked as well, right? Right. Although it might be considered dragging old baggage around, would it make sense to instead of zapping the man page completely write a new one that would at least give a clue on how things are done these days? Otherwise unclued people might just think there's something wrong with their system because the man page is missing and get even more confused. -jake Well, people are supposed to read UPDATING before updating the system. UPDATING already has an entry about this, so has the handbook, the release notes etc. I think we can't really help people that don't read the recommended documentation. I think POLA should apply to things like this (even across major releases). MAKEDEV has been around for a long time and most folks are used to it being there. It's simply something that most people assume will be there on a Unix-like system. Yes, people should read UPDATING and, better still, the release notes. But taking the added step of having a simple man page with a pointer to the devfs paper and saying that MAKEDEV is no more there will avoid a lot of confusion. The goal of documentation should not be to make it possible for sophisticated users to use the system. It should make it as easy as possible for all levels of users, including those new to Unix and BSD to use the system. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
MBuf use size problem on 4.8-RC
Hi, netstat -m produces following output on my machine, running 4.8-RC: 21732/22336/96000 mbufs in use (current/peak/max): 21732 mbufs allocated to data 20733/21260/24000 mbuf clusters in use (current/peak/max) 48104 Kbytes allocated to network (8% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines I tracked the percentage of mb_map in use. It reached 70% and then wrapped back to 0%. Why does it happen? A bug? There seems to be a problem with booting up 4.8-RC on a 4GB machine. The kernel reaching multiuser mode produces message about unability of allocating new u_map and panics. This is HyperThreading enabled machine (2+2logical CPUs). Any ideas? Thanks. /S To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
IP stack problem -- possibly mac-related
The messages below are from today's kernel + mac_mls and mac_biba kld-loaded from loader(8). None of the warning appear if these modules are not loaded (I haven't tried not loading one and then the other, but I can do it on request) fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.0.2.6 netmask 0x broadcast 10.0.255.255 ether 00:02:b3:ae:0d:ea media: Ethernet autoselect (100baseTX full-duplex) status: active maclabel biba/high(high-high),mls/low(low-low) lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 maclabel biba/equal(equal-equal),mls/equal(equal-equal) malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex radix node head r = 1 (0xc262527c) locked @ /usr/src/sys/net/route.c:549 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex radix node head r = 1 (0xc262527c) locked @ /usr/src/sys/net/route.c:549 add net default: gateway 10.0.7.21 ... Starting ntpdate. malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a608) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a608) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a524) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a524) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a440) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a440) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a35c) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a35c) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a278) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a278) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib ... Starting sendmail. malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a998) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a998) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 Initial i386 initialization:. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
playing mp3s and burning a cd
I'm running 5.0-release, so I'm not sure this is the proper forum, but I'm trying my luck anyways. I used to listen to MP3s (using xmms) while burning CDs (using cdrecord) and it used to work fine on -stable. Now on 5.0-release, the music gets *slw* as soon as the massive IO gets on. I presume it's related to the interrupt problems the current branch is generally having. Anyone else seeing this? Should I upgrade to -current? A. -- Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est pas réfutable relève de la magie ou de la mystique. - Popper, Karl pgp0.pgp Description: PGP signature
Re: IP stack problem -- possibly mac-related
On Mon, 24 Mar 2003, Daniel C. Sobral wrote: The messages below are from today's kernel + mac_mls and mac_biba kld-loaded from loader(8). None of the warning appear if these modules are not loaded (I haven't tried not loading one and then the other, but I can do it on request) ... malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 Hmm. I think there's a witness flag to generate stack traces when giving out these sorts of warnings -- debug.witness_trace I think. Can you try turning that on in loader.conf and see if we get some additional information? The only MAC call in udp_output() is mac_create_mbuf_from_socket(), which isn't supposed to result in memory allocation. That should only happen when the mbuf itself is allocated. A stack trace might narrow down the source of the problem. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV(8) manpage
On Mon, Mar 24, 2003 at 09:12:15AM -0800, Kevin Oberman wrote: Date: Mon, 24 Mar 2003 14:34:57 +0100 From: Christian Brueffer [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Mon, Mar 24, 2003 at 09:40:32AM +0200, Jarkko Santala wrote: On Sun, 23 Mar 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Christian Brueffer w= rites: now that MAKEDEV has been gone for a while, the manpages (alpha and i3= 86) can be nuked as well, right? Right. Although it might be considered dragging old baggage around, would it make sense to instead of zapping the man page completely write a new one that would at least give a clue on how things are done these days? Otherwise unclued people might just think there's something wrong with their system because the man page is missing and get even more confused. -jake Well, people are supposed to read UPDATING before updating the system. UPDATING already has an entry about this, so has the handbook, the release notes etc. I think we can't really help people that don't read the recommended documentation. I think POLA should apply to things like this (even across major releases). MAKEDEV has been around for a long time and most folks are used to it being there. It's simply something that most people assume will be there on a Unix-like system. Yes, people should read UPDATING and, better still, the release notes. But taking the added step of having a simple man page with a pointer to the devfs paper and saying that MAKEDEV is no more there will avoid a lot of confusion. The goal of documentation should not be to make it possible for sophisticated users to use the system. It should make it as easy as possible for all levels of users, including those new to Unix and BSD to use the system. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message I'll write a small manpage this evening which says that MAKEDEV is gone now with a short summary of what devfs does. Does that resolve your worries? - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: MAKEDEV(8) manpage
On Mon, 24 Mar 2003, Christian Brueffer wrote: On Mon, Mar 24, 2003 at 09:12:15AM -0800, Kevin Oberman wrote: Date: Mon, 24 Mar 2003 14:34:57 +0100 From: Christian Brueffer [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Mon, Mar 24, 2003 at 09:40:32AM +0200, Jarkko Santala wrote: On Sun, 23 Mar 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Christian Brueffer w= rites: now that MAKEDEV has been gone for a while, the manpages (alpha and i3= 86) can be nuked as well, right? Right. Although it might be considered dragging old baggage around, would it make sense to instead of zapping the man page completely write a new one that would at least give a clue on how things are done these days? Otherwise unclued people might just think there's something wrong with their system because the man page is missing and get even more confused. Well, people are supposed to read UPDATING before updating the system. UPDATING already has an entry about this, so has the handbook, the release notes etc. I think we can't really help people that don't read the recommended documentation. I think POLA should apply to things like this (even across major releases). MAKEDEV has been around for a long time and most folks are used to it being there. It's simply something that most people assume will be there on a Unix-like system. Yes, people should read UPDATING and, better still, the release notes. But taking the added step of having a simple man page with a pointer to the devfs paper and saying that MAKEDEV is no more there will avoid a lot of confusion. The goal of documentation should not be to make it possible for sophisticated users to use the system. It should make it as easy as possible for all levels of users, including those new to Unix and BSD to use the system. I'll write a small manpage this evening which says that MAKEDEV is gone now with a short summary of what devfs does. Does that resolve your worries? Exactly what I had in mind, so sounds good to me. ;) You probably want to make it as generic as possible, so that keeping it up-to-date doesn't become a burden in the future. I'd hate to create any extra maintenance work to anyone, no matter how small. Thanks, -jake -- Jarkko Santala [EMAIL PROTECTED]http://www.iki.fi/~jake/ System Administrator2001:670:83:f08::/64 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: playing mp3s and burning a cd
I see this too: when I listen to tunes and untar a file, the music plays at about .7x the speed, and sounds kind of robotic, even with xmms niced to -20, and tar/gzip at +20. I am running 5.0-CURRENT-20030320-JPSNAP, so I doubt an 'upgrade' is really going to do anything for you at this time. -Craig From: The Anarcat [EMAIL PROTECTED] Subject: playing mp3s and burning a cd I'm running 5.0-release, so I'm not sure this is the proper forum, but I'm trying my luck anyways. I used to listen to MP3s (using xmms) while burning CDs (using cdrecord) and it used to work fine on -stable. Now on 5.0-release, the music gets *slw* as soon as the massive IO gets on. I presume it's related to the interrupt problems the current branch is generally having. Anyone else seeing this? Should I upgrade to -current? A. -- Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est pas réfutable relève de la magie ou de la mystique. - Popper, Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Followup to: Trouble building XFree86-4-Clients.
Well it was Xft. I feel stupid, sorry for wasting peoples time. Anyways I think I recall what happened, during the portupgrade I was playing around with X and caused a system crash. This may have happened during the Xft removal/upgrade stage of portupgrade. I had the same problem when upgrading my XF86 to 4.3.0 over the weekend. XFt is a prerequisite for a bunch of stuff, so it was installed on my machine along with XFree86-4.2.0. However, XFree86-4.2.0 had already installed its own version of libXft and the include files, so the Xft port installed on top of the XFree86-4.2.0 versions of those files. When I tried to upgrade to XFree86-4.3.0, *something* blew away the Xft files, because 'portversion' thought that the Xft package was still installed, even though the actual library and include files were missing. I'm guessing that when the XFree86-4.2.0 port is removed, it also removes the new Xft files. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: playing mp3s and burning a cd
Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) A. On Mon Mar 24, 2003 at 01:45:26PM -0500, Craig Reyenga wrote: I see this too: when I listen to tunes and untar a file, the music plays at about .7x the speed, and sounds kind of robotic, even with xmms niced to -20, and tar/gzip at +20. I am running 5.0-CURRENT-20030320-JPSNAP, so I doubt an 'upgrade' is really going to do anything for you at this time. -Craig From: The Anarcat [EMAIL PROTECTED] Subject: playing mp3s and burning a cd I'm running 5.0-release, so I'm not sure this is the proper forum, but I'm trying my luck anyways. I used to listen to MP3s (using xmms) while burning CDs (using cdrecord) and it used to work fine on -stable. Now on 5.0-release, the music gets *slw* as soon as the massive IO gets on. I presume it's related to the interrupt problems the current branch is generally having. Anyone else seeing this? Should I upgrade to -current? A. -- Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est pas réfutable relève de la magie ou de la mystique. - Popper, Karl -- Si les triangles avaient un Dieu, ils lui donneraient trois côtés. - Montesquieu, Lettres persanes pgp0.pgp Description: PGP signature
Re: playing mp3s and burning a cd
Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) This isn't, by chance, a problem with your setting for the sysctl hw.ata.atapi_dma is it? -Don To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: playing mp3s and burning a cd
On Mon Mar 24, 2003 at 02:14:48PM -0500, Don wrote: Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) This isn't, by chance, a problem with your setting for the sysctl hw.ata.atapi_dma is it? No idea. [EMAIL PROTECTED] sysctl hw.ata.atapi_dma hw.ata.atapi_dma: 0 [EMAIL PROTECTED] should I enable it? I guess I'm out to burn another CD and just test that.. A. -- The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. - Douglas Adams (1952-2001) pgp0.pgp Description: PGP signature
Re: READ_BIG command timeout on CDROM drive
[EMAIL PROTECTED] wrote: Hi all! When I read cdroms with fbsd 5.0, the following message appears in the console very often (it seems to happen with every cdrom I try): acd0: READ_BIG command timeout - resetting ata0: resetting devices .. done It is repeated indefinitely and I can't kill -9 the process that is trying to read the cdrom. umount -f /cdrom also gets stuck and doesn't write any error messages. The driver in use is cd9660: RockRidge Extension. I have to reboot to have access to the cdrom drive again. And besides, the shutdown process does not end every time when the system is in this state. Is there a means to have access to the cdrom drive again without rebooting? I have not seen any bug report for this problem; am I right? This is just a me too but the exact same thing happens to me and I still have not found a way to fix it. I searched the google archives and the FreeBSD mailing list archives to no avail. I posted the problem here and received no solutions. I cannot read audio off the disc and if I mount a data CD, it mounts okay, but will not umount without hanging and I also have to reboot the system to get access to the drive at all. -Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 01:08:37PM -0500, Robert Watson wrote: On Mon, 24 Mar 2003, Daniel C. Sobral wrote: The messages below are from today's kernel + mac_mls and mac_biba kld-loaded from loader(8). None of the warning appear if these modules are not loaded (I haven't tried not loading one and then the other, but I can do it on request) ... malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 Hmm. I think there's a witness flag to generate stack traces when giving out these sorts of warnings -- debug.witness_trace I think. Can you try turning that on in loader.conf and see if we get some additional information? The only MAC call in udp_output() is mac_create_mbuf_from_socket(), which isn't supposed to result in memory allocation. That should only happen when the mbuf itself is allocated. A stack trace might narrow down the source of the problem. I get this too with mac_biba in kernel or loaded as a module. Message at bootup: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex radix node head r = 1 (0xc268377c) locked @ /usr/src/sys/n et/route.c:549 Messages on other network operations: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc27a435c) locked @ /usr/src/sys/netinet/udp_u srreq.c:1034 - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: playing mp3s and burning a cd
On Mon, Mar 24, 2003 at 12:35:10PM -0500, The Anarcat [EMAIL PROTECTED] wrote: I'm running 5.0-release, so I'm not sure this is the proper forum, but I'm trying my luck anyways. I used to listen to MP3s (using xmms) while burning CDs (using cdrecord) and it used to work fine on -stable. Now on 5.0-release, the music gets *slw* as soon as the massive IO gets on. I presume it's related to the interrupt problems the current branch is generally having. Anyone else seeing this? Should I upgrade to -current? Current isn't better. This is a long time problem and is most noticeable when you downgrade from -current to -stable... it's unforgettable feeling :-P I don't expect it will be fixed in the near future, because it's been so over a year now. Current has it's weak points and this is only one of the regressions. -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: playing mp3s and burning a cd
The Anarcat wrote: I'm running 5.0-release, so I'm not sure this is the proper forum, but I'm trying my luck anyways. I used to listen to MP3s (using xmms) while burning CDs (using cdrecord) and it used to work fine on -stable. Now on 5.0-release, the music gets *slw* as soon as the massive IO gets on. I presume it's related to the interrupt problems the current branch is generally having. Anyone else seeing this? Should I upgrade to -current? Yes, I'm seeing this as well. More specifically, whenever there is heavy disk I/O, mp3 playback gets that slow, robotic quality you describe. It's really irritating. It doesn't seem to be as bad in current as it was in 5.0-RELEASE, but it's still a bit of a nuissance. I'm running current from March 7. -Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 08:28:38PM +0100, Christian Brueffer wrote: On Mon, Mar 24, 2003 at 01:08:37PM -0500, Robert Watson wrote: On Mon, 24 Mar 2003, Daniel C. Sobral wrote: The messages below are from today's kernel + mac_mls and mac_biba kld-loaded from loader(8). None of the warning appear if these modules are not loaded (I haven't tried not loading one and then the other, but I can do it on request) ... malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1034 exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ /usr/src/sys/netinet/udp_usrreq.c:1027 Hmm. I think there's a witness flag to generate stack traces when giving out these sorts of warnings -- debug.witness_trace I think. Can you try turning that on in loader.conf and see if we get some additional information? The only MAC call in udp_output() is mac_create_mbuf_from_socket(), which isn't supposed to result in memory allocation. That should only happen when the mbuf itself is allocated. A stack trace might narrow down the source of the problem. I get this too with mac_biba in kernel or loaded as a module. Message at bootup: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex radix node head r = 1 (0xc268377c) locked @ /usr/src/sys/n et/route.c:549 Messages on other network operations: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc27a435c) locked @ /usr/src/sys/netinet/udp_u srreq.c:1034 FYI, debug.witness_trace is set (seems to default to 1). Any other ways to get more info out of this? - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Solved??? Re: playing mp3s and burning a cd
On Mon Mar 24, 2003 at 02:14:48PM -0500, Don wrote: Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) This isn't, by chance, a problem with your setting for the sysctl hw.ata.atapi_dma is it? How extraordinarly cute! This solves it! I'm currently listening to Me, Mom and Morgentaler and burning a 4x CD without any slowdown, this is great. So I guess a workaround is to toggle DMA for my ATAPI bus. Indeed, the burner is IDE and should be working on DMA mode to get optimal performance. The thing is that atapicam hides the DMA/PIO magic from the usual boot messagesand there's therefore no way to see wether the device is in DMA mode unless you compile in both cd0 and acd0 which I heard isn't recommended... A. PS: what's the proper way to enable ATAPI DMA in the loader.conf file? I don't see any flag WRT that there.. I'm tempted to add: set hw.ata.atapi_cam=1 anywhere there... Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-RELEASE #2: Fri Mar 7 15:05:32 EST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LENNII Preloaded elf kernel /boot/kernel/kernel at 0xc06ea000. Preloaded elf module /boot/kernel/snd_emu10k1.ko at 0xc06ea0a8. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc06ea158. Preloaded elf module /boot/kernel/radeon.ko at 0xc06ea204. Preloaded elf module /boot/kernel/acpi.ko at 0xc06ea2b0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1008992834 Hz CPU: AMD Duron(tm) Processor (1008.99-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x670 Stepping = 0 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 1207877632 (1151 MB) avail memory = 1166782464 (1112 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7V-133 on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 9 entries at 0xc00f1750 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xe600-0xe7ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 drm0: ATI Radeon QY VE (AGP) port 0xd800-0xd8ff mem 0xd700-0xd700,0xd800-0xdfff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe600 32MB info: [drm] Initialized radeon 1.1.1 20010405 on minor 0 isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA100 controller port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xb400-0xb41f irq 9 at device 4.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: Color FlatbedScanner 22, rev 1.00/1.00, addr 2 uhci1: VIA 83C572 USB controller port 0xb000-0xb01f irq 9 at device 4.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 4.4 (no driver attached) vr0: VIA VT6102 Rhine II 10/100BaseTX port 0x9400-0x94ff mem 0xd680-0xd68000ff irq 9 at device 9.0 on pci0 vr0: Ethernet address: 00:50:ba:64:e3:6a miibus0: MII bus on vr0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative EMU10K1 port 0x9000-0x901f irq 5 at device 10.0 on pci0 atapci1: Promise ATA100 controller port 0x7000-0x703f,0x7400-0x7403,0x7800-0x7807,0x8000-0x8003,0x8400-0x8407 mem 0xd600-0xd601 irq 10 at device 17.0 on pci0 ata2: at 0x8400 on atapci1 ata3: at 0x7800 on atapci1 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT
Re: IP stack problem -- possibly mac-related
On Mon, 24 Mar 2003, Christian Brueffer wrote: FYI, debug.witness_trace is set (seems to default to 1). Any other ways to get more info out of this? Are you only looking at syslog, or also at the actual console? It could be that the Witness traces only appear on the console itself, not in the log (undesirable, but possible). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: playing mp3s and burning a cd
Actually, on my box, all I/O devices are in DMA mode, and I'm seeing this no matter what device is doing the heavy I/O. I think this should be fixed by 5.1 because it is very annoying. A Pentium 133 in Windows 95 doesnt even do it this bad. -Craig From: Don [EMAIL PROTECTED] Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) This isn't, by chance, a problem with your setting for the sysctl hw.ata.atapi_dma is it? -Don 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: Solved??? Re: playing mp3s and burning a cd
Date: Mon, 24 Mar 2003 14:43:30 -0500 From: The Anarcat [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon Mar 24, 2003 at 02:14:48PM -0500, Don wrote: Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) This isn't, by chance, a problem with your setting for the sysctl hw.ata.atapi_dma is it? How extraordinarly cute! This solves it! I'm currently listening to Me, Mom and Morgentaler and burning a 4x CD without any slowdown, this is great. So I guess a workaround is to toggle DMA for my ATAPI bus. Indeed, the burner is IDE and should be working on DMA mode to get optimal performance. The thing is that atapicam hides the DMA/PIO magic from the usual boot messagesand there's therefore no way to see wether the device is in DMA mode unless you compile in both cd0 and acd0 which I heard isn't recommended... A. PS: what's the proper way to enable ATAPI DMA in the loader.conf file? I don't see any flag WRT that there.. I'm tempted to add: set hw.ata.atapi_cam=3D1 anywhere there... Close. Add: hw.ata.atapi_dma=1# Run the CD-ROM/DVD in DMA mode to /boot/loader.conf. This should be in almost EVERY /boot/loader.conf. The default is 0 (PIO) because DMA is broken on at least a few early CD readers, but it is very rare to have it fail. (I've never seen it.) R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP stack problem -- possibly mac-related
On Mon, 24 Mar 2003, Christian Brueffer wrote: On Mon, Mar 24, 2003 at 02:45:57PM -0500, Robert Watson wrote: On Mon, 24 Mar 2003, Christian Brueffer wrote: FYI, debug.witness_trace is set (seems to default to 1). Any other ways to get more info out of this? Are you only looking at syslog, or also at the actual console? It could be that the Witness traces only appear on the console itself, not in the log (undesirable, but possible). It's on the console. Any chance you could copy/paste it using a serial console or the like? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Solved??? Re: playing mp3s and burning a cd
If you have a 1.0GHz Durn processor, theoretically you should be able to burn that CD at 32X (burner permitting), have 10+ Mozilla windows open, all without a skip in the playback, or boggage. I have an AMD K6-2 450, and I currently can't do 1/4 the stuff simultaneously without music skipping as I could in other, anonymous operaing systems. Also, a simple ogg123 off of the commandline skips a little as well, when untaring something. -Craig From: The Anarcat [EMAIL PROTECTED] On Mon Mar 24, 2003 at 02:14:48PM -0500, Don wrote: Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) This isn't, by chance, a problem with your setting for the sysctl hw.ata.atapi_dma is it? How extraordinarly cute! This solves it! I'm currently listening to Me, Mom and Morgentaler and burning a 4x CD without any slowdown, this is great. So I guess a workaround is to toggle DMA for my ATAPI bus. Indeed, the burner is IDE and should be working on DMA mode to get optimal performance. The thing is that atapicam hides the DMA/PIO magic from the usual boot messagesand there's therefore no way to see wether the device is in DMA mode unless you compile in both cd0 and acd0 which I heard isn't recommended... A. PS: what's the proper way to enable ATAPI DMA in the loader.conf file? I don't see any flag WRT that there.. I'm tempted to add: set hw.ata.atapi_cam=1 anywhere there... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 02:53:08PM -0500, Robert Watson wrote: It's on the console. Any chance you could copy/paste it using a serial console or the like? Well, not much to see here: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc0466d40) locked @ /usr/src/sys/net/n etisr.c:215 which is repeated over and over again, when I copy a large file over NFS. There's no actual trace appearing. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Broken DMA devices
On Mon Mar 24, 2003 at 11:52:07AM -0800, Kevin Oberman wrote: PS: what's the proper way to enable ATAPI DMA in the loader.conf file? I don't see any flag WRT that there.. I'm tempted to add: set hw.ata.atapi_cam=3D1 anywhere there... Close. Add: hw.ata.atapi_dma=1# Run the CD-ROM/DVD in DMA mode to /boot/loader.conf. This should be in almost EVERY /boot/loader.conf. The default is 0 (PIO) because DMA is broken on at least a few early CD readers, but it is very rare to have it fail. (I've never seen it.) Can't the ata drivers detect that condition or recognize the set of drives that are broken instead of penalizing everyone else? A. -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker http://www.ad-mad.co.uk/quotes/freespeech.htm pgp0.pgp Description: PGP signature
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 08:59:29PM +0100, Christian Brueffer wrote: On Mon, Mar 24, 2003 at 02:53:08PM -0500, Robert Watson wrote: It's on the console. Any chance you could copy/paste it using a serial console or the like? Well, not much to see here: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc0466d40) locked @ /usr/src/sys/net/n etisr.c:215 which is repeated over and over again, when I copy a large file over NFS. There's no actual trace appearing. Sorry, these ones are appearing too: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc27a4608) locked @ /usr/src/sys/netinet/udp_u srreq.c:1034 exclusive sleep mutex udp r = 0 (0xc041a18c) locked @ /usr/src/sys/netinet/udp_u srreq.c:1027 - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: READ_BIG command timeout on CDROM drive
[EMAIL PROTECTED] wrote: Hi all! When I read cdroms with fbsd 5.0, the following message appears in the console very often (it seems to happen with every cdrom I try): acd0: READ_BIG command timeout - resetting ata0: resetting devices .. done It is repeated indefinitely and I can't kill -9 the process that is trying to read the cdrom. umount -f /cdrom also gets stuck and doesn't write any error messages. The driver in use is cd9660: RockRidge Extension. I have to reboot to have access to the cdrom drive again. And besides, the shutdown process does not end every time when the system is in this state. Is there a means to have access to the cdrom drive again without rebooting? I have not seen any bug report for this problem; am I right? Just wanted to report that I fixed this problem by adding: hw.ata.atapi_dma=1# Run the CD-ROM/DVD in DMA mode to /boot/loader.conf. The system was trying to access the drive using PIO4 rather than DMA and crapping out. I got the idea from another thread today with the subject playing mp3's and burning a cd. Just an FYI. -Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Solved??? Re: playing mp3s and burning a cd
On Mon Mar 24, 2003 at 02:14:48PM -0500, Don wrote: Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) This isn't, by chance, a problem with your setting for the sysctl hw.ata.atapi_dma is it? How extraordinarly cute! This solves it! I'm currently listening to Me, Mom and Morgentaler and burning a 4x CD without any slowdown, this is great. Glad to be of help. Anytime you have odd system problems like that give sysctl -a a perusal. Sometimes you will be surprised at what you find. There was definitely a reason for turning off DMA access for atapi devices by default, I just can not remember why. I'm sure this issue and the reason were mentioned on the list already. PS: what's the proper way to enable ATAPI DMA in the loader.conf file? I don't see any flag WRT that there.. I'm tempted to add: set hw.ata.atapi_cam=1 hw.ata.atapi_dma not _cam :) -Don To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Solved??? Re: playing mp3s and burning a cd
On Mon Mar 24, 2003 at 03:33:51PM -0500, Don wrote: On Mon Mar 24, 2003 at 02:14:48PM -0500, Don wrote: Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) This isn't, by chance, a problem with your setting for the sysctl hw.ata.atapi_dma is it? How extraordinarly cute! This solves it! I'm currently listening to Me, Mom and Morgentaler and burning a 4x CD without any slowdown, this is great. Glad to be of help. Anytime you have odd system problems like that give sysctl -a a perusal. Sometimes you will be surprised at what you find. There was definitely a reason for turning off DMA access for atapi devices by default, I just can not remember why. I'm sure this issue and the reason were mentioned on the list already. Right... Another dig through the archives I guess. :( PS: what's the proper way to enable ATAPI DMA in the loader.conf file? I don't see any flag WRT that there.. I'm tempted to add: set hw.ata.atapi_cam=1 hw.ata.atapi_dma not _cam :) Now *that* was an odd typo. A. -- Conformity-the natural instinct to passively yield to that vague something recognized as authority. - Mark Twain pgp0.pgp Description: PGP signature
Re: Solved??? Re: playing mp3s and burning a cd
On Mon, Mar 24, 2003 at 14:43:30 -0500, The Anarcat wrote: On Mon Mar 24, 2003 at 02:14:48PM -0500, Don wrote: Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) This isn't, by chance, a problem with your setting for the sysctl hw.ata.atapi_dma is it? How extraordinarly cute! This solves it! I'm currently listening to Me, Mom and Morgentaler and burning a 4x CD without any slowdown, this is great. So I guess a workaround is to toggle DMA for my ATAPI bus. Indeed, the burner is IDE and should be working on DMA mode to get optimal performance. The thing is that atapicam hides the DMA/PIO magic from the usual boot messagesand there's therefore no way to see wether the device is in DMA mode unless you compile in both cd0 and acd0 which I heard isn't recommended... You can do that without problems, just don't use them at the same time, since they're both using the same underlying hardware. You can tell what speed the drive is running by either looking at the transfer rate the cd(4) drive reports, or looking at the dmesg information for the acd driver. e.g.: acd0: DVD-R SONY DVD RW DRU-500A at ata0-master UDMA33 The UDMA33 tag at the end means that it's running at 33MB/sec, which is what the cd(4) driver confirms: cd1 at ata0 bus 0 target 0 lun 0 cd1: SONY DVD RW DRU-500A 1.0c Removable CD-ROM SCSI-0 device cd1: 33.000MB/s transfers cd1: cd present [306511 x 2048 byte records] PS: what's the proper way to enable ATAPI DMA in the loader.conf file? I don't see any flag WRT that there.. I'm tempted to add: set hw.ata.atapi_cam=1 Someone else pointed out that it is atapi_dma. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Solved??? Re: playing mp3s and burning a cd
Kevin Oberman ([EMAIL PROTECTED]) wrote: Close. Add: hw.ata.atapi_dma=1# Run the CD-ROM/DVD in DMA mode to /boot/loader.conf. This should be in almost EVERY /boot/loader.conf. The default is 0 (PIO) because DMA is broken on at least a few early CD readers, but it is very rare to have it fail. (I've never seen it.) my ad2: 2014MB QUANTUM BIGFOOT_CY2160A [4092/16/63] at ata1-master PIO4 Is one of those wierd drives that claims to support DMA, but doesn't. I still get occasional bus resets when doing lots of IO to the drive, if I don't keep it in PIO mode. -- Eric Hodel - [EMAIL PROTECTED] - http://segment7.net All messages signed with fingerprint: FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 pgp0.pgp Description: PGP signature
Re: IP stack problem -- possibly mac-related
On Mon, 24 Mar 2003, Christian Brueffer wrote: Well, not much to see here: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc0466d40) locked @ /usr/src/sys/net/n etisr.c:215 which is repeated over and over again, when I copy a large file over NFS. There's no actual trace appearing. Sorry, these ones are appearing too: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc27a4608) locked @ /usr/src/sys/netinet/udp_u srreq.c:1034 exclusive sleep mutex udp r = 0 (0xc041a18c) locked @ /usr/src/sys/netinet/udp_u srreq.c:1027 Looks like witness warnings don't automatically auto-trace. Could you set witness.ddb and generate a backtrace for each of the warnings and e-mail them to me? Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV(8) manpage
On Mon, Mar 24, 2003 at 08:29:59PM +0200, Jarkko Santala wrote: On Mon, 24 Mar 2003, Christian Brueffer wrote: On Mon, Mar 24, 2003 at 09:12:15AM -0800, Kevin Oberman wrote: Date: Mon, 24 Mar 2003 14:34:57 +0100 From: Christian Brueffer [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Mon, Mar 24, 2003 at 09:40:32AM +0200, Jarkko Santala wrote: On Sun, 23 Mar 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Christian Brueffer w= rites: now that MAKEDEV has been gone for a while, the manpages (alpha and i3= 86) can be nuked as well, right? Right. Although it might be considered dragging old baggage around, would it make sense to instead of zapping the man page completely write a new one that would at least give a clue on how things are done these days? Otherwise unclued people might just think there's something wrong with their system because the man page is missing and get even more confused. Well, people are supposed to read UPDATING before updating the system. UPDATING already has an entry about this, so has the handbook, the release notes etc. I think we can't really help people that don't read the recommended documentation. I think POLA should apply to things like this (even across major releases). MAKEDEV has been around for a long time and most folks are used to it being there. It's simply something that most people assume will be there on a Unix-like system. Yes, people should read UPDATING and, better still, the release notes. But taking the added step of having a simple man page with a pointer to the devfs paper and saying that MAKEDEV is no more there will avoid a lot of confusion. The goal of documentation should not be to make it possible for sophisticated users to use the system. It should make it as easy as possible for all levels of users, including those new to Unix and BSD to use the system. I'll write a small manpage this evening which says that MAKEDEV is gone now with a short summary of what devfs does. Does that resolve your worries? Exactly what I had in mind, so sounds good to me. ;) You probably want to make it as generic as possible, so that keeping it up-to-date doesn't become a burden in the future. I'd hate to create any extra maintenance work to anyone, no matter how small. I'd rather just MLINK mount_devfs(8) to MAKEDEV(8) for the time being, say until 5.2 is out, like is the case for vnconfig(8). Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
ACPI using too much CPU on idle system
top -S shows the following on my machine: CPU states: 0.8% user, 0.0% nice, 80.3% system, 12.9% interrupt, 6.1% idle PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 11 root -160 0K12K RUN563:23 32.23% 32.23% idle 7 root -840 0K12K actask 1:33 18.51% 18.51% acpi_task2 5 root -840 0K12K actask 1:33 18.21% 18.21% acpi_task0 6 root -840 0K12K actask 1:33 17.82% 17.82% acpi_task1 21 root -68 -187 0K12K WAIT 0:55 4.98% 4.98% irq9: fxp0 atapci0* 17 root -24 -143 0K12K WAIT 0:06 0.83% 0.83% swi6: acpitaskq The machine is supposedly idle..no process, disk or network activity, so I can't see any reason for all this kernel CPU activity. What is going on? Is this some kind of software-emulated CPU step-down because ACPI has decided my CPU is too fast? :) Kris pgp0.pgp Description: PGP signature
Re: READ_BIG command timeout on CDROM drive
On Mon, Mar 24, 2003 at 12:20:02PM -0800, Scott R. [EMAIL PROTECTED] wrote: Just wanted to report that I fixed this problem by adding: hw.ata.atapi_dma=1# Run the CD-ROM/DVD in DMA mode to /boot/loader.conf. The system was trying to access the drive using PIO4 rather than DMA and crapping out. I got the idea from another thread today with the subject playing mp3's and burning a cd. Just an FYI. Oh, nice it was only configuration problem. I wish I had such problems, they're so easy to fix, hehe. The problem with I/O (specifically network I/O) I have for a long time is that mouse will be unresponsive (jumping) and sound skips under X while large ftp transfer is happening over the 100Mbit interface. Fxp driver and SMP system if that matters. No cure in the sight. -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV(8) manpage
On Mon, Mar 24, 2003 at 11:03:52PM +0200, Ruslan Ermilov wrote: On Mon, Mar 24, 2003 at 08:29:59PM +0200, Jarkko Santala wrote: On Mon, 24 Mar 2003, Christian Brueffer wrote: On Mon, Mar 24, 2003 at 09:12:15AM -0800, Kevin Oberman wrote: Date: Mon, 24 Mar 2003 14:34:57 +0100 From: Christian Brueffer [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Mon, Mar 24, 2003 at 09:40:32AM +0200, Jarkko Santala wrote: On Sun, 23 Mar 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Christian Brueffer w= rites: now that MAKEDEV has been gone for a while, the manpages (alpha and i3= 86) can be nuked as well, right? Right. Although it might be considered dragging old baggage around, would it make sense to instead of zapping the man page completely write a new one that would at least give a clue on how things are done these days? Otherwise unclued people might just think there's something wrong with their system because the man page is missing and get even more confused. Well, people are supposed to read UPDATING before updating the system. UPDATING already has an entry about this, so has the handbook, the release notes etc. I think we can't really help people that don't read the recommended documentation. I think POLA should apply to things like this (even across major releases). MAKEDEV has been around for a long time and most folks are used to it being there. It's simply something that most people assume will be there on a Unix-like system. Yes, people should read UPDATING and, better still, the release notes. But taking the added step of having a simple man page with a pointer to the devfs paper and saying that MAKEDEV is no more there will avoid a lot of confusion. The goal of documentation should not be to make it possible for sophisticated users to use the system. It should make it as easy as possible for all levels of users, including those new to Unix and BSD to use the system. I'll write a small manpage this evening which says that MAKEDEV is gone now with a short summary of what devfs does. Does that resolve your worries? Exactly what I had in mind, so sounds good to me. ;) You probably want to make it as generic as possible, so that keeping it up-to-date doesn't become a burden in the future. I'd hate to create any extra maintenance work to anyone, no matter how small. I'd rather just MLINK mount_devfs(8) to MAKEDEV(8) for the time being, say until 5.2 is out, like is the case for vnconfig(8). Also good. devfs(5) would be a better choice then, mount_devfs(8) is just an MLINK to mount_std. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: Linux emulation busted
On Mon, Mar 24, 2003 at 08:40:55AM -0700, M. Warner Losh wrote: I had a working Linux world on my laptop. I upgraded my kernel and acroread4 stopped working. Now all I get is: Is acroread4 multithreaded ? Because since about 2 months all multithreaded linux binaries have stopped working for me; I don't know if this because the new glibc 2.2.93 ( I upgraded at the same time to RH 8.0 ) or something in the linux emulation ( I couldn't spot any relevant change there). I didn't have yet the time to investigate, but: - I could reproduce it with small multithreaded test programs. - It seems that the 'thread model' (i.e. what parameters are passed to clone()) hasn't changed in glibc 2.3 Regards Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 03:43:19PM -0500, Robert Watson wrote: On Mon, 24 Mar 2003, Christian Brueffer wrote: Well, not much to see here: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc0466d40) locked @ /usr/src/sys/net/n etisr.c:215 which is repeated over and over again, when I copy a large file over NFS. There's no actual trace appearing. Sorry, these ones are appearing too: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc27a4608) locked @ /usr/src/sys/netinet/udp_u srreq.c:1034 exclusive sleep mutex udp r = 0 (0xc041a18c) locked @ /usr/src/sys/netinet/udp_u srreq.c:1027 Looks like witness warnings don't automatically auto-trace. Could you set witness.ddb and generate a backtrace for each of the warnings and e-mail them to me? Thanks! malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc0466d40) locked @ /usr/src/sys/net/netisr.c:215 Debugger(witness_warn) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db tr Debugger(c03a295c,cd21cb6c,1,c0441b80,c05232e0) at Debugger+0x54 witness_warn(5,0,c03d54ac,c03c2a26,3) at witness_warn+0x1a0 uma_zalloc_arg(c083ad80,0,102,c040df80,4) at uma_zalloc_arg+0x53 malloc(70,c05232e0,102,cd21cbd4,c051ff4b) at malloc+0xd4 biba_alloc(2,c05235c0,cd21cbf4,c02363df,c0ee993c) at biba_alloc+0x26 mac_biba_init_label(c0ee993c,0,c03c2846,2c1,0) at mac_biba_init_label+0x1b mac_init_ipq(c0ee9918,b,0,c1367020,0) at mac_init_ipq+0x8f ip_reass(c0ee9000,c04672c8,c0ee9918,cd21cc44,cd21cca0) at ip_reass+0x5e ip_input(c0ee9000,0,c03ccd2d,e9,c0ebcb00) at ip_input+0x7ff swi_net(0,0,c03c1abe,217,c0ec7a00) at swi_net+0x112 ithread_loop(c0ec6100,cd21cd48,c03c1921,363,aa90) at ithread_loop+0x182 fork_exit(c022e680,c0ec6100,cd21cd48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd21cd7c, ebp = 0 --- - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
several background fsck panics
Hi! I had several panics related to background fsck now. Once I disabled background fsck, all went ok. It began when I pressed the reset buttons on several boots while the system was still doing fscks. Then sometime this happened: Mar 24 21:31:12 fump root: /dev/ad0s2g: 701589 files, 12766670 used, 32836022 free (76598 frags, 4094928 blocks, 0.2% fragmentation) Mar 24 21:32:27 fump kernel: handle_workitem_freeblocks: block count Mar 24 21:37:36 fump root: fsck_ufs: cannot find inode 1443360 and a bit later: Mar 24 21:48:59 fump syslogd: kernel boot file is /boot/kernel/kernel Mar 24 21:48:59 fump kernel: /usr: bad dir ino 500641 at offset 0: mangled entry Mar 24 21:48:59 fump kernel: panic: ufs_dirbad: bad dir Mar 24 21:48:59 fump kernel: Mar 24 21:48:59 fump kernel: syncing disks, buffers remaining... 3810 3810 3810 3809 3809 3809 3806 3807 3807 3807 3807 3807 3803 3803 3803 3780 378 2 3782 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 Mar 24 21:48:59 fump kernel: giving up on 2299 buffers Mar 24 21:48:59 fump kernel: Uptime: 36m18s Mar 24 21:48:59 fump kernel: Dumping 511 MB Mar 24 21:48:59 fump kernel: ata0: resetting devices .. Mar 24 21:48:59 fump kernel: done Mar 24 21:48:59 fump kernel: 16 32 48 64 80[CTRL-C to abort] 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352[CTRL-C to abort] [C TRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL- C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] As I was in X, I thought my system just hung w/o dumping the core (my hdd led is broken obviously), I then pressed reset. Next turn: Mar 24 21:48:59 fump kernel: WARNING: /data was not properly dismounted Mar 24 21:48:59 fump kernel: /data: mount pending error: blocks 32 files 0 Mar 24 21:48:59 fump kernel: /data: superblock summary recomputed system entered multi-user, I logged in, but did not start anything but my login shell. Mar 24 21:53:37 fump syslogd: kernel boot file is /boot/kernel/kernel Mar 24 21:53:37 fump kernel: dev = ad0s2g, block = 1, fs = /data Mar 24 21:53:37 fump kernel: panic: ffs_blkfree: freeing free block Mar 24 21:53:37 fump kernel: (entered debugger, I did a c) Mar 24 21:53:37 fump kernel: syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue Mar 24 21:53:37 fump kernel: Uptime: 2m10s Mar 24 21:53:37 fump kernel: Dumping 511 MB Mar 24 21:53:37 fump kernel: ata0: resetting devices .. Mar 24 21:53:37 fump kernel: done Mar 24 21:53:37 fump kernel: 16 32 48 64 80 96 112 128 144 160 176 192 I pressed reset again as it would have dumped the wrong panic and I wanted to dump the panic that caused the initial panic. Next boot: Mar 24 22:22:58 fump kernel: RENT WAS I=2404025 Mar 24 22:22:58 fump savecore: reboot after panic: bremfree: removing a buffer not on a queue Mar 24 22:22:58 fump savecore: writing core to vmcore.1 ok, here's the stuff: Script started on Mon Mar 24 22:50:14 2003 [EMAIL PROTECTED] /data/crash # gdb -k GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd. (kgdb) exec-file /boot/kernel/kernel (kgdb) symbol-file /usr/obj/usr/src/sys/ZEROGRAVITY/kernel.debug Reading symbols from /usr/obj/usr/src/sys/ZEROGRAVITY/kernel.debug...done. (kgdb) core-file vmcore.1 panic: bremfree: removing a buffer not on a queue panic messages: --- panic: ufs_dirbad: bad dir syncing disks, buffers remaining... 3810 3810 3810 3809 3809 3809 3806 3807 3807 3807 3807 3807 3803 3803 3803 3780 3782 3782 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 3780 giving up on 2299 buffers Uptime: 36m18s Dumping 511 MB ata0: resetting devices .. done 16 32 48 64 80[CTRL-C to abort] 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #5: Tue Mar 18 16:04:55
buildkernel errors after latest cvsup
=== smapi @ - /usr/src/sys machine - /usr/src/sys/i386/include make: don't know how to make smapi_isa.c. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/CUSTOM. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. - The problem: sys/modules/smapi/Makefile:6:SRCS= smapi_isa.c smapi.c smapi_bios.S \ smapi_isa.c isn't in the tree yet. Did someone forget to commit it? -Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Linux emulation busted
Hi, On Mon, Mar 24, 2003 at 08:40:55AM -0700, M. Warner Losh wrote: I had a working Linux world on my laptop. I upgraded my kernel and acroread4 stopped working. Now all I get is: Exited with error code: 0x400e0009. after a whole lot of disk access when I try to run it. This worked on a December kernel for sure. I'm pretty sure it was working as late as a January 15th kernel. It hasn't worked on a March 1st and subsequent kernels. I'm not sure where it broke inbetween. Has anybody else seen this? I've also seen this on two versions of -STABLE, one built this morning, and another built around February 24th. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: playing mp3s and burning a cd
Am Mo, 2003-03-24 um 20.33 schrieb Vallo Kallaste: Now on 5.0-release, the music gets *slw* as soon as the massive IO gets on. I presume it's related to the interrupt problems the current branch is generally having. Anyone else seeing this? Should I upgrade to -current? Current isn't better. This is a long time problem and is most noticeable when you downgrade from -current to -stable... it's unforgettable feeling :-P I don't expect it will be fixed in the near future, because it's been so over a year now. Current has it's weak points and this is only one of the regressions. I remember having this problem on 5.0-RELEASE, but it was completely gone once I upgraded to -CURRENT (late february I think). Perhaps it could be interesting to know if this problem is connected to certain hardware components. (Athlon XP 2400+ (2008 MHZ), SiS board, realtek 8139B network, SB Live!, nVidia TNT2U, UDMA100 WD harddisk) Besides: my CDROM drive is working properly using PIO and UDMA33. Regards, Julian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: buildkernel errors after latest cvsup
On Mon, 24 Mar 2003, Donn Miller wrote: smapi_isa.c isn't in the tree yet. Did someone forget to commit it? Yep, sorry about that; I changed it in a different tree. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Just building the lib part of world
On Sun, Mar 23, 2003 at 05:42:59AM -0800, David Schultz wrote: Thus spake David Leimbach [EMAIL PROTECTED]: Or even better would be just building libc. I have been working on my getpwnam_r assignment... examining implementations in both Darwin and NetBSD and started trying to implement some of this code for FreeBSD... Its not anywhere even near the goal in sight as I am still learning the build system. Do I always have to build world or can I get away with just making some subdirectories? If so what is the best way to do this? Rebuilding gcc each time I just want to test out my code is a real drag Try: cd src/lib/libc make make install I don't know why every one is missing the critical make obj step, incase you are doing this w/o a fresh /usr/obj tree: cd src/lib/libc make obj make depend make all install To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: playing mp3s and burning a cd
Fact is, there is no CD/DVD-ROM in existence that should be capable of making anything above 900MHz skip audio when running at full stink. My AMD AthlonXP 1600+ cpu can burn a CD at 40X from the network, while playing Wolfenstein at 1024x768 in WinXP. The fact that FreeBSD can't even burn at 4-6X while running measly XMMS is totally unnacceptable and should be looked at. I would do it myself, but I'm only at the very beginnings of being able to program in C. -Craig From: Julian St. [EMAIL PROTECTED] Subject: Re: playing mp3s and burning a cd Am Mo, 2003-03-24 um 20.33 schrieb Vallo Kallaste: Now on 5.0-release, the music gets *slw* as soon as the massive IO gets on. I presume it's related to the interrupt problems the current branch is generally having. Anyone else seeing this? Should I upgrade to -current? Current isn't better. This is a long time problem and is most noticeable when you downgrade from -current to -stable... it's unforgettable feeling :-P I don't expect it will be fixed in the near future, because it's been so over a year now. Current has it's weak points and this is only one of the regressions. I remember having this problem on 5.0-RELEASE, but it was completely gone once I upgraded to -CURRENT (late february I think). Perhaps it could be interesting to know if this problem is connected to certain hardware components. (Athlon XP 2400+ (2008 MHZ), SiS board, realtek 8139B network, SB Live!, nVidia TNT2U, UDMA100 WD harddisk) Besides: my CDROM drive is working properly using PIO and UDMA33. Regards, Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV(8) manpage
On 2003-03-24 19:14, Christian Brueffer [EMAIL PROTECTED] wrote: I'll write a small manpage this evening which says that MAKEDEV is gone now with a short summary of what devfs does. Does that resolve your worries? If you write a detailed description of devfs please add it to devfs(5) and just replace the existing manpage of MAKEDEV with something like: The MAKEDEV script was deprecated by devfs(5) and geom(4) and removed from FreeBSD after GEOM became mandatory. Please see the devfs(5), devfs(8), geom(4) and mount_devfs(8) manpages for more details. This should be enough IMHO to point the reader to the right place. - Giorgos PS: I really think that devfs(5) doesn't belong to section 5, since it's not the description of a file format, but this is a very different topic. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SI_SUB_RAID and SI_SUB_VINUM
Hi Gang! I was wondering, what's the point of making Vinum use a totally different SYSINIT type? Isn't there a possibility it can just use SI_SUB_RAID? Cheers. -- Hiten To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: playing mp3s and burning a cd
On 24-Mar-2003 The Anarcat wrote: I used to listen to MP3s (using xmms) while burning CDs (using cdrecord) and it used to work fine on -stable. Now on 5.0-release, the music gets *slw* as soon as the massive IO gets on. I presume it's related to the interrupt problems the current branch is generally having. Anyone else seeing this? Should I upgrade to -current? Yes, I'm seeing (well, actually, *hearing*) the same thing. I also get it whenever I drag a scrollbar in any gtk-based app (Mozilla, Pan). Current cvsupped 3/24, buildworld, buildkernel. And, yes, it is *very* annoying. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SI_SUB_RAID and SI_SUB_VINUM
On Monday, 24 March 2003 at 19:07:56 -0500, Hiten Pandya wrote: Hi Gang! I was wondering, what's the point of making Vinum use a totally different SYSINIT type? Isn't there a possibility it can just use SI_SUB_RAID? Probably. SI_SUB_VINUM was there first. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Linux emulation busted
[EMAIL PROTECTED] wrote: Mensaje citado por M. Warner Losh [EMAIL PROTECTED]: | I had a working Linux world on my laptop. I upgraded my kernel and | acroread4 stopped working. Now all I get is: | | Exited with error code: 0x400e0009. | | after a whole lot of disk access when I try to run it. This worked on | a December kernel for sure. I'm pretty sure it was working as late as | a January 15th kernel. It hasn't worked on a March 1st and subsequent | kernels. I'm not sure where it broke inbetween. Has anybody else | seen this? Both acroread4 and 5 work for me with Mar 21 and Mar 18 kernels with today's world. Acroread5 works on another machine with a Mar 10 kernel and today's world don't seem to have 4 here. Wasn't this a symptom of the recent change, which causes the Linux kernel modules to become out of date with the kernel, if you just expect make to work like it should? Specifically, you are probably running without the modules, or with old versions of the modules. There was a long discussion on (I believe) this list, about two weeks ago. I don't know why the change was made (and I don't like it, either). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: several background fsck panics
Alexander Langer wrote: I had several panics related to background fsck now. Once I disabled background fsck, all went ok. It began when I pressed the reset buttons on several boots while the system was still doing fscks. Disable write caching on your ATA drive. You should be able to safely reset after that. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Broken DMA devices
It seems The Anarcat wrote: hw.ata.atapi_dma=1# Run the CD-ROM/DVD in DMA mode to /boot/loader.conf. This should be in almost EVERY /boot/loader.conf. The default is 0 (PIO) because DMA is broken on at least a few early CD readers, but it is very rare to have it fail. (I've never seen it.) Can't the ata drivers detect that condition or recognize the set of drives that are broken instead of penalizing everyone else? ATAPI DMA is more likely to be broken than to be working, it is a function of both controller chip and device, in some situations even a function of what master/slave device combo we have.. There is a reason that almost all OS's out there has it disabled as default :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
