Re: Update to UFS2 Superblock Format
On Mon, 25 Nov 2002, Kirk McKusick wrote: Date: Mon, 25 Nov 2002 01:08:30 -0800 (PST) From: Julian Elischer [EMAIL PROTECTED] To: Kirk McKusick [EMAIL PROTECTED] cc: [EMAIL PROTECTED], Robert Watson [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Update to UFS2 Superblock Format In-Reply-To: [EMAIL PROTECTED] X-ASK-Info: Whitelist match On Sun, 24 Nov 2002, Kirk McKusick wrote: Some of these fields could usefully be made unsigned others not (for example fs_pendingblocks and fs_pendinginodes). So just going through and making everything unsigned is not the right approach. I will make a pass through and consider changing some of these fields once the tree opens back up, but not at this point in time when we are trying to keep changes to a minimum and do not have time for extensive testing. Kirk McKusick I'm not in a hurry.. It's just something that I thought should be considered. eventually. BTW how can fs_pendingblocks and fs_pendinginodes be -ve? In theory they should never go negative. But if an inconsistency occurs (for example a crash and remount before background fsck has run) the accounting can get out of whack and the numbers go negative. We check for this happening and take corrective action. If they were changed to unsigned, we would miss the negative transition and instead suddenly think that we had a huge amount of pending space to free. So this is an example where changing them to unsigned would break existing code. But that is no worse than the case where the drive as been whacked and you get a huge +ve number.. You have to check for that anyhow if you are checking for bad values. Checking for -ve numbers is only half of the story. If you are checking for impossibly large +ve numbers then you catch those that would have been -ve. So, Who catches the -ve transition anyway? We found the problem with the rotors because they are -ve, leading into an array offset backwards into hyperspace. It's not efficient to test every offset every time it's used. Checking for -ve is no harder than checking for (say), being greater than the number of blocks in a cylinder group. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20021118.tar.gz
On Tue, Nov 26, 2002 at 09:48:27AM +0900, Mitsuru IWASAKI wrote:
Hi,
the new snapshot boots fine here.
However, I still get the message
acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND
OK, never mind. This is normal because your DSDT doesn't have
_S1_ object.
Name(\_S0_, Package(0x4) {
0x0,
0x0,
0x0,
0x0,
})
Name(\_S3_, Package(0x4) {
0x5,
0x5,
0x0,
0x0,
})
Name(\_S4_, Package(0x4) {
0x6,
0x6,
0x0,
0x0,
})
Name(\_S5_, Package(0x4) {
0x7,
0x7,
0x0,
0x0,
})
when I try to suspend the machine or anything with closing the lid,
or using the keyboard buttons, or when I try something like
acpiconf -s 1.
The box in question is an IBM Thinkpad R32.
Any ideas?
Instead of _S1_, you can specify _S3_ (or _S4_ if you setup for
hibernation properly) for ACPI configuration.
Please try:
# sysctl hw.acpi.sleep_button_state=S3
# sysctl hw.acpi.lid_switch_state=S3
# sysctl hw.acpi.standby_state=S3
Thanks
Thanks, that did the trick.
/me should try a little more before sending out mail.
- Christian
--
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
GPG Key ID : 0xA0ED982D
msg47499/pgp0.pgp
Description: PGP signature
MD broken in current
Hi # mdconfig -a -t vnode ./bootimg.bin mdconfig: ioctl(/dev/mdctl): Bad address # truss mdconfig -a -t vnode ./bootimg.bin open(/dev/mdctl,0x2,00)= 3 (0x3) ioctl(3,MDIOCATTACH,0x8058c00) ERR#14 'Bad address' # ls -l /dev/mdctl crw--- 1 root wheel 95, 0x00ff Nov 26 11:37 /dev/mdctl /dev located on devfs mountpoint Problem appears before 14 Nov md compiled into kernel (not module) Any suggestions -- Vladimir B. Grebenschikov [EMAIL PROTECTED] SWsoft Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MD broken in current
On 26 Nov 2002, Vladimir B. Grebenschikov wrote: # mdconfig -a -t vnode ./bootimg.bin mdconfig: ioctl(/dev/mdctl): Bad address This should be ... -t vnode -f ./bootimg.bin. The bug is just low quality option parsing. ./bootimg.bin is garbage when it is not preceded by -f, and garbage args are silently ignored. A -f file is required to specify the vnode for -t vnode but neither the man page synopsis nor the usage message are detailed enough to say this. When no file arg is specified, the file arg is NULL and this causes the Bad address error. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI problem with laptop?
Hello If I choose to make world under -CURRENT the laptop gets hotter (well the processor/hd and so on gets used and causes heat) now, the fan starts to spin faster and so on, but the computer never gets cooler even a day after a build it still is hot and the fan never stops spinning, is there a way to let my processor know how to calm down? This problem dosn't occur when I'm running Windows (XP) /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI problem with laptop?
Hi, If I choose to make world under -CURRENT the laptop gets hotter (well the processor/hd and so on gets used and causes heat) now, the fan starts to spin faster and so on, but the computer never gets cooler even a day after a build it still is hot and the fan never stops spinning, is there a way to let my processor know how to calm down? This problem dosn't occur when I'm running Windows (XP) Hmm, we need further info. on this. Please add the following lines into your /boor/loader.conf: hw.acpi.verbose=1 debug.acpi.layer=ACPI_ALL_COMPONENTS ACPI_BUS debug.acpi.level=ACPI_LV_WARN ACPI_LV_ERROR ACPI_LV_OBJECTS Then you'll get thermal operation messages, something like: Nov 26 19:34:13 mybox kernel: acpi_tz0: _AC0: temperature 60.0 = setpoint 60.0 Nov 26 19:34:13 mybox kernel: acpi_tz0: switched from NONE to _AC0: 60.0C We need the messages like this, acpidump output, and sysctl hw.acpi output to track this down. BTW, does new acpica patches give any effects for your? http://people.freebsd.org/~iwasaki/acpi/acpica-20021002-20021118-test20021121.diff Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I'm impressed, but ...
On Mon, Nov 25, 2002 at 10:04:23PM +0100, Philip Paeps wrote:
Before it is a few megs of the same. Basically Mutt reading my mailbox.
Anything else I can do to help?
You could give the attached patch a try.
Were you by any chance using truss(1) just before mutt started
to hang?
ciao,
-robert
Index: src/sys/alpha/alpha/trap.c
===
RCS file: /home/ncvs/src/sys/alpha/alpha/trap.c,v
retrieving revision 1.102
diff -u -r1.102 trap.c
--- src/sys/alpha/alpha/trap.c 24 Oct 2002 23:09:47 - 1.102
+++ src/sys/alpha/alpha/trap.c 26 Nov 2002 10:51:25 -
@@ -738,7 +738,8 @@
td-td_retval[0] = 0;
td-td_retval[1] = 0;
- STOPEVENT(p, S_SCE, (callp-sy_narg SYF_ARGMASK));
+ STOPEVENT(p, S_SCE, (callp-sy_narg SYF_ARGMASK),
+ syscall entry);
error = (*callp-sy_call)(td, args + hidden);
}
@@ -784,7 +785,7 @@
* register set. If we ever support an emulation where this
* is not the case, this code will need to be revisited.
*/
- STOPEVENT(p, S_SCX, code);
+ STOPEVENT(p, S_SCX, code, syscall exit);
#ifdef DIAGNOSTIC
cred_free_thread(td);
Index: src/sys/i386/i386/trap.c
===
RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v
retrieving revision 1.237
diff -u -r1.237 trap.c
--- src/sys/i386/i386/trap.c7 Nov 2002 01:34:23 - 1.237
+++ src/sys/i386/i386/trap.c26 Nov 2002 10:51:26 -
@@ -1028,7 +1028,7 @@
td-td_retval[0] = 0;
td-td_retval[1] = frame.tf_edx;
- STOPEVENT(p, S_SCE, narg);
+ STOPEVENT(p, S_SCE, narg, syscall entry);
error = (*callp-sy_call)(td, args);
}
@@ -1092,7 +1092,7 @@
* register set. If we ever support an emulation where this
* is not the case, this code will need to be revisited.
*/
- STOPEVENT(p, S_SCX, code);
+ STOPEVENT(p, S_SCX, code, syscall exit);
#ifdef DIAGNOSTIC
cred_free_thread(td);
Index: src/sys/ia64/ia64/trap.c
===
RCS file: /home/ncvs/src/sys/ia64/ia64/trap.c,v
retrieving revision 1.65
diff -u -r1.65 trap.c
--- src/sys/ia64/ia64/trap.c24 Oct 2002 23:09:48 - 1.65
+++ src/sys/ia64/ia64/trap.c26 Nov 2002 10:51:28 -
@@ -852,7 +852,8 @@
td-td_retval[0] = 0;
td-td_retval[1] = 0;
- STOPEVENT(p, S_SCE, (callp-sy_narg SYF_ARGMASK));
+ STOPEVENT(p, S_SCE, (callp-sy_narg SYF_ARGMASK),
+ syscall entry);
error = (*callp-sy_call)(td, args);
}
@@ -900,7 +901,7 @@
* register set. If we ever support an emulation where this
* is not the case, this code will need to be revisited.
*/
- STOPEVENT(p, S_SCX, code);
+ STOPEVENT(p, S_SCX, code, syscall exit);
#ifdef DIAGNOSTIC
cred_free_thread(td);
@@ -1013,7 +1014,7 @@
td-td_retval[0] = 0;
td-td_retval[1] = framep-tf_r[FRAME_R10]; /* edx */
- STOPEVENT(p, S_SCE, narg);
+ STOPEVENT(p, S_SCE, narg, ia32 syscall entry);
error = (*callp-sy_call)(td, args64);
}
@@ -1077,7 +1078,7 @@
* register set. If we ever support an emulation where this
* is not the case, this code will need to be revisited.
*/
- STOPEVENT(p, S_SCX, code);
+ STOPEVENT(p, S_SCX, code, ia32 syscall exit);
#ifdef DIAGNOSTIC
cred_free_thread(td);
Index: src/sys/kern/kern_exec.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.201
diff -u -r1.201 kern_exec.c
--- src/sys/kern/kern_exec.c25 Nov 2002 04:37:44 - 1.201
+++ src/sys/kern/kern_exec.c26 Nov 2002 10:51:29 -
@@ -563,12 +563,6 @@
KNOTE(p-p_klist, NOTE_EXEC);
p-p_flag = ~P_INEXEC;
- /*
-* If tracing the process, trap to debugger so breakpoints
-* can be set before the program executes.
-*/
- _STOPEVENT(p, S_EXEC, 0);
-
if (p-p_flag P_TRACED)
psignal(p, SIGTRAP);
@@ -640,8 +634,14 @@
if (imgp-object)
vm_object_deallocate(imgp-object);
- if (error == 0)
+ if (error == 0) {
+ /*
+* If tracing the process, trap to debugger so breakpoints
+* can be set before the program executes.
+*/
+ STOPEVENT(p, S_EXEC, 0, exec);
goto done2;
+ }
exec_fail:
/* we're done here, clear P_INEXEC */
Index: src/sys/kern/kern_exit.c
===
RCS file:
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Nov 26 03:02:22 PST 2002 -- Kernel build for GENERIC completed on Tue Nov 26 03:34:28 PST 2002 -- Kernel build for LINT started on Tue Nov 26 03:34:28 PST 2002 -- === vinum Makefile, line 4446: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/isp/isp_pci.c: In function `tdma_mkfc': /h/des/src/sys/dev/isp/isp_pci.c:1543: warning: unsigned int format, different type arg (arg 5) /h/des/src/sys/dev/isp/isp_pci.c:1543: warning: int format, different type arg (arg 6) /h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different type arg (arg 6) /h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different type arg (arg 7) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel broken
CVSuped (2 mins ago) -current kernel is broken: cc1: warnings being treated as errors /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_lock': /usr/src/sys/dev/sound/isa/ad1816.c:81: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:81: request for member `mtx_lock' in something not a structure or union /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_unlock': /usr/src/sys/dev/sound/isa/ad1816.c:87: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:87: request for member `mtx_lock' in something not a structure or union Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/sound/pcm buffer.c channel.c feeder.c feeder_fmt.c feeder_rate.c sndstat.c sound.c sound.h vchan.c
On Tue, Nov 26, 2002 at 06:19:41AM +, cameron grant wrote: I have no idea why, but this commit broke kernel building: cc -c -O -pipe -mcpu=athlon -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/sound/isa/ad1816.c cc1: warnings being treated as errors /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_lock': /usr/src/sys/dev/sound/isa/ad1816.c:81: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:81: request for member `mtx_lock' in something not a structure or union /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_unlock': /usr/src/sys/dev/sound/isa/ad1816.c:87: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:87: request for member `mtx_lock' in something not a structure or union *** Error code 1 And the same result for other consumers of snd_mtx* . i'm unable to reproduce this. have you tried a clean build? It was a clean build, done by make buildkernel immediately after make buildworld. SOP. FWIW, I can't even figure out why this doesn't compile, everything looks fine to me and the errors make no sense at all. The only thing I can think to do is blow away /usr/src and get a new one, see if anything changes. -- Ray Kohler [EMAIL PROTECTED] It has been said that man is a rational animal. All my life I have been searching for evidence which could support this. -- Bertrand Russell To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I'm impressed, but ...
On 2002-11-26 12:37:25 (+0100), Robert Drehmel [EMAIL PROTECTED] wrote: On Mon, Nov 25, 2002 at 10:04:23PM +0100, Philip Paeps wrote: Before it is a few megs of the same. Basically Mutt reading my mailbox. Anything else I can do to help? You could give the attached patch a try. Okay. I'll let you know if it helps :-) Were you by any chance using truss(1) just before mutt started to hang? No. I used truss after it hung - and after I rebooted - to try and figure out why it hangs the next time it hung. I'll get back to you after my kernel is compiled. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. If at first you don't succeed, try something else. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: cvs commit: src/sys/dev/sound/pcm buffer.c channel.c feeder.c feeder_fmt.c feeder_rate.c sndstat.c sound.c sound.h vchan.c
First: sorry for sending same error i'ven't seen this thread I've the same prob on a freshly installed system with /usr/src only from CVS repository and /usr/obj clean (It is a minimum installed -current from a 2 days onld snapshot CD). Jan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ray Kohler Sent: Tuesday, November 26, 2002 1:01 PM To: cameron grant Cc: [EMAIL PROTECTED] Subject: Re: cvs commit: src/sys/dev/sound/pcm buffer.c channel.c feeder.c feeder_fmt.c feeder_rate.c sndstat.c sound.c sound.h vchan.c On Tue, Nov 26, 2002 at 06:19:41AM +, cameron grant wrote: I have no idea why, but this commit broke kernel building: cc -c -O -pipe -mcpu=athlon -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/sound/isa/ad1816.c cc1: warnings being treated as errors /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_lock': /usr/src/sys/dev/sound/isa/ad1816.c:81: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:81: request for member `mtx_lock' in something not a structure or union /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_unlock': /usr/src/sys/dev/sound/isa/ad1816.c:87: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:87: request for member `mtx_lock' in something not a structure or union *** Error code 1 And the same result for other consumers of snd_mtx* . i'm unable to reproduce this. have you tried a clean build? It was a clean build, done by make buildkernel immediately after make buildworld. SOP. FWIW, I can't even figure out why this doesn't compile, everything looks fine to me and the errors make no sense at all. The only thing I can think to do is blow away /usr/src and get a new one, see if anything changes. -- Ray Kohler [EMAIL PROTECTED] It has been said that man is a rational animal. All my life I have been searching for evidence which could support this. -- Bertrand Russell 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: Kernel broken
On Tue, Nov 26, 2002 at 12:53:39PM +0100, Jan Stocker wrote: CVSuped (2 mins ago) -current kernel is broken: cc1: warnings being treated as errors /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_lock': /usr/src/sys/dev/sound/isa/ad1816.c:81: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:81: request for member `mtx_lock' in something not a structure or union /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_unlock': /usr/src/sys/dev/sound/isa/ad1816.c:87: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:87: request for member `mtx_lock' in something not a structure or union This turns out to be semi-reproduceable. I have this problem but the committer who made the change can't reproduce it. -- Ray Kohler [EMAIL PROTECTED] Math is like love -- a simple idea but it can get complicated. -- R. Drabek To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel broken
Changing the locks from void * to struct mtx * seems to fix the problem.
Mark
diff -u -r ../../../../vendor/sys/dev/sound/isa/ad1816.c ./isa/ad1816.c
--- ../../../../vendor/sys/dev/sound/isa/ad1816.c Thu Nov 14 17:00:39 2002
+++ ./isa/ad1816.c Tue Nov 26 13:03:17 2002
@@ -53,7 +53,7 @@
int drq2_rid;
void *ih;
bus_dma_tag_t parent_dmat;
- void *lock;
+ struct mtx *lock;
unsigned int bufsize;
struct ad1816_chinfo pch, rch;
diff -u -r ../../../../vendor/sys/dev/sound/isa/mss.c ./isa/mss.c
--- ../../../../vendor/sys/dev/sound/isa/mss.c Thu Nov 14 17:00:39 2002
+++ ./isa/mss.c Tue Nov 26 13:05:48 2002
@@ -66,7 +66,7 @@
int drq2_rid;
void *ih;
bus_dma_tag_tparent_dmat;
-void *lock;
+struct mtx *lock;
char mss_indexed_regs[MSS_INDEXED_REGS];
char opl_indexed_regs[OPL_INDEXED_REGS];
diff -u -r ../../../../vendor/sys/dev/sound/isa/sbc.c ./isa/sbc.c
--- ../../../../vendor/sys/dev/sound/isa/sbc.c Thu Nov 14 17:00:39 2002
+++ ./isa/sbc.c Tue Nov 26 13:06:04 2002
@@ -64,7 +64,7 @@
void *ih[IRQ_MAX];
- void *lock;
+ struct mtx *lock;
u_int32_t bd_ver;
};
diff -u -r ../../../../vendor/sys/dev/sound/pci/cmi.c ./pci/cmi.c
--- ../../../../vendor/sys/dev/sound/pci/cmi.c Thu Nov 14 17:00:39 2002
+++ ./pci/cmi.c Tue Nov 26 13:06:19 2002
@@ -107,7 +107,7 @@
struct resource *reg, *irq;
int regid, irqid;
void*ih;
- void*lock;
+ struct mtx *lock;
int spdif_enabled;
unsigned intbufsz;
diff -u -r ../../../../vendor/sys/dev/sound/pci/ds1.c ./pci/ds1.c
--- ../../../../vendor/sys/dev/sound/pci/ds1.c Thu Nov 14 17:00:40 2002
+++ ./pci/ds1.c Tue Nov 26 13:06:36 2002
@@ -116,7 +116,7 @@
struct resource *reg, *irq;
int regid, irqid;
void*ih;
- void*lock;
+ struct mtx *lock;
void *regbase;
u_int32_t *pbase, pbankbase, pbanksize;
diff -u -r ../../../../vendor/sys/dev/sound/pci/emu10k1.c ./pci/emu10k1.c
--- ../../../../vendor/sys/dev/sound/pci/emu10k1.c Tue Nov 26 09:20:58 2002
+++ ./pci/emu10k1.c Tue Nov 26 13:06:49 2002
@@ -96,7 +96,7 @@
struct resource *reg, *irq;
void*ih;
- void*lock;
+ struct mtx *lock;
unsigned int bufsz;
int timer, timerinterval;
diff -u -r ../../../../vendor/sys/dev/sound/pci/t4dwave.c ./pci/t4dwave.c
--- ../../../../vendor/sys/dev/sound/pci/t4dwave.c Thu Nov 14 17:00:40 2002
+++ ./pci/t4dwave.c Tue Nov 26 13:07:10 2002
@@ -81,7 +81,7 @@
int regtype, regid, irqid;
void *ih;
- void *lock;
+ struct mtx *lock;
u_int32_t playchns;
unsigned int bufsz;
diff -u -r ../../../../vendor/sys/dev/sound/pcm/ac97.c ./pcm/ac97.c
--- ../../../../vendor/sys/dev/sound/pcm/ac97.c Thu Nov 14 17:00:40 2002
+++ ./pcm/ac97.cTue Nov 26 13:07:27 2002
@@ -55,7 +55,7 @@
u_int32_t flags;
struct ac97mixtable_entry mix[32];
char name[AC97_NAMELEN];
- void *lock;
+ struct mtx *lock;
};
struct ac97_codecid {
diff -u -r ../../../../vendor/sys/dev/sound/pcm/mixer.c ./pcm/mixer.c
--- ../../../../vendor/sys/dev/sound/pcm/mixer.cThu Nov 14 17:00:40 2002
+++ ./pcm/mixer.c Tue Nov 26 13:07:52 2002
@@ -47,7 +47,7 @@
u_int32_t recsrc;
u_int16_t level[32];
char name[MIXER_NAMELEN];
- void *lock;
+ struct mtx *lock;
};
static u_int16_t snd_mixerdefaults[SOUND_MIXER_NRDEVICES] = {
diff -u -r ../../../../vendor/sys/dev/sound/pcm/sound.c ./pcm/sound.c
--- ../../../../vendor/sys/dev/sound/pcm/sound.cTue Nov 26 09:20:59 2002
+++ ./pcm/sound.c Tue Nov 26 13:08:08 2002
@@ -50,7 +50,7 @@
char status[SND_STATUSLEN];
struct sysctl_ctx_list sysctl_tree;
struct sysctl_oid *sysctl_tree_top;
- void *lock;
+ struct mtx *lock;
};
devclass_t pcm_devclass;
On Tue, Nov 26, 2002 at 12:53:39PM +0100, Jan Stocker wrote:
CVSuped (2 mins ago) -current kernel is broken:
cc1: warnings being treated as errors
/usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_lock':
/usr/src/sys/dev/sound/isa/ad1816.c:81: warning: dereferencing `void *'
pointer
/usr/src/sys/dev/sound/isa/ad1816.c:81: request for member `mtx_lock' in
something not a structure or union
/usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_unlock':
/usr/src/sys/dev/sound/isa/ad1816.c:87: warning: dereferencing `void *'
pointer
/usr/src/sys/dev/sound/isa/ad1816.c:87: request for member `mtx_lock' in
something not a structure or union
Jan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
Mark
RE: cvs commit: src/sys/dev/sound/pcm buffer.c channel.c feeder.c feeder_fmt.c feeder_rate.c sndstat.c sound.c sound.h vchan.c
Okay here a detailed description... a) Install a minumum -current from snapshot CD (2 days old). b) Add a cvsup-package without gui (i made before with pkg_create -b blah). c) Get -current fom cvs repo (with cvsup...). d) cd /usr/src make buildworld (works fine) e) copying my kernel-conf. f) make KERNCONF=x buildkernel Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI problem with laptop?
Terry Lambert wrote: Is this a Dell Lattitude? They are known to have heat problems. There's also the possibility that the CPU is a desktop CPU in the laptop; people aren't supposed to do that, either, but it can crank up the heat. -- Terry Hello No it's a Evo N114 with an Athlon 4 in it, I think that this is a mobile CPU /John -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: snd_pcm module not usable ... ?
perfect, thanks ... worked like a charm ... On Mon, 25 Nov 2002, Daniel C. Sobral wrote: Marc G. Fournier wrote: Maybe i'm missing something that i need to load, but I took the pcm device out of my kernel config, figuring that I could use the snd_pcm module ... loaded it, but still can't seem to get sound? is there something else I need to do with devfs for this, or do Ihave to compile in the pcm device? pcm is the front-end. You need the back-end, the actual sound driver. Try snd_driver_load=YES. It ought to load everything. Or you can kldload it from the command line, and then check /var/log/messages to find out which driver you are supposed to use. On loader, loading any sound driver will bring in snd_pcm automatically, as a dependency. -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Fundamentalist Debianites, core children of the Linuxen sounds like it could come from the Book of Mormon, or Tolkien on a bad day... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI problem with laptop?
John Angelmo wrote: Terry Lambert wrote: Is this a Dell Lattitude? They are known to have heat problems. There's also the possibility that the CPU is a desktop CPU in the laptop; people aren't supposed to do that, either, but it can crank up the heat. No it's a Evo N114 with an Athlon 4 in it, I think that this is a mobile CPU It may be that Windows ensures that the computer runs cooler by down-clocking it. Have you applied the most recent ACPI patches, and turned on debugging output (at least hw.acpi.verbose=1) to see if it fixes the problem (and if it doesn't, at least report what's going on)? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI problem with laptop?
Terry Lambert wrote: Have you applied the most recent ACPI patches, and turned on debugging output (at least hw.acpi.verbose=1) to see if it fixes the problem (and if it doesn't, at least report what's going on)? It looks like the author of the ACPI code has already replied to your post; apply the patch he suggests, and turn on the debugging he suggests. He knows far mor about ACPI than the rest of us. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20021118.tar.gz
ACPI stiil fails miserably on my Thinkpad T23 with these patches. I've attached the ASL and DSDT data in tar.gz format. Output from boot -v (transcribed by hand, so forgive any obvious typos) Note -- the 'o' character in 'So' below is really o with an umlat. I suspect the space in 'T ' is a non-breaking space as well. acpi0: IBM TP-1A on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GEP31 pci_open(1): mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=35758086) Using $PIR table, 14 entries at 0xc00fdeb0 skipping PCI interrupt list ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name: f0009453 ACPI-0438: *** Error: Looking up [So] in namespace, AE_BAD_CHARACTER ACPI-1287: *** Error: Method execution failed, AE_BAD_CHARACTER ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name: f0009453 ACPI-0438: *** Error: Looking up [So] in namespace, AE_BAD_CHARACTER ACPI-1287: *** Error: Method execution failed, AE_BAD_CHARACTER ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name: f000ff54 ACPI-0438: *** Error: Looking up [T ] in namespace, AE_BAD_CHARACTER repeat last 3 lines 8 times panic: kmem_malloc: entry not found or misaligned Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db show registers .. edx 0x40 ebx 0 ... db trace panic(c03d0e4c,0,c05838c0,1,0) at panic+0xab kmem_malloc(c0832078,1000,1,c058391c,c034c20b) at kmem_malloc+0x33c page_alloc(c083ac80,1000,c058390f,1,780) at page_alloc_0x27 slab_zalloc(c083ac80,1,c4049f6c,c4049f40,63) at slab_zalloc+0xfb uma_zone_slab(c083ac80,1,15f,c4046400,c083ad68) at uma_zone_slab+0x9e uma_zalloc_bucket(c083ac80,1,c03d2929,57e,c151a380) at uma_zalloc_bucekt+0x16d uma_zalloc_arg(c083ac80,0,1,c151a380,c083ac80) at uma_zalloc_arg+0x2f5 malloc(1c,c0550da0,1,c0583940,c0538538) at malloc+0x76 AcpiOsAllocate(1c,c05839f0,c053a4fc,c054fe24,0) at AcpiOsAllocate+0x21 AcpiUtCallocate(1c,1,c054b483,ff,0) at AcpiUtCallocate+0x48 AcpiUtAcquireFromCache(3,0,100,0,c3fa4000) at AcpiUtAcquireFromCache+0xac AcpiPsAllocOp(0,c4046400,0,c0246966,c3fa41e4) at AcpiPsAllocOp+0x7c AcpiPsParseLoop(c3fa4000,c403b040,c0583b0c,0,0) at AcpiPsParseLoop+0x37e AcpiPsParseAml(c3fa4000,c4040340,c4044700,d7ae2332,2f) at AcpiPsParseAml+0x7c AcpiPsxExecute(c4044700,0,c0583b74,c4044700,c0583bfc) at AcpiPsxExecute+0x12f AcpiNsExecuteControlMethod(c4044700,0,c0583b74,c151a500,0) at AcpiNsExecuteControlMethod+0x5f AcpiNsEvaluateByHandle(c4044700,0,c0583bfc,e,0) at AcpiNsEvalueByHandle+0x92 AcpiNsEvaluateRelative(c4044760,c054b6d3,0,c0583bfc0) at AcpiNsEvaluateRelative+0xde AcpiUtExecute_STA(c4044760,c0583c20,0,0,c0583c30) at AcpiUtExecute_STA+0x31 AcpiNsInitOneDevice(c4044760,2,c0583c84,0,6) at AcpiNsInitOneDevice+0x77 AcpiNsInitializeDevices(0,c0583cdc,c053b42e,0,2) at AcpiNsInitializeDevices+0x53 AcpiInitializeObjects(0,2,c052b930,0,0) at AcpiInitializeObjects+0x14 acpi_attach(c403c200,c4005098,c03e3954,c1503a70,c05500e3) at acpi_attach+0x15e ibm_t23_acpi.tar.gz Description: GNU Zip compressed data
Re: Re: Kernel broken
I too could compile successfully last night without any problems.. it fixes the pcm lock problems when using witness and invariant options ... atleast for me. dheeraj -Original Message- From: Ray Kohler [EMAIL PROTECTED] To: Jan Stocker [EMAIL PROTECTED] Date: Tue, 26 Nov 2002 07:12:37 -0500 Subject: Re: Kernel broken On Tue, Nov 26, 2002 at 12:53:39PM +0100, Jan Stocker wrote: CVSuped (2 mins ago) -current kernel is broken: cc1: warnings being treated as errors /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_lock': /usr/src/sys/dev/sound/isa/ad1816.c:81: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:81: request for member `mtx_lock' in something not a structure or union /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_unlock': /usr/src/sys/dev/sound/isa/ad1816.c:87: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:87: request for member `mtx_lock' in something not a structure or union This turns out to be semi-reproduceable. I have this problem but the committer who made the change can't reproduce it. -- Ray Kohler [EMAIL PROTECTED] Math is like love -- a simple idea but it can get complicated. -- R. Drabek 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: Kernel broken
-Original Message-
From: Ray Kohler [EMAIL PROTECTED]
To: Jan Stocker [EMAIL PROTECTED]
Date: Tue, 26 Nov 2002 07:12:37 -0500
Subject: Re: Kernel broken
On Tue, Nov 26, 2002 at 12:53:39PM +0100, Jan Stocker wrote:
CVSuped (2 mins ago) -current kernel is broken:
=20
cc1: warnings being treated as errors
/usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_lock':
/usr/src/sys/dev/sound/isa/ad1816.c:81: warning: dereferencing `void *'
pointer
/usr/src/sys/dev/sound/isa/ad1816.c:81: request for member `mtx_lock' in
something not a structure or union
/usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_unlock':
/usr/src/sys/dev/sound/isa/ad1816.c:87: warning: dereferencing `void *'
pointer
/usr/src/sys/dev/sound/isa/ad1816.c:87: request for member `mtx_lock' in
something not a structure or union
This turns out to be semi-reproduceable. I have this problem but the
committer who made the change can't reproduce it.
I have the same problem, and I've deleted my /usr/src and checked it
out new. I've also cvsup'd from 2 different servers - no help. Either
the commit never made it from the repository to the servers or something
else is totally fubar.
The culprit seems to be a change in /sys/dev/sound/pcm/sound.h, where
snd_mtx{un}lock() were changed from routines to macros which simply
use mtx_{un}lock(). The routines required a ``void *'', but the
macros require a ``struct mtx *''.
The following drivers still declare the lock to be a ``void *'',
which is totally bogus after the above mentioned change:
/sys/dev/sound/isa/ad1816.c
/sys/dev/sound/isa/mss.c
/sys/dev/sound/isa/sbc.c
/sys/dev/sound/pci/cmi.c
/sys/dev/sound/pci/ds1.c
/sys/dev/sound/pci/emu10k1.c
/sys/dev/sound/pci/t4dwave.c
/sys/dev/sound/pcm/ac97.c
/sys/dev/sound/pcm/mixer.c
/sys/dev/sound/pcm/sound.c
Changing the ``void *'' to ``struct mtx *'' allows the kernel to be compiled
and sound also works.
This is definitely a show-stopper and should be fixed ASAP, no matter
which change is correct. cg is the last committer who touched the header.
---
Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
jdk 1.3.1_6 linux compilation.
During a compile of the openoffice-pl package I have just noticed, that 1. Well it depends on java... 2. java depends on the Linux emulation stuff. 3. The automatic fetching of the linux stuff is still looking for RedHat 7.1 files at the ftp.redhat.com FTP site. Well I could live with using OpenOffice without *any* java crap. I never noticed any functionality provided by it. At least please someone remove ftp.redhat.com from the corresponding fetch list. -- Marcin Dalecki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: jdk 1.3.1_6 linux compilation.
On Tuesday 26 November 2002 18:19, Marcin Dalecki wrote: During a compile of the openoffice-pl package I have just noticed, that 1. Well it depends on java... 2. java depends on the Linux emulation stuff. 3. The automatic fetching of the linux stuff is still looking for RedHat 7.1 files at the ftp.redhat.com FTP site. Well I could live with using OpenOffice without *any* java crap. I never noticed any functionality provided by it. You can add java applets to your documents. I guess it's a portable replacement for microsofts macro crap without the security holes. //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACLs on the boot partition?
On 25 Nov 2002 at 23:34, [EMAIL PROTECTED] wrote... How do I enable ACLs on the boot partition? tunefs -a enable /dev/ad0s1a indicates it got set (in single user mode with / mounted readonly). But I still can't set anything with setfacl(1). I tried booting to the fixit floppy, hoping to set acls flag from there to my partition, but it doesn't have tunefs. Is my only choice now to take the drive out and put it in another FreeBSD machine and set it from there? If you are using UFS1, did you follow the procedures in /sys/ufs/ufs/README.acls ? Bruno Miguel Afonso, Biological Eng. student. brunomiguel at dequim dot ist dot utl dot pt D.E.Q. @ I.S.T. - Portugal Linux is for Microsoft haters. BSD is for Unix lovers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: jdk 1.3.1_6 linux compilation.
David Holm wrote: On Tuesday 26 November 2002 18:19, Marcin Dalecki wrote: During a compile of the openoffice-pl package I have just noticed, that 1. Well it depends on java... 2. java depends on the Linux emulation stuff. 3. The automatic fetching of the linux stuff is still looking for RedHat 7.1 files at the ftp.redhat.com FTP site. Well I could live with using OpenOffice without *any* java crap. I never noticed any functionality provided by it. You can add java applets to your documents. I guess it's a portable replacement for microsofts macro crap without the security holes. Thanks for the enlightenment. But how does it come then that mozilla doesn't need anything similar? Anyway I have never ever encountered any document using this feature. And in relation to security: Starting a Java interpreter turns nearly always out to be a DOS attack in effect ;-) I really don't miss Java from IE6.0 either which fortunately lead to th death of the applet technology frenzy on the web. (I'm still fetching the whole Linux emulation environment just to get openoffice up and running again... g...) -- Marcin Dalecki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20020815
Mark Santcroos wrote: On Mon, Aug 26, 2002 at 03:01:48AM +0900, Mitsuru IWASAKI wrote: How about this one? http://people.freebsd.org/~iwasaki/acpi/vga_pci-20020228.tar.gz This simply set PCI_POWERSTATE_D0 for VGA device on wakeup. This didn't work unfortunately. The problem is actually a bit weird. When I suspend (close the lid or with the key combo) the display is not turned off actually. It does go in some form of suspend however. When I resume, the machine comes back to life again, but the screen goes off at that moment. Any news on this issue? I still see the issue Mark described on a similar Dell with today's -current, and it's the only major remaining issue that prevents me from switching to -current exclusively. Not being able to standby is a major pain. This is probably incredibly naive, but since this worked under -stable, shouldn't there be some code already that does the right thing? (I'm guessing the answer must be no, everything is different with ACPI.) Other than that, great job on the ACPI code - everything else works flawlessly! Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: jdk 1.3.1_6 linux compilation.
+---[ Marcin Dalecki ]-- | | (I'm still fetching the whole Linux emulation environment just | to get openoffice up and running again... g...) make -DNATIVE_BOOTSTRAP install for /usr/ports/java/jdk13 should avoid needing the Linux Emu just to get Java running... I haven't tried that with Open Office, so as usual YMMV. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | M:+61 416 022 411 | ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MD broken in current
On Tue, Nov 26, 2002 at 09:00:37PM +1100, Bruce Evans wrote the words in effect of:
On 26 Nov 2002, Vladimir B. Grebenschikov wrote:
# mdconfig -a -t vnode ./bootimg.bin
mdconfig: ioctl(/dev/mdctl): Bad address
This should be ... -t vnode -f ./bootimg.bin.
The bug is just low quality option parsing. ./bootimg.bin is garbage
when it is not preceded by -f, and garbage args are silently ignored.
A -f file is required to specify the vnode for -t vnode but neither
the man page synopsis nor the usage message are detailed enough to
say this. When no file arg is specified, the file arg is NULL and
this causes the Bad address error.
There is also a problem, when the md(4) driver is passed a 0 byte file,
i.e. mdconfig -a -t -vnode -f /tmp/mdimage.zero. It simply hangs the
process in the `mddestroy' state, making it unkillable.
David Wolfskill tested a patch, which I made. It could be a _possible_
fix to the problem. When a 0 byte file is found, by mdcreate_vnode()
it passes up an EINVAL.
I used the stat structure, and the vn_stat() routine to get the information,
although I am not sure if that is the best/sane way of doing it. The URL for
the patch is: http://www.unixdaemons.com/~hiten/work/diffs/md.c.patch
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: md.c
===
RCS file: /home/ncvs/src/sys/dev/md/md.c,v
retrieving revision 1.74
diff -u -r1.74 md.c
--- md.c2002/10/21 20:08:28 1.74
+++ md.c2002/11/24 23:43:40
@@ -79,6 +79,7 @@
#include sys/stdint.h
#include sys/sysctl.h
#include sys/vnode.h
+#include sys/stat.h
#include vm/vm.h
#include vm/vm_object.h
@@ -807,6 +808,7 @@
struct md_s *sc;
struct vattr vattr;
struct nameidata nd;
+ struct stat sb;
int error, flags;
flags = FREAD|FWRITE;
@@ -828,6 +830,13 @@
(void) vn_close(nd.ni_vp, flags, td-td_ucred, td);
return (error ? error : EINVAL);
}
+
+ error = vn_stat(nd.ni_vp, sb, td-td_ucred, NOCRED, td);
+ if (error)
+ return (error);
+ if (sb.st_size == 0)
+ return (EINVAL);
+
VOP_UNLOCK(nd.ni_vp, 0, td);
if (mdio-md_options MD_AUTOUNIT) {
Re: ACLs on the boot partition?
On Tue, 26 Nov 2002, Bruno Miguel wrote: On 25 Nov 2002 at 23:34, [EMAIL PROTECTED] wrote... How do I enable ACLs on the boot partition? tunefs -a enable /dev/ad0s1a indicates it got set (in single user mode with / mounted readonly). But I still can't set anything with setfacl(1). I tried booting to the fixit floppy, hoping to set acls flag from there to my partition, but it doesn't have tunefs. Is my only choice now to take the drive out and put it in another FreeBSD machine and set it from there? If you are using UFS1, did you follow the procedures in /sys/ufs/ufs/README.acls ? No, not using USF1. / was formatted UFS2. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH - changing libc_r to use *context()
I'd like some feedback on whether some heavy threaded apps (GNOME, OpenOffice, Java, etc) have any problems with this patch before asking re@ for commit permission. BTW, it also needs testing on alpha. I tried it on i386 (athon-xp) and every app I've tried stalled/locked or crashed right away. Mozilla gives me: The program 'unknown' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 4773 error_code 2 request_code 53 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) gnome-cd: (gnome_segv:60260): Gdk-CRITICAL **: file gdkpixbuf-render.c: line 190 (gdk_pixbuf_render_to_drawable): assertion `src_x = 0 src_x + width = pixbuf-width' failed xchat2: (xchat:60267): Gtk-CRITICAL **: file gtkprogress.c: line 550 (gtk_progress_set_percentage): assertion `percentage = 0 percentage = 1.0' failed I've recompiled the ports (and stuff they depend on) before I tried them. Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACLs on the boot partition?
On Tue, Nov 26, 2002 at 11:21:28AM -0700, [EMAIL PROTECTED] wrote the words in effect of: On Tue, 26 Nov 2002, Bruno Miguel wrote: On 25 Nov 2002 at 23:34, [EMAIL PROTECTED] wrote... How do I enable ACLs on the boot partition? tunefs -a enable /dev/ad0s1a indicates it got set (in single user mode with / mounted readonly). But I still can't set anything with setfacl(1). I tried booting to the fixit floppy, hoping to set acls flag from there to my partition, but it doesn't have tunefs. Is my only choice now to take the drive out and put it in another FreeBSD machine and set it from there? If you are using UFS1, did you follow the procedures in /sys/ufs/ufs/README.acls ? No, not using USF1. / was formatted UFS2. tunefs -a /your/filesystem I think thats the one. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1950] Call for testers: acpica-unix-20021118.tar.gz
Hi Mitsuru, Tried your patch today and S3 still doesn't work for me. It does seem to suspend but resumes back immediately after suspending. (The same behaviour as with other acpica snapshots) This is the register dump on suspend and resume. Does this make sense to you or someone else? (As in is the explanation in there) acpi_printcpu() debug dump gdt[0077:c03f93c0] idt[0407:c0438b20] ldt[0028] tr[0020] efl[0082] eax[00024000] ebx[c22d0400] ecx[c056d8c0] edx[bfc00090] esi[] edi[c0c02078] ebp[ce3fca90] esp[ce3fca5c] cr0[8005003b] cr2[282dc000] cr3[0a16f000] cr4[0601] cs[0008] ds[0010] es[0010] fs[0018] gs[002f] ss[0010] acpi_printcpu() debug dump gdt[0077:c03f93c0] idt[0407:c0438b20] ldt[0028] tr[0020] efl[0002] eax[0001] ebx[c22d0400] ecx[8000] edx[c26ae000] esi[] edi[c0c02078] ebp[ce3fca90] esp[ce3fca5c] cr0[8005003b] cr2[282dc000] cr3[0a16f000] cr4[0601] cs[0008] ds[0010] es[0010] fs[0018] gs[002f] ss[0010] Laptop is Dell Latitude C640. Thanks Mark On Thu, Nov 21, 2002 at 07:42:05PM +0900, Mitsuru IWASAKI wrote: Hi all, I've made patches for the latest ACPI CA snapshot between 20021002 and 20021118. http://people.freebsd.org/~iwasaki/acpi/acpica-20021002-20021118-test20021121.diff A lot of bugs are fixed, please check the change log at: http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt Please test them and feedback to [EMAIL PROTECTED] if you find any problems. I'll import them into src tree before RC1. Thanks -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Searching for users of netncp and nwfs to help debug 5.0 problems
Martijn Pronk wrote: Robert Watson wrote: The build of netncp is currently broken on 5.0-CURRENT, and I'd like to see this fixed before 5.0-RELEASE. Unfortunately, we're having a lot of trouble finding a test environment, which is the natural and immediate follow-on to the compile fixes :-). Was wondering if anyone with FreeBSD kernel debugging experience and some time on their hands was interested in helping resolve this issue over the next week or two. I can test this next week at work, however, I don't normally use netncp nwfs, so it may take me a while. I'll get back on this next week. I tried to build a kernel with options IPX, NCP and NWFS, but it failed with the following error: cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/home/src/sys -I/home/src/sys/dev -I/home/src/sys/contrib/dev/acpica -I/home/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding /home/src/sys/netncp/ncp_conn.c In file included from /home/src/sys/netncp/ncp_conn.c:46: /home/src/sys/netncp/ncp_conn.h:174: field `nc_lock' has incomplete type /home/src/sys/netncp/ncp_conn.h:193: confused by earlier errors, bailing out *** Error code 1 I guess struct lock can't be found. I hope someone can do something with this. HTH, Martijn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PANIC: Most recently used by bus
Hi,
I've got a panic by unplugging my NIC then plugging it again and then doing
a dhclient interface. I've attached some informations about the panic.
-- Aurélien
Script started on Tue Nov 26 20:17:13 2002
[m[27m[Jnebula# [K[47C/sys/i386/compile/NEBULA[71Dggdb -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) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /boot/kernel/kernel
(kgdb) core-file /var/crash/vmcore.0
panic: from debugger
panic messages:
---
panic: Most recently used by bus
panic: from debugger
Uptime: 2h0m15s
Dumping 123 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc0216bfe in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc0216e43 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc013bed2 in db_panic () at ../../../ddb/db_command.c:450
#4 0xc013be52 in db_command (last_cmdp=0xc039cee0, cmd_table=0x0,
aux_cmd_tablep=0xc0397a0c, aux_cmd_tablep_end=0xc0397a10)
at ../../../ddb/db_command.c:346
#5 0xc013bf66 in db_command_loop () at ../../../ddb/db_command.c:472
#6 0xc013ebfa in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc032eed2 in kdb_trap (type=3, code=0, regs=0xc9077910)
at ../../../i386/i386/db_interface.c:166
#8 0xc033fabf in trap (frame=
{tf_fs = -1061945320, tf_es = -922288112, tf_ds = -1071644656, tf_edi =
-1045057088, tf_esi = 256, tf_ebp = -922257060, tf_isp = -922257092, tf_ebx = 0,
tf_edx = 0, tf_ecx = 3840, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip =
-1070403212, tf_cs = 8, tf_eflags = 658, tf_esp = -1070001757, tf_ss = -1070110374})
at ../../../i386/i386/trap.c:603
#9 0xc03306a8 in calltrap () at {standard input}:98
#10 0xc0216e2b in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:503
#11 0xc0311c4d in mtrash_ctor (mem=0xc1820800, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:138
#12 0xc0310667 in uma_zalloc_arg (zone=0xc0b4c3c0, udata=0x0, flags=0)
at ../../../vm/uma_core.c:1358
#13 0xc020b626 in malloc (size=6, type=0xc03c14e0, flags=0)
---Type return to continue, or q return to quit---
at ../../../kern/kern_malloc.c:182
#14 0xc01f1b73 in exec_elf32_imgact (imgp=0xc9077b88) at imgact_elf.c:804
#15 0xc01feae2 in kern_execve (td=0xc1b5b1c0, fname=---Can't read userspace from dump,
or kernel process---
)
at ../../../kern/kern_exec.c:313
#16 0xc01ff570 in execve (td=0x0, uap=0x0) at ../../../kern/kern_exec.c:694
#17 0xc034039e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135274340, tf_esi = 135274500,
tf_ebp = -1077938104, tf_isp = -922256012, tf_ebx = 0, tf_edx = 135274500, tf_ecx =
135274500, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134723367, tf_cs = 31,
tf_eflags = 646, tf_esp = -1077938132, tf_ss = 47})
at ../../../i386/i386/trap.c:1033
#18 0xc03306fd in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) frame 11
#11 0xc0311c4d in mtrash_ctor (mem=0xc1820800, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:138
138 panic(Most recently used by %s\n, (*ksp == NULL)?
(kgdb) list
133
134 for (p = mem; cnt 0; cnt--, p++)
135 if (*p != uma_junk) {
136 printf(Memory modified after free %p(%d)\n,
137 mem, size);
138 panic(Most recently used by %s\n, (*ksp == NULL)?
139 none : (*ksp)-ks_shortdesc);
140 }
141 }
142
(kgdb) p p
$1 = (u_int32_t *) 0x0
(kgdb) p uma_junk
$2 = 3735929054
(kgdb) quit
[m[27m[Jnebula# [K[47C/sys/i386/compile/NEBULA[71Deexit
Script done on Tue Nov 26 20:18:30 2002
msg47532/pgp0.pgp
Description: PGP signature
RE: [acpi-jp 1982] Re: Call for testers: acpica-unix-20021118.tar.gz
You'll need to enable the ACPI debug output and send this out so we can get a better idea of what is going on. Thanks, Bob -Original Message- From: Matthew Emmerton [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 5:54 AM To: [EMAIL PROTECTED]; Mitsuru IWASAKI Cc: [EMAIL PROTECTED] Subject: [acpi-jp 1982] Re: Call for testers: acpica-unix-20021118.tar.gz ACPI stiil fails miserably on my Thinkpad T23 with these patches. I've attached the ASL and DSDT data in tar.gz format. Output from boot -v (transcribed by hand, so forgive any obvious typos) Note -- the 'o' character in 'So' below is really o with an umlat. I suspect the space in 'T ' is a non-breaking space as well. acpi0: IBM TP-1A on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GEP31 pci_open(1): mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=35758086) Using $PIR table, 14 entries at 0xc00fdeb0 skipping PCI interrupt list ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name: f0009453 ACPI-0438: *** Error: Looking up [So] in namespace, AE_BAD_CHARACTER ACPI-1287: *** Error: Method execution failed, AE_BAD_CHARACTER ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name: f0009453 ACPI-0438: *** Error: Looking up [So] in namespace, AE_BAD_CHARACTER ACPI-1287: *** Error: Method execution failed, AE_BAD_CHARACTER ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name: f000ff54 ACPI-0438: *** Error: Looking up [T ] in namespace, AE_BAD_CHARACTER repeat last 3 lines 8 times panic: kmem_malloc: entry not found or misaligned Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db show registers .. edx 0x40 ebx 0 ... db trace panic(c03d0e4c,0,c05838c0,1,0) at panic+0xab kmem_malloc(c0832078,1000,1,c058391c,c034c20b) at kmem_malloc+0x33c page_alloc(c083ac80,1000,c058390f,1,780) at page_alloc_0x27 slab_zalloc(c083ac80,1,c4049f6c,c4049f40,63) at slab_zalloc+0xfb uma_zone_slab(c083ac80,1,15f,c4046400,c083ad68) at uma_zone_slab+0x9e uma_zalloc_bucket(c083ac80,1,c03d2929,57e,c151a380) at uma_zalloc_bucekt+0x16d uma_zalloc_arg(c083ac80,0,1,c151a380,c083ac80) at uma_zalloc_arg+0x2f5 malloc(1c,c0550da0,1,c0583940,c0538538) at malloc+0x76 AcpiOsAllocate(1c,c05839f0,c053a4fc,c054fe24,0) at AcpiOsAllocate+0x21 AcpiUtCallocate(1c,1,c054b483,ff,0) at AcpiUtCallocate+0x48 AcpiUtAcquireFromCache(3,0,100,0,c3fa4000) at AcpiUtAcquireFromCache+0xac AcpiPsAllocOp(0,c4046400,0,c0246966,c3fa41e4) at AcpiPsAllocOp+0x7c AcpiPsParseLoop(c3fa4000,c403b040,c0583b0c,0,0) at AcpiPsParseLoop+0x37e AcpiPsParseAml(c3fa4000,c4040340,c4044700,d7ae2332,2f) at AcpiPsParseAml+0x7c AcpiPsxExecute(c4044700,0,c0583b74,c4044700,c0583bfc) at AcpiPsxExecute+0x12f AcpiNsExecuteControlMethod(c4044700,0,c0583b74,c151a500,0) at AcpiNsExecuteControlMethod+0x5f AcpiNsEvaluateByHandle(c4044700,0,c0583bfc,e,0) at AcpiNsEvalueByHandle+0x92 AcpiNsEvaluateRelative(c4044760,c054b6d3,0,c0583bfc0) at AcpiNsEvaluateRelative+0xde AcpiUtExecute_STA(c4044760,c0583c20,0,0,c0583c30) at AcpiUtExecute_STA+0x31 AcpiNsInitOneDevice(c4044760,2,c0583c84,0,6) at AcpiNsInitOneDevice+0x77 AcpiNsInitializeDevices(0,c0583cdc,c053b42e,0,2) at AcpiNsInitializeDevices+0x53 AcpiInitializeObjects(0,2,c052b930,0,0) at AcpiInitializeObjects+0x14 acpi_attach(c403c200,c4005098,c03e3954,c1503a70,c05500e3) at acpi_attach+0x15e To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1940] Re: ACPI errors and then panic - fixed!
On Thu, 21 Nov 2002, Mitsuru IWASAKI wrote: On Sat, 5 Oct 2002, Mitsuru IWASAKI wrote: From: Nate Lawson [EMAIL PROTECTED] Subject: ACPI errors and then panic Date: Fri, 4 Oct 2002 17:14:31 -0700 (PDT) Message-ID: [EMAIL PROTECTED] My laptop appears to work ok without ACPI but of course I don't get suspend, resume, etc. I have never been able to get ACPI to work with it, including with a -current as of 2 hours ago. If ACPI is enabled, I get a spew of: ACPI-0412 *** Error: NsSearchAndEnter: Bad character in ACPI name and then a panic from acpi_attach. I sent a reply including the requested traces on Oct 25. Do you need any more information? Please try with new ACPI CA patches at: http://people.freebsd.org/~iwasaki/acpi/acpica-20021002-20021118-test20021121.diff Some memory leak releated bugs were fixed, so your problem might be solved by this hopefully. I did try the patch and am happy to report that my laptop boots with acpi enabled. Thank you! Please commit it before 5.0R. However, acpi doesn't seem to be working for me. Calls to check the battery status fail. Here is my dmesg and sysctl: hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: S1 hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 0 hw.acpi.s4bios: 1 hw.acpi.verbose: 1 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 30 hw.acpi.thermal.tz0.temperature: 3252 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3637 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3692 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.battery.life: 98 hw.acpi.battery.time: -1 hw.acpi.battery.state: 4 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 1 --- Copyright (c) 1992-2002 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 #11: Tue Nov 26 10:44:02 PST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LAPTOP Preloaded elf kernel /boot/kernel/kernel at 0xc0562000. Preloaded elf module /boot/kernel/acpi.ko at 0xc05620a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 999153113 Hz CPU: Pentium III/Pentium III Xeon/Celeron (999.15-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 401997824 (383 MB) avail memory = 384696320 (366 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: IBMTP-1Aon motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 Using $PIR table, 14 entries at 0xc00fdeb0 ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST acpi_button0: Sleep Button on acpi0 ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10
panic from acpiconf -s 4
While trying to suspend my IBM T23, I ran into a panic. acpiconf -s for values 1,2,3 does nothing (failing with acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND). But acpiconf -s 4 panics. scsuspend(c3352600,c32cf058,c03f4d6c,c3335d80,0) at scsuspend+0x17 bus_generic_suspend(c3335480,c324d058,c03f4d6c,c3336080,e399b9f0) at bus_generic_suspend+0x5b bus_generic_suspend(c3331200) at bus_generic_suspend+0x5b isab_suspend(c3331200,c3299058,c03f4d6c,c36917c0,0) at isab_suspend+0x5c bus_generic_suspend(c3331080,c32e4058,c03f4d6c,c32eb058,c11d4600) at bus_generic_suspend+0x5b bus_generic_suspend(c11d4580,c32e3058,c03f4d6c,0,0) at bus_generic_suspend+0x5b bus_generic_suspend(c3305280,c32cc058,c03f4d6c,e399bad2,0) at bus_generic_suspend+0x5b bus_generic_suspend(c11d3c00,c32ac058,c03f4d6c,e399baa8,c3324140) at bus_generic_suspend+0x5b bus_generic_suspend(c11d3e80,c11c3058,c03f4d6c,c03cd283,6060668) at bus_generic_suspend+0x5b acpi_SetSleepState(c3305200,4,c35ef000,c36b2940,e399bb5c) at acpi_SetSleepState+0x106 acpiioctl(c0442200,80045003,e399bc54,3,c35ef000) at acpiioctl+0xb2 spec_ioctl(e399bb5c,e399bc28,c02c12f1,e399bb5c,e399bb70) at spec_ioctl+0x16e spec_vnoperate(e399bb5c,e399bb70,c02589bd,c04477e0,c03f43a0) at spec_vnoperate+0x18 vn_ioctl(c3420d20,80045003,e399bc54,c36aed00,c35ef000) at vn_ioctl+0x1a1 ioctl(c35ef000,e399bd10,c03ebece,407,3) at ioctl+0x4b6 syscall(2f,2f,2f,4,3) at syscall+0x28e Perhaps I should try SC_NO_SUSPEND_VTYSWITCH ? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACLs on the boot partition?
On Tue, 26 Nov 2002, Hiten Pandya wrote: On Tue, Nov 26, 2002 at 11:21:28AM -0700, [EMAIL PROTECTED] wrote the words in effect of: On Tue, 26 Nov 2002, Bruno Miguel wrote: On 25 Nov 2002 at 23:34, [EMAIL PROTECTED] wrote... How do I enable ACLs on the boot partition? tunefs -a enable /dev/ad0s1a indicates it got set (in single user mode with / mounted readonly). But I still can't set anything with setfacl(1). I tried booting to the fixit floppy, hoping to set acls flag from there to my partition, but it doesn't have tunefs. Is my only choice now to take the drive out and put it in another FreeBSD machine and set it from there? If you are using UFS1, did you follow the procedures in /sys/ufs/ufs/README.acls ? No, not using USF1. / was formatted UFS2. tunefs -a /your/filesystem I think thats the one. Cheers. Tried that already on / in single user mode with it mounted readonly. tunefs said it changed the flag, but didn't really. I also tried adding acls to fstab for /, but no effect. Were you successful in doing this for / ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Searching for users of netncp and nwfs to help debug 5.0 problems
On Tue, Nov 26, 2002 at 08:10:50PM +0100, Martijn Pronk wrote the words in effect of: Martijn Pronk wrote: Robert Watson wrote: The build of netncp is currently broken on 5.0-CURRENT, and I'd like to see this fixed before 5.0-RELEASE. Unfortunately, we're having a lot of trouble finding a test environment, which is the natural and immediate follow-on to the compile fixes :-). Was wondering if anyone with FreeBSD kernel debugging experience and some time on their hands was interested in helping resolve this issue over the next week or two. I can test this next week at work, however, I don't normally use netncp nwfs, so it may take me a while. I'll get back on this next week. In file included from /home/src/sys/netncp/ncp_conn.c:46: /home/src/sys/netncp/ncp_conn.h:174: field `nc_lock' has incomplete type /home/src/sys/netncp/ncp_conn.h:193: confused by earlier errors, bailing out *** Error code 1 I guess struct lock can't be found. I hope someone can do something with this. Once you change the sys/lock.h line in ncp_conn.h to sys/lockmgr.h, you will see a lot of struct proc related errors springing up. The motto of this message is, that fixing that line will not make it compile. We need to make sys/netncp use struct thread instead of struct proc. This is easy in some parts of the code, and on some its just a little tricky, but not hard. Somebody did update the prototypes to netncp, but forgot to change the logic, for lockmgr calls, example, its last argument is a struct thread etc. I was going to work on this task at one point in time, but now that my school exam timetable has changed, I will not be able to do it; for the next 2/3 months anyway. If someone wants to give a go at this task, then they are most welcome to take my place. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: jdk 1.3.1_6 linux compilation.
Daniel Flickinger wrote: I just brought up ooo-1.0.l without the java. I had IBM's latest and greatest Linux-java, but it did not want to recognize it so I left the box checked for no java in setup. Everything runs as advertised on openoffice --it looks good. I tried a few files on it, etc. I have no use for java. I tried to disable the address book function but ended up leaving it tied to Mozilla. FYR: CURRENT-5.0 dated 1200 GMT 25 Nov 2002 with /proc ooo from package on projects.oopenoffice.org, less than an hour from start to usable. Yes thanks for the info. However I wen't the source way, since I could copy the basic huge source files over from my existing respositories on Linux. This saved me quite a lot of badwidth... Another question - why does the bootstrapping of java do require gtk+ and glib? AWT is based on Motif. Argh... Linux distro package dependency disease appears all over again here. Somone writes some useless language wrapper for a lib or a plugin interface for a scripting language used by maybe two people of the world (very likely perl python or ruby preferable multiple different releases of them) and I have to start to waste kBytes on stuff I never had any use for... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: mtx_lock() of spin mutex
John Baldwin wrote:
On 18-Oct-2002 Lars Eggert wrote:
John Baldwin wrote:
What is line 488 of src/sys/kern/kern_descrip.c?
fhold(fp) in do_dup().
Still see this issue on today's -current. It's easily reproducible with
a simple cd ~sunhee in a tcsh, where ~sunhee is on NFS:
panic: mtx_lock() of spin mutex D\^QR\M-@\M-TR\M-@ \M^UV\M-@\^D @
/usr/src/sys/kern/kern_descrip.c:485
cpuid = 1; lapic.id = 0200
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 2m28s
pfs_vncache_unload(): 3 entries remaining
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:233
233 dumpsys(dumper);
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:233
#1 0xc02c737e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc02c7977 in panic (fmt=0xc0466524 from debugger)
at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc01533d2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc015320c in db_command (last_cmdp=0xc04d78a0, cmd_table=0x0,
aux_cmd_tablep=0xc04cede0, aux_cmd_tablep_end=0xc04cede4)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc015344a in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc01560e5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc0426547 in kdb_trap (type=3, code=0, regs=0xe0b40be8)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc043e63d in trap (frame=
{tf_fs = 24, tf_es = -1068957680, tf_ds = 16, tf_edi =
-972412288, tf_esi = 256, tf_ebp = -525071308, tf_isp = -525071340,
tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err =
0, tf_eip = -1069389686, tf_cs = 8, tf_eflags = 642, tf_esp =
-1068771002, tf_ss = -1068921887})
at /usr/src/sys/i386/i386/trap.c:603
#9 0xc0427d18 in calltrap () at {standard input}:99
#10 0xc02c795f in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc02bda97 in _mtx_lock_flags (m=0xc0521154, opts=0,
file=0xc0495d47 /usr/src/sys/kern/kern_descrip.c, line=485)
at /usr/src/sys/kern/kern_mutex.c:325
#12 0xc02a93e6 in do_dup (td=0xc60a2a80, type=DUP_FIXED, old=-1, new=4,
retval=0xc60a2b18) at /usr/src/sys/kern/kern_descrip.c:485
#13 0xc02a8643 in dup2 (td=0x0, uap=0x0)
at /usr/src/sys/kern/kern_descrip.c:174
#14 0xc043f2c6 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 4, tf_esi
= 135641600, tf_ebp = -1078050424, tf_isp = -525070988, tf_ebx = -1,
tf_edx = -1078051696, tf_ecx = 135671808, tf_eax = 90, tf_trapno = 12,
tf_err = 2, tf_eip = 134843455, tf_cs = 31, tf_eflags = 646, tf_esp =
-1078051652, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#15 0xc0427d6d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
(kgdb) up 12
(kgdb) list
480 *retval = new;
481 FILEDESC_UNLOCK(fdp);
482 return (0);
483 }
484 fp = fdp-fd_ofiles[old];
485 fhold(fp);
486
487 /*
488 * Expand the table for the new descriptor if needed. This may
489 * block and drop and reacquire the filedesc lock.
The console log has some additional messages anout mutexes, interrupts,
before it spirals down an endless loop of xlock already held messages:
panic: mtx_lock() of spin mutex D^QR@TR@ ^UV@^D @
/usr/src/sys/kern/kern_descrip.c:485
cpuid = 1; lapic.id = 0200
Debugger(panic)
Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0
db trace
Debugger(c0498be1,200,c0497e25,e0b40c70,1) at Debugger+0x5a
panic(c0497e25,c0520f94,c0495d47,1e5,e0b40cb4) at panic+0x12f
_mtx_lock_flags(c0521154,0,c0495d47,1e5,c7078500) at _mtx_lock_flags+0xa7
do_dup(c60a2a80,1,,4,c60a2b18) at do_dup+0xe6
dup2(c60a2a80,e0b40d10,c04bff99,407,c65db418) at dup2+0x33
syscall(2f,2f,bfbf002f,4,815ba00) at syscall+0x3c6
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (90, FreeBSD ELF32, dup2), eip = 0x8098c3f, esp =
0xbfbe3cbc, ebp = 0xbfbe4188 ---
db panic
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 2m28s
pfs_vncache_unload(): 3 entries remaining
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008
Dump complete
Terminate ACPI
panic: absolutely cannot call smp_ipi_shootdown with interrupts already
disabled
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 2m28s
mpt0: soft reset failed: device not running
mpt1: soft reset failed: device not running
pfs_vncache_unload(): 3 entries remaining
panic: witness_destroy: lock (sleep mutex) pseudofs_vncache is not
initialized
cpuid = 1; lapic.id = 0200
Re: Searching for users of netncp and nwfs to help debug 5.0 problems
On Tue, 26 Nov 2002, Hiten Pandya wrote: On Tue, Nov 26, 2002 at 08:10:50PM +0100, Martijn Pronk wrote the words in effect of: In file included from /home/src/sys/netncp/ncp_conn.c:46: /home/src/sys/netncp/ncp_conn.h:174: field `nc_lock' has incomplete type /home/src/sys/netncp/ncp_conn.h:193: confused by earlier errors, bailing out *** Error code 1 I guess struct lock can't be found. I hope someone can do something with this. Once you change the sys/lock.h line in ncp_conn.h to sys/lockmgr.h, you will see a lot of struct proc related errors springing up. The motto of this message is, that fixing that line will not make it compile. We need to make sys/netncp use struct thread instead of struct proc. This is easy in some parts of the code, and on some its just a little tricky, but not hard. Somebody did update the prototypes to netncp, but forgot to change the logic, for lockmgr calls, example, its last argument is a struct thread etc. I was going to work on this task at one point in time, but now that my school exam timetable has changed, I will not be able to do it; for the next 2/3 months anyway. If someone wants to give a go at this task, then they are most welcome to take my place. I thought Julian volunteered to do this a while back. If he is not, I can pick this up and make it compile but I have no equipment to test it on. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sk (miibus) driver won't attach
On Mon, 25 Nov 2002, Robert Faulds wrote: I have a Tyan K7 dual AMD MP200+ system running CURRENT and can not get my SysKonnect 9843 GigE to work. I've tried several different methods of loading the driver (static in the kernel, loaded from /boot/loader.conf, and kldload after booting to multiuser, all with the same result: No miibus attach. miibus is loaded from /boot/loader.conf, but I've also tried building it static into the kernel. coraegis1# kldload if_sk skc0: SysKonnect Gigabit Ethernet port 0x1400-0x14ff mem 0xf400-0xf4003fff irq 3 at device 12.0 on pci0 skc0: SysKonnect SK-NET Gigabit Ethernet Adapter SK-9843 SX sk0: XaQti Corp. XMAC II on skc0 sk0: Ethernet address: 00:00:5a:99:1c:6c skc0: no PHY found! device_probe_and_attach: sk0 attach returned 6 Which PHY do you have attached to yours? We have a huge stack of 9843 SXs here and on the back side is an AMD chip labelled GigaPHY, part number Am79761YC-14. I wouldn't be suprised if syskonnect changed the PHY and we need to code up a driver for it. I can test this in a -current vs. -stable box to confirm your findings if you like. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Searching for users of netncp and nwfs to help debug 5.0 problems
Nate Lawson wrote: On Tue, 26 Nov 2002, Hiten Pandya wrote: On Tue, Nov 26, 2002 at 08:10:50PM +0100, Martijn Pronk wrote the words in effect of: In file included from /home/src/sys/netncp/ncp_conn.c:46: /home/src/sys/netncp/ncp_conn.h:174: field `nc_lock' has incomplete type /home/src/sys/netncp/ncp_conn.h:193: confused by earlier errors, bailing out *** Error code 1 I guess struct lock can't be found. I hope someone can do something with this. Once you change the sys/lock.h line in ncp_conn.h to sys/lockmgr.h, you will see a lot of struct proc related errors springing up. The motto of this message is, that fixing that line will not make it compile. We need to make sys/netncp use struct thread instead of struct proc. This is easy in some parts of the code, and on some its just a little tricky, but not hard. Somebody did update the prototypes to netncp, but forgot to change the logic, for lockmgr calls, example, its last argument is a struct thread etc. I was going to work on this task at one point in time, but now that my school exam timetable has changed, I will not be able to do it; for the next 2/3 months anyway. If someone wants to give a go at this task, then they are most welcome to take my place. I thought Julian volunteered to do this a while back. If he is not, I can pick this up and make it compile but I have no equipment to test it on. If you can at least make it compile then I can test it at my work. Can you tell me when you're done? Martijn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Searching for users of netncp and nwfs to help debug 5.0 problems
On Tue, 26 Nov 2002, Nate Lawson wrote: On Tue, 26 Nov 2002, Hiten Pandya wrote: On Tue, Nov 26, 2002 at 08:10:50PM +0100, Martijn Pronk wrote the words in effect of: In file included from /home/src/sys/netncp/ncp_conn.c:46: /home/src/sys/netncp/ncp_conn.h:174: field `nc_lock' has incomplete type /home/src/sys/netncp/ncp_conn.h:193: confused by earlier errors, bailing out *** Error code 1 I guess struct lock can't be found. I hope someone can do something with this. Once you change the sys/lock.h line in ncp_conn.h to sys/lockmgr.h, you will see a lot of struct proc related errors springing up. The motto of this message is, that fixing that line will not make it compile. We need to make sys/netncp use struct thread instead of struct proc. This is easy in some parts of the code, and on some its just a little tricky, but not hard. Somebody did update the prototypes to netncp, but forgot to change the logic, for lockmgr calls, example, its last argument is a struct thread etc. I was going to work on this task at one point in time, but now that my school exam timetable has changed, I will not be able to do it; for the next 2/3 months anyway. If someone wants to give a go at this task, then they are most welcome to take my place. I thought Julian volunteered to do this a while back. If he is not, I can pick this up and make it compile but I have no equipment to test it on. It's not so much that I volunteered as I said that I'd help with thread/proc issues.. The trouble was that there are places where it used a proc in the old code, but in some cases it needs to be a proc, and in other cases it now needs to be a thread. But all they stored was the proc. Also, from my memories of the code you needed to understand the protocol to know which needed to be which, and I don't know that protocol. In addition whoever does it needs to remember that any structure that stores a thread poitner is probably in error, as threads are transient items and any stored thread pointer is probably a wild pointer within a few milliseconds of being stored. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH - changing libc_r to use *context()
On Tue, 26 Nov 2002, Marc Recht wrote:
I'd like some feedback on whether some heavy threaded apps (GNOME,
OpenOffice, Java, etc) have any problems with this patch before
asking re@ for commit permission. BTW, it also needs testing on
alpha.
I tried it on i386 (athon-xp) and every app I've tried stalled/locked or
crashed right away. Mozilla gives me:
The program 'unknown' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 4773 error_code 2 request_code 53 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Damn, I think I found a problem. Perhaps it might be what's
causing your problem. Do you have I686_CPU defined in
your kernel? If so can you either try it with a kernel
without I686_CPU or with CPU_DISABLE_SSE?
The kernel doesn't align the FPU registers (context) properly.
Actually, neither does anything in userland because the
machine contexts lack align directives.
You can also try modifying the patched uthread_kern.c,
function _thread_kern_sched(). There's a section about
halfway down that looks something like this:
/*
* Return to the interrupted context. We are careful
* not to use the context saved in the thread because
* we may have been interrupted by another signal which
* would have destroyed it. This context is saved by
* the kernel on the thread's stack so it is safe from
* nested signals.
*/
ucp-uc_sigmask = _process_sigmask;
THR_SETCONTEXT(ucp);
PANIC(Resume from setcontext in _thread_kern_sched);
}
else {
do {
Change the THR_SETCONTEXT(ucp) to sigreturn(ucp).
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sk (miibus) driver won't attach
=coraegis1# kldload if_sk =skc0: SysKonnect Gigabit Ethernet port 0x1400-0x14ff mem =0xf400-0xf4003fff = irq 3 at device 12.0 on pci0 =skc0: SysKonnect SK-NET Gigabit Ethernet Adapter SK-9843 SX =sk0: XaQti Corp. XMAC II on skc0 =sk0: Ethernet address: 00:00:5a:99:1c:6c =skc0: no PHY found! =device_probe_and_attach: sk0 attach returned 6 = = Which PHY do you have attached to yours? = = We have a huge stack of 9843 SXs here and on the back side is an AMD chip = labelled GigaPHY, part number Am79761YC-14. I wouldn't be suprised if = syskonnect changed the PHY and we need to code up a driver for it. = = I can test this in a -current vs. -stable box to confirm your findings if = you like. I have the same PHY chip. I followed-up to this post after I saw the same message as Andy Farkas had on his dc(4) driver. /usr/src/sys/vm/uma_core.c:1330: could sleep with skc0 locked from /usr/src/sys/pci/if_sk.c:1049 Current, as of this morning, panics if I kldload if_sk. The machine is not local to me but I'm making arrangements to get a console on the box. I have not tried with a UP kernel on 5.0 but the 4.7 kernel I tested with is not SMP. Robert -- [EMAIL PROTECTED] 39:FF:7C:52:66:9D:B9:A3 EA:67:3C:7F:D1:B6:30:36 Double-Blind Experiment, n.: An experiment in which the chief researcher believes he is fooling both the subject and the lab assistant. Often accompanied by a belief in the tooth fairy. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: mtx_lock() of spin mutex
On 26-Nov-2002 Lars Eggert wrote:
John Baldwin wrote:
On 18-Oct-2002 Lars Eggert wrote:
John Baldwin wrote:
What is line 488 of src/sys/kern/kern_descrip.c?
fhold(fp) in do_dup().
Still see this issue on today's -current. It's easily reproducible with
a simple cd ~sunhee in a tcsh, where ~sunhee is on NFS:
panic: mtx_lock() of spin mutex D\^QR\M-@\M-TR\M-@ \M^UV\M-@\^D @
/usr/src/sys/kern/kern_descrip.c:485
cpuid = 1; lapic.id = 0200
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 2m28s
pfs_vncache_unload(): 3 entries remaining
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:233
233 dumpsys(dumper);
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:233
#1 0xc02c737e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc02c7977 in panic (fmt=0xc0466524 from debugger)
at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc01533d2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc015320c in db_command (last_cmdp=0xc04d78a0, cmd_table=0x0,
aux_cmd_tablep=0xc04cede0, aux_cmd_tablep_end=0xc04cede4)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc015344a in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc01560e5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc0426547 in kdb_trap (type=3, code=0, regs=0xe0b40be8)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc043e63d in trap (frame=
{tf_fs = 24, tf_es = -1068957680, tf_ds = 16, tf_edi =
-972412288, tf_esi = 256, tf_ebp = -525071308, tf_isp = -525071340,
tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err =
0, tf_eip = -1069389686, tf_cs = 8, tf_eflags = 642, tf_esp =
-1068771002, tf_ss = -1068921887})
at /usr/src/sys/i386/i386/trap.c:603
#9 0xc0427d18 in calltrap () at {standard input}:99
#10 0xc02c795f in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc02bda97 in _mtx_lock_flags (m=0xc0521154, opts=0,
file=0xc0495d47 /usr/src/sys/kern/kern_descrip.c, line=485)
at /usr/src/sys/kern/kern_mutex.c:325
#12 0xc02a93e6 in do_dup (td=0xc60a2a80, type=DUP_FIXED, old=-1, new=4,
retval=0xc60a2b18) at /usr/src/sys/kern/kern_descrip.c:485
Hmm, old = -1, this might be fixed by a patch I committed today to fix
bugs in do_dup(). Please try revision 1.169 of kern_descrip.c and let
me know if it is still broken. Thanks.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
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: ACLs on the boot partition?
On Tue, 26 Nov 2002 [EMAIL PROTECTED] wrote: On Tue, 26 Nov 2002, Hiten Pandya wrote: On Tue, Nov 26, 2002 at 11:21:28AM -0700, [EMAIL PROTECTED] wrote the words in effect of: On Tue, 26 Nov 2002, Bruno Miguel wrote: On 25 Nov 2002 at 23:34, [EMAIL PROTECTED] wrote... How do I enable ACLs on the boot partition? tunefs -a enable /dev/ad0s1a indicates it got set (in single user mode with / mounted readonly). But I still can't set anything with setfacl(1). I tried booting to the fixit floppy, hoping to set acls flag from there to my partition, but it doesn't have tunefs. Is my only choice now to take the drive out and put it in another FreeBSD machine and set it from there? If you are using UFS1, did you follow the procedures in /sys/ufs/ufs/README.acls ? No, not using USF1. / was formatted UFS2. tunefs -a /your/filesystem I think thats the one. Cheers. Tried that already on / in single user mode with it mounted readonly. tunefs said it changed the flag, but didn't really. I also tried adding acls to fstab for /, but no effect. Were you successful in doing this for / ? tunefs changes the flag for the next mount, so doesn't take immediate effect. Once you've tunefs'd a read-only file system, you need to unmount and remount it -- for the file system root, this generally means rebooting. Just to confirm: you're running with GENERIC, or with a kernel that includes UFS_ACL, right? (Normally the kernel will complain if you try to mount a file system with ACL support when ACLs aren't enabled). 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
rc_ng breakage introduced with src/etc/rc.d/Makefile 1.5
Hello. In the revision 1.5 of src/etc/rc.d/Makefile Gordon introduces the following breakage into rc_ng scripts (didn't find it early, because installed boxes works as expected and the bug introduce itself a) only with a new installations; b) when rcorder run manually) root@girvas-gw:/etc/rc.d# rcorder -k FreeBSD -s nostart * /dev/null rcorder: requirement `ppp' in file `rpcbind' has no providers. rcorder: requirement `beforenetlkm' in file `ipsec' has no providers. rcorder: requirement `beforenetlkm' in file `ipfilter' has no providers. rcorder: requirement `altqd' in file `NETWORKING' has no providers. rcorder: requirement `dhclient' in file `NETWORKING' has no providers. rcorder: requirement `network' in file `NETWORKING' has no providers. rcorder: requirement `wscons' in file `syslogd' has no providers. rcorder: requirement `sysdb' in file `syslogd' has no providers. rcorder: requirement `mountall' in file `accounting' has no providers. rcorder: requirement `mountall' in file `amd' has no providers. rcorder: requirement `mountall' in file `cleartmp' has no providers. rcorder: requirement `mountall' in file `ldconfig' has no providers. rcorder: requirement `beforemountlkm' in file `mountd' has no providers. rcorder: requirement `mountall' in file `mountd' has no providers. rcorder: requirement `aftermountlkm' in file `securelevel' has no providers. Another one found - Once you install /usr/ports/net/bind9-dlz WITH_OPENSSL=yes it can not start, because /etc/rc.d/ldconfig seed /var/run/ld-elf.so.hints later and /usr/local/sbin/named depends on the libraries in /usr/local/lib # ldd /usr/local/sbin/named /usr/local/sbin/named: libcrypto.so.3 = /usr/local/lib/libcrypto.so.3 (0x281aa000) libmysqlclient.so.10 = /usr/local/lib/mysql/libmysqlclient.so.10 (0x28272000) libz.so.2 = /usr/lib/libz.so.2 (0x2829) libcrypt.so.2 = /usr/lib/libcrypt.so.2 (0x2829e000) libm.so.2 = /usr/lib/libm.so.2 (0x282b7000) libc_r.so.5 = /usr/lib/libc_r.so.5 (0x282d5000) libc.so.5 = /usr/lib/libc.so.5 (0x282f8000) As a quick fix I've added ldconfig as a dependancy to /etc/rc.d/SERVERS, but I'm not sure if it breaks something in diskless environments. I could not find a PR on this. Should I fill one? Sincerely yours, Sergey Mokryshev. -- Sergey S. Mokryshev [EMAIL PROTECTED] SMP453, MOKR-RIPN To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sound problems
Hello there, I have -CURRENT from Saturday on my box. I have SB 128PCI on my board, the module detects it without problems and seems to work fine. But the problem is that the sound is not clear; there happen to be some itchy noises from time to time, when I push up the system load. I wonder whether enlarging the sound buffer woul help, yet hw.snd.pcm0.buffersize is read-only, even setting it in /boot/loader.conf does not help. Under -STABLE those ithes never happened, so I don't think it's a hw issue. Here's my dmesg output, with some irrelevant (IMHO) stuff removed: Copyright (c) 1992-2002 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 #2: Sun Nov 24 23:36:06 CET 2002 root@stronghold:/usr/obj/usr/src/sys/MOONDANCE5 Preloaded elf kernel /boot/kernel/kernel at 0xc04e4000. Preloaded elf module /boot/kernel/mga.ko at 0xc04e4204. Preloaded elf module /boot/kernel/acpi.ko at 0xc04e42ac. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 600026288 Hz CPU: AMD Duron(tm) Processor (600.03-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x630 Stepping = 0 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 536805376 (511 MB) avail memory = 515969024 (492 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard Using $PIR table, 7 entries at 0xc00fdd00 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 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 initial configuration [.. here comes the irqs output and stuff ..] pci0: ACPI PCI bus on pcib0 agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xd500-0xd53f at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 drm0: Matrox G400/G450 (AGP) mem 0xd300-0xd37f,0xd200-0xd2003fff,0xd000-0xd1ff irq 10 at device 0.0 on pci1 info: [drm] AGP at 0xd500 4MB info: [drm] Initialized mga 3.0.2 20010321 on minor 0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pcm0: Creative CT5880-C port 0xdc00-0xdc3f irq 5 at device 9.0 on pci0 rl0: RealTek 8139 10/100BaseTX port 0xe000-0xe0ff mem 0xd540-0xd54000ff irq 11 at device 10.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:e0:7d:b4:33:16 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto [.. floppy, serial/parallel ports, keyboard, PS/2 mouse ..] pmtimer0 on isa0 orm0: Option ROM at iomem 0xc-0xc87ff on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 [.. and ATA drives ..] -- -- wrzask --= v =-- Winfried --=-- GG# 3838383 --=-- JS500-RIPE -- -- [EMAIL PROTECTED] --- [EMAIL PROTECTED] --===-- http://violent.dream.vg/ --- --= Ride the wild wind - push the envelope, don't sit on the fence, --- -- Ride the wild wind - live life on the razor's edge! =-- Queen -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rc_ng breakage introduced with src/etc/rc.d/Makefile 1.5
These are benign. Those scripts are used by NetBSD only. You don't see the errors on boot because of a 2/dev/null in /etc/rc. Cheers. -- Mike Makonnen [EMAIL PROTECTED] GPG Key-ID: 0xDBCC68B9 GPG-KEY: http://www.identd.net/~mtm/mtm.asc Key fingerprint = D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg47550/pgp0.pgp Description: PGP signature
Re: panic: mtx_lock() of spin mutex
John, John Baldwin wrote: On 26-Nov-2002 Lars Eggert wrote: #12 0xc02a93e6 in do_dup (td=0xc60a2a80, type=DUP_FIXED, old=-1, new=4, retval=0xc60a2b18) at /usr/src/sys/kern/kern_descrip.c:485 Hmm, old = -1, this might be fixed by a patch I committed today to fix bugs in do_dup(). Please try revision 1.169 of kern_descrip.c and let me know if it is still broken. Thanks. looks good, can't reproduce the panic anymore. Will keep an eye out for it in the future. Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: src/sys/dev/sound/isa ad1816.c mss.c sbc.c src/sys/dev/sound/pci aureal.c cmi.c ds1.c emu10k1.c maestro.c t4dwave.c src/sys/dev/sound/pcm ac97.c channel.h mixer.c sound.c
On Tue, Nov 26, 2002 at 10:16:28AM -0800, Cameron Grant wrote: cg 2002/11/26 10:16:28 PST Modified files: sys/dev/sound/isaad1816.c mss.c sbc.c sys/dev/sound/pciaureal.c cmi.c ds1.c emu10k1.c maestro.c t4dwave.c sys/dev/sound/pcmac97.c channel.h mixer.c sound.c Log: (hopefully) fix build breakage some people are seeing This fixed it, thanks! -- Ray Kohler [EMAIL PROTECTED] Jesus Saves, Moses Invests, But only Buddha pays Dividends. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rc_ng breakage introduced with src/etc/rc.d/Makefile 1.5
On Tue, 26 Nov 2002, Mike Makonnen wrote: These are benign. Those scripts are used by NetBSD only. You don't see the errors on boot because of a 2/dev/null in /etc/rc. Cheers. Yes, I don't see these errors. But some scripts can change execution order without anchors like mountall For example, adding ldconfig dependancy directly into named brings this order: root@girvas-gw:/etc/rc.d# rcorder -k FreeBSD -s nostart * 2/dev/null ldconfig initdiskless initrandom dumpon vinum Isn't this wrong? Sergey -- Sergey S. Mokryshev [EMAIL PROTECTED] SMP453, MOKR-RIPN To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Searching for users of netncp and nwfs to help debug 5.0 problems
On Tue, 26 Nov 2002, Julian Elischer wrote: On Tue, 26 Nov 2002, Nate Lawson wrote: On Tue, 26 Nov 2002, Hiten Pandya wrote: On Tue, Nov 26, 2002 at 08:10:50PM +0100, Martijn Pronk wrote the words in effect of: In file included from /home/src/sys/netncp/ncp_conn.c:46: /home/src/sys/netncp/ncp_conn.h:174: field `nc_lock' has incomplete type /home/src/sys/netncp/ncp_conn.h:193: confused by earlier errors, bailing out *** Error code 1 I guess struct lock can't be found. I hope someone can do something with this. Once you change the sys/lock.h line in ncp_conn.h to sys/lockmgr.h, you will see a lot of struct proc related errors springing up. The motto of this message is, that fixing that line will not make it compile. We need to make sys/netncp use struct thread instead of struct proc. This is easy in some parts of the code, and on some its just a little tricky, but not hard. Somebody did update the prototypes to netncp, but forgot to change the logic, for lockmgr calls, example, its last argument is a struct thread etc. I was going to work on this task at one point in time, but now that my school exam timetable has changed, I will not be able to do it; for the next 2/3 months anyway. If someone wants to give a go at this task, then they are most welcome to take my place. I thought Julian volunteered to do this a while back. If he is not, I can pick this up and make it compile but I have no equipment to test it on. It's not so much that I volunteered as I said that I'd help with thread/proc issues.. The trouble was that there are places where it used a proc in the old code, but in some cases it needs to be a proc, and in other cases it now needs to be a thread. But all they stored was the proc. Also, from my memories of the code you needed to understand the protocol to know which needed to be which, and I don't know that protocol. In addition whoever does it needs to remember that any structure that stores a thread poitner is probably in error, as threads are transient items and any stored thread pointer is probably a wild pointer within a few milliseconds of being stored. :-) I'll take a whack at it and send it out by tomorrow, working or not. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Searching for users of netncp and nwfs to help debug 5.0 problems
On Tue, Nov 26, 2002 at 01:10:45PM -0800, Julian Elischer wrote the words in effect of: On Tue, 26 Nov 2002, Nate Lawson wrote: On Tue, 26 Nov 2002, Hiten Pandya wrote: On Tue, Nov 26, 2002 at 08:10:50PM +0100, Martijn Pronk wrote the words in effect of: In file included from /home/src/sys/netncp/ncp_conn.c:46: /home/src/sys/netncp/ncp_conn.h:174: field `nc_lock' has incomplete type /home/src/sys/netncp/ncp_conn.h:193: confused by earlier errors, bailing out *** Error code 1 I guess struct lock can't be found. I hope someone can do something with this. Once you change the sys/lock.h line in ncp_conn.h to sys/lockmgr.h, you will see a lot of struct proc related errors springing up. The motto of this message is, that fixing that line will not make it compile. We need to make sys/netncp use struct thread instead of struct proc. This is easy in some parts of the code, and on some its just a little tricky, but not hard. Somebody did update the prototypes to netncp, but forgot to change the logic, for lockmgr calls, example, its last argument is a struct thread etc. I was going to work on this task at one point in time, but now that my school exam timetable has changed, I will not be able to do it; for the next 2/3 months anyway. If someone wants to give a go at this task, then they are most welcome to take my place. I thought Julian volunteered to do this a while back. If he is not, I can pick this up and make it compile but I have no equipment to test it on. It's not so much that I volunteered as I said that I'd help with thread/proc issues.. The trouble was that there are places where it used a proc in the old code, but in some cases it needs to be a proc, and in other cases it now needs to be a thread. But all they stored was the proc. Also, from my memories of the code you needed to understand the protocol to know which needed to be which, and I don't know that protocol. In addition whoever does it needs to remember that any structure that stores a thread poitner is probably in error, as threads are transient items and any stored thread pointer is probably a wild pointer within a few milliseconds of being stored. :-) Changes in ncp_conn.[ch] do not require a lot of netncp-foo. But other modules like ncp_ncp.[ch] might do. Julian's KSE Milestone 2 commit _did_ touch ncp_conn.h and ncp_rq.h. FWIW, some of the code in netncp does not even need a struct proc, but its just there, for some reason. If no one picks this task up, I will eventually get back to it, but not in the next 3/4 weeks or so. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH - changing libc_r to use *context()
Damn, I think I found a problem. Perhaps it might be what's causing your problem. Do you have I686_CPU defined in your kernel? If so can you either try it with a kernel without I686_CPU or with CPU_DISABLE_SSE? Yes, I've I686_CPU and CPU_ENABLE_SSE in my kernel. Trying it without could take a while, because everything is also compiled with -march=athlon-xp.. The kernel doesn't align the FPU registers (context) properly. Actually, neither does anything in userland because the machine contexts lack align directives. You can also try modifying the patched uthread_kern.c, function _thread_kern_sched(). There's a section about halfway down that looks something like this: [..patch] That didn't work (no difference). Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] Searching for users of netncp and nwfs to help debug 5.0 problems
Nate Lawson wrote: It's not so much that I volunteered as I said that I'd help with thread/proc issues.. The trouble was that there are places where it used a proc in the old code, but in some cases it needs to be a proc, and in other cases it now needs to be a thread. But all they stored was the proc. Also, from my memories of the code you needed to understand the protocol to know which needed to be which, and I don't know that protocol. In addition whoever does it needs to remember that any structure that stores a thread poitner is probably in error, as threads are transient items and any stored thread pointer is probably a wild pointer within a few milliseconds of being stored. :-) I'll take a whack at it and send it out by tomorrow, working or not. Don't bother. 8-). The attached patch makes it compile, and takes a shot at doing the right thing. The threasd stuff is problematic; it's useful only for a blocking context. The process stuff is there to identify the connection, actually, which can mean huge latencies (hence the caching of procp). It helps to know that the protocol is exclusively request/response per session, the current code handles only a single session per process (not one per thread), and that lock requests are answered bith synchronously and asynchronously (request/response, then async message on timeout or success). -- Terry smbfs_thr.diff.gz Description: GNU Zip compressed data
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Nov 26 15:06:54 PST 2002 -- Kernel build for GENERIC completed on Tue Nov 26 15:41:38 PST 2002 -- Kernel build for LINT started on Tue Nov 26 15:41:39 PST 2002 -- === vinum Makefile, line 4450: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/isp/isp_pci.c: In function `tdma_mkfc': /h/des/src/sys/dev/isp/isp_pci.c:1543: warning: unsigned int format, different type arg (arg 5) /h/des/src/sys/dev/isp/isp_pci.c:1543: warning: int format, different type arg (arg 6) /h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different type arg (arg 6) /h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different type arg (arg 7) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Searching for users of netncp and nwfs to help debug 5.0 problems
Terry Lambert wrote: I'll take a whack at it and send it out by tomorrow, working or not. Don't bother. 8-). The attached patch makes it compile, and takes a shot at doing the right thing. Just a followup... select definitely won't work (IMO), but needs someone who is threads-savvy with kernel locks to deal with it; I cribbed lock flow from elsewhere, and it looks wrong to me. So this is *definitely* 56K of diffs that *only* address compilation completely, and not full function. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-DP2 ACLs on UFS2
On Mon, 25 Nov 2002 [EMAIL PROTECTED] wrote: I've recently installed FreeBSD 5.0-DP2 to get myself familiar with the upcoming ACLs present in -CURRENT before the release itself. I've setup a test machine with one 45gb ide drive with one slice and two partitions (/ and swap) and installed FreeBSD on it. dumpfs / shows that root is UFS2, and from reading /usr/src/sys/ufs/ufs/README.acls, I don't need to do the extattrctl initattr commands since ufs2 supports EA/ACLs natively. Additionally, I booted to single user mode and enabled ACLS on / by doing a tunefs -a enable /dev/ad0s1a. I proceeded to try getfacl and setfacl. getfacl returned the default settings (just stat() in ACL form according to Robert Watson), however, no matter what I tried all I could get with setfacl -m g:mail:rwx testfile was: setfacl: acl_get_file() failed: Operation not supported I thought perhaps the tunefs on the ro mount of / did not take. So instead I used the mount time flag in fstab: /dev/ad0s1a / ufs rw,acls 1 1 I rebooted, and tried again. Yet I still get the same error message with setfacl. At this point I'm stuck. Is it because I only have / and not / and /usr? Does UFS2 with EA/ACLs not work on boot partitions? Or did I misunderstand something when trying to setup ACLs in -CURRENT? Any advice right now would be welcomed. Thanks. ACLs should work fine on any UFS2 partition where ACLs are enabled. I'm wondering if it's actually UFS2, or if dumpfs is lying to you. Could you try the following command: touch /foo setextattr system foo foo /foo getextattr system foo /foo And tell me what results you get? That will tell us if extended attributes are available or not. 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: 5.0-DP2 ACLs on UFS2
* De: Robert Watson [EMAIL PROTECTED] [ Data: 2002-11-26 ] [ Subjecte: Re: 5.0-DP2 ACLs on UFS2 ] ACLs should work fine on any UFS2 partition where ACLs are enabled. I'm wondering if it's actually UFS2, or if dumpfs is lying to you. Could you libufs stores the UFS version in disk.d_ufs based on the magic in the sblock it finds, and then dumpfs simply does something like printf(UFS%d, disk.d_ufs); More or less... So if it's lying, there's something much more fundamentally wrong :) -- Juli Mallett [EMAIL PROTECTED] OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel broken
On 2002-11-26 16:33, Gary Jennejohn [EMAIL PROTECTED] wrote:
Ray Kohler [EMAIL PROTECTED] wrote:
On Tue, Nov 26, 2002 at 12:53:39PM +0100, Jan Stocker wrote:
CVSuped (2 mins ago) -current kernel is broken:
cc1: warnings being treated as errors
/usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_lock':
/usr/src/sys/dev/sound/isa/ad1816.c:81: warning: dereferencing `void *' pointer
/usr/src/sys/dev/sound/isa/ad1816.c:81: request for member `mtx_lock' in
something not a structure or union
/usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_unlock':
/usr/src/sys/dev/sound/isa/ad1816.c:87: warning: dereferencing `void *' pointer
/usr/src/sys/dev/sound/isa/ad1816.c:87: request for member `mtx_lock' in
something not a structure or union
This turns out to be semi-reproduceable. I have this problem but the
committer who made the change can't reproduce it.
I have the same problem, [...]
The culprit seems to be a change in /sys/dev/sound/pcm/sound.h,
where snd_mtx{un}lock() were changed from routines to macros which
simply use mtx_{un}lock(). The routines required a ``void *'', but
the macros require a ``struct mtx *''.
The following drivers still declare the lock to be a ``void *'',
which is totally bogus after the above mentioned change:
/sys/dev/sound/isa/ad1816.c
/sys/dev/sound/isa/mss.c
/sys/dev/sound/isa/sbc.c
/sys/dev/sound/pci/cmi.c
/sys/dev/sound/pci/ds1.c
/sys/dev/sound/pci/emu10k1.c
/sys/dev/sound/pci/t4dwave.c
/sys/dev/sound/pcm/ac97.c
/sys/dev/sound/pcm/mixer.c
/sys/dev/sound/pcm/sound.c
I successfuly rebuilt a kernel with the following revisions of these
files.
keramida@gothmog[02:01]/home/keramida uname -v
FreeBSD 5.0-CURRENT #1: Tue Nov 26 22:30:31 EET 2002 ...
Can you check that you have the right revisions checked out:
$FreeBSD: src/sys/dev/sound/isa/ad1816.c,v 1.24 2002/06/09 14:20:17 hm Exp $
$FreeBSD: src/sys/dev/sound/isa/mss.c,v 1.78 2002/04/04 20:56:45 jhb Exp $
$FreeBSD: src/sys/dev/sound/isa/sbc.c,v 1.35 2002/04/04 20:56:45 jhb Exp $
$FreeBSD: src/sys/dev/sound/pci/cmi.c,v 1.17 2002/08/23 20:54:32 orion Exp $
$FreeBSD: src/sys/dev/sound/pci/ds1.c,v 1.27 2002/04/04 20:56:46 jhb Exp $
$FreeBSD: src/sys/dev/sound/pci/emu10k1.c,v 1.27 2002/11/25 17:07:33 cg Exp $
$FreeBSD: src/sys/dev/sound/pci/t4dwave.c,v 1.34 2002/10/17 03:45:34 marcel Exp $
$FreeBSD: src/sys/dev/sound/pcm/ac97.c,v 1.27 2002/08/23 06:19:28 orion Exp $
$FreeBSD: src/sys/dev/sound/pcm/mixer.c,v 1.27 2002/07/25 04:49:45 green Exp $
$FreeBSD: src/sys/dev/sound/pcm/sound.c,v 1.79 2002/11/25 17:17:42 cg Exp $
- Giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mbuf header bloat ?
On Mon, Nov 25, 2002 at 08:13:46PM -0500, Andrew Gallatin wrote: It is not out of date. The code means: If you've given me a counter then I'll use it otherwise I'll try to allocate one with malloc(). Ah, duh. Thanks. I'd better start providing one in my driver then.. Again, if you're just using regular mbuf clusters (of the 2K variety) you don't need to because mb_alloc will do it for you. If you're using a third-party buffer (e.g., jumbo buf) then you can if you want to but make sure it's not something that requires freeing afterwords (in other words, only do it if you do the exact same thing mb_alloc does for regular clusters because otherwise you'll have to worry about destructing the counter before freeing the mbuf). Drew -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel broken
On Wed, Nov 27, 2002 at 02:02:12AM +0200, Giorgos Keramidas wrote:
On 2002-11-26 16:33, Gary Jennejohn [EMAIL PROTECTED] wrote:
Ray Kohler [EMAIL PROTECTED] wrote:
On Tue, Nov 26, 2002 at 12:53:39PM +0100, Jan Stocker wrote:
CVSuped (2 mins ago) -current kernel is broken:
cc1: warnings being treated as errors
/usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_lock':
/usr/src/sys/dev/sound/isa/ad1816.c:81: warning: dereferencing `void *' pointer
/usr/src/sys/dev/sound/isa/ad1816.c:81: request for member `mtx_lock' in
something not a structure or union
/usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_unlock':
/usr/src/sys/dev/sound/isa/ad1816.c:87: warning: dereferencing `void *' pointer
/usr/src/sys/dev/sound/isa/ad1816.c:87: request for member `mtx_lock' in
something not a structure or union
This turns out to be semi-reproduceable. I have this problem but the
committer who made the change can't reproduce it.
I have the same problem, [...]
The culprit seems to be a change in /sys/dev/sound/pcm/sound.h,
where snd_mtx{un}lock() were changed from routines to macros which
simply use mtx_{un}lock(). The routines required a ``void *'', but
the macros require a ``struct mtx *''.
The following drivers still declare the lock to be a ``void *'',
which is totally bogus after the above mentioned change:
/sys/dev/sound/isa/ad1816.c
/sys/dev/sound/isa/mss.c
/sys/dev/sound/isa/sbc.c
/sys/dev/sound/pci/cmi.c
/sys/dev/sound/pci/ds1.c
/sys/dev/sound/pci/emu10k1.c
/sys/dev/sound/pci/t4dwave.c
/sys/dev/sound/pcm/ac97.c
/sys/dev/sound/pcm/mixer.c
/sys/dev/sound/pcm/sound.c
I successfuly rebuilt a kernel with the following revisions of these
files.
keramida@gothmog[02:01]/home/keramida uname -v
FreeBSD 5.0-CURRENT #1: Tue Nov 26 22:30:31 EET 2002 ...
Can you check that you have the right revisions checked out:
$FreeBSD: src/sys/dev/sound/isa/ad1816.c,v 1.24 2002/06/09 14:20:17 hm Exp $
$FreeBSD: src/sys/dev/sound/isa/mss.c,v 1.78 2002/04/04 20:56:45 jhb Exp $
$FreeBSD: src/sys/dev/sound/isa/sbc.c,v 1.35 2002/04/04 20:56:45 jhb Exp $
$FreeBSD: src/sys/dev/sound/pci/cmi.c,v 1.17 2002/08/23 20:54:32 orion Exp $
$FreeBSD: src/sys/dev/sound/pci/ds1.c,v 1.27 2002/04/04 20:56:46 jhb Exp $
$FreeBSD: src/sys/dev/sound/pci/emu10k1.c,v 1.27 2002/11/25 17:07:33 cg Exp $
$FreeBSD: src/sys/dev/sound/pci/t4dwave.c,v 1.34 2002/10/17 03:45:34 marcel Exp
$
$FreeBSD: src/sys/dev/sound/pcm/ac97.c,v 1.27 2002/08/23 06:19:28 orion Exp $
$FreeBSD: src/sys/dev/sound/pcm/mixer.c,v 1.27 2002/07/25 04:49:45 green Exp $
$FreeBSD: src/sys/dev/sound/pcm/sound.c,v 1.79 2002/11/25 17:17:42 cg Exp $
cg's latest commit (Tuesday) makes the above change and fixes these
errors. I still can't figure out what would make it work only for some
people, especially if we're all doing proper builds.
--
Ray Kohler [EMAIL PROTECTED]
This novel is not to be tossed lightly aside, but to be hurled with
great force.
-- Dorothy Parker
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Kernel broken
On 2002-11-26 19:21, Ray Kohler [EMAIL PROTECTED] wrote: On Wed, Nov 27, 2002 at 02:02:12AM +0200, Giorgos Keramidas wrote: $FreeBSD: src/sys/dev/sound/isa/ad1816.c,v 1.24 2002/06/09 14:20:17 hm Exp $ [...] cg's latest commit (Tuesday) makes the above change and fixes these errors. I still can't figure out what would make it work only for some people, especially if we're all doing proper builds. Hum, hum. Apparently I was just lucky. Sorry for the false but it works statement. I checked the versions of the files that I have, and the ones that were in cg's commit log: 1.25 +2 -2 src/sys/dev/sound/isa/ad1816.c I had a kernel tree that didn't include the changes :( The buildworld+buildkernel I'm running now should be a better way of checking if anything's broken. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ISA probe failure (ed0)
On Tuesday, November 26, 2002, at 02:09 PM, Andy Farkas wrote: On Mon, 25 Nov 2002, Fred Condo wrote: I have a system whose ethernet card is at ISA irq 9, port 0x280, iomem 0xd8000. FreeBSD 4.7-R correctly detects and uses this card with those settings; FreeBSD 5.0-DP2 does not. Please forgive my newbosity; this is the first time I have installed -CURRENT on anything (except as a stunt). However, a search of the archives did not turn up anything that seemed relevant. Under verbose booting, the kernel says: ed0 failed to probe at port 0x280-0x29f iomem 0xd8000 irq 9 on isa0 I have changed /boot/device.hints to reflect the change from irq 11 to 9. Two things to try, both of which prolly wont work :) - IRQ9 is the same as IRQ2 so try that in /boot/device.hints That resulted in an unbootable system: ed0 at port 0x280-0x27f irq 2 on isa0 panic: inthand_add: Can't initialize ICU Putting in a fresh device.hints (changing only the irq for ed0) makes for a bootable system, but I no longer see the ed0 failed to probe message. FreeBSD 4.7 continues to use the card with no problem. - set the card at a different IRQ (5 is good) adjust /boot/device.hints accordingly. Not an option, this is a jumperless card and the utility disk is long forgotten. Time to cannibalize my other machine. Let me know if you still have probs...I've got one of these ed0 cards lying around somewhere Thanks for the tips. I'll file a pr if I manage to understand the problem. -- fc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Fw: Call for testers: acpica-unix-20021118.tar.gz
As Nate kindly pointed out, my laptop needed a BIOS upgrade. With the upgrade, I can boot fine with ACPI enabled, although some sleep/suspend/resume stuff doesn't work right. Nate's already reported that. Thanks, Matt - Original Message - From: Matthew Emmerton [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Mitsuru IWASAKI [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 8:54 AM Subject: Re: Call for testers: acpica-unix-20021118.tar.gz ACPI stiil fails miserably on my Thinkpad T23 with these patches. I've attached the ASL and DSDT data in tar.gz format. Output from boot -v (transcribed by hand, so forgive any obvious typos) Note -- the 'o' character in 'So' below is really o with an umlat. I suspect the space in 'T ' is a non-breaking space as well. acpi0: IBM TP-1A on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GEP31 pci_open(1): mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=35758086) Using $PIR table, 14 entries at 0xc00fdeb0 skipping PCI interrupt list ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name: f0009453 ACPI-0438: *** Error: Looking up [So] in namespace, AE_BAD_CHARACTER ACPI-1287: *** Error: Method execution failed, AE_BAD_CHARACTER ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name: f0009453 ACPI-0438: *** Error: Looking up [So] in namespace, AE_BAD_CHARACTER ACPI-1287: *** Error: Method execution failed, AE_BAD_CHARACTER ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name: f000ff54 ACPI-0438: *** Error: Looking up [T ] in namespace, AE_BAD_CHARACTER repeat last 3 lines 8 times panic: kmem_malloc: entry not found or misaligned Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db show registers .. edx 0x40 ebx 0 ... db trace panic(c03d0e4c,0,c05838c0,1,0) at panic+0xab kmem_malloc(c0832078,1000,1,c058391c,c034c20b) at kmem_malloc+0x33c page_alloc(c083ac80,1000,c058390f,1,780) at page_alloc_0x27 slab_zalloc(c083ac80,1,c4049f6c,c4049f40,63) at slab_zalloc+0xfb uma_zone_slab(c083ac80,1,15f,c4046400,c083ad68) at uma_zone_slab+0x9e uma_zalloc_bucket(c083ac80,1,c03d2929,57e,c151a380) at uma_zalloc_bucekt+0x16d uma_zalloc_arg(c083ac80,0,1,c151a380,c083ac80) at uma_zalloc_arg+0x2f5 malloc(1c,c0550da0,1,c0583940,c0538538) at malloc+0x76 AcpiOsAllocate(1c,c05839f0,c053a4fc,c054fe24,0) at AcpiOsAllocate+0x21 AcpiUtCallocate(1c,1,c054b483,ff,0) at AcpiUtCallocate+0x48 AcpiUtAcquireFromCache(3,0,100,0,c3fa4000) at AcpiUtAcquireFromCache+0xac AcpiPsAllocOp(0,c4046400,0,c0246966,c3fa41e4) at AcpiPsAllocOp+0x7c AcpiPsParseLoop(c3fa4000,c403b040,c0583b0c,0,0) at AcpiPsParseLoop+0x37e AcpiPsParseAml(c3fa4000,c4040340,c4044700,d7ae2332,2f) at AcpiPsParseAml+0x7c AcpiPsxExecute(c4044700,0,c0583b74,c4044700,c0583bfc) at AcpiPsxExecute+0x12f AcpiNsExecuteControlMethod(c4044700,0,c0583b74,c151a500,0) at AcpiNsExecuteControlMethod+0x5f AcpiNsEvaluateByHandle(c4044700,0,c0583bfc,e,0) at AcpiNsEvalueByHandle+0x92 AcpiNsEvaluateRelative(c4044760,c054b6d3,0,c0583bfc0) at AcpiNsEvaluateRelative+0xde AcpiUtExecute_STA(c4044760,c0583c20,0,0,c0583c30) at AcpiUtExecute_STA+0x31 AcpiNsInitOneDevice(c4044760,2,c0583c84,0,6) at AcpiNsInitOneDevice+0x77 AcpiNsInitializeDevices(0,c0583cdc,c053b42e,0,2) at AcpiNsInitializeDevices+0x53 AcpiInitializeObjects(0,2,c052b930,0,0) at AcpiInitializeObjects+0x14 acpi_attach(c403c200,c4005098,c03e3954,c1503a70,c05500e3) at acpi_attach+0x15e To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Searching for users of netncp and nwfs to help debug5.0 problems
some comments:
firstly:
ncp_conn_locklist(int flags, struct proc *p)
{
! struct thread *td = TAILQ_FIRST(p-p_threads); /* XXX
*/
!
! return lockmgr(listlock, flags | LK_CANRECURSE, 0, td);
}
can't you use unidifs? :-)
ok
there is a Macro to find the first thread in a process.
FIRST_THREAD_IN_PROC(p)
I use it because it makes it easy to find the
places that are DEFINITLY BROKEN. The marker for a KSE breakage is:
XXXKSE, but places that use FIRST_THREAD_IN_PROC(p) are marked
implicitly since nearly any time it is used, the code is trying to
do something that doesn't make sense. (except in fork and
maybe exit and exec, and in things like linux emulation
where you KNOW there is only one thread).
if you see TAILQ_FIRST(p-p_threads) (or FIRST_THREAD_IN_PROC(p)) you
can pretty much guarantee that what is happenning there need to be
completely rewritten, possibly to the extent of rerwiting it's callers
and the caller's callers. That is the problem I hit when trying to
convert it to start with...
Since I don't know the way that process IDs come into the session
control (you have to understand the protocol for that) I basically hit
a wall on trying to work out what to rewrite, and how.
BTW the obnoxious FIRST_THREAD_IN_PROC will go away when
we have got rid of most of the broken code and be replaced in places
for which it is ok with p2td() which will be:
__inline struct thread *
p2td(struct proc *p)
{
KASSERT(((p-p_flag P_KSES) == 0),
(Threaded program uses p2td()));
return (TAILQ_FIRST(p-p_threads));
}
You can always get from a thread to a single process but the reverse
always presents the question which thread?. This question can only be
answered with external information or if you know there is only one
thread at this moment.
julian
On Tue, 26 Nov 2002, Terry Lambert wrote:
Nate Lawson wrote:
It's not so much that I volunteered as I said that I'd help with
thread/proc issues..
The trouble was that there are places where it used a proc in the old
code, but in some cases it needs to be a proc, and in other cases it now
needs to be a thread. But all they stored was the proc. Also, from
my memories of the code you needed to understand the protocol to know
which needed to be which, and I don't know that protocol.
In addition whoever does it needs to remember that any structure that
stores a thread poitner is probably in error, as threads
are transient items and any stored thread pointer is probably a wild
pointer within a few milliseconds of being stored. :-)
I'll take a whack at it and send it out by tomorrow, working or not.
Don't bother. 8-).
The attached patch makes it compile, and takes a shot at doing the
right thing.
The threasd stuff is problematic; it's useful only for a blocking
context. The process stuff is there to identify the connection,
actually, which can mean huge latencies (hence the caching of
procp).
It helps to know that the protocol is exclusively request/response
per session, the current code handles only a single session per
process (not one per thread), and that lock requests are answered
bith synchronously and asynchronously (request/response, then async
message on timeout or success).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: make.conf and make.conf(5)
I'll look into this ;)
--
Tom Rhodes
On Tue, 26 Nov 2002 10:44:29 +1100 (EST)
Andy Farkas [EMAIL PROTECTED] wrote:
On Tue, 19 Nov 2002, Carl Schmidt wrote:
The following PR has two patches attached which address the lack of
some documentation of make.conf in the manual page. It also
contains a patch for make.conf to fix style inconsistencies and two
(if I recall correctly) items which are documented in the manual
page but did not exist in the example conf.
http://www.freebsd.org/cgi/query-pr.cgi?pr=45470
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=116926+0+current/freebsd-doc
--
Carl Schmidt
Tom,
please also consider this suggestion I made over two years ago:
*Date: Fri, 13 Oct 2000 08:53:34 +1100 (EST)
*From: Andy Farkas [EMAIL PROTECTED]
*To: [EMAIL PROTECTED]
*Subject: NOMAN
I was trying to build a minimul system from sources and noticed that
there is no mention of disabling the building and installing of man
pages.
Should the NOMAN knob be documented in both /etc/defaults/make.conf
and/usr/src/Makefile.inc1 ?
--- /usr/src/etc/defaults/make.conf-origMon Sep 25 19:08:01
2000+++ /usr/src/etc/defaults/make.conf Fri Oct 13 08:33:17 2000
@@ -69,4 +69,5 @@
#NOINFO= true# do not make or install info files
#NOLIBC_R= true# do not build libc_r (re-entrant version of
libc)
+#NOMAN=true# do not build and install man pages
#NOPERL= true# To avoid building perl
#NOPROFILE=true# Avoid compiling profiled libraries
--- /usr/src/Makefile.inc1-orig Tue Oct 10 01:28:47 2000
+++ /usr/src/Makefile.inc1 Fri Oct 13 08:48:34 2000
@@ -13,4 +13,5 @@
# -DNOSHARE do not go into share subdir
# -DNOINFO do not make or install info files
+# -DNOMAN do not make or install man files
# -DNOLIBC_R do not build libc_r.
# -DNO_FORTRAN do not build g77 and related libraries.
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Searching for users of netncp and nwfs to help debug5.0 problems
First of all, the patch was just to get to the point of compilability,
which other prople said they would take it from there. I don't
have a NetWare server to test against in my apartment. I'd be just as
happy to _let_ the other people who wanted to take it from there do
do, now that I made it compile.
That said...
Julian Elischer wrote:
some comments:
firstly:
ncp_conn_locklist(int flags, struct proc *p)
{
! struct thread *td = TAILQ_FIRST(p-p_threads); /* XXX
*/
!
! return lockmgr(listlock, flags | LK_CANRECURSE, 0, td);
}
can't you use unidifs? :-)
Only if I want the code to be unreadable. 8-) 8-). Can't you
apply the patch to a -current tree checked out for that purpose,
and get whatever flavor of diffs you want, e.g. cvs diff -u?
Unidiffs don't support fuzz, and uless you are committing the
thing, I'd rather not have to recreate it interatively until it
passes someone's filter. A context diff gives me that.
ok
there is a Macro to find the first thread in a process.
FIRST_THREAD_IN_PROC(p)
I didn't see this. It's definitely the way to go.
Any chance of that being documented any time soon, so that no
one else does the obvious thing, instead, like I did?
I use it because it makes it easy to find the
places that are DEFINITLY BROKEN. The marker for a KSE breakage is:
XXXKSE, but places that use FIRST_THREAD_IN_PROC(p) are marked
implicitly since nearly any time it is used, the code is trying to
do something that doesn't make sense. (except in fork and
maybe exit and exec, and in things like linux emulation
where you KNOW there is only one thread).
if you see TAILQ_FIRST(p-p_threads) (or FIRST_THREAD_IN_PROC(p)) you
can pretty much guarantee that what is happenning there need to be
completely rewritten, possibly to the extent of rerwiting it's callers
and the caller's callers. That is the problem I hit when trying to
convert it to start with...
Actually, I really wanted a LAST_THREAD_IN_PROC(p). The
reality is that I want the most recently inserted thread to use
as a blocking context, on the theory that it would not be used
until much later, and that all the pages it cares about are much
more likely to be in core, particularly on a process with tons
of threads.
The only reason it's being used at all is that the lockmgr()
class need a blocking context for their calls, and it's an
explicit parameter (arguably, it should be curthread).
I can edit the patch (since it's not a unidiff 8-) 8-) 8-)),
or I can post a new one, if you want (it's only 9K, compressed).
But realize that all it means is give me a thread that I can
use as a blocking context while I'm waiting on lockmgr().
Since I don't know the way that process IDs come into the session
control (you have to understand the protocol for that) I basically hit
a wall on trying to work out what to rewrite, and how.
The wire protocol is always request/response. Always. As I
stated before, the only exception is a lock, with/without a
timeout. In that case, you get the synchronous response to
your synchornous request, which basically means request has
been queue for servicing, and you later get a seperate
notification.
The notification is by connection. The connection is per process,
because we are talking about a connection where the credentials
are associated with the connection in question. The connection
provides both a state context (waiting for request vs. request
in progress). Making additional requests over the same VC will
result in a request in progress, go away you dork response to
the client.
When an async response to a lock request comes in, in comes in on
a seperate VC (each connection has 3 VCs, only 2 of which are
normally used: the one for request/response, and the one for
async notifications, which is overloaded to handle lock responses).
The connection is mapped back to a process to map it back to the
blocker.
What this basically means is that NCP's can't be handled as
multithreaded, without establishing a VC per thread. It just
does not work. Therefore NCP request are going to serialize in
the kernel, no matter what you do in happy-thread-town.
If you are asking for the code to be thread safe, then you are
basically talking about multithreading the whole stack:
NWFS - NCP Client - IPX - IP
Probably it would be a better idea if TCP/IP was multithreaded
first?
BTW the obnoxious FIRST_THREAD_IN_PROC will go away when
we have got rid of most of the broken code and be replaced in places
for which it is ok with p2td() which will be:
__inline struct thread *
p2td(struct proc *p)
{
KASSERT(((p-p_flag P_KSES) == 0),
(Threaded program uses p2td()));
return (TAILQ_FIRST(p-p_threads));
}
Uh, how exactly is that less obnoxious, given it's the same code
with a different name and an obnoxious inline instead of a macro?
8-).
You can always get from a thread to a single process but the reverse
always presents
Re: [PATCH] Searching for users of netncp and nwfs to help debug5.0 problems
Terry Lambert wrote: Did you want me to update the patch to use your FIRST_THREAD_IN_PROC macro and resend it? OK; here it is, whether you wanted it or not. -- Terry smbfs_thr.diff.gz Description: GNU Zip compressed data
join
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Searching for users of netncp and nwfs to help debug5.0problems
On Tue, 26 Nov 2002, Terry Lambert wrote: Uh, how exactly is that less obnoxious, given it's the same code with a different name and an obnoxious inline instead of a macro? 8-). it's shorter .. You can always get from a thread to a single process but the reverse always presents the question which thread?. This question can only be answered with external information or if you know there is only one thread at this moment. The answer is that the code doesn't care what thread; it would prefer to not have to think in terms of threads at all, but if you want to force it to, then it's going to think in terms of blocking contexts for the benefit of FreeBSD code it calls, and nothing else. Hense the confusion as to whether to use a thread or a proc.. Did you want me to update the patch to use your FIRST_THREAD_IN_PROC macro and resend it? you could but the fact that FIRST_THREAD_IN_PROC() is used indicates that the whole thing is broken anyway. Your edits are mostly mechanical and don't actually solve the problem. To do that you probably need to actually rewrite some of it I think. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Searching for users of netncp and nwfs to help debug5.0problems
Julian Elischer wrote: The answer is that the code doesn't care what thread; it would prefer to not have to think in terms of threads at all, but if you want to force it to, then it's going to think in terms of blocking contexts for the benefit of FreeBSD code it calls, and nothing else. Hense the confusion as to whether to use a thread or a proc.. Not confusing at all. The only issue is references to the connection structure caches proc, which uses the first thread on the cached proc; otherwise, it uses the thread that was passed in. Did you want me to update the patch to use your FIRST_THREAD_IN_PROC macro and resend it? you could but the fact that FIRST_THREAD_IN_PROC() is used indicates that the whole thing is broken anyway. Your edits are mostly mechanical and don't actually solve the problem. To do that you probably need to actually rewrite some of it I think. They were _intended_ to be mechanical edits. It fixes the problem for the people who were willing to fix it, but didn't have any idea of how to do the edits. I can't really rewrite the code for you, without risking that Novell would claim that I did it with knowledge of the NUC implementation... you _do_ remember the last time Novell and BSD had an issue over code, right, back in 1994, after they bought USL? It's probably better that the patch I've done get to the people who volunteered to fix the code, once it could be compiled, and that the people who volunteered to help them with the threads issues do so. I've done as much as I can without legal risk. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MD broken in current
On Tue, 26 Nov 2002, Hiten Pandya wrote: There is also a problem, when the md(4) driver is passed a 0 byte file, i.e. mdconfig -a -t -vnode -f /tmp/mdimage.zero. It simply hangs the process in the `mddestroy' state, making it unkillable. David Wolfskill tested a patch, which I made. It could be a _possible_ fix to the problem. When a 0 byte file is found, by mdcreate_vnode() it passes up an EINVAL. I used the stat structure, and the vn_stat() routine to get the information, although I am not sure if that is the best/sane way of doing it. The URL for the patch is: http://www.unixdaemons.com/~hiten/work/diffs/md.c.patch I used the stat structure, and the vn_stat() routine to get the information, although I am not sure if that is the best/sane way of doing it. The URL for the patch is: http://www.unixdaemons.com/~hiten/work/diffs/md.c.patch This patch has too many bugs to list (mainly a vnode reference leak). Better fix mddestroy(). I don't know why it hangs ... I guess it is because it is called before initialization is completed in mdinit(), and there aren't enough state checks in mddestroy(). Bruc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: syslog:soffice.bin (ooo-1.0.1) sched_get_priority_min/max
+---[ Daniel Flickinger ]-- | Every program in ooo-1.0.1 I have tried seems to be working | correctly, but syslog is logging copious quantities of: | | cmd soffice.bin pid 817 tried to use non-present sched_get_priority_min | cmd soffice.bin pid 817 tried to use non-present sched_get_priority_max | | I have also seen them from mozilla, but not in quantity. | | Have I failed to include a kernel option? try; options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensiosn -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | M:+61 416 022 411 | ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PANIC: Most recently used by bus
In message: [EMAIL PROTECTED] Aurelien Nephtali [EMAIL PROTECTED] writes: : I've got a panic by unplugging my NIC then plugging it again and then doing : a dhclient interface. I've attached some informations about the panic. Kill the dhclient after you unplug the interface, but before you plug it back in. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PANIC: Most recently used by bus
In message: [EMAIL PROTECTED] M. Warner Losh [EMAIL PROTECTED] writes: : In message: [EMAIL PROTECTED] : Aurelien Nephtali [EMAIL PROTECTED] writes: : : I've got a panic by unplugging my NIC then plugging it again and then doing : : a dhclient interface. I've attached some informations about the panic. : : Kill the dhclient after you unplug the interface, but before you plug : it back in. This can also be caused by a bug in the network driver. If it failed to attach for some reason, but created (and not destroyed) a mutex, then the WITNESS code will modify the softc after it has been freed, trigging the panic you described. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Searching for users of netncp and nwfs to help
debug5.0problems In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 26 Nov 2002, Terry Lambert wrote: Julian Elischer wrote: The answer is that the code doesn't care what thread; it would prefer to not have to think in terms of threads at all, but if you want to force it to, then it's going to think in terms of blocking contexts for the benefit of FreeBSD code it calls, and nothing else. Hense the confusion as to whether to use a thread or a proc.. Not confusing at all. The only issue is references to the connection structure caches proc, which uses the first thread on the cached proc; otherwise, it uses the thread that was passed in. Where does the passed in thread come from? Generally don't use a thread pointer other than yourself unless you have a lock on the proc structure, or the schedlock. Certainly never store it anywhere.. Particularly anywhere that may persist while you sleep in any way. -exception.. kernel threads- .. they are persistant. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
