kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
With today's update of sources (Revision: 223466 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 223466 Last Changed Date: 2011-06-23 08:55:29 +0200 (Do, 23 Jun 2011)) FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config What's up? Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim wrote: On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote: Can you please try the attached patch? It should disable TSC/TSC-low timecounter for your CPU models, I think. Sorry, I attached a wrong patch. Please ignore the previous one and try this, instead. TSC-low is not presented as an option any more: CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.03-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Event timer LAPIC quality 400 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 atrtc0: AT realtime clock port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer RTC frequency 32768 Hz quality 0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 attimer0: AT timer port 0x40-0x43,0x50-0x53 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 kern.timecounter.choice: TSC(-1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On 23.06.2011 11:54, O. Hartmann wrote: With today's update of sources (Revision: 223466 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 223466 Last Changed Date: 2011-06-23 08:55:29 +0200 (Do, 23 Jun 2011)) FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config I have this problem too. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
[head tinderbox] failure on sparc64/sparc64
TB --- 2011-06-23 09:46:45 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 09:46:45 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-06-23 09:46:45 - cleaning the object tree TB --- 2011-06-23 09:47:01 - cvsupping the source tree TB --- 2011-06-23 09:47:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-06-23 09:47:48 - building world TB --- 2011-06-23 09:47:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 09:47:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 09:47:48 - TARGET=sparc64 TB --- 2011-06-23 09:47:48 - TARGET_ARCH=sparc64 TB --- 2011-06-23 09:47:48 - TZ=UTC TB --- 2011-06-23 09:47:48 - __MAKE_CONF=/dev/null TB --- 2011-06-23 09:47:48 - cd /src TB --- 2011-06-23 09:47:48 - /usr/bin/make -B buildworld World build started on Thu Jun 23 09:47:49 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 23 10:49:50 UTC 2011 TB --- 2011-06-23 10:49:50 - generating LINT kernel config TB --- 2011-06-23 10:49:50 - cd /src/sys/sparc64/conf TB --- 2011-06-23 10:49:50 - /usr/bin/make -B LINT TB --- 2011-06-23 10:49:50 - building LINT kernel TB --- 2011-06-23 10:49:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 10:49:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 10:49:50 - TARGET=sparc64 TB --- 2011-06-23 10:49:50 - TARGET_ARCH=sparc64 TB --- 2011-06-23 10:49:50 - TZ=UTC TB --- 2011-06-23 10:49:50 - __MAKE_CONF=/dev/null TB --- 2011-06-23 10:49:50 - cd /src TB --- 2011-06-23 10:49:50 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 23 10:49:50 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 10:53:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 10:53:55 - ERROR: failed to build lint kernel TB --- 2011-06-23 10:53:55 - 3032.88 user 740.70 system 4030.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On 23.06.2011 11:54, O. Hartmann wrote: FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config What's up? I backed out r223443 and r223448 and it helped. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
[head tinderbox] failure on powerpc64/powerpc
TB --- 2011-06-23 09:35:38 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 09:35:38 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-06-23 09:35:38 - cleaning the object tree TB --- 2011-06-23 09:36:01 - cvsupping the source tree TB --- 2011-06-23 09:36:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-06-23 09:36:21 - building world TB --- 2011-06-23 09:36:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 09:36:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 09:36:21 - TARGET=powerpc TB --- 2011-06-23 09:36:21 - TARGET_ARCH=powerpc64 TB --- 2011-06-23 09:36:21 - TZ=UTC TB --- 2011-06-23 09:36:21 - __MAKE_CONF=/dev/null TB --- 2011-06-23 09:36:21 - cd /src TB --- 2011-06-23 09:36:21 - /usr/bin/make -B buildworld World build started on Thu Jun 23 09:36:22 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Thu Jun 23 11:08:56 UTC 2011 TB --- 2011-06-23 11:08:56 - generating LINT kernel config TB --- 2011-06-23 11:08:56 - cd /src/sys/powerpc/conf TB --- 2011-06-23 11:08:56 - /usr/bin/make -B LINT TB --- 2011-06-23 11:08:56 - building LINT kernel TB --- 2011-06-23 11:08:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 11:08:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 11:08:56 - TARGET=powerpc TB --- 2011-06-23 11:08:56 - TARGET_ARCH=powerpc64 TB --- 2011-06-23 11:08:56 - TZ=UTC TB --- 2011-06-23 11:08:56 - __MAKE_CONF=/dev/null TB --- 2011-06-23 11:08:56 - cd /src TB --- 2011-06-23 11:08:56 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 23 11:08:56 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 11:12:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 11:12:51 - ERROR: failed to build lint kernel TB --- 2011-06-23 11:12:51 - 4512.73 user 1081.38 system 5833.26 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-06-23 09:28:37 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 09:28:37 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-06-23 09:28:37 - cleaning the object tree TB --- 2011-06-23 09:28:57 - cvsupping the source tree TB --- 2011-06-23 09:28:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-06-23 09:29:23 - building world TB --- 2011-06-23 09:29:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 09:29:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 09:29:23 - TARGET=powerpc TB --- 2011-06-23 09:29:23 - TARGET_ARCH=powerpc TB --- 2011-06-23 09:29:23 - TZ=UTC TB --- 2011-06-23 09:29:23 - __MAKE_CONF=/dev/null TB --- 2011-06-23 09:29:23 - cd /src TB --- 2011-06-23 09:29:23 - /usr/bin/make -B buildworld World build started on Thu Jun 23 09:29:25 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 23 11:15:40 UTC 2011 TB --- 2011-06-23 11:15:40 - generating LINT kernel config TB --- 2011-06-23 11:15:40 - cd /src/sys/powerpc/conf TB --- 2011-06-23 11:15:40 - /usr/bin/make -B LINT TB --- 2011-06-23 11:15:40 - building LINT kernel TB --- 2011-06-23 11:15:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 11:15:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 11:15:40 - TARGET=powerpc TB --- 2011-06-23 11:15:40 - TARGET_ARCH=powerpc TB --- 2011-06-23 11:15:40 - TZ=UTC TB --- 2011-06-23 11:15:40 - __MAKE_CONF=/dev/null TB --- 2011-06-23 11:15:40 - cd /src TB --- 2011-06-23 11:15:40 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 23 11:15:40 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 11:19:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 11:19:31 - ERROR: failed to build lint kernel TB --- 2011-06-23 11:19:31 - 5402.66 user 995.37 system 6653.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On Thu, Jun 23, 2011 at 09:54:46AM +0200, O. Hartmann wrote: With today's update of sources (Revision: 223466 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 223466 Last Changed Date: 2011-06-23 08:55:29 +0200 (Do, 23 Jun 2011)) FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config See the same diagnostic loop I notice in thread with subj Re: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage) Try to unplug your CDs/DVDs if you have them. -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On 23.06.11 09:54, O. Hartmann wrote: With today's update of sources (Revision: 223466 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 223466 Last Changed Date: 2011-06-23 08:55:29 +0200 (Do, 23 Jun 2011)) FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config What's up? +1, powerpc64. Would be nice if this could be fixed. Thanks, Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On 06/23/11 13:10, Andrey V. Elsukov wrote:
On 23.06.2011 11:54, O. Hartmann wrote:
FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the
kernel and ending up
with the message (repeated every 60 seconds):
run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
What's up?
I backed out r223443 and r223448 and it helped.
It seems to be the only way out at the moment. The just checked out
codebase doesn't even compile a kernel and fails compiling in the ATH
module:
/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:52:4:
note: instantiated from:
W1(_fg) }
^
/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:34:45:
note: instantiated from:
(((_a) 63 (_a) 128 ? (((uint64_t) 1)((_a)-64)) :
(uint64_t) 0))
^ ~
/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:742:21:
warning: shift count is negative
.chan11g_turbo = BM1(T3_2437_2437)},
^
/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:35:29:
note: instantiated from:
#define BM1(_fa){ W0(_fa), W1(_fa) }
^
/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:34:45:
note: instantiated from:
(((_a) 63 (_a) 128 ? (((uint64_t) 1)((_a)-64)) :
(uint64_t) 0))
^ ~
/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah_regdomain.c:170:2:
warning: implicit declaration of function 'HALDEBUG_G' is invalid in C99
[-Wimplicit-function-declaration]
HALDEBUG_G(ah, HAL_DEBUG_REGDOMAIN,
^
/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah_regdomain.c:170:17:
error: use of undeclared identifier 'HAL_DEBUG_REGDOMAIN'; did you mean
'HAL_REG_DOMAIN'?
HALDEBUG_G(ah, HAL_DEBUG_REGDOMAIN,
^
/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah_regdomain.c:612:22:
error: use of undeclared identifier 'HAL_DEBUG_ANY'; did you mean
'HALDEBUG_G'?
HALDEBUG_G(AH_NULL, HAL_DEBUG_ANY,
^
HALDEBUG_G
/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah_regdomain.c:170:2:
note: 'HALDEBUG_G' declared here
HALDEBUG_G(ah, HAL_DEBUG_REGDOMAIN,
^
434 warnings and 2 errors generated.
*** Error code 1
Stop in /usr/src/sys/modules/ath.
*** Error code 1
Stop in /usr/src/sys/modules.
*** Error code 1
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on arm/arm
TB --- 2011-06-23 11:20:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 11:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-06-23 11:20:00 - cleaning the object tree TB --- 2011-06-23 11:20:35 - cvsupping the source tree TB --- 2011-06-23 11:20:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-06-23 11:20:54 - building world TB --- 2011-06-23 11:20:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 11:20:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 11:20:54 - TARGET=arm TB --- 2011-06-23 11:20:54 - TARGET_ARCH=arm TB --- 2011-06-23 11:20:54 - TZ=UTC TB --- 2011-06-23 11:20:54 - __MAKE_CONF=/dev/null TB --- 2011-06-23 11:20:54 - cd /src TB --- 2011-06-23 11:20:54 - /usr/bin/make -B buildworld World build started on Thu Jun 23 11:20:55 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 23 12:15:11 UTC 2011 TB --- 2011-06-23 12:15:11 - WARNING: no kernel config for LINT TB --- 2011-06-23 12:15:11 - cd /src/sys/arm/conf TB --- 2011-06-23 12:15:11 - /usr/sbin/config -m AVILA TB --- 2011-06-23 12:15:11 - building AVILA kernel TB --- 2011-06-23 12:15:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 12:15:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 12:15:11 - TARGET=arm TB --- 2011-06-23 12:15:11 - TARGET_ARCH=arm TB --- 2011-06-23 12:15:11 - TZ=UTC TB --- 2011-06-23 12:15:11 - __MAKE_CONF=/dev/null TB --- 2011-06-23 12:15:11 - cd /src TB --- 2011-06-23 12:15:11 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Thu Jun 23 12:15:11 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 12:15:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 12:15:50 - ERROR: failed to build AVILA kernel TB --- 2011-06-23 12:15:50 - 2380.55 user 723.12 system 3349.83 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
on 22/06/2011 23:09 Kenneth D. Merry said the following: The GEOM event thread is stuck sleeping in the mtx_sleep() call above. So that tells me that one of several things is going on: - There is a path in the cd(4) driver where it can call cam_periph_hold() but not cam_periph_unhold(). - There is another thread in the system that has called cam_periph_hold(), and has gotten stuck before it can call cam_periph_unhold(). - The hold/unhold logic is broken, and there is a case where a thread waiting for the lock can miss the wakeup. After looking at the code, I don't think this is the case, but I may have missed something. So it is probably one of the first two cases. From the dmesg, I only see cd1 listed, not cd0. So it is possible that cd0 is stuck in the probe code somewhere, and the geom code just gets stuck trying to open it when the probe hasn't completed. Seeing the stack trace for the taskq thread that is running on CPU 0 (process 100014) might be enlightening, it's hard to say. That may or may not show the issue. It's possible that this issue is directly related to the commit in question; perhaps there is an error being returned that wasn't returned before and it isn't being handled right in the cd(4) driver. (The cd(4) driver wasn't touched in the commit.) It's also possible that the commit in question just changed the timing and your system is hitting a race that was there previously. I have a suspicion that this is actually the case. More than once I've seen under qemu that the kernel boot non-deterministically gets stuck in the cd driver. Other people have also bumped into this. E.g., here's one of the reports that I googled up, it's not exactly the same as what ache has reported, but somewhat similar: http://lists.freebsd.org/pipermail/freebsd-current/2010-October/020336.html -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
Apparently there is another problem plain ATA CD/DVD related. With r223443
hangs nature is changed: I see no more waiting in caplck state, just
xpt_thrd waiting in ccb_scan state forever and those repeated messages:
run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config
...
and so on.
On Wed, Jun 22, 2011 at 02:09:19PM -0600, Kenneth D. Merry wrote:
On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
On Tue, Jun 21, 2011 at 09:54:04PM -0600, Kenneth D. Merry wrote:
These two are interesting:
http://img825.imageshack.us/img825/1249/21062011014m.jpg
http://img839.imageshack.us/img839/3791/21062011015.jpg
It looks like the GEOM event thread is stuck inside the cd(4) driver. The
cd(4) driver is trying to acquire the peripheral lock, and is sleeping
until it gets it.
What isn't clear is who is holding it. The ps output shows an idle thread
running on CPU 1, and thread 100014 (taskq) running on CPU 0.
Unfortunately I don't see a stack trace for that. (I might have missed
it.)
Do you happen to have the image with the stack trace for that thread?
I don't have the image because no disks are mounted at that stage and the
swap slice is not attached. But I can issue more specific DDB commands to
narrow it down, just say what you need in detail.
BTW, the machine have 2 DVD both are attached to Marvell IDE plain ATA
interface, they always works before.
Are you sure that something holding the lock? 'show lock' shows absolutely
nothing, it is empty.
Well, after looking at the code a little more, it looks like the lock
that is being held is the periph lock, which is really just a flag.
So 'show lock' wouldn't show anything relevant. Here's cam_periph_hold():
int
cam_periph_hold(struct cam_periph *periph, int priority)
{
int error;
/*
* Increment the reference count on the peripheral
* while we wait for our lock attempt to succeed
* to ensure the peripheral doesn't disappear out
* from user us while we sleep.
*/
if (cam_periph_acquire(periph) != CAM_REQ_CMP)
return (ENXIO);
mtx_assert(periph-sim-mtx, MA_OWNED);
while ((periph-flags CAM_PERIPH_LOCKED) != 0) {
periph-flags |= CAM_PERIPH_LOCK_WANTED;
if ((error = mtx_sleep(periph, periph-sim-mtx, priority,
caplck, 0)) != 0) {
cam_periph_release_locked(periph);
return (error);
}
}
periph-flags |= CAM_PERIPH_LOCKED;
return (0);
}
The GEOM event thread is stuck sleeping in the mtx_sleep() call above. So
that tells me that one of several things is going on:
- There is a path in the cd(4) driver where it can call cam_periph_hold()
but not cam_periph_unhold().
- There is another thread in the system that has called cam_periph_hold(),
and has gotten stuck before it can call cam_periph_unhold().
- The hold/unhold logic is broken, and there is a case where a thread
waiting for the lock can miss the wakeup. After looking at the code, I
don't think this is the case, but I may have missed something.
So it is probably one of the first two cases. From the dmesg, I only see
cd1 listed, not cd0. So it is possible that cd0 is stuck in the probe code
somewhere, and the geom code just gets stuck trying to open it when the
probe hasn't completed.
Seeing the stack trace for the taskq thread that is running on CPU 0
(process 100014) might be enlightening, it's hard to say. That may or may
not show the issue.
It's possible that this issue is directly related to the commit in
question; perhaps there is an error being returned that wasn't returned
before and it isn't being handled right in the cd(4) driver. (The cd(4)
driver wasn't touched in the commit.)
It's also possible that the commit in question just changed the timing and
your system is hitting a race that was there previously.
Ken
--
Kenneth Merry
k...@freebsd.org
--
http://ache.vniz.net/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On Thu, Jun 23, 2011 at 03:51:36PM +0300, Andriy Gapon wrote: More than once I've seen under qemu that the kernel boot non-deterministically gets stuck in the cd driver. Other people have also bumped into this. E.g., here's one of the reports that I googled up, it's not exactly the same as what ache has reported, but somewhat similar: http://lists.freebsd.org/pipermail/freebsd-current/2010-October/020336.html Thread named as xpt_thrd might be of particular interest. See my reply to ken (after applying recent r223443), caplck seems gone, but xpt_thrd waiting forever in ccb_scan with repeated messages: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/pc98
TB --- 2011-06-23 11:20:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 11:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-06-23 11:20:00 - cleaning the object tree TB --- 2011-06-23 11:20:38 - cvsupping the source tree TB --- 2011-06-23 11:20:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-06-23 11:20:55 - building world TB --- 2011-06-23 11:20:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 11:20:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 11:20:55 - TARGET=pc98 TB --- 2011-06-23 11:20:55 - TARGET_ARCH=i386 TB --- 2011-06-23 11:20:55 - TZ=UTC TB --- 2011-06-23 11:20:55 - __MAKE_CONF=/dev/null TB --- 2011-06-23 11:20:55 - cd /src TB --- 2011-06-23 11:20:55 - /usr/bin/make -B buildworld World build started on Thu Jun 23 11:20:56 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 23 13:20:16 UTC 2011 TB --- 2011-06-23 13:20:16 - generating LINT kernel config TB --- 2011-06-23 13:20:16 - cd /src/sys/pc98/conf TB --- 2011-06-23 13:20:16 - /usr/bin/make -B LINT TB --- 2011-06-23 13:20:16 - building LINT kernel TB --- 2011-06-23 13:20:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 13:20:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 13:20:16 - TARGET=pc98 TB --- 2011-06-23 13:20:16 - TARGET_ARCH=i386 TB --- 2011-06-23 13:20:16 - TZ=UTC TB --- 2011-06-23 13:20:16 - __MAKE_CONF=/dev/null TB --- 2011-06-23 13:20:16 - cd /src TB --- 2011-06-23 13:20:16 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 23 13:20:16 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 13:25:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 13:25:16 - ERROR: failed to build lint kernel TB --- 2011-06-23 13:25:16 - 5913.60 user 1126.08 system 7516.08 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On Thu, Jun 23, 2011 at 03:10:20PM +0400, Andrey V. Elsukov wrote: On 23.06.2011 11:54, O. Hartmann wrote: FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config What's up? I backed out r223443 and r223448 and it helped. Are you sure about r223443 one? It seems it does good thing: I still have hang at boot, but no more sleeping in caplck, only xpt_thrd sleeping (forever) in ccb_scan. -- http://ache.vniz.net/ pgpGY6bugeZGR.pgp Description: PGP signature
[head tinderbox] failure on i386/i386
TB --- 2011-06-23 11:20:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 11:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-06-23 11:20:00 - cleaning the object tree TB --- 2011-06-23 11:20:45 - cvsupping the source tree TB --- 2011-06-23 11:20:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-06-23 11:21:00 - building world TB --- 2011-06-23 11:21:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 11:21:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 11:21:00 - TARGET=i386 TB --- 2011-06-23 11:21:00 - TARGET_ARCH=i386 TB --- 2011-06-23 11:21:00 - TZ=UTC TB --- 2011-06-23 11:21:00 - __MAKE_CONF=/dev/null TB --- 2011-06-23 11:21:00 - cd /src TB --- 2011-06-23 11:21:00 - /usr/bin/make -B buildworld World build started on Thu Jun 23 11:21:00 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 23 13:20:53 UTC 2011 TB --- 2011-06-23 13:20:53 - generating LINT kernel config TB --- 2011-06-23 13:20:53 - cd /src/sys/i386/conf TB --- 2011-06-23 13:20:53 - /usr/bin/make -B LINT TB --- 2011-06-23 13:20:54 - building LINT kernel TB --- 2011-06-23 13:20:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 13:20:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 13:20:54 - TARGET=i386 TB --- 2011-06-23 13:20:54 - TARGET_ARCH=i386 TB --- 2011-06-23 13:20:54 - TZ=UTC TB --- 2011-06-23 13:20:54 - __MAKE_CONF=/dev/null TB --- 2011-06-23 13:20:54 - cd /src TB --- 2011-06-23 13:20:54 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 23 13:20:54 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 13:27:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 13:27:04 - ERROR: failed to build lint kernel TB --- 2011-06-23 13:27:04 - 5995.45 user 1120.71 system 7624.00 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on ia64/ia64
TB --- 2011-06-23 12:15:51 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 12:15:51 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-06-23 12:15:51 - cleaning the object tree TB --- 2011-06-23 12:16:09 - cvsupping the source tree TB --- 2011-06-23 12:16:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-06-23 12:16:21 - building world TB --- 2011-06-23 12:16:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 12:16:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 12:16:21 - TARGET=ia64 TB --- 2011-06-23 12:16:21 - TARGET_ARCH=ia64 TB --- 2011-06-23 12:16:21 - TZ=UTC TB --- 2011-06-23 12:16:21 - __MAKE_CONF=/dev/null TB --- 2011-06-23 12:16:21 - cd /src TB --- 2011-06-23 12:16:21 - /usr/bin/make -B buildworld World build started on Thu Jun 23 12:16:21 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 23 13:42:50 UTC 2011 TB --- 2011-06-23 13:42:50 - generating LINT kernel config TB --- 2011-06-23 13:42:50 - cd /src/sys/ia64/conf TB --- 2011-06-23 13:42:50 - /usr/bin/make -B LINT TB --- 2011-06-23 13:42:50 - building LINT kernel TB --- 2011-06-23 13:42:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 13:42:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 13:42:50 - TARGET=ia64 TB --- 2011-06-23 13:42:50 - TARGET_ARCH=ia64 TB --- 2011-06-23 13:42:50 - TZ=UTC TB --- 2011-06-23 13:42:50 - __MAKE_CONF=/dev/null TB --- 2011-06-23 13:42:50 - cd /src TB --- 2011-06-23 13:42:50 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 23 13:42:50 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 13:49:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 13:49:16 - ERROR: failed to build lint kernel TB --- 2011-06-23 13:49:16 - 4380.84 user 863.31 system 5605.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Kernel compile failure in ATH.
Hi Just got this error making a new kernel: cc -c -O -pipe -march=prescott -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c -I/usr/src/sys/dev/ath cc1: warnings being treated as errors /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
@r223471: panic: run_interrupt_driven_config_hooks: waited too long
I last built head at r223421; I upgraded sources to r223471. make buildworld was uneventful; building the kernel demonstrated that I needed the patch from r223474, which I applied (after which building the kernel was also uneventful). Here's a cut/paste from serial console of my build machine (laptop also failed similarly, but serial console is a bot more awkward, and the symptoms look the same anyhow): GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #538 r223471M: Thu Jun 23 05:47:53 PDT 2011 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.21-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Family = f Model = 4 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR AMD Features=0x2010NX,LM TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2081562624 (1985 MB) Event timer LAPIC quality 400 ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard kbd1 at kbdmux0 acpi0: PTLTD RSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pci0: base peripheral at device 1.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 1.0 on pci2 aac0: Enable Raw I/O aac0: New comm. interface enabled aac0: Adaptec 2200S, aac driver 2.1.9-1 aacp0: SCSI Passthrough Bus on aac0 aacp1: SCSI Passthrough Bus on aac0 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.3 port 0x2000-0x203f mem 0xd820-0xd821 irq 54 at device 2.0 on pci3 em0: Ethernet address: 00:30:48:2d:32:6a em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.3 port 0x2040-0x207f mem 0xd822-0xd823 irq 55 at device 2.1 on pci3 em1: Ethernet address: 00:30:48:2d:32:6b pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0 pci5: ACPI PCI bus on pcib5 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 at device 29.0 on pci0 usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 at device 29.1 on pci0 usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 at device 29.2 on pci0 usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 at device 29.3 on pci0 usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci6: ACPI PCI bus on pcib6 vgapci0: VGA-compatible display port 0x3000-0x30ff mem 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Power Button on acpi0 atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0
Re: Kernel compile failure in ATH.
On Thu, Jun 23, 2011 at 03:21:28PM +0200, Ian FREISLICH wrote: Hi Just got this error making a new kernel: You need the patch from r223474: Author: adrian Date: Thu Jun 23 12:11:43 2011 New Revision: 223474 URL: http://svn.freebsd.org/changeset/base/223474 Log: add missing #define for the non-debug case. Modified: head/sys/dev/ath/ath_hal/ah_internal.h Modified: head/sys/dev/ath/ath_hal/ah_internal.h == --- head/sys/dev/ath/ath_hal/ah_internal.h Thu Jun 23 10:43:36 2011 (r223473) +++ head/sys/dev/ath/ath_hal/ah_internal.h Thu Jun 23 12:11:43 2011 (r223474) @@ -529,6 +529,7 @@ extern void DO_HALDEBUG(struct ath_hal * __printflike(3,4); #else #define HALDEBUG(_ah, __m, _fmt, ...) +#define HALDEBUG_G(_ah, __m, _fmt, ...) #endif /* AH_DEBUG */ /* Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp1na7umiL9N.pgp Description: PGP signature
[head tinderbox] failure on amd64/amd64
TB --- 2011-06-23 11:20:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 11:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-06-23 11:20:00 - cleaning the object tree TB --- 2011-06-23 11:20:47 - cvsupping the source tree TB --- 2011-06-23 11:20:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-06-23 11:26:11 - building world TB --- 2011-06-23 11:26:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 11:26:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 11:26:11 - TARGET=amd64 TB --- 2011-06-23 11:26:11 - TARGET_ARCH=amd64 TB --- 2011-06-23 11:26:11 - TZ=UTC TB --- 2011-06-23 11:26:11 - __MAKE_CONF=/dev/null TB --- 2011-06-23 11:26:11 - cd /src TB --- 2011-06-23 11:26:11 - /usr/bin/make -B buildworld World build started on Thu Jun 23 11:26:11 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Thu Jun 23 13:56:31 UTC 2011 TB --- 2011-06-23 13:56:32 - generating LINT kernel config TB --- 2011-06-23 13:56:32 - cd /src/sys/amd64/conf TB --- 2011-06-23 13:56:32 - /usr/bin/make -B LINT TB --- 2011-06-23 13:56:32 - building LINT kernel TB --- 2011-06-23 13:56:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 13:56:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 13:56:32 - TARGET=amd64 TB --- 2011-06-23 13:56:32 - TARGET_ARCH=amd64 TB --- 2011-06-23 13:56:32 - TZ=UTC TB --- 2011-06-23 13:56:32 - __MAKE_CONF=/dev/null TB --- 2011-06-23 13:56:32 - cd /src TB --- 2011-06-23 13:56:32 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 23 13:56:32 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 14:02:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 14:02:13 - ERROR: failed to build lint kernel TB --- 2011-06-23 14:02:13 - 7310.12 user 1473.91 system 9733.17 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
O. Hartmann wrote: With today's update of sources (Revision: 223466 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 223466 Last Changed Date: 2011-06-23 08:55:29 +0200 (Do, 23 Jun 2011)) FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config What's up? SVN rev 223443 broke ATAPI support. SVN rev 223475 should fix it. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-06-23 13:27:05 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 13:27:05 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-06-23 13:27:05 - cleaning the object tree TB --- 2011-06-23 13:27:17 - cvsupping the source tree TB --- 2011-06-23 13:27:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-06-23 13:27:30 - building world TB --- 2011-06-23 13:27:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 13:27:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 13:27:30 - TARGET=powerpc TB --- 2011-06-23 13:27:30 - TARGET_ARCH=powerpc TB --- 2011-06-23 13:27:30 - TZ=UTC TB --- 2011-06-23 13:27:30 - __MAKE_CONF=/dev/null TB --- 2011-06-23 13:27:30 - cd /src TB --- 2011-06-23 13:27:30 - /usr/bin/make -B buildworld World build started on Thu Jun 23 13:27:30 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 23 15:13:01 UTC 2011 TB --- 2011-06-23 15:13:01 - generating LINT kernel config TB --- 2011-06-23 15:13:01 - cd /src/sys/powerpc/conf TB --- 2011-06-23 15:13:01 - /usr/bin/make -B LINT TB --- 2011-06-23 15:13:01 - building LINT kernel TB --- 2011-06-23 15:13:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 15:13:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 15:13:01 - TARGET=powerpc TB --- 2011-06-23 15:13:01 - TARGET_ARCH=powerpc TB --- 2011-06-23 15:13:01 - TZ=UTC TB --- 2011-06-23 15:13:01 - __MAKE_CONF=/dev/null TB --- 2011-06-23 15:13:01 - cd /src TB --- 2011-06-23 15:13:01 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 23 15:13:02 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 15:16:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 15:16:51 - ERROR: failed to build lint kernel TB --- 2011-06-23 15:16:51 - 5354.82 user 1024.17 system 6586.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Thursday 23 June 2011 04:21 am, Ian FREISLICH wrote: Jung-uk Kim wrote: On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote: Can you please try the attached patch? It should disable TSC/TSC-low timecounter for your CPU models, I think. Sorry, I attached a wrong patch. Please ignore the previous one and try this, instead. TSC-low is not presented as an option any more: CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.03-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTR R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,M OVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Event timer LAPIC quality 400 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 atrtc0: AT realtime clock port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer RTC frequency 32768 Hz quality 0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 attimer0: AT timer port 0x40-0x43,0x50-0x53 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 kern.timecounter.choice: TSC(-1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) It's already committed (r223426). Thanks! Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On Wed, Jun 22, 2011 at 02:09:19PM -0600, Kenneth D. Merry wrote: Well, after looking at the code a little more, it looks like the lock that is being held is the periph lock, which is really just a flag. So 'show lock' wouldn't show anything relevant. Here's cam_periph_hold(): With recent r223475 situation returned to what you describe (and still no cd0 in probe). As tracing 18 show, it was cdopen() who calls cam_periph_hold() and sleeps there forever. Tracing 100014 as you suggest shows almost nothing: only fork_trampoline() is there. -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On Thu, Jun 23, 2011 at 06:12:54PM +0300, Alexander Motin wrote: ... SVN rev 223443 broke ATAPI support. SVN rev 223475 should fix it. Thanks -- that did resolve the issue for me. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp5oemRmqK7r.pgp Description: PGP signature
Thoughts on TMPFS no longer being considered highly experimental
Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c (revision 221113) +++ tmpfs_vfsops.c (working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on arm/arm
TB --- 2011-06-23 16:00:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 16:00:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-06-23 16:00:01 - cleaning the object tree TB --- 2011-06-23 16:00:15 - cvsupping the source tree TB --- 2011-06-23 16:00:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-06-23 16:00:37 - building world TB --- 2011-06-23 16:00:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 16:00:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 16:00:37 - TARGET=arm TB --- 2011-06-23 16:00:37 - TARGET_ARCH=arm TB --- 2011-06-23 16:00:37 - TZ=UTC TB --- 2011-06-23 16:00:37 - __MAKE_CONF=/dev/null TB --- 2011-06-23 16:00:37 - cd /src TB --- 2011-06-23 16:00:37 - /usr/bin/make -B buildworld World build started on Thu Jun 23 16:00:37 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 23 16:54:28 UTC 2011 TB --- 2011-06-23 16:54:28 - WARNING: no kernel config for LINT TB --- 2011-06-23 16:54:28 - cd /src/sys/arm/conf TB --- 2011-06-23 16:54:28 - /usr/sbin/config -m AVILA TB --- 2011-06-23 16:54:28 - building AVILA kernel TB --- 2011-06-23 16:54:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 16:54:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 16:54:28 - TARGET=arm TB --- 2011-06-23 16:54:28 - TARGET_ARCH=arm TB --- 2011-06-23 16:54:28 - TZ=UTC TB --- 2011-06-23 16:54:28 - __MAKE_CONF=/dev/null TB --- 2011-06-23 16:54:28 - cd /src TB --- 2011-06-23 16:54:28 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Thu Jun 23 16:54:28 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for AVILA completed on Thu Jun 23 16:57:20 UTC 2011 TB --- 2011-06-23 16:57:20 - cd /src/sys/arm/conf TB --- 2011-06-23 16:57:20 - /usr/sbin/config -m BWCT TB --- 2011-06-23 16:57:20 - building BWCT kernel TB --- 2011-06-23 16:57:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 16:57:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 16:57:20 - TARGET=arm TB --- 2011-06-23 16:57:20 - TARGET_ARCH=arm TB --- 2011-06-23 16:57:20 - TZ=UTC TB --- 2011-06-23 16:57:20 - __MAKE_CONF=/dev/null TB --- 2011-06-23 16:57:20 - cd /src TB --- 2011-06-23 16:57:20 - /usr/bin/make -B buildkernel KERNCONF=BWCT Kernel build for BWCT started on Thu Jun 23 16:57:20 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for BWCT completed on Thu Jun 23 16:59:17 UTC 2011 TB --- 2011-06-23 16:59:17 - cd /src/sys/arm/conf TB --- 2011-06-23 16:59:17 - /usr/sbin/config -m CAMBRIA TB --- 2011-06-23 16:59:18 - building CAMBRIA kernel TB --- 2011-06-23 16:59:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 16:59:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 16:59:18 - TARGET=arm TB --- 2011-06-23 16:59:18 - TARGET_ARCH=arm TB --- 2011-06-23 16:59:18 - TZ=UTC TB --- 2011-06-23 16:59:18 - __MAKE_CONF=/dev/null TB --- 2011-06-23 16:59:18 - cd /src TB --- 2011-06-23 16:59:18 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA Kernel build for CAMBRIA started on Thu Jun 23 16:59:18 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah.c:897: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_setTxQProps': /src/sys/dev/ath/ath_hal/ah.c:870: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_get_mimo_chan_noise': /src/sys/dev/ath/ath_hal/ah.c:1003: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_getChanNoise': /src/sys/dev/ath/ath_hal/ah.c:929: undefined reference to `ath_hal_debug' ah.o:/src/sys/dev/ath/ath_hal/ah.c:223: more undefined references to `ath_hal_debug' follow *** Error code 1 Stop in /obj/arm.arm/src/sys/CAMBRIA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 17:02:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 17:02:23 - ERROR: failed to build CAMBRIA kernel TB --- 2011-06-23 17:02:23 - 2699.52 user 782.00 system 3742.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
Re: Thoughts on TMPFS no longer being considered highly experimental
I gave up on using it after a brief try earlier this year. I can't remember the details, but it did lock up my amd64 system. On Thu, 23 Jun 2011, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c (revision 221113) +++ tmpfs_vfsops.c (working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
On Thu Jun 23 11, Matthew Jacob wrote: I gave up on using it after a brief try earlier this year. I can't remember the details, but it did lock up my amd64 system. On Thu, 23 Jun 2011, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. +1 here. i haven't experienced any issues for 1 year or so, but if people think removing the warning entirely is too early, maybe the warning can be rephrased in order to be less frightening. maybe sth like: TMPFS still needs wider testing and thus should not be considered ready for production use, yet. cheers. alex I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c (revision 221113) +++ tmpfs_vfsops.c (working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } -printf(WARNING: TMPFS is considered to be a highly experimental -feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Jacob wrote: I gave up on using it after a brief try earlier this year. I can't remember the details, but it did lock up my amd64 system. On Thu, 23 Jun 2011, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. There was some issues with sendfile(2) and mmap(2) causing kernel hangs in some cases. vim triggers such hangs for me. However, those problems were fixed and MFCed (afair). I'm using tmpfs on several machines in production without any problems. Maybe being _highly_ experimental for nearly 4 years is enough? :) Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c(revision 221113) +++ tmpfs_vfsops.c(working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } -printf(WARNING: TMPFS is considered to be a highly experimental -feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4Dg1cACgkQwcJ4iSZ1q2m3uACfcUoGrQeAZdAHDm8VnbKInzWI gIoAn3SMoNAdABZ39GHS6HSyIHLXGNIt =aXnk -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
Hi, Sounds good to me. The tmpfs(5) man page should be patched also. -- Craig Rodrigues rodr...@crodrigues.org On Thu, Jun 23, 2011 at 9:31 AM, David O'Brien obr...@freebsd.org wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c (revision 221113) +++ tmpfs_vfsops.c (working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Craig Rodrigues rodr...@rodrigues.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
On 23 June 2011 17:31, David O'Brien obr...@freebsd.org wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c (revision 221113) +++ tmpfs_vfsops.c (working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); -- -- David (obr...@freebsd.org) How about noting that no-one's managed to get it to work correctly with ZFS yet, but fine with UFS? Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
2011/6/23 Alexander V. Chernikov melif...@ipfw.ru: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Jacob wrote: I gave up on using it after a brief try earlier this year. I can't remember the details, but it did lock up my amd64 system. On Thu, 23 Jun 2011, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. There was some issues with sendfile(2) and mmap(2) causing kernel hangs in some cases. vim triggers such hangs for me. However, those problems were fixed and MFCed (afair). I'm using tmpfs on several machines in production without any problems. Maybe being _highly_ experimental for nearly 4 years is enough? :) I think there are still problems with high wired memory consumers like ZFS. I've got 0-sized tmpfs with 8GB RAM + ZFS with 4GB ARC + 4GB swap. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c (revision 221113) +++ tmpfs_vfsops.c (working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4Dg1cACgkQwcJ4iSZ1q2m3uACfcUoGrQeAZdAHDm8VnbKInzWI gIoAn3SMoNAdABZ39GHS6HSyIHLXGNIt =aXnk -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
I may have missed something, but I'm not aware of any serious PRs on TMPFS either. There was some issues with sendfile(2) and mmap(2) causing kernel hangs in some cases. vim triggers such hangs for me. However, those problems were fixed and MFCed (afair). Can you sway when? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c(revision 221113) +++ tmpfs_vfsops.c(working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); The things I am aware of: - there is a races on the lookup. They were papered over in r212305, but the bug was not really fixed, AFAIR. - the tmpfs does double-buffering for the mapped vnodes. This is quite insulting for the memory-backed fs, isn't it ? I have a patch, but it is still under review. - I believe Peter Holm has more test cases that fails with tmpfs. He would have more details. I somewhat remember some panic on execve(2) the binary located on tmpfs. Removing the warning will not make the issues coming away. pgpJs4JMIlpaE.pgp Description: PGP signature
Re: Thoughts on TMPFS no longer being considered highly experimental
On (23/06/2011 20:44), Olivier Smedts wrote: 2011/6/23 Alexander V. Chernikov melif...@ipfw.ru: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Jacob wrote: I gave up on using it after a brief try earlier this year. I can't remember the details, but it did lock up my amd64 system. On Thu, 23 Jun 2011, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. There was some issues with sendfile(2) and mmap(2) causing kernel hangs in some cases. vim triggers such hangs for me. However, those problems were fixed and MFCed (afair). I'm using tmpfs on several machines in production without any problems. Maybe being _highly_ experimental for nearly 4 years is enough? :) I think there are still problems with high wired memory consumers like ZFS. I've got 0-sized tmpfs with 8GB RAM + ZFS with 4GB ARC + 4GB swap. There is a patch to make tmpfs memory management more strict (more aggressive), and set default partition size to half of all memory. http://marc.info/?l=freebsd-fsm=129747362722933w=2 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On 06/23/11 18:29, David Wolfskill wrote: On Thu, Jun 23, 2011 at 06:12:54PM +0300, Alexander Motin wrote: ... SVN rev 223443 broke ATAPI support. SVN rev 223475 should fix it. Thanks -- that did resolve the issue for me. Peace, david Me, too. Thanks, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On 06/23/11 16:57, Hartmann, O. wrote: On 06/23/11 18:29, David Wolfskill wrote: On Thu, Jun 23, 2011 at 06:12:54PM +0300, Alexander Motin wrote: ... SVN rev 223443 broke ATAPI support. SVN rev 223475 should fix it. Thanks -- that did resolve the issue for me. Peace, david Me, too. Thanks, Oliver I'm still having problems with an ATA bus containing a DVD drive and a Zip driver (da). -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
Nathan Whitehorn wrote: I'm still having problems with an ATA bus containing a DVD drive and a Zip driver (da). Can't it be some different problem? What are the symptoms? -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
current status of digi driver
While attempting to upgrade our comm servers from 7.4-RELEASE to 8.2-RELEASE, I discovered that the digi driver didn't make the grade. I searched the archives and found discussions in August 2008 concerning drivers that were disconnected for lack of MPSAFEness. The threads continued right up to the point where it was agreed that the drivers shouldn't be allowed to halt/delay the MPSAFE switch in 8.0-RELEASE. It appears that there was also agreement that (at least) some of the drivers, digi included, would be converted soon after 8.0-RELEASE. The pre-MPSAFE code appears to be included in the most recent -STABLE and -CURRENT, but doesn't get built. The HARDWARE.TXT still includes digi among supported multiport serial device drivers. Is there any plan to bring digi forward? We have about 55 modem ports over ten 8-port Xr cards (PCI) that connect remote sites via dial-up. These work perfectly with 7.4-RELEASE. We would like to see them work perfectly with 8.x-RELEASE or 9.x-RELEASE. I have time and hardware to test with and can help as needed. Thoughts? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On 06/23/11 17:17, Alexander Motin wrote: Nathan Whitehorn wrote: I'm still having problems with an ATA bus containing a DVD drive and a Zip driver (da). Can't it be some different problem? What are the symptoms? Hanging in run_interrupt_driven_config_hooks, immediately after probing the zip drive, which it didn't do before. Here's the end of a verbose boot: pass0 at ata1 bus 0 scbus1 target 0 lun 0 pass0: HITACHI DVD-ROM GD-7000 016J Removable CD-ROM SCSI-0 device pass0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) pass1 at ata1 bus 0 scbus1 target 1 lun 0 pass1: IOMEGA ZIP 100 04.H Removable Direct Access SCSI-0 device pass1: 13.300MB/s transfers (WDMA1, ATAPI 12bytes, PIO 65534bytes) Adding CPU 0, pir=0, awake=1 Waking up CPU 1 (dev=ff83e928) Adding CPU 1, pir=1, awake=1 SMP: AP CPU #1 launched WARNING: WITNESS option enabled, expect reduced performance. (da0:ata1:0:1:0): SCSI status errorG EOM: new disk da(0da0 :ata1:0:1:0):G EROEMA:D nCeAwP AdCiIsTkY (c1d00). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:ata1:0:1:0): CAM status: SCSI Status Error (da0:ata1:0:1:0): SCSI status: Check Condition (da0:ata1:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da0:ata1:0:1:0): Retrying command (per sense data) (cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (cd0:ata1:0:0:0): Retrying command (per sense data) (da0:ata1:0:1:0): SCSI status error (da0:ata1:0:1:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:ata1:0:1:0): CAM status: SCSI Status Error (da0:ata1:0:1:0): SCSI status: Check Condition (da0:ata1:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:ata1:0:1:0): Error 6, Unretryable error da0 at ata1 bus 0 scbus1 target 1 lun 0 da0: IOMEGA ZIP 100 04.H Removable Direct Access SCSI-0 device da0: 13.300MB/s transfers (WDMA1, ATAPI 12bytes, PIO 65534bytes) da0: Attempt to query device size failed: NOT READY, Medium not present [hang] -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on arm/arm
TB --- 2011-06-23 21:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 21:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-06-23 21:50:00 - cleaning the object tree TB --- 2011-06-23 21:50:22 - cvsupping the source tree TB --- 2011-06-23 21:50:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-06-23 21:50:59 - building world TB --- 2011-06-23 21:50:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 21:50:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 21:50:59 - TARGET=arm TB --- 2011-06-23 21:50:59 - TARGET_ARCH=arm TB --- 2011-06-23 21:50:59 - TZ=UTC TB --- 2011-06-23 21:50:59 - __MAKE_CONF=/dev/null TB --- 2011-06-23 21:50:59 - cd /src TB --- 2011-06-23 21:50:59 - /usr/bin/make -B buildworld World build started on Thu Jun 23 21:50:59 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 23 22:44:34 UTC 2011 TB --- 2011-06-23 22:44:35 - WARNING: no kernel config for LINT TB --- 2011-06-23 22:44:35 - cd /src/sys/arm/conf TB --- 2011-06-23 22:44:35 - /usr/sbin/config -m AVILA TB --- 2011-06-23 22:44:35 - building AVILA kernel TB --- 2011-06-23 22:44:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 22:44:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 22:44:35 - TARGET=arm TB --- 2011-06-23 22:44:35 - TARGET_ARCH=arm TB --- 2011-06-23 22:44:35 - TZ=UTC TB --- 2011-06-23 22:44:35 - __MAKE_CONF=/dev/null TB --- 2011-06-23 22:44:35 - cd /src TB --- 2011-06-23 22:44:35 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Thu Jun 23 22:44:35 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for AVILA completed on Thu Jun 23 22:47:54 UTC 2011 TB --- 2011-06-23 22:47:54 - cd /src/sys/arm/conf TB --- 2011-06-23 22:47:54 - /usr/sbin/config -m BWCT TB --- 2011-06-23 22:47:54 - building BWCT kernel TB --- 2011-06-23 22:47:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 22:47:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 22:47:54 - TARGET=arm TB --- 2011-06-23 22:47:54 - TARGET_ARCH=arm TB --- 2011-06-23 22:47:54 - TZ=UTC TB --- 2011-06-23 22:47:54 - __MAKE_CONF=/dev/null TB --- 2011-06-23 22:47:54 - cd /src TB --- 2011-06-23 22:47:54 - /usr/bin/make -B buildkernel KERNCONF=BWCT Kernel build for BWCT started on Thu Jun 23 22:47:54 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for BWCT completed on Thu Jun 23 22:49:54 UTC 2011 TB --- 2011-06-23 22:49:54 - cd /src/sys/arm/conf TB --- 2011-06-23 22:49:54 - /usr/sbin/config -m CAMBRIA TB --- 2011-06-23 22:49:54 - building CAMBRIA kernel TB --- 2011-06-23 22:49:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 22:49:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 22:49:54 - TARGET=arm TB --- 2011-06-23 22:49:54 - TARGET_ARCH=arm TB --- 2011-06-23 22:49:54 - TZ=UTC TB --- 2011-06-23 22:49:54 - __MAKE_CONF=/dev/null TB --- 2011-06-23 22:49:54 - cd /src TB --- 2011-06-23 22:49:54 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA Kernel build for CAMBRIA started on Thu Jun 23 22:49:54 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah.c:897: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_setTxQProps': /src/sys/dev/ath/ath_hal/ah.c:870: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_get_mimo_chan_noise': /src/sys/dev/ath/ath_hal/ah.c:1003: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_getChanNoise': /src/sys/dev/ath/ath_hal/ah.c:929: undefined reference to `ath_hal_debug' ah.o:/src/sys/dev/ath/ath_hal/ah.c:223: more undefined references to `ath_hal_debug' follow *** Error code 1 Stop in /obj/arm.arm/src/sys/CAMBRIA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 22:52:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 22:52:35 - ERROR: failed to build CAMBRIA kernel TB --- 2011-06-23 22:52:35 - 2690.85 user 772.94 system 3754.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
Re: current status of digi driver
On Thu, 23 Jun 2011, David Boyd wrote: While attempting to upgrade our comm servers from 7.4-RELEASE to 8.2-RELEASE, I discovered that the digi driver didn't make the grade. I searched the archives and found discussions in August 2008 concerning drivers that were disconnected for lack of MPSAFEness. The threads continued right up to the point where it was agreed that the drivers shouldn't be allowed to halt/delay the MPSAFE switch in 8.0-RELEASE. It appears that there was also agreement that (at least) some of the drivers, digi included, would be converted soon after 8.0-RELEASE. The pre-MPSAFE code appears to be included in the most recent -STABLE and -CURRENT, but doesn't get built. The HARDWARE.TXT still includes digi among supported multiport serial device drivers. Is there any plan to bring digi forward? [snip] I have time and hardware to test with and can help as needed. Patches have been submitted in the last week to update the digi(4) driver to work with the new TTY layer. If you are able to spend some time testing them on 9-CURRENT, there is a possibility that there may still be time to get them into the tree before 9.0-RELEASE. The patches can be found in kern/158086. Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: misc/157903: automated kldload for USB class devices
Hi, I need some people testing the following patch: http://svn.freebsd.org/changeset/base/223486 svn up and build a new kernel. Try to remove all USB devices from kernel config except the host controllers and USB keyboard. Then put the following file into /etc/devd/ http://hselasky.homeunix.org:8192/bus_auto.conf MD5 (bus_auto.conf) = 4a1130910cdbe0a5d3eca86b0b12f533 Verify using kldstat that modules are loaded when you plug a new USB device. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On 6/22/11 4:09 PM, Kenneth D. Merry wrote: On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote: On Tue, Jun 21, 2011 at 09:54:04PM -0600, Kenneth D. Merry wrote: These two are interesting: http://img825.imageshack.us/img825/1249/21062011014m.jpg http://img839.imageshack.us/img839/3791/21062011015.jpg It looks like the GEOM event thread is stuck inside the cd(4) driver. The cd(4) driver is trying to acquire the peripheral lock, and is sleeping until it gets it. What isn't clear is who is holding it. ... The GEOM event thread is stuck sleeping in the mtx_sleep() call above. So that tells me that one of several things is going on: - There is a path in the cd(4) driver where it can call cam_periph_hold() but not cam_periph_unhold(). - There is another thread in the system that has called cam_periph_hold(), and has gotten stuck before it can call cam_periph_unhold(). - The hold/unhold logic is broken, and there is a case where a thread waiting for the lock can miss the wakeup. After looking at the code, I don't think this is the case, but I may have missed something. So it is probably one of the first two cases. ... I have a theory for the cause of this hang. The commit that triggers this problem added calls to g_access() during the geom_dev probe. I believe this hit a race in cdregister() where the periph hold lock is dropped around the changer probe code. Why the periph hold lock is dropped there, I do not know as I haven't fully reviewed the changer probe code. The drop of the lock in cdregister() can allow geom classes to probe and thus call g_access()-g_disk_access()-cdopen() before a probe is initiated in the normal way by cdregister(). cdopen() checks for media presence by issuing immediate ccds. When the race is exploited, the peripheral will be in the probe state when the immediate ccbs are requested. This will cause the device probe to be performed before the immediate ccd is returned. When the cdopen() activity finally unwinds, cdregister() will again take the periph hold lock and schedule the peripheral, expecting probe processing to complete and release the hold lock. However, since the periph is already in the normal state (due to the successful probe performed indirectly by the cdopen() call), that unlock never happens, thus wedging the device. To test this theory, apply the following patch. I do not know if this is safe for changer devices, but I will review the changer code if this patch fixes ache's problem. -- Justin --- //depot/vendor/FreeBSD/head/sys/cam/scsi/scsi_cd.c 2011-05-07 10:06:43.0 -0600 +++ /home/justing/perforce/vendor/FreeBSD/head/sys/cam/scsi/scsi_cd.c 2011-05-07 10:06:43.0 -0600 @@ -687,6 +687,10 @@ else softc-minimum_command_size = 6; + /* +* Refcount and block open attempts until we are setup +* Can't block +*/ (void)cam_periph_hold(periph, PRIBIO); cam_periph_unlock(periph); /* @@ -747,7 +751,6 @@ softc-disk-d_hba_subdevice = cpi.hba_subdevice; disk_create(softc-disk, DISK_VERSION); cam_periph_lock(periph); - cam_periph_unhold(periph); /* * Add an async callback so that we get @@ -972,12 +975,6 @@ cdregisterexit: - /* -* Refcount and block open attempts until we are setup -* Can't block -*/ - (void)cam_periph_hold(periph, PRIBIO); - if ((softc-flags CD_FLAG_CHANGER) == 0) xpt_schedule(periph, CAM_PRIORITY_DEV); else ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: misc/157903: automated kldload for USB class devices
On Friday 24 June 2011 04:37:25 Hans Petter Selasky wrote: Hi, I need some people testing the following patch: http://svn.freebsd.org/changeset/base/223486 svn up and build a new kernel. Try to remove all USB devices from kernel config except the host controllers and USB keyboard. Then put the following file into /etc/devd/ http://hselasky.homeunix.org:8192/bus_auto.conf MD5 (bus_auto.conf) = 4a1130910cdbe0a5d3eca86b0b12f533 Verify using kldstat that modules are loaded when you plug a new USB device. --HPS Hi, Turns out some additional patches were needed: http://svn.freebsd.org/changeset/base/223489 Please try again. Updated bus_auto.conf: http://hselasky.homeunix.org:8192/bus_auto.conf MD5 (/etc/devd/bus_auto.conf) = c321d1801f0fa3c6260eeef7061330e8 --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on arm/arm
TB --- 2011-06-24 03:40:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-24 03:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-06-24 03:40:00 - cleaning the object tree TB --- 2011-06-24 03:40:20 - cvsupping the source tree TB --- 2011-06-24 03:40:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-06-24 03:40:58 - building world TB --- 2011-06-24 03:40:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 03:40:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 03:40:58 - TARGET=arm TB --- 2011-06-24 03:40:58 - TARGET_ARCH=arm TB --- 2011-06-24 03:40:58 - TZ=UTC TB --- 2011-06-24 03:40:58 - __MAKE_CONF=/dev/null TB --- 2011-06-24 03:40:58 - cd /src TB --- 2011-06-24 03:40:58 - /usr/bin/make -B buildworld World build started on Fri Jun 24 03:40:58 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Jun 24 04:35:32 UTC 2011 TB --- 2011-06-24 04:35:33 - WARNING: no kernel config for LINT TB --- 2011-06-24 04:35:33 - cd /src/sys/arm/conf TB --- 2011-06-24 04:35:33 - /usr/sbin/config -m AVILA TB --- 2011-06-24 04:35:33 - building AVILA kernel TB --- 2011-06-24 04:35:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 04:35:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 04:35:33 - TARGET=arm TB --- 2011-06-24 04:35:33 - TARGET_ARCH=arm TB --- 2011-06-24 04:35:33 - TZ=UTC TB --- 2011-06-24 04:35:33 - __MAKE_CONF=/dev/null TB --- 2011-06-24 04:35:33 - cd /src TB --- 2011-06-24 04:35:33 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Fri Jun 24 04:35:33 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for AVILA completed on Fri Jun 24 04:38:24 UTC 2011 TB --- 2011-06-24 04:38:24 - cd /src/sys/arm/conf TB --- 2011-06-24 04:38:24 - /usr/sbin/config -m BWCT TB --- 2011-06-24 04:38:24 - building BWCT kernel TB --- 2011-06-24 04:38:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 04:38:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 04:38:24 - TARGET=arm TB --- 2011-06-24 04:38:24 - TARGET_ARCH=arm TB --- 2011-06-24 04:38:24 - TZ=UTC TB --- 2011-06-24 04:38:24 - __MAKE_CONF=/dev/null TB --- 2011-06-24 04:38:24 - cd /src TB --- 2011-06-24 04:38:24 - /usr/bin/make -B buildkernel KERNCONF=BWCT Kernel build for BWCT started on Fri Jun 24 04:38:24 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for BWCT completed on Fri Jun 24 04:40:50 UTC 2011 TB --- 2011-06-24 04:40:50 - cd /src/sys/arm/conf TB --- 2011-06-24 04:40:50 - /usr/sbin/config -m CAMBRIA TB --- 2011-06-24 04:40:50 - building CAMBRIA kernel TB --- 2011-06-24 04:40:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 04:40:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 04:40:50 - TARGET=arm TB --- 2011-06-24 04:40:50 - TARGET_ARCH=arm TB --- 2011-06-24 04:40:50 - TZ=UTC TB --- 2011-06-24 04:40:50 - __MAKE_CONF=/dev/null TB --- 2011-06-24 04:40:50 - cd /src TB --- 2011-06-24 04:40:50 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA Kernel build for CAMBRIA started on Fri Jun 24 04:40:50 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah.c:897: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_setTxQProps': /src/sys/dev/ath/ath_hal/ah.c:870: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_get_mimo_chan_noise': /src/sys/dev/ath/ath_hal/ah.c:1003: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_getChanNoise': /src/sys/dev/ath/ath_hal/ah.c:929: undefined reference to `ath_hal_debug' ah.o:/src/sys/dev/ath/ath_hal/ah.c:223: more undefined references to `ath_hal_debug' follow *** Error code 1 Stop in /obj/arm.arm/src/sys/CAMBRIA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-24 04:43:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-24 04:43:35 - ERROR: failed to build CAMBRIA kernel TB --- 2011-06-24 04:43:35 - 2733.97 user 781.89 system 3815.13 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
Re: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On Jun 23, 2011, at 9:01 PM, Justin T. Gibbs wrote:
On 6/22/11 4:09 PM, Kenneth D. Merry wrote:
On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
On Tue, Jun 21, 2011 at 09:54:04PM -0600, Kenneth D. Merry wrote:
These two are interesting:
http://img825.imageshack.us/img825/1249/21062011014m.jpg
http://img839.imageshack.us/img839/3791/21062011015.jpg
It looks like the GEOM event thread is stuck inside the cd(4)
driver. The
cd(4) driver is trying to acquire the peripheral lock, and is sleeping
until it gets it.
What isn't clear is who is holding it.
...
The GEOM event thread is stuck sleeping in the mtx_sleep() call above. So
that tells me that one of several things is going on:
- There is a path in the cd(4) driver where it can call cam_periph_hold()
but not cam_periph_unhold().
- There is another thread in the system that has called cam_periph_hold(),
and has gotten stuck before it can call cam_periph_unhold().
- The hold/unhold logic is broken, and there is a case where a thread
waiting for the lock can miss the wakeup. After looking at the code, I
don't think this is the case, but I may have missed something.
So it is probably one of the first two cases.
...
I have a theory for the cause of this hang.
The commit that triggers this problem added calls to g_access() during the
geom_dev probe. I believe this hit a race in cdregister() where
the periph hold lock is dropped around the changer probe code. Why the
periph hold lock is dropped there, I do not know as I haven't fully
reviewed the changer probe code.
Are you talking about this?
disk_create(softc-disk, DISK_VERSION);
cam_periph_lock(periph);
cam_periph_unhold(periph);
[...]
if (((cgd-ccb_h.target_lun 0)
((softc-quirks CD_Q_NO_CHANGER) == 0))
|| ((softc-quirks CD_Q_CHANGER) != 0)) {
The unhold there compliments the hold that was done prior to disk_create().
The hold/unhold is done as a hack around the need to drop the periph/sim mutex
while calling disk_create(), due to the later's insistence on using blocking
calls. I've wanted to re-think how that pattern is done (it's the same gross
hack in nearly all of the periph drivers), but haven't gotten around to it. If
the 'hold' semaphore needs to be held longer to prevent the race that you're
theorizing, then it should be possible to simply extend its coverage in the
code block, but I'm not sure if it'll result in an unintended deadlock with the
changer enumeration/matching code. I _think_ that it'll be ok, but the density
of magic in the code is a bit overwhelming at this time of night =-)
Scott
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
