Re: panic: invalid PDPE on recend amd64
Hi, I got a similar panic on amd64. Looking into the source it hit KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with a printf to see what triggered the assertion and here is the output. Combined with memcontrol output 'bogus' keyword it seems buggy BIOS violated some kind of spec and caused this. Is it fatal? It looks fine on my machine without the assertion. --->8--boot message ->8 mem: base 0xfffdc000 len 0x0002 base 0xc000 len 0x4000 base 0x len 0x8000 base 0x8000 len 0x4000 base 0xbff0 len 0x0010 base 0x0001 len 0x4000 null: --->8--memcontrol output ->8 r...@jsli-nb:~ # memcontrol list 0x0/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x1/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x2/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x3/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x4/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x5/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x6/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x7/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x84000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x88000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x94000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x98000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0xa/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xac000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xca000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xce000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcf000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xda000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdc000/0x1000 BIOS write-protect fixed-base fixe
Re: panic: invalid PDPE on recend amd64
On Sun, Nov 7, 2010 at 3:28 AM, Alan Cox wrote: > This is a different type of BIOS misconfiguration than your machine had. > > I'm attaching a possible patch for this one. > Sorry for replying late. This patch works for me. The source tree was cvsup on Sunday before previous mail. Thank you! Jia-Shiun. ___ 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"
cpufreq not working as module on i386/amd64
Hi all, I found that cpufreq driver failed to attach when compiled as module and loaded, but it works fine when compiled into kernel. I am wondering if this is due to some kind of limitation, or can be fixed? Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop (amd64). Both got the same result. dmesg of T4200 attached. kldload module: ->8->8->8- est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a device_attach: est0 attach returned 6 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a -8<-8<-8<- (repeated 6 times, kldload retries?) compiled into kernel: ->8->8->8- ... fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices coretemp0: on cpu0 coretemp0: Setting TjMax=104 p4tcc0: on cpu0 est0: on cpu0 coretemp1: on cpu1 coretemp1: Setting TjMax=104 p4tcc1: on cpu1 est1: on cpu1 Device configuration finished. procfs registered ... -8<-8<-8<- Jia-Shiun. ___ 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: Marvell 88SX7042
On Sat, Jun 12, 2010 at 5:03 AM, oizs wrote: > Hello, > > I got myself a board made for google by arima and had some issues with it > booting freebsd on it, but with some help of the list i was able to make it > boot. > Now i have two problems, whenever i try to reboot i get kernel trap 12, and > the more irritating problem, is that i can't make disks on the marvell > controller show up. According to 'man ata' the 88sx7042 is supported, but > even if i compile the kernel to support mvs, or try to load it with > loader.conf it won't load the driver. If i load debian up im able to > read/write them, so its probably not a hw issue. I would welcome any ideas > since im starting to run out of them. > > pciconf -lv > > hpt...@pci0:2:0:0: class=0x01 card=0x11ab11ab chip=0x704211ab > rev=0x02 hdr=0x00 > Your 88sx7042 is claimed by hptrr, driver for highpoint rocketraid adapters. You may want to build a custom kernel by removing the line device hptrr -js. ___ 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"
rm cannot recursively delete directory on tmpfs on RPi2
amd64 and RPi3 do not have this issue. jsli@rpi2:/home/jsli 13:04 # uname -a FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG arm jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt jsli@rpi2:/home/jsli 13:05 # cd /mnt jsli@rpi2:/mnt 13:05 # tar xf /usr/ports/distfiles/sqlite-autoconf-326.tar.gz jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ rm: sqlite-autoconf-326/tea: Operation not permitted rm: sqlite-autoconf-326/: Directory not empty jsli@rpi2:/mnt 13:05 # -Jia-Shiun ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rm cannot recursively delete directory on tmpfs on RPi2
On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: > On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li wrote: > > > > amd64 and RPi3 do not have this issue. > > > > jsli@rpi2:/home/jsli 13:04 # uname -a > > FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG > arm > > jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt > > jsli@rpi2:/home/jsli 13:05 # cd /mnt > > jsli@rpi2:/mnt 13:05 # tar xf > > /usr/ports/distfiles/sqlite-autoconf-326.tar.gz > > jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ > > rm: sqlite-autoconf-326/tea: Operation not permitted > > rm: sqlite-autoconf-326/: Directory not empty > > jsli@rpi2:/mnt 13:05 # > > > > -Jia-Shiun > > Did you check for file flags? Do "ls -lod sqlite-autoconf-326/tea". > > Unlikely caused by flags I think. jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt jsli@rpi2:/home/jsli # cd /mnt jsli@rpi2:/mnt # ls -R jsli@rpi2:/mnt # mkdir dir jsli@rpi2:/mnt # ls -R dir/ ls: dir: directory causes a cycle jsli@rpi2:/mnt # looks inode no for directories are wrong jsli@rpi2:/mnt # ll -ia total 4 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ jsli@rpi2:/mnt # ll -ia dir total 0 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ jsli@rpi2:/mnt # -Jia-Shiun ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ver 2 of the patch [was: Re: i915 driver update testing]
On Fri, Oct 24, 2014 at 3:03 AM, Konstantin Belousov wrote: > Due to my mistake during the patch generation, i915.5.patch is just > a garbage. > > Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one > private report of the patch worked from person who got the same panic > in iicbb. panic when I was opening Google maps in Chromium 38. But I was unable to reproduce it. The original code does not panic. src is r273588. CPU is an i5-3450. debug message attached. screenshot: https://lh3.googleusercontent.com/-BpPTfNTObtU/VEs9RGT7i6I/gfA/TvOnT-BP3zo/w894-h671-no/IMG_20141025_134906.jpg -Jia-Shiun. agp0: on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory agp0: AGP_SNB_GFX_MODE: agp0: AGP_SNB_GCC1: 0x0211 agp0: Mappable GTT entries: 65536 agp0: Total GTT entries: 524288 info: [drm] Initialized drm 1.1.0 20060810 [drm:pid958:drm_probe] desc : (null) drmn0: on vgapci0 [drm:pid958:drm_attach] MSI count = 1 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 267 to local APIC 2 vector 51 vgapci0: using IRQ 267 for MSI info: [drm] MSI enabled 1 message(s) [drm:pid958:drm_load] [drm:pid958:drm_agp_init] agp_available = 1 info: [drm] AGP at 0xe000 256MB [drm:pid958:drm_ctxbitmap_next] bit : 0 [drm:pid958:drm_ctxbitmap_init] drm_ctxbitmap_init : 0 [drm:pid958:drm_addmap] offset = 0xf780, size = 0x0040, type = 1 [drm:pid958:drm_addmap] Added map 1 0xf780/0x40 [drm:pid958:intel_setup_mchbar] mchbar already enabled iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0x0 iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0x0 iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0x0 iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0x0 iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0x0 iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0x0 iic12: on iicbus12 iic13: on iicbus13 [drm:pid958:intel_opregion_setup] graphic opregion physical addr: 0xd8a87018 [drm:pid958:intel_opregion_setup] SWSCI supported info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. [drm:KMS:pid958:intel_detect_pch] Found PatherPoint PCH [drm:KMS:pid958:init_vbt_defaults] Set default to SSC at 100MHz [drm:KMS:pid958:intel_parse_bios] Using VBT from OpRegion: $VBT SNB/IVB-DESKTOPd [drm:KMS:pid958:parse_general_features] BDB_GENERAL_FEATURES int_tv_support 0 int_crt_support 1 lvds_use_ssc 0 lvds_ssc_freq 120 display_clock_mode 0 [drm:KMS:pid958:parse_general_definitions] crt_ddc_bus_pin: 2 [drm:KMS:pid958:parse_lfp_panel_data] Found panel mode in BIOS VBT tables: [drm:KMS:pid958:drm_mode_debug_printmodeline] Modeline 0:"1024x768" 0 65000 1024 1048 1184 1344 768 771 777 806 0x8 0xa [drm:KMS:pid958:parse_lfp_panel_data] VBT initial LVDS value 300 [drm:KMS:pid958:parse_sdvo_panel_data] Found SDVO panel mode in BIOS VBT tables: [drm:KMS:pid958:drm_mode_debug_printmodeline] Modeline 0:"1600x1200" 0 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x8 0xa [drm:KMS:pid958:parse_sdvo_device_mapping] No SDVO device info is found in VBT [drm:KMS:pid958:intel_init_pm] Using MT version of forcewake [drm:KMS:pid958:intel_modeset_init] 3 display pipes available. [drm:KMS:pid958:intel_lvds_init] LVDS is not present in VBT [drm:KMS:pid958:intel_crt_init] pch crt adpa set to 0x80f40010 [drm:KMS:pid958:intel_setup_outputs] HDMIB 0 PCH_DP_B 0 HDMIC 1 HDMID 1 PCH_DP_C 1 PCH_DP_D 1 LVDS 0 [drm:KMS:pid958:intel_dp_i2c_init] i2c_init DPDDC-C [drm:KMS:pid958:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f [drm:KMS:pid958:intel_dp_i2c_aux_ch] aux_ch failed -60 [drm:KMS:pid958:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f [drm:KMS:pid958:intel_dp_i2c_aux_ch] aux_ch failed -60 [drm:KMS:pid958:intel_dp_i2c_init] i2c_init DPDDC-D [drm:KMS:pid958:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f [drm:KMS:pid958:intel_dp_i2c_aux_ch] aux_ch failed -60 [drm:KMS:pid958:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f [drm:KMS:pid958:intel_dp_i2c_aux_ch] aux_ch failed -60 [drm:KMS:pid958:ironlake_crtc_dpms] crtc 0/0 dpms off [drm:KMS:pid958:intel_update_fbc] [drm:KMS:pid958:ironlake_crtc_dpms] crtc 1/1 dpms off [drm:pid958:gm45_get_vblank_counter] i915: trying to get vblank count for disabled pipe B [drm:pid958:gm45_get_vblank_counter] i915: trying to get vblank count for disabled pipe B [drm:KMS:pid958:intel_update_fbc] [drm:KMS:pid958:ironlake_crtc_dpms] crtc 2/2 dpms off [drm:pid958:gm45_get_vblank_counter] i915: trying to get vblank count for disabled pipe C [drm:pid958:gm45_get_vblank_counter] i915: trying to get vblank count for disabled pipe C [drm:KMS:pid958:intel_update_fbc] [drm:KMS:pid958:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_pch_edp 0 has_cpu_edp 0 has_ck505 0 [drm:KMS:pid958:ironlake_init_pch_refclk] Disabling SSC entirely drmn0: taking over the fictitious range
Re: Haswell CPU Feature
On Tue, Jan 6, 2015 at 1:23 PM, Neel Natu wrote: > Hi Sean, > > On Mon, Jan 5, 2015 at 6:34 PM, Sean Bruno wrote: > > I'm thinking something like this: > > > > Index: sys/x86/x86/identcpu.c > > === > > - --- sys/x86/x86/identcpu.c(revision 276729) > > +++ sys/x86/x86/identcpu.c (working copy) > > @@ -781,7 +781,7 @@ > > "\011TM2" /* Thermal Monitor 2 */ > > "\012SSSE3" /* SSSE3 */ > > "\013CNXT-ID" /* L1 context ID > available */ > > - - "\014" > > + "\014SDBG" /* IA32_DEBUG_INTERFACE > debug*/ > > "\015FMA" /* Fused Multiply Add */ > > "\016CX16" /* CMPXCHG16B > Instruction */ > > "\017xTPR" /* Send Task Priority > Messages*/ > > > > > > Looks good. > Maybe also this for completeness? # svnlite diff Index: sys/x86/include/specialreg.h === --- sys/x86/include/specialreg.h(revision 276737) +++ sys/x86/include/specialreg.h(working copy) @@ -154,6 +154,7 @@ #defineCPUID2_TM2 0x0100 #defineCPUID2_SSSE30x0200 #defineCPUID2_CNXTID 0x0400 +#defineCPUID2_SDBG 0x0800 #defineCPUID2_FMA 0x1000 #defineCPUID2_CX16 0x2000 #defineCPUID2_XTPR 0x4000 -Jia-Shiun ___ 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: Acer C720 Chromebook (was: Re: looking for new netbook)
On Thu, Jan 8, 2015 at 4:08 AM, Warren Block wrote: > > When researching this machine a couple of weeks back, I saw somewhere that > it was based on a similar existing PC-compatible Acer model, V3 or V5 > maybe, or the ES1 series (can't find the reference again, of course). But > all of those with 11.6" displays look to have older or less powerful > processors, typically the Celeron N2840. The Celeron 2955 in the C720 is > about 50% faster. > > The E3-111-P8DW has a faster CPU, but it is a third-generation N3530. > Standard hard drive and socketed RAM, though. > > No, N3530 is Baytrail too, a quad-core one. N2840 is dual-core. They are both architecturally successsor of 'Atom' core family despite being labelled Celeron or Pentium. The brands are good for Intel to differentiate prices but useless for technical purpose. The same happens to AMD too. Acer provides model variations in CPU, RAM, storage, display, etc. according to geo markets. For example ES1-111 is only available with N2940 (another quad-core) here in Taiwan. If you can find a quad-core Baytrail model and don't mind slower single-thread performance, the E3 or ES1 series are easier to install FreeBSD I guess. Total multi-thread performance are comparable. And now prices do not differ much either, since Microsoft tax is lifted from these new cheaper models to compete with Chromebooks. -Jia-Shiun. ___ 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: i915kms.ko: when loaded with Haswell HD4600, display goes blank
On Fri, Jan 30, 2015 at 7:26 AM, Adrian Chadd wrote: > wait a sec - before the dri2 update, what exactly were you doing? What > happened when you loaded i915kms? Nothing should've been found and no > i915 driver should've been running > > There's no haswell support for i915kms, so it shouldn't have worked > /at all/. You should've just gotten either vt(4) or sc(4) + vesa as a > console, and VESA graphics. > > As a workaround, you can just not load i915kms, or patch i915kms to > not detect your haswell chipset. > Haswell device IDs were added in r277487 too. So does it mean people should start to test and report bugs regarding Haswell? -Jia-Shiun. ___ 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: HEADS-UP: Enabling WITH_DEBUG_FILES by default
On Thu, Feb 12, 2015 at 12:11 PM, Glen Barber wrote: > The major benefit is that all debugging data that we need to properly > debug application crashes in the base system will be available > out-of-box. > > There is a trade-off here, in both directions. For arm, for example, > the trade-off is that the default installed userland would grow, however > when there is a PR regarding an application crash, the tools to diagnose > the issue are there by default (we do not need to ask that the utility > is rebuilt with debugging options enabled, and then recreate the crash). > > I considered making this an opt-in thing for arm, but given the above > rationale, thought it would be more beneficial for the opposite route. > If you feel necessary, however, we can turn this off by default for now > for arm. > Is this default value supposed to go to future releases or only kept in -current for development & debugging purpose? For releases and resource-critical platforms, it'd be nice to build them all at once but only populate when needed after installation. -Jia-shiun. ___ 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"
svn repository uuid mismatch from mirror
Hi all, I wanted to svn up my /usr/src and it reported repository uuid mismatch. After digging it seems to be related to svn mirrors. Is UUID supposed to be different among mirrors? If not, could anything detect it and contact mirror admins? Since it is now all hidden behind geo dns. # svn up Updating '.': svn: E170009: Repository UUID '50bf32de-df07-e311-8ff9-0026557e8dec' doesn't match expected UUID 'ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f' # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 286782 Node Kind: directory Schedule: normal Last Changed Author: pfg Last Changed Rev: 286782 Last Changed Date: 2015-08-14 22:58:04 +0800 (Fri, 14 Aug 2015) # svn info https://svn.freebsd.org/base Path: base URL: https://svn.freebsd.org/base Relative URL: ^/ Repository Root: https://svn.freebsd.org/base Repository UUID: 50bf32de-df07-e311-8ff9-0026557e8dec Revision: 286835 Node Kind: directory Last Changed Author: adrian Last Changed Rev: 286835 Last Changed Date: 2015-08-17 10:04:11 +0800 (Mon, 17 Aug 2015) # host svn.freebsd.org svn.freebsd.org is an alias for svnmir.geo.freebsd.org. svnmir.geo.FreeBSD.org has address 140.113.168.170 svnmir.geo.FreeBSD.org has IPv6 address 2001:f18:113:fb5d::e6a:0 svnmir.geo.FreeBSD.org mail is handled by 0 . # svn info https://213.138.116.72/base Error validating server certificate for 'https://213.138.116.72:443': - The certificate hostname does not match. Certificate information: - Hostname: svn.freebsd.org - Valid: from Jun 22 00:00:00 2015 GMT until Jun 22 23:59:59 2016 GMT - Issuer: Gandi, Paris, Paris, FR - Fingerprint: E9:37:73:80:B5:32:1B:93:92:94:98:17:59:F0:FA:A2:5F:1E:DE:B9 (R)eject, accept (t)emporarily or accept (p)ermanently? t Path: base URL: https://213.138.116.72/base Relative URL: ^/ Repository Root: https://213.138.116.72/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 286835 Node Kind: directory Last Changed Author: adrian Last Changed Rev: 286835 Last Changed Date: 2015-08-17 10:04:11 +0800 (Mon, 17 Aug 2015) # -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
installworld failed by mounting other's /usr/obj
I have one machine which is faster to build world and export /usr/obj for others to install. As of r297266 installworld would fail. It seems to be caused by r296921 which would delete libc.ld. In this case libc.ld resides on a read-only /usr/obj mount. -- >>> Installing everything -- cd /usr/src; /usr/obj/usr/src/make.amd64/bmake -f Makefile.inc1 install ===> lib (install) ===> lib/csu (install) ===> lib/csu/amd64 (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o Scrt1.o gcrt1.o /usr/lib/ ===> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib/ install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib/ install -T debug -o root -g wheel -m 444libc.so.7.debug /usr/lib/debug/lib/ install -S -C -o root -g wheel -m 444 libc.ld /usr/lib/libc.so rm -f libc.ld rm: libc.ld: Permission denied *** Error code 1 Stop. bmake[5]: stopped in /usr/src/lib/libc *** Error code 1 Stop. bmake[4]: stopped in /usr/src/lib *** Error code 1 Stop. bmake[3]: stopped in /usr/src *** Error code 1 Stop. bmake[2]: stopped in /usr/src *** Error code 1 Stop. bmake[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src 0.778u 0.483s 0:01.36 91.9% 1356+245k 0+655io 1483pf+0w jsli@jsli-bsd:/usr/src # -Jia-Shiun ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SD card adapter doesn't working anymore
On Mon, Mar 28, 2016 at 11:38 PM, Ian Lepore wrote: > Wow, there's just nothing to work with in that output. I think the > increased debuging didn't output anything because nothing is happening, > and that's consistant with the value in the Present State register when > the driver attaches, which says that no card is inserted. (It says > that in several ways... when a card is in, half a dozen of those bits > should be non-zero.) > > It makes me think the controller isn't powered up, or is in some > suspend mode or something. But that would be at the pci bus level, not > something the driver is in control of. I had a problem like that > initially on my FitPc2 x86 board that has sdhci on it, but the problem > went away with a bios update. > I tried it on my once-worked notebook. If sdcard was not inserted mmc0 does not get probed. If sdcard was inserted while loading sdhci_pci module, timeout repeats until I eject the sdcard. And inserting card afterward did not get it probed in either cases. Kernel is FreeBSD jsli-nb 11.0-CURRENT FreeBSD 11.0-CURRENT #8 r297267M: Fri Mar 25 19:50:53 CST 2016 jsli@4cbsd:/usr/obj/usr/src/sys/Minimal-NODEBUG amd64 No card: found-> vendor=0x197b, dev=0x2381, revid=0x00 domain=0, bus=7, slot=0, func=2 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0407, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 3 supports D0 D3 current D3 MSI supports 1 message pci0:7:0:2: reprobing on driver added pci5: set ACPI power state D0 on \134_SB_.PCI0.EXP5.J382 pci0:7:0:2: Transition from D3 to D0 sdhci_pci0: mem 0xd7000200-0xd70002ff irq 16 at device 0.2 on pci5 sdhci_pci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 259 to local APIC 1 vector 54 sdhci_pci0: using IRQ 259 for MSI sdhci_pci0-slot0: 50MHz 8bits 3.3V DMA sdhci_pci0-slot0: == REGISTER DUMP == sdhci_pci0-slot0: Sys addr: 0x | Version: 0xac01 sdhci_pci0-slot0: Blk size: 0x | Blk cnt: 0x sdhci_pci0-slot0: Argument: 0x | Trn mode: 0x sdhci_pci0-slot0: Present: 0x0008 | Host ctl: 0x sdhci_pci0-slot0: Power:0x | Blk gap: 0x sdhci_pci0-slot0: Wake-up: 0x | Clock:0x sdhci_pci0-slot0: Timeout: 0x | Int stat: 0x sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x | Slot int: 0x sdhci_pci0-slot0: Caps: 0x014832b2 | Max curr: 0x sdhci_pci0-slot0: === sdhci_pci0: 1 slot(s) allocated random: harvesting attach, 8 bytes (4 bits) from sdhci_pci0 Card inserted: found-> vendor=0x197b, dev=0x2381, revid=0x00 domain=0, bus=7, slot=0, func=2 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0407, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 3 supports D0 D3 current D3 MSI supports 1 message pci0:7:0:2: reprobing on driver added pci5: set ACPI power state D0 on \134_SB_.PCI0.EXP5.J382 pci0:7:0:2: Transition from D3 to D0 sdhci_pci0: mem 0xd7000200-0xd70002ff irq 16 at device 0.2 on pci5 sdhci_pci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 259 to local APIC 1 vector 54 sdhci_pci0: using IRQ 259 for MSI sdhci_pci0-slot0: 50MHz 8bits 3.3V DMA sdhci_pci0-slot0: == REGISTER DUMP == sdhci_pci0-slot0: Sys addr: 0x | Version: 0xac01 sdhci_pci0-slot0: Blk size: 0x | Blk cnt: 0x sdhci_pci0-slot0: Argument: 0x | Trn mode: 0x sdhci_pci0-slot0: Present: 0x000f | Host ctl: 0x sdhci_pci0-slot0: Power:0x | Blk gap: 0x sdhci_pci0-slot0: Wake-up: 0x | Clock:0x sdhci_pci0-slot0: Timeout: 0x | Int stat: 0x sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x | Slot int: 0x sdhci_pci0-slot0: Caps: 0x014832b2 | Max curr: 0x sdhci_pci0-slot0: === sdhci_pci0: 1 slot(s) allocated random: harvesting attach, 8 bytes (4 bits) from sdhci_pci0 found-> vendor=0x197b, dev=0x2383, revid=0x00 domain=0, bus=7, slot=0, func=3 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 3 supports D0 D3 current D3 MSI supports 1 message pci0:7:0:3: reprobing on driver added pci5: set ACPI power state D0 on \134_SB_.PCI0.EXP5.J383 pci0:7:0:3: Transition from D3 to D0 pci0:7:0:3: Transition from D0 to D3 found-> vendor=0x197b, dev=0x2384, revid=0x00 domain=0, bus=7, slot=0, fun
Re: installworld failed by mounting other's /usr/obj
On Wed, Mar 30, 2016 at 2:19 AM, Jean-Sébastien Pédron wrote: > On 27/03/2016 09:07, Jia-Shiun Li wrote: > > I have one machine which is faster to build world and export /usr/obj for > > others to install. > > > > As of r297266 installworld would fail. It seems to be caused by r296921 > > which would delete libc.ld. In this case libc.ld resides on a read-only > > /usr/obj mount. > > Hi! > > This was fixed by Bryan Drewery in r297270. > > Yes I confirmed that in r297394 this is no longer issue. Thank you Jean and Bryan. -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEAD does not build bwn (after r297405 ?)
On Wed, Mar 30, 2016 at 2:06 PM, Rainer Hurling wrote: > If I try to build most recent HEAD (r297407), I get the following error: > > I suspect r297405 with its migration of time_* macros to be the reason? > > Adrian Chadd fixed that in r297409. -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DeLock 10x SATA AHCI controller not working properly
according to the msgs, the controller pretended to be a 12-port host to hide port multipliers behind it? Creative, but then any magic (or bugs) it does remains vendor-specific and unknown to outside world. Looks there is no firmware or jumpers to change this behavior. http://www.addonics.com/products/ad10sa6gpx2.php -Jia-Shiun. On Tue, Nov 8, 2016 at 1:42 PM, Alexander Motin wrote: > As I have told before, this card is from completely different price > segment then proper SAS/SATA HBAs. For its $80 it is not promised to be > reliable. But in case anything can be done, I'll try to take a look on > it in couple weeks when I get one and return home. > > On 07.11.2016 16:19, Daniel Engberg wrote: > > I discussed this card briefly with Alexander Motin (@mav) back in 2015, > > https://forums.freebsd.org/threads/50411/page-2#post-282648 . > > I've CCed him for suggestions. > > > > https://lists.freebsd.org/pipermail/freebsd-current/ > 2016-October/063668.html > > -- > Alexander Motin > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
TSC as timecounter makes system lag
Hi all, since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel Pentium T4200 notebook lagged a lot. System time was running a lot slower, sometimes even looked like it freezed. Keystroke repeat rate was slow too. Since system time is slow, I tried to change timecounter from default TSC to HPET. And it resumed normal immediately. The same world binary works fine on other Ivybridge and Haswell desktops, so I assume this may be related to CPU or mainboard generations. version is FreeBSD jsli-nb 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311687: Mon Jan 9 04:07:27 CST 2017 jsli@4cbsd:/personal/freebsd/obj/x64/personal/freebsd/fbsdsrc/sys/MINIMAL-NODEBUG amd64 and CPU is CPU: Pentium(R) Dual-Core CPU T4200 @ 2.00GHz (1995.04-MHz K8-class CPU) Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10 Features=0xbfebfbff Features2=0xc00e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics Tested similar OS rev on another Intel Core 2 Duo E7400 Wolfdale (the same generation as the Pentium T4200). The same lag also happens on it. BTW on both system, cpuX:timer interrupts do not fire at all and count remains 0. -Jia-Shiun ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TSC as timecounter makes system lag
On Fri, Jan 13, 2017 at 8:26 AM, Jia-Shiun Li wrote: > Hi all, > > since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel Pentium > T4200 notebook lagged a lot. System time was running a lot slower, > sometimes even looked like it freezed. Keystroke repeat rate was slow too. > > Since system time is slow, I tried to change timecounter from default TSC > to HPET. And it resumed normal immediately. > > Did a binary search. Turns out it was caused by r310177 "Enable EARLY_AP_STARTUP on amd64 and i386 kernels by default." r310175 does not have this issue. Removing this option from kernel config also solves it. -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TSC as timecounter makes system lag
Sorry just saw this. Bad Gmail. On Fri, Jan 13, 2017 at 8:05 PM, Konstantin Belousov wrote: > On Fri, Jan 13, 2017 at 08:26:04AM +0800, Jia-Shiun Li wrote: > > Hi all, > > > > since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel Pentium > > T4200 notebook lagged a lot. System time was running a lot slower, > > sometimes even looked like it freezed. Keystroke repeat rate was slow > too. > > > > Since system time is slow, I tried to change timecounter from default TSC > > to HPET. And it resumed normal immediately. > Please show the output of sysctl kern.timecounter and kern.eventtimer. > I suspect that you changed eventtimer and not timecounter. > Files attached. I changed it by "sysctl kern.timecounter.hardware=HPET" > The same world binary works fine on other Ivybridge and Haswell desktops, > > so I assume this may be related to CPU or mainboard generations. > > > > version is > > > > FreeBSD jsli-nb 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311687: Mon Jan 9 > > 04:07:27 CST 2017 > > jsli@4cbsd:/personal/freebsd/obj/x64/personal/freebsd/ > fbsdsrc/sys/MINIMAL-NODEBUG > > amd64 > > > > and CPU is > > > > CPU: Pentium(R) Dual-Core CPU T4200 @ 2.00GHz (1995.04-MHz > K8-class > > CPU) > > Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10 > > > > Features=0xbfebfbff APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI, > MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > > > Features2=0xc00e39d SSSE3,CX16,xTPR,PDCM,XSAVE,OSXSAVE> > > AMD Features=0x20100800 > > AMD Features2=0x1 > > TSC: P-state invariant, performance statistics > > > > Tested similar OS rev on another Intel Core 2 Duo E7400 Wolfdale (the > same > > generation as the Pentium T4200). The same lag also happens on it. > > > > BTW on both system, cpuX:timer interrupts do not fire at all and count > > remains 0. > It is known that LAPIC is shut down in C2 and deeper CPU sleep states on > Core2. FreeBSD 11 (and HEAD) started using MWAIT and requesting deep > wait states from BIOS. If the configuration uses LAPIC and deep sleeps > are enabled, eventtimers do not work reliably. > > Default configuration should strongly prefer HPET eventtimer over LAPIC for > machines which do not have LAPIC armed in Cx states, see r309189. If you > do not have any customizations of eventtimer selection, then please provide > verbose dmesg from your boot. > > If you prefer to not use deep Cx and MWAIT, set loader tunable > debug.acpi.disabled to include word "mwait", see acpi(4). You can check > that this worked by looking at sysctl dev.cpu.N output. > Thanks for the explanation. Looks eventtimer favored HPET over LAPIC like you described on this notebook. -Jia-Shiun. kern.eventtimer.periodic: 0 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(100) i8254(100) RTC(0) kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.HPET3.quality: 440 kern.eventtimer.et.HPET3.frequency: 14318180 kern.eventtimer.et.HPET3.flags: 3 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.LAPIC.quality: 100 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.flags: 15 kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) TSC(1000) dummy(-100) kern.timecounter.hardware: TSC kern.timecounter.alloweddeviation: 5 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 79078 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 55592 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.counter: 1931486323 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.TSC.quality: 1000 kern.timecounter.tc.TSC.frequency: 1995044550
Re: TSC as timecounter makes system lag
BTW please see my other mail of this thread. It seems to be related to EARLY_AP_STARTUP option. On Mon, Jan 16, 2017 at 4:20 AM, Konstantin Belousov wrote: > I still do not understand. Is the sysctl output below from the pristine > boot where no timecounter/eventtimer reconfiguration were done ? > > Show me exact command which you used to revive the machine. Do not > describe > it by words, copy/paste from the console. > > Don't have access to the exact machine right now. Let me reproduce it on another with a c2d E7400. login as: jsli Authenticating with public key "rsa-key-20160711@jsli-pc" Last login: Mon Jan 16 11:11:28 2017 from tmux(1074).%1 FreeBSD 12.0-CURRENT (GENERIC-NODEBUG) #24 r312210: Sun Jan 15 15:03:40 CST 2017 Welcome to FreeBSD! Release Notes, Errata: https://www.FreeBSD.org/releases/ Security Advisories: https://www.FreeBSD.org/security/ FreeBSD Handbook: https://www.FreeBSD.org/handbook/ FreeBSD FAQ: https://www.FreeBSD.org/faq/ Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd- questions/ FreeBSD Forums:https://forums.FreeBSD.org/ Documents installed with the system are in the /usr/local/share/doc/freebsd/ directory, or can be installed later with: pkg install en-freebsd-doc For other languages, replace "en" with a language code like de or fr. Show the version of FreeBSD installed: freebsd-version ; uname -a Please include that output and any error messages when posting questions. Introduction to manual pages: man man FreeBSD directory layout: man hier Edit /etc/motd to change this login announcement. jsli@jsli-bsd:~ % sysctl kern.eventtimer kern.timecounter kern.eventtimer.periodic: 0 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(100) i8254(100) RTC(0) kern.eventtimer.et.HPET3.quality: 440 kern.eventtimer.et.HPET3.frequency: 14318180 kern.eventtimer.et.HPET3.flags: 3 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.LAPIC.quality: 100 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.flags: 15 kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 5046106 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.counter: 1449012340 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 10698 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.tc.TSC-low.frequency: 1400076588 kern.timecounter.tc.TSC-low.counter: 2260820915 kern.timecounter.tc.TSC-low.mask: 4294967295 jsli@jsli-bsd:~ % su Password: jsli@jsli-bsd:/home/jsli # sysctl kern.timecounter.hardware=HPET kern.timecounter.hardware: TSC-low -> HPET jsli@jsli-bsd:/home/jsli # sysctl kern.eventtimer kern.timecounter kern.eventtimer.periodic: 0 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(100) i8254(100) RTC(0) kern.eventtimer.et.HPET3.quality: 440 kern.eventtimer.et.HPET3.frequency: 14318180 kern.eventtimer.et.HPET3.flags: 3 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.LAPIC.quality: 100 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.flags: 15 kern.timecounter.tsc_shift: 1 k
Re: TSC as timecounter makes system lag
On Mon, Jan 16, 2017 at 8:00 PM, Konstantin Belousov wrote: > On Mon, Jan 16, 2017 at 12:28:54PM +0800, Jia-Shiun Li wrote: > > BTW please see my other mail of this thread. It seems to be related to > > EARLY_AP_STARTUP option. > Yes, I noted, I might have an idea, but the report that changing the > timecounter makes the lags go away still does not fit into my understanding > of the code. > > Most likely this is an interaction between the EARLY_AP_STARTUP and the > fact that HPET interrupt is global, while most modern systems use LAPIC > event timer, which is per-cpu, and the testing of the option was done > on them. There are some differences in handling the configurations, see > sys/kern/kern_clocksource.c, the option and ET_FLAG_PERCPU. > > And, changing the _timecounter_ fixes the issue ? Can you double-check > this ? > Yes. I noticed this because systat refreshes looked slower, and keystroke did not repeat smoothly for 30/s. I have system clock shown on tmux status line. On c2d it drifted away. Setting timecounter brings it back to normal. See also eventtimer & timecounter tests below. > > With the settings above, i.e. HPET for both eventtimer and timecounter, > please show vmstat -ia output for two times with the interval of 2 secs. > Attached. > > What if you change _eventtimer_ to APIC and then immediately back to HPET, > does the problem go away ? > > It doesn't look so. But keeping LAPIC as eventtimer helps. jsli@jsli-bsd:/home/jsli # sysctl kern.eventtimer.timer=LAPIC && sysctl kern.eventtimer.timer=HPET && ntpdate tw.pool.ntp.org && sleep 30 && ntpdate tw.pool.ntp.org kern.eventtimer.timer: HPET -> LAPIC kern.eventtimer.timer: LAPIC -> HPET 16 Jan 22:00:21 ntpdate[8472]: step time server 203.71.244.7 offset 18.980716 sec 16 Jan 22:01:56 ntpdate[8601]: step time server 103.226.213.30 offset 58.813079 sec jsli@jsli-bsd:/home/jsli # sysctl kern.eventtimer.timer=LAPIC && ntpdate tw.pool.ntp.org && sleep 30 && ntpdate tw.pool.ntp.org kern.eventtimer.timer: HPET -> LAPIC 16 Jan 22:02:36 ntpdate[8666]: step time server 103.226.213.30 offset 19.773086 sec 16 Jan 22:03:13 ntpdate[8776]: adjust time server 103.226.213.30 offset 0.000455 sec jsli@jsli-bsd:/home/jsli # sysctl kern.eventtimer.timer=HPET && ntpdate tw.pool.ntp.org && sleep 30 && ntpdate tw.pool.ntp.org kern.eventtimer.timer: LAPIC -> HPET 16 Jan 22:03:47 ntpdate[8853]: step time server 103.226.213.30 offset 6.344004 sec 16 Jan 22:05:18 ntpdate[8975]: step time server 61.216.153.105 offset 54.908872 sec jsli@jsli-bsd:/home/jsli # sysctl kern.timecounter.hardware=HPET && ntpdate tw.pool.ntp.org && sleep 30 && ntpdate tw.pool.ntp.org kern.timecounter.hardware: TSC-low -> HPET 16 Jan 22:06:29 ntpdate[9073]: step time server 59.124.29.241 offset 39.211691 sec 16 Jan 22:07:05 ntpdate[9185]: adjust time server 61.216.153.105 offset 0.001015 sec jsli@jsli-bsd:/home/jsli # sysctl kern.timecounter.hardware=TSC-low && ntpdate tw.pool.ntp.org && sleep 30 && ntpdate tw.pool.ntp.org kern.timecounter.hardware: HPET -> TSC-low 16 Jan 22:07:28 ntpdate[9244]: step time server 61.216.153.105 offset 3.122954 sec 16 Jan 22:08:58 ntpdate[9357]: step time server 61.216.153.104 offset 53.758451 sec jsli@jsli-bsd:/home/jsli # > Also, if you set the loader tunable kern.eventtimer.timer to LAPIC, > and do not enable C2+, does the system boot into the usable state ? > > Not sure if you mean disabling C2 from BIOS. Right now I don't have BIOS access to the c2d, and my notebook only has minimal BIOS settings to play with. Anyway on notebook set kern.eventtimer.timer=LAPIC in loader prompt to boot , and the system still lags. But after setting sysctl dev.cpu.0.cx_lowest=C1 && sysctl dev.cpu.1.cx_lowest=C1 system clock returns to normal speed. -Jia-Shiun. jsli@jsli-bsd:~ % vmstat -ia 2 2 interrupt total rate ???0 0 irq1: atkbd0 2 0 stray irq1 0 0 irq0: attimer0 0 0 stray irq0 0 0 irq3: 0 0 stray irq3 0 0 irq4: uart00 0 stray irq4 0 0 irq5: 0 0 stray irq5 0 0 irq6: 0 0 stray irq6 0 0 irq7: 0 0 stray irq7 0 0 irq8: atrtc0 0 0 stra
Re: TSC as timecounter makes system lag
On Tue, Jan 17, 2017 at 10:05 PM, Hans Petter Selasky wrote: > I've seen something similar. Does the attached patch make any difference? > > Can you dump: > > vmstat -i > > Just after boot w/ and w/o the attached patch, when the keystroke did not > repeat smoothly. > > Your patch fixes this issue. It is now working as expected. vmstat output attached. Running w/ kernel r312210. Thanks, -Jia-Shiun. interrupt total rate ???0 0 irq1: atkbd0 2 0 stray irq1 0 0 irq0: attimer0 0 0 stray irq0 0 0 irq3: 0 0 stray irq3 0 0 irq4: uart00 0 stray irq4 0 0 irq5: 0 0 stray irq5 0 0 irq6: 0 0 stray irq6 0 0 irq7: 0 0 stray irq7 0 0 irq8: atrtc0 0 0 stray irq8 0 0 irq9: acpi00 0 stray irq9 0 0 irq10: 0 0 stray irq100 0 irq11: 0 0 stray irq110 0 irq12: 0 0 stray irq120 0 irq13: 0 0 stray irq130 0 irq14: 0 0 stray irq140 0 irq15: 0 0 stray irq150 0 irq16: em0:irq0++ 16 0 stray irq160 0 irq17: 0 0 stray irq170 0 irq18: uhci2 ehci0+ 18 0 stray irq180 0 irq19: uhci4 0 0 stray irq190 0 irq20: hpet0 28522442 stray irq200 0 irq21: uhci1 0 0 stray irq210 0 irq22: 0 0 stray irq220 0 irq23: uhci3 ehci1 0 0 stray irq230 0 cpu0:timer 0 0 irq256: hdac0110 2 stray irq256 0 0 irq257: pcib1 0 0 stray irq257 0 0 irq258: pcib2 0 0 stray irq258 0 0 irq259: pcib3 0 0 stray irq259 0 0 irq260: re0 6587102 stray irq260 0 0 irq261: ahci0:ch0 4062 63 stray irq261 0 0 irq262: ahci0:ch1 0 0 stray irq262 0 0 irq263: ahci0:ch2 0 0 stray irq263 0 0 irq264: ahci0:ch3 0 0 stray irq264 0 0 irq265: ahci0:ch4 0 0 stray irq265 0 0 irq266: ahci0:ch5 0 0 stray irq266 0 0 irq267: ahci0:60 0 stray irq267 0 0 irq268: ahci0:70 0 stray irq268 0 0 irq269: ahci0:80 0 stray irq269 0 0 irq270: ahci0:90 0 stray irq270 0 0 irq271: ahci0:10 0 0 stray irq271 0 0 irq272: ahci0:11 0 0 stray irq272 0 0 irq273: ahci0:12 0 0 stray irq273 0 0 irq274: ahci0:13 0 0 stray irq274 0 0 irq275: ahci0:14 0 0 stray irq275
Re: Strange issue after early AP startup
On Thu, Jan 19, 2017 at 4:23 PM, Hans Petter Selasky wrote: > > I can add prints/asserts to show that what happens is that > "state->nextcallopt > now" while "state->nextcall <= now". This situtation > is allowed to persist due to the way getnextcpuevent() is currently > implemented. > > Can the people CC'ed give the attached patch a spin and report back? > > As far as c2d system time is concerned, it works correctly for me w/ r312210. -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange issue after early AP startup
On Sat, Jan 21, 2017 at 3:51 PM, Hans Petter Selasky wrote: > FYI: > > https://svnweb.freebsd.org/changeset/base/312551 > > Hi hps, sorry I have to correct my test results. I found that I did not revert changes to kernel config, which commented out EARLY_AP_STARTUP option, before testing you patches. So they were tested without EARLY_AP_STARTUP. I tested again your patches with kernel config reverted, and they (and head as of r312620) did not solve the c2d system time lag issue. vmstat results attached. And also my apology for this stupid mistake. -Jia-Shiun. interrupt total rate ???0 0 irq1: atkbd0 2 0 stray irq1 0 0 irq0: attimer0 0 0 stray irq0 0 0 irq3: 0 0 stray irq3 0 0 irq4: uart00 0 stray irq4 0 0 irq5: 0 0 stray irq5 0 0 irq6: 0 0 stray irq6 0 0 irq7: 0 0 stray irq7 0 0 irq8: atrtc0 0 0 stray irq8 0 0 irq9: acpi00 0 stray irq9 0 0 irq10: 0 0 stray irq100 0 irq11: 0 0 stray irq110 0 irq12: 0 0 stray irq120 0 irq13: 0 0 stray irq130 0 irq14: 0 0 stray irq140 0 irq15: 0 0 stray irq150 0 irq16: em0:irq0++ 18 0 stray irq160 0 irq17: 0 0 stray irq170 0 irq18: uhci2 ehci0+ 18 0 stray irq180 0 irq19: uhci4 0 0 stray irq190 0 irq20: hpet0 12503277 stray irq200 0 irq21: uhci1 0 0 stray irq210 0 irq22: 0 0 stray irq220 0 irq23: uhci3 ehci1 0 0 stray irq230 0 cpu0:timer 0 0 cpu1:timer 0 0 irq256: hdac0 97 2 stray irq256 0 0 irq257: pcib1 0 0 stray irq257 0 0 irq258: pcib2 0 0 stray irq258 0 0 irq259: pcib3 0 0 stray irq259 0 0 irq260: re0 9049201 stray irq260 0 0 irq261: ahci0:ch0 4186 93 stray irq261 0 0 irq262: ahci0:ch1 0 0 stray irq262 0 0 irq263: ahci0:ch2 0 0 stray irq263 0 0 irq264: ahci0:ch3 0 0 stray irq264 0 0 irq265: ahci0:ch4 0 0 stray irq265 0 0 irq266: ahci0:ch5 0 0 stray irq266 0 0 irq267: ahci0:60 0 stray irq267 0 0 irq268: ahci0:70 0 stray irq268 0 0 irq269: ahci0:80 0 stray irq269 0 0 irq270: ahci0:90 0 stray irq270 0 0 irq271: ahci0:10 0 0 stray irq271 0 0 irq272: ahci0:11 0 0 stray irq272 0 0 irq273: ahci0:12 0 0 stray i
Re: TSC as timecounter makes system lag
FYI since it was not really solved as of r313090, I created bug 216833 to keep track of it. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216833 -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TSC as timecounter makes system lag
I got the impression that TSC was not preferred timecounter if it is not C-state invariant. But this apparenly is not the case now. Dig a bit and found r277900 chose to prefer TSC over saving power by disabling C2 state when TSC is selected as timecounter. But with EARLY_AP_STARTUP, and TSC as timecounter, CPU still enters C2 state. (Observed by sysctl dev.cpu.0.cx_usage_counters) With nooptions EARLY_AP_STARTUP, CPU correctly stays 100% in C1 and no lower. I added a printf in tc_windup() to check. With EARLY_AP_STARTUP, cpu_disable_c2_sleep is never increased, so it can not prevent CPU from entering C2. Guess there's some kind of race or init order issue, but it is beyond my understanding for now. -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TSC as timecounter makes system lag
On Thu, Feb 23, 2017 at 6:08 PM, Konstantin Belousov
wrote:
>
> This is a useful analysis.
>
> Yes, I think that there is an init ordering issue. Note that
> cpu_disable_c2_sleep is only changed in tc_windup() when timecounter
> is changed. If existing and already engadged timecounter suddenly gets
> TC_FLAG_C2STOP set, tc_windup() ignores the flag. And with the early
> AP startup, tsc seems to be set as timecounter too early.
>
> Just moving order of init_TSC_tc() would not help, since tsc checks smp
> consistency, which requires started APs. Try this for now, but might
> be John has better idea how to handle the issue. You might need to add
> some extern declarations for the patch to compile.
>
> diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
> index 3f36fbd9f8a..f8e33069c70 100644
> --- a/sys/x86/x86/tsc.c
> +++ b/sys/x86/x86/tsc.c
> @@ -545,6 +545,8 @@ init_TSC_tc(void)
> if (cpu_deepest_sleep >= 2 && cpu_vendor_id == CPU_VENDOR_INTEL &&
> (amd_pminfo & AMDPM_TSC_INVARIANT) == 0) {
> tsc_timecounter.tc_flags |= TC_FLAGS_C2STOP;
> + if (timecounter == &tsc_timecounter)
> + cpu_disable_c2_sleep++;
> if (bootverbose)
> printf("TSC timecounter disables C2 and C3.\n");
> }
>
This does not work.
I added a printf before the outer if clause, and it says
init_TSC_tc:546: deepest vendor 8086 amd_pminfo
full boot dmesg attached. Looks init_TSC_tc() is called too early before
acpi_cpu_attach() initializing cpu_deepest_sleep. Maybe it should be put
after
driver initialization, since it depends on probed ACPI C states?
-Jia-Shiun.
Table 'FACP' at 0xcdd80290
Table 'APIC' at 0xcdd80390
APIC: Found table at 0xcdd80390
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 2: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 130 ACPI ID 3: disabled
MADT: Found CPU APIC ID 131 ACPI ID 4: disabled
Copyright (c) 1992-2017 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 12.0-CURRENT #21 r313909M: Thu Feb 23 22:31:13 CST 2017
jsli@jsli-e5:/usr/obj/usr/src/c2dlag/sys/GENERIC-NODEBUG amd64
FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM
3.9.1)
Table 'FACP' at 0xcdd80290
Table 'APIC' at 0xcdd80390
Table 'MCFG' at 0xcdd80400
Table 'OEMB' at 0xcdd8e040
Table 'HPET' at 0xcdd89530
Table 'GSCI' at 0xcdd8e0d0
Table 'OSFR' at 0xcdd89570
Table 'SSDT' at 0xcdd90bd0
ACPI: No SRAT table found
PPIM 0: PA=0xa, VA=0x8261, size=0x1, mode=0
VT(vga): resolution 640x480
Preloaded elf kernel "/boot/c2d.v/kernel" at 0x824ad000.
Preloaded /boot/entropy "/boot/entropy" at 0x824ade40.
Preloaded elf obj module "/boot/c2d.v/zfs.ko" at 0x824ade90.
Preloaded elf obj module "/boot/c2d.v/opensolaris.ko" at 0x824ae678.
Calibrating TSC clock ... TSC clock: 2800156285 Hz
CPU: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz (2800.16-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10
Features=0xbfebfbff
Features2=0xc08e39d
AMD Features=0x20100800
AMD Features2=0x1
TSC: P-state invariant, performance statistics
Instruction TLB: 2M pages, 4-way, 8 entries or 4M pages, 4-way, 4 entries
Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries
64-Byte prefetching
Data TLB0: 4 KByte pages, 4-way associative, 16 entries
Data TLB0: 4 MByte pages, 4-way set associative, 16 entries
2nd-level cache: 3MByte, 12-way set associative, 64 byte line size
1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size
Data TLB1: 4 KByte pages, 4-way associative, 256 entries
1st-level data cache: 32 KB, 8-way set associative, 64 byte line size
L2 cache: 3072 kbytes, 8-way associative, 64 bytes/line
real memory = 4294967296 (4096 MB)
Physical memory chunk(s):
0x0001 - 0x0009afff, 569344 bytes (139 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x024f6000 - 0xc614efff, 3284504576 bytes (801881 pages)
0x0001 - 0x00012ffcdfff, 805101568 bytes (196558 pages)
avail memory = 4058112000 (3870 MB)
Event timer "LAPIC" quality 100
LAPIC: ipi_wait() us multiplier 68 (r 4100134 tsc 2800156285)
ACPI APIC Table:
Package ID shift: 1
L2 cache ID shift: 1
L1 cache ID shift: 0
Core ID shift: 0
INTR: Adding local APIC 1 as a target
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
Package HW ID = 0
Core HW ID = 0
CPU0 (BSP): APIC ID: 0
Core HW ID = 1
CPU1 (AP): APIC ID: 1
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 2
x86bios: IVT 0x00-0x0004ff at 0x
Re: TSC as timecounter makes system lag
On Fri, Feb 24, 2017 at 12:55 AM, John Baldwin wrote:
> On Thursday, February 23, 2017 11:04:58 PM Jia-Shiun Li wrote:
> >
> >
> > This does not work.
> >
> > I added a printf before the outer if clause, and it says
> >
> > init_TSC_tc:546: deepest vendor 8086 amd_pminfo
> >
> > full boot dmesg attached. Looks init_TSC_tc() is called too early before
> > acpi_cpu_attach() initializing cpu_deepest_sleep. Maybe it should be put
> > after
> > driver initialization, since it depends on probed ACPI C states?
>
> We don't actually need cpu_deepest_sleep. We could just set C2STOP always.
> It doesn't hurt to have the flag set if the system only supports C1 except
> that you get the printf in a verbose boot.
>
> Try this slight variation of Konstantin's patch. If this works we can
> remove
> cpu_deepest_sleep entirely as a followup since it will no longer be used:
>
> Index: tsc.c
> ===
> --- tsc.c (revision 314113)
> +++ tsc.c (working copy)
> @@ -542,9 +542,11 @@ init_TSC_tc(void)
> * result incorrect runtimes for kernel idle threads (but not
> * for any non-idle threads).
> */
> - if (cpu_deepest_sleep >= 2 && cpu_vendor_id == CPU_VENDOR_INTEL &&
> + if (cpu_vendor_id == CPU_VENDOR_INTEL &&
> (amd_pminfo & AMDPM_TSC_INVARIANT) == 0) {
> tsc_timecounter.tc_flags |= TC_FLAGS_C2STOP;
> + if (timecounter == &tsc_timecounter)
> + cpu_disable_c2_sleep++;
> if (bootverbose)
> printf("TSC timecounter disables C2 and C3.\n");
> }
>
Tested working on E7400 against r313909. And changing timecounter from/to
TSC
correctly enables/disables C2.
The latter part cpu_disable_c2_sleep++ is not needed. When
init_TSC_tc() got called timecounter is not yet tsc_timecounter.
inittimecounter() later will do the work calling tc_windup().
-Jia-Shiun.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TSC as timecounter makes system lag
On Fri, Feb 24, 2017 at 7:45 PM, Konstantin Belousov wrote: > On Fri, Feb 24, 2017 at 12:15:26PM +0800, Jia-Shiun Li wrote: > > Tested working on E7400 against r313909. And changing timecounter from/to > > TSC > > correctly enables/disables C2. > > > > The latter part cpu_disable_c2_sleep++ is not needed. When > > init_TSC_tc() got called timecounter is not yet tsc_timecounter. > > inittimecounter() later will do the work calling tc_windup(). > > > > You mean, just this > - if (cpu_deepest_sleep >= 2 && cpu_vendor_id == CPU_VENDOR_INTEL && > + if (cpu_vendor_id == CPU_VENDOR_INTEL && > is enough to fix the issue ? If yes, we can remove the cpu_deepest_sleep > variable. This is John' observation, I think he would prefer to prepare > the patch. > Correct. That's enough. -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TSC as timecounter makes system lag
On Fri, Feb 24, 2017 at 9:32 PM, Jia-Shiun Li wrote: > On Fri, Feb 24, 2017 at 7:45 PM, Konstantin Belousov > wrote: > >> On Fri, Feb 24, 2017 at 12:15:26PM +0800, Jia-Shiun Li wrote: >> > Tested working on E7400 against r313909. And changing timecounter >> from/to >> > TSC >> > correctly enables/disables C2. >> > >> > The latter part cpu_disable_c2_sleep++ is not needed. When >> > init_TSC_tc() got called timecounter is not yet tsc_timecounter. >> > inittimecounter() later will do the work calling tc_windup(). >> > >> >> You mean, just this >> - if (cpu_deepest_sleep >= 2 && cpu_vendor_id == CPU_VENDOR_INTEL && >> + if (cpu_vendor_id == CPU_VENDOR_INTEL && >> is enough to fix the issue ? If yes, we can remove the cpu_deepest_sleep >> variable. This is John' observation, I think he would prefer to prepare >> the patch. >> > > Correct. That's enough. > > Since that's simple enough... patch attached. Tested against r313909 too. -Jia-Shiun. fix-tsc-timecounter.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Rangeley C2758: missed IOMMU support for Xen Dom0
On Fri, May 26, 2017 at 2:53 AM, Alex Deiter wrote: > > # pciconf -lv > none1@pci0:0:15:0: class=0x080600 card=0x082015d9 chip=0x1f168086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Atom processor C2000 RCEC' > class = base peripheral > subclass = IOMMU > Rangeley does not have IOMMU, or in Intel term VT-d. Device 15 is RCEC for PCIe error reporting. -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to increase MAXPHYS?
On Sun, Jun 4, 2017 at 1:33 PM, Warner Losh wrote: > On Sat, Jun 3, 2017 at 2:59 PM, Colin Percival > wrote: > > > On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > > wrote: > > > Add better support for larger I/O clusters, including larger physical > > > I/O. The support is not mature yet, and some of the underlying > > implementation > > > needs help. However, support does exist for IDE devices now. > > > > and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > > again, > > or do we need to wait at least two decades between changes? > > > > This is hurting performance on some systems; in particular, EC2 "io1" > disks > > are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized spinning > > rust) > > disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > > recommends > > using a maximum I/O size of 1 MB (and despite NFS not being *physical* > I/O > > it > > seems to still be limited by MAXPHYS). > > > > MAXPHYS is the largest I/O transaction you can push through the system. It > doesn't matter that the I/O is physical or not. The name is a relic from a > time that NFS didn't exist. > Sounds like MAXPHYS usage has grown too widespread than intended to be. Would it be better for specific components to depart from MAXPHYS if they care about performance, and use more specific limit from protocol or hardware spec etc. e.g. MAXDMASIZE, MAX_ATA_IO_SIZE, and maybe some query functions. Having a global max for everything to use just doesn't feel right. If this is the direction to go in the long run, then changing MAXPHYS references to own-defined limitations may be more meaningful than raising it universally. Then I'd propose not to raise it, or people would not be motivated to fix that. A quick grep shows that many references use it as a cap only 'for safety'. -Jia-Shiun ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cpufreq not working as module on i386/amd64
I was cleaning up hard drive and found these old logs. Anyway I added some printf() and saw the process failed at device_find_child(..., "acpi_perf", ...) of est_acpi_info() i.e. it cannot find acpi_perf device. devinfo did confirmed the absence of acpi_perf. Comparing the dmesgs revealed the main difference: IST (i-state?) OEM tables in SSDT seems not loaded if cpufreq was not compiled into kernel, as it shows below. Before I diving into the ACPI part, can anyone familiar with how ACPI works shed me some light? ->8->8->8- % diff -bu cpufreq-nb.log cpufreq-no.log ... @@ -158,17 +158,11 @@ acpi0: Power Button (fixed) cpu0: Processor \\_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 -ACPI: SSDT 0xbfd8dc98 00223 (v01 PmRef Cpu0Ist 3000 INTL 20051117) -ACPI: Dynamic OEM Table Load: -ACPI: SSDT 0 00223 (v01 PmRef Cpu0Ist 3000 INTL 20051117) ACPI: SSDT 0xbfd8b598 00537 (v01 PmRef Cpu0Cst 3001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00537 (v01 PmRef Cpu0Cst 3001 INTL 20051117) cpu1: Processor \\_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 -ACPI: SSDT 0xbfd8ce18 001CF (v01 PmRefApIst 3000 INTL 20051117) -ACPI: Dynamic OEM Table Load: -ACPI: SSDT 0 001CF (v01 PmRefApIst 3000 INTL 20051117) ACPI: SSDT 0xbfd8df18 0008D (v01 PmRefApCst 3000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0008D (v01 PmRefApCst 3000 INTL 20051117 On Sat, Jan 29, 2011 at 4:41 PM, Alexander Best wrote: > On Sat Jan 29 11, Jia-Shiun Li wrote: >> Hi all, >> >> I found that cpufreq driver failed to attach when compiled as module >> and loaded, but it works fine when compiled into kernel. I am >> wondering if this is due to some kind of limitation, or can be fixed? > > that's rather odd. for me neither the module nor the kernel code works, since > my cpu isn't supported by sys/x86/cpufreq/est.c. actually only pentium mobile > cpus seem to be supported. > > maybe you can add some printf's to est.c:est_get_info() to identify at which > point error gets set. also you might want to make > > "est: cpu_vendor %s, msr %0jx\n", cpu_vendor, msr); > > non-conditional. maybe the output differy in kernel/module mode. > > cheers. > alex > >> >> Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop >> (amd64). Both got the same result. dmesg of T4200 attached. >> >> kldload module: >> ->8->8->8- >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a >> device_attach: est0 attach returned 6 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a >> -8<-8<-8<- >> (repeated 6 times, kldload retries?) >> >> compiled into kernel: >> ->8->8->8- >> ... >> fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 >> uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 >> isa_probe_children: probing PnP devices >> coretemp0: on cpu0 >> coretemp0: Setting TjMax=104 >> p4tcc0: on cpu0 >> est0: on cpu0 >> coretemp1: on cpu1 >> coretemp1: Setting TjMax=104 >> p4tcc1: on cpu1 >> est1: on cpu1 >> Device configuration finished. >> procfs registered >> ... >> -8<-8<-8<- >> >> Jia-Shiun. > > > -- > a13x ___ 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"
if_re not working on boot
Hi all, wondering if anyone else encounters the same situation. LOM Realtek RT8111F on my mainboard Asus P8H77M-LE does not appear to work on boot. Ping to any hosts has no response. But after "ifconfig re0 down up" it works fine. Looks like something was not properly initialized. verbose dmesg: http://pastebin.com/h4S38sGZ Jia-Shiun. ___ 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"
Failed to compile current kernel with llvm/clang
Hi all, I am trying to build world and kernel with llvm according to instructions on wiki: http://wiki.freebsd.org/BuildingFreeBSDWithClang buildworld is fine, but when building GENERIC kernel it failed on hpt27xx: ===> hpt27xx (all) /usr/src/sys/modules/hpt27xx/../../dev/hpt27xx/osm_bsd.c:1180:25: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] S_IRUSR | S_IWUSR, driver_name); ^~~ @/dev/hpt27xx/hpt27xx_config.h:46:21: note: expanded from: #define driver_name hpt27xx_driver_name ^~~ I cannot find symbol hpt27xx_driver_name in that directory. Is it expanded from some macros I am not aware of? BTW clang does generate much friendly and useful warnings so far as I saw. Regards, Jia-Shiun ___ 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: Failed to compile current kernel with llvm/clang
On Mon, Feb 20, 2012 at 2:00 PM, matt wrote: > You have the > WERROR= > NO_WERROR= > > lines in /etc/make.conf? You got me. I only quickly copy-pasted CC/CXX definitions and forgot about WERROR & NO_WERROR. No wonder others do not have this problem. Sorry for the noise. Thanks, Jia-Shiun. ___ 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: FreeBSD: Marvell 88SX61xx should be 88SE61xx
Hi all, Maybe some spam filters ate my mails so I am replying to current@. Could anyone help to commit it? Regards, Jia-Shiun On Thu, Feb 23, 2012 at 8:57 PM, Jia-Shiun Li wrote: > Hi Alexander, > > I've submitted a PR for this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=165271 > > could you help to review the patch attached to the PR and check it in? > It only changes strings, not any functionality. > > Regards, > Jia-Shiun. > > On Tue, Mar 29, 2011 at 1:57 AM, Jia-Shiun Li wrote: >> Hi Alexander, >> >> I am Jia-Shiun Li, writing to you for the Marvell SATA device names in >> FreeBSD drivers. >> >> I noticed the boot message for my onboard 88SE6121: >> >> atapci0: port >> 0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f mem >> 0xfeaffc00-0xfeaf irq 16 at device 0.0 on pci2 >> ahci0: on atapci0 >> >> according to Marvell their names should be 88SE[69]1xx instead of >> 88SX[69]1xx: >> http://www.marvell.com/products/storage/storage_system_solutions/sata_controllers_pc_consumer/ >> >> a simple way to tell is that mvs(4) devices are 88SX and ahci(4) devices are >> 88SE. >> >> I made a patch out of this, basically just text replacement. It does not >> affect functionality, but I think it would be better to be identified >> correctly anyway. Would you mind help committing the changes? >> >> Regards, >> >> Jia-Shiun. ___ 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"
r232498 breaks building ports security/nss with both gcc & clang
after updated current- as of Mar 5,
security/nss build broken at /usr/include/runetype.h &
/usr/include/xlocale/_ctype.h. A quick grep shows that nowhere else
under /usr/src/include uses 'inline'.
gcc:
gmake[1]: Entering directory
`/usr/ports/security/nss/work/nss-3.13.3/mozilla/security/nss/lib'
cd util; gmake libs
gmake[2]: Entering directory
`/usr/ports/security/nss/work/nss-3.13.3/mozilla/security/nss/lib/util'
cc -o FreeBSD10.0_OPT.OBJ/quickder.o -c -O2 -pipe
-I/usr/local/include/nspr -L/usr/local/lib -fno-strict-aliasing -O
-fPIC -ansi -Wall
-Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX
-UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_
UTIL_DIRECTLY -I../../dist/FreeBSD10.0_OPT.OBJ/include
-I../../dist/public/ -I../../dist/private/ -O -fPIC -ansi -Wall
-Wno-switch -D
FREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG
-D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -
I../../../dist/FreeBSD10.0_OPT.OBJ/include -I../../../dist/public/
-I../../../dist/private/ -O -fPIC -ansi -Wall -Wno-switch -DFREEBS
D -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG
-D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY
-I../..
/../../dist/FreeBSD10.0_OPT.OBJ/include -I../../../../dist/public/nss
-I../../../../dist/private/nss quickder.c
In file included from /usr/include/_ctype.h:94,
from /usr/include/ctype.h:46,
from secport.h:83,
from seccomon.h:62,
from secasn1.h:51,
from quickder.c:43:
/usr/include/runetype.h:93: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'const'
In file included from /usr/include/ctype.h:46,
from secport.h:83,
from seccomon.h:62,
from secasn1.h:51,
from quickder.c:43:
/usr/include/_ctype.h: In function '__maskrune':
/usr/include/_ctype.h:100: error: invalid type argument of '->'
/usr/include/_ctype.h: In function '__sbmaskrune':
/usr/include/_ctype.h:107: error: invalid type argument of '->'
/usr/include/_ctype.h: In function '__toupper':
/usr/include/_ctype.h:133: error: invalid type argument of '->'
/usr/include/_ctype.h: In function '__sbtoupper':
/usr/include/_ctype.h:140: error: invalid type argument of '->'
/usr/include/_ctype.h: In function '__tolower':
/usr/include/_ctype.h:147: error: invalid type argument of '->'
/usr/include/_ctype.h: In function '__sbtolower':
/usr/include/_ctype.h:154: error: invalid type argument of '->'
In file included from /usr/include/ctype.h:83,
from secport.h:83,
from seccomon.h:62,
from secasn1.h:51,
from quickder.c:43:
/usr/include/xlocale/_ctype.h: At top level:
/usr/include/xlocale/_ctype.h:112: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'int'
/usr/include/xlocale/_ctype.h:112: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'int'
/usr/include/xlocale/_ctype.h:113: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'int'
/usr/include/xlocale/_ctype.h:113: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'int'
/usr/include/xlocale/_ctype.h:114: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'int'
clang:
gmake[1]: Entering directory
`/usr/ports/security/nss/work/nss-3.13.3/mozilla/security/nss/lib'
cd util; gmake libs
gmake[2]: Entering directory
`/usr/ports/security/nss/work/nss-3.13.3/mozilla/security/nss/lib/util'
clang -o FreeBSD10.0_OPT.OBJ/quickder.o -c -O2 -pipe
-I/usr/local/include/nspr -L/usr/local/lib -fno-strict-aliasing -O
-fPIC -ansi -W
all -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX
-UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DU
SE_UTIL_DIRECTLY -I../../dist/FreeBSD10.0_OPT.OBJ/include
-I../../dist/public/ -I../../dist/private/ -O -fPIC -ansi -Wall
-Wno-switch
-DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG
-D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTL
Y -I../../../dist/FreeBSD10.0_OPT.OBJ/include -I../../../dist/public/
-I../../../dist/private/ -O -fPIC -ansi -Wall -Wno-switch -DFRE
EBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG
-D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -I..
/../../../dist/FreeBSD10.0_OPT.OBJ/include
-I../../../../dist/public/nss -I../../../../dist/private/nss
quickder.c
clang: warning: argument unused during compilation: '-L/usr/local/lib'
In file included from quickder.c:43:
In file included from ./secasn1.h:51:
In file included from ./seccomon.h:62:
In file included from ./secport.h:83:
In file included from /usr/include/ctype.h:46:
In file included from /usr/include/_ctype.h:94:
/usr/include/runetype.h:93:8: error: unknown type name 'inline'
static inline const _RuneLocale *__getCurrentRuneLocale(void)
^
/usr/include/runetype.h:93:15: error: expected identifier or '('
static inlin
boot2 overflow when building with clang
I am not familiar with boot2, but it looks like allocated size for boot2 is not enough to hold code generated by clang. Reverting r232570 fixes it. ===> sys/boot/i386/boot2 (all) objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mllvm -stack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99-S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp clang -c boot2.s clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mllvm -stack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99 -c /usr/src/sys/boot/i386/boot2/sio.S ld -static -N --gc-sections -nostdlib -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=15a1 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e31 text=200 data=1c31 org=0 entry=0 -49 bytes available *** [boot2] Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** [all] Error code 1 Stop in /usr/src/sys/boot/i386. *** [all] Error code 1 Stop in /usr/src/sys/boot. *** [all] Error code 1 Stop in /usr/src/sys. *** [sys.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. Jia-Shiun. ___ 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"
make delete-old failed to remove bind directories
as title and as of FreeBSD jsli-bsd64 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #3 r255962: Tue Oct 1 15:22:04 CST 2013 jsli@jsli-bsd64:/usr/obj/usr/src/sys/GENERIC amd64 'make delete-old' failed to remove bind-related dirs. Looks like ordering issue to me. Also there are still some dirs and files exist after several repeat runs to overcome ordering issue. Not sure if they are created by me though. I did not make use of bind. output: >>> Removing old directories /usr/include/lwres rmdir: /usr/share/doc/bind9: Directory not empty /usr/share/doc/bind9/arm /usr/share/doc/bind9/misc /var/named/dev rmdir: /var/named/etc: Directory not empty rmdir: /var/named/etc/namedb: Directory not empty /var/named/etc/namedb/dynamic /var/named/etc/namedb/master /var/named/etc/namedb/slave rmdir: /var/named/var: Directory not empty /var/named/var/dump /var/named/var/log rmdir: /var/named/var/run: Directory not empty /var/named/var/run/named /var/named/var/stats /var/run/named >>> Old directories removed To remove old libraries run 'make delete-old-libs'. jsli@jsli-bsd64:/usr/src # ls -R /var/named/etc/namedb/ named.conf working/ /var/named/etc/namedb/working: jsli@jsli-bsd64:/usr/src # Jia-Shiun. ___ 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: cron(8) improvement
On Sun, Nov 10, 2013 at 10:13 AM, Adrian Chadd wrote: > > The point I'm making is this: > > * when populating rc.conf.d/, don't just do 'cp' in a post-install script > * when populating the cron daemon entries in rc.cron.d, don't just > 'cp' in a post-install script. > > sounds like we need a ports/pkg config system for admins *after* they have been installed, if bsdconfig interface for en-/disabling services is too simple to do what users want. For cron.d I believe only a few will object it. It is only question who should put files in it. Taking dbus/hald for example, that probably belongs to xorg meta-ports to do the necessary works to enable it, if dbus users prefer to enable it manually. And that will involve painful package dependencies. Imagine more complex cases like letting user choose cron tasks to enable. ports/pkg being a wrapper around 3rd party packages, inevitably it will need to decide some default settings in advance for user. For compile time it is probably ok, or user can choose to compile it with different options. Do we need to agree on some common user interface to do the run-time user-adjustable settings for applications? That's probably also subject to what a pkg install should do by definition. -Jia-Shiun. ___ 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: Leaving the Desktop Market
On Wed, May 7, 2014 at 1:05 AM, Matthias Apitz wrote: > > # dmesg > ... > CPU: Intel(R) Celeron(R) M processor 900MHz (900.11-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x6d8 Family = 0x6 Model = 0xd Stepping = 8 > > Features=0xafe9fbff > AMD Features=0x10 > real memory = 2147483648 (2048 MB) > avail memory = 2076614656 (1980 MB) > The Celeron M CPU is a Pentium-M without EIST. Otherwise you'd see EST bit set in Features2. See https://wiki.freebsd.org/AsusEee. Guess that's why Asus deliberately underclocked it to 630MHz in the first gen EEE PC 701 - no automatic way available. Don't know if p4tcc or acpi_throttle helps, though. -Jia-Shiun. ___ 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: Processor cores not properly detected/activated?
On Sat, May 24, 2014 at 6:38 PM, Tim Bishop wrote: > On Fri, May 23, 2014 at 09:03:12PM -0600, Alan Somers wrote: >> Yeah, I think so. It seems like a GENERIC kernel ought to be able to >> handle the biggest commonly available quad socket systems. Anything >> with more than 4 sockets, though, is probably too exotic to deserve >> such special treatment. > > I submitted a PR to that effect: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=190169 > > Thanks again for your help. > > Tim. > Hi, I read in the follow-up of the PR that current hard limit is 256. Currently available systems* can already push usage up to 240. IVB-EX aka Xeon E7v2 supports 8-socket * 15-core * 2-thread. Expect something to break 256 in less than a year I think. X2APIC support will be required then. In theory it is already possible to build larger systems with custom glue logic, but I am not aware of any. *: E.g. IBM System x3950 X6 -Jia-Shiun. ___ 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"
all processes have ppid 1
Hi all, on r270962 -current ps indicates all processes have ppid 1 which is not reasonable. This happened to me since about 1 week ago. Wondering if anyone sees the same. the 'ps axdl' result looks like: http://pastebin.com/qFg5FusN -Jia-Shiun. ___ 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: all processes have ppid 1
On Wed, Sep 3, 2014 at 2:27 PM, Mateusz Guzik wrote: > > Please try r270993. > confirm fixed. Thanks! http://pastebin.com/YrPtL35p -Jia-Shiun. ___ 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"
Panic at USB drive plugging in
Hi all, as personal preference I compiled kernel with drivers as module as possible. Recently I found that plugging in USB drives causes kernel to panic. But it does not happen when booting with GENERIC kernel which has USB drivers compiled in. panic screenshot: http://goo.gl/pIIDaF back trace: http://goo.gl/ww4yy6 the kernel is compiled: FreeBSD 4cbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r253395: Fri Jul 19 15:20:08 CST 2013 jsli@4cbsd:/usr/obj/usr/src/sys/Minimal amd64 the back trace looks like devd and something had timing issues. Any ideas? Regards, Jia-Shiun. ___ 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: Panic at USB drive plugging in
On Wed, Jul 24, 2013 at 12:13 AM, Alexander Motin wrote: > On 23.07.2013 19:07, Hans Petter Selasky wrote: >> This looks like a CAM/SCSI problem and not directly USB stack problem. > > It seems crashed inside the CAM sg driver, that is not part of GENERIC > kernel. Are you using it is some way? > No. I do not use it at all. kernel conf & loader.conf: ---8<-- # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: head/sys/amd64/conf/GENERIC 252867 2013-07-06 07:49:41Z delphij $ cpu HAMMER ident Minimal options MSGBUF_SIZE=327680 makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options TCP_OFFLOAD # TCP offload options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options QUOTA # Enable disk quotas for UFS options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD # New Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options CAPABILITY_MODE # Capsicum capability mode options CAPABILITIES # Capsicum capabilities options MAC # TrustedBSD MAC Framework options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF # Kernel ELF linker loads CTF data options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging support. Always need this: options KDB # Enable kernel debugger support. # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use this instead: options DDB # Support DDB. options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver options VESA # Add support for VESA BIOS Extensions (VBE) device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # add support for th
Re: Panic at USB drive plugging in
On Wed, Jul 24, 2013 at 4:02 AM, Alexander Motin wrote: > cam.k kernel module includes all existing periph drivers in one bundle. > Loading cam.ko you are probably getting sg driver also, that triggers > reported issue. You may try to rip out sg with single line hack to module's > Makefile. The real fix require looking closer on sg, which I never used. > Indeed. Test result did confirm that if sg is not included in cam.ko USB drives will not cause kernel to panic. Jia-Shiun. ___ 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: Panic at USB drive plugging in
2013/7/24 下午10:26 於 "Jia-Shiun Li" 寫道： > On Wed, Jul 24, 2013 at 4:02 AM, Alexander Motin wrote: > > cam.k kernel module includes all existing periph drivers in one bundle. > > Loading cam.ko you are probably getting sg driver also, that triggers > > reported issue. You may try to rip out sg with single line hack to > module's > > Makefile. The real fix require looking closer on sg, which I never used. > > > > Indeed. Test result did confirm that if sg is not included in cam.ko > USB drives will not cause kernel to panic. > > Hi all, turns out, it may be conflicts between assumed and actual sg usage. The sg driver specifically assumes a write-read sequence. If a read comes first it will cause sg to panic at msleep() in sgread. In my case the process is hald-probe-storage tasting new devices. But it can be as simple as "dd if=/dev/sgX". I am wondering that, is sg necessary on FreeBSD? Since most applications seem to live happily without it in GENERIC kernel. Maybe we can isolate it from cam.ko to make cam usable as module, and make the standalone sg module depending on cam module before sg got more resistant to misuse? Regards, Jia-Shiun. ___ 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"
