Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
Hi, I installed FreeBSD 5.2 and updated using cvsup on Dell Poweredge 1600SC. However still FreeBSD doesn't recognize network card. It has onboard Intel Pro/1000 MT card. What should I do in order to use this onboard Intel PRO/1000 card? I checked Intel web site and found only em driver for FreeBSD 4.7. Where can I find latest driver for Intel PRO/1000 MT network card? tia, Ganbold ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
On Mon, 16 Feb 2004, Ganbold wrote: Hi, I installed FreeBSD 5.2 and updated using cvsup on Dell Poweredge 1600SC. However still FreeBSD doesn't recognize network card. It has onboard Intel Pro/1000 MT card. What should I do in order to use this onboard Intel PRO/1000 card? I checked Intel web site and found only em driver for FreeBSD 4.7. Where can I find latest driver for Intel PRO/1000 MT network card? tia, Ganbold The driver in 5.2 should support that card. Can you post the results of a pciconf -lv so we can see the PCI ID of your specific card? Thanks, Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
Hi, Following is the output of pciconf -lv command: [EMAIL PROTECTED]:0:0:class=0x06 card=0x chip=0x00171166 rev=0x32 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:1:class=0x06 card=0x chip=0x00171166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x02 card=0x9207103c chip=0x1213 rev=0x10 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-1207D Fast Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:14:0:class=0x03 card=0x01351028 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage XL PCI' class= display subclass = VGA [EMAIL PROTECTED]:15:0: class=0x06 card=0x02011166 chip=0x02011166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI to ISA Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI EIDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:15:2:class=0x0c0310 card=0x02201166 chip=0x02201166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 OpenHCI Compliant USB Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:15:3:class=0x060100 card=0x02301166 chip=0x02251166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:16:0: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:16:2: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x01 card=0x01351028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI Ganbold At 06:22 PM 16.02.2004, you wrote: On Mon, 16 Feb 2004, Ganbold wrote: Hi, I installed FreeBSD 5.2 and updated using cvsup on Dell Poweredge 1600SC. However still FreeBSD doesn't recognize network card. It has onboard Intel Pro/1000 MT card. What should I do in order to use this onboard Intel PRO/1000 card? I checked Intel web site and found only em driver for FreeBSD 4.7. Where can I find latest driver for Intel PRO/1000 MT network card? tia, Ganbold The driver in 5.2 should support that card. Can you post the results of a pciconf -lv so we can see the PCI ID of your specific card? Thanks, Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
Not wishing to point out the obvious but there's no EM controller there? Steve - Original Message - From: Ganbold [EMAIL PROTECTED] To: Mike Silbersack [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 16, 2004 10:45 AM Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current Hi, Following is the output of pciconf -lv command: [EMAIL PROTECTED]:0:0:class=0x06 card=0x chip=0x00171166 rev=0x32 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:1:class=0x06 card=0x chip=0x00171166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x02 card=0x9207103c chip=0x1213 rev=0x10 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-1207D Fast Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:14:0:class=0x03 card=0x01351028 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage XL PCI' class= display subclass = VGA [EMAIL PROTECTED]:15:0: class=0x06 card=0x02011166 chip=0x02011166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI to ISA Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI EIDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:15:2:class=0x0c0310 card=0x02201166 chip=0x02201166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 OpenHCI Compliant USB Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:15:3:class=0x060100 card=0x02301166 chip=0x02251166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:16:0: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:16:2: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x01 card=0x01351028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current
What happends when you load the module if_em.ko kldload if_em.ko Cheers, -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene mrtg.grunn.org Dutch mirror of MRTG -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Steven Hartland Verzonden: maandag 16 februari 2004 11:54 Aan: Mike Silbersack; Ganbold CC: [EMAIL PROTECTED] Onderwerp: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current Not wishing to point out the obvious but there's no EM controller there? Steve - Original Message - From: Ganbold [EMAIL PROTECTED] To: Mike Silbersack [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 16, 2004 10:45 AM Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current Hi, Following is the output of pciconf -lv command: [EMAIL PROTECTED]:0:0:class=0x06 card=0x chip=0x00171166 rev=0x32 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:1:class=0x06 card=0x chip=0x00171166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x02 card=0x9207103c chip=0x1213 rev=0x10 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-1207D Fast Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:14:0:class=0x03 card=0x01351028 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage XL PCI' class= display subclass = VGA [EMAIL PROTECTED]:15:0: class=0x06 card=0x02011166 chip=0x02011166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI to ISA Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI EIDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:15:2:class=0x0c0310 card=0x02201166 chip=0x02201166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 OpenHCI Compliant USB Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:15:3:class=0x060100 card=0x02301166 chip=0x02251166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:16:0: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:16:2: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x01 card=0x01351028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ Freebsd-hackers mailing list [EMAIL PROTECTED] http://lists.elvandar.org/mailman/listinfo/freebsd-hackers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
Hi, Maybe server doesn't have EM card at the end. Only reason why I'm thinking is there are 2 identical Dell Poweredge 1600SC servers and the other one has Redhat Linux 9.0 installed and Intel PRO/1000MT card is recognized properly. Ganbold At 06:53 PM 16.02.2004, you wrote: Not wishing to point out the obvious but there's no EM controller there? Steve - Original Message - From: Ganbold [EMAIL PROTECTED] To: Mike Silbersack [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 16, 2004 10:45 AM Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current Hi, Following is the output of pciconf -lv command: [EMAIL PROTECTED]:0:0:class=0x06 card=0x chip=0x00171166 rev=0x32 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:1:class=0x06 card=0x chip=0x00171166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x02 card=0x9207103c chip=0x1213 rev=0x10 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-1207D Fast Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:14:0:class=0x03 card=0x01351028 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage XL PCI' class= display subclass = VGA [EMAIL PROTECTED]:15:0: class=0x06 card=0x02011166 chip=0x02011166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI to ISA Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI EIDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:15:2:class=0x0c0310 card=0x02201166 chip=0x02201166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 OpenHCI Compliant USB Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:15:3:class=0x060100 card=0x02301166 chip=0x02251166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:16:0: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:16:2: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x01 card=0x01351028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current
When I try to load if_em.ko module /var/log/messages says: Feb 16 19:08:41 mnao1 kernel: module_register: module pci/em already exists! Feb 16 19:08:41 mnao1 kernel: Module pci/em failed to register: 17 Ganbold At 07:07 PM 16.02.2004, you wrote: What happends when you load the module if_em.ko kldload if_em.ko Cheers, -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene mrtg.grunn.org Dutch mirror of MRTG -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Steven Hartland Verzonden: maandag 16 februari 2004 11:54 Aan: Mike Silbersack; Ganbold CC: [EMAIL PROTECTED] Onderwerp: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current Not wishing to point out the obvious but there's no EM controller there? Steve - Original Message - From: Ganbold [EMAIL PROTECTED] To: Mike Silbersack [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 16, 2004 10:45 AM Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current Hi, Following is the output of pciconf -lv command: [EMAIL PROTECTED]:0:0:class=0x06 card=0x chip=0x00171166 rev=0x32 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:1:class=0x06 card=0x chip=0x00171166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x02 card=0x9207103c chip=0x1213 rev=0x10 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-1207D Fast Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:14:0:class=0x03 card=0x01351028 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage XL PCI' class= display subclass = VGA [EMAIL PROTECTED]:15:0: class=0x06 card=0x02011166 chip=0x02011166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI to ISA Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI EIDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:15:2:class=0x0c0310 card=0x02201166 chip=0x02201166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 OpenHCI Compliant USB Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:15:3:class=0x060100 card=0x02301166 chip=0x02251166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:16:0: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:16:2: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x01 card=0x01351028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ Freebsd-hackers mailing list [EMAIL PROTECTED] http://lists.elvandar.org/mailman/listinfo/freebsd-hackers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current
Alright, the module is already compiled into the kernel, or the driver is already loaded. Strange, because i yesterday build in the same nic on my machine. snip uname -a FreeBSD luca.elvandar.org 5.2.1-RC2 FreeBSD 5.2.1-RC2 #2: Sun Feb 15 19:44:28 CET 2004 [EMAIL PROTECTED]:/usr/freebsd52/src/sys/i386/compile/ELVANDAR i386 /snip snip em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.19 port 0xa000-0xa03f mem 0xde00-0xde01,0xde80-0xde81 irq 12 at device 10.0 on pci0 em0: Speed:N/A Duplex:N/A /snip Could it be a bios setting (note that i am guessing now) ?, onboard nic enabled.. Cheers -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene mrtg.grunn.org Dutch mirror of MRTG -Oorspronkelijk bericht- Van: Ganbold [mailto:[EMAIL PROTECTED] Verzonden: maandag 16 februari 2004 12:16 Aan: Remko Lodder CC: [EMAIL PROTECTED] Onderwerp: RE: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current When I try to load if_em.ko module /var/log/messages says: Feb 16 19:08:41 mnao1 kernel: module_register: module pci/em already exists! Feb 16 19:08:41 mnao1 kernel: Module pci/em failed to register: 17 Ganbold At 07:07 PM 16.02.2004, you wrote: What happends when you load the module if_em.ko kldload if_em.ko Cheers, -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene mrtg.grunn.org Dutch mirror of MRTG -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Steven Hartland Verzonden: maandag 16 februari 2004 11:54 Aan: Mike Silbersack; Ganbold CC: [EMAIL PROTECTED] Onderwerp: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current Not wishing to point out the obvious but there's no EM controller there? Steve - Original Message - From: Ganbold [EMAIL PROTECTED] To: Mike Silbersack [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 16, 2004 10:45 AM Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current Hi, Following is the output of pciconf -lv command: [EMAIL PROTECTED]:0:0:class=0x06 card=0x chip=0x00171166 rev=0x32 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:1:class=0x06 card=0x chip=0x00171166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x02 card=0x9207103c chip=0x1213 rev=0x10 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-1207D Fast Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:14:0:class=0x03 card=0x01351028 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage XL PCI' class= display subclass = VGA [EMAIL PROTECTED]:15:0: class=0x06 card=0x02011166 chip=0x02011166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI to ISA Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI EIDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:15:2:class=0x0c0310 card=0x02201166 chip=0x02201166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 OpenHCI Compliant USB Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:15:3:class=0x060100 card=0x02301166 chip=0x02251166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:16:0: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:16:2: class=0x06 card=0x chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:4:0: class=0x01 card=0x01351028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
Hi, Ganbold wrote on Mon, Feb 16, 2004 at 06:45:39PM +0800: [..] [EMAIL PROTECTED]:4:0: class=0x02 card=0x9207103c chip=0x1213 rev=0x10 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-1207D Fast Ethernet Adapter' class= network subclass = ethernet [..] This is the only probed Ethernet device and it seems rl driver has already attached to it. I know that DELL servers can be equipped with an em NIC optionally, maybe this is the case for your second machine. You should check the connectors on the back, if there is an additional TP or SX port (I think the Pro/1000 is SX only). If your RedHat machine has the SX port, but your other one doesn't, that would solve the mystery, wouldn't it? HTH, Daniel -- IRCnet: Mr-Spock - Truth lies in the eye of the beholder - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/ smime.p7s Description: S/MIME cryptographic signature
Re: Adding 'realclean' target to /usr/src/Makefile
On Sun, Feb 15, 2004 at 05:57:14AM -0600, Matthew D. Fuller wrote: On Sun, Feb 15, 2004 at 09:20:56AM + I heard the voice of Bruce M Simpson, and lo! it spake thus: It would be helpful if it were pointed out in documentation somewhere that the path to the compile and source directories, when doing NFS kernel installs, has to be identical to those which were in effect on the build box due to the treatment of MAKEOBJDIRPREFIX during the modules build (and subsequent modules/* path creation). And, last time I tried it (which admittedly was a long time ago, so grab your salt grainer), the same applied to world builds too. To stop this from being happening, Jun Kuriyama has done a cleanup lately to replace lots of symlink created during buildworld with cp(1) commands. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
Yes I installed Realtek card because FreeBSD doesn't recognize onboard card. It has onboard TP connector same as Redhat machine has. Ganbold At 07:37 PM 16.02.2004, you wrote: Hi, Ganbold wrote on Mon, Feb 16, 2004 at 06:45:39PM +0800: [..] [EMAIL PROTECTED]:4:0: class=0x02 card=0x9207103c chip=0x1213 rev=0x10 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-1207D Fast Ethernet Adapter' class= network subclass = ethernet [..] This is the only probed Ethernet device and it seems rl driver has already attached to it. I know that DELL servers can be equipped with an em NIC optionally, maybe this is the case for your second machine. You should check the connectors on the back, if there is an additional TP or SX port (I think the Pro/1000 is SX only). If your RedHat machine has the SX port, but your other one doesn't, that would solve the mystery, wouldn't it? HTH, Daniel -- IRCnet: Mr-Spock - Truth lies in the eye of the beholder - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
If that's the case doesn't look like its being detected. Is it disabled in the bios? Steve - Original Message - From: Ganbold [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 16, 2004 12:05 PM Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current Yes I installed Realtek card because FreeBSD doesn't recognize onboard card. It has onboard TP connector same as Redhat machine has. Ganbold This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing v_op for vnode on the fly
On Fri, Feb 13, 2004 at 09:49:53PM -0500, Brian F. Feldman wrote: Andrey Simonenko [EMAIL PROTECTED] wrote: Is it enough to get exclusive lock on vnode, before changing v_op pointer? Here is my code: vn_lock(cvp-vp, LK_EXCLUSIVE | LK_RETRY, p); if (flag 0) cvp-vp-v_op = catch_vnode_vnodeop_p; /* My vnodeop_p. */ else cvp-vp-v_op = cvp-vnodeop_p; /* Original v_op. */ VOP_UNLOCK(cvp-vp, 0, p); I made some tests and see that most of VOP_xxx require lock (shared or exclusive) on vnode, as well this is documented in the manual pages. No, you are not allowed to change v_op, ever. Can you do what you're trying to do in the MAC framework? It seems like that is what you want to be doing! The other possibility is using something like umapfs/lomacfs/ unionfs. First of all thanks for your answer. I need to control activities on vnode not for protecting it from processes. I try to find a way to synchronize shared access (read, write, mmap'ed file) to existent vnode (vnode which is currently is used on home host by local processes) from process on remote hosts. This situation is like NFS, but NFS (or similar systems) has own vnode operation vector for their vnodes and can synchronize access in their VOPs. Since in my situation vnodes can have different vnode operation vectors (i.e. files can belong to different VFS) I can't set v_op for vnode when vnode is created (getnewvnode()). Having read documentation and analyzed sources, I think that MAC can't help. MAC allows to synchronize access in read() and write() syscalls, but access to VOP_GETPAGES, which is called in vm_fault() for example, can't be synchronized using MAC framework. File systems umapfs, lomacfs, unionfs also don't help. May be it is possible to do something with stackable VFS, but I haven't find a solution with stackable VFS yet. What can be broken when v_op is changed during holding exclusive lock on vnode? Does a moment when v_op is changed can cause any problems? Currently I found that nullfs and uniofs will not work if v_op is changed, because they compare v_op with their vnodeop_p. Thanks for your help again. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
We did some more experiments and when we compiled the object file on 5.2 then linked it on the 4.9 machine and then ran it on the 5.2 machine, there was no cyclical problem seen (Frankenstein run). Kind of points to the 5.2 link stage, i.e., 5.2 libraries? Check out the graphical exhibits at http://www.employees.org/~rsargent/flops/ The graph at the very bottom shows the Frankenstein run. The graphs depict the /usr/bin/time results of running 300 iterations of flops 1.2 while incrementing the env one byte between iterations. I use flops 1.2, it runs less modules than 2.0 but still exhibits the cyclical slowness [alignment] problem as module #2 in flops 2.0. Source code for flops 1.2 is at the bottom of the above link. Juan From: Alexandr Kovalenko [EMAIL PROTECTED] To: Wes Peters [EMAIL PROTECTED] CC: Juan Tumani [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) Date: Sat, 14 Feb 2004 10:24:21 +0200 Hello, Wes Peters! On Tue, Feb 10, 2004 at 11:29:34AM -0800, you wrote: On Monday 09 February 2004 13:20, Juan Tumani wrote: I have an Intel D845GE m/b w/ a P4 1.7 CPU and I have the box setup to dual boot to either 4.9 or 5.2. Both OS are right off the latest posted iso CD image, i.e., no updates, no kernel tweaks, everything vanilla right out of the box. I compiled flops.c on both 4.9 and 5.2 and the 5.2 performance is less than half that of 4.9: 760 MFLOPS on 4.9 v/s 340 MFLOPS on 5.2. I tried turning off the SMP and other kernel tweaks and no improvement in 5.2. I then downloaded and installed gcc295 on the 5.2 machine and that fixed the problem. So now all I have to do is figure out the gcc 3.3.3 switches to make it run like gcc 2.9.5 or figure out how to rebuild 5.2 w/ gcc 2.9.5 :-). I'm not sure that kernel tweaks are going to make much difference on a single-threaded floating point benchmark. Compiler optimizations sure do, though. (Note: I couldn't find version 1.2 of flops.c, so this is based on version 2.0.) On a 2.0GHz P4, I see: [EMAIL PROTECTED] cc -o flops -O -DUNIX flops.c Could you please explain me this? Result is fully reproduceable. Please note, that the only difference is the output file name. Even resulting files match bit-to-bit. If I do mv very-slow-flops flops2 and then run ./flops2, it runs as flops2 - fast. Machine is Dual 2.8 GHz Xeon with HTT disabled (in BIOS). FreeBSD is 5.2.1-RC2. %fetch http://home.iae.nl/users/mhx/flops.c Receiving flops.c (34942 bytes): 100% 34942 bytes transferred in 0.6 seconds (54.72 kBps) %cc -o flops2 -O2 -mcpu=pentium4 -DUNIX flops.c flops.c: In function `main': flops.c:174: warning: return type of `main' is not `int' %cc -o flops-sse-4 -O2 -mcpu=pentium4 -DUNIX flops.c flops.c: In function `main': flops.c:174: warning: return type of `main' is not `int' %cc -o very-slow-flops -O2 -mcpu=pentium4 -DUNIX flops.c flops.c: In function `main': flops.c:174: warning: return type of `main' is not `int' %./flops2 FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module ErrorRunTime MFLOPS (usec) 1 4.0146e-13 0.0130 1074.8815 2 -1.4166e-13 0.0128545.3338 3 4.7184e-14 0.0177960.4579 4 -1.2557e-13 0.0166903.6914 5 -1.3800e-13 0.0317915.0687 6 3.2380e-13 0.0310936.3149 7 -8.4583e-11 0.0403297.7250 8 3.4867e-13 0.0310968.6112 Iterations = 51200 NullTime (usec) = 0.0006 MFLOPS(1) = 635.0698 MFLOPS(2) = 560.4516 MFLOPS(3) = 805.4502 MFLOPS(4) = 945.5219 %./flops-sse-4 FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module ErrorRunTime MFLOPS (usec) 1 4.0146e-13 0.0177791.6075 2 -1.4166e-13 0.0309226.7944 3 4.7184e-14 0.0202842.7146 4 -1.2557e-13 0.0166902.8921 5 -1.3800e-13 0.0317916.2631 6 3.2380e-13 0.0309937.0923 7 -8.4583e-11 0.0403297.9173 8 3.4867e-13 0.0309969.3446 Iterations = 51200 NullTime (usec) = 0.0006 MFLOPS(1) = 297.9983 MFLOPS(2) = 546.3944 MFLOPS(3) = 775.3701 MFLOPS(4) = 922.1566 %./very-slow-flops FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module ErrorRunTime MFLOPS (usec) 1 4.0146e-13 0.0317442.0039 2 -1.4166e-13 0.0331211.3728 3 4.7184e-14 0.0350485.1899 4 -1.2557e-13 0.0168892.8307 5 -1.3800e-13 0.0319909.7385 6 3.2380e-13 0.0311931.1527 7 -8.4583e-11 0.0405296.4570 8 3.4867e-13 0.0312
Branch prediction
For as long as I've been programming, I've always been under the
impression that CPUs will always predict a branch as being false
the first time they come across it.
Many, many years ago, I came across a DEC programming guide that
said the same thing. It suggested using 'do { } while()' over
'while() {}' for loops as this ensured that the loop block was
correctly pre-fetched (rather than whatever followed the loop)
the first time the branch was encountered.
To this day, I still write all my code in this fashion. I was
wondering, have either CPU architectures or compilers improved
over time such that this isn't an issue anymore? Are CPUs able
to intelligently predict a branch the first time they encounter
it? Do compilers re-order blocks to optimise pre-fetching and
minimise branch mis-prediction?
With CPUs like the P4 -- with it's 20-something stage pipeline
-- branch mis-prediction is expensive. I realise certain CPUs
optimise their branch prediction units by maintaining branch
prediction histories, which would help when a branch is encoun-
tered repeatedly, but does the old adage of always predict
false still hold true the first time a branch is encountered?
So, writing code such that the true branch is intended to be
executed far less than what comes after it; good practice or
pointless habit?
Regards,
Trent.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote: On Sunday 15 February 2004 12:46, Dag-Erling Sm?rgrav wrote: Alexandr Kovalenko [EMAIL PROTECTED] writes: Could you please explain me this? Result is fully reproduceable. Please note, that the only difference is the output file name. Even resulting files match bit-to-bit. [...] Definitely some kind of alignment problem, but it only shows up at some optimization levels and not others. I've tested the patch Dan mentioned before and the results were astonishing. Running the flops.c 1.2 program in a loop, lengthening the environment string by one byte each time, I get 8 successive runs of fast, then 8 successive runs of slow, where fast and slow vary between 650 and 990 mflops. With the patch, the performance is always 990, within a few percent. Should I commit this? What effect does it have on non-i386 architectures? Kris pgp0.pgp Description: PGP signature
Re: Branch prediction
At 16:42 15/02/2004, Trent Nelson wrote: does the old adage of always predict false still hold true the first time a branch is encountered? Most processors predict that forward branches are not taken, and backward branches are taken (since backward branches occur most often in loops). Of course, some processors now have hints (conditional-jump- which-is-usually-taken, conditional-jump-which-is-usually-not- taken, etc.) Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
On Mon, 16 Feb 2004, Daniel Lang wrote: Hi, Ganbold wrote on Mon, Feb 16, 2004 at 06:45:39PM +0800: [..] [EMAIL PROTECTED]:4:0: class=0x02 card=0x9207103c chip=0x1213 rev=0x10 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-1207D Fast Ethernet Adapter' class= network subclass = ethernet [..] This is the only probed Ethernet device and it seems rl driver has already attached to it. I know that DELL servers can be equipped with an em NIC optionally, maybe this is the case for your second machine. You should check the connectors on the back, if there is an additional TP or SX port (I think the Pro/1000 is SX only). If your RedHat machine has the SX port, but your other one doesn't, that would solve the mystery, wouldn't it? Hopefully no one has mentioned this already, but if the network connector is there on the back next to the USB ports, did you ensure that it was enabled in the BIOS? I have a PowerEdge 400SC with the exact same internal Gigabit chipset and, although it was enabled by default on this machine, YMMV. Just something to check if you haven't already --Sean ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5)
Hi Wes, How many mflops do you get if on your 5.2 machine you run a flops that was compiled -static on 4.9 ? My tests show the speed more than doubles. Thanks- JT From: Wes Peters [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Dag-Erling Smørgrav),Alexandr Kovalenko [EMAIL PROTECTED] CC: [EMAIL PROTECTED], Juan Tumani [EMAIL PROTECTED] Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5) Date: Mon, 16 Feb 2004 03:52:16 -0800 MIME-Version: 1.0 Received: from mx2.freebsd.org ([216.136.204.119]) by mc9-f9.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 15 Feb 2004 19:52:44 -0800 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18])by mx2.freebsd.org (Postfix) with ESMTPid B8559565B0; Sun, 15 Feb 2004 19:51:57 -0800 (PST)(envelope-from [EMAIL PROTECTED]) Received: from hub.freebsd.org (localhost [127.0.0.1])by hub.freebsd.org (Postfix) with ESMTPid 6CDEE16A50C; Sun, 15 Feb 2004 19:51:53 -0800 (PST) Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])by hub.freebsd.org (Postfix) with ESMTP id B429316A4CEfor [EMAIL PROTECTED];Sun, 15 Feb 2004 19:51:30 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26])by mx1.FreeBSD.org (Postfix) with ESMTP id AAF9243D1Dfor [EMAIL PROTECTED];Sun, 15 Feb 2004 19:51:30 -0800 (PST)(envelope-from [EMAIL PROTECTED]) Received: from 204.68.178.129 (66-91-236-204.san.rr.com [66.91.236.204])by smtp-relay.omnis.com (Postfix) with ESMTPid 463A78836A3; Sun, 15 Feb 2004 19:51:26 -0800 (PST) X-Message-Info: EoYTbT2lH2OyKE31GpCEKyiRPPOIBbCy Delivered-To: [EMAIL PROTECTED] User-Agent: KMail/1.5.4 References: [EMAIL PROTECTED][EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSDfreebsd-hackers.freebsd.org List-Unsubscribe: http://lists.freebsd.org/mailman/listinfo/freebsd-hackers,mailto:[EMAIL PROTECTED] List-Archive: http://lists.freebsd.org/pipermail/freebsd-hackers List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://lists.freebsd.org/mailman/listinfo/freebsd-hackers,mailto:[EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 16 Feb 2004 03:52:45.0036 (UTC) FILETIME=[55C1E2C0:01C3F440] On Sunday 15 February 2004 12:46, Dag-Erling Smørgrav wrote: Alexandr Kovalenko [EMAIL PROTECTED] writes: Could you please explain me this? Result is fully reproduceable. Please note, that the only difference is the output file name. Even resulting files match bit-to-bit. [...] Definitely some kind of alignment problem, but it only shows up at some optimization levels and not others. I've tested the patch Dan mentioned before and the results were astonishing. Running the flops.c 1.2 program in a loop, lengthening the environment string by one byte each time, I get 8 successive runs of fast, then 8 successive runs of slow, where fast and slow vary between 650 and 990 mflops. With the patch, the performance is always 990, within a few percent. Should I commit this? RCS file: /big/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.235 diff -u -w -r1.235 kern_exec.c --- kern_exec.c 28 Dec 2003 04:37:59 - 1.235 +++ kern_exec.c 11 Feb 2004 16:47:28 - @@ -1014,6 +1014,15 @@ */ vectp = (char **)(destp - (imgp-argc + imgp-envc + 2) * sizeof(char *)); + + /* +* Align stack to a multiple of 0x20. +* XXX vectp has the wrong type; we usually want a vm_offset_t; +* the suword() family takes a void *, but should take a vm_offset_t. +* XXX should align stack for signals too. +* XXX should do this more machine/compiler-independently. +*/ + vectp = (char **)(((vm_offset_t)vectp ~(vm_offset_t)0x1F) - 4); /* * vectp also becomes our initial stack base -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] _ Let the advanced features services of MSN Internet Software maximize your online time. http://click.atdmt.com/AVE/go/onm00200363ave/direct/01/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
Kris Kennaway [EMAIL PROTECTED] writes: On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote: Should I commit this? What effect does it have on non-i386 architectures? It can't possibly hurt. If the stack is already aligned on a better boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary since 64 and 128 are multiples of 32, and the patch is a no-op. If only a 16-byte alignment is required, a 32-byte alignment wastes a small amount of memory but does not hurt performance. I believe that less-than-16 (and possibly even less-than-32) alignment is pessimal on all platforms we support. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
maximum mfsroot size limit
Hi. I have a problem with very large mfsroot filesystems in FreeBSD-4.9. 100Mb mfsroot fs boots and works fine, but 128Mb fs with the same content cause immediate reboot after 'Booting kernel in xxx seconds' line. Kernel config is GENERIC minus some unneeded things. Box with 1Gb of RAM is booting from IDE flash device (DiskOnChip). I've tried to bump MD_NSECT, but it doesn't make any difference. Andrew. P.S. I'm sorry if I am asking in the wrong list. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
Some interesting finding there what if any are the impacts for performance in real life applications? Steve - Original Message - From: Dag-Erling Smørgrav [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote: Should I commit this? What effect does it have on non-i386 architectures? It can't possibly hurt. If the stack is already aligned on a better boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary since 64 and 128 are multiples of 32, and the patch is a no-op. If only a 16-byte alignment is required, a 32-byte alignment wastes a small amount of memory but does not hurt performance. I believe that less-than-16 (and possibly even less-than-32) alignment is pessimal on all platforms we support. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5)
Wes, I patched in the patch shown below and it didn't fix the problem, it only changed the frequency of the spikes to 32 on/off. Please see the second chart at this URL: http://www.employees.org/~rsargent/flops/charts2.html Did you run the script [long enuf] to see what frequency you experience with the kern pacthed on your system? JT From: Wes Peters [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Dag-Erling Smørgrav),Alexandr Kovalenko [EMAIL PROTECTED] CC: [EMAIL PROTECTED], Juan Tumani [EMAIL PROTECTED] Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5) Date: Mon, 16 Feb 2004 03:52:16 -0800 On Sunday 15 February 2004 12:46, Dag-Erling Smørgrav wrote: Alexandr Kovalenko [EMAIL PROTECTED] writes: Could you please explain me this? Result is fully reproduceable. Please note, that the only difference is the output file name. Even resulting files match bit-to-bit. [...] Definitely some kind of alignment problem, but it only shows up at some optimization levels and not others. I've tested the patch Dan mentioned before and the results were astonishing. Running the flops.c 1.2 program in a loop, lengthening the environment string by one byte each time, I get 8 successive runs of fast, then 8 successive runs of slow, where fast and slow vary between 650 and 990 mflops. With the patch, the performance is always 990, within a few percent. Should I commit this? RCS file: /big/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.235 diff -u -w -r1.235 kern_exec.c --- kern_exec.c 28 Dec 2003 04:37:59 - 1.235 +++ kern_exec.c 11 Feb 2004 16:47:28 - @@ -1014,6 +1014,15 @@ */ vectp = (char **)(destp - (imgp-argc + imgp-envc + 2) * sizeof(char *)); + + /* +* Align stack to a multiple of 0x20. +* XXX vectp has the wrong type; we usually want a vm_offset_t; +* the suword() family takes a void *, but should take a vm_offset_t. +* XXX should align stack for signals too. +* XXX should do this more machine/compiler-independently. +*/ + vectp = (char **)(((vm_offset_t)vectp ~(vm_offset_t)0x1F) - 4); /* * vectp also becomes our initial stack base -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] _ Click here for a FREE online computer virus scan from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5)
Juan Tumani [EMAIL PROTECTED] writes: I patched in the patch shown below and it didn't fix the problem, it only changed the frequency of the spikes to 32 on/off. try replacing 0x1F with 0x3F in the patch and see what happens. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing v_op for vnode on the fly
Andrey Simonenko [EMAIL PROTECTED] wrote: On Fri, Feb 13, 2004 at 09:49:53PM -0500, Brian F. Feldman wrote: Andrey Simonenko [EMAIL PROTECTED] wrote: Is it enough to get exclusive lock on vnode, before changing v_op pointer? Here is my code: vn_lock(cvp-vp, LK_EXCLUSIVE | LK_RETRY, p); if (flag 0) cvp-vp-v_op = catch_vnode_vnodeop_p; /* My vnodeop_p. */ else cvp-vp-v_op = cvp-vnodeop_p; /* Original v_op. */ VOP_UNLOCK(cvp-vp, 0, p); I made some tests and see that most of VOP_xxx require lock (shared or exclusive) on vnode, as well this is documented in the manual pages. No, you are not allowed to change v_op, ever. Can you do what you're trying to do in the MAC framework? It seems like that is what you want to be doing! The other possibility is using something like umapfs/lomacfs/ unionfs. First of all thanks for your answer. I need to control activities on vnode not for protecting it from processes. I try to find a way to synchronize shared access (read, write, mmap'ed file) to existent vnode (vnode which is currently is used on home host by local processes) from process on remote hosts. This situation is like NFS, but NFS (or similar systems) has own vnode operation vector for their vnodes and can synchronize access in their VOPs. Since in my situation vnodes can have different vnode operation vectors (i.e. files can belong to different VFS) I can't set v_op for vnode when vnode is created (getnewvnode()). Having read documentation and analyzed sources, I think that MAC can't help. MAC allows to synchronize access in read() and write() syscalls, but access to VOP_GETPAGES, which is called in vm_fault() for example, can't be synchronized using MAC framework. Well, there is the ability to prevent the mmap(2) in the first place using mac_check_vnode_mmap(). Is that close to sufficient for those purposes? File systems umapfs, lomacfs, unionfs also don't help. May be it is possible to do something with stackable VFS, but I haven't find a solution with stackable VFS yet. Try to look closer at them; I think it's possible to do a lot of what you want because the initial LOMAC implementation for FreeBSD, before the MAC framework existed, did just such a thing. What can be broken when v_op is changed during holding exclusive lock on vnode? Does a moment when v_op is changed can cause any problems? Currently I found that nullfs and uniofs will not work if v_op is changed, because they compare v_op with their vnodeop_p. The thing that you're missing if you just modify v_op is synchronization for each vnode's v_op field for VOP_*() calls. In short, there is no synchronization for that field at all (if you ignore the special-cased Giant). In some cases, this matters -- in others, it doesn't -- so if you don't actually add any new fields to the vnode then changing the v_op might work reasonably well for some filesystems (the ones that don't actually examine the value of v_op). Happy to help, -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Branch prediction
Trent Nelson wrote:
For as long as I've been programming, I've always been under the
impression that CPUs will always predict a branch as being false
the first time they come across it.
The state of the art has advanced considerably since then.
Many, many years ago, I came across a DEC programming guide that
said the same thing. It suggested using 'do { } while()' over
'while() {}' for loops as this ensured that the loop block was
correctly pre-fetched (rather than whatever followed the loop)
the first time the branch was encountered.
That must have been a long time ago. while() {} loops routinely get
compiled as:
bra condition_check
looptop:
... body of loop ...
condition:
... test condition ...
bcc looptop:
A 'do' loop differs only in omitting the initial forward
branch. Since this is an unconditional forward branch, it's
always correctly predicted. ;-)Thus, as a practical matter,
there's no performance difference between do/while and
while.
... have either CPU architectures or compilers improved
over time such that this isn't an issue anymore? Are CPUs able
to intelligently predict a branch the first time they encounter
it? Do compilers re-order blocks to optimise pre-fetching and
minimise branch mis-prediction?
Yes, compilers re-order blocks. I once spent a couple of weeks
trying to hand-assemble some code to run faster than the compiler.
I was only able to accomplish it if there were particular processor
features (SIMD instructions or explicit prefetch) that the
compiler was unaware of. For serial C code, the compilers are
pretty smart these days.
In particular, modern instruction sets allow the compiler to
specify whether the branch should be default-taken or default-not-taken.
Processors contain branch history that can detect and record
certain common patterns (e.g., branch is not taken every third
time) to improve prediction. (This history is maintained as
long as the branch remains in the instruction cache, and can be
very effective for tight inner loops.)
If there are no compiler hints and no branch history, I think
Colin was right: default taken for backward branches (assume
loops happen) default not taken for forward branches (assume if
tests succeed).
Practically speaking, I find it very rarely worth the trouble
of trying to predict this sort of thing unless you're dealing
with unusually performance-critical code.
Tim Kientzle
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
On Mon, 16 Feb 2004, Ganbold wrote: Hi, Following is the output of pciconf -lv command: As others have pointed out, the problem isn't in the em driver, since the card isn't even showing up in pciconf. Either it's somehow not enabled, or FreeBSD isn't detecting the PCI bridge that the card is connected to. If you're running in ACPI mode, I suggest that you try running without ACPI and see if that changes anything. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: maximum mfsroot size limit
At 18:29 16/02/2004, Andrew L. Neporada wrote: I have a problem with very large mfsroot filesystems in FreeBSD-4.9. 100Mb mfsroot fs boots and works fine, but 128Mb fs with the same content cause immediate reboot after 'Booting kernel in xxx seconds' line. Increase the value of NKPT in src/sys/i386/include/pmap.h. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5)
Juan Tumani [EMAIL PROTECTED] writes: I patched in the patch shown below and it didn't fix the problem, it only changed the frequency of the spikes to 32 on/off. try replacing 0x1F with 0x3F in the patch and see what happens. That seems to work in that it flattens the line out. Not sure why programs linked in 4.9 don't need the alignment fix in 5.2. Also, if you compare the 'floor' shown in the first 2 charts (as well as the last chart) at: http://www.employees.org/~rsargent/flops/ with the 3rd chart at: http://www.employees.org/~rsargent/flops/charts2.html you can see the program is more than twice as fast when linked in FreeBSD 4.9 than when linked in 5.2 as shown by the floor being 1.25 seconds/iteration for 4.9 linking v/s 2.96 seconds/iteration for 5.2 linking (on my ref machine). Any ideas, things to try, linker options in 5.2? Thanks- JT _ Choose now from 4 levels of MSN Hotmail Extra Storage - no more account overload! http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: maximum mfsroot size limit
On Mon, Feb 16, 2004 at 07:06:07PM +, Colin Percival wrote: At 18:29 16/02/2004, Andrew L. Neporada wrote: I have a problem with very large mfsroot filesystems in FreeBSD-4.9. 100Mb mfsroot fs boots and works fine, but 128Mb fs with the same content cause immediate reboot after 'Booting kernel in xxx seconds' line. Increase the value of NKPT in src/sys/i386/include/pmap.h. Thanks. Everything works as expected now. Colin Percival Andrew. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
On Mon, Feb 16, 2004 at 07:11:16PM +0100, Dag-Erling Smørgrav wrote: It can't possibly hurt. If the stack is already aligned on a better boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary since 64 and 128 are multiples of 32, and the patch is a no-op. If only a 16-byte alignment is required, a 32-byte alignment wastes a small amount of memory but does not hurt performance. I believe that less-than-16 (and possibly even less-than-32) alignment is pessimal on all platforms we support. I'm not happy with the patch as-is and would be happier if a cleaner MI-way of expressing this were found. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
Bruce M Simpson [EMAIL PROTECTED] writes: I'm not happy with the patch as-is and would be happier if a cleaner MI-way of expressing this were found. What exactly is wrong with the patch? (except for the fact that empirical tests show it should align on a 64-byte boundary) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5)
I'm surprised Bruce hasn't chimed in here yet. I guess he's tired of repeating himself. In 4.9, libcsu, which generates crt1.o (which is the start code for C programs which the linker links in automatically) has this line in it: andl$~0xf, %%esp# align stack to 16-byte boundary So anything linked with 4.9 is going to align the stack on a 16 byte boundary no matter WHAT the kernel does. FreeBSD-5 does not have this alignment in its crt1.o because GCC3 automatically aligns the stack on a per-procedure basis. Or at least it is supposed to. Maybe it's broke? :-) -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5)
Thanks Matt for picking up on the linker problem. Patching the kernel would, to me, be masking the real problem. What other improvements does gcc333 have over gcc295 that might explain why it's linked products run in a half-fast mode (take twice+ as long)? JT From: Matthew Dillon [EMAIL PROTECTED] To: Juan Tumani [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5) Date: Mon, 16 Feb 2004 13:12:15 -0800 (PST) I'm surprised Bruce hasn't chimed in here yet. I guess he's tired of repeating himself. In 4.9, libcsu, which generates crt1.o (which is the start code for C programs which the linker links in automatically) has this line in it: andl$~0xf, %%esp# align stack to 16-byte boundary So anything linked with 4.9 is going to align the stack on a 16 byte boundary no matter WHAT the kernel does. FreeBSD-5 does not have this alignment in its crt1.o because GCC3 automatically aligns the stack on a per-procedure basis. Or at least it is supposed to. Maybe it's broke? :-) -Matt _ Check out the great features of the new MSN 9 Dial-up, with the MSN Dial-up Accelerator. http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
more info about KLD
Hi, I have two questions: (1) Is there any more detailed information regarding KLD in addition to the KDL facility programming in DaemonNews and in Architecture Book? (2) Can I turn an arbitrary piece of codes in kernel into a KLD? Say, the entire TCP/IP stack? Thanks a lot! -- Bin Ren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5)
On Mon, 16 Feb 2004 16:36:35 -0500 Juan Tumani [EMAIL PROTECTED] wrote: Thanks Matt for picking up on the linker problem. Patching the kernel would, to me, be masking the real problem. What other improvements does gcc333 have over gcc295 that might explain why it's linked products run in a half-fast mode (take twice+ as long)? JT From: Matthew Dillon [EMAIL PROTECTED] To: Juan Tumani [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5) Date: Mon, 16 Feb 2004 13:12:15 -0800 (PST) I'm surprised Bruce hasn't chimed in here yet. I guess he's tired of repeating himself. In 4.9, libcsu, which generates crt1.o (which is the start code for C programs which the linker links in automatically) has this line in it: andl$~0xf, %%esp# align stack to 16-byte boundary So anything linked with 4.9 is going to align the stack on a 16 byte boundary no matter WHAT the kernel does. FreeBSD-5 does not have this alignment in its crt1.o because GCC3 automatically aligns the stack on a per-procedure basis. Or at least it is supposed to. Maybe it's broke? :-) -Matt Quite possibly. I run the same test using the latest GCC snapshot configured as system compiler and did not see such a massive slowdown. GCC 3.3.3 wins slightly on most tests and loses only on module #2 of the flops.c program posted here. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5)
: :Thanks Matt for picking up on the linker problem. Patching the kernel :would, to me, be masking the real problem. : :What other improvements does gcc333 have over gcc295 that might :explain why it's linked products run in a half-fast mode (take twice+ :as long)? : :JT I do not see a 50% loss in performance in my tests, but the GCC3 on DragonFly is a later snapshot (gcc-3.3-20040126). Generally speaking GCC3 does a better job -O2 then GCC2 when I optimize for my Athlon64. (-O2 and -O3 have the same results on GCC3 in my tests). These tests were run on an Athlon 64 3200+, on a DragonFly system of course, (which has both gcc2 and gcc3 in the base system): GCC2GCC2GCC2GCC3GCC3GCC3GCC3 -O -O2 -O2/k6 -O -O2 -O2 -O2 athlon athlon stackbndry=5 MFLOPS(1) 10711068 794 926 862 861 MFLOPS(2)832 818 810 789 825 855 857 MFLOPS(3) 1131112111051021113412081208 MFLOPS(4) 1306135613501156134614601456 GCC3 only loses in MFLOPS(1). When I looked at the assembly generated for MFLOPS(1) between GCC2 and GCC3 two things stand out: * GCC2 does a few extra stack-relative memory ops and they are spread out more. GCC3 does fewer memory ops and they are concentrated at the beginning and the end of the loop code. * GCC2 uses fld %st(x) to shift the FP stack around, while GCC3 uses fxch %st(x) to shift the FP stack around. Since we know FP operations are stack-alignment-sensitive I can see how a stack misalignment can result in terrible performance. What is less certain is whether (FP aligned) accesses to *different* data-cache lines effects performance, and that is something that GCC does not seem to optimize. My guess at least in regards to MFLOPS(1), for which GCC3 generates consistently worse results on my machine, is that FXCH (exchange fp reg with top of fp stack) performance is not hardware optimized as well as FLD (load to top of FP stack) performance, at least on my Athlon 64. This also points to the fact that both Intel and AMD have done major reoptimizations of their floating point instruction set in nearly every processor release they've ever done. The performance loss you are seeing on your machine could very well turn into a performance gain on different cpu. On a DELL-2550 I get this: DELL2550 2xPentiumIII @ 1.1GHz GCC2GCC3GCC3GCC3 -O3 -O3 -O3 -O3 -march= (nil) (nil) p3 ppro MFLOPS(1) 380 290 283 283 MFLOPS(2) 302 293 291 291 MFLOPS(3) 454 459 462 463 MFLOPS(4) 563 581 593 593 My guess is that GCC3 introduced a bit of pessimization when they started over-using FXCH and that the MFLOPS(1) code just happens to hit the case due to the huge number of FXCH's it uses. It's probably stalling the instruction pipline in a few more places. -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5)
One last note... if you guys are trying to compile flops.c with the GCC2.95 port it is probably being linked against FreeBSD-5's lib/csu's crt1.o, which does not have the stack alignment. Original 4.9-compiled binaries will have been linked against 4.9's crt1.o, which DOES have the stack alignment. Modifying kern_exec.c is not the right solution, I don't think. Adding some basic alignment back into crt1.o (like 4.9 has) would be a reasonable solution. In DragonFly I kept 4.9's alignment code in lib/csu's crt1.c, and I will be keeping it in there even when we wholely switch to gcc3 at some future date. It doesn't hurt anything and I don't like 'assuming' that GCC will always be used for C compiling. -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
On Mon, 2004/02/16 at 19:11:16 +0100, Dag-Erling Smørgrav wrote: Kris Kennaway [EMAIL PROTECTED] writes: On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote: Should I commit this? What effect does it have on non-i386 architectures? It can't possibly hurt. If the stack is already aligned on a better boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary since 64 and 128 are multiples of 32, and the patch is a no-op. If only a 16-byte alignment is required, a 32-byte alignment wastes a small amount of memory but does not hurt performance. I believe that less-than-16 (and possibly even less-than-32) alignment is pessimal on all platforms we support. Well, it misaligns stack_base on 64-bit architectures, for example (notice the - 4, which is there to compensate for the fixup in kern_execve() that will subtract another sizeof(register_t)): vectp = (char **)(((vm_offset_t)vectp ~(vm_offset_t)0x1F) - 4); It would by much better to be able to align the stack in exec_setregs(), like amd64, ia64, powerpc and sparc64 do. Unfortunately that would require changes to crt1, so it would pose a compatibility problem. - Thomas -- Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/ [EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/ Oh, great altar of passive entertainment... Bestow upon me thy discordant images at such speed as to render linear thought impossible! -- Calvin and Hobbes ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5)
Matthew Dillon wrote: I'm surprised Bruce hasn't chimed in here yet. I guess he's tired of repeating himself. In 4.9, libcsu, which generates crt1.o (which is the start code for C programs which the linker links in automatically) has this line in it: andl$~0xf, %%esp# align stack to 16-byte boundary So anything linked with 4.9 is going to align the stack on a 16 byte boundary no matter WHAT the kernel does. FreeBSD-5 does not have this alignment in its crt1.o because GCC3 automatically aligns the stack on a per-procedure basis. Or at least it is supposed to. Maybe it's broke? :-) I've not looked at 3.3, but I seem to recall that GCC 3.2 did not actually align the stack within each function, but preserved the alignment. (That is, each function assumed the stack had a certain alignment on entry and ensured that alignment was preserved for any subsequent function calls.) I had my doubts about this, as it meant there was a LOT of stack fiddling before and after every function call. (The alignment was handled at caller, not callee. A lot of functions don't need any alignment at all, really, so it seems like it could be wasted effort in a lot of cases.) If I'm remembering this correctly, then aligning the stack in crt1.o would be pretty much essential. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5)
:I've not looked at 3.3, but I seem to recall that GCC 3.2 :did not actually align the stack within each function, but :preserved the alignment. (That is, each function assumed the stack :had a certain alignment on entry and ensured that alignment :was preserved for any subsequent function calls.) Easy to test... ah, ok. 3.3 aligns the stack in main(). main: pushl %ebp movl%esp, %ebp subl$8, %esp andl$-16, %esp ailgns stack here andl 0xfff0,%esp ... And the preserves the alignment in other procedures... 8 + ebp + retaddr is 16 bytes: charlie: pushl %ebp movl%esp, %ebp subl$8, %esp /* I declared 'volatile int x' as a stack var */ callfubar callfubar callfubar leave ret :If I'm remembering this correctly, then aligning :the stack in crt1.o would be pretty much essential. : :Tim Kientzle For gcc 2.95, yes. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5)
I just downloaded gcc33 (20040202) and it does not need the kern_exec.c hack. Thanks for your cycles. JT _ Get some great ideas here for your sweetheart on Valentine's Day - and beyond. http://special.msn.com/network/celebrateromance.armx ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: more info about KLD
Bin Ren wrote this message on Thu, Jan 01, 1970 at 02:04 +0100: Might want to run ntpdate on your machine... I have two questions: (1) Is there any more detailed information regarding KLD in addition to the KDL facility programming in DaemonNews and in Architecture Book? have you checked the kernel developers handbook.. (2) Can I turn an arbitrary piece of codes in kernel into a KLD? Say, the entire TCP/IP stack? Yes, for the most part you can. Though you may limited on when you can load/unload the code. The tcp/ip stack may be a bit difficult as it has interdependancies on other parts, like ipv6... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
Hi Mike and all, I found the problem with the Intel PRO/1000 card. I looked in the BIOS and it says NO MAC address! I even reset BIOS but no results. It seems like onboard Intel card is broken or malfunctioning. I told the owner to change Dell server to another. Thanks for all who tried to help me and suggested ideas. Ganbold At 02:59 AM 17.02.2004, you wrote: On Mon, 16 Feb 2004, Ganbold wrote: Hi, Following is the output of pciconf -lv command: As others have pointed out, the problem isn't in the em driver, since the card isn't even showing up in pciconf. Either it's somehow not enabled, or FreeBSD isn't detecting the PCI bridge that the card is connected to. If you're running in ACPI mode, I suggest that you try running without ACPI and see if that changes anything. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
