(no subject)
Subject: Re: Possible instruction pipelining problem between HT's on the same die ? References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] :I would expect that putting the fence on the write side will solve the :problem. As Stephen discussed, the writes will land in a store buffer :for a period of time, during which a fence on the write CPU will flush :it out and make it visible to the other CPUs. Doing a fence on the read :CPU will have no effect on the store buffers of the write CPU and will :be a waste of time. As a way to reduce latency... but a fence on the write side does not solve the reordering problem on the read side. When the write side writes the FIFO entry and then updates the FIFO index, the read side must be able to guarentee that the FIFO data it reads is valid when it sees that the FIFO index has been updated. This means that the read side cannot afford to allow the reads to be reordered and thus must use some sort of fence. :Another thing to keep in mind is that there is no difference here :between HT and non HT SMP protocol. While HT cores share execution :units, they DO NOT share registers, store buffers, or cache (at least, :not in a way that is visible outside of the low-level implementation of :the chip). : :Scott They do share the cache, but I see your point. I'm not sure about store buffers but from the behavior I've observed I suspect that store buffers either are not shared, or a logical cpu's store buffer sniffing does not extend to the other logical cpu's entries. In our case latency is not a big issue. These are almost universally asynchronous messages flying between the cpus. What matters is the cycle overhead on each side to send and process the message. Hence I was trying to avoid the use of locked bus cycle instructions. I'll have to run tests to check the relative expense of the *FENCE instructions (when supported) verses doing a lock; addl 0(%esp) to fence the read. At least I don't have to put the fence in the body of the processing loop... I just have to put it after the read of the FIFO's write index before the loop is entered. It's a real shame that special instructions are required at all. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ath port for 4.11?
Hello, is there a port of the ath driver for FreeBsd 4.11? -Hanspeter ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
USB CDC ACM
Hello all... Has anyone a mobile phone (motorola v300?), in the FreeBSD environment? There are some apps like: kmobiletools, kandy, moto4lin, that just need a modem interface to contact to the cell phone and sync (contacts, meetings...). But i don't know if FreeBSD have these 'specs' implemented (USB CDC ACM). Maybe the umodem can handle the mobiles's modem. So, i just want to know if someone have a mobile phone working, and with which configurations? Thanks. -- [EMAIL PROTECTED] http://omestre.freeshell.org - I believe i need every ship we have if we're going to survive this attack. Then why did you allow the Nebuchadnezzar to leave? (Commander Lock) Because i believe our survival dependes on more than how many ships we have. (Councillor Hamann) - Matrix Reloaded - - ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: cc1: internal compiler error: Abort trap: 6
I figured this out, basically somehow the pf_table.c file got truncated during the install. When I installed a fresh complete file, the make succeeded. However I am surprised that gcc did not report a more verbose warning. Br vijay -Original Message- From: Kris Kennaway [mailto:[EMAIL PROTECTED] Sent: Friday, June 03, 2005 11:12 AM To: Singh, Vijay Cc: freebsd-hackers@freebsd.org Subject: Re: cc1: internal compiler error: Abort trap: 6 On Thu, Jun 02, 2005 at 03:59:35PM -0700, Singh, Vijay wrote: Hello, while doing a make buildkernel on a FreeBSD 6.0 system, I get a compile failure in pf (depend): === pf (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include echo #define DEV_PF 1 opt_pf.h echo #define DEV_PFLOG 1 opt_pf.h echo #define INET 1 opt_inet.h echo #define INET6 1 opt_inet6.h echo #define DEV_BPF 1 opt_bpf.h rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/src/sys/modules/pf/../../contrib/pf -D_KERNEL -DKLD_MODULE -I- -I/usr/src/sys/modules/pf/../../contrib/pf -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -I/usr/obj/usr/src/sys/SMP /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c /usr/src/sys/modules/pf/../../contrib/pf/net/pf_subr.c /usr/src/sys/modules/pf/../../contrib/pf/net/pf_osfp.c /usr/src/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c /usr/src/sys/modules/pf/../../contrib/pf/net/pf_norm.c /usr/src/sys/modules/pf/../../contrib/pf/net/pf_table.c /usr/src/sys/modules/pf/../../contrib/pf/net/if_pflog.c /usr/src/sys/modules/pf/../../contrib/pf/netinet/in4_cksum.c cc1: internal compiler error: Abort trap: 6 Were you doing a buildworld -j large number on an SMP system? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible instruction pipelining problem between HT's on the same die ? (fwd)
Hi, I did a fair amount of lock-free programming during my PhD and for Xen, so I may be able to shed some light on this situation. OTOH I may also be confused: the x86 memory model is poorly specified and the reference manuals are often badly written and misleading. I'll address the points and questions out of order But I'm beginning to think that it isn't working as advertised. I've read the manuals over and over again and they seem to only guarentee write ordering between physical cpus, not between logical HT cpus, and even then it appears that a cpu can do a speculative read and thus get an old value for A even after getting a new value for B. The ordering guarantees between HTs are identical to those between physical cpus. I'm referring to Section 7.6.19 of IARM (Intel IA-32 Reference Manual) Vol 3. It's slightly confusing that it says can further be defined as 'write-ordered with store buffer forwarding' but this forwarding only occurs separately *within* each logical cpu (the store buffer is statically partitioned between the two HTs), and this phrase is identical to the one describing physical cpu behaviour in Section 7.2.2 (ie. it is redundant to reiterate it in this later section). Reads can be speculatively executed out-of-order, but this property isn't unique to HTs. This race could in theory happen across physical cpus. Now I was depending on the presumed write ordering, so if a foreign cpu sees that B is updated it can assume that A has also been updated. You *can* depend on write ordering. But this ordering is no help if CPU#1 has already executed, and is retiring, the read from A by the time it executes the read from B. It's CPU#1 that is screwing up, not CPU#0. I looked at the various SFENCE/LFENCE/MFENCE instructions and they do not seem to guarentee ordering for speculative accesses at all. They all say that they do not protect against speculative reads. Bus-locked instructions don't seem to avoid speculative reads either. I think the reference manual is being almost wilfully misleading by referring to the speculative prefetch mechanism and its total independence from the fence instructions: data could be speculatively loaded into the cache just before, during, or after the execution of an MFENCE instruction. It is important to realise that speculative execution of a memory-reading instruction is quite different from speculative prefetch into a cache. The latter should not matter to the programmer: the cache coherency protocol hides it. Consider the code example in the original email: cpu #0 write A write B (HT)cpu #1 read B if (B) read A gets OLD data in A, not new data If CPU#1 prefetches A into its cache before it reads B, it may indeed see the old value of A; *but* when CPU#0 writes A it will invalidate that cacheline in all remote caches; *furthermore* CPU#0 cannot commit its update of B until after it has committed its update of A (x86 guarantees write order). So, if CPU#1 reads the new value of B, then any stale value of A in its cache has been invalidated by that point. All you need to ensure is that CPU#1 hasn't speculatively executed the read from A: precisely the purpose of MFENCE and LFENCE. This is more complicated if both CPUs are sharing their memory hierarchy. However, either cache lines are tagged with an HT identifier and so the cache logically operates as two separate variable-sized caches (in which case normal cache coherency rules apply as described above), or there is true cacheline sharing (in which case there is no stale data to worry about, as CPU#0 will directly update the cache data that CPU#1 will read from). Either way, there's no weakening of the memory model. -- Keir ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
playing audio CD's on modern laptops
Hi, On my laptop, which is not very old, they have dropped support for playing CD's through cdcontrol. To play CD's one has to read the samples off the CD-ROM and send it to the soundcard in software. The problem is that the ATAPI driver complains when trying to read audio data: acd0: WARNING - READ_CD UDMA ICRC error (retrying request) So I tried: sysctl hw.ata.atapi_dma=0 Which says I should put hw.ata.atapi_dma=0 into a non-existent file. Then I tried: echo hw.ata.atapi_dma=0 /boot/device.hints And rebooted. Now things work. Why is PIO mode not selected automatically by the ATAPI driver? Hence obviously some manufacturers try to save money here, not supporting all modes for all mediums? UDMA works for data CD-ROM's though. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
vmstat reporting incorrect cpu usage
I've noticed if i run vmstat with no params when rebuilding the kernel i get this right: # vmstat procs memory page disk faults cpu r b w avmfre flt re pi po fr sr ad0 in sy cs us sy id 2 1 0 294156 44596 313 0 0 0 296 1 0 82 85 225 14 8 78 # But, if i run it like this # vmstat -c 2 procs memory page disk faults cpu r b w avmfre flt re pi po fr sr ad0 in sy cs us sy id 1 1 0 299580 38204 313 0 0 0 296 1 0 82 85 225 14 8 78 1 1 0 294996 42876 886 0 0 0 2061 0 3 1364 2231 81 19 0 # The second result shows what top does, but the first one seems to be completely wrong... # vmstat -c 6 procs memory page disk faults cpu r b w avmfre flt re pi po fr sr ad0 in sy cs us sy id 1 1 0 300136 36196 313 0 0 0 296 1 0 82 85 225 14 8 78 1 1 0 301040 35312 230 0 0 0 9 0 0 2193 489 2156 87 13 0 1 1 0 296720 39644 1234 0 0 0 2326 0 5 2190 1530 2185 70 30 0 1 1 0 297092 39228 1435 0 0 0 1336 0 3 2200 1562 2188 75 25 0 1 1 0 298488 37844 1573 0 0 0 1229 0 4 2206 1592 2191 69 31 0 1 1 0 299372 36908 316 0 0 0 123 0 96 2301 618 2442 86 14 0 # Only the first one seems to do it though... FreeBSD 5.3-RELEASE. Does this happen for anyone else? (Mabe someone running 5.4 can test this?) ~Neo-Vortex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: playing audio CD's on modern laptops
On Sat, Jun 04, 2005 at 03:47:42PM +0200, Hans Petter Selasky wrote: Why is PIO mode not selected automatically by the ATAPI driver? Hence obviously some manufacturers try to save money here, not supporting all modes for all mediums? UDMA works for data CD-ROM's though. (a) Because it adds a lot of overhead for normal operation e.g. playing a DVD. (b) Because not all drives are unable to correctly implement it, for many ATAPI-DMA and CDDA works fine. BTW, you can always switch without rebooting, atacontrol(8) is your friend. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vmstat reporting incorrect cpu usage
- Original Message - From: Neo-Vortex [EMAIL PROTECTED] To: freebsd-hackers@freebsd.org Sent: Saturday, June 04, 2005 10:01 AM Subject: vmstat reporting incorrect cpu usage I've noticed if i run vmstat with no params when rebuilding the kernel i get this right: # vmstat procs memory page disk faults cpu r b w avmfre flt re pi po fr sr ad0 in sy cs us sy id 2 1 0 294156 44596 313 0 0 0 296 1 0 82 85 225 14 8 78 # But, if i run it like this # vmstat -c 2 procs memory page disk faults cpu r b w avmfre flt re pi po fr sr ad0 in sy cs us sy id 1 1 0 299580 38204 313 0 0 0 296 1 0 82 85 225 14 8 78 1 1 0 294996 42876 886 0 0 0 2061 0 3 1364 2231 81 19 0 # The second result shows what top does, but the first one seems to be completely wrong... # vmstat -c 6 procs memory page disk faults cpu r b w avmfre flt re pi po fr sr ad0 in sy cs us sy id 1 1 0 300136 36196 313 0 0 0 296 1 0 82 85 225 14 8 78 1 1 0 301040 35312 230 0 0 0 9 0 0 2193 489 2156 87 13 0 1 1 0 296720 39644 1234 0 0 0 2326 0 5 2190 1530 2185 70 30 0 1 1 0 297092 39228 1435 0 0 0 1336 0 3 2200 1562 2188 75 25 0 1 1 0 298488 37844 1573 0 0 0 1229 0 4 2206 1592 2191 69 31 0 1 1 0 299372 36908 316 0 0 0 123 0 96 2301 618 2442 86 14 0 # Only the first one seems to do it though... FreeBSD 5.3-RELEASE. Does this happen for anyone else? (Mabe someone running 5.4 can test this?) The first line is the average since the system was last booted; all other lines are instantaneous. -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vmstat reporting incorrect cpu usage
On Saturday 04 June 2005 17:58, Matt Emmerton wrote: The first line is the average since the system was last booted; all other lines are instantaneous. yeap. from man page: -c Repeat the display count times. The first display is for the time since a reboot and each subsequent report is for the time period since the last display. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How FREEBSD deals with request for continuous physical pages
In message: [EMAIL PROTECTED] Bao Zhao [EMAIL PROTECTED] writes: : Linux use buddy allocator.but I find it seems that : FREEBSD uses single page linked list. but SLAB and : some drivers need continuous physical pages, so I : wonder how FREEBSD solved this problem. contigmalloc() Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
help me with C languaje please, re: files.
Hi all, I am programming in C and I need to read a quantity of lines of a file. How can I know when a line arrives at his end? exists some special character? exists some file in C in the kernel of FreeBSD (4.11) where I can find somewhat similar? example: how read four lines of a file. thanks and sorry for my badly English. -- Concepción, Chile. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: help me with C languaje please, re: files.
On Sat, Jun 04, 2005 at 02:11:01PM -0400, Pablo Mora wrote: Hi all, I am programming in C and I need to read a quantity of lines of a file. How can I know when a line arrives at his end? exists some special character? exists some file in C in the kernel of FreeBSD (4.11) where I can find somewhat similar? example: how read four lines of a file. Take a look at fgets(3). The end of line character (in FreeBSD) is '\n'. -- La prueba mas fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fork mystries....
Thank you guys,
I got it fork is creating a different process.
Currently, I am working a lot that I forget even the basic principales ;-)
I need a break ...
-aziz
On 6/3/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Aziz,
Fork is for process creation. Look up pthread_create() and/or POSIX
thread
creation, etc. You should be able to find a lot of info on google with a
quick
search:
http://math.arizona.edu/~swig/documentation/pthreads/
From the OS standpoint a process is like a different program when you fork
it.
A thread is more like a single program with a bunch of subsections all
running
at the same time, then the OS and CPU jump back and forth giving a little
run-time to each subsection. Threads share a common space; processes [as
far as
I recal] do not (which is where inter process communication comes into
play).
Anyway, have fun! :)
Ray
At 07:55 PM 6/3/2005 -0400, Aziz Kezzou wrote:
| Hi all,
| It's probably not the right mailing list to ask but I am really
| surprised about global variable sharing in a multithreaded C
| application. If I remember well my multithreading course global
| variables are shared between threads, right ?
|
| Example :
|
| int counter = 0;
| int main() {
| if( fork()==0) {
| while(1) {
| sleep(1);
| counter++;
| printf(Son : counter = %d\n, counter);
| }
| } else {
| while(1) {
| sleep(1);
| printf(Parent : counter = %d\n, counter);
| }
| }
| return 0;
| }
|
|
| All I get is :
| Parent : counter = 0
| Son : counter = 1
| Son : counter = 2
| Parent : counter = 0
| Son : counter = 3
| Parent : counter = 0
| Son : counter = 4
| Parent : counter = 0
|
| why counter isn't shared between the two threads ??!
| thanks,
| -aziz
| ___
| freebsd-hackers@freebsd.org mailing list
| http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
| To unsubscribe, send any mail to
[EMAIL PROTECTED]
|
|
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NMI handlers ??
In message: [EMAIL PROTECTED] Dipjyoti Saikia [EMAIL PROTECTED] writes: : I am working on IPMI watchdog implementation . The problem that I am : facing is that in case of improper system shutdown or powerfail the : watchdog keeps running and the next time system boots up , BIOS : complains of FRB2 timeout and fails one of the CPU's ( Working on SMP : system ) . : : My idea is to handle NMI generated by abruptly pushing power button : and disabling the timer in the routine. : : Can we have a handlers for NMI ?? I am not very sure what is happening : inside the kernel when NMI is delivered . : : Please provide me some inputs. We did this at timing solutions. Here are a few notes: (1) You must disable the F00F_HACK with the kernel config file. (2) We had to hack the nmi code to allow multiple refiring of the nmi routine in the chipset. These hacks are evidentially fairly chipset specific. We were using the #IOCHK line on the ISA bus to accomplish this. I don't think that you'll need to worry about this. (3) You need some kind of NMI handler. You can do almost nothing in this handler. The following code is from 4.x. nmiReset is set elsewhere. #include machine/asmacros.h /* miscellaneous macros */ #include sys/cdefs.h /* CPP macros */ /* XXX: not very portable! */ #define KDSEL 0x10/* kernel data selector */ .text ALIGN_TEXT .globl Xtscnmidrv Xtscnmidrv: pushl %eax pushl %ecx pushl %edx pushl %ds movl$KDSEL, %eax movl%eax, %ds /* read the timestamp counter */ .byte 0x0f, 0x31 /* RDTSC */ movl%edx, tsHi movl%eax, tsLo /* update the counter */ inclnmiCounter /* * XXX: It is necessary to drop the NMI level on the driving * card at this point IF we wish to use 'NMI_CREATE_EDGE' */ .globl nmiReset movlnmiReset, %eax testl %eax, %eax /* XXX: we should really just permanently disable NMIs in this case */ je skip call*%eax skip: /* diddle the IOCHK# NMI registers */ inb $0x61, %al /* current PORT-B contents */ /* XXX: need to test source bits, assume IOCHK# for now... */ andb$0x0f, %al /* PIIX wants upper bits 0 on write */ orb $0x08, %al /* IOCHK# high to clear */ outb%al, $0x61 andb$0x07, %al /* IOCHK# low to enable */ outb%al, $0x61 /* restore registers */ popl%ds popl%edx popl%ecx popl%eax iret .data ALIGN_DATA .globl nmiCounter nmiCounter: .long 0 .globl timeStamp timeStamp: tsLo: .long 0 tsHi: .long 0 4) We have to establish the handler: /* Install the custom TSC NMI handler. */ setidt( 2, IDTVEC(tscnmidrv), SDT_SYS386IGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL) ); and set nmiReset when you arm the nmi source and clear it if you ever disarm it. nmiReset should be set to the function you want to call. I'm not sure what the right sequence of inb/outb is for your chipset... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB CDC ACM
I beleive that umodem implements the usb cdc acm interface. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: help me with C languaje please, re: files.
#include stdio.h
#include stdlib.h
int main(void) {
FILE *p_to_f;
char buf[1024];
int i, j = 0;
p_to_f = fopen(test,r);
if(p_to_f == NULL) {
perror(fopen);
exit(EXIT_FAILURE);
}
for(i = 0; i 4 !feof(p_to_f); i++) {
fgets(buf,1024,p_to_f);
printf(%s, buf);
}
fclose(p_to_f);
return 0;
}
I expect that be well what I did. Thanks Victor.
PD Corrigeme Si hay algo malo. :D
--
Concepción, Chile.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
