Re: Dead lock
Am 30.05.2007 um 16:32 schrieb Roger Miranda: As of right now the machine goes into dead lock within a few hours (only when on the network). I get no WITNESS errors (LORs), or kernel dumps, or anything in the logs that look like an error or out of the ordinary. Is there anything else I could try? or am I looking at a hardware failure? What specifically do you mean by deadlock? Does Caps Lock or Num Lock still toggle the indicator? Can you enter the debugger? If so, there's a couple of things you could try from there, including saving a dump by entering call doadump or panic. Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dead lock
On Wednesday 13 June 2007 08:30, Stefan Bethke wrote: Am 30.05.2007 um 16:32 schrieb Roger Miranda: As of right now the machine goes into dead lock within a few hours (only when on the network). I get no WITNESS errors (LORs), or kernel dumps, or anything in the logs that look like an error or out of the ordinary. Is there anything else I could try? or am I looking at a hardware failure? What specifically do you mean by deadlock? Does Caps Lock or Num Lock still toggle the indicator? Can you enter the debugger? If so, there's a couple of things you could try from there, including saving a dump by entering call doadump or panic. Hi Stefan, Caps Lock nor Num Lock Toggles. We can not enter the debugger. It's a completly locked up system. At first I thought it was a Hardware or NIC issue. But we have tried new Hardware and 3com nics instead of the em (intel) NICs. Roger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Unix domain socket leak in 6-STABLE
Hi, as you are aware, there is a unix domain socket leak in 6-STABLE, which AFAIK is not yet fully fixed. I wanted to ask about the status or some possible fixes, as I know a way to reproduce the problem in a matter of minutes. We are running Cyrus and Postfix with the user DB in OpenLDAP. When using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd quickly runs out of filedescriptors as it is not closing any unix sockets (judging by ever increasing lsof output). Using TCP sockets is just fine. If there are patches I could try, don't hesitate to send them to me. Cheers, Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unix domain socket leak in 6-STABLE
Ulrich Spoerlein wrote: Hi, as you are aware, there is a unix domain socket leak in 6-STABLE, which AFAIK is not yet fully fixed. We are running Cyrus and Postfix with the user DB in OpenLDAP. When using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd quickly runs out of filedescriptors as it is not closing any unix sockets (judging by ever increasing lsof output). Can you perhaps isolate the bug / give more information on it? I'm asking because I'm currently using an application with unix domain sockets in production wich handles lots of connects/disconnects per second and it doesn't seem to show leakage. signature.asc Description: OpenPGP digital signature
Re: Can't get if_txp(4) to attach to a 3CR990B-TXM NIC
On Tuesday 12 June 2007 09:15 pm, Pyun YongHyeon wrote: On Tue, Jun 12, 2007 at 10:20:11AM -0700, Freddie Cash wrote: On Friday 08 June 2007 09:59 pm, Pyun YongHyeon wrote: On Fri, Jun 08, 2007 at 09:13:37AM -0700, Freddie Cash wrote: Good morning, I'm having a bit of an issue getting a 3CR990B-TXM NIC detected and usable. Just wondering if anyone knows of any issues with this NIC chipset and/or with the motherboard chipset. The motherboard is a Biostar GeForce 6100 AM2 using an nVidia nForce 410 chipset and nVidia GeForce 6100 vide chipset. I've tried FreeBSD 6.1, 6.2, 6-STABLE (from Wed), and 7-CURRENT (from Thu) on this system. Everything installs nicely, everything on the board is detected correctly and usable. It's just the PCI NIC that doesn't work. If I compile a custom kernel without any network drivers in it, and then kldload if_txp, the following appears (same message on all 4 versions): txp0: 3Com 3cR990B-TXM Etherlink with 3XP Processor port 0xbc00-0xbc7f mem 0xfdcff000-0xfdcff07f irq 16 at device 8.0 on pci3 txp0: not waiting for boot device_attach: txp0 attach returned -1 Would you try attached path? It wouldn't fix your issue but it will handle failure of contigmalloc as expected. Patch applies cleanly, module compiles cleanly, and module is kldloaded cleanly. But same error message as before, and no txp0 device is created. Tested on 7-CURRENT from last week. Thanks for testing! It seems that the message will show up in case of firmware loading/ring initialization failure. Try attached patch which will show failing function name. Patch uplied cleanly, module compiled clealy, and module was kldloaded cleanly. Error message is now: txp0: 3Com 3cR990B-TXM Etherlink with 3XP Processor port 0xbc00-0xbc7f mem 0xfdcff000-0xfdcff07f irq 18 at device 6.0 on pci3 txp0: txp_download_fw: not waiting for boot device_attach: txp0 attach returned -1 The IRQ and device numbers changed as it's in a different PCI slot than before. Looks like your guess was right, there's something not working right in the firmware download. Because I don't have 3CR990 hardware it's very hard to fix it. I'm unsure remote debugging would help here. Btw, it seems the hardware looks very good(except for extra copying on strict alignment architecture) and it even supports TSO! We normally use 3C905-series and 3C980-series NICs. Our local PC vendor sent us these instead when we ordered low-profile NICs to put into our new firewall boxes (while we wait for the back-order on Intel gigabit dual-port, low-profile, PCIe NICs to be filled). I was going to try upgrading the firmware on the NICs, as there's an update available on the 3Com website, but the installer requires a Windows box (tried via a DOS boot disk and get the Can't be run in DOS mode error), which we don't have available at the moment. -- Freddie Cash, LPIC-2 CCNT CCLP Network Support Technician School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unix domain socket leak in 6-STABLE
On Wed, Jun 13, 2007 at 04:22:45PM +0200, Ulrich Spoerlein wrote: Hi, as you are aware, there is a unix domain socket leak in 6-STABLE, which AFAIK is not yet fully fixed. I wanted to ask about the status or some possible fixes, as I know a way to reproduce the problem in a matter of minutes. We are running Cyrus and Postfix with the user DB in OpenLDAP. When using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd quickly runs out of filedescriptors as it is not closing any unix sockets (judging by ever increasing lsof output). Using TCP sockets is just fine. If there are patches I could try, don't hesitate to send them to me. Might be a red herring, but worth mentioning as a possibility: I've seen this kind of problem with domain sockets (at least on Linux with a multi-use tool called busybox) where on error conditions the code never bothered to close the existing socket it opened, thus resulting in leaks/resource exhaustion over time. The code later got fixed, but a pretty nasty bug especially when the program is used in a lot of embedded products... In regards to FreeBSD, I remember reading some mails from Robert Watson last month in regards to UNIX domain socket code changes: http://monkey.org/freebsd/archive/freebsd-stable/200705/msg00200.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unix domain socket leak in 6-STABLE
On Wed, 13 Jun 2007 16:22:45 +0200, Ulrich Spoerlein [EMAIL PROTECTED] wrote: Hi, as you are aware, there is a unix domain socket leak in 6-STABLE, which AFAIK is not yet fully fixed. I wanted to ask about the status or some possible fixes, as I know a way to reproduce the problem in a matter of minutes. We are running Cyrus and Postfix with the user DB in OpenLDAP. When using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd quickly runs out of filedescriptors as it is not closing any unix sockets (judging by ever increasing lsof output). Shouldn't slapd close its unix socket? Or am I misreading this. Using TCP sockets is just fine. If there are patches I could try, don't hesitate to send them to me. Cheers, Uli Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re Unix domain socket leak in 6-STABLE
On 6/13/07, Ivan Voras [EMAIL PROTECTED] wrote:
Can you perhaps isolate the bug / give more information on it? I'm
asking because I'm currently using an application with unix domain
sockets in production wich handles lots of connects/disconnects per
second and it doesn't seem to show leakage.
Ok, I'm not exactly sure what I should do. First of all, there are two
LDAP consumers: postfix and cyrus-saslauthd. A fairly common setup, I
suppose.
If I bombard this setup with hundreds of mails, cyrus is at one point
unable to process the mails further, stating that:
Jun 13 18:27:22 misctest1 lmtpunix[47460]: IOERROR: opening
/data/cyrus/spool/user/ulrspoe/cyrus.cache: Too many open files
The error is misleading, though, as it is not cyrus that is out of
file descriptors, but rather OpenLDAP. Restarting slapd will make
cyrus work again.
I logged the lsof output during the mail bomb and the slapd-lines are
continually rising:
misctest1# while :; do echo -n `date` ; lsof 2/dev/null | awk '$1
~ /imapd/{imapd+=1} $1 ~ /slapd/{slapd+=1} $3 ~ /postfix/{pf+=1}
END{print imapd, pf, slapd}'; sleep 60;done
Wed Jun 13 18:21:55 CEST 2007 1378 71 272
Wed Jun 13 18:22:57 CEST 2007 1378 71 272
Wed Jun 13 18:23:58 CEST 2007 1378 216 316
Wed Jun 13 18:24:59 CEST 2007 1378 321 644
Wed Jun 13 18:26:01 CEST 2007 1378 333 1132
Wed Jun 13 18:27:02 CEST 2007 1378 329 1804
Wed Jun 13 18:28:04 CEST 2007 1378 417 2280
The third column never goes down significantly. I have the setup now
sitting at 2k open files for the slapd process and will wait until
tomorrow, if the count ever decreases again.
Changing from
ldapi://%2fvar%2frun%2fopenldap%2fldapi/ to ldap://127.0.0.1/ fixes
the problem. It might be a genuine problem in OpenLDAP, though. We are
using openldap-server-2.3.34_1
Cheers,
Uli
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unix domain socket leak in 6-STABLE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, June 13, 2007 09:17:36 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: I've seen this kind of problem with domain sockets (at least on Linux with a multi-use tool called busybox) where on error conditions the code never bothered to close the existing socket it opened, thus resulting in leaks/resource exhaustion over time. The code later got fixed, but a pretty nasty bug especially when the program is used in a lot of embedded products... In regards to FreeBSD, I remember reading some mails from Robert Watson last month in regards to UNIX domain socket code changes: http://monkey.org/freebsd/archive/freebsd-stable/200705/msg00200.html 'k, just to ring in here ... I can definitely attest to there being a leak here, as it was me that was originally burned by it ... in my case, I eventually was able to isolate which VPS/jail was causing it and haven't run it since, but was never able to determine exactly what was causing it, since there wasn't really anything unusual running in that jail :( But ... based on the discussions that were had at the time, it was my understanding that if all applications were shut down on the server (to the bare minimal), eventually the kernel GC should clean up all residual sockets ... when I did this (shut down all applications but the very bare minimum) and waited for 10+ minutes, socket usage never drop'd below about 4k sockets in use, or something like that ... Unlike Ulrich, I wasn't running LDAP at the time, so that wasn't the cause for me ... I could easily enough restart that jail if there was some more useful information I could get from it, but the thread kinda dwindled off over time, and rebooting a server ever 3 days was getting a wee bit annoying to my clients :) But, if someone has something they'd like me to do to provide more info, I'm willing to do it (short of anything that requires DDB / console access ... that server is remote) ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGcC0y4QvfyHIvDvMRApuZAJ9xKfa2/LqkcMkFEr4vrtnLt3ObcQCg43hs 7QX1hYskbQh/L8XJn1r1/Ts= =xKdx -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FYI: ULi/ALi SATA fix committed on HEAD
I have just committed a change (with soren's blessing) for the upcoming 7.0 branch which resolves the regression with ALI/ULI sata controllers introduced in 6.2-RELEASE. This affected a number of systems in particular the ASUS Vintage series of barebones boxes. Some folks on stable were affected too. regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unix domain socket leak in 6-STABLE
Marc G. Fournier wrote: 'k, just to ring in here ... I can definitely attest to there being a leak here, as it was me that was originally burned by it ... in my case, I eventually was able to isolate which VPS/jail was causing it and haven't run it since, but was never able to determine exactly what was causing it, since there wasn't really anything unusual running in that jail :( But ... based on the discussions that were had at the time, it was my understanding that if all applications were shut down on the server (to the bare minimal), eventually the kernel GC should clean up all residual sockets ... when I did this (shut down all applications but the very bare minimum) and waited for 10+ minutes, socket usage never drop'd below about 4k sockets in use, or something like that ... Hi Marc, was your leak a kernel leak or a user leak (if it actually makes a difference). Because I'm only hitting the problem within the slapd process itself. Restart it, every thing is good again. Other applications are also no affected. I think what's happening to me, is that slapd keeps unix domain sockets lingering too long. When blasting mails through the system, all those tiny ldap lookups then lead to slapd reaching it's process limit. I wonder though: maxfilesperproc is roughly 12k, but lsof needs to only count 2.5k lines of slapd output when the limit is hit. Is there a better way to check, how much fds/resources are open by a certain process? When using TCP sockets, the number of open files hardly changes. Ulrich Spoerlein -- The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled. -- Will Cuppy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unix domain socket leak in 6-STABLE
On Wed, Jun 13, 2007 at 08:15:56PM +0200, Ulrich Spoerlein wrote: I wonder though: maxfilesperproc is roughly 12k, but lsof needs to only count 2.5k lines of slapd output when the limit is hit. Is there a better way to check, how much fds/resources are open by a certain process? sockstat is what you're looking for. Also, do not forget about limits(1). If the sockets aren't being closed (in any condition; after completion or after error), there's going to be a leak until the daemon is restarted. I wouldn't be surprised if this is what's happening, based on previous experience I've had with slapd during my day job. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
atapicam and cd-rw problem, no cd0 but acd0 some error
Hi guys, I am running 6-STABLE as of today and I cannot use the CD-RW on my IBM T40 to burn CDs. When I put atapicam_load=YES in loader.conf or compile it in the kernel I see the following error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 and no /dev/cd0 is created. I don`t see the above error without atapicam loaded or in kernel. This is not something new, I haven`t been able to get /dev/cd0 since more than a month following 6-STABLE, don`t know if it ever worked on 6 or 6.x, but I certainly cannot get it to work on 6-STABLE. Any help would be appreciated :) I would be happy ot be able to burn CDs. I have acd0: CDRW TOSHIBA DVD-ROM SD-R9012/1121 at ata1-master UDMA33 and camcontrol shows: TOSHIBA DVD-ROM SD-R9012 1121at scbus2 target 0 lun 0 (pass1) Thanks -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B pgp9CYLqGQLU5.pgp Description: PGP signature
Re: Unix domain socket leak in 6-STABLE
On 6/13/07, Ulrich Spoerlein [EMAIL PROTECTED] wrote: Hi, as you are aware, there is a unix domain socket leak in 6-STABLE, which AFAIK is not yet fully fixed. I wanted to ask about the status or some possible fixes, as I know a way to reproduce the problem in a matter of minutes. We are running Cyrus and Postfix with the user DB in OpenLDAP. When using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd quickly runs out of filedescriptors as it is not closing any unix sockets (judging by ever increasing lsof output). Using TCP sockets is just fine. If there are patches I could try, don't hesitate to send them to me. Ohhh !! I had exactly the same problem last night. After change the line of /usr/local/etc/nss_ldap.conf from uri ldap://127.0.0.1/ to uri ldapi://%2fvar%2frun%2fopenldap%2fldapi/ The open sockets off this machine started to increase until reach maxfiles limit and show messages like this: kernel: kern.maxfiles limit exceeded by uid 65534, please see tuning(7). and slapd stopped to accept new connections. During the day (production hours) the number off connections (using TCP sockets) to OpenLDAP range from 16 to 45. Last night after change the type connection to Unix Domain Socket the number of connections raised rapidly to about 4000. I get this numbers using sockstat -c command. This machine is our Samba PDC, running 6.2-STABLE compile in Apr 5 13:33:50 using samba-3.0.24,1, nss_ldap-1.255, openldap-server-2.3.34_1 I can provide more information if need. Any Advises/Patches ? Best Regards, Alexandre Biancalana ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
marketing lists for medical and dental fields
I was told that you were looking for marketing databases of the medical community. Until the end of this week (June 15/2007) we have this deal on the go: Directories for the USA: - Physicians: 700 thousand doctors in the US. Data is provided in Excel format and sortable by state or specialty. Over a dozen different fields and more than 30 specialties. Individual Cost: $349 - Hospital Admins: 23 thousand in all with data for the CEO, CFO, CIO, COO and more Individual Cost: $220 - Dentists and Related Dental Services: 597 thousand records in all Individual Cost: $209 If you buy the directory of physicians you will get the other 2 for free. Contact us at 1-206-984-0935 or send an email to [EMAIL PROTECTED] Reply with 'null' in the subject if you choose not to remain in our records # This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal # ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unix domain socket leak in 6-STABLE
* Alexandre Biancalana [EMAIL PROTECTED] [070613 12:40] wrote: On 6/13/07, Ulrich Spoerlein [EMAIL PROTECTED] wrote: Hi, as you are aware, there is a unix domain socket leak in 6-STABLE, which AFAIK is not yet fully fixed. I wanted to ask about the status or some possible fixes, as I know a way to reproduce the problem in a matter of minutes. We are running Cyrus and Postfix with the user DB in OpenLDAP. When using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd quickly runs out of filedescriptors as it is not closing any unix sockets (judging by ever increasing lsof output). Using TCP sockets is just fine. If there are patches I could try, don't hesitate to send them to me. Ohhh !! I had exactly the same problem last night. After change the line of /usr/local/etc/nss_ldap.conf from uri ldap://127.0.0.1/ to uri ldapi://%2fvar%2frun%2fopenldap%2fldapi/ The open sockets off this machine started to increase until reach maxfiles limit and show messages like this: kernel: kern.maxfiles limit exceeded by uid 65534, please see tuning(7). and slapd stopped to accept new connections. During the day (production hours) the number off connections (using TCP sockets) to OpenLDAP range from 16 to 45. Last night after change the type connection to Unix Domain Socket the number of connections raised rapidly to about 4000. I get this numbers using sockstat -c command. This machine is our Samba PDC, running 6.2-STABLE compile in Apr 5 13:33:50 using samba-3.0.24,1, nss_ldap-1.255, openldap-server-2.3.34_1 I can provide more information if need. Any Advises/Patches ? I would advise running truss or ktrace against the process to see if it's actually attempting to close the descriptor. this would explain if the leak is in the application, or maybe libc/kernel. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unix domain socket leak in 6-STABLE
On 6/13/07, Alfred Perlstein [EMAIL PROTECTED] wrote: I would advise running truss or ktrace against the process to see if it's actually attempting to close the descriptor. this would explain if the leak is in the application, or maybe libc/kernel. -- - Alfred Perlstein Hi ! I change nss_ldap.conf again to access OpenLDAP via unix domain socket. Here is the connection counter before the change: Wed Jun 13 22:35:55 BRT 2007 unix sockets: 99 tcp sockets: 12 Here is the connection counter rigth before change connection method back to TCP socket: Wed Jun 13 22:56:01 BRT 2007 unix sockets: 2902 tcp sockets: 13 Follow the link to the 500k lines kdump file from a ktrace of an smbd process that leaked more than 1000 unix domain sockets connections during this time. http://www.seudns.net/~ale/smbd.kdump.bz2 ps: I removed some lines from the file that shows socket read returns, because they showed usernames e other informations that I don't want to expose. Regards, Alexandre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't get if_txp(4) to attach to a 3CR990B-TXM NIC
On Wed, Jun 13, 2007 at 09:01:39AM -0700, Freddie Cash wrote:
On Tuesday 12 June 2007 09:15 pm, Pyun YongHyeon wrote:
On Tue, Jun 12, 2007 at 10:20:11AM -0700, Freddie Cash wrote:
On Friday 08 June 2007 09:59 pm, Pyun YongHyeon wrote:
On Fri, Jun 08, 2007 at 09:13:37AM -0700, Freddie Cash wrote:
Good morning,
I'm having a bit of an issue getting a 3CR990B-TXM NIC detected
and usable. Just wondering if anyone knows of any issues with
this NIC chipset and/or with the motherboard chipset.
The motherboard is a Biostar GeForce 6100 AM2 using an nVidia
nForce 410 chipset and nVidia GeForce 6100 vide chipset.
I've tried FreeBSD 6.1, 6.2, 6-STABLE (from Wed), and 7-CURRENT
(from Thu) on this system. Everything installs nicely,
everything on the board is detected correctly and usable. It's
just the PCI NIC that doesn't work.
If I compile a custom kernel without any network drivers in it,
and then kldload if_txp, the following appears (same message on
all 4 versions):
txp0: 3Com 3cR990B-TXM Etherlink with 3XP Processor port
0xbc00-0xbc7f mem 0xfdcff000-0xfdcff07f irq 16 at device 8.0 on
pci3 txp0: not waiting for boot
device_attach: txp0 attach returned -1
Would you try attached path?
It wouldn't fix your issue but it will handle failure of
contigmalloc as expected.
Patch applies cleanly, module compiles cleanly, and module is
kldloaded cleanly. But same error message as before, and no txp0
device is created.
Tested on 7-CURRENT from last week.
Thanks for testing!
It seems that the message will show up in case of firmware loading/ring
initialization failure. Try attached patch which will show failing
function name.
Patch uplied cleanly, module compiled clealy, and module was kldloaded
cleanly.
Error message is now:
txp0: 3Com 3cR990B-TXM Etherlink with 3XP Processor port 0xbc00-0xbc7f
mem 0xfdcff000-0xfdcff07f irq 18 at device 6.0 on pci3
txp0: txp_download_fw: not waiting for boot
device_attach: txp0 attach returned -1
The IRQ and device numbers changed as it's in a different PCI slot than
before.
Looks like your guess was right, there's something not working right in
the firmware download.
Revert previous patch and apply attached patch again.
Please give it spin and let me know result.
Because I don't have 3CR990 hardware it's very hard to fix it. I'm
unsure remote debugging would help here.
Btw, it seems the hardware looks very good(except for extra copying on
strict alignment architecture) and it even supports TSO!
We normally use 3C905-series and 3C980-series NICs. Our local PC vendor
sent us these instead when we ordered low-profile NICs to put into our
new firewall boxes (while we wait for the back-order on Intel gigabit
dual-port, low-profile, PCIe NICs to be filled).
I don't have experience from 3C980 but it seems the 3C990 with 3XP
processor looks better hardware than 3C905/3C980 series.
I was going to try upgrading the firmware on the NICs, as there's an
update available on the 3Com website, but the installer requires a
Windows box (tried via a DOS boot disk and get the Can't be run in DOS
mode error), which we don't have available at the moment.
--
Regards,
Pyun YongHyeon
Index: if_txp.c
===
RCS file: /home/ncvs/src/sys/dev/txp/if_txp.c,v
retrieving revision 1.46
diff -u -r1.46 if_txp.c
--- if_txp.c12 Jun 2007 04:33:21 - 1.46
+++ if_txp.c14 Jun 2007 03:50:51 -
@@ -541,14 +541,15 @@
WRITE_REG(sc, TXP_H2A_0, TXP_BOOTCMD_DOWNLOAD_COMPLETE);
- for (i = 0; i 1; i++) {
+ for (i = 0; i 2; i++) {
r = READ_REG(sc, TXP_A2H_0);
if (r == STAT_WAITING_FOR_BOOT)
break;
DELAY(50);
}
if (r != STAT_WAITING_FOR_BOOT) {
- device_printf(sc-sc_dev, not waiting for boot\n);
+ device_printf(sc-sc_dev, %s: not waiting for boot,
+ status = 0x%08x\n, __func__, r);
return (-1);
}
@@ -1014,7 +1015,7 @@
boot-br_zero_hi = 0;
/* See if it's waiting for boot, and try to boot it */
- for (i = 0; i 1; i++) {
+ for (i = 0; i 2; i++) {
r = READ_REG(sc, TXP_A2H_0);
if (r == STAT_WAITING_FOR_BOOT)
break;
@@ -1022,7 +1023,8 @@
}
if (r != STAT_WAITING_FOR_BOOT) {
- device_printf(sc-sc_dev, not waiting for boot\n);
+ device_printf(sc-sc_dev, %s: not waiting for boot,
+ status = 0x%08x\n, __func__, r);
return(ENXIO);
}
Re: Can't get if_txp(4) to attach to a 3CR990B-TXM NIC
On Thu, Jun 14, 2007 at 12:58:07PM +0900, To Freddie Cash wrote: On Wed, Jun 13, 2007 at 09:01:39AM -0700, Freddie Cash wrote: On Tuesday 12 June 2007 09:15 pm, Pyun YongHyeon wrote: On Tue, Jun 12, 2007 at 10:20:11AM -0700, Freddie Cash wrote: On Friday 08 June 2007 09:59 pm, Pyun YongHyeon wrote: On Fri, Jun 08, 2007 at 09:13:37AM -0700, Freddie Cash wrote: Good morning, I'm having a bit of an issue getting a 3CR990B-TXM NIC detected and usable. Just wondering if anyone knows of any issues with this NIC chipset and/or with the motherboard chipset. The motherboard is a Biostar GeForce 6100 AM2 using an nVidia nForce 410 chipset and nVidia GeForce 6100 vide chipset. I've tried FreeBSD 6.1, 6.2, 6-STABLE (from Wed), and 7-CURRENT (from Thu) on this system. Everything installs nicely, everything on the board is detected correctly and usable. It's just the PCI NIC that doesn't work. If I compile a custom kernel without any network drivers in it, and then kldload if_txp, the following appears (same message on all 4 versions): txp0: 3Com 3cR990B-TXM Etherlink with 3XP Processor port 0xbc00-0xbc7f mem 0xfdcff000-0xfdcff07f irq 16 at device 8.0 on pci3 txp0: not waiting for boot device_attach: txp0 attach returned -1 Would you try attached path? It wouldn't fix your issue but it will handle failure of contigmalloc as expected. Patch applies cleanly, module compiles cleanly, and module is kldloaded cleanly. But same error message as before, and no txp0 device is created. Tested on 7-CURRENT from last week. Thanks for testing! It seems that the message will show up in case of firmware loading/ring initialization failure. Try attached patch which will show failing function name. Patch uplied cleanly, module compiled clealy, and module was kldloaded cleanly. Error message is now: txp0: 3Com 3cR990B-TXM Etherlink with 3XP Processor port 0xbc00-0xbc7f mem 0xfdcff000-0xfdcff07f irq 18 at device 6.0 on pci3 txp0: txp_download_fw: not waiting for boot device_attach: txp0 attach returned -1 The IRQ and device numbers changed as it's in a different PCI slot than before. Looks like your guess was right, there's something not working right in the firmware download. Revert previous patch and apply attached patch again. Please give it spin and let me know result. Because I don't have 3CR990 hardware it's very hard to fix it. I'm unsure remote debugging would help here. Btw, it seems the hardware looks very good(except for extra copying on strict alignment architecture) and it even supports TSO! We normally use 3C905-series and 3C980-series NICs. Our local PC vendor sent us these instead when we ordered low-profile NICs to put into our new firewall boxes (while we wait for the back-order on Intel gigabit dual-port, low-profile, PCIe NICs to be filled). I don't have experience from 3C980 but it seems the 3C990 with 3XP processor looks better hardware than 3C905/3C980 series. I was going to try upgrading the firmware on the NICs, as there's an update available on the 3Com website, but the installer requires a Windows box (tried via a DOS boot disk and get the Can't be run in DOS mode error), which we don't have available at the moment. Forgot to say an important thing. It seems that OpenBSD has a newer firmware image than that of FreeBSD. If you are still in trouble with firmware, try updating the firmware image at the following URL. http://people.freebsd.org/~yongari/txp/3c990img.h Just replace sys/dev/txp/3c990img.h with the file at the URL. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
