Re: FreeBSD-HEAD gets stuck on vnode operations
On Mon, May 27, 2013 at 12:22:54AM +0200, Jilles Tjoelker wrote: On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monn? wrote: On 26/05/13 22:20, Jilles Tjoelker wrote: Instead of a pause() that may be too short or too long, how about waiting for the necessary lock? In other words, replace the kern_yield() call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach to acquire two locks without imposing an order between them. Since there might be more than one locked vnode, waiting on a specific locked vnode seemed rather arbitrary, but I agree that the pause is also rather arbitrary. Also, can we be sure that the v_interlock mutex will not be destroyed while the syncer process is waiting for it to be unlocked? I think this is a major problem. My idea was too easy and will not work. That said, the code in mnt_vnode_next_active() appears to implement some sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms (default value of hogticks) and then yields. This is far too long for a mutex lock and if it takes that long it means that either the thread owning the lock is blocked by us somehow or someone is abusing a mutex to work like a sleepable lock such as by spinning or DELAY. Given that it has been spinning for 200ms, it is not so bad to pause for one additional microsecond. The adaptive spinning was added fairly recently, so apparently it happens fairly frequently that VI_TRYLOCK fails transiently. Unfortunately, the real adaptive spinning code cannot be used because it will spin forever as long as the thread owning v_interlock is running, including when that is because it is spinning for vnode_free_list_mtx. Perhaps we can try to VI_TRYLOCK a certain number of times. It is also possible to check the contested bit of vnode_free_list_mtx (sys/netgraph/netflow/netflow.c does something similar) and stop spinning in that case. A cpu_spinwait() invocation should also be added to the spin loop. There are two 'proper' solutions for this issue: One is to change the handling of the vnode lifecycle to allow the safe block for the vnode interlock acquisition. In particular, the change would add some stability of the vnode memory when vnode is put on the free list. As example, the vnode zone could be marked as type-stable again, and then the vnode interlock can be obtained with dropped free list lock. Arguably, marking the zone as non-freeable would be a regression, esp. for the zone which accounts for largest allocation on the kernel memory. Another one is to somehow ensure that the priority is properly propagated from the spinning thread to the vnode interlock owner. I think that it is desirable to donate some amount of priority from the spinning thread. Unfortunately, I was unable to come up with elegant solution for this which would be also contained and did not require rewamp of the mutex interfaces. BTW, if anybody come up with the idea of the restructuring the free list handling to avoid the free list/vnode interlock LOR altogether, it would be the best. I do not have objections against the pause() addition, but I would argue that should_yield() should be removed then, switching the code to unconditionally pause when the collision detected. pgpx2bUtXS6KF.pgp Description: PGP signature
Re: NAND Framework ONFI chip detection
From: Alexander Fedorovalexander.fedo...@rtlservice.com Date: 24 maja 2013 03:51:58 GMT-07:00 To: curr...@freebsd.org Subject: Re: [PATCH] NAND Framework ONFI chip detection Hi, current! I received a positive feedback from Grzegorz Bernacki (semihalf). He said that my patch is ok. Can anyone commit a proposed patch? Hi Alexander, I've just submitted your patch. Thanks for fixing it. regards, grzesiek ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
port building warnings about compat.ia32.maxvmem
Hi, when I try to build ports on -CURRENT, I've been seeing tons of these messages since the past week or so: make: /usr/ports/Mk/bsd.port.mk line 1633: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi The amd64 kernel I'm building this on doesn't have COMPAT_FREEBSD32 defined. Lars ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD-HEAD gets stuck on vnode operations
On 27/05/13 08:07, Konstantin Belousov wrote: On Mon, May 27, 2013 at 12:22:54AM +0200, Jilles Tjoelker wrote: On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monn? wrote: On 26/05/13 22:20, Jilles Tjoelker wrote: Instead of a pause() that may be too short or too long, how about waiting for the necessary lock? In other words, replace the kern_yield() call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach to acquire two locks without imposing an order between them. Since there might be more than one locked vnode, waiting on a specific locked vnode seemed rather arbitrary, but I agree that the pause is also rather arbitrary. Also, can we be sure that the v_interlock mutex will not be destroyed while the syncer process is waiting for it to be unlocked? I think this is a major problem. My idea was too easy and will not work. That said, the code in mnt_vnode_next_active() appears to implement some sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms (default value of hogticks) and then yields. This is far too long for a mutex lock and if it takes that long it means that either the thread owning the lock is blocked by us somehow or someone is abusing a mutex to work like a sleepable lock such as by spinning or DELAY. Given that it has been spinning for 200ms, it is not so bad to pause for one additional microsecond. The adaptive spinning was added fairly recently, so apparently it happens fairly frequently that VI_TRYLOCK fails transiently. Unfortunately, the real adaptive spinning code cannot be used because it will spin forever as long as the thread owning v_interlock is running, including when that is because it is spinning for vnode_free_list_mtx. Perhaps we can try to VI_TRYLOCK a certain number of times. It is also possible to check the contested bit of vnode_free_list_mtx (sys/netgraph/netflow/netflow.c does something similar) and stop spinning in that case. A cpu_spinwait() invocation should also be added to the spin loop. There are two 'proper' solutions for this issue: One is to change the handling of the vnode lifecycle to allow the safe block for the vnode interlock acquisition. In particular, the change would add some stability of the vnode memory when vnode is put on the free list. As example, the vnode zone could be marked as type-stable again, and then the vnode interlock can be obtained with dropped free list lock. Arguably, marking the zone as non-freeable would be a regression, esp. for the zone which accounts for largest allocation on the kernel memory. Another one is to somehow ensure that the priority is properly propagated from the spinning thread to the vnode interlock owner. I think that it is desirable to donate some amount of priority from the spinning thread. Unfortunately, I was unable to come up with elegant solution for this which would be also contained and did not require rewamp of the mutex interfaces. BTW, if anybody come up with the idea of the restructuring the free list handling to avoid the free list/vnode interlock LOR altogether, it would be the best. I do not have objections against the pause() addition, but I would argue that should_yield() should be removed then, switching the code to unconditionally pause when the collision detected. Taking the idea from Jilles, what about replacing should_yield with a check to see if the vnode_free_list_mtx mutex is contented? That would prevent us from doing unnecessary pauses, and only releasing the vnode_free_list_mtx mutex when there's someone else that actually needs it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD-HEAD gets stuck on vnode operations
On Mon, May 27, 2013 at 10:19:51AM +0200, Roger Pau Monn? wrote: On 27/05/13 08:07, Konstantin Belousov wrote: On Mon, May 27, 2013 at 12:22:54AM +0200, Jilles Tjoelker wrote: On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monn? wrote: On 26/05/13 22:20, Jilles Tjoelker wrote: Instead of a pause() that may be too short or too long, how about waiting for the necessary lock? In other words, replace the kern_yield() call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach to acquire two locks without imposing an order between them. Since there might be more than one locked vnode, waiting on a specific locked vnode seemed rather arbitrary, but I agree that the pause is also rather arbitrary. Also, can we be sure that the v_interlock mutex will not be destroyed while the syncer process is waiting for it to be unlocked? I think this is a major problem. My idea was too easy and will not work. That said, the code in mnt_vnode_next_active() appears to implement some sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms (default value of hogticks) and then yields. This is far too long for a mutex lock and if it takes that long it means that either the thread owning the lock is blocked by us somehow or someone is abusing a mutex to work like a sleepable lock such as by spinning or DELAY. Given that it has been spinning for 200ms, it is not so bad to pause for one additional microsecond. The adaptive spinning was added fairly recently, so apparently it happens fairly frequently that VI_TRYLOCK fails transiently. Unfortunately, the real adaptive spinning code cannot be used because it will spin forever as long as the thread owning v_interlock is running, including when that is because it is spinning for vnode_free_list_mtx. Perhaps we can try to VI_TRYLOCK a certain number of times. It is also possible to check the contested bit of vnode_free_list_mtx (sys/netgraph/netflow/netflow.c does something similar) and stop spinning in that case. A cpu_spinwait() invocation should also be added to the spin loop. There are two 'proper' solutions for this issue: One is to change the handling of the vnode lifecycle to allow the safe block for the vnode interlock acquisition. In particular, the change would add some stability of the vnode memory when vnode is put on the free list. As example, the vnode zone could be marked as type-stable again, and then the vnode interlock can be obtained with dropped free list lock. Arguably, marking the zone as non-freeable would be a regression, esp. for the zone which accounts for largest allocation on the kernel memory. Another one is to somehow ensure that the priority is properly propagated from the spinning thread to the vnode interlock owner. I think that it is desirable to donate some amount of priority from the spinning thread. Unfortunately, I was unable to come up with elegant solution for this which would be also contained and did not require rewamp of the mutex interfaces. BTW, if anybody come up with the idea of the restructuring the free list handling to avoid the free list/vnode interlock LOR altogether, it would be the best. I do not have objections against the pause() addition, but I would argue that should_yield() should be removed then, switching the code to unconditionally pause when the collision detected. Taking the idea from Jilles, what about replacing should_yield with a check to see if the vnode_free_list_mtx mutex is contented? That would prevent us from doing unnecessary pauses, and only releasing the vnode_free_list_mtx mutex when there's someone else that actually needs it. This would still be racy, and possibly allows the lock convoy in the same manner as the current code. Also, AFAIR, the real problem was when two iterators start synchronized, it usually ended in live-lock. If you are willing, try this, of course, but I tend to agree with just an addition of pause() for now. pgpusDk8a1XnT.pgp Description: PGP signature
Re: FreeBSD-HEAD gets stuck on vnode operations
On 27/05/13 12:23, Konstantin Belousov wrote: On Mon, May 27, 2013 at 10:19:51AM +0200, Roger Pau Monn? wrote: On 27/05/13 08:07, Konstantin Belousov wrote: On Mon, May 27, 2013 at 12:22:54AM +0200, Jilles Tjoelker wrote: On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monn? wrote: On 26/05/13 22:20, Jilles Tjoelker wrote: Instead of a pause() that may be too short or too long, how about waiting for the necessary lock? In other words, replace the kern_yield() call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach to acquire two locks without imposing an order between them. Since there might be more than one locked vnode, waiting on a specific locked vnode seemed rather arbitrary, but I agree that the pause is also rather arbitrary. Also, can we be sure that the v_interlock mutex will not be destroyed while the syncer process is waiting for it to be unlocked? I think this is a major problem. My idea was too easy and will not work. That said, the code in mnt_vnode_next_active() appears to implement some sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms (default value of hogticks) and then yields. This is far too long for a mutex lock and if it takes that long it means that either the thread owning the lock is blocked by us somehow or someone is abusing a mutex to work like a sleepable lock such as by spinning or DELAY. Given that it has been spinning for 200ms, it is not so bad to pause for one additional microsecond. The adaptive spinning was added fairly recently, so apparently it happens fairly frequently that VI_TRYLOCK fails transiently. Unfortunately, the real adaptive spinning code cannot be used because it will spin forever as long as the thread owning v_interlock is running, including when that is because it is spinning for vnode_free_list_mtx. Perhaps we can try to VI_TRYLOCK a certain number of times. It is also possible to check the contested bit of vnode_free_list_mtx (sys/netgraph/netflow/netflow.c does something similar) and stop spinning in that case. A cpu_spinwait() invocation should also be added to the spin loop. There are two 'proper' solutions for this issue: One is to change the handling of the vnode lifecycle to allow the safe block for the vnode interlock acquisition. In particular, the change would add some stability of the vnode memory when vnode is put on the free list. As example, the vnode zone could be marked as type-stable again, and then the vnode interlock can be obtained with dropped free list lock. Arguably, marking the zone as non-freeable would be a regression, esp. for the zone which accounts for largest allocation on the kernel memory. Another one is to somehow ensure that the priority is properly propagated from the spinning thread to the vnode interlock owner. I think that it is desirable to donate some amount of priority from the spinning thread. Unfortunately, I was unable to come up with elegant solution for this which would be also contained and did not require rewamp of the mutex interfaces. BTW, if anybody come up with the idea of the restructuring the free list handling to avoid the free list/vnode interlock LOR altogether, it would be the best. I do not have objections against the pause() addition, but I would argue that should_yield() should be removed then, switching the code to unconditionally pause when the collision detected. Taking the idea from Jilles, what about replacing should_yield with a check to see if the vnode_free_list_mtx mutex is contented? That would prevent us from doing unnecessary pauses, and only releasing the vnode_free_list_mtx mutex when there's someone else that actually needs it. This would still be racy, and possibly allows the lock convoy in the same manner as the current code. Also, AFAIR, the real problem was when two iterators start synchronized, it usually ended in live-lock. If you are willing, try this, of course, but I tend to agree with just an addition of pause() for now. OK, I've tested replacing kern_yield with a pause the whole night and that seems to be working as expected, I did no longer see any lockups, usually during a whole night run I saw at least 3 or 4 lockups. If you are happy (and others) with the replacement you can commit it and we can replace the should_yield call later if needed. Thanks, Roger. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Intel D2500CC motherboard and strange RS232/UART behavior
Hello Lev,
to be precise, I disabled serial ports 3 and 4 and
swapped ports 1 and 2 to the back panel in the
machine's BIOS.
Then I added a test to the ioapic_config_intr function
to detect the trig == INTR_TRIGGER_EDGE and
pol == INTR_POLARITY_LOW case and to rewrite it to
INTR_TRIGGER_EDGE and INTR_TRIGGER_HIGH.
I have not tried to enable port 3 and 4 because I
cannot test them (could not find the necessary
connectors).
Regards
Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
we...@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407
-Original Message-
From: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Lev Serebryakov
Sent: Friday, May 24, 2013 10:12 PM
To: Weiß, Jürgen
Cc: 'freebsd-current@freebsd.org'
Subject: Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Jürgen.
You wrote 24 мая 2013 г., 23:15:17:
WJ According to the ACPI of the board, uart0 and uart 2
WJ use IRQ 3 and
WJ IRQ (Edge, ActiveLow, Shared, )
WJ{3}
WJ uart1 and uart3 use IRQ 4
WJ IRQ (Edge, ActiveLow, Shared, )
WJ{4}
WJ ioapic_config_intr is called with trig == INTR_TRIGGER_EDGE and
WJ pol == INTR_POLARITY_LOW.
WJ The combinatation of Edge and ActiveLow seems kind of broken.
WJ Forcing the polarity in ioapic_config_intr to INTR_POLARITY_HIGH
WJ and disabling uart 2 and uart 3 results in two working serial
WJ interfaces.
WJ So what is the correct fix to this?
I've tried to disable ACPI access to these UARTs at all, then only
two of them are detected, but they don't work either. And I cannot
disable 2 and 3, as screen I have attached to this box (old IBM-made
LCD from register/cashier machine, which works perfectly with FreeBSD
default text console on this MoBo) cannot show text (!) BIOS setup
screen to me -- it shows only blue noise and looks like compeltely
out-of-sync. I need to bring this box to some other dispaly and try
to disable these two UARTs AND disable ACPI for them with loader
tunable.
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Changing CPU frequency for Xeon processors
Thanks Eric, in case of HP Proliant DL120 G7 server, BIOS's configuration needs to be OS Control Mode. The similar would apply to other systems. Cheers, - Michio On May 18, 2013, at 10:07 PM, Eric van Gyzen wrote: On 05/18/2013 10:09 AM, Michio Honda wrote: Hi, I'm trying to experiment with downclocking CPU. My environment is 10.0-CURRENT amd64. However, my CPU (Xeon E31220) seems not to be supported by the cpufreq module, thus dmesg shows: est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. As a result, although sysctl -a shows the list of available frequency values (dev.cpu.0.freq_levels: 3093/-1 2706/-1 2319/-1 1933/-1 1546/-1 1159/-1 773/-1 386/-1 dev.), I cannot set the value (the error message is sysctl: dev.cpu.0.freq=773: Device not configured). Do you have any idea to change CPU frequency for this CPU? In my experience, the not recognized message indicates that the feature is not enabled in the BIOS. Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD-10.0 code freeze
Hi, I heard a rumor that the 10.0 code freeze will be in the end of July. Is that true? Can anyone tell me when does it plan to be? Regards, Oded Shanoon Ofed-FreeBSD team Mellanox Technologies, Raanana ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD-10.0 code freeze
On May 27, 2013, at 6:33 AM, Oded Shanoon wrote: Hi, I heard a rumor that the 10.0 code freeze will be in the end of July. Is that true? No. The release engineering team will shift focus to 9.2-R after the current focus of 8.4-R. Can anyone tell me when does it plan to be? 10 will be the focal point sometime after 9.2-R. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
bsd.qt.mk (cc --version [...])
There is no cc executable in the path (eg., there is no /usr/bin/cc) and the CC
make-variable is set to an absolute path to the C compiler (Clang) in
/etc/make.conf. Then, for example,
cd /usr/ports/www/seamonkey make config
results in the following output:
make: /usr/ports/Mk/bsd.qt.mk line 313: warning: Couldn't read shell's output for (cc --version 2
/dev/null | /usr/bin/awk 'NR == 1 { gsub(/[()]/, , $2); print $2 }') || echo gcc
TODO: fix.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building of libc in /usr/src/lib/libc results in error
On 05/27/2013 02:28, Super Bisquit wrote: building shared library libc.so.7 /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. I have run into this issue multiple times in the past -- its occurrence seems to be correlated with header updates. As an instant workaround, you can add ALLOW_SHARED_TEXTREL=1 to /etc/make.conf for one buildworldinstallworld run, and then do another run, for which ALLOW_SHARED_TEXTREL=1 will empirically not be required. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building of libc in /usr/src/lib/libc results in error
On May 27, 2013, at 19:21, d...@gmx.com wrote: On 05/27/2013 02:28, Super Bisquit wrote: building shared library libc.so.7 /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. I have run into this issue multiple times in the past -- its occurrence seems to be correlated with header updates. As an instant workaround, you can add ALLOW_SHARED_TEXTREL=1 to /etc/make.conf for one buildworldinstallworld run, and then do another run, for which ALLOW_SHARED_TEXTREL=1 will empirically not be required. This may work around the issue, but it will not solve the root cause. Normally, you should never get these warnings, so there must be something special about your environment. Can you post your make.conf, src.conf and any other relevant settings? -Dimitry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Intel AMT
From observation: volt% amttool-tng k5 rem_control info ## 'k5' :: AMT Remote Control FAULT: 500 Can't connect to k5:16992 (Invalid argument) (1) k5% sudo ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO ether e8:40:f2:ec:60:5e inet 10.146.103.5 netmask 255.255.0.0 broadcast 10.146.255.255 media: Ethernet autoselect (1000baseT full-duplex) status: active k5% sudo ifconfig em0 -tso4 Doesn't work immediately, but AMT starts to work. volt% amttool-tng k5 rem_control info ## 'k5' :: AMT Remote Control FAULT: 500 Can't connect to k5:16992 (Invalid argument) (1) volt% amttool-tng k5 rem_control info ## 'k5' :: AMT Remote Control # Remote Control Info :: AMT Remote Control Powerstate: S0 Watchdog Expired: No Power Source: AC Remote Control Capabilities: Control Commands Supported powerCycle powerDown powerUp reset IanaOemNumber 343 Special Commands Supported PXE-boot HD-boot CD-boot Special Commands (Oem) IDER SOL BiosReflash BiosSetup BiosPause SystemFirmwareCapabilities LockKeyboard UserPasswordBypass ForcedProgressEvents VerbosityVerbose VerbosityQuiet VerbosityScreenBlank Is it normal? When KVM sesion is open network card works only on 10baseT standard. You cannot change speed: k8% # ifconfig em0 media 1000baseT k8% # lo kernel -2 May 25 01:01:14 k8 kernel: em0: Media change is blocked due to SOL/IDER session. May 25 01:02:16 k8 kernel: em0: Media change is blocked due to SOL/IDER session. After closig KVM connection with VNC Viewer: k8% # ifconfig em0 media 1000baseT k8% ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO inet 10.146.103.8 netmask 255.255.0.0 broadcast 10.146.255.255 media: Ethernet 1000baseT (1000baseT full-duplex) status: active And very important: after speed change AMT works fine. Any kind of reset network card makes AMT good, for example: ifconfig em0 -txcsum 2013/5/14 Kamil Czekirda kczeki...@gmail.com: Motherboard: Intel DQ77KB, the latest BIOS AMT fw. both ethernet interfaces connected, DHCP configured only the the first (managment) or only the second - the same result: after appr. 5 min ? AMT can't be accesed. (Same result on a few such a PCs which we have about ten in lab) FreeBSD: 9.1 amd64, SVN-updated and recompiled (kernel+world) on 11 May: if_em driver: em0: Intel(R) PRO/1000 Network Connection 7.3.7 port 0xf080-0xf09f mem 0xf7e0-0xf7e1, 0xf7e39000-0xf7e39fff irq 20 at d em1: Intel(R) PRO/1000 Network Connection 7.3.7 port 0xe000-0xe01f mem 0xf7c0-0xf7c1,0xf7c2-0xf7c23fff irq 18 at d k1% uname -a FreeBSD k1 9.1-STABLE FreeBSD 9.1-STABLE #0: Sat May 11 23:22:00 CEST 2013 k1% biosver Version:KBQ7710H.86A.0049.2013.0130.1732 Release Date: 01/30/2013 smbios.bios.reldate=01/30/2013 smbios.bios.vendor=Intel Corp. smbios.bios.version=KBQ7710H.86A.0049.2013.0130.1732 smbios.chassis.maker= smbios.chassis.serial= smbios.chassis.tag= smbios.chassis.version= smbios.memory.enabled=4194304 smbios.planar.maker=Intel Corporation smbios.planar.product=DQ77KB smbios.planar.serial=BTKB22100SUJ smbios.planar.version=AAG40294-401 smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker= smbios.system.product= smbios.system.serial= smbios.system.uuid=7fe1575d-31a4-e111-9b80-6431503407e9 smbios.system.version= smbios.version=2.7 k1% # lspci 00:00.0 Host bridge: Intel Corporation Ivy Bridge DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Ivy Bridge Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation Panther Point MEI Controller #1 (rev 04) 00:16.3 Serial controller: Intel Corporation Panther Point KT Controller (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation Panther Point USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation Panther Point High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1 (rev c4) 00:1c.2 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 3 (rev c4) 00:1c.6 PCI bridge:
copyin+copyout in one step ?
Hi, say a process P1 wants to use the kernel to copy the content of a buffer SRC (in its user address space) to a buffer DST (in the address space of another process P2), and assume that P1 issues the request to the kernel when P2 has already told the kernel where the data should go: P1P2 +--+ ++ | SRC | | DST| +--v---+ +--^-+ ||-- ||kernel |^ || | ++| +-| tmpbuf ++ copyin|| copyout P1 ctx++ P2 ctx I guess the one above is the canonical way: P1 does a copyin() to a temporary buffer, then notifies P2 which can then issue or complete a syscall to do a copyout from tmpbuf to DST in P2's context. But I wonder, is it possible to do it as follows: P2 tells the kernel where the data should go (DST); later, P1 issues a system call and through a combined copyinout() moves data directly from SRC to DST, operating in the context of P1. | copyinout() ? | +---+ issued by P1 Is this doable at all ? I suspect that tell DST to the kernel might be especially expensive as it needs to pin the page so it is accessible while doing the syscall for P1 ? (the whole point for this optimization is saving the extra copy through the buffer, but it may be pointless if pinning the memory is more expensive than the copy) cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: copyin+copyout in one step ?
On 5/27/13 4:38 PM, Luigi Rizzo wrote: Hi, say a process P1 wants to use the kernel to copy the content of a buffer SRC (in its user address space) to a buffer DST (in the address space of another process P2), and assume that P1 issues the request to the kernel when P2 has already told the kernel where the data should go: P1P2 +--+ ++ | SRC | | DST| +--v---+ +--^-+ ||-- ||kernel |^ || | ++| +-| tmpbuf ++ copyin|| copyout P1 ctx++ P2 ctx I guess the one above is the canonical way: P1 does a copyin() to a temporary buffer, then notifies P2 which can then issue or complete a syscall to do a copyout from tmpbuf to DST in P2's context. But I wonder, is it possible to do it as follows: P2 tells the kernel where the data should go (DST); later, P1 issues a system call and through a combined copyinout() moves data directly from SRC to DST, operating in the context of P1. | copyinout() ? | +---+ issued by P1 Is this doable at all ? I suspect that tell DST to the kernel might be especially expensive as it needs to pin the page so it is accessible while doing the syscall for P1 ? (the whole point for this optimization is saving the extra copy through the buffer, but it may be pointless if pinning the memory is more expensive than the copy) I suspect you'll want to use something like vslock(9) and sf_bufs. Have a look at vm/vm_glue.c - vslock() vm_imgact_hold_page(). On amd64, I *think* mapping an sfbuf or if you are really evil you can optimistically wire the page in the vm (cheap). If it's present then you can just use the direct map to access it. However, if it's not present, then fall back to another method, or maybe just fault it in (which will have to happen anyhow) and then retry. Sounds like a cool project! -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: copyin+copyout in one step ?
On 5/27/13 4:56 PM, Alfred Perlstein wrote: On 5/27/13 4:38 PM, Luigi Rizzo wrote: Hi, say a process P1 wants to use the kernel to copy the content of a buffer SRC (in its user address space) to a buffer DST (in the address space of another process P2), and assume that P1 issues the request to the kernel when P2 has already told the kernel where the data should go: P1P2 +--+ ++ | SRC | | DST| +--v---+ +--^-+ ||-- ||kernel |^ || | ++| +-| tmpbuf ++ copyin|| copyout P1 ctx++ P2 ctx I guess the one above is the canonical way: P1 does a copyin() to a temporary buffer, then notifies P2 which can then issue or complete a syscall to do a copyout from tmpbuf to DST in P2's context. But I wonder, is it possible to do it as follows: P2 tells the kernel where the data should go (DST); later, P1 issues a system call and through a combined copyinout() moves data directly from SRC to DST, operating in the context of P1. | copyinout() ? | +---+ issued by P1 Is this doable at all ? I suspect that tell DST to the kernel might be especially expensive as it needs to pin the page so it is accessible while doing the syscall for P1 ? (the whole point for this optimization is saving the extra copy through the buffer, but it may be pointless if pinning the memory is more expensive than the copy) I suspect you'll want to use something like vslock(9) and sf_bufs. Have a look at vm/vm_glue.c - vslock() vm_imgact_hold_page(). On amd64, I *think* mapping an sfbuf or if you are really evil you can optimistically wire the page in the vm (cheap). If it's present then you can just use the direct map to access it. However, if it's not present, then fall back to another method, or maybe just fault it in (which will have to happen anyhow) and then retry. Sounds like a cool project! -Alfred Oh, one other thing.. look at the pipe code. It used to do what you suggest, I think however it was driven by the READER pinning the WRITER's address space and doing a direct copy. However it may not be optimized for NOT-mapping into kva as I suggested doing. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: copyin+copyout in one step ?
On Tue, May 28, 2013 at 01:38:01AM +0200, Luigi Rizzo wrote: Hi, say a process P1 wants to use the kernel to copy the content of a buffer SRC (in its user address space) to a buffer DST (in the address space of another process P2), and assume that P1 issues the request to the kernel when P2 has already told the kernel where the data should go: P1P2 +--+ ++ | SRC | | DST| +--v---+ +--^-+ ||-- ||kernel |^ || | ++| +-| tmpbuf ++ copyin|| copyout P1 ctx++ P2 ctx I guess the one above is the canonical way: P1 does a copyin() to a temporary buffer, then notifies P2 which can then issue or complete a syscall to do a copyout from tmpbuf to DST in P2's context. But I wonder, is it possible to do it as follows: P2 tells the kernel where the data should go (DST); later, P1 issues a system call and through a combined copyinout() moves data directly from SRC to DST, operating in the context of P1. | copyinout() ? | +---+ issued by P1 Is this doable at all ? I suspect that tell DST to the kernel might be especially expensive as it needs to pin the page so it is accessible while doing the syscall for P1 ? (the whole point for this optimization is saving the extra copy through the buffer, but it may be pointless if pinning the memory is more expensive than the copy) Yes, it is doable. If the copy can happen when either P1 or P2 are active context, then proc_rwmem() already perform exactly what you want. The virtual address in the address space of the 'other process' is specified as uio-uio_offset. The iov specifies the region(s) for the current process. If you want to perform the copy from P1 to P2 while some other context P3 is active, the same structure as proc_rwmem() would work, but you obviously would need to do vm_fault_hold() for both sides, and use pmap_copy_pages() instead of uiomove_fromphys(). In either case, you get copy without temporal buffer, but the setup cost could be non-trivial. You never know until measured. pgpTQLn3fMXt7.pgp Description: PGP signature
Re: copyin+copyout in one step ?
On Mon, May 27, 2013 at 7:38 PM, Luigi Rizzo ri...@iet.unipi.it wrote: say a process P1 wants to use the kernel to copy the content of a buffer SRC (in its user address space) to a buffer DST (in the address space of another process P2), and assume that P1 issues the request to the kernel when P2 has already told the kernel where the data should go: Urm... Isn't the use of shared memory the more obvious way to transfer data between processes? Am I missing some nuance? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
