Re: PCMCIA questions: mapping attribute and common memory?
Warner, Thanks for your informative response. On Thu, Sep 05, 2002 at 02:59:36PM -0600, M. Warner Losh wrote: You generally don't map attribute memory. With one exception (the raylan cards), there's no hardware in the attribute memory section and it is just used to store the cis. ... [ray(4) and xe(4)] Those are the two worst ones to look at. Don't do what they do, as the ray(4) hardware is weird and the xe(4) driver was written before we could read the cis from the kernel. The particular device I'm working with is the Gemplus GPR400 PCMCIA Smart Card Reader. It has hardware registers in the attribute memory. One of these registers tells me when a card is inserted/ejected, and there are also some bits in that space which are used to handle suspending and resuming the card. What's the best way for me to do this, whilst being OLDCARD and NEWCARD compatible? (And just out of interest, is it possible to read the CIS from the kernel easily whilst still being OLDCARD friendly?) : If so, how do I get at the resource? : If not, how would I go about doing this myself in the driver? bus_alloc_resource() Ok. Say I have my first two tuples and they look like this:- Tuple #1, code = 0x1 (Common memory descriptor), length = 3 000: d4 00 ff Common memory device information: Device number 1, type Function specific, WPS = OFF Speed = 100nS, Memory block size = 512b, 1 units Tuple #2, code = 0x17 (Attribute memory descriptor), length = 3 000: 64 10 ff Attribute memory device information: Device number 1, type SRAM, WPS = OFF Speed = 100nS, Memory block size = 512b, 3 units How will these blocks be mapped when I allocate the resource? Are they coalesced into a single memory map in the order in which they appear in the CIS? Thing is, 2KB is 0x800 hex, and the register addresses I see in this Linux code I'm porting all start at 0xFA0. This would seem to indicate that a 2KB memory window is needed. [(3+1)*512]. The Linux code asks for a window size of 0x1000, which is 4KB, yet the comment says it's asking for 2KB. Bizarre. Once I've allocated the window as a resource, how would I go about accessing that memory directly? Would I need to establish a page mapping? [probe] Ideally, you'd just match the OEM ID and vendor info of the card. Less ideally, you'd match the strings in the CIS. So why do many pccard driver probes allocate and deallocate their card's resources? Is this merely to make sure they're available in anticipation of attach? BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
intermezzo?
Hi, I have recently come across an old little discussion about InterMezzo. I 've got the impression that it wasn't really welcome to FreeBSD. Just curious if something similar has been done for FreeBSD, or if someone is working on such thing. I am actually looking for an MS research project topic and Intermezzo seemed to be an interesting possibility. Other suggestions would be also helpful. Thanks, Seva Tonkonoh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: intermezzo?
In message [EMAIL PROTECTED], Seva Tonkonoh writ es: Hi, I have recently come across an old little discussion about InterMezzo. I 've got the impression that it wasn't really welcome to FreeBSD. What is it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [tulip-bug] FreeBSD Problems with dc(4) ADMtek AN985 chip
Hi, This technique cannot be efficiently used with mbufs in *BSD, so there must be two different ring handling code paths: both chained and wrapped-ring configurations. Ok That's very likely a media selection problem, rather than a Rx descriptor problem. Of course resetting the chip will clear a descriptor hang, but that wouldn't be my first guess. It looks like you are right. I've seen two problems and they produced mixed results. 1.) TX underrun (FreeBSD specific) 2.) Media selection problem after small timeouts (cable problems) (Linux and FreeBSD) But why I don't see this in wind*** ? I run now this patch for two days (Enable automatically TX underrun recovery) http://www.FreeBSD.org/cgi/query-pr.cgi?pr=34236 This patch fixed the problems that all connections got dropped. After have fixed this, I still had the connection problems, but the connections were still active. It looks now that the media selection does not work all the times. If the connection goes away for just a few moments 1/10sec or faster (maybe two times fery fast) the link stays broken even if the connection is there again 100%. If the connection is interrupted more than 5/10sec the link works again. My switch does still show a active link, and ifconfig does show it as active. It looks that some recovery function does not work as expected. How does this have to behave normally. Hardware bug (chip) or software bug ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: intermezzo?
Hello, I have recently come across an old little discussion about InterMezzo. I 've got the impression that it wasn't really welcome to FreeBSD. What is it ? I think he's talking about this one: What is InterMezzo? InterMezzo is a new distributed file system with a focus on high availability. InterMezzo will be suitable for replication of servers, mobile computing, managing system software on large clusters, and for maintenance of high availability clusters. http://www.inter-mezzo.org/ [ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]--- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: intermezzo?
Seva Tonkonoh wrote: I have recently come across an old little discussion about InterMezzo. I 've got the impression that it wasn't really welcome to FreeBSD. It's illegal to distribute a binary FreeBSD distribution with GPL'ed components linked into the kernel because of clause 6 of the GPL. As long as the boot FS is not InterMezzo, and the FS is loaded as a seperately compiled module, there should be no problem with it. I kind of wish they'd LGPL'ed it, or figured some other way to not poison pill the code, but it still seems like it could be used. Just curious if something similar has been done for FreeBSD, or if someone is working on such thing. Sarnoff has done a similar implementation for FreeBSD, called MNFS, which had an integrated distributed cache coherency protocol, and was implemented for FreeBSD circa 1996. The InterMezzo paper suggest that we call te driver that implements this a cache filter driver; standard terminaology says we should call them oplocks (opportunistic locks) or leases. NFSv3 and NFSv4 have these features, in increasing order of integration. They note this in section 3 of their paper, but maintain their use of the callback/filter driver terminology. Maybe they wanted a patent. 8-). InterMezzo also appears to want to disable the local buffer cache, with regard to involvement in open/close (section 4). Since the VM and buffer cache are integrated in FreeBSD, this is not really possible to do. The concentration on open/close time is probably at fault here; you could get the same effect by caching file handles, where a real close lags some time after a close request, so that the open can be reacquired without a probem. IMO, though, this is very much an artifact of the use of Coda, and not a general optimization applicable to a correctly written distributed FS client. Some of the benchmarks are pretty bogus in the writeback caching (section 5). In particular, the mkdir/rmdir benchmark is a bit contrived, compared to real world usage patterns for FS's. I am actually looking for an MS research project topic and Intermezzo seemed to be an interesting possibility. Other suggestions would be also helpful. You could implement this as a stacking VFS module fairly easily, beginning with the NULLFS code. The cache coherency issues in FreeBSD mean that you will be converting get/put page operations into read/write operations in your FS stacking layer (FreeBSD does not properly support stacking of all VOP's, at present), but the performance impact for the microbenchmarks in question should not really affect your FreeBSD numbers (the microbenchmarks that are describd in the paper bear little resemblance to real work, so things that will hurt the performance of real work, won't hurt the results of the microbenchmarks; guess you could say that was a good thing ;^)). The paper also doesn't really apply to FreeBSD; the FFS sync issues that it describes are vs. the NetBSD Coda implementation. The FFS in FreeBSD overcomes most of these issues via Soft Updates. They also could have mounted the FS async in NetBSD, to put it on a par with the speed and reliability of Ext2. All in all, it looks like an interesting thing to play with, and since you aren't going to boot from it, it's not prohibitive in the ability of people to really use the work, like an XFS or JFS GPL'ed FS that you would use as your root/boot FS would be. If you need a proof of concept, then you should block diagram out an implementation, assuming VFS stacking, and see if it can work that way (IMO, it can, bt I don't know how accurately the diagrams in the InterMezzo paper represent the interface encapsulation they imply). The most important consideration in any MS project is whether or not the project is interesting to you, and what you can get out of it (IMO). Whatever you do, do it for yourself, and if it's useful to anyone else, that's just gravy. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: intermezzo?
intermezzo probably is not impossible on freebsd. I worked on the early versions and most of the hard work is done outside the kernel. It would be nice to see it on freebsd. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Report to Sender
Incident Information:- Database: d:/notes/data/mail2.box Originator: hackers [EMAIL PROTECTED] Recipients: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Worm Klez.E immunity Date/Time: 09/06/2002 08:42:26 AM The file attachment BORDER.exe you sent to the recipients listed above was infected with the W32/Klez.h@MM virus and was not successfully cleaned. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: intermezzo?
Ronald G Minnich wrote: intermezzo probably is not impossible on freebsd. I worked on the early versions and most of the hard work is done outside the kernel. It would be nice to see it on freebsd. FWIW, Ron was involved in the MNFS stuff I mentioned earlier. I didn't know that he was involved in InterMezzo, though. Hi, Ron! 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: intermezzo?
On Fri, 6 Sep 2002, Terry Lambert wrote: Sarnoff has done a similar implementation for FreeBSD, called MNFS, which had an integrated distributed cache coherency protocol, and was implemented for FreeBSD circa 1996. goodness, that's me! They're pretty different however. MNFS was for distributed shared memory and was designed to ensure that mmap'ed blocks from the same file remainted consistent across a set of clients. Intermezzo is kind of like coda done right. The intermezzo name refers to the code that layers between the VFS layer of Linux and ext2/3. OPs from the VFS layer can be redirected to user mode from the intermezzo code. I think intermezzo is doable on freebsd, it just takes time. Also, it is a module. Maybe they wanted a patent. 8-). Fortunately Peter Braam doesn't worry about patents :-) Peter was here yesterday and tells us that intermezzo can now run over tmpfs. That's cool, I had done something like that two years ago but it was a bit of work and now it just works fine. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
gigabit NIC of choice?
What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) I'm looking for: - Easy FreeBSD integration. - Reliability. - High performance. Thanks, -Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Gemplus GPR400
It gets even better. It turns out the GPR400 doesn't support IRQ 9. Because IRQ 9 is allocated for the pcic device and muxed, the devices I put in the slot will always be allocated...irq 9. I'm using a Sony Vaio Z600, which has a Ricoh RL5C475 PCI-CardBus Bridge. So this means that pccardd can't actually configure the device. It will die, rather than give me a chance to force it into polling mode. When I try to force the IRQ for pcic0 to IRQ 3 and force ISA interrupt routing from the loader, I get a panic. I've attached the relevant dmesg output. Where do I go from here? Can I hack pccardd in any way to not baulk when it can't match free IRQs with one the card will configure to? BMS Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.6-STABLE #2: Wed Sep 4 18:52:52 BST 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/TRIAGE Calibrating clock(s) ... TSC clock: 794099521 Hz, i8254 clock: 1193190 Hz Timecounter i8254 frequency 1193190 Hz CPU: Pentium III/Pentium III Xeon/Celeron (794.10-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268369920 (262080K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0045d000 - 0x0ffe5fff, 263753728 bytes (64393 pages) avail memory = 256819200 (250800K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f6c10 bios32: Entry = 0xfd890 (c00fd890) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x11e pnpbios: Found PnP BIOS data at 0xc00f6c40 pnpbios: Entry = f:b431 Rev = 1.0 pnpbios: Event flag at 400 Other BIOS signatures found: ACPI: 000f6bb0 Preloaded elf kernel kernel at 0xc0436000. Preloaded elf module splash_pcx.ko at 0xc04360a8. Preloaded elf module vesa.ko at 0xc043614c. Preloaded splash_image_data /boot/splash/emily_black_640.pcx at 0xc04361e8. Preloaded elf module if_wi.ko at 0xc0436248. Preloaded elf module snd_ds1.ko at 0xc04362e8. Preloaded elf module snd_pcm.ko at 0xc0436388. Preloaded elf module uhid.ko at 0xc0436428. Preloaded elf module ums.ko at 0xc04364c4. Preloaded elf module umass.ko at 0xc0436560. Preloaded elf module agp.ko at 0xc0436600. Preloaded elf module nmdm.ko at 0xc043669c. VESA: information block 56 45 53 41 00 02 00 01 00 01 00 00 00 00 22 00 00 01 7f 00 00 01 0b 01 00 01 21 01 00 01 2a 01 00 01 00 01 01 01 10 01 11 01 12 01 03 01 13 01 14 01 15 01 05 01 16 01 17 01 18 01 07 01 19 01 VESA: 40 mode(s) found VESA: v2.0, 8128k memory, flags:0x0, mode table:0xc03c8382 (122) VESA: ATI MACH64 VESA: ATI Technologies Inc. MACH64RM 01.00 Pentium Pro MTRR support enabled Creating DISK md0 md0: Malloc disk Math emulator present splash: image@0xc03c952c, size:110262 splash_pcx: image good: width = 640 height = 480 depth = 8 planes = 1 splash_pcx: considering mode 257: vi_width = 640 vi_height = 480 vi_depth = 8 vi_planes = 1 pcx_splash: selecting mode 257 splash: image decoder found: splash_pcx pci_open(1):mode 1 addr port (0x0cf8) is 0x80003904 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) Using $PIR table, 7 entries at 0xc00fdf50 apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard found- vendor=0x8086, dev=0x7190, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base 4000, size 24 found- vendor=0x8086, dev=0x7191, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 found- vendor=0x8086, dev=0x7110, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base fc90, size 4 found- vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=d, irq=9 map[20]: type 1, range 32, base fca0, size 5 found- vendor=0x8086, dev=0x7113, revid=0x03 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[90]: type 1, range 32, base 1040, size 4 found- vendor=0x104d, dev=0x8039, revid=0x02 class=0c-00-10, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base fedf7000, size 11 map[14]: type 1, range 32, base fedf7c00, size 9 found- vendor=0x1073, dev=0x0010, revid=0x02
Re: gigabit NIC of choice?
On Fri, Sep 06, 2002 at 11:59:05AM -0400, Dan Ellard wrote: ... What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) I'm looking for: - Easy FreeBSD integration. - Reliability. - High performance. i have had good results with the single-port Intel em cards They are reasonably priced too, at least the copper version. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gigabit NIC of choice?
On Fri, 6 Sep 2002, Luigi Rizzo wrote: i have had good results with the single-port Intel em cards They are reasonably priced too, at least the copper version. Thanks for the note. (and thanks for reminding me that I meant to ask about copper! I hope to never deal with fiber again...) -Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gigabit NIC of choice?
Dan Ellard wrote: What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) I'm looking for: - Easy FreeBSD integration. - Reliability. - High performance. The Tigon II has the best performances, but that's because software people rewrote the firmware, instead of hardware engineers moonlighting as programmers. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
I climb the mountain seeking wisdom
Any kind and learned kernel hackers out there who can spare a few cycles to help me along my learning curve? It has been a while (5+ years) since I have done any serious kernel work (SysV environment) and my copy of DI of 4.3BSD is showing its (and my) age. At the moment, the whole area of Bus Resources is causing me greif, my panic rate is about 4 or 5 panics/hour (but I'm sure, with some coaching, I could get that to 7 or 8 :-) RTFM is an acceptable answer if accompanied by refrences, I have already read all the relevant bits I could find in http://www.freebsd.org/docs.html -stacy -- If they keep lowering education standards and raising the price of gasoline, there are going to be a lot of stupid people walking around. Stacy Millions [EMAIL PROTECTED] Millions Consulting Limited To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: I climb the mountain seeking wisdom
On 06-Sep-2002 Stacy Millions wrote: Any kind and learned kernel hackers out there who can spare a few cycles to help me along my learning curve? It has been a while (5+ years) since I have done any serious kernel work (SysV environment) and my copy of DI of 4.3BSD is showing its (and my) age. At the moment, the whole area of Bus Resources is causing me greif, my panic rate is about 4 or 5 panics/hour (but I'm sure, with some coaching, I could get that to 7 or 8 :-) What kind of panics? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Gemplus GPR400
I've booted into Windows (which appears to use ACPI, but I have the BIOS configuring and allocating resources). Windows uses the following for the Cardbus controller: irq 9, db000-dbfff (presumably the memory window with the GPR400 inserted), and 0x3e0-0x3e1 for pcmcia configuration. The GPR400 ends up getting 0x240-0x25F with IRQ *7* under Win2k. Why does the pcic0 device under -STABLE wind up assigning everything 9? Is this a stupid question? Do I get a biscuit? BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gigabit NIC of choice?
Terry Lambert wrote: Dan Ellard wrote: What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) The Tigon II has the best performances, but that's because software people rewrote the firmware, instead of hardware engineers moonlighting as programmers. 8-) 8-). I recall from a while back that gigabit cards have relatively large caches on them, correct? How does the size of the cache impact performance, and what is considered a sufficient cache size? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I climb the mountain seeking wisdom
John Baldwin wrote: On 06-Sep-2002 Stacy Millions wrote: At the moment, the whole area of Bus Resources is causing me greif, my panic rate is about 4 or 5 panics/hour (but I'm sure, with some coaching, I could get that to 7 or 8 :-) What kind of panics? Page fault while in kernel mode unfortunately, ddb hangs so I don't get a core file. -stacy -- If they keep lowering education standards and raising the price of gasoline, there are going to be a lot of stupid people walking around. Stacy Millions [EMAIL PROTECTED] Millions Consulting Limited To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
interrupting the remote kernel
Hello, I have BREAK_TO_DEBUGGER, DDB and no DDB_UNATTENDED on the target kernel and remotebreak = 1 on the remote gdb. So I'm expecting pressing ctl-C in the remote gdb should interrupt the remote kernel as if it had encountered a breakpoint. Is my expectation right? Nothing happens when pressing ctl-C once. Pressing it twice just gives me the option to detach gdb. How can I interrupt the remote kernel without breakpoints? I'm trying to locate kernel hangings. Is it possible with this approach? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gigabit NIC of choice?
Darren Pilgrim wrote: Terry Lambert wrote: Dan Ellard wrote: What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) The Tigon II has the best performances, but that's because software people rewrote the firmware, instead of hardware engineers moonlighting as programmers. 8-) 8-). I recall from a while back that gigabit cards have relatively large caches on them, correct? How does the size of the cache impact performance, and what is considered a sufficient cache size? The best advice I have for you is to read the source code for the drivers, specifically any commentary by Bill Paul up top; he tells it like it is, with regard to the hardware. In general, cards with DMA engines that require better than two byte alignment require that the mbufs be copied again for transmit. Also, in general, the more queue descriptors, the better, since they limit the number of packets pending input or output that you can have outstanding simultaneously. Controllers that can't do scatter/gather are also problematic, because they mean you have to allocate a seperate buffer area out of memory and copy outbound data into thue buffer instead of scattering, and copy from the buffer to mbufs on the receive (gather). The smaller the amount of memory on the card, the worse things are, as well, because it limits the amount of data you can have outstanding, as well, which limits your throuput. Bad cards are also not capable of software interrupt coelescing (this was one of my contributions). Basically, what this means is that a card will not DMA, or does not have a modified register, or does not update it, while an interuppt is being processed (e.g. after the interrupt is raised in hardware, and has not yet been ACKed). The effect of this is that you can't poll at the end of the interrupt handler for new data, only exitting the handler when there is no new data to process (10 to 15% performance inmprovement, by my benchmarks). Bad cards will also have smaller on-chip buffers (as opposed to on-card buffers). For example, there are a number of cards that supposedly support both jumbograms and TCP checksum offloading, but have only 8K of space. A jumbogram is 9K, so when using jumbograms, it's impossible to offload checksums to the hardware. There are cards that supposedly support checksumming, but use the buggy incremental checksum update algorithm (two's complement vs. one's complement arithmatic), and will screw up the TCP checksum, yielding 0xfffe instead of 0x after summing, because they don't correctly handle negative zero (there is an RFC update on this). A really good card will allow you to align card buffers to host page boundaries, which can dignificantly speed up I/O. This is what I was referring to when I said there was a rewritten firmware for the Tigon II. The manufacturer won't reall share sufficient information for this interface to be implemented on the Tigon III. Basically, it eliminates another copy. The absolute worst one (according to Bill Paul) is the RealTek 8129/8139. See the comments in /usr/src/sys/pci/if_rl.c. Mostly, if you go by the comments in the drivers, you'll get a feel for what's done right and what's done wrong from a host interface perspective by the card manufacturer. As to your cache question... the size of the cache is the pool size. If you look at this as a queueing theory problem, then amount of buffer space translates directly into how much it's willing to tolerate delays in servicing interrupts -- pool retention time. Above a certain size, and it really won't effect your ability to shove data through it because there will be more and more free space available. Unless you are going card-to-card (unlikely; most firmware doesn't support the necessary ability to do incremental header rewriting, and flow monitoring, so that you can mark flows without in-band data that needs to be rewritten e.g. text IP addresses in FTP port commands, etc.), you will always end up with a certain amount of buffer space free, because the limiting factor is going to be your ability to shovel data over the PCI bus from the disk to main memory and back over the same bus to the network card. So my flip answer seems flip, but to get the best overall performance, you should use a Tigon II with the FreeBSD specific firmware, and the zero copy TCP patches that need the firmware patches. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gigabit NIC of choice?
Terry Lambert wrote: The Tigon II has the best performances, but that's because software people rewrote the firmware, instead of hardware engineers moonlighting as programmers. 8-) 8-). References: http://people.freebsd.org/~ken/zero_copy/ -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interrupting the remote kernel
hit CTL_ALT_ESC on it's keyboard... or do: sysctl debug.enter_debugger=gdb On Fri, 6 Sep 2002, Hanspeter Roth wrote: Hello, I have BREAK_TO_DEBUGGER, DDB and no DDB_UNATTENDED on the target kernel and remotebreak = 1 on the remote gdb. So I'm expecting pressing ctl-C in the remote gdb should interrupt the remote kernel as if it had encountered a breakpoint. Is my expectation right? Nothing happens when pressing ctl-C once. Pressing it twice just gives me the option to detach gdb. How can I interrupt the remote kernel without breakpoints? I'm trying to locate kernel hangings. Is it possible with this approach? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gigabit NIC of choice?
Thank you! It was fun to watch questions come up and get shot down while reading the same email. Now if you'll excuse me, I need to go use the source, Terry. Terry Lambert wrote: Darren Pilgrim wrote: Terry Lambert wrote: Dan Ellard wrote: What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) The Tigon II has the best performances, but that's because software people rewrote the firmware, instead of hardware engineers moonlighting as programmers. 8-) 8-). I recall from a while back that gigabit cards have relatively large caches on them, correct? How does the size of the cache impact performance, and what is considered a sufficient cache size? The best advice I have for you is to read the source code for the drivers, specifically any commentary by Bill Paul up top; he tells it like it is, with regard to the hardware. long explaination snipped To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gigabit NIC of choice?
On Fri, Sep 06, 2002 at 10:32:12 -0700, Terry Lambert wrote: Dan Ellard wrote: What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) I'm looking for: - Easy FreeBSD integration. - Reliability. - High performance. The Tigon II has the best performances, but that's because software people rewrote the firmware, instead of hardware engineers moonlighting as programmers. 8-) 8-). You'll get good performance with the Tigon II with jumbo frames under -current with ZERO_COPY_SOCKETS and TI_JUMBO_HDRSPLIT turned on. Note that good performance == lower CPU utilization here, although it is difficult to see any improvement in -current with SMP enabled, and the improvement isn't as large in UP mode as it used to be. You can easily get wire rates with jumbo frames with a Tigon II without zero copy, given a reasonably fast machine. (At least on -stable. Reasonably fast == 1GHz Pentium III, 64 bit PCI.) With 1500 byte frames, though, the Tigon II won't perform as well as some other controllers. For most folks, performance with 1500 byte frames is what matters, since you usually need a jumbo-capable gigabit switch to take advantage of jumbo frames in anything more than a point to point environment. The modifications I made to the Tigon firmware (the ones that are in FreeBSD) are actually relatively minor. The main trick is to make sure that the header is in its own scatter/gather element, so the payload will be page aligned. (Assuming the second and subsequent scatter/gather elements are page aligned.) So if your workload consists of jumbo frames for the most part, and receive performance is important, I would suggest a Tigon II-based board, like the GA620T, if you can find one. (Obviously that's getting more and more difficult nowadays.) Otherwise, I would suggest another card with better performance with 1500 byte frames. (I haven't done any tests with other boards, so I can't make specific recommendations.) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interrupting the remote kernel
On Sep 06 at 12:11, Julian Elischer spoke: hit CTL_ALT_ESC on it's keyboard... Doing this on the remote host (running gdb) tells me `No debugger in kernel'. Doing this on the target host passes control to the remote gdb. But I want to pass control to the remote debugger by issuing the interrupt command on the _remote_ host (in gdb). or do: sysctl debug.enter_debugger=gdb Doing this on the target host also passes control to the remote gdb. But I want to be able to pass control to the debugger when the target kernel `hangs', that is when no `ctl-alt-f1', `ctl-alt-del' has any effect. I thought that remotebreak on the remote gdb should allow me this. But it seems to be something else... -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Tue, Aug 06, 2002 at 06:55:11PM -0700, Peter Wemm wrote:
`-mcpu=CPU-TYPE'
Tune to CPU-TYPE everything applicable about the generated code,
except for the ABI and the set of available instructions. The
choices for CPU-TYPE are `i386', `i486', `i586', `i686',
`pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3',
`pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird',
`athlon-4', `athlon-xp' and `athlon-mp'.
You can also add -msse, -msse2, -m3dnow to use those extensions. It would
appear that our bsd.cpu.mk file is out of date and is missing the newer
cpu types.
How about the following patch (I've only tested 'pentium3'):
Index: share/mk/bsd.cpu.mk
===
RCS file: /usr/home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.16
diff -u -r1.16 bsd.cpu.mk
--- share/mk/bsd.cpu.mk 2 Aug 2002 18:04:22 - 1.16
+++ share/mk/bsd.cpu.mk 6 Sep 2002 20:25:46 -
-28,8 +28,8
CPUTYPE = i686
. elif ${CPUTYPE} == pentium
CPUTYPE = i586
-. elif ${CPUTYPE} == athlon
-CPUTYPE = k7
+. elif ${CPUTYPE} == k7
+CPUTYPE = athlon
. endif
. endif
-42,20 +42,30
# http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == athlon-mp
+_CPUCFLAGS = -march=athlon-mp
+. elif ${CPUTYPE} == athlon-xp
+_CPUCFLAGS = -march=athlon-xp
+. elif ${CPUTYPE} == athlon-4
+_CPUCFLAGS = -march=athlon-4
+. elif ${CPUTYPE} == athlon-tbird
+_CPUCFLAGS = -march=athlon-tbird
+. elif ${CPUTYPE} == athlon
_CPUCFLAGS = -march=athlon
+. elif ${CPUTYPE} == k6-3
+_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == k6-2
-_CPUCFLAGS = -march=k6
+_CPUCFLAGS = -march=k6-2
. elif ${CPUTYPE} == k6
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == k5
_CPUCFLAGS = -march=pentium
. elif ${CPUTYPE} == p4
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium4
. elif ${CPUTYPE} == p3
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium3
. elif ${CPUTYPE} == p2
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium2
. elif ${CPUTYPE} == i686
_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == i586/mmx
Index: share/examples/etc/make.conf
===
RCS file: /usr/home/ncvs/src/share/examples/etc/make.conf,v
retrieving revision 1.198
diff -u -r1.198 make.conf
--- share/examples/etc/make.conf2 Aug 2002 18:04:22 - 1.198
+++ share/examples/etc/make.conf6 Sep 2002 20:25:19 -
-24,7 +24,7
# NO_CPU_CFLAGS variable below.
# Currently the following CPU types are recognized:
# Intel x86 architecture:
-# (AMD CPUs) k7 k6-2 k6 k5
+# (AMD CPUs) athlon-mp athlon-xp athlon-4 athlon-tbird athlon k6-3 k6-2 k6
+k5
# (Intel CPUs) p4 p3 p2 i686 i586/mmx i586 i486 i386
# Alpha/AXP architecture: ev6 pca56 ev56 ev5 ev45 ev4
# Intel ia64 architecture: itanium
msg36772/pgp0.pgp
Description: PGP signature
Excessive swap usage w/ 4.6
After having moved servers from 4.3 and 4.5 to 4.6, we are noticing that swap indicates much higher usage. Today, one of our squid cache servers hit (and stayed at) 50% swap utilization so I decided to do some digging. This machine has 512 MB physical RAM in it and is running FreeBSD 4.5-RELEASE-p7 Here's a ps with some cruft removed and columns widened for readability. ps -axel CPU PRI NIVSZRSS WCHAN STAT TT TIME COMMAND 0 -18 0 0 0 sched DLs ??0:00.00 (swapper) 0 10 0544116 wait ILs ??0:00.31 /sbin/init -- 0 -18 0 0 0 psleep DL??5:30.16 (pagedaemon) 0 18 0 0 0 psleep DL??0:00.04 (vmdaemon) 0 -18 0 0 0 psleep DL??0:33.61 (bufdaemon) 0 -2 0 0 0 vlruwt DL??0:29.52 (vnlru) 0 18 0 0 0 syncer DL?? 29:36.89 (syncer) 0 2 0948340 select Ss??0:15.27 /usr/sbin/syslogd -s 0 2 0 1300352 select Ss??3:52.69 ntpd -p /var/run/ntpd.pid 0 2 0 1064560 select Is??0:00.18 /usr/sbin/inetd -wW 0 10 0984216 nanslp Is??0:15.08 /usr/sbin/cron 28 2 0 2136264 select Is??3:00.12 /usr/local/sbin/sshd 0 10 0 2940 0 wait IWs ??0:00.00 () /usr/local/sbin/squid 4 2 0 398380 381916 poll S ?? 286:58.56 (squid) (squid) 0 -6 0860176 piperd Ss??1:35.35 (unlinkd) (unlinkd) 0 2 0 4792512 select Ss??0:01.48 sshd: 0 2 0 2732 1920 select Ss??0:02.73 /usr/local/sbin/gated 0 2 0 2096 1464 select Ss??0:00.08 /usr/local/sbin/httpd 0 2 0 2504 1660 accept I ??0:00.01 /usr/local/sbin/httpd 0 2 0 2512 1668 accept I ??0:00.01 /usr/local/sbin/httpd 0 18 0 1584820 pause Ssp00:00.51 SSH_CLIENT= 0 28 0416172 - R+p00:00.00 SSH_CLIENT= 0 3 0948528 ttyin Is+ v00:00.00 /usr/libexec/getty Pc ttyv0 0 3 0948524 ttyin Is+ v10:00.00 /usr/libexec/getty Pc ttyv1 === === Totals427,688 393,208 -393,208 === 34,480 So, swap usage should be about this much. But: pstat -s Device 1K-blocks UsedAvail Capacity Type /dev/ad0s1b614272 304792 30948050%Interleaved This seems very excessive as well as unjustified. Is there some way I can find out if I have a swap leak or some other way to figure out what is going on? As I mentioned, we noticed a significant increase in swap usage on many servers between 4.3 or 4.5 and 4.6 /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
In the last episode (Sep 06), Kris Kennaway said: How about the following patch (I've only tested 'pentium3'): Index: share/mk/bsd.cpu.mk I've been using a similar patch ever since 3.* went into the tree with no problems. Haven't benchmarked the difference between pentiumpro and the other options, either, though. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interrupting the remote kernel
On Fri, 6 Sep 2002, Hanspeter Roth wrote: On Sep 06 at 12:11, Julian Elischer spoke: hit CTL_ALT_ESC on it's keyboard... Doing this on the remote host (running gdb) tells me `No debugger in kernel'. Doing this on the target host passes control to the remote gdb. Like it should. Julian's suggestions were both for the target host. But I want to pass control to the remote debugger by issuing the interrupt command on the _remote_ host (in gdb). You can do this by connecting a second serial cable for a console between your host and target or by using the remotechat option and a single cable. Once you have the serial console, option ALT_BREAK_TO_DEBUGGER allows you to initiate a break using your terminal emulator's send break command. But I want to be able to pass control to the debugger when the target kernel `hangs', that is when no `ctl-alt-f1', `ctl-alt-del' has any effect. If the hang is not a system hang, the console break will have an effect. But if the kernel is so hung that the keyboard doesn't work, the remote serial console will not do you any better. In this case you need a box with a real console (i.e. Sun). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New scsi_target code
On Thu, 5 Sep 2002, Bruce M Simpson wrote: On Thu, Sep 05, 2002 at 01:54:08AM -0700, Nate Lawson wrote: I have rewritten the scsi_target driver and usermode client with a much simpler model suggested by Justin Gibbs. The kernel driver receives This sounds like excellent work and I can't wait to check it out further. Whilst looking into the problem of USB-ATA bridge support I was recently faced with the problem of writing various ATA-SCSI command translations, which involved emulating a SCSI device, so I imagine your code should be very useful. Possibly. I have updated the version online with a patch for -current. It builds and runs but panics in read/write. I'll look into the issues with -current over the weekend. I'm very interested in comments and testing on -stable to help update the general architecture and stability. Thanks, -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
NEWCARD in -STABLE
I had a thought. Perhaps this situation makes me an ideal candidate for being a guinea pig for NEWCARD in -STABLE? Just a thought. If you have diffs, bring it on. If things require a bit more work, I am more than willing to give a hand (not ready to take this lying down, I got myself the equipment as a challenge). BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
Kris Kennaway wrote:
On Tue, Aug 06, 2002 at 06:55:11PM -0700, Peter Wemm wrote:
`-mcpu=CPU-TYPE'
Tune to CPU-TYPE everything applicable about the generated code,
except for the ABI and the set of available instructions. The
choices for CPU-TYPE are `i386', `i486', `i586', `i686',
`pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3',
`pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird',
`athlon-4', `athlon-xp' and `athlon-mp'.
You can also add -msse, -msse2, -m3dnow to use those extensions. It would
appear that our bsd.cpu.mk file is out of date and is missing the newer
cpu types.
How about the following patch (I've only tested 'pentium3'):
[patch ripped]
I've got a very similar patch which I believe to be a bit more complete
because it also updates the MACHINE_CPU variable which lists the
features available on a particular CPU. I attach it to this mail.
Cheers,
Maxime
Index: bsd.cpu.mk
===
RCS file: /space2/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.16
diff -u -p -r1.16 bsd.cpu.mk
--- bsd.cpu.mk 2 Aug 2002 18:04:22 - 1.16
+++ bsd.cpu.mk 11 Aug 2002 18:46:06 -
-28,8 +28,8 CPUTYPE = ultrasparc
CPUTYPE = i686
. elif ${CPUTYPE} == pentium
CPUTYPE = i586
-. elif ${CPUTYPE} == athlon
-CPUTYPE = k7
+. elif ${CPUTYPE} == k7
+CPUTYPE = athlon
. endif
. endif
-42,20 +42,30 CPUTYPE = k7
# http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == athlon-mp
+_CPUCFLAGS = -march=athlon-mp
+. elif ${CPUTYPE} == athlon-xp
+_CPUCFLAGS = -march=athlon-xp
+. elif ${CPUTYPE} == athlon-4
+_CPUCFLAGS = -march=athlon-4
+. elif ${CPUTYPE} == athlon-tbird
+_CPUCFLAGS = -march=athlon-tbird
+. elif ${CPUTYPE} == athlon
_CPUCFLAGS = -march=athlon
+. elif ${CPUTYPE} == k6-3
+_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == k6-2
-_CPUCFLAGS = -march=k6
+_CPUCFLAGS = -march=k6-2
. elif ${CPUTYPE} == k6
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == k5
_CPUCFLAGS = -march=pentium
. elif ${CPUTYPE} == p4
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium4
. elif ${CPUTYPE} == p3
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium3
. elif ${CPUTYPE} == p2
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium2
. elif ${CPUTYPE} == i686
_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == i586/mmx
-93,8 +103,18 CFLAGS += ${_CPUCFLAGS}
# presence of a CPU feature.
.if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == athlon-mp
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-xp
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-4
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-tbird
+MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon
MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == k6-3
+MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6-2
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: I've got a very similar patch which I believe to be a bit more complete because it also updates the MACHINE_CPU variable which lists the features available on a particular CPU. I attach it to this mail. Oops, I forgot that part. How about sse2 though? Kris msg36779/pgp0.pgp Description: PGP signature
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
Kris Kennaway wrote:
On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote:
I've got a very similar patch which I believe to be a bit more complete
because it also updates the MACHINE_CPU variable which lists the
features available on a particular CPU. I attach it to this mail.
Oops, I forgot that part. How about sse2 though?
Forgot that one. Here is an updated patch. I'm quite sure that on the
Intel side, only the pentium 4 have sse2, but I don't know if any AMD
chip supports it yet. The attached patch only adds it for p4's.
Cheers,
Maxime
Index: bsd.cpu.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.16
diff -u -p -r1.16 bsd.cpu.mk
--- bsd.cpu.mk 2 Aug 2002 18:04:22 - 1.16
+++ bsd.cpu.mk 7 Sep 2002 01:05:43 -
-28,8 +28,8 CPUTYPE = ultrasparc
CPUTYPE = i686
. elif ${CPUTYPE} == pentium
CPUTYPE = i586
-. elif ${CPUTYPE} == athlon
-CPUTYPE = k7
+. elif ${CPUTYPE} == k7
+CPUTYPE = athlon
. endif
. endif
-42,20 +42,30 CPUTYPE = k7
# http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == athlon-mp
+_CPUCFLAGS = -march=athlon-mp
+. elif ${CPUTYPE} == athlon-xp
+_CPUCFLAGS = -march=athlon-xp
+. elif ${CPUTYPE} == athlon-4
+_CPUCFLAGS = -march=athlon-4
+. elif ${CPUTYPE} == athlon-tbird
+_CPUCFLAGS = -march=athlon-tbird
+. elif ${CPUTYPE} == athlon
_CPUCFLAGS = -march=athlon
+. elif ${CPUTYPE} == k6-3
+_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == k6-2
-_CPUCFLAGS = -march=k6
+_CPUCFLAGS = -march=k6-2
. elif ${CPUTYPE} == k6
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == k5
_CPUCFLAGS = -march=pentium
. elif ${CPUTYPE} == p4
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium4
. elif ${CPUTYPE} == p3
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium3
. elif ${CPUTYPE} == p2
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium2
. elif ${CPUTYPE} == i686
_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == i586/mmx
-93,8 +103,18 CFLAGS += ${_CPUCFLAGS}
# presence of a CPU feature.
.if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == athlon-mp
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-xp
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-4
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-tbird
MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon
+MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == k6-3
+MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6-2
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6
-102,7 +122,7 MACHINE_CPU = mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k5
MACHINE_CPU = k5 i586 i486 i386
. elif ${CPUTYPE} == p4
-MACHINE_CPU = sse i686 mmx i586 i486 i386
+MACHINE_CPU = sse2 sse i686 mmx i586 i486 i386
. elif ${CPUTYPE} == p3
MACHINE_CPU = sse i686 mmx i586 i486 i386
. elif ${CPUTYPE} == p2
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Fri, Sep 06, 2002 at 06:08:23PM -0700, Maxime Henrion wrote: Kris Kennaway wrote: On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: I've got a very similar patch which I believe to be a bit more complete because it also updates the MACHINE_CPU variable which lists the features available on a particular CPU. I attach it to this mail. Oops, I forgot that part. How about sse2 though? Forgot that one. Here is an updated patch. I'm quite sure that on the Intel side, only the pentium 4 have sse2, but I don't know if any AMD chip supports it yet. The attached patch only adds it for p4's. Looks good to me! Kris msg36781/pgp0.pgp Description: PGP signature
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
Maxime Henrion wrote: Kris Kennaway wrote: On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: I've got a very similar patch which I believe to be a bit more complete because it also updates the MACHINE_CPU variable which lists the features available on a particular CPU. I attach it to this mail. Oops, I forgot that part. How about sse2 though? Forgot that one. Here is an updated patch. I'm quite sure that on the Intel side, only the pentium 4 have sse2, but I don't know if any AMD chip supports it yet. The attached patch only adds it for p4's. Both of the Hammer cpus support SSE2 FWIW. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCMCIA questions: mapping attribute and common memory?
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : Thanks for your informative response. Sure. Sorry for the long delay on this one. I wanted to give a good answer rather than a fast one. : On Thu, Sep 05, 2002 at 02:59:36PM -0600, M. Warner Losh wrote: : You generally don't map attribute memory. With one exception (the : raylan cards), there's no hardware in the attribute memory section and : it is just used to store the cis. : ... : [ray(4) and xe(4)] : Those are the two worst ones to look at. Don't do what they do, as : the ray(4) hardware is weird and the xe(4) driver was written before : we could read the cis from the kernel. : : The particular device I'm working with is the Gemplus GPR400 PCMCIA : Smart Card Reader. It has hardware registers in the attribute memory. Yuck! Fortunately, I've been sensitized to it by the raylink driver. : One of these registers tells me when a card is inserted/ejected, and : there are also some bits in that space which are used to handle : suspending and resuming the card. ok. : What's the best way for me to do this, whilst being OLDCARD and NEWCARD : compatible? (And just out of interest, is it possible to read the CIS : from the kernel easily whilst still being OLDCARD friendly?) Do you need to read the CIS directly? Or do you just need to map the attribute memory to access well known locationss? The answer isn't much different, and I'll get into that below. : : If so, how do I get at the resource? : : If not, how would I go about doing this myself in the driver? : : bus_alloc_resource() : : Ok. Say I have my first two tuples and they look like this:- : : Tuple #1, code = 0x1 (Common memory descriptor), length = 3 : 000: d4 00 ff : Common memory device information: : Device number 1, type Function specific, WPS = OFF : Speed = 100nS, Memory block size = 512b, 1 units : : Tuple #2, code = 0x17 (Attribute memory descriptor), length = 3 : 000: 64 10 ff : Attribute memory device information: : Device number 1, type SRAM, WPS = OFF : Speed = 100nS, Memory block size = 512b, 3 units : : How will these blocks be mapped when I allocate the resource? They are memory mapped devices. : Are they : coalesced into a single memory map in the order in which they appear in the : CIS? Thing is, 2KB is 0x800 hex, and the register addresses I see in this : Linux code I'm porting all start at 0xFA0. This would seem to indicate : that a 2KB memory window is needed. [(3+1)*512]. The Linux code asks for a : window size of 0x1000, which is 4KB, yet the comment says it's asking for : 2KB. Bizarre. Linux code tends to say one thing and do another often. :-) : Once I've allocated the window as a resource, how would I go about accessing : that memory directly? Would I need to establish a page mapping? OK. Lemme talk with code (which I've grabbed from ray_res_alloc_am) sc-am_rid = RAY_AM_RID; sc-am_res = bus_alloc_resource(sc-dev, SYS_RES_MEMORY, sc-am_rid, 0UL, ~0UL, 0x1000, RF_ACTIVE); error = CARD_SET_MEMORY_OFFSET(device_get_parent(sc-dev), sc-dev, sc-am_rid, 0, NULL); error = CARD_SET_RES_FLAGS(device_get_parent(sc-dev), sc-dev, SYS_RES_MEMORY, sc-am_rid, PCCARD_A_MEM_ATTR); error = CARD_SET_RES_FLAGS(device_get_parent(sc-dev), sc-dev, SYS_RES_MEMORY, sc-am_rid, PCCARD_A_MEM_8BIT); (I'm not sure why the ray driver doesn't combine the last two calls). The rid is 3. pccardd abuses window 0 (and the comments in the ray driver say 1 also, which may be possible). We really should use window 4 for the CIS, but that's too big a change (and would break support for media chipsets, which have only one memory map, but those are only on early pc98 laptops). Anyway, you pick the window that you want to use. You the map it. To manage where in the memory you'd like to map it, you set the offset. To make it the attribute memory, we set the resoruce flags. Ditto with 8 bit. Allocating the common memory would be similar. In the ray driver, it uses rid 0 for the common memory so it can get the size of the memory. So that code looks like: u_long start, count, end; sc-cm_rid = RAY_CM_RID; start = bus_get_resource_start(sc-dev, SYS_RES_MEMORY, sc-cm_rid); count = bus_get_resource_count(sc-dev, SYS_RES_MEMORY, sc-cm_rid); end = start + count - 1; sc-cm_res = bus_alloc_resource(sc-dev, SYS_RES_MEMORY, sc-cm_rid, start, end, count, RF_ACTIVE); error = CARD_SET_MEMORY_OFFSET(device_get_parent(sc-dev), sc-dev, sc-cm_rid, 0, NULL); error = CARD_SET_RES_FLAGS(device_get_parent(sc-dev), sc-dev, SYS_RES_MEMORY, sc-cm_rid, PCCARD_A_MEM_COM); error = CARD_SET_RES_FLAGS(device_get_parent(sc-dev), sc-dev, SYS_RES_MEMORY, sc-cm_rid,
