Backup/restore of bootable w2k fat32 part from freebsd
Hi, are there experiences with backup/restore of an bootable w2k partition from within FreeBSD? I've seen `newfs_msdos -B`, but how to extract the w2k bootblock (dd?) ? Is it sufficient to get an bootable partition? Thanks! Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
fsck -p
Hi! Today I've got a hard lockup with 4.7 box. Upon reboot, ``fsck -p'' was run, and it resulted in the following, in particular: /dev/da0s1h: UNREF FILE I=591 OWNER=nobody MODE=100644 /dev/da0s1h: SIZE=81269024 MTIME=Nov 20 09:50 2002 (CLEARED) /dev/da0s1h: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/da0s1h: SUMMARY INFORMATION BAD (SALVAGED) /dev/da0s1h: BLK(S) MISSING IN BIT MAPS (SALVAGED) I thought that the correct action here would be to reconnect this file under fs's lost+found, but it did not happen. Why? (I've lost a week of useful squid's access.log.) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38206/pgp0.pgp Description: PGP signature
PLS GET BACK TO ME.
DEAR FRIEND, THIS LETTER MAY COME TO YOU AS A SURPRISE DUE TO THE FACT THAT WE HAVE NOT YET MET. THE MESSAGE COULD BE STRANGE BUT REAL IF YOU PAY SOME ATTENTION TO IT. I COULD HAVE NOTIFIED YOU ABOUT IT AT LEAST FOR THE SAKE OF YOUR INTEGRITY. PLEASE ACCEPT MY SINCERE APOLOGIES. IN BRINGING THIS MESSAGE OF GOODWILL TO YOU, I HAVE TO SAY THAT I HAVE NO INTENTIONS OF CAUSING YOU ANY PAINS. I AM MRS. SANDRA SAVIMBI, DAUGHTER OF THE LATE REBEL LEADER JONAS SAVIMBI OF ANGOLA WHO WAS KILLED ON THE 22ND OF FEBUARY 2002 . MY LATE FATHER, JONAS SAVIMBI WAS ABLE TO DEPOSIT A LARGE SUM OF MONEY IN DIFFERENT BANKS IN EUROPE AND THE MOVEMENT OF HIS FAMILY MEMBERS (INCLUDING ME) IS RESTRICTED. WE ARE FORBIDDEN TO EITHER TRAVEL ABROAD OR OUT OF OUR LOCALITIES. PRESENTLY, THE US$8,500,000.00 EIGHT MILLION, FIVE HUNDRED THOUSAND DOLLARS MY FATHER TRANSFERRED TO NETHERLANDS IS SAFE AND IS WITH A SECURITY FIRM. I AM THEREFORE SOLICITING YOUR HELP TO HAVE THIS MONEY TRANSFERRED INTO YOUR ACCOUNT BEFORE MY GOVERNMENT GET WIND OF THIS FUND. YOU MAY KNOW THAT MY FATHER WAS A REBEL LEADER IN ANGOLA BEFORE HIS DEATH AND MY REASON FOR DOING THIS IS BECAUSE IT WILL BE DIFFICULT FOR THE ANGOLAN GOVERNMENT TO TRACE MY FATHER'S MONEY TO AN INDIVIDUAL'S ACCOUNT, ESPECIALLY WHEN SUCH AN INDIVIDUAL HAS NO RELATIONSHIP WITH MY FATHER THEREBY KEEPING THAT MONEY FOR MY FAMILY USE. AT PRESENT THE MONEY AS I SAID IS KEPT IN A SECURITY COMPANY IN THE NETHERLAND. I AM CURRENTLY AND TEMPORARILY LIVING IN ANGOLA WITH MY HUSBAND. MY BROTHER HAS A REFUGEE STATUS IN THE NETHERLANDS. MOREOVER, THE POLITICAL CLIMATE IN ANGOLA AT THE MOMENT IS SO SENSITIVE AND UNSTABLE SO IT WILL BE BETTER WE DO THIS TRANSACTION NOW. WITH THIS PASSWORD AND INFORMATION I WILL SEND YOU, AND THE CHANGE OF OWNERSHIP THAT I WILL SEND TO THE SECURITY FIRM, YOU WILL BE ABLE TO REPRESENT US IN THE NETHERLANDS TO CLAIM THIS CONSIGNMENT FROM THE SECURITY FIRM. WHEN YOU ARE READY, I WILL GIVE YOU THE INFORMATION NEEDED BEFORE YOU CAN GET ACCESS TO THE FUND, YOU WILL THEN PROCEED TO NETHERLANDS WHERE YOU WILL SIGN THE FINAL RELEASE DOCUMENTS OF THE US$8,500,000.00 EIGHT, MILLION, FIVE HUNDRED THOUSAND DOLLARS. I WILL GIVE YOU FURTHER DETAILS WHEN I GET YOUR RESPONSE TO THIS LETTER ASSURING US THAT YOU WILL BE ABLE TO REPRESENT US IN THE NETHERLANDS AND THAT YOU WILL MAKE THIS TRANSACTION CONFIDENTIAL. IT IS VERY IMPORTANT THAT YOU GIVE ME YOUR PHONE AND FAX NUMBERS WHILE THIS IS KEPT CONFIDENTIAL. YOU CAN CONTACT ME WITH MY E-MAIL ADDRESS, [EMAIL PROTECTED] YOU CAN ALSO SEND A COPY TO MY BROTHER WHO IS SEEKING ASSYLUM IN THE NETHERLANDS ON;[EMAIL PROTECTED] YOURS SINCERELY, SANDRA SAVIMBI. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraph couldbe a router also)
[EMAIL PROTECTED] wrote: Hiten Pandya wrote: On Tue, Nov 19, 2002 at 02:32:00PM -0800, Terry Lambert wrote the words in effect of: I asked that someone with an if_ti test it first, and report back to me. As far as I know, no one has tested it yet, or if they have, they're not talking. I don't personally own an if_ti at this point. Right. Seriously. I don't own one. [double take] toneofvoice=play nicely boys I don't think Hiten was questioning that. Rather he was acknowledging your statement. Oh, right. may have conveyed his meaning a little better. /toneofvoice ttfn, Tony To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Playing with Current.
On 20-Nov-2002 Ryan Sommers wrote: First off I wasn't sure which list to send this to: current, hackers or questions; so if this is the wrong destination my apologies. Anyway, last year, after years of using Linux, I fell in love with the FreeBSD project. Now, I've had the desire offer my time and energy to help development. My problem though is I only have 3 machines where I'm currently living, 2 desktops and a laptop. I have to leave Windows installed on one desktop for compatibility and I'd like to leave the other desktop running 4.x so I have a UNIX computer that I know will always be working. That leaves me with the laptop to play with 5.0 and CURRENT. However, the laptop is a puny Cyrix P180+ (I think it's the MediaGX chip or whatever they were touting a few years back). Doing a make world or building a kernel would probably take me two weeks, not the best environment for development. My question is could I keep and build the CURRENT source tree on the FreeBSD desktop, mount it over NFS to the laptop, and install it over the NFS mount? I know I can do that with 4.x, but I'm wondering if this is really testing CURRENT if I don't build it on the 5.0 kernel. For now I really don't think I'll be able to help much with writing anything too intense; however I noticed in the latest 5.0 release notes that people have been converting Perl scripts to C and I'm more then capable of doing that. And I also think the laptop, even though it is slow would be a usable platform for working on that kind of development. This should work fine (doing installworld over NFS). You might want to do the initial install on the laptop using a CD or floppies to install DP2 however. What are your thoughts on this setup; is it worth my time or should I just sit idly by until I can get a desktop system to play with CURRENT. I have a little free time and about 7 years experience programming C in Linux and UNIX (peanuts compared to most people reading this I imagine) but I'd like to help a cause I believe in. Just using 5.0 will help find some bugs I'm sure. :) -- 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: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraphcouldbe a router also)
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hiten Pandya wrote: On Tue, Nov 19, 2002 at 02:32:00PM -0800, Terry Lambert wrote the words in effect of: I asked that someone with an if_ti test it first, and report back to me. As far as I know, no one has tested it yet, or if they have, they're not talking. I don't personally own an if_ti at this point. Right. Seriously. I don't own one. [double take] toneofvoice=play nicely boys I don't think Hiten was questioning that. Rather he was acknowledging your statement. Oh, right. may have conveyed his meaning a little better. /toneofvoice ttfn, Tony Hehe. I was not being sarcastic. I just acknoledged your statement. The reason I asked about committing the patch in the first place, is because I thought that the patch had been around on the -net@ list, and had been reviewed. My apologies. -- Hiten [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraphcouldbe a router also)
Hiten Pandya wrote: Hehe. I was not being sarcastic. I just acknoledged your statement. The reason I asked about committing the patch in the first place, is because I thought that the patch had been around on the -net@ list, and had been reviewed. My apologies. It's been around on the list for a while, but if it's working for the people involved, they are not saying anything. Last I heard, the person who had the problem had tried the Intel Gigabit card, but not the Tigon III, but was looking for a Gigabit card recommendation. I suppose I could make the same patch for the Intel card. The problem is that DEVICE_POLLING is an all-or-nothing thing, you can't control it on a card-by-card basis, even with a sysctl, because it fills out an entry point that's statically, rather than procedurally initialized. Basically, that means that the worst case, you could not turn it on for cards that are known to work, if the patch fails to work for the Tigon III. If someone with a Tigon III card could try the patch with the DEVICE_POLLING option enabled, and device polling turned on, and let us know that the card keeps functioning, rather than them getting a panic, then that would be enough, I think, to say commit it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraphcouldbe a router also)
On Wed, Nov 20, 2002 at 09:20:17AM -0800, Terry Lambert wrote the words in effect of: Hiten Pandya wrote: Hehe. I was not being sarcastic. I just acknoledged your statement. The reason I asked about committing the patch in the first place, is because I thought that the patch had been around on the -net@ list, and had been reviewed. My apologies. It's been around on the list for a while, but if it's working for the people involved, they are not saying anything. Last I heard, the person who had the problem had tried the Intel Gigabit card, but not the Tigon III, but was looking for a Gigabit card recommendation. I suppose I could make the same patch for the Intel card. The problem is that DEVICE_POLLING is an all-or-nothing thing, you can't control it on a card-by-card basis, even with a sysctl, because it fills out an entry point that's statically, rather than procedurally initialized. Basically, that means that the worst case, you could not turn it on for cards that are known to work, if the patch fails to work for the Tigon III. If someone with a Tigon III card could try the patch with the DEVICE_POLLING option enabled, and device polling turned on, and let us know that the card keeps functioning, rather than them getting a panic, then that would be enough, I think, to say commit it. I think the Device Polling sysctls will need tuning, if I am thinking straightly. No? -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraphcouldbe a router also)
From: Terry Lambert [mailto:[EMAIL PROTECTED]] Hiten Pandya wrote: Hehe. I was not being sarcastic. I just acknoledged your statement. The reason I asked about committing the patch in the first place, is because I thought that the patch had been around on the -net@ list, and had been reviewed. My apologies. It's been around on the list for a while, but if it's working for the people involved, they are not saying anything. Last I heard, the person who had the problem had tried the Intel Gigabit card, but not the Tigon III, but was looking for a Gigabit card recommendation. I suppose I could make the same patch for the Intel card. The problem is that DEVICE_POLLING is an all-or-nothing thing, you can't control it on a card-by-card basis, even with a sysctl, because it fills out an entry point that's statically, rather than procedurally initialized. Is there any point to using device polling with the tigon 3 (broadcom 570x etc)? It has a pretty good interrupt reducer in it by itself. Just tune the 2 rx and the 2 tx parameters and you get a constant interrupt rate with good latency for any packet rate. I changed (if_bge.c): /* RX Interrupt no more than every ~500 us */ sc-bge_rx_coal_ticks = 512; /* TX Interrupt no more than every ~500 us */ sc-bge_tx_coal_ticks = 512; /* RX Interrupt no more than every ~120 packets */ sc-bge_rx_max_coal_bds = 128; /* TX Interrupt no more than every ~120 packets */ sc-bge_tx_max_coal_bds = 128; and this gives no more than 2000 interrupts/s, and no more than 500us of latency. The if_em has similar functionality AFAIK. --don To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[FreeBSD PR bin/15416] addr2line broken
FreeBSD PR bin/15416 (addr2line is unable to find line numbers) indicates that addr2line appears to be broken. This PR was submitted at the end of 99 when 4.x was -current. It hasn't been touched since. The PR gives a test case where addr2line appears to be broken. I ran this exact test case on a 4-stable box and saw the same issue. The version addr2line reports is 2.12.1 [FreeBSD] 2002-07-20. I tested it on 5-DP2 and it appears to work correctly, the version there is 2.13 [FreeBSD] 2002-10-10. What's the correct thing to do with this PR? The issue does appear to be fixed in -current (with the newer addr2line). I suppose the PR should at least be set to a status of patched. Thanks. -Joseph To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraphcouldbe a router also)
Hiten Pandya wrote: If someone with a Tigon III card could try the patch with the DEVICE_POLLING option enabled, and device polling turned on, and let us know that the card keeps functioning, rather than them getting a panic, then that would be enough, I think, to say commit it. I think the Device Polling sysctls will need tuning, if I am thinking straightly. No? You can control it with IFF_POLLING. But that's only good if the code in the interrupt routine, init routine, and, in the if_ti case, the ti_rxeof routine isn't broken. It's incredibly trivial code, but the fact that it's in the default interrupt path, if the kernel was compiled with the DEVICE_POLLING option, even if it's not set on the interface, means the risk is too high for a blind commit this close to a release. The correct thing to have done is probably to add an entry point into the DEVMETHOD table for the rxeof and txeof, and a polling init routine, and a polling routine, to avoid having to wedge the ether_poll register into the init routine of drivers which support polling. And then seperate out the interrupt enabling/disabling code as DEVMETHOD entry points as well. A side effect of this would be to remove a measurable amount of overhead from the interrupt handlers of drivers that support DEVICE_POLLING, but don't have it enabled on the card. Doing this would allow for automatic support for DEVICE_POLLING for all drivers, without the device_polling function call and compare overhead on each interrupt, in the non-polling case. Turning it on/off via sysctl also requires these changes, as does turning it off via ifconfig, since a poll is required after that to take care of data that arrived before interrupts were enabled, and failed to generate an interrupt, and so will never result in the data being reaped (this is a bug in the polling disabling case for all DEVICE_POLLING code, right now). This would also allow the implementation of soft interrupt coelescing at a higher layer, for all drivers... that only assumes that all drivers are munged to add rxeof/txeof DEVMETHODs, so it could be done without supporting DEVICE_POLLING everywhere. Basically, this would mean changing all the drivers to match Bill Paul's template (seperate rxeof/txeof routines), which most older drivers don't do, and which had bus overhead for some other drivers, and then exposing the routines as part of the formal interface. None of this is stuff that would make it past the release engineers in time for inclusion in 5.0, but an tested if_ti patch might. So I only did an if_ti patch. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraphcouldbe a router also)
Don Bowman wrote:
Is there any point to using device polling with the tigon 3
(broadcom 570x etc)? It has a pretty good interrupt reducer in it
by itself.
Just tune the 2 rx and the 2 tx parameters and you get a constant
interrupt rate with good latency for any packet rate.
This is hardware interrupt coelescing. It is a totally seperate
thing.
The point of DEVICE_POLLING is to avoid the receiver livelock
case, when you are under extreme load.
What this probably means is that you haven't put enough load
on the hardware to see the livelock case.
Given enough load, the 'ticks' trigger never fires: you are
getting enough packets that, even if you divide by 128 ('bds'),
you are still in trouble.
The problem is that at 128 'bds', you end up spending 128
times as long in the interrupt handler, so all you are saving
is the trigger latency.
This pushes the top end before livelock higher, but it doesn't
prevent it.
You also delay packet processing on up to 'bds - 1' packets that
are received in the 'ticks' window, before the 'bds'th packet
comes in, so you increase your mbuf pool size for unprocessed
packets. This doesn't really affect performance, per se, but
it will reduce the total number of simultaneous connections you
are able to support at a given client load on a web server (for
example).
The DEVICE_POLLING option doesn't just get rid of interrupts;
what it does is delays packet input until the rest of the
system is ready to handle the packets.
It's not actually ideal; really, you want to tell the hardware
to stop DMA'ing into packet buffers, so that you don't eat the
bus latency while you are not polling for more data. A number
as high as 128 (depending on the firmware) can actually be a
bad thing.
Bottom line is that, until a full LRP is integrated, the best
performance you are going to be able to get is DEVICE_POLLING,
and it doesn't really matter how much you can amortize the
interrupt overhead.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/bin/sleep sleep.c
David Schultz [EMAIL PROTECTED] wrote: BSS and modified data are not shared, and Matt is only counting zero fill and COW faults. Most of the BSS is mmapped zero pages that are copy-on-write, so in simple programs they should be mostly shared. See rtld-elf/map_object.c Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: SOUTHEAST 6 TO GALE 8 LOCALLY SEVERE GALE 9 EASING SOUTH TO SOUTHWEST 4 TO 5 LATER. OCCASIONAL RAIN. MODERATE TO GOOD. MODERATE TO ROUGH OR VERY ROUGH. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraphcouldbe a router also)
From: Terry Lambert [mailto:[EMAIL PROTECTED]] Don Bowman wrote: Is there any point to using device polling with the tigon 3 (broadcom 570x etc)? It has a pretty good interrupt reducer in it by itself. Just tune the 2 rx and the 2 tx parameters and you get a constant interrupt rate with good latency for any packet rate. This is hardware interrupt coelescing. It is a totally seperate thing. The point of DEVICE_POLLING is to avoid the receiver livelock case, when you are under extreme load. What this probably means is that you haven't put enough load on the hardware to see the livelock case. Actually I have pushed it to the livelock case. I'm shocked at how easy this is to do with BSD (I'm used to system like vxworks with much lower over head interrupt processing). I found that for a 2x XEON @ 2GHz that I can achieve this @ ~100Mbps of minimal size UDP fragments. Tuning the driver dramatically improved the situation. Reducing the size of its receive ring to the proper amount also helps since it will then run out of buffers and drop packets. This isn't extreme load, it isn't really particularly heavy load, its only like ~200Kpps. I suspect the defragmenting is the issue, so I tried it again with ARP's. This helped a lot. I'm still not clear on how the receiver polling helps me, it also makes a constant rate consumption of packets. If I set the bds to the max, then I will only be interrupted @ constant rate by the device. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraphcouldbe a router also)
Don Bowman wrote: From: Terry Lambert [mailto:[EMAIL PROTECTED]] Don Bowman wrote: Is there any point to using device polling with the tigon 3 (broadcom 570x etc)? It has a pretty good interrupt reducer in it by itself. Just tune the 2 rx and the 2 tx parameters and you get a constant interrupt rate with good latency for any packet rate. This is hardware interrupt coelescing. It is a totally seperate thing. The point of DEVICE_POLLING is to avoid the receiver livelock case, when you are under extreme load. What this probably means is that you haven't put enough load on the hardware to see the livelock case. Actually I have pushed it to the livelock case. I'm shocked at how easy this is to do with BSD (I'm used to system like vxworks with much lower over head interrupt processing). I found that for a 2x XEON @ 2GHz that I can achieve this @ ~100Mbps of minimal size UDP fragments. Tuning the driver dramatically improved the situation. Reducing the size of its receive ring to the proper amount also helps since it will then run out of buffers and drop packets. This isn't extreme load, it isn't really particularly heavy load, its only like ~200Kpps. I suspect the defragmenting is the issue, so I tried it again with ARP's. This helped a lot. I'm still not clear on how the receiver polling helps me, it also makes a constant rate consumption of packets. If I set the bds to the max, then I will only be interrupted @ constant rate by the device. Thanks to Luigi for writing a nice manual page on Device Polling operation. It explains most of the things clearly. There is also something about tuning the HZ kernel configuration option. FYI, the manual page is polling(4). For more information, and Frequently Asked Questions, checkout the following Luigi's homepage: http://info.iet.unipi.it/~luigi/polling/ Cheers. -- Hiten [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/bin/sleep sleep.c
On Wed, 20 Nov 2002, Tony Finch wrote: David Schultz [EMAIL PROTECTED] wrote: BSS and modified data are not shared, and Matt is only counting zero fill and COW faults. Most of the BSS is mmapped zero pages that are copy-on-write, so in simple programs they should be mostly shared. See rtld-elf/map_object.c Tony. I'm curious how well COW sharing really works under FreeBSD. Earlier this year, I fixed a piece of code which was O((processes sharing a page)^2) in the VM system. When certain simple forkbombs were run, they would cause the machine to freeze for 30 seconds at a time or more once the VM cleanup routines kicked in and ran the O(N^2) piece of code. What bugged me at the time was that I couldn't seem to reproduce the problem with other programs... this led me to believe that we aren't really sharing too many pages in common use, but I didn't have time to investigate if that was true or not. Someone with an interest in VM implementations might want to take a wander through and see how well page sharing really works on a typical FreeBSD system. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SiS 900 Ethernet card
Dear FreeBSD friends, In an email before I reported about a problem with the SiS 900 ethernetcard: Dear FreeBSD friends, I have bought a nice laptop computer (Gericom Masterpiece 25340 XL). It has an ethernet card inside, based on SiS 900 chip. During boot, FreeBSD can detect the card, but cannot assign an MAC address, nor initializing the card. I receive following messages: sis0: SiS 900 10/100BaseTX port 0xf800-0xf8ff mem 0xe8005000-0xe8005fff irq 4 at device 4.0 on pci0 sis0: Ethernet address: ff:ff:ff:ff:ff:ff sis0: MII without any PHY! device_probe_and_attach: sis0 attach returned 6 Does anybody know to solve this problem? On that I received two different patches, which could solve the problem. I have attached them to this email: sis.diff from Luoqi Chen and if_sis.patch from Jeff Seeman. if_sis.patch didn't do the job. The message during boot didn't change and moreover I was not able to use the ethernet device. sis.diff did a better a job, but it solved the problem partly. Have a look to the output during boot: ... sis0: SiS 900 10/100BaseTX port 0xf800-0xf8ff mem 0xe8005000-0xe8005fff irq 5 at device 4.0 on pci0 sis0: Ethernet address: ff:ff:ff:ff:ff:ff miibus0: MII bus on sis0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcic0: YENTA PCI-CardBus Bridge irq 11 at device 10.0 on pci0 pcic0: PCI Memory allocated: 0x8800 ... Still the system is not able to retrieve the MAC address from the ethernetcard. Of course I could assign a MAC address manually and work around the problem (ifconfig sis0 lladdr xx:xx:xx:xx:xx:xx), but still it would be nice to have a driver which does a proper job. Is a better patch available? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Grüßen, Willy * W.K. Offermans Eindhoven University of Technology Department of Chemical Engineering Laboratory of Catalysis (SKA) building ST-W 4.27, PO Box 513 5600 MB Eindhoven, Netherlands Tel: 0(031) 40 247 37 81 Fax: 0(031) 40 247 50 32 Home: 0(031) 45 544 49 99 e-mail: [EMAIL PROTECTED] http://www.catalysis.nl If you are bored playing with Bill Gates' toy, start to work with a real operating system Feel free, feel FreeBSD (www.FreeBSD.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SiS 900 Ethernet card
I just to say that I have similar problem and I also have SiS900 on my Laptop but I only receive MII without any PHY and the system reboots before even booted ! The mac is 00:00:00:00:00:00 It seems that the driver for this network card is not working at all ! P.S. Thanks for the patches, I'll try them On Wed, 20 Nov 2002, Willy Offermans wrote: Dear FreeBSD friends, In an email before I reported about a problem with the SiS 900 ethernetcard: Dear FreeBSD friends, I have bought a nice laptop computer (Gericom Masterpiece 25340 XL). It has an ethernet card inside, based on SiS 900 chip. During boot, FreeBSD can detect the card, but cannot assign an MAC address, nor initializing the card. I receive following messages: sis0: SiS 900 10/100BaseTX port 0xf800-0xf8ff mem 0xe8005000-0xe8005fff irq 4 at device 4.0 on pci0 sis0: Ethernet address: ff:ff:ff:ff:ff:ff sis0: MII without any PHY! device_probe_and_attach: sis0 attach returned 6 Does anybody know to solve this problem? On that I received two different patches, which could solve the problem. I have attached them to this email: sis.diff from Luoqi Chen and if_sis.patch from Jeff Seeman. if_sis.patch didn't do the job. The message during boot didn't change and moreover I was not able to use the ethernet device. sis.diff did a better a job, but it solved the problem partly. Have a look to the output during boot: ... sis0: SiS 900 10/100BaseTX port 0xf800-0xf8ff mem 0xe8005000-0xe8005fff irq 5 at device 4.0 on pci0 sis0: Ethernet address: ff:ff:ff:ff:ff:ff miibus0: MII bus on sis0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcic0: YENTA PCI-CardBus Bridge irq 11 at device 10.0 on pci0 pcic0: PCI Memory allocated: 0x8800 ... Still the system is not able to retrieve the MAC address from the ethernetcard. Of course I could assign a MAC address manually and work around the problem (ifconfig sis0 lladdr xx:xx:xx:xx:xx:xx), but still it would be nice to have a driver which does a proper job. Is a better patch available? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Grüßen, Willy * W.K. Offermans Eindhoven University of Technology Department of Chemical Engineering Laboratory of Catalysis (SKA) building ST-W 4.27, PO Box 513 5600 MB Eindhoven, Netherlands Tel: 0(031) 40 247 37 81 Fax: 0(031) 40 247 50 32 Home: 0(031) 45 544 49 99 e-mail: [EMAIL PROTECTED] http://www.catalysis.nl If you are bored playing with Bill Gates' toy, start to work with a real operating system Feel free, feel FreeBSD (www.FreeBSD.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hardware in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SiS 900 Ethernet card
[reports of sis900 driver not working] Could you post the output of pciconf -lv on your systems so we can see what exact variant of the sis900 card you have? Wolfgang To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SiS 900 Ethernet card with PCI configuration
Hello, sis0@pci0:4:0:class=0x02 card=0xb7321019 chip=0x09001039 rev=0x91 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS900 Fast Ethernet/Home Networking Ctrlr' class= network subclass = ethernet that's apparently a SiS962 chip. This one is not (yet) supported in FreeBSD; the MAC address is stored on an EEPROM that is shared with the IEEE 1394 port and needs a special access protocol. If you want to hack on the driver yourself, a search for sis962 and sis900.c or sis900.h on google should get you the information what was changed on the linux driver to support this particular chip. I _might_ find the time next weekend to cobble together a patch you could try. Wolfgang To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SiS 900 Ethernet card
Dear FreeBSD friend, I'm not able to hack the code myself, I'm just a FreeBSD user (enthousiastic one) not a developer. So it would be nice if someone else could do it. On Wed, Nov 20, 2002 at 03:03:24PM +0100, Wolfgang Zenker wrote: Hello, sis0@pci0:4:0: class=0x02 card=0xb7321019 chip=0x09001039 rev=0x91 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS900 Fast Ethernet/Home Networking Ctrlr' class= network subclass = ethernet that's apparently a SiS962 chip. This one is not (yet) supported in FreeBSD; the MAC address is stored on an EEPROM that is shared with the IEEE 1394 port and needs a special access protocol. If you want to hack on the driver yourself, a search for sis962 and sis900.c or sis900.h on google should get you the information what was changed on the linux driver to support this particular chip. I _might_ find the time next weekend to cobble together a patch you could try. Wolfgang -- Met vriendelijke groeten, Willy * W.K. Offermans Eindhoven University of Technology Department of Chemical Engineering Laboratory of Catalysis (SKA) building ST-W 4.27, PO Box 513 5600 MB Eindhoven, Netherlands Tel: 0(031) 40 247 37 81 Fax: 0(031) 40 247 50 32 Home: 0(031) 45 544 49 99 e-mail: [EMAIL PROTECTED] http://www.catalysis.nl If you are bored playing with Bill Gates' toy, start to work with a real operating system Feel free, feel FreeBSD (www.FreeBSD.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SiS 900 Ethernet card
Dear FreeBSD friend, Indeed it is, as you call it, one of those 'silicon on the motherboard' things. So I don't know if this is more difficult for you to do. On Wed, Nov 20, 2002 at 07:44:05AM -0700, Howard Harvey wrote: - Original Message - From: Willy Offermans [EMAIL PROTECTED] To: Wolfgang Zenker [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 7:26 AM Subject: Re: SiS 900 Ethernet card Dear FreeBSD friend, I'm not able to hack the code myself, I'm just a FreeBSD user (enthousiastic one) not a developer. So it would be nice if someone else could do it. Is this one of those 'silicon on the motherboard' things or an external PCI card? I've hacked ethernet drivers before and if it's just a PCI card, I would certainly be willing to have a (w)hack at it. 2 H[[EMAIL PROTECTED]] If you don't realize it's crazy If you don't understand the source Don't reach too fast for the answers Cuz it get's worse. --- Headstones On Wed, Nov 20, 2002 at 03:03:24PM +0100, Wolfgang Zenker wrote: Hello, sis0@pci0:4:0: class=0x02 card=0xb7321019 chip=0x09001039 rev=0x91 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS900 Fast Ethernet/Home Networking Ctrlr' class= network subclass = ethernet that's apparently a SiS962 chip. This one is not (yet) supported in FreeBSD; the MAC address is stored on an EEPROM that is shared with the IEEE 1394 port and needs a special access protocol. If you want to hack on the driver yourself, a search for sis962 and sis900.c or sis900.h on google should get you the information what was changed on the linux driver to support this particular chip. I _might_ find the time next weekend to cobble together a patch you could try. Wolfgang -- -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, Willy * W.K. Offermans Eindhoven University of Technology Department of Chemical Engineering Laboratory of Catalysis (SKA) building ST-W 4.27, PO Box 513 5600 MB Eindhoven, Netherlands Tel: 0(031) 40 247 37 81 Fax: 0(031) 40 247 50 32 Home: 0(031) 45 544 49 99 e-mail: [EMAIL PROTECTED] http://www.catalysis.nl If you are bored playing with Bill Gates' toy, start to work with a real operating system Feel free, feel FreeBSD (www.FreeBSD.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Backup/restore of bootable w2k fat32 part from freebsd
On Wed, 2002-11-20 at 18:42, Michael Reifenberger wrote: are there experiences with backup/restore of an bootable w2k partition from within FreeBSD? I've seen `newfs_msdos -B`, but how to extract the w2k bootblock (dd?) ? Is it sufficient to get an bootable partition? I think you'll have trouble unless you backup and restore the extra bits (system, hidden, archive) as well. I wrote a patch for msdosfs which maps these to suid/sgid/sticky (yes, I know, gross, but it was useful at the time). You can have it if you want. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/sys/cam/scsi scsi_cd.c scsi_cd.h src/sys/dev/ataatapi-cd.c src/sys/sys cdrio.h src/usr.sbin/burncd burncd.8 burncd.csrc/usr.sbin/cdcontrol cdcontrol.1 cdcontrol.c
On Wed, 20 Nov 2002, Dirk Froemberg wrote:
What about CDRIOCGETBLOCKSIZE and CDRIOCSETBLOCKSIZE? Any chance
to have these ioctl in cd(4)?
This would allow mplayer to play (S)VCD with SCSI cd drives. 8-)
Regards Dirk
I'm open to reviewing a patch that does this if someone wants to do it
(jkh?) The ioctls left to port from atapi-cd.c are:
#define CDRIOCBLANK _IOW('c', 100, int)
#define CDRIOCNEXTWRITEABLEADDR _IOR('c', 101, int)
#define CDRIOCINITWRITER_IOW('c', 102, int)
#define CDRIOCINITTRACK _IOW('c', 103, struct cdr_track)
#define CDRIOCSENDCUE _IOW('c', 104, struct cdr_cuesheet)
#define CDRIOCFLUSH _IO('c', 105)
#define CDRIOCFIXATE_IOW('c', 106, int)
#define CDRIOCGETBLOCKSIZE _IOR('c', 109, int)
#define CDRIOCSETBLOCKSIZE _IOW('c', 110, int)
#define CDRIOCGETPROGRESS _IOR('c', 111, int)
#define CDRIOCREADFORMATCAPS_IOR('c', 112, struct
cdr_format_capacities)
#define CDRIOCFORMAT_IOW('c', 113, struct cdr_format_params)
However, I'm working on more CAM stuff that should make this code
duplication unnecessary so I won't be duping this code myself.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/bin/sleep sleep.c
Thus spake Tony Finch [EMAIL PROTECTED]: David Schultz [EMAIL PROTECTED] wrote: BSS and modified data are not shared, and Matt is only counting zero fill and COW faults. Most of the BSS is mmapped zero pages that are copy-on-write, so in simple programs they should be mostly shared. See rtld-elf/map_object.c Once those pages are written to, the kernel must fault in a fresh zero-filled page. Since the BSS typically holds uninitialized data, we can probably assume that the program is going to initialize most of it at some point, so there will be very few shared BSS pages. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/bin/sleep sleep.c
Thus spake Mike Silbersack [EMAIL PROTECTED]: I'm curious how well COW sharing really works under FreeBSD. Earlier this year, I fixed a piece of code which was O((processes sharing a page)^2) in the VM system. When certain simple forkbombs were run, they would cause the machine to freeze for 30 seconds at a time or more once the VM cleanup routines kicked in and ran the O(N^2) piece of code. What bugged me at the time was that I couldn't seem to reproduce the problem with other programs... this led me to believe that we aren't really sharing too many pages in common use, but I didn't have time to investigate if that was true or not. Someone with an interest in VM implementations might want to take a wander through and see how well page sharing really works on a typical FreeBSD system. :) I'm not sure exactly what routine you're referring to, but one thing to keep in mind is that most pages that somehow got to be massively shared are never, ever written. For example, the text segment of virtually all executables is read-only, except when using debuggers. Anyway, the point is that if it takes O(N^2) time to take a write fault on a page shared by N processes, that's certainly bad, but not as bad as it sounds. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraphcouldbe a router also)
[ ... why you want something more than interrupt coelescing ... ] Don Bowman wrote: Actually I have pushed it to the livelock case. I'm shocked at how easy this is to do with BSD (I'm used to system like vxworks with much lower over head interrupt processing). I found that for a 2x XEON @ 2GHz that I can achieve this @ ~100Mbps of minimal size UDP fragments. Tuning the driver dramatically improved the situation. Reducing the size of its receive ring to the proper amount also helps since it will then run out of buffers and drop packets. This isn't extreme load, it isn't really particularly heavy load, its only like ~200Kpps. I suspect the defragmenting is the issue, so I tried it again with ARP's. This helped a lot. I'm still not clear on how the receiver polling helps me, it also makes a constant rate consumption of packets. If I set the bds to the max, then I will only be interrupted @ constant rate by the device. OK. This really has nothing to do with interrupt processing latency, except that such latency increases pool retention time, and reduces the overall load-bearing capacity of a single system. In other words, latency effects the number of connections and the total amount of data in transit, but not whether or not that data gets through. So it's not a direct cause of livelock, even if it can be an indirect cause. There are a couple of livelock points. The best paper describing this is: Eliminating Receiver Livelock in an Interrupt-Driven Kernel Jeffrey C. Mogul, K.K. Ramakrishnan http://citeseer.nj.nec.com/mogul96eliminating.html This isn't the earliest paper on the topic but it's authoritative. All of these boil down to packets not getting all the way to the application that has the socket open, for whaetver reason, or the inability of the system to send responses to the packets which it has received. Basically, a receiver livelock can occur any place that there is not a negative feedback loop to control packet sources, once you achieve resource saturation. In BSD network processing, there are a number of livelock points, where there is no negative feedback loop. Following the packet in from the wire, these are: o Received packets are copied across the bus to a main memory ring buffer, even when the packets are not being processed, for some cards. The correct thing to do is to not copy the packets in this case, reserving the bus for other data transfers (e.g. an NFS server can not do disk transfers if it is spending all bus cycles doing packet transfers). This is a network controller firmware issue, and has to be addressed there (many, but not all, network adapters do the right thing). o Hardware interrupts occur when packets are transferred successfully from network adapter memory to main memory, which causes the host system to run the interrupt handler code, instead of running other code, like the protocol processing or the application that owns the connection. This is the highest priority, so you need to be able to squelch interrupt processing. o Protocol processing is the next highest priority item; if you successfully squelch hardware interrupts when you hit load capacity, you can still deny applications time to run by, instead of spending all of your time handling interrupts, spending all your time doing protocol processing. The application does not have an opportunity to run, to deal with the packets which have been received. o Application processing is the lowest priority item. When you hit a resource limit, such as number of mbufs available in the system as a whole, such that you cannot allocate send chains for responding to the traffic requests you are getting, then you back up input requests, and, again, you are in trouble. All of these lead to receiver livelock. There are several ways to attack this issue, but given an infinite ability to generate load, the only one that's effective at handling at least *some* load is to insert negative feedback loops between the stall points in the network processing model, so that the next stage can squelch the incoming packets. The normal way to deal with this is to drop the packets as early as possible, before investing a lot of resources in processing them. The best way (so far) of doing this is LRP (Lazy Receiver Processing), which is described in: Lazy Receiver Processing (LRP): A Network Subsystem Architecture for Server Systems Peter Druschel, Gaurav Banga http://citeseer.nj.nec.com/druschel96lazy.html This paper described more of the details of receiver livelock, and the problems with the BSD processing model, and has a number of nice pictures that I cab't do justice to with just ASCII Art. What DEVICE_POLLING does
Re: Intel PCI Modem
Hi!
On Wednesday, November 06, 2002 2:38 AM, WATANABE Kiyoshi wrote:
On Thu, 31 Oct 2002 11:04:18 -0600, Braulio Jos$Bi (BSolano Rojas wrote:
I have an Intel V92 HaM Data Fax Voice Modem. It is a hardware based
modem. Mi pnpbios recognizes it as Simple COMM. controler IRQ12.
AFAIK, Intel HaM (Host Accelerated Modem) is a sort of what is called
Winmodem.
And if I do pciconf -l:
none0@pci0:9:0: class=0x078000 card=0x chip=0x40001813 rev=0x02
hdr=0x00
!!
When subclass is 0x80 (defined as PCIS_SIMPLECOMM_OTHER),
in most cases it means that the device is either Winmodem or IrDA.
There are binary+source Intel HaM modem drivers for linux at:
http://developer.intel.com/design/modems/support/drivers_linux.htm
Intel-v92ham.tgz -- Intel MD563X-HaM V.92 chipset
Intel-536ep.tgz -- Intel 536EP V.92 chipset
If you have experience in writing device driver,
I think it is not so difficult to port it to FreeBSD.
It will take much time though.
I do not have experience on this. However I would like to do it. Where may
I find documentation on how to write a FreeBSD driver?
Best regards,
Braulio Solano
On Wed, 6 Nov 2002 00:42:05 -0600, Braulio José Solano Rojas wrote:
Hello!
On Monday, November 04, 2002 John Baldwin wrote:
On 04-Nov-2002 Braulio José Solano Rojas wrote:
Hi!
On Thursday, October 31, 2002 John Baldwin wrote:
On 31-Oct-2002 Braulio José Solano Rojas wrote:
Hello!
I have an Intel V92 HaM Data Fax Voice Modem. It is a hardware
based
modem. Mi pnpbios recognizes it as Simple COMM. controler
IRQ12.
I would like to hack sio.c in order to get it working. Therefore
I
think I
should add an entry to pci_ids[] like:
{hex x, Intel V92 HaM Data Fax Voice, hex y}
But I do not know what are hex x and hex y, or if it is going to
work.
The 'x' is 0x40001813. To get the 'y', you need to do a boot -v
and send the output here.
I have tried with these:
{0x40001813, Creatix V.90 HaM Modem, 0x10}
{0x40001813, Creatix V.90 HaM Modem, 0x14}
If I do a boot -v I get this:
found - vendor=0x1813, dev=0x4000, revid=0x02
class=07-80-00, ndrtype=0x00, mfdev=0
subordinatebus=0 secondarybus=0
intpin=a, irq=12
map[10]: type 1, range 32, base df00, size 12
map[14]: type 1, range 32, base 000d8000, size 8
I also have added to my kernel configuration file option
PCI_ENABLE_IO_MODES.
You want to use the 0x14 version. Does it work?
No it does not work.
I have tried with:
devicesio2 at isa? port IO_COM3 irq 12
on my kernel configuration file and with:
devicesio2 at pci? port IO_COM3 irq 12
without success.
May be, I should add this modem to src/sys/dev/puc/pucdata.c.
Unless it has multiple serial ports on it I would just stick it
in sio_pci.c.
Where is this file? I can not find it.
Do I have to add something more than
{0x40001813, Creatix V.90 HaM Modem, 0x14}in sio.c?
If yes, what and where?
Is the entry for sio2 in my kernel configuration file fine?
I appreciate your help.
Best regards,
Braulio Solano
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Épargnez de 15% à 80% sur vos coûts publicitaires !
Du bureau de Didier Bonneville-Roussy St-Barthélemy Cher ami et entrepreneur, Ceci est le premier numéro de la Lettre du marketing géométrique. Le coût de l'abonnement pour un an est de 197$. Par contre, j'ai décidé de vous envoyer cette première lettre gratuitement et de vous offrir un abonnement d'essai de trois mois pour seulement 7$. Lisez attentivement les informations que je vous livre dans ces huit pages et décidez-vous dans les 15 jours. Il y a 7 ans, lorsque j'ai commencé en marketing, je me suis rendu compte que je pouvais épargner des sommes considérables en frais de publicité en étudiant de manière approfondie la nature de la relation entre les médias et les agences de publicité, ainsi qu'entre les médias et les organismes communautaires. J'ai remarqué deux choses: les agences paient toujours moins que les autres entreprises et les organismes communautaires paient toujours moins que les agence de publicités pour faire paraître leurs annonces. J'ai découvert comment payer en tout temps le même prix que les agences (rabais de 15%) et dans certaines circonstances le même prix que les organismes communautaires (50% de rabais). Si vous me laissez vous expliquer comment tout cela fonctionne, vous serez, vous aussi, avant la fin de cette lettre, en mesure d'épargner de 15% à 80% sur vos coûts publicitaires, et même, dans certains cas, d'obtenir des pages et des pages de publicités gratuites. Commençons par les agences. À peu près tous les médias, radio, télé, journaux, magazines, les agents de listes et les sites internet offrent un rabais automatique de 15% aux agences de publicité qui placent des annonces. Lorsqu'on regarde dans le CARD (Canadian Advertising Rates And Data) et le SRDS (Standard Rates And Data Service), qui sont les deux répertoires des tarifs publicitaires, nous pouvons noter trois types de rabais: 1. Rabais au volume présenté sous forme de prix réduit par ligne agate ou sous forme de prix réduit pour un nombre prédéterminé d'insertions en un an; 2. Un rabais de 15% aux agences; 3. Un rabais pour paiement rapide (généralement de 2%). Le CARD et le SRDS portent tous deux la mention «rabais offert aux agences reconnues seulement», lorsque l'agence de publicité peut bénéficier d'un rabais. Cette mention ne vaut rien. En fait oui, elle vaut quelque chose, dans la mesure où elle vous dissuade de demander le rabais de 15% normalement attribué à l'agence, si vous ne faites pas partie d'une agence reconnue. Mais ça, les représentants publicitaires dans les différents médias ne vous le disent pas. Pourquoi? Parce qu'ils sont rémunérés à la commission et qu'il ont tout avantage à ne pas vous le dire. De plus, si vous faites vraiment partie d'une agence, vous utilisez nécessairement le CARD et le SRDS et vous savez qu'il y a de tels rabais. Voici le premier secret: il n'existe rien de tel qu'une agence reconnue. N'importe quel zouave de Saint-Clin-clin peut-être une agence reconnue. Mon petit frère de neuf ans pourrait, demain matin, devenir une agence reconnue s'il disait ces neuf petits mots: «Je veux le rabais que vous attribuez aux agences.» Certains médias sont plus désagréables que d'autres et ne vous accorderont pas de rabais pour l'agence si votre compagnie ne porte pas un nom qui ressemble vaguement à celui d'une agence de publicité. Mais, si vous êtes intelligent, ce que je crois puisque vous me lisez, vous allez courir au palais de justice et vous enregistrer un nom d'entreprise du genre «Bingo Marketing» pour 45$ et rappeler ce représentant et lui dire que vous appellez maintenant d'une agence reconnue. Et vous voilà maintenant agence reconnue. Vous avez droit à un rabais de 15%. De plus, vous avez aussi droit au rabais pour paiement rapide de 2% si vos encaisses vous le permettent. C'est, en tout, 17% de rabais sur tous vos achats publicitaires que je viens de vous faire épargner. Ceci est valable pour les journaux, les magazines, la radio, la télévision, les sites internet, les agents de listes, les posters, les publi-sacs, etc. Maintenant, pour le rabais de type volume, je ne vous conseille en aucun cas de l'utiliser et surtout si une agence vous le propose. D'ailleurs, je défie n'importe qu'elle agence sur ce sujet. Prenez votre bottin et demandez-leur comment épargner de l'argent sur vos achats publicitaires. Écoutez attentivement la merde qu'ils vous servent et comparez l'information que je vous donne ici. Il n'y a aucune commune mesure. Revenons au rabais de type volume. En gros, c'est une proposition qui ne peut que défavoriser l'annonceur. D'abord, les rabais sont ridiculement bas, généralement quelques dollars sur des milliers, ensuite, d'un point de vue strictment marketing géométrique, c'est le meilleur moyen de vous faire avoir. Voici pourquoi: Il s'agit de contrats fondés sur l'utilisation du média sur une période d'un an. Par exemple vous recevez un rabais de X% si vous placez 4
seeking clarification of makefile rules 'safe' with -j
I'm crunching out some complex 'make' rules , and am having a brain
fart as to what sorts of rules are safe to use with '-j'.
As a matter of example, I'm looking at /usr/share/mk/sys.mk under
4.5-RELEASE:
# XXX not -j safe
.y.out:
${YACC} ${YFLAGS} ${.IMPSRC}
${CC} ${CFLAGS} ${LDFLAGS} y.tab.c ${LDLIBS} -ly -o ${.TARGET}
rm -f y.tab.c
.l.out:
${LEX} -t ${LFLAGS} ${.IMPSRC} ${.PREFIX}.tmp.c
${CC} ${CFLAGS} ${LDFLAGS} ${.PREFIX}.tmp.c ${LDLIBS} -ll -o ${.TARGET}
rm -f ${.PREFIX}.tmp.c
Why is the .y.out target annotated as 'not -j safe', but the next
target is?
--
Brian 'you Bastard' Reichert[EMAIL PROTECTED]
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA Intel architecture: the left-hand path
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: seeking clarification of makefile rules 'safe' with -j
In the last episode (Nov 21), Brian Reichert said:
I'm crunching out some complex 'make' rules , and am having a brain
fart as to what sorts of rules are safe to use with '-j'.
As a matter of example, I'm looking at /usr/share/mk/sys.mk under
4.5-RELEASE:
# XXX not -j safe
.y.out:
${YACC} ${YFLAGS} ${.IMPSRC}
${CC} ${CFLAGS} ${LDFLAGS} y.tab.c ${LDLIBS} -ly -o ${.TARGET}
rm -f y.tab.c
.l.out:
${LEX} -t ${LFLAGS} ${.IMPSRC} ${.PREFIX}.tmp.c
${CC} ${CFLAGS} ${LDFLAGS} ${.PREFIX}.tmp.c ${LDLIBS} -ll -o ${.TARGET}
rm -f ${.PREFIX}.tmp.c
.y.out uses a constant filename (y.tab.c) as an intermediate file. If
make -j decided to compile two .y files in the same directory at the
same time, one's going to get overwritten. .l.out avoids this by using
${.PREFIX}, which expands to the filename of the source file minus path
and extension. .y.out could be made safe by making the first line
${YACC} ${YFLAGS} -o ${.PREFIX}.y.tmp.c ${.IMPSRC}
and replacing y.tab.c. with ${.PREFIX}.y.tmp.c . For good measure,
.l.out should probably be using ${.PREFIX}.l.tmp.c, just so you can
tell which rule generated a particular tempfile.
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: seeking clarification of makefile rules 'safe' with -j
On Wed, Nov 20, 2002 at 11:53:45PM -0600, Dan Nelson wrote:
.y.out uses a constant filename (y.tab.c) as an intermediate file. If
make -j decided to compile two .y files in the same directory at the
same time, one's going to get overwritten. .l.out avoids this by using
${.PREFIX}, which expands to the filename of the source file minus path
and extension. .y.out could be made safe by making the first line
${YACC} ${YFLAGS} -o ${.PREFIX}.y.tmp.c ${.IMPSRC}
and replacing y.tab.c. with ${.PREFIX}.y.tmp.c . For good measure,
.l.out should probably be using ${.PREFIX}.l.tmp.c, just so you can
tell which rule generated a particular tempfile.
Ah, that does paint it succinctly. If your suggestion is sound,
should it be perhaps submitted as a PR to make 'make' even safer
by default?
--
Dan Nelson
[EMAIL PROTECTED]
--
Brian 'you Bastard' Reichert[EMAIL PROTECTED]
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA Intel architecture: the left-hand path
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
