Re: rpc.lockd problems
On Wed, 13 Nov 2002, Kris Kennaway wrote: Yes, and I have no problems interoperating NFS under 4.x between these machines (or under 5.0 as long as I don't try and lock any files) - it's just 5.0's rpc.lockd. Can you help isolate the problem by trying this same operation from a Solaris NFS client? I'm actually happy to get bug reports about rpc.lockd as it means that someone is actually using my code. However, after having rewritten and debugged the FreeBSD rpc.lockd, I have no desire to debug the Linux one. ;) I believe that Linux client, at least, requires special patches to make its NFS properly compliant (it's not part of the main kernel tree). I don't track Linux enough to know if the server also requires something similar. See the talk from Connectathon 2002: http://www.connectathon.org/talks02/trond.pdf As well as the NFS patches at: http://www.fys.uio.no/~trondmy/ http://www.fys.uio.no/~trondmy/src/ -a -a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl5.6.1 wrapper
On Thu, Nov 14, 2002 at 06:01:46AM +1100, Andrew Kenneth Milton wrote: Why can't someone with a fresh stable do an ls -R / And someone with a fresh current do the same? Because that's only part of the story. What about people updating from other supported source upgrade versions (4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7)? Kris msg46664/pgp0.pgp Description: PGP signature
mdconfig /tmp problem
Folks, I have been using an mdconfig /tmp for quite a while. Today, running -current from 11/14 I got the following errors while doing an installworld after testing my bind 8.3.3-patched import stuff: kernel: swap_pager_strategy: bp 0xc2f34480 blk 0 size 0, not page bounded (plus lots more) During the installworld whatever binary was being read from the /tmp/install.foo directory would segfault, and I'd get one or more of those in my log. Here is my little script for creating the mem disk. It hasn't changed in a long time. # Usually a noop, but just in case mdconfig -d -u 10 2/dev/null mdconfig -a -t swap -s 8M -u 10 disklabel -r -w md10 auto /dev/null newfs -U /dev/md10c /dev/null mount /dev/md10c /tmp /bin/chmod 1777 /tmp I'll be upgrading to a more recent -current asap, but I thought I'd throw this out there what with the release imminent and all. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sbin/sysctl sysctl.8 src/sys/kern init_main.c
Conrad Sabatier [EMAIL PROTECTED] writes: Was the following just swallowed up into the bowels of the CVS beast or something? :-) I've tried updating my sources several times, and still not retrieving it. Hook, line and sinker, eh? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sbin/sysctl sysctl.8 src/sys/kern init_main.c
On 14-Nov-2002 Dag-Erling Smorgrav wrote: Conrad Sabatier [EMAIL PROTECTED] writes: Was the following just swallowed up into the bowels of the CVS beast or something? :-) I've tried updating my sources several times, and still not retrieving it. Hook, line and sinker, eh? You know, I did suspect that maybe it was a prank. Thought it seemed a little too good to be true. :-) -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
truss and KSE
While experimenting with the new libpthread, I found that if you run `truss' on a KSE process, both truss and its victim get into a weird state and don't respond to TERM, INT or QUIT signals. The truss proc dies if you send it the KILL signal, but the victim process cannot be killed. Stranger still, it's in the run state but not actually performing any work. I understand that KSE is still an experimental feature but I thought this was worth pointing out because it could be used as a local DoS and we are nearing 5.0-RELEASE. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss and KSE
What is your revision of kern_thread.c? revision 1.58 should fix this problem. - Original Message - From: Tim Robbins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 9:06 PM Subject: truss and KSE While experimenting with the new libpthread, I found that if you run `truss' on a KSE process, both truss and its victim get into a weird state and don't respond to TERM, INT or QUIT signals. The truss proc dies if you send it the KILL signal, but the victim process cannot be killed. Stranger still, it's in the run state but not actually performing any work. I understand that KSE is still an experimental feature but I thought this was worth pointing out because it could be used as a local DoS and we are nearing 5.0-RELEASE. Tim 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: /dev/acd*t* no longer available in -current?
On Wed, 13 Nov 2002, Conrad Sabatier wrote: Please disregard. I discovered it was just that I was using single-digit track numbers (e.g., acd0t1), whereas leading-zero numbers were expected (e.g., acd0t01). Sorry 'bout that. :\ On 13-Nov-2002 Conrad Sabatier wrote: I've been using a homemade CD ripping script under -stable that uses dd with the acd0t* devices. Unfortunately, these seem no longer to exist in -current, or am I mistaken? I'm still a bit perplexed by devfs, to be honest. Is there any way to create these devices (if they are still supported, that is)? Single-digit track numbers are correct and are still generated by MAKEDEV. The devfs numbers were broken in: % RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v % Working file: atapi-cd.c % head: 1.126 % ... % % revision 1.119 % date: 2002/05/28 17:39:17; author: sos; state: Exp; lines: +1 -1 % Use %02d in track numbers, so that 1 is 01, much easier for scripts % Contrary to the log message, %02d is harder for scripts. It gives many more cases to handle: - %d format under RELENG_4 - %d format under -current in the non-devfs case - %d format under -current even in the devfs case for track numbers = 100 - %02d under -current in the devfs case for track numbers 100. The following patch backs out rev.1.119 of atapi-cd.c and fixes the following older devfs bugs in acd: - insecure permissions. Among other holes, these allowed the world to erase cd-rw's. - hard-coded ownerships leading to broken groups for the track devices. %%% Index: atapi-cd.c === RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v retrieving revision 1.126 diff -u -2 -r1.126 atapi-cd.c --- atapi-cd.c 18 Oct 2002 22:03:34 - 1.126 +++ atapi-cd.c 14 Nov 2002 13:10:52 - @@ -282,5 +282,5 @@ dev = make_dev(acd_cdevsw, dkmakeminor(cdp-lun, 0, 0), - UID_ROOT, GID_OPERATOR, 0644, acd%d, cdp-lun); + UID_ROOT, GID_OPERATOR, 0640, acd%d, cdp-lun); make_dev_alias(dev, acd%da, cdp-lun); make_dev_alias(dev, acd%dc, cdp-lun); @@ -1330,8 +1330,8 @@ char name[16]; - sprintf(name, acd%dt%02d, cdp-lun, track); + sprintf(name, acd%dt%d, cdp-lun, track); entry = malloc(sizeof(struct acd_devlist), M_ACD, M_NOWAIT | M_ZERO); entry-dev = make_dev(acd_cdevsw, (cdp-lun 3) | (track 16), - 0, 0, 0644, name, NULL); + UID_ROOT, GID_OPERATOR, 0640, name, NULL); entry-dev-si_drv1 = cdp-dev-si_drv1; TAILQ_INSERT_TAIL(cdp-dev_list, entry, chain); %%% Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bug? vm.stats.sys.v_syscall not updated
On Thu, 14 Nov 2002, Borja Marcos wrote: There is a problem in -CURRENT. The vm.stats.sys.v_syscall from the system MIB is not updated. This variable was used at least by the systat command, and it happens to be used by an Orca (www.orcaware.com) data collector I am writing for FreeBSD. Is this a bug? If it is not, is there another system call counter available? This is a bug in rev.1.62 of vm_meter.c and associated changes. I use the following fix: %%% Index: pcpu.h === RCS file: /home/ncvs/src/sys/sys/pcpu.h,v retrieving revision 1.9 diff -u -2 -r1.9 pcpu.h --- pcpu.h 20 Aug 2002 19:50:30 - 1.9 +++ pcpu.h 21 Aug 2002 00:17:02 - @@ -98,6 +100,10 @@ * support single-instruction memory increments. */ -#define PCPU_LAZY_INC(var) (++*PCPU_PTR(var)) - +#ifdef SMP +#definePCPU_LAZY_INC(var) (++*PCPU_PTR(var)) +#else +#definePCPU_LAZY_INC(var) (++(var)) +#endif + /* * Machine dependent callouts. cpu_pcpu_init() is responsible for %%% There are several related bugs. E.g., in the SMP case the stats aren't up to date in their usual place until you look at them, so programs that look at them using kvm will see stale values. There are too many such programs... jhb may have more complete fixes. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MORE: Re: Bug? vm.stats.sys.v_syscall not updated
On Thu, 14 Nov 2002, Borja Marcos wrote: Looking at the kernel sources, I see that in /usr/src/sys/i386/i386/trap.c, --- snip /* * note: PCPU_LAZY_INC() can only be used if we can afford * occassional inaccuracy in the count. */ PCPU_LAZY_INC(cnt.v_syscall); --- snip This seems to be a macro to update a per-CPU variable. But, AFAIK, there is *only* one variable now. Is it correct? The ia64 version (/usr/src/sys/ia64/ia64) happily updates this variable: ... This part is a bug in the ia64 version (in fact, in all non-i386 arches for syscall() and in all arches for many other statistics): PCPU_LAZY_INC() is only deployed for 1 variable on 1 arch so far. (See an earlier reply for how to unbreak the deployed case.) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM modules dependency on PAM library (was: Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c)
On Mon, Apr 08, 2002 at 02:49:04PM +0200, Dag-Erling Smorgrav wrote:
Ruslan Ermilov [EMAIL PROTECTED] writes:
You're right. I forgot to relink pam_ssh.so library, and the diff was
against the wrong revision. I will still commit the const poisoning
patch to libutil, as the impact turned out to be really low.
Thanks, const poisoning is a Good Thing [tm].
BTW, could you try to figure out a way we can split up the libpam
build so the modules can depend on libpam.so? What I'd like is:
1) build static modules
2) build static and dynamic libpam
3) build dynamic modules (with dependency on libpam.so)
or
1) build dynamic libpam
2) build modules (with dependency on libpam.so)
3) build static libpam
or something similar.
Uh oh, here is the version that seems to work. Once I'm confident it
passes the make release test (it has already passed the preliminary
make buildworld test), I intend to commit it.
Note that I'm not passing the _NO_LIBPAM_SO_YET to the depend stage
intentionally; otherwise, it results in incomplete .depend files.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.311
diff -u -r1.311 Makefile.inc1
--- Makefile.inc1 13 Nov 2002 13:49:29 - 1.311
+++ Makefile.inc1 14 Nov 2002 14:39:46 -
@@ -729,7 +729,8 @@
.endif
_prebuild_libs+= lib/libcom_err lib/libcrypt lib/libkvm lib/libmd \
- lib/libncurses lib/libopie lib/libradius lib/librpcsvc \
+ lib/libncurses lib/libopie lib/libpam lib/libradius \
+ lib/librpcsvc \
lib/libsbuf lib/libtacplus lib/libutil lib/libypclnt \
lib/libz lib/msun
@@ -755,7 +756,7 @@
_generic_libs+=usr.sbin/pcvt/keycap
.endif
-.for _lib in ${_startup_libs} ${_prebuild_libs} ${_generic_libs}
+.for _lib in ${_startup_libs} ${_prebuild_libs:Nlib/libpam} ${_generic_libs}
${_lib}__L: .PHONY
.if exists(${.CURDIR}/${_lib})
${ECHODIR} === ${_lib}; \
@@ -765,6 +766,16 @@
${MAKE} DIRPRFX=${_lib}/ install
.endif
.endfor
+
+# libpam is special: we need to build static PAM modules before
+# static PAM library, and dynamic PAM library before dynamic PAM
+# modules.
+lib/libpam__L: .PHONY
+ ${ECHODIR} === lib/libpam; \
+ cd ${.CURDIR}/lib/libpam; \
+ ${MAKE} DIRPRFX=lib/libpam/ depend; \
+ ${MAKE} DIRPRFX=lib/libpam/ -D_NO_LIBPAM_SO_YET all; \
+ ${MAKE} DIRPRFX=lib/libpam/ -D_NO_LIBPAM_SO_YET install
_startup_libs: ${_startup_libs:S/$/__L/}
_prebuild_libs: ${_prebuild_libs:S/$/__L/}
Index: lib/libpam/modules/Makefile.inc
===
RCS file: /home/ncvs/src/lib/libpam/modules/Makefile.inc,v
retrieving revision 1.13
diff -u -r1.13 Makefile.inc
--- lib/libpam/modules/Makefile.inc 13 May 2002 10:53:24 - 1.13
+++ lib/libpam/modules/Makefile.inc 14 Nov 2002 14:39:46 -
@@ -4,7 +4,6 @@
NOINSTALLLIB= yes
NOPROFILE= yes
-SHLIB_NAME?= ${LIB}.so.${SHLIB_MAJOR}
CFLAGS+= -I${PAMDIR}/include
CFLAGS+= -I${.CURDIR}/../../libpam
@@ -14,8 +13,12 @@
# This is nasty.
# For the static case, libpam.a depends on the modules.
# For the dynamic case, the modules depend on libpam.so.N
-# Punt for the time being until I can figure out how to do it.
-#DPADD+= ${LIBPAM}
-#LDADD+= -lpam
+.if defined(_NO_LIBPAM_SO_YET)
+NOPIC= YES
+.else
+SHLIB_NAME?= ${LIB}.so.${SHLIB_MAJOR}
+DPADD+=${LIBPAM}
+LDADD+=-lpam
+.endif
.include ../Makefile.inc
msg46674/pgp0.pgp
Description: PGP signature
Re: current SMP kernel crashes (different?)
you wrote: I think the ACPI PCI LNK code is messing up b/c with SMP we don't use LNK's. So you probably want to disable ACPI for now. Is the panic the same w/o ACPI? without ACPI the kernel hangs after the Waiting 2 seconds for SCSI devices to settle message. Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x6dbc00 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02d7383 stack pointer = 0x10:0xc06decf8 frame pointer = 0x10:0xc06ded18 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at _mtx_lock_flags+0x43: cmpl$0xc05216c0,0(%ebx) db trace _mtx_lock_flags(6dbc00,0,c04c3c00,138,c02d767d) at _mtx_lock_flags+0x43 ithread_remove_handler(c06ded80,c06ded78,c046c427,c06ded80,0) at ithread_remove_handler+0x53 inthand_remove(c06ded80,0,c04e8e36,445,a0) at inthand_remove+0x11 cpu_initclocks(c06ded98,c02bcf75,0,6db000,6dbc00) at cpu_initclocks+0x327 initclocks(0,6db000,6dbc00,6db000,0) at initclocks+0x1c mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db _mtx_lock_flags+0x43 - sys/kern/kern_mutex.c:324 ithread_remove_handler+0x53 - sys/kern/kern_intr.c:314 inthand_remove+0x11 - sys/i386/isa/intr_machdep.c:705 cpu_initclocks+0x327 - sys/i386/isa/clock.c:1096 initclocks+0x1c - sys/kern/kern_clock.c:153 mi_startup+0xb5 - sys/kern/init_main.c:217 KASSERT(m-mtx_object.lo_class == lock_class_mtx_sleep, (mtx_lock() of spin mutex %s @ %s:%d, m-mtx_object.lo_name, file, line)); It's blowing up doing that == compare, so it seems that the mutex pointer (m) (%ebx) is 0x6dbc00. (Doing a p $ebx might confirm this.) That means that the ithread might be messed up. Either that or the handler itself might be messed up. If you do a hexdump of the first argument to ithread_remove_handler() that should give you a dump of the struct intrhand, and you can then see if that looks valid, esp. the ithread pointer. If the ithread pointer is valid then you can start looking at the ithread structure via hexdump and see if it looks valid. Thanks for these hints, I'll try them ASAP, dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Quota/FS problems
Hello current@ I am having a problem with one of my machines running -CURRENT srcs from Nov. 5 The machine is acting as an NFS server. It crashed around the 12th or so with a Softupdates deps error which is maybe what started all of this. (no I do not have the crash dump, but I will do my best to get one if it happens again). The slice that puked (/dev/amrd1s1e )was fsck'd and remounted on reboot. I had not noticed problems with the slice until I tried to apply quotas to it. I added options QUOTA to my kernel, enable_quotas=YES to /etc/rc.conf and rebooted. I then did an edquota on a proto user (quota). I subsequently ran edquota -p quota 1050-99 which created a large quota file: thompson# ls -sk quota.user /maildirs 31264 quota.user I then rebooted again for good measure (and to make sure quotacheck ran) when I ran repquota -a however, I was suprised to see incorrect values for fs usage: thompson# repquota -a | head -3 -- ~ Block limitsFile limits User used soft hard grace usedsoft hard grace 12071 -- 526553667584 -4 0 0 - thompson# ls -l /maildirs/1/7/12071 total 2 drwx-- 10 12071 1024 512 Sep 13 17:12 Maildir/ thompson# du -sh * /maildirs/1/7/12071 62MMaildir so, I decided that I should unmount the slice and run quotacheck on it by hand, which i did: thompson# quotacheck -a quotacheck: bad inode number 1 to nextinode THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: /dev/amrd1s1e (/maildirs) I then tried to fsck -fF /dev/amrd1s1e which acted normal (reported no errors, nor any fixing) Then, quotacheck again, with the same results as before. So...I tried turning off softupdates with tunefs -n disable; fsck'ing; quotachecking again, and again, same results. Thanks for reading this far, if you haven't given up yet, hopefully you can help me. I really don't know what is going on, and after searching the archives I turned up nothing helpful. Is there something about Softupdates, and quotas? dmesg and fstab are at http://www.msu.edu/~muk/thompson/ Is my disk just hosed? If so, why isn't fsck saying anything? Any help would be greatly appreciated. Thanks in advance, ./muk -- m. kolb [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM modules dependency on PAM library (was: Re: cvs commit:src/lib/libpam/modules/pam_unix pam_unix.c)
Ruslan Ermilov [EMAIL PROTECTED] writes: Uh oh, here is the version that seems to work. Once I'm confident it passes the make release test (it has already passed the preliminary make buildworld test), I intend to commit it. Thanks! DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
**HEADS UP** /usr/bin/perl wrapper removal imminent
The /usr/bin/perl wrapper isn't solving many of the problems it was imported to deal with. There are limitations to it that don't have a clear fix. One of the bigger problems is the duplicate perl binaries that occurs building and using packages from /usr/ports. Since the import of the /usr/bin/perl wrapper, the Perl port has gained an enhanced use.perl script that solves the problems. Thus the wrapper will be removed from the base system in a 5 days (Monday Nov 18th PST). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl5.6.1 wrapper
At 2:01 AM -0800 11/14/02, Kris Kennaway wrote: On Thu, Nov 14, 2002, Andrew Kenneth Milton wrote: Why can't someone with a fresh stable do an ls -R / And someone with a fresh current do the same? Because that's only part of the story. What about people updating from other supported source upgrade versions (4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7)? I'll try to do as many of these as I can. Is there any initial ISO image available for what will be 5.0-dp2? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /dev/acd*t* no longer available in -current?
It seems Bruce Evans wrote: Single-digit track numbers are correct and are still generated by MAKEDEV. Single digit track numbers are wrong and should be fixed in MAKEDEV. The devfs numbers were broken in: % RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v % Working file: atapi-cd.c % head: 1.126 % ... % % revision 1.119 % date: 2002/05/28 17:39:17; author: sos; state: Exp; lines: +1 -1 % Use %02d in track numbers, so that 1 is 01, much easier for scripts % Contrary to the log message, %02d is harder for scripts. It gives many more cases to handle: - %d format under RELENG_4 Should be fixed. - %d format under -current in the non-devfs case DEVFS should be considered mandatory for the track devices on current. - %d format under -current even in the devfs case for track numbers = 100 BZZT!! there can be a max of 99 tracks on a CD. - %02d under -current in the devfs case for track numbers 100. Thats actually the one thats right :) The following patch backs out rev.1.119 of atapi-cd.c and fixes the following older devfs bugs in acd: - insecure permissions. Among other holes, these allowed the world to erase cd-rw's. Use rc.devfs for that as it was intended. - hard-coded ownerships leading to broken groups for the track devices. Well, that sounds like a bug alright... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic when removing umass device (USB Camera)
On Thu, 14 Nov 2002, Kutulu wrote:
I have an HP digital camera w/ CompactFlash that acts as a USB mass-storage
device that's panic'ing my system when I remove it.
If I do not load the umass driver, then the camera is detected as a simple
generic ugen0 device, and I can safely add/remove the device at will. If I
load the umass driver, the camera is correctly detected as a mass-storage
device as such:
umass0: HP USB DIGITAL CAMERA, rev 1.10/1.00, addr4
umass0: Residue incorrect, was 0, should've been 252
umass0: Residue incorrect, was 0, should've been 252
umass0: Residue incorrect, was 0, should've been 252
umass0: Residue incorrect, was 0, should've been 252
umass0: Residue incorrect, was 0, should've been 252
da0 at umass-sim0 bus 0 target 0 lun 0
da0: HP USB CAMERA 1.00 Removeable Direct Access SCSI-0 device
da0: 1.000 MB/s transfers
da0: 30 MB (62657 512 byte sectors: 64H 32S/T 30C)
At this point, if I detach the camera (or, if the camera puts itself to
sleep as it will do after 5 minutes of inactivity), I get the following
errors:
umass0: BBB reset failed, IOERROR
umass0: BBB bulk-in clear stall failed, IOERROR
umass0: BBB bulk-out clear stall failed, IOERROR
(these are repeated 4 more times...)
umass0: at uhub1 port 4 (addr 4) disconnected
(da0: umass-sim0:0:0:)): lost device
umass0: detached
Try this patch for the BBB stall:
Index: /sys/cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.113
diff -u -r1.113 scsi_da.c
--- /sys/cam/scsi/scsi_da.c 17 Oct 2002 18:04:41 - 1.113
+++ /sys/cam/scsi/scsi_da.c 14 Nov 2002 19:04:40 -
@@ -416,7 +416,7 @@
* HP 315 Digital Camera
* PR: kern/41010
*/
- {T_DIRECT, SIP_MEDIA_REMOVABLE, HP, USB Camera*, *},
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, HP, USB CAMERA*, *},
/*quirks*/ DA_Q_NO_6_BYTE
}
};
followed by a panic:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xdeadc10a
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01ea9d6
stack pointer = 0x10:0xc5e42b74
frame pointers = 0x10:0xc5e42b74
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def 32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL0
current process = 23 (usb0)
kernel: type 12 trap, code=0
Stopped at device_get_nameunit+0x6:movl0x2c(%eax), %eax
Something is attempting to access memory that has already been freed (note
the 0xdead). I need a stacktrace from a kernel with symbols to know more
about who is calling device_get_nameunit. You can set a dumpdev and get a
core or run gdb over a serial line against the kernel.debug. If you don't
have that yet, just a tr in ddb would help.
The really odd part is, if I haven't done anything between attaching and
detaching, then I now get dropped into DDB and cannot continue without
rebooting. However, if I *have* tried to access the device (even so much as
cat /dev/da0) before detaching, I get the panic then get returned
immediately to my console. The SCSI device disappears when I rescan the
SCSI bus with camcontrol, and if I reattach the camera is doesn't come back,
but otherwise the system keeps going like normal. (The actual devfs nodes
/dev/da0 and /dev/umass0 are still there, however)
Page fault != panic although it often results in one. Once you access
/dev/da0, it gets SI_NAMED and thus the data isn't freed twice in the same
matter. The bug is still there, it's just being masked.
Should I be able to remove this device at run-time, or am I trying to do
something that's presently unsupported? And if so, what else do I need to
do?
This should work. As long as you don't have an fs mounted on the device,
you should be able to detach it.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd problems
On Thu, Nov 14, 2002 at 01:47:43AM -0800, Andrew P. Lentvorski wrote: On Wed, 13 Nov 2002, Kris Kennaway wrote: Yes, and I have no problems interoperating NFS under 4.x between these machines (or under 5.0 as long as I don't try and lock any files) - it's just 5.0's rpc.lockd. Can you help isolate the problem by trying this same operation from a Solaris NFS client? I'm actually happy to get bug reports about rpc.lockd as it means that someone is actually using my code. However, after having rewritten and debugged the FreeBSD rpc.lockd, I have no desire to debug the Linux one. ;) Sorry, I have no access to a Solaris machine :( Kris msg46682/pgp0.pgp Description: PGP signature
Re: after cvsup make chinpui3 get undefined reference error
On Thu, Nov 14, 2002 at 03:00:51PM -0800, Kris Kennaway wrote: On Thu, Nov 14, 2002 at 08:31:43AM +0800, suken woo wrote: g++ -o chinput chinput.o init.o server.o config.o color.o util.o convert.o IC.o XIM.o focus.o root.o overspot.o onspot.o offspot.o voice.o keyboard.o handw.o hwengine.o loop.o -L/usr/X11R6/lib -lXext -lX11 ./IMdkit/lib/libXimd.a -L../../unicon-im/client -L../../unicon-im/server -limmclient -Wl,-rpath=/usr/local/lib/Chinput/im -limm_server -lc_r -lc -lImlib ../../unicon-im/server/libimm_server.so: undefined reference to `ostream::operator(char const*)' ../../unicon-im/server/libimm_server.so: undefined reference to `cout' *** Error code 1 Again, it's unfortunate but expected that many ports fail to build on -current. There's not much point in reporting them (they're all listed at http://bento.freebsd.org) unless you can supply a patch to fix it. I just had 3 PR (44290,44291,45201) closed because no one would commit the patches to fix the builds on -current. Two of these PRs were submitted almost a month ago. So, supplying patch hardly guarantees the port will be fixed. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
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 Thu Nov 14 15:20:14 PST 2002 -- Kernel build for GENERIC completed on Thu Nov 14 15:51:41 PST 2002 -- Kernel build for LINT started on Thu Nov 14 15:51:41 PST 2002 -- === vinum Makefile, line 4441: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 5) *** 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: after cvsup make chinpui3 get undefined reference error
On Thu, Nov 14, 2002 at 03:36:59PM -0800, Steve Kargl wrote: On Thu, Nov 14, 2002 at 03:00:51PM -0800, Kris Kennaway wrote: On Thu, Nov 14, 2002 at 08:31:43AM +0800, suken woo wrote: g++ -o chinput chinput.o init.o server.o config.o color.o util.o convert.o IC.o XIM.o focus.o root.o overspot.o onspot.o offspot.o voice.o keyboard.o handw.o hwengine.o loop.o -L/usr/X11R6/lib -lXext -lX11 ./IMdkit/lib/libXimd.a -L../../unicon-im/client -L../../unicon-im/server -limmclient -Wl,-rpath=/usr/local/lib/Chinput/im -limm_server -lc_r -lc -lImlib ../../unicon-im/server/libimm_server.so: undefined reference to `ostream::operator(char const*)' ../../unicon-im/server/libimm_server.so: undefined reference to `cout' *** Error code 1 Again, it's unfortunate but expected that many ports fail to build on -current. There's not much point in reporting them (they're all listed at http://bento.freebsd.org) unless you can supply a patch to fix it. I just had 3 PR (44290,44291,45201) closed because no one would commit the patches to fix the builds on -current. So the PR was closed with the problems still existing? That shouldn't have happened. Two of these PRs were submitted almost a month ago. So, supplying patch hardly guarantees the port will be fixed. Well, there are never guarantees in this game, but there's certainly a greater chance. I've done a number of passes through the PR database committing PRs that fix build errors, and we have 3 new committers recently who are also working on this. Kris msg46687/pgp0.pgp Description: PGP signature
Re: gcc 3.2.1 optimization bug ?
Thus spake TOMITA Yoshinori [EMAIL PROTECTED]: But unfortunately, that ugly code was contained in our inhouse library written by someone. It took me two days to debug and find out where difference comes from between gcc-2.95.4 and gcc-3.2.1. You can work around the problem by disabling -fschedule-insns or -fstrict-aliasing, both of which are turned on by -O2. The latter option is the more direct cause of your problem, but for some reason only the combination of the two seems to generate incorrect output on i386. Of course what you really ought to do is fix the code. C99 makes no provisions for type punning, to my knowledge. However, the GCC project officially blesses two practices: - referring to any object through a character pointer - punning the elements of a union Note that the latter only works if you directly refer to the union directly, rather than through a pointer. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-stable build on -current
Hello! Can 5.x properly cross-buildworld a 4.x source tree? Background info.. I have 3 machines at home: 1- graphic workstation 1Ghz, 1Gbyte of RAM dual Win2k/FreeBSD-stable 2- personal web/mail server P166 FreeBSD-stable 3- router 486 FreeBSD-stable My concern is that I won't be able to buildworld in 50 minutes as I can do now on the 1Ghz. Basically, I would turn my experiments machine (the workstation) in a real development machine, running -current and still a -stable world for the 2 other boxes. Anyone cares to share such experiences? Please CC me, I'm not on the list (yet). Thanks, A. -- From the age of uniformity, from the age of solitude, from the age of Big Brother, from the age of doublethink - greetings! msg46689/pgp0.pgp Description: PGP signature
Re: panic when removing umass device (USB Camera)
From: Nate Lawson [EMAIL PROTECTED]
Sent: Thursday, November 14, 2002 2:13 PM
Try this patch for the BBB stall:
Index: /sys/cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.113
diff -u -r1.113 scsi_da.c
--- /sys/cam/scsi/scsi_da.c 17 Oct 2002 18:04:41 - 1.113
+++ /sys/cam/scsi/scsi_da.c 14 Nov 2002 19:04:40 -
@@ -416,7 +416,7 @@
* HP 315 Digital Camera
* PR: kern/41010
*/
- {T_DIRECT, SIP_MEDIA_REMOVABLE, HP, USB Camera*, *},
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, HP, USB CAMERA*, *},
/*quirks*/ DA_Q_NO_6_BYTE
}
};
I applied this patch and rebuilt my kernel w/ debugging symbols, so next
time it panic's I can get a core file.
The really good news is that this patch appears to have solved BOTH the BBB
stall errors *and* the panic:
umass0: at uhub1 port 4 (addr 4) disconnected
(da0:umass-sim0:0:0:0): lost device
(da0:umass-sim0:0:0:0): removing device entry
umass0: detached
Whatever the bug was appears to have been removing the da0 device entry, as
when the page fault did happen that message didn't appear on the console nor
did da0 go away. Now I get da0 (and da0s1, which also didn't happen before)
when the camera's on, and neither device when the camera's off.
Thanks *a lot* for this quick turnaround time. If you want me to back the
patch out and get a trace anyway (in case I'm now just covering up a bug
that still exists) I'd be more than happy to. Lemme know. I'm now going to
try actually mounting the device and moving files to/from it :)
--Mike Edenfield
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: -stable build on -current
Hello! Can 5.x properly cross-buildworld a 4.x source tree? I've tried this once when downgrading a not-so-stable -CURRENT (SMP) box to a hopefully-more-stable -STABLE box. I remember running into problems with gcc 3.x failing to compile gcc 2.95 and some C++ related things. I ended up unpacking a 4.7 distribution from the CD into a chroot environment and running buildworld in there. IIRC, this produced a usable world/kernel that could be installed. Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic when removing umass device (USB Camera)
From: Kutulu [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 8:58 PM Subject: Re: panic when removing umass device (USB Camera) I'm now going to try actually mounting the device and moving files to/from it :) Quick follow-up that this is working fine, including the file system unmounting itself when the camera goes to sleep. I'm rather impressed, even Windows 2000 complained about that one. :) --Mike Edenfield To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Question about POSIX AIO
Hi,
I am running a -CURRENT system.
I had some code that was calling aio_suspend(), and
was setting errno to EINVAL. From the man page for aio_suspend:
[EINVAL] iocbs contains more than AIO_LISTIO_MAX asynchronous
I/O requests, or at least one of the requests is not
valid.
I reduced my list of I/O requests to AIO_LISTIO_MAX -1, and I did not
got EINVAL any more.
My question is, why are the following values different?
The following program:
#include aio.h
#include unistd.h
#include stdio.h
int
main(int argc, char *argv)
{
printf(%d\n, AIO_LISTIO_MAX);
printf(%d\n, sysconf(_SC_AIO_LISTIO_MAX));
}
will print:
16
-1
sysctl -a | grep aio will return:
vfs.aio.max_aio_procs: 32
vfs.aio.num_aio_procs: 4
vfs.aio.target_aio_procs: 4
vfs.aio.max_aio_queue: 1024
vfs.aio.num_queue_count: 0
vfs.aio.num_buf_aio: 0
vfs.aio.aiod_timeout: 1000
vfs.aio.aiod_lifetime: 3000
vfs.aio.unloadable: 0
vfs.aio.max_aio_per_proc: 32
vfs.aio.max_aio_queue_per_proc: 256
vfs.aio.max_buf_aio: 16
p1003_1b.aio_listio_max: 0
p1003_1b.aio_max: 0
p1003_1b.aio_prio_delta_max: 0
How can I get sysconf(_SC_AIO_LISTIO_MAX) to return something sensible,
ie. where would I need to look in order to patch the system?
Thanks.
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: truss and KSE
On Thu, Nov 14, 2002 at 05:39:12AM -0800, David Xu wrote: What is your revision of kern_thread.c? revision 1.58 should fix this problem. I believe it was 1.57. I'll try with 1.58 and let you know if the problem is still there. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 optimization bug ?
On Thu, 14 Nov 2002 17:37:50 -0800, David Schultz [EMAIL PROTECTED] said: Da You can work around the problem by disabling -fschedule-insns or Da -fstrict-aliasing, both of which are turned on by -O2. The latter Da option is the more direct cause of your problem, but for some Da reason only the combination of the two seems to generate incorrect Da output on i386. Before posting that question here, one of my colleague advised me that it may have something to do with aliasing feature. I looked up the option -fstrict-aliasing in gcc.info and tried: gcc -O2 -fstrict-aliasing ... ha-ha... I should have read the info more carefully. -fno-strict-alias also worked for it. Thanks. -- TOMITA Yoshinori To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM modules dependency on PAM library (was: Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c)
On Thu, Nov 14, 2002 at 04:28:37PM +0100, Dag-Erling Smorgrav wrote: Ruslan Ermilov [EMAIL PROTECTED] writes: Uh oh, here is the version that seems to work. Once I'm confident it passes the make release test (it has already passed the preliminary make buildworld test), I intend to commit it. Thanks! I've tested it with i386 buildworld and cross-release of alpha. (i386 release died in buildkernel due to already fixed breakage in /sys/dev/pccard.) This is now committed. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg46709/pgp0.pgp Description: PGP signature
Re: buildkernel failure
pcic isn't supported with NEWCARD yet :-) I'll fix it none-the-less. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
