Re: problems with wi driver.
Mmhh, must have been blind... i was looking for it a very long time (without my eyes .) Thanks !!! Robert On Thu, Aug 14, 2003 at 11:21:36PM -0600, M. Warner Losh wrote: : Is there a better way to toggle the start address for 16 bit and 32 bit : cards with sysctl?? u_long cbb_start_16_io = CBB_START_16_IO; TUNABLE_INT(hw.cbb.start_16_io, (int *)cbb_start_16_io); SYSCTL_ULONG(_hw_cbb, OID_AUTO, start_16_io, CTLFLAG_RW, cbb_start_16_io, CBB_START_16_IO, Starting ioport for 16-bit cards); so hw.cbb.start_16_io Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: usbd does not use detach
On Friday 15 August 2003 14:13, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : It should also have a hint to indicate that this device could potentially : go away at any time, so it shouldn't cache anything if at all possible. : (Although it would be good if the user could elect to override this in : the interests of performance) : : I suspect that would require more significant changes though :) I suspect that this would be as hard to implement as dealing with things going away, and produce a system that is less desirable to use. I think ideally both would be possible.. It IS nice when you plug something in and it is mounted, and you do what you want with it, then a few seconds after you finish you unplug it. I LIKE this feature of Windows etc :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: pca driver being retired.
Mark Murray wrote: I see considerable scope for an infrastructure that would allow drivers to be ports. _Easily_. This is a good idea. I think if this infrastructure already existed, then many people would make their drivers into ports. Until then, though, the drivers will likely have to be part of the kernel. Would it be a useful exercise for the people who want drivers to be ports instead of being in the kernel to provide this facility for driver writers to use? 8^p. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: pca driver being retired.
On Friday 15 August 2003 16:45, Terry Lambert wrote: Mark Murray wrote: I see considerable scope for an infrastructure that would allow drivers to be ports. _Easily_. This is a good idea. I think if this infrastructure already existed, then many people would make their drivers into ports. Until then, though, the drivers will likely have to be part of the kernel. Would it be a useful exercise for the people who want drivers to be ports instead of being in the kernel to provide this facility for driver writers to use? See comms/ltmdm, x11/nvidia-driver, audio/aureal-kmod, comms/mwavem etc.. They already build fine.. The problem I find is that when you update your kernel the port doesn't get rebuilt, so reasonably often this results in your machine going *boom* when the port loads its module. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
M. Warner Losh wrote: These two are redundant. Devices can already ask the bridge driver if the device is still present on the bus. Smart drivers already do this, but most of the drivers in the tree are dumb. You also have to deal with device disappearance in ISRs since it is possible for the device to go away while the device is in the middle of the ISR. Some bus technologies also allow interrupt entry when a card/device is ejected. Another common case is to hibernate/sleep/suspend/whatever the machine, and then disconnect the device out from under it, and it not being there when the machine wakes back up. Almost all MP3 players and Palm devices have that issues (since the order of human operation is to shut off the machine, get the wallet and keys, grab the iPod (or whatever), and head out the door). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on ia64/ia64
TB --- 2003-08-15 09:49:23 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-08-15 09:49:23 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-08-15 09:52:10 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims 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/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-08-15 10:57:16 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Aug 15 10:57:16 GMT 2003 [...] touch hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c sh /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/conf/newvers.sh GENERIC cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror vers.c linking kernel.debug sys_process.o: In function `kern_ptrace': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/kern/sys_process.c:691: undefined reference to `cpu_ptrace' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-08-15 11:05:25 - /usr/bin/make returned exit code 1 TB --- 2003-08-15 11:05:25 - ERROR: failed to build generic kernel TB --- 2003-08-15 11:05:25 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
On Thu, Aug 14, 2003 at 08:17:33PM -0400, Andrew Gallatin wrote: You have machdep.hlt_logical_cpus: 1 in your sysctl output. [BTW, lots of people read this mail via the web archives at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1073654+0+current/freebsd-current, where its impossible to view mime; it would be MUCH better for us if appended things like stack traces and sysctl output rather then scrambling them for no reason] You can also read the archives at: http://lists.freebsd.org/pipermail/freebsd-current That archive supports MIME. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
Craig Rodrigues writes: On Thu, Aug 14, 2003 at 08:17:33PM -0400, Andrew Gallatin wrote: You have machdep.hlt_logical_cpus: 1 in your sysctl output. [BTW, lots of people read this mail via the web archives at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1073654+0+current/freebsd-current, where its impossible to view mime; it would be MUCH better for us if appended things like stack traces and sysctl output rather then scrambling them for no reason] You can also read the archives at: http://lists.freebsd.org/pipermail/freebsd-current That archive supports MIME. But it doesn't have a link to the raw email message so that I can download it via fetch, point my mailer at it and reply.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: pca driver being retired.
On Wed, 13 Aug 2003, Julian Elischer wrote: Well I'm not too happy about this.. It's the only audio I have on my TI-810 laptop. That is however not running -current yet. I'm also not pleased from the perspective that this is the only major example in the tree of how to use the clock-speedup code in i386/isa/clock.c. A very nice piece of functionality I use quite often. I use pca only to exercise the clock-speedup code. I use the clock (interrupt) speedup code mainly for generating interrupt load for stress testing. I could easily replace this by a sysctl. [Context lost to top posting.] Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible | Description | |-+--+-+-| | | | | KSE M:N threading | | | | | support is reaching | | | | | experimental yet| | | | Julian | usable status on| | Production-quality | In | Elischer, David | i386 for| | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N| | | | Eischen | threading should be | | | | | productionable and | | | | | usable on all | | | | | platforms by| | | | | 5.2-RELEASE.| |-+--+-+-| | | | | Currently, the MD | | | | | elements of KSE are | | | | | present only for| | | | | the i386 platform, | | | | | limiting use of KSE | | | | | to the i386 | | | | | platform. It is | | | | | highly desirable to | | KSE support for | | Jake| make KSE available | | sparc64, alpha, | -- | Burkholder, --, | on non-i386 | | ia64| | -- | platforms for | | | | | 5.2-RELEASE so that | | | | | KSE can see more| | | | | broad exposure, and | | | | | the performance | | | | | benefits of KSE can | | | | | be visible to users | | | | | of the 64-bit | | | | | FreeBSD | | | | | architectures. | |-+--+-+-| | | | | Kris Kennaway | | | | | reports high| | | | | instability of | | | | | 5-CURRENT on ia64 | | | In | Marcel | machines, such as | | ia64 stability | Progress | Moolenaar | the pluto* | | | | | machines. These | | | | | problems need to be | | | | | fixed in order to | | | | | get a successful| | | | | package build. | |-+--+-+-| | | | | ia64 serial console | | | | | support is reported | | | | | to not be | | | | | functional on HP| | | In | Marcel | Itanium2 platforms. | | ia64 sio support| progress | Moolenaar, | A reworking of the | | | | Warner Losh | sio driver to | | | | | improve platform| | | | | independence and| | | | | bus handling is | | | |
2 LORs on my NFS server.
Hi list,
My CURRENT is already a bit old:
# uname -a
FreeBSD polly.arved.de 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sun Jul 20
01:00:14 CEST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/CURRENT/sys/POLLY i386
But at least the first problem looks like it hasn't been fixed yet:
This happend while the machine was NFS-serving around 3 clients with
normal udp NFS and a fourth. client tried to mount something via
mount_nfs -T -a 2
vmcore.1:
Debugger(c0382315) at Debugger+0x45
witness_lock(c04599ec,8,c03b13ee,26d,0) at witness_lock+0x54e
_mtx_lock_flags(c04599ec,0,c03b13ee,26d) at _mtx_lock_flags+0x7d
tcp_usr_rcvd(c1b7d600,80) at tcp_usr_rcvd+0x1b
soreceive(c1b7d600,c8724b1c,c8724b28,c8724b20,0) at soreceive+0x789
nfsrv_rcv(c1b7d600,c20f2e00,4) at nfsrv_rcv+0x72
sowakeup(c1b7d600,c1b7d64c) at sowakeup+0x75
tcp_input(c0bc1600,14) at tcp_input+0x11df
ip_input(c0bc1600) at ip_input+0x7a0
swi_net(0) at swi_net+0xe7
ithread_loop(c0b8a080,c8724d48,c0b8cbe0,c02134a0,0) at
ithread_loop+0x126
fork_exit(c02134a0,c0b8a080,c8724d48) at fork_exit+0xab
fork_trampoline() at fork_trampoline+0x1a
db show locks
exclusive sleep mutex inp r = 0 (0xc1a7de0c) locked @
/usr/src/CURRENT/sys/netinet/tcp_input.c:650
exclusive sleep mutex netisr lock r = 0 (0xc0457140) locked @
/usr/src/CURRENT/sys/net/netisr.c:215
exclusive sleep mutex Giant r = 0 (0xc042eac0) locked @
/usr/src/CURRENT/sys/kern/kern_intr.c:533
(kgdb) bt
#0 doadump () at /usr/src/CURRENT/sys/kern/kern_shutdown.c:240
#1 0xc014e7f8 in db_fncall (dummy1=0, dummy2=0, dummy3=-1069114912,
dummy4=0xc87248d8 ôHrÈȹ!ÀèHrÈ\001\215\ÀôHrÈø\003)
at /usr/src/CURRENT/sys/ddb/db_command.c:547
#2 0xc014e5f0 in db_command (last_cmdp=0xc0419460, cmd_table=0x0,
aux_cmd_tablep=0xc03c9410, aux_cmd_tablep_end=0xc03c9414)
at /usr/src/CURRENT/sys/ddb/db_command.c:346
#3 0xc014e6cb in db_command_loop ()
at /usr/src/CURRENT/sys/ddb/db_command.c:471
#4 0xc0150f8a in db_trap (type=3, code=0)
at /usr/src/CURRENT/sys/ddb/db_trap.c:73
#5 0xc0351ef5 in kdb_trap (type=3, code=0, regs=0xc8724a04)
at /usr/src/CURRENT/sys/i386/i386/db_interface.c:172
#6 0xc03612da in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1069194936, tf_esi
= -1069180436, tf_ebp = -932033976, tf_isp = -932034000, tf_ebx = 0,
tf_edx = 0, tf_ecx = 1, tf_eax = 25, tf_trapno = 3, tf_err = 0, tf_eip =
-1070259835, tf_cs = 8, tf_eflags = 662, tf_esp = -1069194932, tf_ss =
-932033928})
at /usr/src/CURRENT/sys/i386/i386/trap.c:595
#7 0xc0353558 in calltrap () at {standard input}:102
#8 0xc0242c4e in witness_lock (lock=0xc04599ec, flags=8,
file=0xc03b13ee /usr/src/CURRENT/sys/netinet/tcp_usrreq.c,
line=621)
at /usr/src/CURRENT/sys/kern/subr_witness.c:838
#9 0xc021b7dd in _mtx_lock_flags (m=0xc04599ec, opts=0,
---Type return to continue, or q return to quit---
file=0xc03b13ee /usr/src/CURRENT/sys/netinet/tcp_usrreq.c,
line=621)
at /usr/src/CURRENT/sys/kern/kern_mutex.c:334
#10 0xc02a9b1b in tcp_usr_rcvd (so=0x0, flags=128)
at /usr/src/CURRENT/sys/netinet/tcp_usrreq.c:621
#11 0xc0257829 in soreceive (so=0xc1b7d600, psa=0xc8724b1c,
uio=0xc8724b28,
mp0=0xc8724b20, controlp=0x0, flagsp=0xc8724b24)
at /usr/src/CURRENT/sys/kern/uipc_socket.c:1087
#12 0xc1a9ff92 in nfsrv_rcv (so=0xc1b7d600, arg=0xc20f2e00, waitflag=4)
at /usr/src/CURRENT/sys/nfsserver/nfs_srvsock.c:445
#13 0xc0258e35 in sowakeup (so=0xc1b7d600, sb=0xc1b7d64c)
at /usr/src/CURRENT/sys/kern/uipc_socket2.c:320
#14 0xc02a1abf in tcp_input (m=0xc0bc1600, off0=20)
at /usr/src/CURRENT/sys/netinet/tcp_input.c:1108
#15 0xc029c6c0 in ip_input (m=0xc0bc1600)
at /usr/src/CURRENT/sys/netinet/ip_input.c:943
#16 0xc0284507 in swi_net (dummy=0x0) at
/usr/src/CURRENT/sys/net/netisr.c:236
#17 0xc02135c6 in ithread_loop (arg=0xc0b8a080)
at /usr/src/CURRENT/sys/kern/kern_intr.c:534
#18 0xc021294b in fork_exit (callout=0xc02134a0 ithread_loop,
arg=0xc0b8a080, frame=0xc8724d48)
at /usr/src/CURRENT/sys/kern/kern_fork.c:794
(kgdb) fr 12
#12 0xc1a9ff92 in nfsrv_rcv (so=0xc1b7d600, arg=0xc20f2e00, waitflag=4)
at /usr/src/CURRENT/sys/nfsserver/nfs_srvsock.c:445
445 error = so-so_proto-pr_usrreqs-pru_soreceive
(kgdb) list
440 /*
441 * Do soreceive().
442 */
443 auio.uio_resid = 10;
444 flags = MSG_DONTWAIT;
445 error = so-so_proto-pr_usrreqs-pru_soreceive
446 (so, nam, auio, mp, NULL, flags);
447 if (error || mp == NULL) {
448 if (error == EWOULDBLOCK)
449 slp-ns_flag |= SLP_NEEDQ;
(kgdb) fr 11
#11 0xc0257829 in soreceive (so=0xc1b7d600, psa=0xc8724b1c,
uio=0xc8724b28,
mp0=0xc8724b20, controlp=0x0, flagsp=0xc8724b24)
at /usr/src/CURRENT/sys/kern/uipc_socket.c:1087
warning: Source file is more recent than executable.
1087
Re: [PATCH] jail NG schript patch for mounting devfs andprocfsautomatically
On 14.08.2003 15:36, Scot W. Hetzel wrote:
I just noticed a problem with periodic scripts inside a jail. I'm getting:
Local system status:
tee: /dev/stderr: Operation not supported
Mail in local queue:
tee: /dev/stderr: Operation not supported
Mail in submit queue:
tee: /dev/stderr: Operation not supported
in the periodic daily, weekly, monthly and security reports. But if I mount
the fdescfs on the jail, then these errors go away.
So we need to add the following to the new jail script
jail_start()
{
:
eval jail_devfs=\\$jail_${_jail}_devfs\
[ -z ${jail_devfs} ] jail_devfs=NO:
eval jail_fdescfs=\\$jail_${_jail}_fdescfs\
[ -z ${jail_fdescfs} ] jail_fdescfs=NO
:
if checkyesno jail_devfs ; then
mount -t devfs dev ${jail_devdir}
if checkyesno jail_fdescfs ; then
mount -t fdescfs fdesc ${jail_devdir}/fd
fi
:
fi
:
}
jail_stop()
{
:
eval jail_devfs=\\$jail_${_jail}_devfs\
[ -z ${jail_devfs} ] jail_devfs=NO:
eval jail_fdescfs=\\$jail_${_jail}_fdescfs\
[ -z ${jail_fdescfs} ] jail_fdescfs=NO
:
if checkyesno jail_devfs ; then
if [ -d ${jail_devdir} ] ; then
if checkyesno jail_fdescfs; then
umount -f ${jail_devdir}/fd /dev/null 21
fi
umount -f ${jail_devdir} /dev/null 21
fi
fi
:
}
The only decsion we need to make is wheter to always mount the fdescfs when
devfs is mounted on the jail, or have a variable to enable mounting of the
fdescfs (jail_*_fdescfs).
Scot
I don't run periodics in jails, because they are not allowed to mail
out :-)
But I wouldn't really care having fdescfs mounted every time as
security problem, so I would decide to mount it ever (or defaultly).
If someone cares, addition of jail_example_mount_fdescfs is
recommented.
I add a CC to security@, because of there may be one or other who
has an important comment.
Best,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel failing to build
On 14.08.2003 23:10, Kris Kennaway wrote:
On Thu, Aug 14, 2003 at 05:28:54PM +0200, Guido Falsi wrote:
I's been a few days, the kernel on my machine is failing to build in the
same point...I tried cvsupping at various times.
The system is a -current from 19 July.
Build your kernel with WERROR= as discussed on this list.
There're 2 WERROR-related flages, NO_WERROR (bool, which
suppresses -Werror in some cases in /usr/share/mk/bsd.sys.mk)
and WERROR (string, contains Werror-Flag in
/usr/src/sys/conf/kern.pre.mk)
Suggestion to the Makefile maintainers:
--- kern.pre.mk.origFri Aug 15 14:32:40 2003
+++ kern.pre.mk Fri Aug 15 14:33:23 2003
@@ -52,7 +52,11 @@
.endif
.endif
DEFINED_PROF= ${PROF}
+.if defined(NO_WERROR)
+WERROR?= -Wno-error
+.else
WERROR?= -Werror
+.endif
INLINE_LIMIT?= 15000
CFLAGS+= -finline-limit=${INLINE_LIMIT} -fno-strict-aliasing
Best,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
On Thu, 14 Aug 2003 22:37:35 -0600 (MDT) M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Eric Jacobs [EMAIL PROTECTED] writes: : #DETACH_FORCE: Clients using the device must be disconnected, : #typically by revoking open file descriptors. May not : #return EBUSY due to client activitiy, but may return : #that or other errors due to hardware problems or : #limitations. : # : #DETACH_EJECTED: This call is made from a lower-level bus : #driver when the device has been physically removed from : #the system. Like DETACH_FORCE, except that drivers can : #avoid attemping (and failing) to reset the hardware : #state. This request must succeed. These two are redundant. Devices can already ask the bridge driver if the device is still present on the bus. Smart drivers already do this, but most of the drivers in the tree are dumb. How does one do this check? It is not obvious, which may explain why there are so many dumb drivers in this regard. Another factor that aggravates this is that in some cases, the driver itself may not care about this check, but its clients will. For example, umass may well not need to do anything different depending on whether it was unloaded or its device was unplugged. But the layers below it, CAM, GEOM, and VFS, may still need that information. And they aren't going to know what the USB device is, much less how to query for its existence. It seems to me that the solution for dumb drivers is to make it as easy for them to be smart, by doing as much as possible in the bus driver. You also have to deal with device disappearance in ISRs since it is possible for the device to go away while the device is in the middle of the ISR. Some bus technologies also allow interrupt entry when a card/device is ejected. : In addition, the DETACH_FORCE and DETACH_EJECTED flags could : be mapped to appropriate flag values for the other subsystems, such : as MNT_FORCE and (a new) MNT_EJECTED flag for VFS. The problem is that when you are detaching a device, it is gone when you return from the detach routine. Right. I haven't looked at the code extensively, but I believe the GEOM orphanage concept handles this well. When the disk_destroy is called during the device detach, it means that GEOM will take over returning errors to clients who still may be trying to use the device, so that those requests won't get sent to the device, and the device would be safe to delete. It can be hard to know what buffers (disk, network, etc) in the system refer a given newbus device because there's not a one to one mapping for the device_t to dev_t that the rest of the system uses. Devices may or may not know about buffers that are outstanding. Work would be needed in the buf/bio system to reference cound the dev_t so that when the driver destroys it, it doesn't go completely away until the reference count goes to zero. However, doing that may have unfavorable performance impacts. This exists in GEOM, see struct g_bioq and the nstart and nend fields of struct g_consumer. I don't know if it actually handles the hot-unplug scenario, though. The design should be able to handle it. : i manually umount the device before unpluging it. : : That is the only safe way to do it for now. Agreed. Warner Eric ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
On Thu, 14 Aug 2003 10:38:07 -0700 John-Mark Gurney [EMAIL PROTECTED] wrote: This is a bit more complex than this. There are many more layers between usb and VFS. For USB umass devices, they proxy to cam, which then is an interface to da which is a provider for geom which then provides the final device for ufs to mount. So, each and every one of those steps need to be taught about this. Right now, very few things use newbus even though they should. This is a problem of them existing before newbus was nailed down. CAM doesn't use newbus for any of it's device management (scsi device, not HBA attachment). Yes, I'm aware that there are more layers. Propogating the flag value down is trivial. The major deficiency of CAM and GEOM is that errors can't be sent back up. For example, we have this scenario: # mount /dev/da0s1a /mnt # mounting a USB hard drive # cd /mnt # in use # kldunload umass # oops! it succeeds # Ideally, I'd love to see an enhanced newbus provide the One True Framework for attaching and detaching both devices and device clients. Unfortunately, it seems like it would take a substantial redesign to get there from this point. Eric ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adaptec AIC7902 Ultra320 Problems
On Mon, Aug 11, 2003 at 01:36:01PM -0400, Craig Rodrigues wrote: You can get firmware and drivers for these drives from Hitachi: http://www.hgst.com/support/ Specifically where? I can't find any firmware there. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
On Thu, Aug 14, 2003 at 10:49:42PM -0400, Adam Migus wrote: Andrew Gallatin wrote: WRT the mime thing. My apologies. It never occured to me as everyone I know personally uses a real mail reader. I'd attached them simply to keep the scrolling down and allow order independant viewing. Thanks for the tip. I'll just read them in as plain text in the future. If it gives mail or mh problems, it doesn't work on *real* mail readers. :) hawk, ignobly usin mutt -- Richard E. Hawkins, Asst. Prof. of Economics/\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with an onboard Realtek 8139D
Hi all, with 5.1-current I have a problem with an onboard Realtek 8139D on a (very recent Fujitsu E4010D centrino laptop): after some network activity the system freezes. With 4.8-stable the NIC works flawlessly, but every 5.x-system I tried had that problem (5.0-R, 5.1-R as well as recent snapshots). Is there anything know or at least something I can do to inverstigate that. My problem is that with that laptop under -current pccards also do not work :-( so I'm stuck with the onboard NIC. Best regards -- Udo Schweigert, Siemens AG | Voice : +49 89 636 42170 CT IC CERT, Siemens CERT | Fax: +49 89 636 41166 D-81730 Muenchen / Germany | email : [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on alpha/alpha
TB --- 2003-08-15 16:00:12 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-08-15 16:00:12 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-08-15 16:03:09 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims 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/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-08-15 17:08:16 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Aug 15 17:08:16 GMT 2003 Kernel build for GENERIC completed on Fri Aug 15 17:19:52 GMT 2003 TB --- 2003-08-15 17:19:52 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-08-15 17:19:52 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Aug 15 17:19:52 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/utopia/utopia.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/vinum/vinum.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/vinum/vinumconfig.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6
Re: clock works slowly when I change CPU speed
I changed 3 files in quoted mail below (tsc.c clock.h clock.c) back to the previous revision, on my ThinkPad A22e (the last cvsup was on Aug 13), and recompiled kernel (the config file is almost the same as GENERIC), and compared behavior of the clock between 2 kernels as: kernel with the latest (on Aug 13) revision of these 3 files kernel with the previous revision of these 3 file On condition of hw.acpi.cpu.performance_speed as 8, the clock works normally ... for both of the latest and the previous revision of these 3 files On condition of hw.acpi.cpu.performance_speed as 4, the clock works slowly ... for the latest revision of these 3 files normally ... for the previous revision of these 3 files In details, when the clock works slowly, the clock works at the half of normal speed. For comparing clock, I used /usr/bin/top and another machine that has a reliable clock. (ex. video recorder) /bin/date is also suitable for comparing. On condition of the clock working slowly, snd_ich.ko said double of normal value for link rate (48000Hz is expected) when I execute kldload snd_ich by hand. I read the diff between the revisions, but I could not find out reason why the change of 3 files affects relations between clock and CPU speed setting. But it does affect. On Fri, 15 Aug 2003 07:24:59 +0900 (JST) MATOBA Hirozumi wrote: | On Thu, 2003-08-14 at 19:50, Nate Lawson wrote: | This indicates that the problem was introduced in a kernel change between | Aug 2 and Aug 9 and that acpi is not at fault. Try searching the cvs-all | archives between those dates (and perhaps narrowing the date more). | | I misunderstood Nate Lawson's words at the first time I read, | but he said about the cvs-all *mailing-list* archive. | And I found the mail about keyword clock in it. | | I will try going back to before this change (by using cvsup etc). | | Message-Id: [EMAIL PROTECTED] | From: Poul-Henning Kamp [EMAIL PROTECTED] | Date: Wed, 6 Aug 2003 08:05:28 -0700 (PDT) | To: [EMAIL PROTECTED], [EMAIL PROTECTED], | [EMAIL PROTECTED] | X-FreeBSD-CVS-Branch: HEAD | Subject: cvs commit: src/sys/i386/i386 tsc.c src/sys/i386/include clock.h | src/sys/i386/isa clock.c | | phk 2003/08/06 08:05:28 PDT | |FreeBSD src repository | |Modified files: | sys/i386/i386tsc.c | sys/i386/include clock.h | sys/i386/isa clock.c |Log: |Dont initialize a TSC timecounter until we know if it is broken or not. | |Revision ChangesPath |1.201 +6 -0 src/sys/i386/i386/tsc.c |1.45 +1 -0 src/sys/i386/include/clock.h |1.201 +1 -0 src/sys/i386/isa/clock.c -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Change to kernel+modules build approach
On 15-Aug-2003 M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : : On 14-Aug-2003 Andrew Gallatin wrote: : : John Baldwin writes: : :On 14-Aug-2003 Ruslan Ermilov wrote: : On Thu, Aug 14, 2003 at 02:10:19AM -0600, Scott Long wrote: : Luoqi Chen wrote: : [...] : On the other hand, all modules should create all the opt_*.h files : it needs when built individually. Add opt_ddb.h to nullfs's Makefile : should fix the breakage. : : Our kernel build system isn't set up to handle passing config options : to modules. Various solutions to this have been proposed, but nothing : has appeared yet. In 5.x, we document that modules will not work with : PAE. : : How does the below look? This is basically a more generic implementation : of Luoqi's idea, but for -CURRENT: : :I would prefer something far more radical that would involve moving :all the module metadata to sys/conf (i.e. removing sys/modules) and :building all the modules based on a single kernel config file. : : Would this tie modules to that kernel config? If so, would it mean : the end of the ability of 3rd party developers to ship binary drivers : and expect them to work with any kernel? : : Well, yes, but, one could always build generic modules by using : a kernel config containing 'options KLD_MODULE' or some such. : This would allow one to compile optimized modules if they wanted to, : but still provide the ability to build fully generic modules. This sounds like an either or choice. I don't care too much if the third party drivers aren't hyper optimzied for my kernel. But to force users of them to use some generic kernel would be a big support nightmare. No, generic modules would always work with all kernels except for exceptional cases like PAE (unavoidable, really), and MUTEX_PROFILING (this is a debugging thing, so ISV's wouldn't need to ship modules with that turned on). All this would add is the ability to build modules optimized for your current kernel. If this is not super desired (which I wouldn't mind), then I think we should take the modules out of /boot/kernel and put them in /boot/modules or some such. I do want to get the metadata down to one copy somehow though. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Change to kernel+modules build approach
John Baldwin writes: No, generic modules would always work with all kernels except for exceptional cases like PAE (unavoidable, really), and MUTEX_PROFILING (this is a debugging thing, so ISV's wouldn't need to ship modules with that turned on). All this would add is the ability to build modules optimized for your current kernel. If this is not super desired (which I wouldn't mind), then I think we should take the modules out of /boot/kernel and put them in /boot/modules or some such. I do want to get the metadata down to one copy somehow though. YES! YES! I'd be very much in favor of totally decoupling the modules from the kernel. In fact, once we've done that, we can move the kernel back to /kernel where it belongs, and /boot/modules can become /modules ;) BTW, what, exactly, changes size with PAE? Everything? Or would a driver that just used things like busdma, mutexes, interrupts, etc, be OK assuming the busdma interface were made so that they were always 64-bit? Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
In message: [EMAIL PROTECTED]
Eric Jacobs [EMAIL PROTECTED] writes:
: In message: [EMAIL PROTECTED]
: Eric Jacobs [EMAIL PROTECTED] writes:
: : #DETACH_FORCE: Clients using the device must be disconnected,
: : #typically by revoking open file descriptors. May not
: : #return EBUSY due to client activitiy, but may return
: : #that or other errors due to hardware problems or
: : #limitations.
: : #
: : #DETACH_EJECTED: This call is made from a lower-level bus
: : #driver when the device has been physically removed from
: : #the system. Like DETACH_FORCE, except that drivers can
: : #avoid attemping (and failing) to reset the hardware
: : #state. This request must succeed.
:
: These two are redundant. Devices can already ask the bridge driver if
: the device is still present on the bus. Smart drivers already do
: this, but most of the drivers in the tree are dumb.
:
: How does one do this check? It is not obvious, which may explain why
: there are so many dumb drivers in this regard.
#
# Is the hardware described by _child still attached to the system?
#
# This method should return 0 if the device is not present. It should
# return -1 if it is present. Any errors in determining should be
# returned as a normal errno value. Client drivers are to assume that
# the device is present, even if there is an error determining if it is
# there. Busses are to try to avoid returning errors, but newcard will return
# an error if the device fails to implement this method.
#
METHOD int child_present {
device_t_dev;
device_t_child;
} DEFAULT bus_generic_child_present;
It is recently added.
: Another factor that aggravates this is that in some cases, the driver
: itself may not care about this check, but its clients will. For example,
: umass may well not need to do anything different depending on whether
: it was unloaded or its device was unplugged. But the layers below it,
: CAM, GEOM, and VFS, may still need that information. And they aren't
: going to know what the USB device is, much less how to query for its
: existence.
Well, somebody has to talk to hardware, and that somebody has to
cope. And the problem is we can
: It seems to me that the solution for dumb drivers is to make it as
: easy for them to be smart, by doing as much as possible in the bus
: driver.
You aren't making things easier. You have:
switch (foo) {
case DETACH_FORCE:
flush();
/* fall through */
case DETACH_EJECT:
...
}
vs
if (bus_child_present(dev))
flush();
...
: : In addition, the DETACH_FORCE and DETACH_EJECTED flags could
: : be mapped to appropriate flag values for the other subsystems, such
: : as MNT_FORCE and (a new) MNT_EJECTED flag for VFS.
:
: The problem is that when you are detaching a device, it is gone when
: you return from the detach routine.
:
: Right. I haven't looked at the code extensively, but I believe the GEOM
: orphanage concept handles this well. When the disk_destroy is called
: during the device detach, it means that GEOM will take over returning
: errors to clients who still may be trying to use the device, so that
: those requests won't get sent to the device, and the device would be
: safe to delete.
If this is true, then no driver work should be necessary at all for
disk devices. However, the upper layers don't deal too well with
errors flushing. And it does nothing for network drives that have
similar problems.
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock works slowly when I change CPU speed
In message [EMAIL PROTECTED], MATOBA Hirozumi wri tes: On condition of hw.acpi.cpu.performance_speed as 8, the clock works You should not be using the TSC for timekeeping if you change the frequency of it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
In message: [EMAIL PROTECTED] Eric Jacobs [EMAIL PROTECTED] writes: : On Thu, 14 Aug 2003 10:38:07 -0700 : John-Mark Gurney [EMAIL PROTECTED] wrote: : : : This is a bit more complex than this. There are many more layers between : usb and VFS. For USB umass devices, they proxy to cam, which then is an : interface to da which is a provider for geom which then provides the : final device for ufs to mount. So, each and every one of those steps : need to be taught about this. Right now, very few things use newbus : even though they should. This is a problem of them existing before : newbus was nailed down. CAM doesn't use newbus for any of it's device : management (scsi device, not HBA attachment). : : Yes, I'm aware that there are more layers. Propogating the flag value : down is trivial. The major deficiency of CAM and GEOM is that errors : can't be sent back up. For example, we have this scenario: : : # mount /dev/da0s1a /mnt # mounting a USB hard drive : # cd /mnt # in use : # kldunload umass # oops! it succeeds : # : : Ideally, I'd love to see an enhanced newbus provide the One True : Framework for attaching and detaching both devices and device : clients. Unfortunately, it seems like it would take a substantial : redesign to get there from this point. Nah, just to make cam use it. cam and newbus were contemporary developments, so cam used the old ad-hoc way of dealing. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Change to kernel+modules build approach
In message: [EMAIL PROTECTED] Andrew Gallatin [EMAIL PROTECTED] writes: : : John Baldwin writes: : : No, generic modules would always work with all kernels except for : exceptional cases like PAE (unavoidable, really), and MUTEX_PROFILING : (this is a debugging thing, so ISV's wouldn't need to ship modules : with that turned on). All this would add is the ability to build : modules optimized for your current kernel. If this is not super : desired (which I wouldn't mind), then I think we should take the : modules out of /boot/kernel and put them in /boot/modules or some such. : I do want to get the metadata down to one copy somehow though. : : YES! YES! I'd be very much in favor of totally decoupling the : modules from the kernel. : : In fact, once we've done that, we can move the kernel back to /kernel : where it belongs, and /boot/modules can become /modules ;) That would be somewhat difficult. It would make it a lot harder to keep a 2 or 4 week old kernel around for testing since you couldn't load current modules with an old kernel (generally, but sometimes it works). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Change to kernel+modules build approach
On Fri, 15 Aug 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Andrew Gallatin [EMAIL PROTECTED] writes: : : John Baldwin writes: : : No, generic modules would always work with all kernels except for : exceptional cases like PAE (unavoidable, really), and MUTEX_PROFILING : (this is a debugging thing, so ISV's wouldn't need to ship modules : with that turned on). All this would add is the ability to build : modules optimized for your current kernel. If this is not super : desired (which I wouldn't mind), then I think we should take the : modules out of /boot/kernel and put them in /boot/modules or some such. : I do want to get the metadata down to one copy somehow though. : : YES! YES! I'd be very much in favor of totally decoupling the : modules from the kernel. : : In fact, once we've done that, we can move the kernel back to /kernel : where it belongs, and /boot/modules can become /modules ;) That would be somewhat difficult. It would make it a lot harder to keep a 2 or 4 week old kernel around for testing since you couldn't load current modules with an old kernel (generally, but sometimes it works). Has anyone in this discussion looked at what Matt has done with Dragonfly? He's re-arranged the kernel tree and moved each driver/module into its own directory. Each directory has a Makefile. thus a traversal of the kernel tree make hierarchy generates the modules. The modules subdirectory is going away.. (I think he's in the middle of doing that now) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PQI 128MB USB flash drive mount problems
hi, i have a PQI Intelligent Stick 128MB USB flash drive that i'm trying to get working on -CURRENT. i added: device da device scbus device umass to my kernel configuration. when i attach the drive, it detects it correctly, and i get the following kernel messages on the console: umass0: Intelligent Stick Intelligent Stick, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: USB Card IntelligentStick 1.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 127MB (260448 512 byte sectors: 64H 32S/T 127C) umass0: Phase Error, residue = 0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 after the above is printed, it prints: Opened disk da0 - 5 Opened disk da0 - 5 Opened disk da0 - 5 Opened disk da0 - 5 4 times, and then it appears to give up. any attempt to mount /dev/da0s1 fails after a timeout of about 15-20 seconds or so. ash# mount -t msdos /dev/da0s1 /mnt/istick msdosfs: /dev/da0s1: Input/output error any ideas what to do to debug this? given pointers, i'm willing to play with some code. thanks! leon nb: please cc me on responses. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Change to kernel+modules build approach
In message: [EMAIL PROTECTED] Julian Elischer [EMAIL PROTECTED] writes: : : : On Fri, 15 Aug 2003, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Andrew Gallatin [EMAIL PROTECTED] writes: : : : : John Baldwin writes: : : : : No, generic modules would always work with all kernels except for : : exceptional cases like PAE (unavoidable, really), and MUTEX_PROFILING : : (this is a debugging thing, so ISV's wouldn't need to ship modules : : with that turned on). All this would add is the ability to build : : modules optimized for your current kernel. If this is not super : : desired (which I wouldn't mind), then I think we should take the : : modules out of /boot/kernel and put them in /boot/modules or some such. : : I do want to get the metadata down to one copy somehow though. : : : : YES! YES! I'd be very much in favor of totally decoupling the : : modules from the kernel. : : : : In fact, once we've done that, we can move the kernel back to /kernel : : where it belongs, and /boot/modules can become /modules ;) : : That would be somewhat difficult. It would make it a lot harder to : keep a 2 or 4 week old kernel around for testing since you couldn't : load current modules with an old kernel (generally, but sometimes it : works). : : Has anyone in this discussion looked at what Matt has done with : Dragonfly? He's re-arranged the kernel tree and moved each driver/module : into its own directory. Each directory has a Makefile. thus : a traversal of the kernel tree make hierarchy generates the modules. : : The modules subdirectory is going away.. (I think he's in the middle : of doing that now) That's certainly an interesting concept. One that would make it easier to deal with modules since you have the Makefile right where you need it. If that is all that he's done, then that wouldn't answer John's objection to the current state of affairs: meta data in two places (module Makefile and conf/files*). If he's done something else in addition to the movement, then that would be interesting to look at. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PQI 128MB USB flash drive mount problems
In message [EMAIL PROTECTED], leon j. breedt write
s:
hi,
i have a PQI Intelligent Stick 128MB USB flash drive that
i'm trying to get working on -CURRENT.
For another PQI product I need this patch. There is a good
chance they use the same controller chip:
Index: scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.151
diff -u -r1.151 scsi_da.c
--- scsi_da.c 6 Aug 2003 17:30:03 - 1.151
+++ scsi_da.c 7 Aug 2003 07:39:29 -
@@ -364,6 +364,16 @@
{T_DIRECT, SIP_MEDIA_REMOVABLE, MITSUMI, USB FDD, *},
/*quirks*/ DA_Q_NO_SYNC_CACHE
},
+ {
+ /*
+* PQI Travel Flash, rev 1.10/2.05, addr 2
+* General Flash Disk Drive 2.05
+* Serial Number ST92163-2000
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, General Flash Disk Drive,
+*, *},
+ /*quirks*/ DA_Q_NO_SYNC_CACHE
+ }
#endif /* DA_OLD_QUIRKS */
};
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock works slowly when I change CPU speed
On Fri, 2003-08-15 at 14:03, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], MATOBA Hirozumi wri tes: On condition of hw.acpi.cpu.performance_speed as 8, the clock works You should not be using the TSC for timekeeping if you change the frequency of it. So, what should be done to restore the proper behavior of the timekeeping on these systems? Bob ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PQI 128MB USB flash drive mount problems -- RESOLVED
On Fri, Aug 15, 2003 at 09:45:25PM +0200, Poul-Henning Kamp wrote: For another PQI product I need this patch. There is a good chance they use the same controller chip: applied, added DA_OLD_QUIRKS to config, recompiled, rebooted, and it works flawlessly. thanks! leon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock works slowly when I change CPU speed
* Bob Fleck [EMAIL PROTECTED] [2003-08-15 22:46]: So, what should be done to restore the proper behavior of the timekeeping on these systems? $ dmesg | grep counter Timecounter i8254 frequency 1193182 Hz Timecounter ACPI-fast frequency 3579545 Hz Timecounter TSC frequency 1595302164 Hz $ sysctl -w kern.timecounter.hardware=i8254 Fixes the problem for me. I suspect you should set this in /etc/sysctl.conf to enable it permanently. Regards -Thorsten -- One good reason why computers can do more work than people is that they never have to stop and answer the phone. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
System call recvfrom returning with the following locks held ...
I got this on an alpha machine overnight. Is this fixed already? Kris System call recvfrom returning with the following locks held: exclusive sleep mutex Giant r = 0 (0xfc69ac88) locked @ /a/asami/portbuild/alpha/src-client/sys/kern/uipc_syscalls.c:944 panic: witness_warn Stack backtrace: db_print_backtrace() at db_print_backtrace+0x18 backtrace() at backtrace+0x2c panic() at panic+0x148 witness_warn() at witness_warn+0x254 syscall() at syscall+0x530 XentSys() at XentSys+0x64 --- syscall (38) --- --- user mode --- panic pgp0.pgp Description: PGP signature
Re: System call recvfrom returning with the following locks held ...
On Fri, Aug 15, 2003 at 02:10:46PM -0700, Kris Kennaway wrote: I got this on an alpha machine overnight. Is this fixed already? I believe this was a goof on my part, but it was fixed by kan@ earlier this week. Let me know if it persists. David. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/pc98
TB --- 2003-08-15 20:07:17 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-08-15 20:07:17 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-08-15 20:09:49 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims 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/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-08-15 21:08:53 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Aug 15 21:08:53 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/libkern/udivdi3.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/libkern/umoddi3.c cc -c -x assembler-with-cpp -DLOCORE -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/i386/busio.s cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/i386/busiosubr.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev
Re: Change to kernel+modules build approach
:: Has anyone in this discussion looked at what Matt has done with :: Dragonfly? He's re-arranged the kernel tree and moved each driver/module :: into its own directory. Each directory has a Makefile. thus :: a traversal of the kernel tree make hierarchy generates the modules. :: :: The modules subdirectory is going away.. (I think he's in the middle :: of doing that now) : :That's certainly an interesting concept. One that would make it :easier to deal with modules since you have the Makefile right where :you need it. If that is all that he's done, then that wouldn't answer :John's objection to the current state of affairs: meta data in two :places (module Makefile and conf/files*). If he's done something :else in addition to the movement, then that would be interesting to :look at. : :Warner Yes, I've done away with the 'modules' directory and have been reincorporating the modules Makefiles into the main part of the kernel tree. It turns out not to be all that difficult. Most module Makefile's can be plopped into the proper directory with very few changes. On half of them I only had to remove the .PATH directive. Subdirectories are glued together with the standard bsd.subdir.mk. Some surgery is required, but nothing difficult. For example, the netgraph modules necessitated moving each /usr/src/sys/netgraph/* element into a subdirectory to accomodate the Makefile for that netgraph module. There are a few areas like that... mainly changes which force partitionable entities into their own subdirectories which I consider to be good for the structure of the system. It is still a work in progress but I am very close to getting all the ducks honking properly in regards to config based kernel builds, make buildkernel, separate module builds, and module builds with and without 'make obj'. I heartily recommend that -current investigate and implement the refolding of the module build into the main kernel source tree. Eventually my goal is to make the entire kernel sufficiently modular that 'config' can be gotten rid of (or, at least, relegated to just generating the various .h files from the config options). -- I have also done additional (and very extensive) reorganization of the kernel source tree, but it is probably too extensive for -current to consider (read: about 40 dillon hours of work plus another 40 dillon hours to cleanup the build issues afterwords). Not only did I completely reorganize filesystems, network subsystems, and device drivers, I also moved driver-specific architecture-specific files out of e.g. i386/ and into appropriate_driver/i386, and I also changed config to generate use_*.h instead *.h files, which allowed me to remove the -I- sillyness from the Makefiles, which in turn allows relative #include file paths to be used again in the kernel source (in the many places where they make sense, which is just about everywhere). This greatly improves our ability to modularize of the kernel. But it was a huge amount of work. If I were to pick *one* thing to recommend that -current adopt it would be to change all the config generated *.h files to use_*.h (plus the same thing in those module makefiles which generated *.h files), and get rid of the -I- compiler option, then incrementally fix all the #include's that can be trivially relative to being trivially relative. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR with filedesc structure and Giant
On Mon, Aug 11, 2003 at 03:47:02PM -0700, Kris Kennaway wrote:
lock order reversal
1st 0xc3d25134 filedesc structure (filedesc structure) @
/a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:902
2nd 0xc04aa500 Giant (Giant) @
/a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
#10 0xc02313e4 in spec_poll (ap=0xce655af8)
at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
The problem seems to be due to select() being called on the /dev/null
device, and it is holding the filedesc lock when it reaches
PICKUP_GIANT() in spec_poll.
(kgdb) frame 10
#10 0xc02313e4 in spec_poll (ap=0xce655af8)
at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
372 in /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c
(kgdb) print ap-a_vp-v_type
$26 = VCHR
(kgdb) print ap-a_vp-v_un-vu_spec-vu_cdev-si_udev
$27 = 514
This may be related to the following commit of phk:
---
date: 2002/09/27 19:47:59; author: phk; state: Exp; lines: +76 -13
Add a D_NOGIANT flag which can be set in a struct cdevsw to indicate
that a particular device driver is not Giant-challenged.
SPECFS will DROP_GIANT() ... PICKUP_GIANT() around calls to the
driver in question.
Notice that the interrupt path is not affected by this!
This does _NOT_ work for drivers accessed through cdevsw-d_strategy()
ie drivers for disk(-like), some tapes, maybe others.
---
#11 0xc02308d8 in spec_vnoperate (ap=0x0)
at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:122
#12 0xc02d152c in vn_poll (fp=0x0, events=0, active_cred=0xc42f6800, td=0x0) at
vnode_if.h:537
#13 0xc029491e in selscan (td=0xc3087720, ibits=0xce655b98, obits=0xce655b88, nfd=6)
at /a/asami/portbuild/i386/src-client/sys/sys/file.h:272
#14 0xc029449f in kern_select (td=0xc3087720, nd=6, fd_in=0xbfbff5b0, fd_ou=0x0,
fd_ex=0x0, tvp=0xce655cd4)
at /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:822
#15 0xc0294116 in select (td=0x0, uap=0xce655d10)
at /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:726
#16 0xc03f0233 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134565968, tf_esi = -1077938776,
tf_ebp = 674425792, tf_isp = -832217740, tf_ebx = 0, tf_edx = -1077938768, tf_ecx =
0, tf_eax = 93, tf_trapno = 12, tf_err = 2, tf_eip = 671926988, tf_cs = 31,
tf_eflags = 534, tf_esp = 674425704, tf_ss = 47})
at /a/asami/portbuild/i386/src-client/sys/i386/i386/trap.c:1008
#17 0xc03e011d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
pgp0.pgp
Description: PGP signature
Re: Problems with bktr on -current
On Sun, Aug 03, 2003 at 03:35:17PM +0200, Guido Berhoerster wrote: Hello, I've got some trouble with the bktr-driver on FreeBSD 5.x. With fxtv the video-output is distorted and choppy, it appears that only odd scanlines are redrawn regularly while even scanlines remain for like half a second as ghost images. When the fxtv window is overlapped by some other window the video is only updated about every 30 seconds. When using mplayer's bsdbt848-driver I get an undistorted image but also choppy video. I wasn't able to test it with xawtv since it's still broken on 5.x. This is a regression over 4.x, where everything works flawlessly. I can reproduce these Problems on FreeBSD 5.0, 5.1, -CURRENT and also on NetBSD 1.6.1. So my guess is that this is related to some more recent patches which have been applied to FreeBSD 5.x and NetBSD 1.6.1 but not FreeBSD 4.8. Does anybody have similar problems or does anybody know what changes might have caused this problem? I had a very similar problem a couple of months ago. I recall that my problem had to do with the kernel and fxtv being built with different headers. Are you building fxtv from scratch on each system or using the same binary? -- David P. Reese, Jr. [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR with filedesc structure and Giant
On Fri, 15 Aug 2003, Kris Kennaway wrote: The problem seems to be due to select() being called on the /dev/null device, and it is holding the filedesc lock when it reaches PICKUP_GIANT() in spec_poll. Yeah, this is pretty much the same issue you've been bumping into for a bit -- we hold filedesc lock over select(), which means every object we poll can't grab a lock that either comes before the file descriptor lockin the lock order, or that might sleep. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock works slowly when I change CPU speed
On Fri, 15 Aug 2003 22:50:47 +0200 Thorsten Greiner wrote: | $ dmesg | grep counter | Timecounter i8254 frequency 1193182 Hz | Timecounter ACPI-fast frequency 3579545 Hz | Timecounter TSC frequency 1595302164 Hz | $ sysctl -w kern.timecounter.hardware=i8254 | Fixes the problem for me. I suspect you should set this in | /etc/sysctl.conf to enable it permanently. Thank you for your advice. I compared the behaviors of the 2 kernel in the quoted mail below (I wrote) about Timecounter in dmesg and about value of kern.timecounter.hardware, then I understood the mail On Fri, 15 Aug 2003 20:03:28 +0200 Poul-Henning Kamp wrote: You should not be using the TSC for timekeeping if you change the frequency of it. means. On my ThinkPad A22e, 3 kind of Timecounters appear in dmesg. Between 2 kernels, both of about appeaing order in dmesg and about the default value of kern.timecounter.hardware differ. On kernel with the previous revision of these 3 file: $ dmesg | grep counter Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 797048080 Hz Timecounter ACPI-fast frequency 3579545 Hz Timecounters tick every 10.000 msec $ sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-fast On kernel with the latest (on Aug 13) revision of these 3 files: $ dmesg | grep counter Timecounter i8254 frequency 1193182 Hz Timecounter ACPI-fast frequency 3579545 Hz Timecounter TSC frequency 797048048 Hz Timecounters tick every 10.000 msec $ sysctl kern.timecounter.hardware kern.timecounter.hardware: TSC So, on kernel with the latest (on Aug 13) revision of these 3 files, after executing sysctl -w kern.timecounter.hardware=ACPI-fast the clock works normally for any CPU speed settings, successfully. I will put it in /etc/sysctl.conf :-) # Does kernel choose the Timecounter which detects recently # as the default value of kern.timecounter.hardware? On Sat, 16 Aug 2003 02:27:01 +0900 (JST) I wrote: | I changed 3 files in quoted mail below (tsc.c clock.h clock.c) | back to the previous revision, | on my ThinkPad A22e (the last cvsup was on Aug 13), | and recompiled kernel (the config file is almost the same as GENERIC), | and compared behavior of the clock between 2 kernels as: | | kernel with the latest (on Aug 13) revision of these 3 files | kernel with the previous revision of these 3 file | | | Message-Id: [EMAIL PROTECTED] | | From: Poul-Henning Kamp [EMAIL PROTECTED] | | Date: Wed, 6 Aug 2003 08:05:28 -0700 (PDT) | | To: [EMAIL PROTECTED], [EMAIL PROTECTED], | | [EMAIL PROTECTED] | | X-FreeBSD-CVS-Branch: HEAD | | Subject: cvs commit: src/sys/i386/i386 tsc.c src/sys/i386/include clock.h | | src/sys/i386/isa clock.c | | | | phk 2003/08/06 08:05:28 PDT | | | |FreeBSD src repository | | | |Modified files: | | sys/i386/i386tsc.c | | sys/i386/include clock.h | | sys/i386/isa clock.c | |Log: | |Dont initialize a TSC timecounter until we know if it is broken or not. | | | |Revision ChangesPath | |1.201 +6 -0 src/sys/i386/i386/tsc.c | |1.45 +1 -0 src/sys/i386/include/clock.h | |1.201 +1 -0 src/sys/i386/isa/clock.c -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
