Re: svn commit: r209611 - head/sys/dev/e1000
On 18 August 2010 14:52, pluknet wrote: > On 17 August 2010 20:27, Jack Vogel wrote: >> Cool the first person to actually try and use it :) >> >> Yes, there's one key thing you have to do right now that's not >> documented, because of the simplistic PCI structure the guest >> has the kernel blacklists it from using MSIX. SO, what you need >> to do is set the honor_blacklist (that's not the complete string, >> use sysctl -a |grep blacklist to find it) and set that to 0. It needs >> to be set at boot. >> >> That should get you running. >> >> Jack >> > > Nice, thanks! > > It works! > By the way, Sometimes after boot I have to kldreload if_igb.ko several times until watchdog go to sleep, so traffic starts flowing. igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 1, hw tdt = 1 igb0: TX(0) desc avail = 1023,Next TX to Clean = 0 igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 3, hw tdt = 3 igb0: TX(0) desc avail = 1021,Next TX to Clean = 0 igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 6, hw tdt = 6 igb0: TX(0) desc avail = 1018,Next TX to Clean = 0 igb0: detached igb0: mem 0xf202-0xf2023fff,0xf2024000-0xf2027fff at device 4.0 on pci0 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 76:99:ea:b0:e0:eb igb0: link state changed to UP stray irq0 stray irq0 igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 3, hw tdt = 3 igb0: TX(0) desc avail = 1021,Next TX to Clean = 0 stray irq0 stray irq0 too many stray irq 0's: not logging anymore igb0: promiscuous mode enabled igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 28, hw tdt = 28 igb0: TX(0) desc avail = 996,Next TX to Clean = 0 igb0: promiscuous mode disabled igb0: detached igb0: mem 0xf202-0xf2023fff,0xf2024000-0xf2027fff at device 4.0 on pci0 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 76:99:ea:b0:e0:eb igb0: link state changed to UP dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.1 dev.igb.0.%driver: igb dev.igb.0.%location: slot=4 function=0 handle=\_SB_.PCI0.S4__ dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10ca subvendor=0x8086 subdevice=0xa03c class=0x02 dev.igb.0.%parent: pci0 dev.igb.0.nvm: -1 dev.igb.0.flow_control: 3 dev.igb.0.enable_aim: 1 dev.igb.0.rx_processing_limit: 100 dev.igb.0.link_irq: 0 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.device_control: 0 dev.igb.0.rx_control: 0 dev.igb.0.interrupt_mask: 0 dev.igb.0.extended_int_mask: 0 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 58976 dev.igb.0.fc_low_water: 58960 dev.igb.0.queue0.txd_head: 424 dev.igb.0.queue0.txd_tail: 424 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 186 dev.igb.0.queue0.rxd_head: 758 dev.igb.0.queue0.rxd_tail: 758 dev.igb.0.queue0.rx_packets: 4855 dev.igb.0.queue0.rx_bytes: 316295 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.queue1.txd_head: 0 dev.igb.0.queue1.txd_tail: 0 dev.igb.0.queue1.no_desc_avail: 0 dev.igb.0.queue1.tx_packets: 0 dev.igb.0.queue1.rxd_head: 0 dev.igb.0.queue1.rxd_tail: 1023 dev.igb.0.queue1.rx_packets: 0 dev.igb.0.queue1.rx_bytes: 0 dev.igb.0.queue1.lro_queued: 0 dev.igb.0.queue1.lro_flushed: 0 dev.igb.0.mac_stats.good_pkts_recvd: 0 dev.igb.0.mac_stats.good_pkts_txd: 0 dev.igb.0.mac_stats.good_octets_recvd: 0 dev.igb.0.mac_stats.good_octest_txd: 0 dev.igb.0.mac_stats.mcast_pkts_recvd: 0 -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ROOT MOUNT ERROR when booting from zfs
Hi all, i am getting the error message in $subject when trying to boot from zfs. I followed the instructions found in: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror Before posting all config details and asking what i might have done wrong: Is there any possibility to get a more detailed error message than just ROOT MOUNT ERROR? e.g. zpool not found | zpool could not be imported | illegal mount options | etc The kernel reports that it is trying to mount from zfs:zroot, which is correct. The zfs kernel module is being loaded. -- Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-62394 Fax :-3341 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ROOT MOUNT ERROR when booting from zfs
On Thu, 19 Aug 2010 14:33:11 +0200 Heinrich Rebehn wrote: > Hi all, > > i am getting the error message in $subject when trying to boot from zfs. > I followed the instructions found in: > > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror > > Before posting all config details and asking what i might have done wrong: Is > there any possibility to get a more detailed error message than just ROOT > MOUNT ERROR? e.g. zpool not found | zpool could not be imported | illegal > mount options | etc You have tried verbose boot? If not, try it and see if you get more information. -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRERELEASE: CPU packages not detected correctly
on 10/08/2010 19:55 pluknet said the following: > On 16 July 2010 19:47, Jung-uk Kim wrote: >> The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and >> sys/i386/i386/mp_machdep.c. >> >> http://people.freebsd.org/~jkim/mp_machdep2.diff >> > > > Hi. > > Just checked on Xen HVM with 3 cores. > 1) 8.1 unmodified: > FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > FreeBSD/SMP: 1 package(s) x 3 core(s) > > 2) 8.1 + patch > FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > WARNING: Non-uniform processors. > WARNING: Using suboptimal topology. Can you debug, e.g. with printfs, what exactly goes wrong? I wonder if in this case code follows some unusual/unexpected path. BTW, could you please also provide CPU name/model/features as detected by the kernel? Thanks! -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: svn commit: r209611 - head/sys/dev/e1000
On Thu, Aug 19, 2010 at 2:45 AM, pluknet wrote: > > By the way, > > Sometimes after boot I have to kldreload if_igb.ko several > times until watchdog go to sleep, so traffic starts flowing. > Hmmm, the intention is that the VF always be single queue, but I see the code I used to limit it is broken, so you are getting two queues. For now near the top of if_igb.c set igb_num_queues = 1; I believe that will get rid of the watchdogs. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On 19 August 2010 20:39, Andriy Gapon wrote: > on 10/08/2010 19:55 pluknet said the following: >> On 16 July 2010 19:47, Jung-uk Kim wrote: >>> The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and >>> sys/i386/i386/mp_machdep.c. >>> >>> http://people.freebsd.org/~jkim/mp_machdep2.diff >>> >> >> >> Hi. >> >> Just checked on Xen HVM with 3 cores. >> 1) 8.1 unmodified: >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> FreeBSD/SMP: 1 package(s) x 3 core(s) >> >> 2) 8.1 + patch >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >> WARNING: Non-uniform processors. >> WARNING: Using suboptimal topology. > > Can you debug, e.g. with printfs, what exactly goes wrong? > I wonder if in this case code follows some unusual/unexpected path. Sorry, I'm a bit busy right now. I hope to debug this somewhere in the next week. > BTW, could you please also provide CPU name/model/features as detected by the > kernel? Sure. CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0x1781fbbf Features2=0x80982201> TSC: P-state invariant real memory = 4194304000 (4000 MB) avail memory = 3932786688 (3750 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 2 cpu2 (AP/HT): APIC ID: 4 Just a thought. # HTT might somehow correlate with current maxcpus limit (32). > > Thanks! -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Thursday 19 August 2010 12:56 pm, pluknet wrote: > On 19 August 2010 20:39, Andriy Gapon wrote: > > on 10/08/2010 19:55 pluknet said the following: > >> On 16 July 2010 19:47, Jung-uk Kim wrote: > >>> The patch should apply fine on both > >>> sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. > >>> > >>> http://people.freebsd.org/~jkim/mp_machdep2.diff > >> > >> Hi. > >> > >> Just checked on Xen HVM with 3 cores. > >> 1) 8.1 unmodified: > >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > >> FreeBSD/SMP: 1 package(s) x 3 core(s) > >> > >> 2) 8.1 + patch > >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > >> WARNING: Non-uniform processors. > >> WARNING: Using suboptimal topology. > > > > Can you debug, e.g. with printfs, what exactly goes wrong? > > I wonder if in this case code follows some unusual/unexpected > > path. > > Sorry, I'm a bit busy right now. > I hope to debug this somewhere in the next week. > > > BTW, could you please also provide CPU name/model/features as > > detected by the kernel? > > Sure. > CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz > 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 6 > Model = 1a Stepping = 5 > Features=0x1781fbbfE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x80982201> > TSC: P-state invariant > real memory = 4194304000 (4000 MB) > avail memory = 3932786688 (3750 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP/HT): APIC ID: 2 > cpu2 (AP/HT): APIC ID: 4 > > Just a thought. > # HTT might somehow correlate with current maxcpus limit (32). One thing I am not sure is whether those CPUID instructions are executed on *real* CPUs or translated in HVM. On top of that, I am not even sure they will be executed on *correct* cores. I bet they won't. If that's the case, we should add exception for virtualized environment as we did for default HZ. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRERELEASE: CPU packages not detected correctly
on 19/08/2010 19:56 pluknet said the following: > CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 > > Features=0x1781fbbf > Features2=0x80982201> > TSC: P-state invariant > real memory = 4194304000 (4000 MB) > avail memory = 3932786688 (3750 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP/HT): APIC ID: 2 > cpu2 (AP/HT): APIC ID: 4 Thanks! BTW, what does Intel's code report? Jung-uk's convenience script: http://people.freebsd.org/~jkim/cpu_topology-12212009.sh -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ROOT MOUNT ERROR when booting from zfs
On 19.08.2010, at 17:24, Torfinn Ingolfsen wrote: > On Thu, 19 Aug 2010 14:33:11 +0200 > Heinrich Rebehn wrote: > >> Hi all, >> >> i am getting the error message in $subject when trying to boot from zfs. >> I followed the instructions found in: >> >> http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror >> >> Before posting all config details and asking what i might have done wrong: >> Is there any possibility to get a more detailed error message than just ROOT >> MOUNT ERROR? e.g. zpool not found | zpool could not be imported | illegal >> mount options | etc > > You have tried verbose boot? > If not, try it and see if you get more information. > -- > Regards, > Torfinn Ingolfsen Yes, i have tried. I did get a flurry of information, but nothing related to the kernel not being able to mount the root fs. In the meanwhile, i have redone the installation and for some reason it is working now. Probably the pool cache was missing.. :-) Now i have another problem: The root fs on on a 4-disk zfs mirror. I am testing under VMware fusion using virtual scsi disks. In order to test redundancy, i removed the first disk and booting failed. The loader reports: error 1 lba 32 error 1 lba 1 error 1 lba 32 error 1 lba 1 error 1 lba 32 error 1 lba 1 error 1 lba 32 error 1 lba 1 No ZFS pools located, can't boot If i remove any other of the 3 disks instead, booting works fine. Is the pool's configuration only stored on the first disk? Do i have to replicate it to the other disks by hand? -Heinrich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ROOT MOUNT ERROR when booting from zfs
on 19/08/2010 20:46 Heinrich Rebehn said the following: > Now i have another problem: > > The root fs on on a 4-disk zfs mirror. I am testing under VMware fusion using > virtual scsi disks. In order to test redundancy, i removed the first disk and > booting failed. The loader reports: > > error 1 lba 32 error 1 lba 1 error 1 lba 32 error 1 lba 1 error 1 lba 32 error > 1 lba 1 error 1 lba 32 error 1 lba 1 No ZFS pools located, can't boot > > If i remove any other of the 3 disks instead, booting works fine. Is the > pool's > configuration only stored on the first disk? Do i have to replicate it to the > other disks by hand? Fix for this has been recently MFC-ed to stable/8. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ROOT MOUNT ERROR when booting from zfs
On 19.08.2010, at 19:50, Andriy Gapon wrote: > on 19/08/2010 20:46 Heinrich Rebehn said the following: >> Now i have another problem: >> >> The root fs on on a 4-disk zfs mirror. I am testing under VMware fusion using >> virtual scsi disks. In order to test redundancy, i removed the first disk and >> booting failed. The loader reports: >> >> error 1 lba 32 error 1 lba 1 error 1 lba 32 error 1 lba 1 error 1 lba 32 >> error >> 1 lba 1 error 1 lba 32 error 1 lba 1 No ZFS pools located, can't boot >> >> If i remove any other of the 3 disks instead, booting works fine. Is the >> pool's >> configuration only stored on the first disk? Do i have to replicate it to the >> other disks by hand? > > Fix for this has been recently MFC-ed to stable/8. > > -- > Andriy Gapon Great! Thanks to all FreeBSD developers! --Heinrich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On 19 August 2010 21:27, Andriy Gapon wrote: > on 19/08/2010 19:56 pluknet said the following: >> CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class >> CPU) >> Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 >> >> Features=0x1781fbbf >> Features2=0x80982201> >> TSC: P-state invariant >> real memory = 4194304000 (4000 MB) >> avail memory = 3932786688 (3750 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP/HT): APIC ID: 2 >> cpu2 (AP/HT): APIC ID: 4 > > Thanks! > BTW, what does Intel's code report? > Jung-uk's convenience script: > http://people.freebsd.org/~jkim/cpu_topology-12212009.sh > Software visible enumeration in the system: Number of logical processors visible to the OS: 3 Number of logical processors visible to this process: 3 Number of processor cores visible to this process: 3 Number of physical packages visible to this process: 1 Hierarchical counts by levels of processor topology: # of cores in package 0 visible to this process: 3 . Affinity masks per SMT thread, per core, per package: Individual: P:0, C:0, T:0 --> 1 Core-aggregated: P:0, C:0 --> 1 Individual: P:0, C:1, T:0 --> 2 Core-aggregated: P:0, C:1 --> 2 Individual: P:0, C:2, T:0 --> 4 Core-aggregated: P:0, C:2 --> 4 Pkg-aggregated: P:0 --> 7 APIC ID listings from affinity masks OS cpu 0, Affinity mask 01 - apic id 0 OS cpu 1, Affinity mask 02 - apic id 2 OS cpu 2, Affinity mask 04 - apic id 4 Package 0 Cache and Thread details L1D is Level 1 Data cache, size(KBytes)= 32, Cores/cache= 1, Caches/package= 3 L1I is Level 1 Instruction cache, size(KBytes)= 32, Cores/cache= 1, Caches/package= 3 L2 is Level 2 Unified cache, size(KBytes)= 256, Cores/cache= 1, Caches/package= 3 L3 is Level 3 Unified cache, size(KBytes)= 8192, Cores/cache= 1, Caches/package= 3 ++++ Cache | L1D| L1D| L1D| Size | 32K| 32K| 32K| OScpu#| 0| 1| 2| Core | c0| c1| c2| AffMsk| 1| 2| 4| ++++ Cache | L1I| L1I| L1I| Size | 32K| 32K| 32K| ++++ Cache | L2| L2| L2| Size |256K|256K|256K| ++++ Cache | L3| L3| L3| Size | 8M| 8M| 8M| ++++ Combined socket AffinityMask= 0x7 -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On 19 August 2010 21:26, Jung-uk Kim wrote: > On Thursday 19 August 2010 12:56 pm, pluknet wrote: >> On 19 August 2010 20:39, Andriy Gapon wrote: >> > on 10/08/2010 19:55 pluknet said the following: >> >> On 16 July 2010 19:47, Jung-uk Kim wrote: >> >>> The patch should apply fine on both >> >>> sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. >> >>> >> >>> http://people.freebsd.org/~jkim/mp_machdep2.diff >> >> >> >> Hi. >> >> >> >> Just checked on Xen HVM with 3 cores. >> >> 1) 8.1 unmodified: >> >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> >> FreeBSD/SMP: 1 package(s) x 3 core(s) >> >> >> >> 2) 8.1 + patch >> >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >> >> WARNING: Non-uniform processors. >> >> WARNING: Using suboptimal topology. >> > >> > Can you debug, e.g. with printfs, what exactly goes wrong? >> > I wonder if in this case code follows some unusual/unexpected >> > path. >> >> Sorry, I'm a bit busy right now. >> I hope to debug this somewhere in the next week. >> >> > BTW, could you please also provide CPU name/model/features as >> > detected by the kernel? >> >> Sure. >> CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz >> 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 6 >> Model = 1a Stepping = 5 >> Features=0x1781fbbf>E,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT> >> Features2=0x80982201> >> TSC: P-state invariant >> real memory = 4194304000 (4000 MB) >> avail memory = 3932786688 (3750 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP/HT): APIC ID: 2 >> cpu2 (AP/HT): APIC ID: 4 >> >> Just a thought. >> # HTT might somehow correlate with current maxcpus limit (32). > > One thing I am not sure is whether those CPUID instructions are > executed on *real* CPUs or translated in HVM. I may add only that of Features2 presents only in Xen HVM environment, and its role is afaik to indicate a Xen guest mode. There is no any mention of this bit in the latest Intel doc (ie it's reserved/unused). Also, at least NetBSD has a special handling of this bit. See commit log for CPUID2_RAZ in sys/arch/x86/include/specialreg.h, 1.37 FWIW RAZ states for "reserved and zero" or so. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with mxge on RELENG_8_1
At 3:21 PM -0400 8/13/10, Robert Healey wrote: I recently updated the central file server/router systems for a pair of research clusters from RELENG_8_0 to RELENG_8_1. After following the proper procedures, the network throughput when pulling files from both machines via mxge0 is 200KB/s or less. Before the update, 50MB/s was the normal rate. Doing some testing, with the 8.1 kernel booted, I can upload files to the server over the 10G link with scp or NFS at the expected rates. I can fetch files from the Internet using this server as the NAT gateway also at the expected rates. Retrieving files from the server over mxge, the throughput falls to 200KB/s. Retrieving files from the server from the onboard Broadcom NIC, rates are as to be expected from gigabit. With 8.0, everything works as expected. Hardware Config 1: Dell Poweredge R610 with 2 Xeon E5530 @ 2.4 GHz, hyperthread disabled and 24GB RAM. Onboard interface is bce. Disk is attached via a PERC 6/E. Internal cluster switch is Dell Powerconnect 6248P. This switch sees excessive large packets on the 10G connection on 8.1, but not 8.0. Hardware Config 2: HP Proliant DL 320G6 with 1 Xeon E5540 @ 2.53GHz, hyperthread enabled and 8GB RAM. Onboard interface is bge. Disk is attached via a HP Smart Array P212. Internal cluster switch is an HP Procurve 2910al. It does not see any packet errors from the 10G link. You're seeing the performance problems with both scp and NFS? Could you get some tcpdumps of a file transfer with both setups (8.0 vs 8.1), just to see if something very odd jumps out? If I'm reading this right, file transfers work at expected speeds if the file is going *to* the server, but you see the slowdown when you're pulling files *from* the server. That sounds similar to a problem with a duplex-mismatch, except of course that you shouldn't be getting into duplex issues on a gigabit network. -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Thursday 19 August 2010 03:30 pm, pluknet wrote: > On 19 August 2010 21:26, Jung-uk Kim wrote: > > On Thursday 19 August 2010 12:56 pm, pluknet wrote: > >> On 19 August 2010 20:39, Andriy Gapon wrote: > >> > on 10/08/2010 19:55 pluknet said the following: > >> >> On 16 July 2010 19:47, Jung-uk Kim wrote: > >> >>> The patch should apply fine on both > >> >>> sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. > >> >>> > >> >>> http://people.freebsd.org/~jkim/mp_machdep2.diff > >> >> > >> >> Hi. > >> >> > >> >> Just checked on Xen HVM with 3 cores. > >> >> 1) 8.1 unmodified: > >> >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > >> >> FreeBSD/SMP: 1 package(s) x 3 core(s) > >> >> > >> >> 2) 8.1 + patch > >> >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > >> >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > >> >> WARNING: Non-uniform processors. > >> >> WARNING: Using suboptimal topology. > >> > > >> > Can you debug, e.g. with printfs, what exactly goes wrong? > >> > I wonder if in this case code follows some unusual/unexpected > >> > path. > >> > >> Sorry, I'm a bit busy right now. > >> I hope to debug this somewhere in the next week. > >> > >> > BTW, could you please also provide CPU name/model/features as > >> > detected by the kernel? > >> > >> Sure. > >> CPU: Intel(R) Xeon(R) CPU � � � � � E5520 �@ 2.27GHz > >> (2763.12-MHz 686-class CPU) Origin = "GenuineIntel" �Id = > >> 0x106a5 �Family = 6 Model = 1a �Stepping = 5 > >> Features=0x1781fbbf >>,PG E,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT> > >> Features2=0x80982201> > >> TSC: P-state invariant > >> real memory �= 4194304000 (4000 MB) > >> avail memory = 3932786688 (3750 MB) > >> ACPI APIC Table: > >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > >> �cpu0 (BSP): APIC ID: �0 > >> �cpu1 (AP/HT): APIC ID: �2 > >> �cpu2 (AP/HT): APIC ID: �4 > >> > >> Just a thought. > >> �# HTT might somehow correlate with current maxcpus limit (32). > > > > One thing I am not sure is whether those CPUID instructions are > > executed on *real* CPUs or translated in HVM. > > I may add only that of Features2 presents only in Xen > HVM environment, and its role is afaik to indicate a Xen guest > mode. There is no any mention of this bit in the latest Intel doc > (ie it's reserved/unused). Ah, that means the HVM is actually translating the instruction, not running directly on the CPU. That means, we cannot use any CPUID instructions for topology detection in HVM. And I bet all MSRs will be translated as well. It is not just HVM, but also any emulations and virtualizations in general. Actually, CPU topology detection does nothing in these environments because hypervisor or whatever will do memory translations and stuff unless some "hints" are given by guest or "ballooning" is done for virtual devices and resources. Usually, this kind of problem is handled by VM-specific device drivers, e.g., VirtualBox Guest Additions, VMware Tools, etc. In theory, Xen domU should do much better job than these tools because it is specifically modified to handle these problems without losing performance. > Also, at least NetBSD has a special handling of this bit. > See commit log for CPUID2_RAZ in sys/arch/x86/include/specialreg.h, > 1.37 FWIW RAZ states for "reserved and zero" or so. Hmm... Interesting. But we should never rely on an undocumented bit to identify HVM or whatever. Thanks for the info, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resizing GPT partitions
There is a good software can solve your problem--Partition Manager. You needn't worry about anything wrong at all; it can help you easily http://www.extend-partition.com/help/how-to-resize-partition.html resize partition without data loss. And I want to tell you, this software is free for use. So, I think this is your best choice. -- View this message in context: http://old.nabble.com/Resizing-GPT-partitions-tp28820639p29488441.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRERELEASE: CPU packages not detected correctly
on 19/08/2010 22:15 pluknet said the following: > On 19 August 2010 21:27, Andriy Gapon wrote: >> on 19/08/2010 19:56 pluknet said the following: >>> CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class >>> CPU) >>> Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = >>> 5 >>> >>> Features=0x1781fbbf >>> Features2=0x80982201> >>> TSC: P-state invariant >>> real memory = 4194304000 (4000 MB) >>> avail memory = 3932786688 (3750 MB) >>> ACPI APIC Table: >>> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >>> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP/HT): APIC ID: 2 >>> cpu2 (AP/HT): APIC ID: 4 >> Thanks! >> BTW, what does Intel's code report? >> Jung-uk's convenience script: >> http://people.freebsd.org/~jkim/cpu_topology-12212009.sh >> > > Software visible enumeration in the system: > Number of logical processors visible to the OS: 3 > Number of logical processors visible to this process: 3 > Number of processor cores visible to this process: 3 > Number of physical packages visible to this process: 1 > > Hierarchical counts by levels of processor topology: > # of cores in package 0 visible to this process: 3 . So, original Intel code detects the topology correctly. Jung-uk, despite what you said in the parallel followup, I think that this demonstrates that there is a flaw in your patch as compared to the logic in the Intel-provided code. FWIW, I was surprised to see a loop in topo_probe_0x4 - I don't see such a loop in Intel's code. Also, (level == 1 && cpu_logical == logical * cores) verification might be a suspect too. It may be OK for real hardware, but emulated hardware may stick to minimal compatibility required. > Affinity masks per SMT thread, per core, per package: > Individual: > P:0, C:0, T:0 --> 1 > > Core-aggregated: > P:0, C:0 --> 1 > Individual: > P:0, C:1, T:0 --> 2 > > Core-aggregated: > P:0, C:1 --> 2 > Individual: > P:0, C:2, T:0 --> 4 > > Core-aggregated: > P:0, C:2 --> 4 > > Pkg-aggregated: > P:0 --> 7 > > > APIC ID listings from affinity masks > OS cpu 0, Affinity mask 01 - apic id 0 > OS cpu 1, Affinity mask 02 - apic id 2 > OS cpu 2, Affinity mask 04 - apic id 4 > > > Package 0 Cache and Thread details > L1D is Level 1 Data cache, size(KBytes)= 32, Cores/cache= 1, Caches/package= > 3 > L1I is Level 1 Instruction cache, size(KBytes)= 32, Cores/cache= 1, > Caches/package= 3 > L2 is Level 2 Unified cache, size(KBytes)= 256, Cores/cache= 1, > Caches/package= 3 > L3 is Level 3 Unified cache, size(KBytes)= 8192, Cores/cache= 1, > Caches/package= 3 > ++++ > Cache | L1D| L1D| L1D| > Size | 32K| 32K| 32K| > OScpu#| 0| 1| 2| > Core | c0| c1| c2| > AffMsk| 1| 2| 4| > ++++ > > Cache | L1I| L1I| L1I| > Size | 32K| 32K| 32K| > ++++ > > Cache | L2| L2| L2| > Size |256K|256K|256K| > ++++ > > Cache | L3| L3| L3| > Size | 8M| 8M| 8M| > ++++ > > Combined socket AffinityMask= 0x7 > -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
