Re: Time keeping Issues with the low-resolution TSC timecounter
On Friday 17 June 2011 02:54 pm, Jung-uk Kim wrote: On Friday 17 June 2011 01:45 pm, Ian FREISLICH wrote: Jung-uk Kim wrote: On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: Jung-uk Kim wrote: 1481522037144590601.0098392393 1495969404144473671.0090225853 As you can see, HPET increases normally (within errors from sleep(3) accuracy, syscall overhead, etc.) but TSC-low is totally erratic (and too low). I don't know how this can happen, though. :-( I need some time to figure it out. Even though sleep states have been disabled in the past when on AC power, they seem to have mysteriously been enabled. Perhaps this accounts for the strangeness: /etc/rc.conf performance_cx_lowest=HIGH performance_cpu_freq=HIGH economy_cx_lowest=LOW economy_cpu_freq=HIGH [mini] /usr/home/ianf $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1600 dev.cpu.0.freq_levels: 1600/2000 1400/1750 1333/1533 1166/1341 1066/1066 932/932 800/600 700/525 600/450 500/375 400/300 300/225 200/150 100/75 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 8.69% 91.30% last 693us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 14.96% 85.03% last 2897us Pulling the power cord and re-inserting it has the cx_lowest correctly trantsition to C1 and then TSC-low behaves properly as the system timecounter. But, time will be wierd when on battery. In light of this, I doubt the patch in your other email will have any effect. Perhaps the thing to do is to have the timecounter code aware of the lowest Cx sleep state and to pick best time counter for that state and to re-evaluate the choice on cx_lowest transitions. ie: TSC-low, HPET or ACPI-fast for C1 and HPET or ACPI-fast for C2 and lower. Hmm... So, you are saying this CPU model is P-state invariant but not C-state invariant (i.e., it stops incrementing in C2 state and above). If that's the case, it is really useless for timecounter. :-( What happens if you set it to C2, i.e., economy_cx_lowest=C2 In other words, does it really stop in C2-state? The folowing is with timecounter=HPET, just to see what the effect on TSC-low is. It looks like it does stop in C3. hw.acpi.cpu.cx_lowest=C3 [mini] /usr/home/ianf $ sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1)); sysctl kern.timecounter.tc.TSC-low.counter; sleep 1; done' kern.timecounter.tc.TSC-low.counter: 722687906 kern.timecounter.tc.TSC-low.counter: 724328394 kern.timecounter.tc.TSC-low.counter: 726038743 kern.timecounter.tc.TSC-low.counter: 727690855 kern.timecounter.tc.TSC-low.counter: 729245616 kern.timecounter.tc.TSC-low.counter: 730786569 kern.timecounter.tc.TSC-low.counter: 732398571 kern.timecounter.tc.TSC-low.counter: 733910987 kern.timecounter.tc.TSC-low.counter: 735711469 kern.timecounter.tc.TSC-low.counter: 737368279 hw.acpi.cpu.cx_lowest=C2 kern.timecounter.tc.TSC-low.counter: 897318486 kern.timecounter.tc.TSC-low.counter: 909873821 kern.timecounter.tc.TSC-low.counter: 922416894 kern.timecounter.tc.TSC-low.counter: 934960462 kern.timecounter.tc.TSC-low.counter: 947504154 kern.timecounter.tc.TSC-low.counter: 960050573 kern.timecounter.tc.TSC-low.counter: 972590754 kern.timecounter.tc.TSC-low.counter: 985133990 kern.timecounter.tc.TSC-low.counter: 997677052 kern.timecounter.tc.TSC-low.counter: 1010220299 CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.04-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,M TR R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,P BE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM ,M OVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Thanks for the info, it confirmed my speculation. Somewhere from an Intel manual, I think I read TSC stops when DPSLP# pin is asserted for Core/Core2/Atom processors and I guess that means entering C3 stops TSC. :-( Can you please try the attached patch? It should disable TSC/TSC-low timecounter for your CPU models, I think. Sorry for the delay, Jung-uk Kim Index: sys/dev/acpica/acpi_cpu.c === --- sys/dev/acpica/acpi_cpu.c (revision 223372) +++ sys/dev/acpica/acpi_cpu.c (working copy) @@
Re: Time keeping Issues with the low-resolution TSC timecounter
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.
Jung-uk Kim
Index: sys/dev/acpica/acpi_cpu.c
===
--- sys/dev/acpica/acpi_cpu.c (revision 223372)
+++ sys/dev/acpica/acpi_cpu.c (working copy)
@@ -856,6 +856,8 @@ acpi_cpu_cx_list(struct acpi_cpu_softc *sc)
sbuf_printf(sb, C%d/%d , i + 1, sc-cpu_cx_states[i].trans_lat);
if (sc-cpu_cx_states[i].type ACPI_STATE_C3)
sc-cpu_non_c3 = i;
+ else
+ cpu_can_deep_sleep = 1;
}
sbuf_trim(sb);
sbuf_finish(sb);
Index: sys/kern/kern_clocksource.c
===
--- sys/kern/kern_clocksource.c (revision 223372)
+++ sys/kern/kern_clocksource.c (working copy)
@@ -59,6 +59,7 @@ __FBSDID($FreeBSD$);
cyclic_clock_func_tcyclic_clock_func = NULL;
#endif
+intcpu_can_deep_sleep = 0; /* C3 state is available. */
intcpu_disable_deep_sleep = 0; /* Timer dies in C3. */
static voidsetuptimer(void);
Index: sys/sys/systm.h
===
--- sys/sys/systm.h (revision 223372)
+++ sys/sys/systm.h (working copy)
@@ -253,6 +253,7 @@ voidcpu_startprofclock(void);
void cpu_stopprofclock(void);
void cpu_idleclock(void);
void cpu_activeclock(void);
+extern int cpu_can_deep_sleep;
extern int cpu_disable_deep_sleep;
intcr_cansee(struct ucred *u1, struct ucred *u2);
Index: sys/x86/x86/tsc.c
===
--- sys/x86/x86/tsc.c (revision 223372)
+++ sys/x86/x86/tsc.c (working copy)
@@ -444,6 +444,19 @@ init_TSC_tc(void)
goto init;
}
+ /*
+* We cannot use the TSC if it stops incrementing in deep sleep.
+* Currently only Intel CPUs are known for this problem unless
+* the invariant TSC bit is set.
+*/
+ if (cpu_can_deep_sleep cpu_vendor_id == CPU_VENDOR_INTEL
+ (amd_pminfo AMDPM_TSC_INVARIANT) == 0) {
+ tsc_timecounter.tc_quality = -1000;
+ if (bootverbose)
+ printf(TSC timecounter disabled: C3 enabled.\n);
+ goto init;
+ }
+
#ifdef SMP
/*
* We can not use the TSC in SMP mode unless the TSCs on all CPUs are
___
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 j...@freebsd.org 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. Works for me: fk@r500 ~ $dmesg | grep TSC Calibrating TSC clock ... TSC clock: 1995045800 Hz 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 TSC: P-state invariant, performance statistics TSC timecounter disabled: C3 enabled. Timecounter TSC frequency 1995045800 Hz quality -1000 Thanks a lot. Fabian signature.asc Description: PGP signature
[head tinderbox] failure on ia64/ia64
TB --- 2011-06-21 21:38:22 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-21 21:38:22 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-06-21 21:38:22 - cleaning the object tree TB --- 2011-06-21 21:38:44 - cvsupping the source tree TB --- 2011-06-21 21:38:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-06-21 21:38:58 - building world TB --- 2011-06-21 21:38:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-21 21:38:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-21 21:38:58 - TARGET=ia64 TB --- 2011-06-21 21:38:58 - TARGET_ARCH=ia64 TB --- 2011-06-21 21:38:58 - TZ=UTC TB --- 2011-06-21 21:38:58 - __MAKE_CONF=/dev/null TB --- 2011-06-21 21:38:58 - cd /src TB --- 2011-06-21 21:38:58 - /usr/bin/make -B buildworld World build started on Tue Jun 21 21:38: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 Tue Jun 21 23:04:39 UTC 2011 TB --- 2011-06-21 23:04:39 - generating LINT kernel config TB --- 2011-06-21 23:04:39 - cd /src/sys/ia64/conf TB --- 2011-06-21 23:04:39 - /usr/bin/make -B LINT TB --- 2011-06-21 23:04:39 - building LINT kernel TB --- 2011-06-21 23:04:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-21 23:04:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-21 23:04:39 - TARGET=ia64 TB --- 2011-06-21 23:04:39 - TARGET_ARCH=ia64 TB --- 2011-06-21 23:04:39 - TZ=UTC TB --- 2011-06-21 23:04:39 - __MAKE_CONF=/dev/null TB --- 2011-06-21 23:04:39 - cd /src TB --- 2011-06-21 23:04:39 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Jun 21 23:04:39 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/acpica/acpi_resource.c:350: warning: format '%x' expects type 'unsigned int', but argument 8 has type 'UINT64' [-Wformat] /src/sys/dev/acpica/acpi_resource.c:350: warning: format '%d' expects type 'int', but argument 9 has type 'UINT64' [-Wformat] /src/sys/dev/acpica/acpi_resource.c:356: warning: format '%x' expects type 'unsigned int', but argument 8 has type 'UINT64' [-Wformat] /src/sys/dev/acpica/acpi_resource.c:356: warning: format '%x' expects type 'unsigned int', but argument 9 has type 'UINT64' [-Wformat] /src/sys/dev/acpica/acpi_resource.c:356: warning: format '%d' expects type 'int', but argument 10 has type 'UINT64' [-Wformat] /src/sys/dev/acpica/acpi_resource.c:360: warning: format '%x' expects type 'unsigned int', but argument 8 has type 'UINT64' [-Wformat] /src/sys/dev/acpica/acpi_resource.c:360: warning: format '%x' expects type 'unsigned int', but argument 9 has type 'UINT64' [-Wformat] /src/sys/dev/acpica/acpi_resource.c:360: warning: format '%d' expects type 'int', but argument 10 has type 'UINT64' [-Wformat] *** 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-21 23:09:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-21 23:09:35 - ERROR: failed to build lint kernel TB --- 2011-06-21 23:09:35 - 4255.98 user 848.02 system 5472.82 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
Re: CFT: msk(4) 64bit DMA support
On Sun, Jun 05, 2011 at 02:23:57PM -0400, David Schultz wrote: 85;95;0cOn Thu, May 26, 2011, YongHyeon PYUN wrote: Here is a patch that implements 64bit DMA on msk(4). If you use msk(4) on a system that has more than 4GB memory, please try the patch at the following URL and let me know whether it works or not. You need latest msk(4) in HEAD to apply the patch. http://people.freebsd.org/~yongari/msk/msk.64bit.dma.diff Previously msk(4) may have used bounce buffers on systems that have more than 4GB memory. You can verify whether msk(4) is using bounce buffers by checking the output of sysctl hw.busdma. For instance, hw.busdma.zone0.total_bounced counter would increase while network operation is in progress. If patch above works you wouldn't see the counter change anymore and it would also enhance network performance since it wouldn't have to copy from or to bounce buffers. Sorry for late reply. After applying this patch, I still see total_bounced increasing: hw.busdma.zone0.total_bounced: 441 Hmm, I guess it could be caused by other drivers in the system. Can you verify whether all other drivers in the system use 64bit DMA? I think just testing msk(4) with netperf/iperf will make it clear (i.e. no disk access). Note that I have MSI disabled to work around some issues with the card becoming wedged: hw.pci.enable_msix=0 hw.pci.enable_msi=0 MSI has nothing to do with 64bit DMA. Possibly relevant bits of dmesg: FreeBSD 9.0-CURRENT #4 r222717M: Sun Jun 5 12:27:07 EDT 2011 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (3000.06-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 6 Model = 17 Stepping = 6 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=0x8e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8246677504 (7864 MB) Event timer LAPIC quality 400 ACPI APIC Table: IntelR AWRDACPI FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) ioapic0: Changing APIC ID to 4 ioapic0 Version 2.0 irqs 0-23 on motherboard mskc0: Marvell Yukon 88E8053 Gigabit Ethernet port 0xae00-0xaeff mem 0xfdefc000-0xfdef irq 17 at device 0.0 on pci4 msk0: Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02 on mskc0 msk0: Ethernet address: 00:01:29:a3:3c:a3 miibus0: MII bus on msk0 e1000phy0: Marvell 88E Gigabit PHY PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow msk0: link state changed to UP ___ 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: atkbdc broken on current ?
On 2011/05/05 21:21, Damjan Marion wrote: Hi, I have issue with old HP DL380G3 server. When I use ILO virtual console to manage server. Seems that 9-CURRENT fails to detect atkbdc. When I boot 8.2-RELEASE it works well. 8.2 dmesg shows: atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 9.0: atkbdc0: Keyboard controller (i8042) failed to probe at port 0x60 on isa0 Is this a known issue? Should I enable some additional outputs, like KBDIO_DEBUG? Thanks, Damjan One problem I found is if I remove PS/2 keyboard and use a USB keyboard, I can not use PS/2 mouse, it will not be detected. David Xu ___ 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 00:49:34 +0400, Andrey Chernov wrote: On Tue, Jun 21, 2011 at 10:17:19AM -0600, Kenneth D. Merry wrote: ps alltrace show locks show msgbuf Hopefully that will give us something to start looking at... This would really work a lot better if there is any way to get a serial console on the machine. The above will produce a good bit of output, and would likely need a lot of pictures. Since we can't reproduce the problem here, some debugging help would be greatly appreciated. Sorry I have no serial console. Here are the photos. I remove very similar looking USB parts from 'ps' and 'alltrace', and very general parts from 'alltrace' always been there. I hope remaining info will be enough. USB hotplagging works at this stage, so no reason to look there. If it will be not enough, I'll upload whole series. Thanks for uploading all of the photos. That's a lot of work, but they are helpful... I think I see part of the problem, but not the whole problem: 'show lock' outputs nothing, it means no locks just sleep somewhere forever. 'ps': http://img43.imageshack.us/img43/1424/21062011001j.jpg http://img835.imageshack.us/img835/6607/21062011002.jpg http://img841.imageshack.us/img841/5401/21062011003.jpg 'alltrace': http://img864.imageshack.us/img864/6757/21062011004ya.jpg http://img542.imageshack.us/img542/4857/21062011005.jpg http://img828.imageshack.us/img828/823/21062011006.jpg http://img5.imageshack.us/img5/910/21062011007.jpg http://img7.imageshack.us/img7/4704/21062011008.jpg http://img848.imageshack.us/img848/5487/21062011009.jpg http://img641.imageshack.us/img641/2/21062011010.jpg http://img7.imageshack.us/img7/7946/21062011011.jpg http://img860.imageshack.us/img860/8185/21062011012.jpg http://img696.imageshack.us/img696/5276/21062011013.jpg 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? http://img594.imageshack.us/img594/1773/21062011016.jpg http://img109.imageshack.us/img109/9937/21062011017.jpg http://img51.imageshack.us/img51/6047/21062011018l.jpg 'show msgbuf': http://img59.imageshack.us/img59/46/21062011019.jpg http://img189.imageshack.us/img189/483/21062011020.jpg http://img19.imageshack.us/img19/8163/21062011021.jpg http://img683.imageshack.us/img683/3171/21062011022.jpg http://img819.imageshack.us/img819/5923/21062011023.jpg http://img692.imageshack.us/img692/3789/21062011024.jpg http://img580.imageshack.us/img580/1550/21062011025.jpg http://img560.imageshack.us/img560/7478/21062011026.jpg http://img94.imageshack.us/img94/9371/21062011027.jpg http://img857.imageshack.us/img857/5185/21062011028.jpg Thanks, Ken -- Kenneth Merry k...@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: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
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. -- 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)
Remove cd/acd from your kernel config to see if that allows you to boot? I unplug DVDs physically and kernel finally boots! BTW both DVDs was empty during the hanged boot and works normally under Win7. -- 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
Reproducible panic with TRIM and ufs snapshots
Hi, I encountered a panic in the 2011/05 snapshot of 9-current. Snapshot creation an UFS filesystem with or without SU+J leads to panic: % mdconfig -a -t malloc -s 128m % newfs -U -O2 -t /dev/md0 % mount /dev/md0 /mnt % mksnap_ffs /mnt /mnt/foo = panic My system is: fbsd-vbox# uname -a FreeBSD fbsd-vbox.lan 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu May 12 11:28:09 UTC 2011 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i38 The panic message and the backtrace (starting at stack level 11) are: Fatal trap 18: integer divide fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0xc0cd493b stack pointer = 0x28:0xd612b3d0 frame pointer = 0x28:0xd612b444 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1172 (mksnap_ffs) Physical memory: 495 MB Dumping 97 MB: 82 66 50 34 18 2 #0 doadump () at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:244 #1 0xc04dda49 in db_fncall (dummy1=1, dummy2=0, dummy3=-1055234816, dummy4=0xd612b19c ) at /usr/src/sys/ddb/db_command.c:548 #2 0xc04dde41 in db_command (last_cmdp=0xc0fccbfc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04ddf9a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04dff1d in db_trap (type=18, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc09d9ad2 in kdb_trap (type=18, code=0, tf=0xd612b390) at /usr/src/sys/kern/subr_kdb.c:533 #6 0xc0ccab4f in trap_fatal (frame=0xd612b390, eva=0) at /usr/src/sys/i386/i386/trap.c:958 #7 0xc0ccb58c in trap (frame=0xd612b390) at /usr/src/sys/i386/i386/trap.c:754 #8 0xc0cb422c in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #9 0xc0cd493b in __qdivrem (uq=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/libkern/qdivrem.c:97 #10 0xc0cd4861 in __moddi3 (a=1245184, b=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/libkern/moddi3.c:60 #11 0xc093c01c in g_io_request (bp=0xc4388dac, cp=0xc3c8fcc0) at /usr/src/sys/geom/geom_io.c:427 #12 0xc0bac655 in ffs_blkfree (ump=0xc4a39800, fs=0xd0844000, devvp=0xc3c8fcc0, bno=608, size=16384, inum=4, dephd=0x0) at /usr/src/sys/ufs/ffs/ffs_alloc.c:2066 #13 0xc0bb872a in mapacct_ufs2 (vp=0xc3c8fcc0, oldblkp=0xc68e9790, lastblkp=0xc68e97d0, fs=0xd0844000, lblkno=4, expungetype=2) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1533 #14 0xc0bba338 in expunge_ufs2 (snapvp=0xc3c8fcc0, cancelip=0xc68e789c, fs=0xd0844000, acctfunc=0xc0bb8640 mapacct_ufs2, expungetype=2, clearmode=0) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1330 #15 0xc0bbe7e5 in ffs_snapshot (mp=0xc4b7cca8, snapfile=0xc365d300 /mnt/tut) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:747 #16 0xc0bd7900 in ffs_mount (mp=0xc4b7cca8) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:395 #17 0xc0a361c6 in vfs_donmount (td=0xc34e8b80, fsflags=2166784, fsoptions=0xc3624000) at /usr/src/sys/kern/vfs_mount.c:924 #18 0xc0a36804 in nmount (td=0xc34e8b80, uap=0xd612bcec) at /usr/src/sys/kern/vfs_mount.c:409 #19 0xc09e7c13 in syscallenter (td=0xc34e8b80, sa=0xd612bce4) at /usr/src/sys/kern/subr_trap.c:344 #20 0xc0ccadd4 in syscall (frame=0xd612bd28) at /usr/src/sys/i386/i386/trap.c:1082 #21 0xc0cb4291 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 #22 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) More information can be provided if necessary. -- Homepage: www.yamagi.org Jabber: yam...@yamagi.org GnuPG/GPG:0xEFBCCBCB ___ 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: [PATCH] ipfw call/return rule actions
On Tue, Jun 21, 2011 at 10:22:40AM +, Vadim Goncharov wrote: Hi, I have made a patch http://nuclight.avtf.net/vadim/ipfw_call_20110620.diff which adds a call and return rule actions to make it possible to organize subroutines with rules - skipto is like goto and only allows jumps forward, not backward. This could be useful to help doing somewaht like per-interface ACL, something similar to pf anchors or iptables chains. Please test, hope to see this committed soon and released in 9.0 ! nice function and nice implementation. It does not affect any existing ruleset etc. so it should really be an easy addition, even if we don't make it for 9.0 there are no ABI issues to be worried about. By chance have you tried to measure the cost of a call/return pair ? cheers luigi Sample ipfw list: 00500 call 2000 ip from 10.0.0.5 to any 00600 count log ip from 10.0.0.5 to any 00999 allow ip from any to any 02000 count ip from any to any // entry of subr 02100 count log ip from any to any 02999 return log ip from any to any // leave subr 03600 count log ip from 10.0.0.5 to any 65534 allow ip from any to any 65535 deny ip from any to any Here after 2999 packet continues from 501, next number after call. Or this could be used to reduce number of rules when previously one did many skipto's for each direction/interface and had to repeat the same rules again and again, e.g.: add 100 call 5000 all from any to any in recv em0 add 110 deny all from table(10) to any in recv em0 add 200 call 5000 all from any to any in recv em1 add 210 deny all from table(20) in recv em1 ... add 5000 deny log all from any to any not antispoof add 5010 deny tcp from any to any 135,139,445 add 5020 deny udp from any to any 137,138 add 5030 allow tcp from any to any established ... add 5999 return // end of common block -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-i...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-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
[head tinderbox] failure on ia64/ia64
TB --- 2011-06-21 10:09:09 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-21 10:09:09 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-06-21 10:09:09 - cleaning the object tree TB --- 2011-06-21 10:09:20 - cvsupping the source tree TB --- 2011-06-21 10:09:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-06-21 10:10:10 - building world TB --- 2011-06-21 10:10:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-21 10:10:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-21 10:10:10 - TARGET=ia64 TB --- 2011-06-21 10:10:10 - TARGET_ARCH=ia64 TB --- 2011-06-21 10:10:10 - TZ=UTC TB --- 2011-06-21 10:10:10 - __MAKE_CONF=/dev/null TB --- 2011-06-21 10:10:10 - cd /src TB --- 2011-06-21 10:10:10 - /usr/bin/make -B buildworld World build started on Tue Jun 21 10:10: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 World build completed on Tue Jun 21 11:36:43 UTC 2011 TB --- 2011-06-21 11:36:43 - generating LINT kernel config TB --- 2011-06-21 11:36:43 - cd /src/sys/ia64/conf TB --- 2011-06-21 11:36:43 - /usr/bin/make -B LINT TB --- 2011-06-21 11:36:43 - building LINT kernel TB --- 2011-06-21 11:36:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-21 11:36:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-21 11:36:43 - TARGET=ia64 TB --- 2011-06-21 11:36:43 - TARGET_ARCH=ia64 TB --- 2011-06-21 11:36:43 - TZ=UTC TB --- 2011-06-21 11:36:43 - __MAKE_CONF=/dev/null TB --- 2011-06-21 11:36:43 - cd /src TB --- 2011-06-21 11:36:43 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Jun 21 11:36:43 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kgssapi/kgss_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/vm/vm_page.c:2356:2: error: #error PAGE_SIZE is not supported. mkdep: compile failed *** 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-21 11:38:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-21 11:38:23 - ERROR: failed to build lint kernel TB --- 2011-06-21 11:38:23 - 4171.46 user 806.41 system 5354.17 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
Re: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On Mon, Jun 20, 2011 at 15:46:56 +0400, Andrey Chernov wrote: On Mon, Jun 20, 2011 at 11:01:46AM +0300, Kostik Belousov wrote: On Mon, Jun 20, 2011 at 11:02:22AM +0400, Andrey Chernov wrote: On Sun, Jun 19, 2011 at 08:15:43PM -0600, Justin T. Gibbs wrote: On 6/19/11 6:19 PM, Andrey Chernov wrote: Exactly that commit is responsible for boot hang. Please fix. BTW, I have MBR on SATA disk (CAM emulated), ICH9. Since it works for me, you'll need to provide more information. Can you at least drop into kdb to determine the likely source of the hang by getting a stack trace of all processes to see where they are sleeping and dumping lock information? I drop into DDB and put 'bt' console photo in the very first message of this thread - nothing unusual seen in the main stack. Could you please specify exact DDB commands you want to be issued by me? No dump can be provided since nothing is mounted yet including swap, BTW, I remember I saw previously unseen warnings with post Jun 14 kernels: xpt_action_default: CCB type 0xe not supported 'ps' inside DDB shows [xpt_thrd] at ccb_scan wmesg state and [g_event] at caplck wmesg state, [kernel] at g_waitid state. Even don't know, if it matters. Just in case, please try r223277. As the second message in the thread states, I try first even 223296 with the same hang and the same xpt_action_default: CCB type 0xe not supported As I think, DDB's 'ps' indicates that kernel waits something from geom and geom waits something from ccb_scan forever, just raw guess. I will be glad to issue more specific DDB commands and upload corresponding photos. BTW, pluging and unplugging USB devides works in that stage. Can you do the following when the hang happens: ps alltrace show locks show msgbuf Hopefully that will give us something to start looking at... This would really work a lot better if there is any way to get a serial console on the machine. The above will produce a good bit of output, and would likely need a lot of pictures. Since we can't reproduce the problem here, some debugging help would be greatly appreciated. Thanks, Ken -- Kenneth Merry k...@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: TLS bug?
On 06/17/2011 02:35 PM, Marius Strobl wrote: On Fri, Jun 17, 2011 at 03:31:29PM -0400, Nathaniel W Filardo wrote: On Fri, Jun 17, 2011 at 08:07:13PM +0200, Marius Strobl wrote: Using bonnie++ I can't reproduce this (didn't try mysql) but I have I seem to have good luck reproducing it with -r 5 -s 10 -x 10 by about the third iteration. Ok, with these parameters I can reproduce it. some TLS fixes for libthr I forgot about but could be relevant here (most actually date back to 2008 when the base binutils didn't support GNUTLS for sparc64 so I couldn't test them easily). Could you please give a libthr build with the following patch a try? http://people.freebsd.org/~marius/libthr_sparc64.diff Concurrent runs both with and without those diffs still asserted. Interestingly, libc's .tbss section, even after the assertion, is still full of zeros, so it looks like something stranger than a wild-write back to .tbss. I'll go diving through the tls allocation code again when I get a minute. In combination with the below patch bonnie++ survived 100 iterations here. I'm not sure what this means though as I don't have much knowledge about TLS, I merely implemented the necessary relocations. Could be that malloc() actually requires the initial exec model for variant II. Unfortunately, it's not documented why it was added for x86. Jason, can you shed some light on this? Marius Index: malloc.c === --- malloc.c(revision 219535) +++ malloc.c(working copy) @@ -234,7 +234,7 @@ #ifdef __sparc64__ # define LG_QUANTUM 4 # define LG_SIZEOF_PTR 3 -# define TLS_MODEL/* default */ +# define TLS_MODEL__attribute__((tls_model(initial-exec))) #endif #ifdef __amd64__ # define LG_QUANTUM 4 I added the initial-exec TLS_MODEL because it is faster than the default; jemalloc in no way depends on this for correctness though, so your patch is safe. Thanks, Jason ___ 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: udav: vendor 0x0fe6, product: 0x9700
Hi Hans ! theoretically would only do this, put the id's in the files for the udav.c work, but was not so, the driver did not work with these entries, simply could not allocate a PHY. Dmesg: ugen0.2: vendor 0x0fe6 at usbus0 udav0: vendor 0x0fe6 USB 2.0 10100M Ethernet Adaptor, class 0/0, rev 1.10/1.01, addr 2 on usbus0 udav0: attaching PHYs failed In OpenBSD working normally. 2011/6/19 Hans Petter Selasky hsela...@c2i.net: On Friday 17 June 2011 15:46:17 Luiz Gustavo S. Costa wrote: Hi all I was venturing more on the idea of running this adapter, I decided to test on OpenBSD 4.9 OpenBSD 4.9 RELEASE is already entry for id 0x8180, equal to FreeBSD 9.0-CURRENT. What I did (see attached diff file) was to do the same, I tried to do in freebsd, add the id of the new adapter based on 0x8180 And everything worked as I expected, I managed to get a MAC address and use the ifconfig output as below: udav0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 lladdr 00:e0:4c:53:44:58 priority: 0 media: Ethernet none inet6 fe80::2e0:4cff:fe53:4458%udav0 prefixlen 64 scopeid 0x5 Do I have to specify the id somewhere else, some input to the PHY? Thanks Hi, Your patch has been committed with some modifications: http://svn.freebsd.org/changeset/base/223288 --HPS -- /\ Luiz Gustavo S. Costa / \ Programmer at BSD Perimeter / \ /\/\/\ Visit the pfSense Project / \ \ \ http://www.pfsense.org - BSD da serra carioca, Teresopolis (visite: http://miud.in/Inv) Contatos: luizgust...@luizgustavo.pro.br / lgco...@pfsense.org Blog: http://www.luizgustavo.pro.br ___ 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: udav: vendor 0x0fe6, product: 0x9700
On Tuesday 21 June 2011 19:17:13 Luiz Gustavo S. Costa wrote: Hi Hans ! theoretically would only do this, put the id's in the files for the udav.c work, but was not so, the driver did not work with these entries, simply could not allocate a PHY. Dmesg: ugen0.2: vendor 0x0fe6 at usbus0 udav0: vendor 0x0fe6 USB 2.0 10100M Ethernet Adaptor, class 0/0, rev 1.10/1.01, addr 2 on usbus0 udav0: attaching PHYs failed Check the miibus code. Maybe the PHY in question is not supported. --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
xpt_action_default: CCB type 0xe not supported
Fresh installation and after world kernel update I get these messages during boot: xpt_action_default: CCB type 0xe not supported xpt_action_default: CCB type 0xe not supported The system is running GENERIC with debugging for use in current off options. Full dmesg attached. Regards, -- George Kontostanos aisecure.net http://www.aisecure.net 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 #0: Tue Jun 21 19:28:33 EEST 2011 r...@core2duo.aicom.loc:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2401.97-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6f6 Family = 6 Model = f Stepping = 6 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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4057284608 (3869 MB) Event timer LAPIC quality 400 ACPI APIC Table: MSTEST OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: MSTEST TESTONLY on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0xE7, should be 0xDA (20110527/tbutils-282) cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0x9c00-0x9c7f mem 0xfd00-0xfdff,0xc000-0xcfff,0xfc00-0xfcff irq 16 at device 0.0 on pci1 uhci0: Intel 82801H (ICH8) USB controller USB-D port 0xdc00-0xdc1f irq 16 at device 26.0 on pci0 uhci0: LegSup = 0x2f00 usbus0: Intel 82801H (ICH8) USB controller USB-D on uhci0 uhci1: Intel 82801H (ICH8) USB controller USB-E port 0xe000-0xe01f irq 17 at device 26.1 on pci0 uhci1: LegSup = 0x2f00 usbus1: Intel 82801H (ICH8) USB controller USB-E on uhci1 ehci0: Intel 82801H (ICH8) USB 2.0 controller USB2-B mem 0xfebffc00-0xfebf irq 18 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2: Intel 82801H (ICH8) USB 2.0 controller USB2-B on ehci0 hdac0: Intel 82801H High Definition Audio Controller mem 0xfebf8000-0xfebfbfff irq 22 at device 27.0 on pci0 pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci4: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 19 at device 28.3 on pci0 pci3: ACPI PCI bus on pcib3 re0: RealTek 8168/8111 B/C/CP/D/DP/E PCIe Gigabit Ethernet port 0xb800-0xb8ff mem 0xfeaff000-0xfeaf irq 19 at device 0.0 on pci3 re0: Using 1 MSI message re0: Chip rev. 0x3800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:18:f3:03:66:7e pcib4: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0 pci2: ACPI PCI bus on pcib4 atapci0: JMicron JMB363 UDMA133 controller port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f mem 0xfe9fe000-0xfe9f irq 16 at device 0.0 on pci2 ahci0: JMicron JMB363 AHCI SATA controller on atapci0 ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich1: AHCI channel at channel 1 on ahci0 ata2: ATA channel 0 on atapci0 uhci2: Intel 82801H (ICH8) USB controller USB-A port 0xd480-0xd49f irq 23 at device 29.0 on pci0 uhci2: LegSup = 0x2f00 usbus3: Intel 82801H (ICH8) USB controller USB-A on uhci2 uhci3: Intel 82801H (ICH8) USB controller USB-B port 0xd800-0xd81f irq 19 at device 29.1 on pci0 uhci3: LegSup = 0x2f00 usbus4: Intel 82801H (ICH8) USB controller USB-B on uhci3 uhci4: Intel 82801H (ICH8) USB controller USB-C port 0xd880-0xd89f irq 18 at device 29.2 on pci0 uhci4: LegSup = 0x2f00 usbus5: Intel 82801H (ICH8) USB controller USB-C on uhci4 ehci1: Intel 82801H (ICH8) USB 2.0 controller USB2-A mem 0xfebff800-0xfebffbff irq 23 at device 29.7 on pci0 usbus6: EHCI version 1.0 usbus6: Intel 82801H (ICH8) USB 2.0 controller USB2-A on ehci1 pcib5: ACPI PCI-PCI bridge at device 30.0 on pci0 pci5: ACPI PCI bus
Re: xpt_action_default: CCB type 0xe not supported
On 06/21/11 10:51, George Kontostanos wrote: Fresh installation and after world kernel update I get these messages during boot: xpt_action_default: CCB type 0xe not supported xpt_action_default: CCB type 0xe not supported The system is running GENERIC with debugging for use in current off options. Full dmesg attached. Regards, ___ 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 SImilar issues on Tyan board with SATA 3gbs, atapicam custom kernel. I assumed it was the ugly CF adapter I have, as I've had shoddy USB devices confuse CAM in the past. Not as annoying as virtualbox being borked currently, I assume it's simply a printf that is a little too verbose? Or is scsi borked too? Matt ___ 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: xpt_action_default: CCB type 0xe not supported
On 06/21/11 19:58, Matt wrote: On 06/21/11 10:51, George Kontostanos wrote: Fresh installation and after world kernel update I get these messages during boot: xpt_action_default: CCB type 0xe not supported xpt_action_default: CCB type 0xe not supported The system is running GENERIC with debugging for use in current off options. Full dmesg attached. Regards, ___ 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 SImilar issues on Tyan board with SATA 3gbs, atapicam custom kernel. I assumed it was the ugly CF adapter I have, as I've had shoddy USB devices confuse CAM in the past. Not as annoying as virtualbox being borked currently, I assume it's simply a printf that is a little too verbose? Or is scsi borked too? Matt ___ 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 Same here, ASUS board, Intel ICH10R, SATA 3GB. Custom kernel: # S-ATA/AHCI Interface device ahci# Serial ATA Advanced Host Controller Interface driver device ata # Legacy Core ATA functionality options ATA_CAM # ATA CAM # device mvs # Marvell Serial ATA Host Controller driver device siis# Marvell Serial ATA Host Controller driver and the SCSI stuff. Seems to be a very verbose thing inside the CAM system. 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: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
Hi Andrey, On Mon, Jun 20, 2011 at 5:46 AM, Andrey Chernov a...@freebsd.org wrote: As the second message in the thread states, I try first even 223296 with the same hang and the same xpt_action_default: CCB type 0xe not supported As I think, DDB's 'ps' indicates that kernel waits something from geom and geom waits something from ccb_scan forever, just raw guess. I will be glad to issue more specific DDB commands and upload corresponding photos. BTW, pluging and unplugging USB devides works in that stage. Please try this patch: http://people.freebsd.org/~will/patches/ata_xpt_add_advinfo.0.diff Thanks. --Will. ___ 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: xpt_action_default: CCB type 0xe not supported
On Tue, Jun 21, 2011 at 08:51:02PM +0300, George Kontostanos wrote: Fresh installation and after world kernel update I get these messages during boot: xpt_action_default: CCB type 0xe not supported xpt_action_default: CCB type 0xe not supported +1 on ICH9 SATA -- 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: xpt_action_default: CCB type 0xe not supported
On Tue, Jun 21, 2011 at 11:22 AM, Andrey Chernov a...@freebsd.org wrote:
On Tue, Jun 21, 2011 at 08:51:02PM +0300, George Kontostanos wrote:
Fresh installation and after world kernel update I get these messages
during boot:
xpt_action_default: CCB type 0xe not supported
xpt_action_default: CCB type 0xe not supported
+1 on ICH9 SATA
It's noise added via r223081, that wasn't present in the previous
revision (
http://svnweb.freebsd.org/base/head/sys/cam/cam_xpt.c?view=markuppathrev=223081
):
2930case XPT_SDEV_TYPE:
2931case XPT_TERM_IO:
2932case XPT_ENG_INQ:
2933/* XXX Implement */
2934printf(%s: CCB type %#x not supported\n, __func__,
2935 start_ccb-ccb_h.func_code);
2936start_ccb-ccb_h.status = CAM_PROVIDE_FAIL;
2937if (start_ccb-ccb_h.func_code XPT_FC_DEV_QUEUED) {
2938xpt_done(start_ccb);
2939}
2940break;
It probably should be removed.
Thanks,
-Garrett
___
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)
After applying the patch the system does not boot anymore! It hangs after probing for scsi devices. On Tue, Jun 21, 2011 at 8:58 PM, Will Andrews w...@firepipe.net wrote: Hi Andrey, On Mon, Jun 20, 2011 at 5:46 AM, Andrey Chernov a...@freebsd.org wrote: As the second message in the thread states, I try first even 223296 with the same hang and the same xpt_action_default: CCB type 0xe not supported As I think, DDB's 'ps' indicates that kernel waits something from geom and geom waits something from ccb_scan forever, just raw guess. I will be glad to issue more specific DDB commands and upload corresponding photos. BTW, pluging and unplugging USB devides works in that stage. Please try this patch: http://people.freebsd.org/~will/patches/ata_xpt_add_advinfo.0.diff Thanks. --Will. ___ 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 -- George Kontostanos aisecure.net http://www.aisecure.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: xpt_action_default: CCB type 0xe not supported
On Jun 21, 2011, at 1:13 PM, Garrett Cooper wrote:
On Tue, Jun 21, 2011 at 11:22 AM, Andrey Chernov a...@freebsd.org wrote:
On Tue, Jun 21, 2011 at 08:51:02PM +0300, George Kontostanos wrote:
Fresh installation and after world kernel update I get these messages
during boot:
xpt_action_default: CCB type 0xe not supported
xpt_action_default: CCB type 0xe not supported
+1 on ICH9 SATA
It's noise added via r223081, that wasn't present in the previous
revision (
http://svnweb.freebsd.org/base/head/sys/cam/cam_xpt.c?view=markuppathrev=223081
):
This should fix it:
--- cam_xpt.c 14 Jun 2011 14:53:17 - 1.262
+++ cam_xpt.c 21 Jun 2011 19:44:17 -
@@ -2931,8 +2931,9 @@
case XPT_TERM_IO:
case XPT_ENG_INQ:
/* XXX Implement */
- printf(%s: CCB type %#x not supported\n, __func__,
- start_ccb-ccb_h.func_code);
+ CAM_DEBUG(start_ccb-ccb_h.path, CAM_DEBUG_INFO,
+ (%s: CCB type %#x not supported\n, __func__,
+ start_ccb-ccb_h.func_code));
start_ccb-ccb_h.status = CAM_PROVIDE_FAIL;
if (start_ccb-ccb_h.func_code XPT_FC_DEV_QUEUED) {
xpt_done(start_ccb);
___
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 Tue, Jun 21, 2011 at 11:58:17AM -0600, Will Andrews wrote: Hi Andrey, On Mon, Jun 20, 2011 at 5:46 AM, Andrey Chernov a...@freebsd.org wrote: As the second message in the thread states, I try first even 223296 with the same hang and the same xpt_action_default: CCB type 0xe not supported As I think, DDB's 'ps' indicates that kernel waits something from geom and geom waits something from ccb_scan forever, just raw guess. I will be glad to issue more specific DDB commands and upload corresponding photos. BTW, pluging and unplugging USB devides works in that stage. Please try this patch: http://people.freebsd.org/~will/patches/ata_xpt_add_advinfo.0.diff The patch does not fix the hang I talk about, but diagnostic is removed. -- 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 Tue, Jun 21, 2011 at 10:17:19AM -0600, Kenneth D. Merry wrote: ps alltrace show locks show msgbuf Hopefully that will give us something to start looking at... This would really work a lot better if there is any way to get a serial console on the machine. The above will produce a good bit of output, and would likely need a lot of pictures. Since we can't reproduce the problem here, some debugging help would be greatly appreciated. Sorry I have no serial console. Here are the photos. I remove very similar looking USB parts from 'ps' and 'alltrace', and very general parts from 'alltrace' always been there. I hope remaining info will be enough. USB hotplagging works at this stage, so no reason to look there. If it will be not enough, I'll upload whole series. 'show lock' outputs nothing, it means no locks just sleep somewhere forever. 'ps': http://img43.imageshack.us/img43/1424/21062011001j.jpg http://img835.imageshack.us/img835/6607/21062011002.jpg http://img841.imageshack.us/img841/5401/21062011003.jpg 'alltrace': http://img864.imageshack.us/img864/6757/21062011004ya.jpg http://img542.imageshack.us/img542/4857/21062011005.jpg http://img828.imageshack.us/img828/823/21062011006.jpg http://img5.imageshack.us/img5/910/21062011007.jpg http://img7.imageshack.us/img7/4704/21062011008.jpg http://img848.imageshack.us/img848/5487/21062011009.jpg http://img641.imageshack.us/img641/2/21062011010.jpg http://img7.imageshack.us/img7/7946/21062011011.jpg http://img860.imageshack.us/img860/8185/21062011012.jpg http://img696.imageshack.us/img696/5276/21062011013.jpg http://img825.imageshack.us/img825/1249/21062011014m.jpg http://img839.imageshack.us/img839/3791/21062011015.jpg http://img594.imageshack.us/img594/1773/21062011016.jpg http://img109.imageshack.us/img109/9937/21062011017.jpg http://img51.imageshack.us/img51/6047/21062011018l.jpg 'show msgbuf': http://img59.imageshack.us/img59/46/21062011019.jpg http://img189.imageshack.us/img189/483/21062011020.jpg http://img19.imageshack.us/img19/8163/21062011021.jpg http://img683.imageshack.us/img683/3171/21062011022.jpg http://img819.imageshack.us/img819/5923/21062011023.jpg http://img692.imageshack.us/img692/3789/21062011024.jpg http://img580.imageshack.us/img580/1550/21062011025.jpg http://img560.imageshack.us/img560/7478/21062011026.jpg http://img94.imageshack.us/img94/9371/21062011027.jpg http://img857.imageshack.us/img857/5185/21062011028.jpg -- 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
