Re: Copying a file on msdos FS (fat32) changes content
On Tue, 13 Jun 2017, Martijn Rijkeboer wrote: > Yes, this patch fixes the problem. Thanks for the report and the testing. I have committed the revert yesterday.
Re: Copying a file on msdos FS (fat32) changes content
On 06/12/17 21:41, Stefan Fritsch wrote:
> On Mon, 12 Jun 2017, Martijn Rijkeboer wrote:
>> After upgrading to the latest snapshot there seems to be something wrong
>> with the msdos filesystem driver. When I copy a binary file on a msdos
>> (fat32)
>> mounted partition the content changes e.g.:
>>
>> # cp refind_x64.efi bootx64.efi
>> # ls -l refind_x64.efi bootx64.efi
>> -rw-r--r-- 1 root wheel 230856 Jun 12 10:47 bootx64.efi
>> -rw-r--r-- 1 root wheel 230856 Mar 9 11:09 refind_x64.efi
>> # sha256 refind_x64.efi bootx64.efi
>> SHA256 (refind_x64.efi) =
>> 9c9a38f168fed270c158ff5a68d3fa5172eb15bcb41662abf69faa13d2abc418
>> SHA256 (bootx64.efi) =
>> 26f7350143cc897d53b0257dbf5d9f1d84eace4746cbd9f2ff95a033ee0c577f
>
> Sigh.
>
> Please try if the attached patch fixes the problem. It reverts a likely
> culprit.
Yes, this patch fixes the problem.
Kind regards,
Martijn Rijkeboer
>
> Cheers,
> Stefan
>
> diff --git sys/msdosfs/denode.h sys/msdosfs/denode.h
> index efa8192a06d..cdca90500ab 100644
> --- sys/msdosfs/denode.h
> +++ sys/msdosfs/denode.h
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: denode.h,v 1.31 2017/05/29 13:48:12 sf Exp $ */
> +/* $OpenBSD: denode.h,v 1.30 2016/08/30 19:47:23 sf Exp $ */
> /* $NetBSD: denode.h,v 1.24 1997/10/17 11:23:39 ws Exp $ */
>
> /*-
> @@ -142,6 +142,7 @@ struct denode {
> struct vnode *de_devvp; /* vnode of blk dev we live on */
> uint32_t de_flag; /* flag bits */
> dev_t de_dev; /* device where direntry lives */
> + daddr_t de_lastr;
> uint32_t de_dirclust; /* cluster of the directory file containing
> this entry */
> uint32_t de_diroffset; /* offset of this entry in the directory
> cluster */
> uint32_t de_fndoffset; /* offset of found dir entry */
> diff --git sys/msdosfs/msdosfs_vnops.c sys/msdosfs/msdosfs_vnops.c
> index 61b45af6185..39c60044df5 100644
> --- sys/msdosfs/msdosfs_vnops.c
> +++ sys/msdosfs/msdosfs_vnops.c
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: msdosfs_vnops.c,v 1.114 2017/05/29 13:48:12 sf Exp $ */
> +/* $OpenBSD: msdosfs_vnops.c,v 1.113 2016/08/30 19:47:23 sf Exp $ */
> /* $NetBSD: msdosfs_vnops.c,v 1.63 1997/10/17 11:24:19 ws Exp $*/
>
> /*-
> @@ -77,13 +77,13 @@
>
> static uint32_t fileidhash(uint64_t);
>
> -int msdosfs_bmaparray(struct vnode *, daddr_t, daddr_t *, int *);
> int msdosfs_kqfilter(void *);
> int filt_msdosfsread(struct knote *, long);
> int filt_msdosfswrite(struct knote *, long);
> int filt_msdosfsvnode(struct knote *, long);
> void filt_msdosfsdetach(struct knote *);
>
> +
> /*
> * Some general notes:
> *
> @@ -509,14 +509,18 @@ int
> msdosfs_read(void *v)
> {
> struct vop_read_args *ap = v;
> + int error = 0;
> + uint32_t diff;
> + int blsize;
> + int isadir;
> + uint32_t n;
> + long on;
> + daddr_t lbn, rablock, rablkno;
> + struct buf *bp;
> struct vnode *vp = ap->a_vp;
> struct denode *dep = VTODE(vp);
> struct msdosfsmount *pmp = dep->de_pmp;
> struct uio *uio = ap->a_uio;
> - int isadir, error = 0;
> - uint32_t n, diff, size, on;
> - struct buf *bp;
> - daddr_t cn, bn;
>
> /*
>* If they didn't ask for any data, then we are done.
> @@ -531,8 +535,7 @@ msdosfs_read(void *v)
> if (uio->uio_offset >= dep->de_FileSize)
> return (0);
>
> - cn = de_cluster(pmp, uio->uio_offset);
> - size = pmp->pm_bpcluster;
> + lbn = de_cluster(pmp, uio->uio_offset);
> on = uio->uio_offset & pmp->pm_crbomask;
> n = ulmin(pmp->pm_bpcluster - on, uio->uio_resid);
>
> @@ -545,22 +548,31 @@ msdosfs_read(void *v)
> if (diff < n)
> n = diff;
>
> + /* convert cluster # to block # if a directory */
> + if (isadir) {
> + error = pcbmap(dep, lbn, &lbn, 0, &blsize);
> + if (error)
> + return (error);
> + }
> /*
>* If we are operating on a directory file then be sure to
>* do i/o with the vnode for the filesystem instead of the
>* vnode for the directory.
>*/
> if (isadir) {
> - error = pcbmap(dep, cn, &cn, 0, &size);
> - if (error)
> - return (error);
> - error = bread(pmp->pm_devvp, cn, size, &bp);
> + error = bread(pmp->pm_devvp, lbn, blsize, &bp);
> } else {
> - bn = de_cn2bn(pmp, cn);
> - if (de_cn2off(pmp, cn + 1) >= dep->de_FileSize)
> - error = bread(vp, bn, size, &bp);
> + rablock = lbn + 1;
> + rablkno = de_cn2bn(pmp, rablock);
> + if (dep->de_last
Re: Copying a file on msdos FS (fat32) changes content
> Please try if the attached patch fixes the problem. It reverts a likely > culprit. I sent my last email before I saw your patch. The patch resolves the issue for me. Thanks.
Re: Copying a file on msdos FS (fat32) changes content
> After upgrading to the latest snapshot there seems to be something wrong > with the msdos filesystem driver. When I copy a binary file on a msdos > (fat32) mounted partition the content changes e.g.: I seem to get similar results. It is consistent at char 4097 with every test. # mount /dev/sd2i /mnt # cd /mnt # dd if=/dev/random count=128 | tee foo | sha256 128+0 records in 128+0 records out 65536 bytes transferred in 0.013 secs (4751396 bytes/sec) 32eeb6ea5ae66c9773e44b711cedb6406f6b7bfc4820a7ba67bc15cdb57bb3a9 # cp foo bar # sha256 foo bar SHA256 (foo) = 32eeb6ea5ae66c9773e44b711cedb6406f6b7bfc4820a7ba67bc15cdb57bb3a9 SHA256 (bar) = fbc95c92049953e6708e75dd5f0c9914737765baf4dc718aa37cc78bedcdbb3a # cmp foo bar foo bar differ: char 4097, line 19 # cd # umount /mnt # mount /dev/sd2i /mnt # cd /mnt # sha256 foo bar SHA256 (foo) = fbc95c92049953e6708e75dd5f0c9914737765baf4dc718aa37cc78bedcdbb3a SHA256 (bar) = fbc95c92049953e6708e75dd5f0c9914737765baf4dc718aa37cc78bedcdbb3a # fdisk sd2 Disk: sd2 geometry: 976/255/63 [15679488 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 0B 0 1 2 -976 0 48 [ 64:15679424 ] FAT32 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused # fsck /dev/sd2i ** /dev/rsd2i ** Phase 1 - Read and Compare FATs ** Phase 2 - Check Cluster Chains ** Phase 3 - Check Directories ** Phase 4 - Check for Lost Files 3 files, 3629976 free (1956070 clusters) OpenBSD 6.1-current (GENERIC.MP) #3: Mon Jun 12 09:43:26 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3672182784 (3502MB) avail mem = 3555098624 (3390MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec100 (47 entries) bios0: vendor American Megatrends Inc. version "1501" date 04/01/2016 bios0: ASUS All Series acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET MSDM BGRT SSDT SSDT CRAT SSDT acpi0: wakeup devices RLAN(S4) UASM(S4) SBAZ(S4) PS2K(S4) UAR1(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) XHC0(S4) PX16(S4) GPP0(S4) GPP1(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) 5150 APU with Radeon(tm) R3, 1597.22 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: TSC frequency 1597224470 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) 5150 APU with Radeon(tm) R3, 1597.01 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Athlon(tm) 5150 APU with Radeon(tm) R3, 1597.01 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Athlon(tm) 5150 APU with Radeon(tm) R3, 1597.02 MHz cpu3: FPU,VME,DE,PSE,TS
Re: Copying a file on msdos FS (fat32) changes content
On Mon, 12 Jun 2017, Martijn Rijkeboer wrote:
> After upgrading to the latest snapshot there seems to be something wrong
> with the msdos filesystem driver. When I copy a binary file on a msdos (fat32)
> mounted partition the content changes e.g.:
>
> # cp refind_x64.efi bootx64.efi
> # ls -l refind_x64.efi bootx64.efi
> -rw-r--r-- 1 root wheel 230856 Jun 12 10:47 bootx64.efi
> -rw-r--r-- 1 root wheel 230856 Mar 9 11:09 refind_x64.efi
> # sha256 refind_x64.efi bootx64.efi
> SHA256 (refind_x64.efi) =
> 9c9a38f168fed270c158ff5a68d3fa5172eb15bcb41662abf69faa13d2abc418
> SHA256 (bootx64.efi) =
> 26f7350143cc897d53b0257dbf5d9f1d84eace4746cbd9f2ff95a033ee0c577f
Sigh.
Please try if the attached patch fixes the problem. It reverts a likely
culprit.
Cheers,
Stefan
diff --git sys/msdosfs/denode.h sys/msdosfs/denode.h
index efa8192a06d..cdca90500ab 100644
--- sys/msdosfs/denode.h
+++ sys/msdosfs/denode.h
@@ -1,4 +1,4 @@
-/* $OpenBSD: denode.h,v 1.31 2017/05/29 13:48:12 sf Exp $ */
+/* $OpenBSD: denode.h,v 1.30 2016/08/30 19:47:23 sf Exp $ */
/* $NetBSD: denode.h,v 1.24 1997/10/17 11:23:39 ws Exp $ */
/*-
@@ -142,6 +142,7 @@ struct denode {
struct vnode *de_devvp; /* vnode of blk dev we live on */
uint32_t de_flag; /* flag bits */
dev_t de_dev; /* device where direntry lives */
+ daddr_t de_lastr;
uint32_t de_dirclust; /* cluster of the directory file containing
this entry */
uint32_t de_diroffset; /* offset of this entry in the directory
cluster */
uint32_t de_fndoffset; /* offset of found dir entry */
diff --git sys/msdosfs/msdosfs_vnops.c sys/msdosfs/msdosfs_vnops.c
index 61b45af6185..39c60044df5 100644
--- sys/msdosfs/msdosfs_vnops.c
+++ sys/msdosfs/msdosfs_vnops.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: msdosfs_vnops.c,v 1.114 2017/05/29 13:48:12 sf Exp $ */
+/* $OpenBSD: msdosfs_vnops.c,v 1.113 2016/08/30 19:47:23 sf Exp $ */
/* $NetBSD: msdosfs_vnops.c,v 1.63 1997/10/17 11:24:19 ws Exp $*/
/*-
@@ -77,13 +77,13 @@
static uint32_t fileidhash(uint64_t);
-int msdosfs_bmaparray(struct vnode *, daddr_t, daddr_t *, int *);
int msdosfs_kqfilter(void *);
int filt_msdosfsread(struct knote *, long);
int filt_msdosfswrite(struct knote *, long);
int filt_msdosfsvnode(struct knote *, long);
void filt_msdosfsdetach(struct knote *);
+
/*
* Some general notes:
*
@@ -509,14 +509,18 @@ int
msdosfs_read(void *v)
{
struct vop_read_args *ap = v;
+ int error = 0;
+ uint32_t diff;
+ int blsize;
+ int isadir;
+ uint32_t n;
+ long on;
+ daddr_t lbn, rablock, rablkno;
+ struct buf *bp;
struct vnode *vp = ap->a_vp;
struct denode *dep = VTODE(vp);
struct msdosfsmount *pmp = dep->de_pmp;
struct uio *uio = ap->a_uio;
- int isadir, error = 0;
- uint32_t n, diff, size, on;
- struct buf *bp;
- daddr_t cn, bn;
/*
* If they didn't ask for any data, then we are done.
@@ -531,8 +535,7 @@ msdosfs_read(void *v)
if (uio->uio_offset >= dep->de_FileSize)
return (0);
- cn = de_cluster(pmp, uio->uio_offset);
- size = pmp->pm_bpcluster;
+ lbn = de_cluster(pmp, uio->uio_offset);
on = uio->uio_offset & pmp->pm_crbomask;
n = ulmin(pmp->pm_bpcluster - on, uio->uio_resid);
@@ -545,22 +548,31 @@ msdosfs_read(void *v)
if (diff < n)
n = diff;
+ /* convert cluster # to block # if a directory */
+ if (isadir) {
+ error = pcbmap(dep, lbn, &lbn, 0, &blsize);
+ if (error)
+ return (error);
+ }
/*
* If we are operating on a directory file then be sure to
* do i/o with the vnode for the filesystem instead of the
* vnode for the directory.
*/
if (isadir) {
- error = pcbmap(dep, cn, &cn, 0, &size);
- if (error)
- return (error);
- error = bread(pmp->pm_devvp, cn, size, &bp);
+ error = bread(pmp->pm_devvp, lbn, blsize, &bp);
} else {
- bn = de_cn2bn(pmp, cn);
- if (de_cn2off(pmp, cn + 1) >= dep->de_FileSize)
- error = bread(vp, bn, size, &bp);
+ rablock = lbn + 1;
+ rablkno = de_cn2bn(pmp, rablock);
+ if (dep->de_lastr + 1 == lbn &&
+ de_cn2off(pmp, rablock) < dep->de_FileSize)
+ error = breadn(vp, de_cn2bn(pmp, lbn),
+ pmp->pm_bpcluster, &rablkno,
+
Copying a file on msdos FS (fat32) changes content
Hi, After upgrading to the latest snapshot there seems to be something wrong with the msdos filesystem driver. When I copy a binary file on a msdos (fat32) mounted partition the content changes e.g.: # cp refind_x64.efi bootx64.efi # ls -l refind_x64.efi bootx64.efi -rw-r--r-- 1 root wheel 230856 Jun 12 10:47 bootx64.efi -rw-r--r-- 1 root wheel 230856 Mar 9 11:09 refind_x64.efi # sha256 refind_x64.efi bootx64.efi SHA256 (refind_x64.efi) = 9c9a38f168fed270c158ff5a68d3fa5172eb15bcb41662abf69faa13d2abc418 SHA256 (bootx64.efi) = 26f7350143cc897d53b0257dbf5d9f1d84eace4746cbd9f2ff95a033ee0c577f Since this is my EFI boot partition my system won't boot afterwards. It gives a "X64 Exception Type - 0006" error. Kind regards, Martijn Rijkeboer # sysctl kern.version kern.version=OpenBSD 6.1-current (GENERIC.MP) #2: Sun Jun 11 22:26:32 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP # mount | grep /mnt /dev/sd0i on /mnt type msdos (local) # dmesg OpenBSD 6.1-current (GENERIC.MP) #2: Sun Jun 11 22:26:32 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8548429824 (8152MB) avail mem = 8283561984 (7899MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xcfb6c020 (59 entries) bios0: vendor Award Software International, Inc. version "F7" date 10/22/2012 bios0: Gigabyte Technology Co., Ltd. GA-970A-UD3 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP MSDM HPET MCFG EUDS MATS TAMG APIC MATS SSDT acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) SBAZ(S4) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) P2P_(S5) PCE2(S4) PCE3(S4) PCE4(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD FX(tm)-4100 Quad-Core Processor, 3624.71 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative cpu0: TSC frequency 3624706430 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 201MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD FX(tm)-4100 Quad-Core Processor, 3624.31 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD FX(tm)-4100 Quad-Core Processor, 3624.31 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative cpu2: smt 0, core 3, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD FX(tm)-4100 Quad-Core Processor, 3624.31 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu3: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative cpu3: smt 0, c
