40gig IDE drives?
Anyone know how to get a 40gig IDE drive working under FreeBSD? It picks it up as having 79000 odd sectors and says that the geometary is wrong, and it doesnt work. Any advice would be appreciated Thanks Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DDB is not setting break points...
On Thu, 1 Jun 2000, G.B.Naidu wrote: > I am having problems with DDB while setting breakpoints in the kernel. I > entered the DDB by giving kernel -d at boot prompt. After that I tried to > set break point at ip_output() by giving "b ip_output". But it complains > saying that "sumbol not found". I thought this might be due to stripped Early setting of breakpoints by name was broken by the switch to elf in FreeBSD-3.0 (symbols aren't available until the kernel module sysinit runs much later). I think it works for aout kernels in 3.x but not in 4.0 or -current. Use gdb or set breakpoints early by value in broken versions. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DDB is not setting break points... (fwd)
Hi Doug, Thanks for your reply. We tried as per your mail. But still the DDB is complaining the same saying that "symbol not found". What could be the reason? Am I missing something in the whole process? thanks --gb On Thu, 1 Jun 2000, Doug White wrote: > On Thu, 1 Jun 2000, G.B.Naidu wrote: > > > Have posted this questoin earlier. I have got no replies. Some body take > > some time to clarify this? > > cd /sys/boot > make depend all install > disklabel -B ad0 > reboot > > This will update your bootblocks. > > > In the handbook chap 21, Note says: Note that if you have an older version > > of boot blocks. your debugger symbols might not be loaded at all. Update > > the bopot blocks; > > Doug White| FreeBSD: The Power to Serve > [EMAIL PROTECTED] | www.FreeBSD.org > -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Japan and Korea from June 7th through June 15th
Jordan K. Hubbard ([EMAIL PROTECTED]) wrote: > > Does this mean we won't get the SMP stuff done next week? > > I'm back on the 15th (you gain 10 hours coming back) and the SMP > meeting isn't until the 16th and 17th. Of course it will. :) You mean 15th & 16th right? :) -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Japan and Korea from June 7th through June 15th
In message <7816.959911822@localhost> "Jordan K. Hubbard" writes: : I'll be in Japan (Tokyo/Nagoya/Osaka areas) from the 7th through the : 12th and will be speaking at the Networld + INTEROP 2000 FreeBSD BOF : on 6/8 as well as the Japan Unix Society meeting in Nagoya on 6/9. : Anyone in these area is welcome to attend or simply join us afterwards : for dinner or something; see http://www.jp.freebsd.org for scheduling : details or contact [EMAIL PROTECTED] I'll also be at these meetings speaking as well. A news flash with more details is in the works. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Japan and Korea from June 7th through June 15th
In message <7816.959911822@localhost> "Jordan K. Hubbard" writes: : I'll be in Japan (Tokyo/Nagoya/Osaka areas) from the 7th through the : 12th and will be speaking at the Networld + INTEROP 2000 FreeBSD BOF : on 6/8 as well as the Japan Unix Society meeting in Nagoya on 6/9. : Anyone in these area is welcome to attend or simply join us afterwards : for dinner or something; see http://www.jp.freebsd.org for scheduling : details or contact [EMAIL PROTECTED] I'll be there too. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Japan and Korea from June 7th through June 15th
On Thursday, 1 June 2000 at 19:21:29 -0700, Jordan K. Hubbard wrote: >> Does this mean we won't get the SMP stuff done next week? > > I'm back on the 15th (you gain 10 hours coming back) and the SMP > meeting isn't until the 16th and 17th. Of course it will. :) Ah, I didn't see that message. Did you send one? Can you resend it? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Japan and Korea from June 7th through June 15th
> Does this mean we won't get the SMP stuff done next week? I'm back on the 15th (you gain 10 hours coming back) and the SMP meeting isn't until the 16th and 17th. Of course it will. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Japan and Korea from June 7th through June 15th
On Thursday, 1 June 2000 at 19:10:22 -0700, Jordan K. Hubbard wrote: > I'll be in Japan (Tokyo/Nagoya/Osaka areas) from the 7th through the > 12th and will be speaking at the Networld + INTEROP 2000 FreeBSD BOF > on 6/8 as well as the Japan Unix Society meeting in Nagoya on 6/9. > Anyone in these area is welcome to attend or simply join us afterwards > for dinner or something; see http://www.jp.freebsd.org for scheduling > details or contact [EMAIL PROTECTED] > >> From 6/12 though 6/15 I'll be in Seoul, Korea for the Free Software > conference there (on the 14th) but have no firm plans for the other > days yet. I would like to get together with some of the > kr.freebsd.org people if they're available, however, and would be > pleased if someone from that group could contact either myself or > Lydia Bennett <[EMAIL PROTECTED]> to arrange something. Does this mean we won't get the SMP stuff done next week? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
I will be in Japan and Korea from June 7th through June 15th
I'll be in Japan (Tokyo/Nagoya/Osaka areas) from the 7th through the 12th and will be speaking at the Networld + INTEROP 2000 FreeBSD BOF on 6/8 as well as the Japan Unix Society meeting in Nagoya on 6/9. Anyone in these area is welcome to attend or simply join us afterwards for dinner or something; see http://www.jp.freebsd.org for scheduling details or contact [EMAIL PROTECTED] >From 6/12 though 6/15 I'll be in Seoul, Korea for the Free Software conference there (on the 14th) but have no firm plans for the other days yet. I would like to get together with some of the kr.freebsd.org people if they're available, however, and would be pleased if someone from that group could contact either myself or Lydia Bennett <[EMAIL PROTECTED]> to arrange something. Thanks! - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multilingual Installer for 3.2-RELEASE (Re: pccard boot.flp...)
Just following up on this - are there any plans to merge this work back into the mainstream so that we can generate "localized" installation floppies for the Japanese community in future releases? Thanks! (Yes, I'm really catching up on email over a year old today). - Jordan > In <[EMAIL PROTECTED]> I wrote, > > >> Thank you. Now I'm working on updated sysinstall messages. > >> I'll send the URL of message.lt_EN, *.TXT, *.hlp files to translate > >> when I finished this work. > >> I want translators to other languages. > > I finished updating indices of messages, and complied the first public > test version. > > Currently, following binary package is compiled with English, Japanese > and Korean support. As a result of increased size of boot.flp, > Japanese and Korean support is now merged again into the same boot.flp > image. > > http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/floppies-19990608.tar.gz > (Compiled boot.flp, kern.flp, and mfsroot.flp binaries) > > http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/release-19990608.tar.gz > (Patched source tree of /usr/src/release) > > http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/translation-kit-19990608.tar.gz > (All you have to translate is this tarball) > > Current Translation Status: > --- > JapaneseKorean > --- > sysinstall messages: almost okay NG > help files: NG almost okay > --- > > -- > HOSOKAWA, Tatsumi > Assistant Manager > Information Technology Center, Keio University > <[EMAIL PROTECTED]> > > > 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
TCP/IP protocol S/W
Hello In the paper "Experience With TCP/IP Networking Protocol S/W over Embedded OS for Network Appliance" in computer society IEEE, it says: The environment for the development of embedded OS and TCP/IP protocol S/W. Embedded OS and TCP/IP module are implemented by gnu c compiler, gcc-2.6.1, under the FreeBSD OS. I apologize, What is it or what signify the term "TCP/IP protocol S/W" ? Thanks. +--+ | YONNY CARDENAS B. [EMAIL PROTECTED] | +--+ UNIX is BSD, and FreeBSD is an advanced 4.4BSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
... > The problem is that the cards get swapped. ... > It's a long story as to why switching cables, or changing which card gets > which IP address isn't really a good solution. The short answer is that i suppose the only place where you use the actual card names is the firewall config and rc.conf -- can't you just make these scripts fetch the ethernet address of the card(s), set a shell variable with the name of the good card, and go ahead with that ? I did something similar in picobsd to make the same floppy recognise the hardware on different systems. Something like (in /etc/rc): n_ether="" for main_if in `ifconfig -l` ; do set `ifconfig $main_if` while [ "$1" != "" ] ; do if [ $1 = "ether" ] ; then main_ether=$2 break 2 else shift fi done done At which point $main_ether contains the ethernet address of your first ethernet interface and you can base decisions on that... cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
... > The problem is that the cards get swapped. ... > It's a long story as to why switching cables, or changing which card gets > which IP address isn't really a good solution. The short answer is that i suppose the only place where you use the actual card names is the firewall config and rc.conf -- can't you just make these scripts fetch the ethernet address of the card(s), set a shell variable with the name of the good card, and go ahead with that ? I did something similar in picobsd to make the same floppy recognise the hardware on different systems. Something like (in /etc/rc): n_ether="" for main_if in `ifconfig -l` ; do set `ifconfig $main_if` while [ "$1" != "" ] ; do if [ $1 = "ether" ] ; then main_ether=$2 break 2 else shift fi done done At which point $main_ether contains the ethernet address of your first ethernet interface and you can base decisions on that... cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
On Thu, 1 Jun 2000, Kenneth D. Merry wrote: > On Thu, Jun 01, 2000 at 11:19:29 -0600, Fred Clift wrote: > > > > > > i suppose the only place where you use the actual card names > > > is the firewall config and rc.conf -- can't you just make these > > > scripts fetch the ethernet address of the card(s), set a shell > > > variable with the name of the good card, and go ahead with that ? > > > > Yeah I'm about to the point of doing this for lack of other options. > > Thanks for the sample code -- I'm sure it'll come in handy if I can solve > > this any other way. > > > > The best fix would be to find a way to hard-wire which card is which in > > the kernel config (ie fxp0 is always on pci0...) but I dont know if you > > can do that kind of thing with pci devices. > > The problem is that when the new-bus code was introduced, the probe order > was changed from a bus-by-bus probe (breadth first?) to a depth-first > probe. > > i.e. as soon as another PCI bus is found (e.g. on a bridge chip) it is > probed, rather than deferring the probe of the new bus until the probe of > the current bus has been completed. > > I think Doug Rabson had plans to fix the probe order, but it never > happened. > > There is no way to hardwire PCI devices, so you'll probably have to just > change which card is referenced in your scripts. I can see that that would be fun if I were to switch from 3.4-STABLE to 4.0-STABLE on my 7-NIC (8-port) router. Currently they all probe in a way that the physical layout of the cards mirrors the logical layout. One is a dual-port NIC with PCI bridge which would constitute a PCI bus all by itself, then I believe there are three separate PCI busses of three slots each for a total of 9 PCI slots (or it could be 4x2 and 1x1). I can just imagine a physical to logical mapping nightmare of 2-3-4-7-8-9-1-2-3 now. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: S5933 PCI Adapter..??
At 04:24 PM 6/1/00 -0400, Joy Ganguly wrote: >Dennis wrote: > >> At 12:13 PM 6/1/00 -0600, Warner Losh wrote: >> >In message <[EMAIL PROTECTED]> Dennis writes: >> >: Have you done bus performance testing with this card? Given the >> >: architechture of the AMCC part, it seems highly improbable that you will be >> >: able to get high throughput with such a card. Because the AMCC part >> >: requires external logic it is impossible to do pass-through single cycle >> >: bursts, which is required for efficient utilization of the PCI bus. Once >> >: you begin holding off cycles the PCI bus totally pigs out (which is why >> >: virtually all high-speed pci solutions are single-chip type designs). >> > >> >Yes. I've done drivers for several cards with this design. The AMCC >> >part is very fussy and will often lock up the bus unless the card >> >designer has put enough extra logic on the card to cope with the >> >oddities of the card. Sadly, many don't. >> >> We used it on our first (and now defunct) pci board, and we didnt have >> trouble with lockups (there are quite a few errata that have to be >> addresses), but the arbitration was pitifully slow. There was no way to get >> high throughput across the bus. We completely rejected it for use on >> T3...i find it interesting that someone did an OC3/ATM card with it. >> >> Dennis >> >> Emerging Technologies, Inc. >> > >well the problem seems to have been with the motherboard. i changed the >motherboard and the card is working. >we are using "point" oc3 card from 'applied telecom'. we have not done >any >performance testing. the card is mainly meant for monitoring. of course this discussion has nothing to do with your problem...but Im glad you figured it out :-) good luck with your throughput. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: S5933 PCI Adapter..??
Dennis wrote: > At 12:13 PM 6/1/00 -0600, Warner Losh wrote: > >In message <[EMAIL PROTECTED]> Dennis writes: > >: Have you done bus performance testing with this card? Given the > >: architechture of the AMCC part, it seems highly improbable that you will be > >: able to get high throughput with such a card. Because the AMCC part > >: requires external logic it is impossible to do pass-through single cycle > >: bursts, which is required for efficient utilization of the PCI bus. Once > >: you begin holding off cycles the PCI bus totally pigs out (which is why > >: virtually all high-speed pci solutions are single-chip type designs). > > > >Yes. I've done drivers for several cards with this design. The AMCC > >part is very fussy and will often lock up the bus unless the card > >designer has put enough extra logic on the card to cope with the > >oddities of the card. Sadly, many don't. > > We used it on our first (and now defunct) pci board, and we didnt have > trouble with lockups (there are quite a few errata that have to be > addresses), but the arbitration was pitifully slow. There was no way to get > high throughput across the bus. We completely rejected it for use on > T3...i find it interesting that someone did an OC3/ATM card with it. > > Dennis > > Emerging Technologies, Inc. > well the problem seems to have been with the motherboard. i changed the motherboard and the card is working. we are using "point" oc3 card from 'applied telecom'. we have not done any performance testing. the card is mainly meant for monitoring. joy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ISA device with no ports in 4.0
Trying to use a "compat" driver with no isa ports and 4.0 complains (we used to return a 1 and set the ioport to 0)..since you cant return a 0 from probe, is there a trick to tell the system that there are no ports? DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
UDMA-33 Error Messages
I had a power outage this morning and my 4.0-Stable system suddenly started generating the following messages Jun 1 09:38:55 opal /kernel: acd0: DVD-ROM at ata1-master using PIO4 Jun 1 09:38:55 opal /kernel: Mounting root from ufs:/dev/ad0s3a Jun 1 09:38:55 opal /kernel: ad0: UDMA ICRC READ ERROR blk# 0 retrying Jun 1 09:38:55 opal last message repeated 2 times Jun 1 09:38:55 opal /kernel: ad0: UDMA ICRC READ ERROR blk# 0ata0-master: WARNING: WAIT_READY active=ATA_ACTIVE_ATA Jun 1 09:38:55 opal /kernel: falling back to PIO mode Jun 1 09:38:55 opal /kernel: WARNING: / was not properly dismounted This machine had never done this before and I noticed that the reboot hadn't taken care of the dismount message. I had to manually fsck the system. A single user boot produced much nastier messages and were persistant. I rebooted three times before I did the manual fsck. The boot to single user was the third boot. The reboot after the fsck sequence produced the following boot stream cut and pasted from dmesg. Jun 1 10:20:23 opal /kernel: ad0: 19541MB [39703/16/63] at ata0-master using UDMA33 Jun 1 10:20:23 opal /kernel: ad1: 6679MB [14475/15/63] at ata0-slave using UDMA33 Jun 1 10:20:23 opal /kernel: ad3: 12970MB [26353/16/63] at ata1-slave using UDMA33 Jun 1 10:20:23 opal /kernel: acd0: DVD-ROM at ata1-master using PIO4 Jun 1 10:20:23 opal /kernel: Mounting root from ufs:/dev/ad0s3a I also noticed the "/kernel: WARNING: / was not properly dismounted" in messages from people having ATA read error troubles on UDMA drives. Kent -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: S5933 PCI Adapter..??
At 12:13 PM 6/1/00 -0600, Warner Losh wrote: >In message <[EMAIL PROTECTED]> Dennis writes: >: Have you done bus performance testing with this card? Given the >: architechture of the AMCC part, it seems highly improbable that you will be >: able to get high throughput with such a card. Because the AMCC part >: requires external logic it is impossible to do pass-through single cycle >: bursts, which is required for efficient utilization of the PCI bus. Once >: you begin holding off cycles the PCI bus totally pigs out (which is why >: virtually all high-speed pci solutions are single-chip type designs). > >Yes. I've done drivers for several cards with this design. The AMCC >part is very fussy and will often lock up the bus unless the card >designer has put enough extra logic on the card to cope with the >oddities of the card. Sadly, many don't. We used it on our first (and now defunct) pci board, and we didnt have trouble with lockups (there are quite a few errata that have to be addresses), but the arbitration was pitifully slow. There was no way to get high throughput across the bus. We completely rejected it for use on T3...i find it interesting that someone did an OC3/ATM card with it. Dennis Emerging Technologies, Inc. - http://www.etinc.com ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX Multiport T1 and HSSI/T3 UNIX-based Routers Bandwidth Management Standalone Systems Bandwidth Management software for LINUX and FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
> > i suppose the only place where you use the actual card names > is the firewall config and rc.conf -- can't you just make these > scripts fetch the ethernet address of the card(s), set a shell > variable with the name of the good card, and go ahead with that ? Yeah I'm about to the point of doing this for lack of other options. Thanks for the sample code -- I'm sure it'll come in handy if I can solve this any other way. The best fix would be to find a way to hard-wire which card is which in the kernel config (ie fxp0 is always on pci0...) but I dont know if you can do that kind of thing with pci devices. Thanks for the help. -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: S5933 PCI Adapter..??
In message <[EMAIL PROTECTED]> Dennis writes: : Have you done bus performance testing with this card? Given the : architechture of the AMCC part, it seems highly improbable that you will be : able to get high throughput with such a card. Because the AMCC part : requires external logic it is impossible to do pass-through single cycle : bursts, which is required for efficient utilization of the PCI bus. Once : you begin holding off cycles the PCI bus totally pigs out (which is why : virtually all high-speed pci solutions are single-chip type designs). Yes. I've done drivers for several cards with this design. The AMCC part is very fussy and will often lock up the bus unless the card designer has put enough extra logic on the card to cope with the oddities of the card. Sadly, many don't. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
On Thu, Jun 01, 2000 at 11:19:29 -0600, Fred Clift wrote: > > > > i suppose the only place where you use the actual card names > > is the firewall config and rc.conf -- can't you just make these > > scripts fetch the ethernet address of the card(s), set a shell > > variable with the name of the good card, and go ahead with that ? > > Yeah I'm about to the point of doing this for lack of other options. > Thanks for the sample code -- I'm sure it'll come in handy if I can solve > this any other way. > > The best fix would be to find a way to hard-wire which card is which in > the kernel config (ie fxp0 is always on pci0...) but I dont know if you > can do that kind of thing with pci devices. The problem is that when the new-bus code was introduced, the probe order was changed from a bus-by-bus probe (breadth first?) to a depth-first probe. i.e. as soon as another PCI bus is found (e.g. on a bridge chip) it is probed, rather than deferring the probe of the new bus until the probe of the current bus has been completed. I think Doug Rabson had plans to fix the probe order, but it never happened. There is no way to hardwire PCI devices, so you'll probably have to just change which card is referenced in your scripts. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_fault() problem
:It seems to be a problem in vm/vm_fault() and :vnode_pager_generic_putpages() in FreeBSD 3.x & 4.0. : :The following code illustrates the problem: : :#include :#include :... Yes, this is definitely a bug. I'll take a look at fixing it on the weekend. I think what we have to do is allocate the file blocks at the time the page is dirties instead of later on when we try to flush the page out. It should be possible to do this in vm/vm_fault.c line 255 (in vm_fault(), the call to vm_freeze_copyopts()). This way if the filesystem runs out of space we can seg-fault the process synchronously. The problem as it stands now is that the pages are flushed asynchronously, and so the bitmap allocation can occur at a random time. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
... > The problem is that the cards get swapped. ... > It's a long story as to why switching cables, or changing which card gets > which IP address isn't really a good solution. The short answer is that i suppose the only place where you use the actual card names is the firewall config and rc.conf -- can't you just make these scripts fetch the ethernet address of the card(s), set a shell variable with the name of the good card, and go ahead with that ? I did something similar in picobsd to make the same floppy recognise the hardware on different systems. Something like (in /etc/rc): n_ether="" for main_if in `ifconfig -l` ; do set `ifconfig $main_if` while [ "$1" != "" ] ; do if [ $1 = "ether" ] ; then main_ether=$2 break 2 else shift fi done done At which point $main_ether contains the ethernet address of your first ethernet interface and you can base decisions on that... cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
> > i suppose the only place where you use the actual card names > is the firewall config and rc.conf -- can't you just make these > scripts fetch the ethernet address of the card(s), set a shell > variable with the name of the good card, and go ahead with that ? Yeah I'm about to the point of doing this for lack of other options. Thanks for the sample code -- I'm sure it'll come in handy if I can solve this any other way. The best fix would be to find a way to hard-wire which card is which in the kernel config (ie fxp0 is always on pci0...) but I dont know if you can do that kind of thing with pci devices. Thanks for the help. -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DDB is not setting break points... (fwd)
On Thu, 1 Jun 2000, G.B.Naidu wrote: > Have posted this questoin earlier. I have got no replies. Some body take > some time to clarify this? cd /sys/boot make depend all install disklabel -B ad0 reboot This will update your bootblocks. > In the handbook chap 21, Note says: Note that if you have an older version > of boot blocks. your debugger symbols might not be loaded at all. Update > the bopot blocks; Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
... > The problem is that the cards get swapped. ... > It's a long story as to why switching cables, or changing which card gets > which IP address isn't really a good solution. The short answer is that i suppose the only place where you use the actual card names is the firewall config and rc.conf -- can't you just make these scripts fetch the ethernet address of the card(s), set a shell variable with the name of the good card, and go ahead with that ? I did something similar in picobsd to make the same floppy recognise the hardware on different systems. Something like (in /etc/rc): n_ether="" for main_if in `ifconfig -l` ; do set `ifconfig $main_if` while [ "$1" != "" ] ; do if [ $1 = "ether" ] ; then main_ether=$2 break 2 else shift fi done done At which point $main_ether contains the ethernet address of your first ethernet interface and you can base decisions on that... cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
changed pci bus probe order from 3.2 to 4.0 -- ideas?
Hi. I've just switched to 4.0 right now and I have a problem. (well the first problem is that I dont know enough about freebsd, but I digress) I have two fxp network cards in box (intel ether express pro 10/100), one of which is integrated into the motherboard, the other of which is pluged into an active pci riser card. In 3.2 and 4.0, the pci-bus on the riser card is pci3 and the 'integrated' pci bus is 0. In 3.2 pci0 is scanned first, for devices and the integrated card is found and made fxp0, then pci1, pci2 and finally pci3, finding the second card, making it fxp1. In 4.0 it seems that pci3, then pci2 then pci1 then pci0 are being probed, finding the cards in the other order, and swapping what is fxp0 and fxp1. The problem is that the cards get swapped. It's a long story as to why switching cables, or changing which card gets which IP address isn't really a good solution. The short answer is that the second card doesn't actually ever have a network cable plugged into it at all, and is just there as a carrier of a home-brew network boot-bios. So, is there some way in the kernel config file to wire down which busses fxp0 and fxp1 live on? The only experience I have with this is playing around with isa sound cards in my desktop machine... Or alternatively, I _think_ that the bus probe stuff is in /usr/src/sys/kern/subr_bus.c I tried fiddling with device_add_child and device_add_child_ordered, but in retrospect it seems that that would just ocntrol the order in which an individual bus is scanned. How can I change the order in which the busses are scanned? Thanks in advance for any help you can give me. Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: multiple nfs mounts in 4.0-stable
:it seems that : :mount a.b.c.d:/dir /mntpoint :mount a.b.c.d:/dir2 /mntpoint : :will result in 2 mounts showing in the mount table. I dont recall this :happening in 3.x, and it seems quite wrong. (shouldnt the second attempt :return a busy)? : :DB This is how it worked in 3.x too. The second mount is simply mounted on top of the first. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: S5933 PCI Adapter..??
At 05:31 PM 5/31/00 -0700, Mike Smith wrote: >> hi all, >> >> i have a atm oc3 care which uses the amcc S5933 PCI adapter. however the >> driver reports "unable to map mem" at boot time. i used pciconf to read >> the configuration space base address registers and all of them showed >> 0x. however when i write all 1's t the base registers they give >> me the proper mask. the device and vendor id configuration registers >> show the right values. i think the bios is unable to assign physical >> addresses. Have you done bus performance testing with this card? Given the architechture of the AMCC part, it seems highly improbable that you will be able to get high throughput with such a card. Because the AMCC part requires external logic it is impossible to do pass-through single cycle bursts, which is required for efficient utilization of the PCI bus. Once you begin holding off cycles the PCI bus totally pigs out (which is why virtually all high-speed pci solutions are single-chip type designs). Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
multiple nfs mounts in 4.0-stable
it seems that mount a.b.c.d:/dir /mntpoint mount a.b.c.d:/dir2 /mntpoint will result in 2 mounts showing in the mount table. I dont recall this happening in 3.x, and it seems quite wrong. (shouldnt the second attempt return a busy)? DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
DDB is not setting break points... (fwd)
Hi, Have posted this questoin earlier. I have got no replies. Some body take some time to clarify this? thanks --gb -- -- Forwarded message -- Date: Thu, 1 Jun 2000 10:57:49 +0530 (IST) From: G.B.Naidu <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: DDB is not setting break points... Hi, I am having problems with DDB while setting breakpoints in the kernel. I entered the DDB by giving kernel -d at boot prompt. After that I tried to set break point at ip_output() by giving "b ip_output". But it complains saying that "sumbol not found". I thought this might be due to stripped kernel.( I configured the kernel with -g option), so I installed the unstripped kernel. Still I am getting the same error message from DDB. Why it is not setting break points? Am I missing some thing? In the handbook chap 21, Note says: Note that if you have an older version of boot blocks. your debugger symbols might not be loaded at all. Update the bopot blocks; I am having a doubt that is it due to older version of boot blocks? I am running FreeBSD 3.3-RELEASE. How do I findout that whether my boot blocks are older? In the first place is it the reason for DDB complaining about symbols not found? Any help is appreciated. thanks --gb -- 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
vm_fault() problem
It seems to be a problem in vm/vm_fault() and
vnode_pager_generic_putpages() in FreeBSD 3.x & 4.0.
The following code illustrates the problem:
#include
#include
#include
#include
#include
#define COUNT 1024
#define SIZE10*1024*1024
int main () {
int i,j,fd;
char *fptr, fname [16];
for (i=0;ip_ucred);
cnt.v_vnodeout++;
cnt.v_vnodepgsout += ncount;
if (error) {
printf("vnode_pager_putpages: I/O error %d\n", error);
}
if (auio.uio_resid) {
printf("vnode_pager_putpages: residual I/O %d at %lu\n",
auio.uio_resid, (u_long)m[0]->pindex);
}
for (i = 0; i < ncount; i++) {
rtvals[i] = VM_PAGER_OK;/* */
}
return rtvals[0]; /* */
So, such errors as I/O errors, are not handled there.
This seems to be a serious problem in FreeBSD VM subsystem, isn't it ?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
