Re: HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
Hi, for information, I tested the latest patch from bz@ : http://sources.zabbadoz.net/freebsd/patchset/20061005-01-carp-v6-scope-ipfw.diff and carp with IPv6 is working fine again ! More information in the PR (kern/98622) thanks a lot -- Philippe Pegon Bruce A. Mah wrote: If memory serves me right, Philippe Pegon wrote: In June 2006, I opened a PR (kern/98622) about a regression on CARP with IPv6 addresses: CARP is not usable with IPv6. Since I tracked down the culprit commit (see appropriate info in the PR), I can affirm that this regression appeared before the 6.1-RELEASE. bz@ has just recently (a couple of hours ago) updated kern/98622 with a possible fix. It'd be really useful if you (or anyone else experiencing this problem) could try this out and give him some feedback. (I know that you, Philippe, know all this already, but I wanted to get the information out to a wider audience.) Cheers, Bruce. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog Timeout - bge devices
Hi, On this subject, does somebody know why there is no pending issues listed at http://www.freebsd.org/releases/6.2R/todo.html ? -- Philippe Pegon Jeremy Chadwick wrote: On Wed, Oct 04, 2006 at 02:34:16PM +1000, John Marshall wrote: $ dmesg | grep bge bge0: Broadcom BCM5705K Gigabit Ethernet, ASIC rev. 0x3003 mem 0xe820-0xe820 irq 17 at device 4.0 on pci4 miibus1: MII bus on bge0 bge0: Ethernet address: 00:0b:cd:e7:51:ba bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP As far as SCHED_ULE goes, if you have issues with it, use SCHED_4BSD. 4BSD is still the default, and definitely works. I've run into too many issues (in the past; maybe some have since been dealt with) with ULE, so I stick purely with 4BSD. Now, about watchdog timeouts in general -- there's a pending issue which is still under investigation. Please see this thread: http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028792.html Yes, it's long, but it does pertain to bge (despite the subject stating em). After you read it all, or most of it, you should probably partake in the convo there. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
FreeBSD Security Officer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, Hi, On October 31st, FreeBSD 5.3 and FreeBSD 5.4 will have reached their End of Life and will no longer be supported by the FreeBSD Security Team. Users of either of those FreeBSD releases are strongly encouraged to upgrade to FreeBSD 5.5 or FreeBSD 6.1 before that date. In addition, the FreeBSD 6.0 End of Life is presently scheduled for November 30th. Depending upon the progress of the FreeBSD 6.2 release cycle, this may be delayed until December 31st in order to allow time for users of FreeBSD 6.0 to upgrade to FreeBSD 6.2. I'm a bit worried about the EoL of FreeBSD 6.0. In June 2006, I opened a PR (kern/98622) about a regression on CARP with IPv6 addresses: CARP is not usable with IPv6. Since I tracked down the culprit commit (see appropriate info in the PR), I can affirm that this regression appeared before the 6.1-RELEASE. Some of our main servers provide redundant services (DNS, Webmail, LDAP) based on CARP, with equivalent functionnality over IPv4 or IPv6. Since we cannot degrade IPv6 service, our servers are stick to 6.0-RELEASE. This problem has been reported to re@, but the TODO list for 6.2 doesn't mention it (it is still empty, in fact). As a campus network operator, we are proud to offer bleeding edge service to our 50K users, and we advocate FreeBSD locally since it was the ideal OS to run IPv6 service. In order to continue to provide IPv6 service, do we have to run an obsolete system (with all security risks involved), or do we have to choose another system? Please, either support 6.0-RELEASE longer, or (better) help us correct this problem! Thanks in advance, Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]
vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Smart Array 64xx Controller' class= mass storage subclass = RAID [EMAIL PROTECTED]:1:0: class=0x010400 card=0x40910e11 chip=0x00460e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Smart Array 64xx Controller' class= mass storage subclass = RAID [EMAIL PROTECTED]:2:0: class=0x02 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:2:1: class=0x02 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:3:0: class=0x03 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Rage XL PCI' class= display subclass = VGA [EMAIL PROTECTED]:4:0: class=0x088000 card=0xb2060e11 chip=0xb2030e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'iLo Integrated Lights Out Processor' class= base peripheral [EMAIL PROTECTED]:4:2: class=0x088000 card=0xb2060e11 chip=0xb2040e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'iLo Integrated Lights Out Processor' class= base peripheral -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2
Hi, it's just a me too. On our ftp server (ftp8.fr.freebsd.org), sometimes we see some watchdog timeout in the log with a bge card, but maybe it's not the same problem... : /var/log/messages:Sep 23 02:47:06 anubis kernel: bge1: watchdog timeout -- resetting /var/log/messages:Sep 23 02:47:06 anubis kernel: bge1: link state changed to DOWN /var/log/messages:Sep 23 02:47:11 anubis kernel: bge1: link state changed to UP /var/log/messages.0.bz2:Sep 12 22:22:48 anubis kernel: bge1: watchdog timeout -- resetting /var/log/messages.0.bz2:Sep 12 22:22:48 anubis kernel: bge1: link state changed to DOWN /var/log/messages.0.bz2:Sep 12 22:22:51 anubis kernel: bge1: link state changed to UP /var/log/messages.0.bz2:Sep 17 15:22:01 anubis kernel: bge1: watchdog timeout -- resetting /var/log/messages.0.bz2:Sep 17 15:22:01 anubis kernel: bge1: link state changed to DOWN /var/log/messages.0.bz2:Sep 17 15:22:06 anubis kernel: bge1: link state changed to UP /var/log/messages.0.bz2:Sep 20 12:13:07 anubis kernel: bge1: watchdog timeout -- resetting /var/log/messages.0.bz2:Sep 20 12:13:07 anubis kernel: bge1: link state changed to DOWN /var/log/messages.0.bz2:Sep 20 12:13:11 anubis kernel: bge1: link state changed to UP /var/log/messages.1.bz2:Sep 6 08:33:54 anubis kernel: bge1: watchdog timeout -- resetting /var/log/messages.1.bz2:Sep 6 08:33:54 anubis kernel: bge1: link state changed to DOWN /var/log/messages.1.bz2:Sep 6 08:33:59 anubis kernel: bge1: link state changed to UP /var/log/messages.2.bz2:Sep 4 17:39:25 anubis kernel: bge1: link state changed to DOWN /var/log/messages.2.bz2:Sep 4 17:39:28 anubis kernel: bge1: link state changed to UP /var/log/messages.3.bz2:Aug 29 12:09:36 anubis kernel: bge0: watchdog timeout -- resetting /var/log/messages.3.bz2:Aug 29 12:09:36 anubis kernel: bge0: link state changed to DOWN /var/log/messages.3.bz2:Aug 29 12:09:41 anubis kernel: bge0: link state changed to UP /var/log/messages.4.bz2:Aug 22 15:44:00 anubis kernel: bge0: watchdog timeout -- resetting /var/log/messages.4.bz2:Aug 22 15:44:00 anubis kernel: bge0: link state changed to DOWN /var/log/messages.4.bz2:Aug 22 15:44:03 anubis kernel: bge0: link state changed to UP -- Philippe Pegon Patrick M. Hausen wrote: Hello! Well, the best I can say at the moment is, Wow. =-( I guess the thing to do here is to figure out if the problem lies with the em interrupt handler not getting run, or the taskqueue not getting run. I helped Pyun with some debugging by providing ssh access to a machine showing the (seemingly) same problem. At first he thought the interrupt handler of the em driver was the culprit, but we applied quite a few patches and tested afterwards - seems like the driver is not the cause. On -stable occasionally other people complained about very similar looking problems with bge and other drivers. My guess is, though I'm not a kernel developer, just an experienced admin, that em stands out as problematic just by coincidence. Certain onboard network components tend to come with certaiin chipsets and certain architectures. So, Pyun suggested it was a problem with the taskqueue that was introduced some time between 6.0 and 6.1. With my system (Tyan GT20 B5161G20) the problem shows when there is heavy disk and cpu activity, like make buildworld. I made sure that the em interface doesn't share an interrupt with the SATA controller. When the problem occurs, I get the well known watchdog timeout messages and then the system's network activity over that interface freezes completely for a couple of minutes. Usually the system recovers after a while without reboot or other measures. What I can do: give ssh access to a system showing this behaviour including a network connection to another box, so one can transfer large amounts of data over a private LAN. I used FTP of a sparse big file. Prerequisite: fixed IP address of the machine that the developer whishes to use to connect to my system. HTH, Patrick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Snapshot duration, performance and how to avoid I/O lock
Ulrich Spörlein wrote: Hi, Hi, I have to create regular snapshots of several volumes roughly 1.4TB in size (each). But using mksnap_ffs takes a lot of time (45 minutes) and it looks like it could be speed up. [snip] Another thing is blocking other disk I/O while snapshotting. Right now I did a ls(1) in the .snap directory, so I understand the filesystem is now suspended. The workaround would then be to dont do that. But what if other snapshots are accessed during that time? I want to provide yesterdays snapshot to our users while taking the current snapshot and providing access to the newest data at the same time. I had seen that a long time ago (on another controller), and it seems it's not better today, our post from june 2005 without response at the end : http://docs.freebsd.org/cgi/getmsg.cgi?fetch=410600+0+archive/2005/freebsd-stable/20050612.freebsd-stable http://docs.freebsd.org/cgi/getmsg.cgi?fetch=463968+0+archive/2005/freebsd-stable/20050612.freebsd-stable -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
carp with IPv6 broken on 6.1
Hi, it seems that carp is really broken on FreeBSD 6.1 when an inet6 address is configured on a carp interface. Other persons observed the same symptoms. I filled a pr : kern/98622 thanks -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
carp with IPv6 broken on 6.1-RELEASE
Hi, it seems that carp is broken on FreeBSD 6.1-RELEASE when an inet6 address is configured on a carp interface. Since I upgraded from 6.0 to 6.1 (today) I can't see IPv6 carp advertisement with tcpdump. Did someone else observe this ? thanks -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compaq Proliant CISS slow writes
Ivan Voras wrote: I need to get a Proliant machine with 2 P3 processors running FreeBSD 6. I don't know much about the machine, I think it's ML 380 G2 or close to that, but I have physical access. So far, everything is fine (once the inability to boot from CD-ROM is circumvented), except one detail: horrible write performance on its CISS 5 RAID5 array. I get ~75MB/s burst (large blocks) reads, and only 5MB/s burst writes. I know how RAID5 works, but still, this is bad. The machine has been running Linux before this and performance was Ok - I didn't benchmark it but the feeling when working on it was normal, while on FreeBSD it's noticably slow in mixed read/write load. Is there anything I can try to improve this? In the verbose boot log there's a line that says the controller supports simple, performant and MEMQ modes, and the one that's used is simple - does this have any influence? If so, how to change it? Thanks! do you have write cache on your Smart Array 532 ? I had the same problem last year with a Smart Array 642, this controller is sold without write cache and we needed to buy the couple battery/write cache for it to have good write performance. -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compaq Proliant CISS slow writes
Ivan Voras wrote: Philippe Pegon wrote: do you have write cache on your Smart Array 532 ? I don't know (not my hardware) - how to find out? If I remember correctly, you can see it at boot time. I don't know how to find it when FreeBSD is up. Maybe someone else knows it (if it's possible) ? -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compaq Proliant CISS slow writes
Ivan Voras wrote: Philippe Pegon wrote: If I remember correctly, you can see it at boot time. I don't know how to find it when FreeBSD is up. Maybe someone else knows it (if it's possible) ? It doesn't mention cache when booting and initialising the array. I'm not sure, but I believe that the Smart Array 532 doesn't have write cache and doesn't support it : http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarray532/questionsanswers.html#11 and in the specs : http://h18004.www1.hp.com/products/quickspecs/10851_div/10851_div.html 32MB Memory optimizes performance and data throughput. NOTE: 32 MB of DRAM used for code, transfer buffers, and non-battery backed read cache -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic in 6-RELEASE-p4 with if_bridge and pf
Andrew Thompson wrote: On Thu, Feb 02, 2006 at 10:36:56AM +, James Seward wrote: Hello, I am trying to deploy a FreeBSD6 machine using if_bridge and pf to provide some protection for our Windows servers ;) During testing it seemed to work fine, but in production it panics frequently. When I came in to work this morning it was complaining about mbufs, so I have tried increasing the number of mbufs as explained in various places around the web. Despite the fact that it didn't seem to be getting near the limit of mbufs I set (8192) it has paniced another couple of times this morning already. I have now set it to 16k, but I don't currently hold much hope of this fixing it. Fatal trap 12: page fault while in kernel mode This is a known problem with 6.0R, see the 2005/11/16 entry in http://www.freebsd.org/releases/6.0R/errata.html. You should either upgrade to 6-STABLE or you can apply this patch to fix the problem. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_bridge.c.diff?r1=1.32r2=1.34 Why not MFCed that on RELENG_6_0 ? It's a critical bug. -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 buildworld failed
Viktorija wrote: Hello! mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/gen-perf.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/iterator.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/key-list.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/list-node.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/read-line.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/trace.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/vectors.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src /v ersion.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc cc: Internal error: Segmentation fault: 11 (program cc1plus) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/usr.bin/gperf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Why it is happening? Where can be a problem? http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#SIGNAL11 Thanks a lot, Viktoria -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ftp8.fr.freebsd.org HP msa20
Hi, we are hosting ftp8.fr.freebsd.org. The server is an HP DL360 G4 with an HP msa20 attached for mirrors with FreeBSD 6, the msa20 is connected to a smart array 642 card. Yesterday, due to bugs in the firmware of the msa20 (like false detection of disk failures), we upgraded it with version 2.4.56-6 and now FreeBSD cannot detect the msa20. Therefore ftp8.fr.freebsd.org is down. Somebody can help ? thanks in advance -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftp8.fr.freebsd.org HP msa20
Simon Barner wrote: Philippe Pegon wrote: Hi, we are hosting ftp8.fr.freebsd.org. The server is an HP DL360 G4 with an HP msa20 attached for mirrors with FreeBSD 6, the msa20 is connected to a smart array 642 card. Yesterday, due to bugs in the firmware of the msa20 (like false detection of disk failures), we upgraded it with version 2.4.56-6 and now FreeBSD cannot detect the msa20. Therefore ftp8.fr.freebsd.org is down. Somebody can help ? You'll probably need to provide more information, e.g. - pciconf -l - Expert from old dmesg where it was detected. - Maybe the kernel config you are right anubis# pciconf -l [EMAIL PROTECTED]:0:0:class=0x06 card=0x32000e11 chip=0x35908086 rev=0x0a hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x060400 card=0x0050 chip=0x35958086 rev=0x0a hdr=0x01 [EMAIL PROTECTED]:4:0: class=0x060400 card=0x0050 chip=0x35978086 rev=0x0a hdr=0x01 [EMAIL PROTECTED]:6:0: class=0x060400 card=0x0050 chip=0x35998086 rev=0x0a hdr=0x01 [EMAIL PROTECTED]:28:0:class=0x060400 card=0x0050 chip=0x25ae8086 rev=0x02 hdr=0x01 [EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x244e8086 rev=0x0a hdr=0x01 [EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x25a18086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:31:1: class=0x01018a card=0x32010e11 chip=0x25a28086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0044 chip=0x03298086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:0:2: class=0x060400 card=0x0044 chip=0x032a8086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:1:0:class=0x010400 card=0x409b0e11 chip=0x00460e11 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x010400 card=0x40910e11 chip=0x00460e11 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x02 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 [EMAIL PROTECTED]:2:1: class=0x02 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 [EMAIL PROTECTED]:3:0: class=0x03 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 [EMAIL PROTECTED]:4:0: class=0x088000 card=0xb2060e11 chip=0xb2030e11 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:4:2: class=0x088000 card=0xb2060e11 chip=0xb2040e11 rev=0x01 hdr=0x00 I cannot find an old dmesg (too many error messages have filled /var/log/messages*). The current dmesg : Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RELEASE #0: Thu Nov 24 20:51:49 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ANUBIS Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.15-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x659dSSE3,RSVD2,MON,DS_CPL,EST,TM2,CNTX-ID,CX16,b14 AMD Features=0x2000LM Hyperthreading: 2 logical CPUs real memory = 3758043136 (3583 MB) avail memory = 3678756864 (3508 MB) ACPI APIC Table: HP 0083 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic1: Changing APIC ID to 9 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard ioapic3 Version 2.0 irqs 72-95 on motherboard npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: HP P52 on motherboard acpi0: Power Button (fixed) pci_link0: ACPI PCI Link LNKA irq 7 on acpi0 pci_link1: ACPI PCI Link LNKB irq 0 on acpi0 pci_link2: ACPI PCI Link LNKC irq 7 on acpi0 pci_link3: ACPI PCI Link LNKD irq 3 on acpi0 pci_link4: ACPI PCI Link LNKE irq 0 on acpi0 pci_link5: ACPI PCI Link LNKF irq 5 on acpi0 pci_link6: ACPI PCI Link LNKG irq 5 on acpi0 pci_link7: ACPI PCI Link LNKH irq 3 on acpi0 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x908-0x90b on acpi0 cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci13: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 4.0 on pci0 pci6: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.0 on pci6 pci7: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 0.2 on pci6 pci10: ACPI PCI bus on pcib4 ciss0: HP Smart Array 642 port 0x5000-0x50ff mem 0xfdff-0xfdff1fff,0xfdf8-0xfdfb irq 72 at device 1.0 on pci10 ciss0: [GIANT-LOCKED] pcib5: ACPI PCI-PCI bridge at device 6.0 on pci0 pci3: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 28.0 on pci0 pci2: ACPI PCI bus on pcib6 ciss1: HP Smart Array 6i port 0x4000-0x40ff mem 0xfdef-0xfdef1fff,0xfde8-0xfdeb irq 24 at device 1.0 on pci2 ciss1: [GIANT-LOCKED] bge0: Broadcom
Re: ciss(4) driver in FreeBSD 6.x ...
Marc G. Fournier wrote: Hi .. Hi, Having read the man page, there is alot in there that makes me wonder whether going with a HP Smart Array P600 is a wise idea ... The Compaq ciss adapters require faked responses to get reasonable behavior out of them. In addition, the ciss command set is by no means adequate to support the functionality of a RAID controller, and thus the supported Compaq adapters utilize portions of the control protocol from earlier I'm specifically looking at the Proliant DL360, which has this card ... can you provide any comments, or insight, concerning what the man page states? Should I shy away from this controller? :( We have about thirty HP servers (DL360 and DL380) with FreeBSD 5 and 6, and they seem to work fine with ciss driver. Just this damn bug (kern/83375) which is not related to ciss driver... Thanks ... -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ciss(4) driver in FreeBSD 6.x ...
Holger Kipp wrote: On Thu, Nov 24, 2005 at 07:15:07PM +0100, Sascha Holzleiter wrote: On Thu, Nov 24, 2005 at 07:01:17PM +0100, Philippe Pegon wrote: We have about thirty HP servers (DL360 and DL380) with FreeBSD 5 and 6, and they seem to work fine with ciss driver. Just this damn bug (kern/83375) which is not related to ciss driver... do you know of any method to monitor these [ciss] controllers with FreeBSD, e.g. to detect drive failures? You could simply monitor the corresponding ciss syslog-messages and scan for state changes (ie from OK to something else). Apart from reboot-messages, you only get messages if states are changing... you could also use camcontrol(8) for example : camcontrol inquiry da0 -D Regards, Holger Kipp alogis AG, Berlin -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ciss(4) driver in FreeBSD 6.x ...
Sascha Holzleiter wrote: Hi, On Thu, Nov 24, 2005 at 07:01:17PM +0100, Philippe Pegon wrote: We have about thirty HP servers (DL360 and DL380) with FreeBSD 5 and 6, and they seem to work fine with ciss driver. Just this damn bug (kern/83375) which is not related to ciss driver... do you know of any method to monitor these controllers with FreeBSD, e.g. to detect drive failures? We use camcontrol(8) and a perl script. The perl script runs every five minutes a command like that : # camcontrol inquiry da0 -D pass0: COMPAQ RAID 5 VOLUME OK Fixed Direct Access SCSI-5 device and when the output changes, it sends an alarm by mail. -- Philippe Pegon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fw: GENERIC and DEFAULTS
dick hoogendijk wrote: On Wed, 02 Nov 2005 23:27:15 +0100 Philippe PEGON [EMAIL PROTECTED] wrote: Ken Menzel wrote: options INVARIANT_SUPPORT nooptions WITNESS nooptions WITNESS_SKIP_SPIN If I include GENERIC can I comment out the following? #cpuI486_CPU #cpuI586_CPU Does this make any difference? I have always done this out of habit. would it become in /usr/src/sys/i386/conf/NOTES we can read : # # You must specify at least one CPU (the one you intend to run on); # deleting the specification for CPUs you don't need to use may make # parts of the system run faster. # cpu I486_CPU cpu I586_CPU# aka Pentium(tm) cpu I686_CPU# aka Pentium Pro(tm) nocpu I486_CPU ? Or is this irrelevant as the build knows what CPU I have? if the description is true, it's relevant ;) Sure, but I think it's the *syntax* that matters here? options - nooptions / i486_cpu - no??? It's OK to leave GENERIC alone, but HOW are things switched off? sorry, my sentence was incomplete, I wanted to say : if the description is true, it's relevant to have this option -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fw: GENERIC and DEFAULTS
Ken Menzel wrote: options INVARIANT_SUPPORT nooptions WITNESS nooptions WITNESS_SKIP_SPIN If I include GENERIC can I comment out the following? #cpuI486_CPU #cpuI586_CPU Does this make any difference? I have always done this out of habit. would it become in /usr/src/sys/i386/conf/NOTES we can read : # # You must specify at least one CPU (the one you intend to run on); # deleting the specification for CPUs you don't need to use may make # parts of the system run faster. # cpu I486_CPU cpu I586_CPU# aka Pentium(tm) cpu I686_CPU# aka Pentium Pro(tm) nocpu I486_CPU ? Or is this irrelevant as the build knows what CPU I have? if the description is true, it's relevant ;) Thanks, Ken -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
Marc Olzheim wrote: On Mon, Oct 31, 2005 at 08:36:42AM -0700, Scott Long wrote: Anyone having updates for my showstopper page, please, notify me... http://www.stack.nl/%7Emarcolz/FreeBSD/showstoppers.html The pty problem is likely a side effect of known locking problems with ttys and ptys in general. This probably the weakest part of the kernel right now and I don't know of a good work-around for apps that use these extensively. That said, there doesn't seem to be much of a problem with casual use; I use screen(1) quite a bit on my production 6.0-RC mailserver+firewall. I know it doesn't trigger too often for most users, but still, for us, once a week per server on 2 production servers we installed FreeBSD 5 and 6 on, is way too often. :-( for information, we have the same problem on our productions servers with FreeBSD 5 and I know that we are not alone. We hoped a lot for a solution with FreeBSD 6 after this thread : http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-June/016154.html but I have just tested with FreeBSD 6.0-RC1 and the problem is always there :-( -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic with nfsd on 5.4-RELEASE-p1
Hi, last friday we had a panic on a FreeBSD 5.4-RELEASE-p1 visibly related to nfsd. This box exports home directory for approxymately 20 users with nfs. $ uname -a FreeBSD crc.u-strasbg.fr 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #2: Thu Jun 9 12:59:40 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CRC i386 The kernel config file and dmesg are attached. The kernel is launched with ACPI enabled. Fatal trap 12: page fault in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0739000 stack pointer = 0x10:0xe925ea08 frame pointer = 0x10:0xe925ea24 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 499 (nfsd) [thread pid 499 tid 100154 ] Stopped at nfs_rephead+0x144: movl%eax,0(%edx) db trace Tracing pid 499 tid 100154 td 0xc3954600 nfs_rephead(78,c9266c00,0,e925ea60,e925ea64) at nfs_rephead+0x144 nfsrv_remove(c9266c00,c3ff4b80,c3954600,e925eca8,e925eca4) at nfsrv_remove+0x5d9 nfssvc_nfsd(c3954600,0,c3954600,e925ece8,c3957388) at nfssvc_nfsd+0x406 nfssvc(c3954600,e925edl14,2,0,296) at nfssvc+0x1bc syscall(2f,2f,2f,bfbfeec4,8) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (155, FreeBSD ELF32, nfssvc), eip = 0x280c3b9b, esp = 0xbfbfeb1c, ebp = 0xbfbfeb38 --- -- Philippe PEGON # # CRC # machine i386 cpu I686_CPU ident CRC # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=15000# Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic# I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram
Re: FreeBSD as nfs-server
Claus Guttesen a écrit : Hi. Hi, Last week I phased out my remaining trusty FreeBSD nfs-server. The first was phased out three weeks ago. They have served me well for about two year and I have been *very* satisfied with the performance and stability. The below mentioned reasons made the decision easier to migrate to veritas volume manager on solaris. 1. Lack of a journaling filesystem. 2. Lack of a logical volume manager. My intent is *not* to start a flamewar, simpy stating why I had to migrate. Additional comments to item #1: We have background-fsck, what's wrong with that? Well, there is nothing wrong with that in a way. Background-fsck does work, but my nfs-server have had three unplanned reboots during that time, none of them was caused by the nfs-server itself, but caused by other factors. The server comes back up as it should and detects that the volumes wasn't unmounted in an orderly fashion and defers the volume to background-fsck. So far so good. When the background-fsck is done with one volume and it jumps to the next, my webservers connected to the nfs-server are unable to read and write to the nfs-volumes for a period of 15-30 minutes. The smallest (of several) volume is 400 GB and the largest (of several) is 2 TB. The outcome is that my website is seen as being inaccessible. This was with FreeBSD 5.2 beta through 5.4 I saw this behaviour. we switched our mail server to Linux for your first reason : see http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-June/thread.html#15751 So I'm delighted to read that the initial work on a journaling filesystem has started. Additional comments to item #2: Use vinum! Is it vinum or gvinum which is the future of FreeBSD? The docs related to vinum refers to some parameters in newfs not present in the manual-pages. As more volumes are added the task of configuring (g)vinum will become more and more timeconsuming and errorprone. Does it recover correctly in the event of a crash, how about fsck/newfs on volumes larger than 2 TB? The camcontrol program on FreeBSD is a very robust tool. This is one program I miss. Some parameters to the find- and date-commands on FreeBSD aren't there on solaris, so I'll keep the old nfs-server around for doing day2day maintenance. I'm keeping FreeBSD as webservers (of course). regards Claus -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: bge0: watchdog timeout -- resetting
Uzi Klein a écrit : Chris Phillips wrote: I've only ever had that message, on network cards that were about to die. The machine is a new HP DL380-G4 I doubt the card is dying (even tho its the easy way out for me) we have 3 HP DL380-G4 with FreeBSD 5.4-RELEASE-p3 and I never seen this message on them. On DL380-G4, there is 2 bge cards, have you tried bge1 for seeing if you have the same symptom ? Uzi Klein wrote: Hi Ever since i upgraded to 5.4-RELEASE-p3 i get these entries in /var/log/messages once in a while : kernel: bge0: watchdog timeout -- resetting Sorry, attached my kernel config and dmesg www# uname -v FreeBSD 5.4-RELEASE-p3 #1: Fri Jul 1 22:35:49 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DL380 U. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
Kris Kennaway a écrit : On Fri, Jul 01, 2005 at 03:03:35PM +0200, Marc Olzheim wrote: On Fri, Jul 01, 2005 at 12:41:39PM +0200, Marc Olzheim wrote: On Fri, Jul 01, 2005 at 12:14:58PM +0200, Marc Olzheim wrote: Somehow, this sounds familiar, i.e.: the lock cmpxchgl: Fatal trap 12: page fault while in kernel mode ... Stopped at 0xc05160c3 = knote+0x27:lock cmpxchgl %ecx,0x1c(%edx) Somehow I think I solved this last time by activating 'INVARIANTS'... I'll try that now. Let's paraphrase: I think i solved this last time by activating 'INVARIANTS'... Anyway, tried that and yes, it didn't crash in the last few hours, so I guess it works. Without INVARIANTS, it crashed within seconds. On the downside, my Gigabit performance dropped from 99 MB/sec to 80 MB/sec because of INVARIANTS. The panic appears to be an instance of a known bug in 5.4 (and INVARIANTS will not fix it, but may just delay the inevitable by changing timings). See Doug White's recent emails which point to a patch you should test. If you think about this mail : http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-June/016165.html and follow the thread, you will see that this patch doesn't solve the problem. The last mail which I can see from doug white about this problem is : http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-June/016495.html for the moment, it seems that there is no solution for 5.x Kris -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-p1 crash
Mitch Parks wrote:
On Sun, 19 Jun 2005, Doug White wrote:
On Fri, 17 Jun 2005, Mitch Parks wrote:
Below are details regarding another crash on a Dell 2600 SMP (HTT and
USB
disabled). It has been 9 days since the last crash. I didn't have the
serial
console in place for this last crash, but it is now.
As noted, the ttwakeup() panic is a known bug. The best thing we have for
a fix is this patch:
http://people.freebsd.org/~mlaier/tty.t_pgrp.diff
Please give it a try and report back if you have any more panics (or
don't :-) ).
Thanks! This patch appears to be for 5.3, but I manually applied the
chunk of the patch that didn't apply cleanly and the countdown is on.
I'll report back in 10 days unless something bad happens before then.
Below is the patch chunk #10 that I actually applied rather than the one
given. If I've done something bad here by removing the PGRP_LOCK please
let me know.
I'm not a kernel developper, but if you remove
PGRP_LOCK(tp-t_pgrp);
and the PGRP_UNLOCK(tp-t_pgrp) in the if condition (removed by the
orginal patch)
there is maybe another PGRP_UNLOCK(tp-t_pgrp); to remove if the if
condition doesn't match, line 2528 in the original 5.4-p1 tty.c ?
Hunk #6 succeeded at 1154 (offset -51 lines).
Hunk #7 succeeded at 1215 (offset -6 lines).
Hunk #8 succeeded at 1203 (offset -51 lines).
Hunk #9 succeeded at 1946 (offset -5 lines).
Hunk #10 failed at 2562.
Hunk #11 succeeded at 2847 (offset -212 lines).
1 out of 11 hunks failed--saving rejects to tty.c.rej
@@ -2495,19 +2511,21 @@
* On return following a ttyprintf(), we set tp-t_rocount to 0 so
* that pending input will be retyped on BS.
*/
+ sx_slock(proctree_lock);
if (tp-t_session == NULL) {
+ sx_sunlock(proctree_lock);
ttyprintf(tp, not a controlling terminal\n);
tp-t_rocount = 0;
return;
}
if (tp-t_pgrp == NULL) {
+ sx_sunlock(proctree_lock);
ttyprintf(tp, no foreground process group\n);
tp-t_rocount = 0;
return;
}
- PGRP_LOCK(tp-t_pgrp);
- if ((p = LIST_FIRST(tp-t_pgrp-pg_members)) == 0) {
- PGRP_UNLOCK(tp-t_pgrp);
+ if ((p = LIST_FIRST(tp-t_pgrp-pg_members)) == NULL) {
+ sx_sunlock(proctree_lock);
ttyprintf(tp, empty foreground process group\n);
tp-t_rocount = 0;
return;
Or the complete patch:
http://kuoi.asui.uidaho.edu/~mitch/crash/tty_5.4.patch
Mitch Parks
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Philippe PEGON
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-p1 crash
Philippe PEGON wrote:
Mitch Parks wrote:
On Sun, 19 Jun 2005, Doug White wrote:
On Fri, 17 Jun 2005, Mitch Parks wrote:
Below are details regarding another crash on a Dell 2600 SMP (HTT
and USB
disabled). It has been 9 days since the last crash. I didn't have
the serial
console in place for this last crash, but it is now.
As noted, the ttwakeup() panic is a known bug. The best thing we have
for
a fix is this patch:
http://people.freebsd.org/~mlaier/tty.t_pgrp.diff
Please give it a try and report back if you have any more panics (or
don't :-) ).
Thanks! This patch appears to be for 5.3, but I manually applied the
chunk of the patch that didn't apply cleanly and the countdown is on.
I'll report back in 10 days unless something bad happens before then.
Below is the patch chunk #10 that I actually applied rather than the
one given. If I've done something bad here by removing the PGRP_LOCK
please let me know.
I'm not a kernel developper, but if you remove
PGRP_LOCK(tp-t_pgrp);
and the PGRP_UNLOCK(tp-t_pgrp) in the if condition (removed by the
orginal patch)
there is maybe another PGRP_UNLOCK(tp-t_pgrp); to remove if the if
condition doesn't match, line 2528 in the original 5.4-p1 tty.c ?
after having applied the patch (with your modification), there is no
sx_sunlock(proctree_lock) in the ttyinfo function if the three
conditions failed. Maybe we have just to replace
PGRP_UNLOCK(tp-t_pgrp); line 2528 by sx_sunlock(proctree_lock) ?
I think that we need the helps of a kernel developper.
Hunk #6 succeeded at 1154 (offset -51 lines).
Hunk #7 succeeded at 1215 (offset -6 lines).
Hunk #8 succeeded at 1203 (offset -51 lines).
Hunk #9 succeeded at 1946 (offset -5 lines).
Hunk #10 failed at 2562.
Hunk #11 succeeded at 2847 (offset -212 lines).
1 out of 11 hunks failed--saving rejects to tty.c.rej
@@ -2495,19 +2511,21 @@
* On return following a ttyprintf(), we set tp-t_rocount to
0 so
* that pending input will be retyped on BS.
*/
+ sx_slock(proctree_lock);
if (tp-t_session == NULL) {
+ sx_sunlock(proctree_lock);
ttyprintf(tp, not a controlling terminal\n);
tp-t_rocount = 0;
return;
}
if (tp-t_pgrp == NULL) {
+ sx_sunlock(proctree_lock);
ttyprintf(tp, no foreground process group\n);
tp-t_rocount = 0;
return;
}
- PGRP_LOCK(tp-t_pgrp);
- if ((p = LIST_FIRST(tp-t_pgrp-pg_members)) == 0) {
- PGRP_UNLOCK(tp-t_pgrp);
+ if ((p = LIST_FIRST(tp-t_pgrp-pg_members)) == NULL) {
+ sx_sunlock(proctree_lock);
ttyprintf(tp, empty foreground process group\n);
tp-t_rocount = 0;
return;
Or the complete patch:
http://kuoi.asui.uidaho.edu/~mitch/crash/tty_5.4.patch
Mitch Parks
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Philippe PEGON
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-p1 crash
Mitch Parks a écrit :
On Sun, 19 Jun 2005, Mitch Parks wrote:
On Sun, 19 Jun 2005, Doug White wrote:
As noted, the ttwakeup() panic is a known bug. The best thing we have
for
a fix is this patch:
http://people.freebsd.org/~mlaier/tty.t_pgrp.diff
Please give it a try and report back if you have any more panics (or
don't :-) ).
I'll report back in 10 days unless something bad happens before then.
*sigh* Ok, I'm back too soon. Suggestions?
same thing for me
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address= 0x4296bad0
fault code= supervisor write, page not present
instruction pointer= 0x8:0xc055740e
stack pointer= 0x10:0xe8f6e9b8
frame pointer= 0x10:0xe8f6e9c0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process= 34338 (sshd)
trap number= 12
panic: page fault
cpuid = 0
boot() called on cpu#0
Uptime: 17h9m7s
Dumping 2047 MB
...
#0 doadump () at pcpu.h:159
159 __asm __volatile(movl %%fs:0,%0 : =r (td));
#0 doadump () at pcpu.h:159
#1 0xc05357d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc0535afd in panic (fmt=0xc068b12f %s)
at /usr/src/sys/kern/kern_shutdown.c:566
#3 0xc06633b4 in trap_fatal (frame=0xe8f6e978, eva=1117174480)
at /usr/src/sys/i386/i386/trap.c:817
#4 0xc06630f7 in trap_pfault (frame=0xe8f6e978, usermode=0,
eva=1117174480)
at /usr/src/sys/i386/i386/trap.c:735
#5 0xc0662d51 in trap (frame=
{tf_fs = -1068367848, tf_es = -386531312, tf_ds = 16777232, tf_edi
= -9965
94328, tf_esi = 1117174476, tf_ebp = -386471488, tf_isp = -386471516,
tf_ebx = -
1003267468, tf_edx = 1117174476, tf_ecx = -1066423096, tf_eax = 0,
tf_trapno = 1
2, tf_err = 2, tf_eip = -1068141554, tf_cs = 8, tf_eflags = 66054,
tf_esp = -1003267584, tf_ss = -1003279104}) at
/usr/src/sys/i386/i386/trap.c:425
#6 0xc06513ea in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7 0xc0520018 in fork1 (td=0xc4335a74, flags=89, pages=-386471452,
procp=0xc056425d) at atomic.h:154
#8 0xc0557362 in selwakeuppri (sip=0xc4335a74, pri=89)
at /usr/src/sys/kern/sys_generic.c:1056
#9 0xc056425d in ttwakeup (tp=0x10206) at /usr/src/sys/kern/tty.c:2382
#10 0xc0562ee0 in ttymodem (tp=0xc4335a00, flag=0)
at /usr/src/sys/kern/tty.c:1639
#11 0xc0566beb in ptcopen (dev=0xc4332d00, flag=3, devtype=8192, td=0x0)
at linedisc.h:136
#12 0xc04f9f66 in spec_open (ap=0xe8f6ea80)
at /usr/src/sys/fs/specfs/spec_vnops.c:207
#13 0xc04f9cab in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:118
#14 0xc0594985 in vn_open_cred (ndp=0xe8f6ebe4, flagp=0xe8f6ece4, cmode=0,
cred=0xc3853880, fdidx=0) at vnode_if.h:228
#15 0xc059456a in vn_open (ndp=0x0, flagp=0xe8f6ece4, cmode=0, fdidx=3)
at /usr/src/sys/kern/vfs_vnops.c:91
#16 0xc058e417 in kern_open (td=0xc41f5d80, path=0x0,
pathseg=UIO_USERSPACE,
flags=3, mode=0) at /usr/src/sys/kern/vfs_syscalls.c:957
#17 0xc058e328 in open (td=0xc41f5d80, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:926
#18 0xc06636ef in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi =
671951917, tf_e
bp = -1077943096, tf_isp = -386470540, tf_ebx = 671959136, tf_edx =
671951944, t
f_ecx = 674495244, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip =
674002619, tf_cs = 31, tf_eflags = 658, tf_esp = -1077943188, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1009
#19 0xc065143f in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:201
#20 0x002f in ?? ()
#21 0x002f in ?? ()
#22 0x002f in ?? ()
#23 0x in ?? ()
#24 0x280d2c2d in ?? ()
#25 0xbfbfe4c8 in ?? ()
#26 0xe8f6ed74 in ?? ()
#27 0x280d4860 in ?? ()
#28 0x280d2c48 in ?? ()
#29 0x2833fb0c in ?? ()
#30 0x0005 in ?? ()
#31 0x000c in ?? ()
#32 0x0002 in ?? ()
#33 0x282c76bb in ?? ()
#34 0x001f in ?? ()
#35 0x0292 in ?? ()
#36 0xbfbfe46c in ?? ()
#37 0x002f in ?? ()
#38 0x in ?? ()
#39 0x in ?? ()
#40 0x in ?? ()
#41 0x in ?? ()
#42 0x6701c000 in ?? ()
#43 0xc41fac5c in ?? ()
#44 0xc41f5d80 in ?? ()
#45 0xe8f6eb34 in ?? ()
#46 0xe8f6eb1c in ?? ()
#47 0xc347f600 in ?? ()
#48 0xc0545d9f in sched_switch (td=0x280d2c2d, newtd=0x280d4860,
flags=Cannot access memory at address 0xbfbfe4d8
)
at /usr/src/sys/kern/sched_4bsd.c:881
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [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: 5.4-p1 crash
Robert Watson a crit :
This sounds very similar to a serial console related tty bug I was
experiencing on -STABLE a few months ago, and that is believed may have
been worked around in 5.4 tweaks before release. In particular, that
there are reference counting related bugs in the 5.x tty code that are
fixed by a partial rewrite of the tty code in 6.x, but that are too
large and disruptive to merge to RELENG_5. If the problem is
persisting, it may be worth trying to merge anyway, but it is a pretty
big change and would break device driver binary compatibility, etc.
What we might want to do here is wait until 6.x has settled out a bit
more, then consider merging it to 5.x once 6.x has gotten burned in with
similar workloads and continued to not illustrate the 5.x tty reference
bugs.
Thanks for your answer.
Like I said on anothers posts, we have a FreeBSD 5.4-p1 which connects every fifteen minutes with an
expect program to a lot of network devices for retrieving some informations, it seems that it is the
culprit, the server crashed almost everyday. We reduced the frequency to one per hour and that
attenuates the problem.
This panic is easy to reproduce with this simple expect program (see below) by running it 6 times
simultaneously and waiting a few hours, I tested it on a HP DL360 with 2 cpu. If that can help, I
can test this on current next week.
#! /usr/local/bin/expect
set timeout 60
set host [lindex $argv 0]
set pass PASSWORD
spawn ssh [EMAIL PROTECTED]
expect {
continue*(yes/no) { send yes\r ; exp_continue }
assword: { send $pass\r }
}
expect *# {
send ls\r
}
expect *# {
send exit\r
}
puts Done.
Robert N M Watson
--
Philippe PEGON
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-p1 crash
Kris Kennaway a crit : On Fri, Jun 17, 2005 at 03:23:19PM -0700, Mitch Parks wrote: Below are details regarding another crash on a Dell 2600 SMP (HTT and USB disabled). It has been 9 days since the last crash. I didn't have the serial console in place for this last crash, but it is now. Text includes: 1. backtrace 2. dmesg 3. kernel conf Since Dell diagnostics and Memtest check out fine, I'm kind of between a rock and a hard place here. I have a similar 2600 running 4.9 that is working great. I'd welcome any advice. Unfortunately this is a known bug in FreeBSD; check the archives for more discussion. Doug White tried to look at fixing it before 5.4-RELEASE but I think he gave up. do you know if someone works on it ? I sent two mail in freebsd-stable about it without solution and this bug is really annoying : http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-June/015952.html and http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-June/015864.html there is a PR for it : kern/74319 Kris thanks -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-p1 crash
Xin LI a crit : On Fri, Jun 17, 2005 at 07:53:52PM -0400, Kris Kennaway wrote: On Fri, Jun 17, 2005 at 03:23:19PM -0700, Mitch Parks wrote: Below are details regarding another crash on a Dell 2600 SMP (HTT and USB disabled). It has been 9 days since the last crash. I didn't have the serial console in place for this last crash, but it is now. Text includes: 1. backtrace 2. dmesg 3. kernel conf Since Dell diagnostics and Memtest check out fine, I'm kind of between a rock and a hard place here. I have a similar 2600 running 4.9 that is working great. I'd welcome any advice. Unfortunately this is a known bug in FreeBSD; check the archives for more discussion. Doug White tried to look at fixing it before 5.4-RELEASE but I think he gave up. Just curious... What's the problem? Is there known steps that can trigger it quickly so we can grab the bug? for me, it seems that it is an expect program which connects to a lot of network equipement with spawn ssh ... for retrieving some informations. For the moment, I reduced the frequency and the server crash happens much less often. Cheers, -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-p1 crash
Xin LI a crit :
On Fri, Jun 17, 2005 at 07:53:52PM -0400, Kris Kennaway wrote:
On Fri, Jun 17, 2005 at 03:23:19PM -0700, Mitch Parks wrote:
Below are details regarding another crash on a Dell 2600 SMP (HTT and USB
disabled). It has been 9 days since the last crash. I didn't have the
serial console in place for this last crash, but it is now.
Text includes:
1. backtrace
2. dmesg
3. kernel conf
Since Dell diagnostics and Memtest check out fine, I'm kind of between a
rock and a hard place here. I have a similar 2600 running 4.9 that is
working great. I'd welcome any advice.
Unfortunately this is a known bug in FreeBSD; check the archives for
more discussion. Doug White tried to look at fixing it before
5.4-RELEASE but I think he gave up.
Just curious...
What's the problem? Is there known steps that can trigger it quickly so
we can grab the bug?
I just tested in one FreeBSD-5.4-p1 box (HP DL360 with two CPU) and it seems this simple expect
program which runs six times simultaneously crashs the box after approximately 2 hours :
#! /usr/local/bin/expect
set timeout 60
set host [lindex $argv 0]
set pass PASSWORD
spawn ssh [EMAIL PROTECTED]
expect {
continue*(yes/no) { send yes\r ; exp_continue }
assword: { send $pass\r }
}
expect *# {
send ls\r
}
expect *# {
send exit\r
}
puts Done.
Cheers,
if that can help
--
Philippe PEGON
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CARP and VLAN interfaces (5.4)
Paul Civati a écrit : Philippe PEGON [EMAIL PROTECTED] wrote: I also tested it with em card and for me it only runs if I connect the network card after the boot, otherwise I have the INIT symptom on carp's interfaces. Did the patch apply cleanly? no I applied it to 5.4-REL sources, part of the code was already in there so I added the missing bits manually. Seems to work fine in my initial testing. I also added the missing bits manually, maybe I did a mistake... Actually I cannot test anymore, the firewall runs OpenBSD. -Paul- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proliant 380 G4
Palle Girgensohn a écrit : Hi! Just a quick check - a client is getting a Proliant 380 G4 with a 6i Raid controller. Haven't used this hardware before. Will it work fine with FreeBSD? Which version will work best, 5.4 or 4.11? Any peculiarities or things to think about? Any input appreciated! we have 3 Proliant 380 G4 and hardware works fine. For your information, I attach a dmesg of one of them. I've just another problem, but I don't think that it comes from hardware : http://lists.freebsd.org/pipermail/freebsd-stable/2005-June/015952.html Thanks Palle -- Philippe PEGON Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-STABLE #3: Thu May 19 20:35:36 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NS1A Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.15-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 2147430400 (2047 MB) avail memory = 2095968256 (1998 MB) ACPI APIC Table: HP 0083 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard ioapic3 Version 2.0 irqs 72-95 on motherboard ioapic4 Version 2.0 irqs 96-119 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: HP P51 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x908-0x90b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci2: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci2 pci3: ACPI PCI bus on pcib2 bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfdef-0xfdef irq 25 at device 1.0 on pci3 miibus0: MII bus on bge0 brgphy0: BCM5704 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:12:79:d8:a0:37 bge1: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfdee-0xfdee irq 26 at device 1.1 on pci3 miibus1: MII bus on bge1 brgphy1: BCM5704 10/100/1000baseTX PHY on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:12:79:d8:a0:36 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci2 pci4: ACPI PCI bus on pcib3 ciss0: HP Smart Array 6i port 0x4000-0x40ff mem 0xfdf8-0xfdfb,0xfdff-0xfdff1fff irq 51 at device 3.0 on pci4 pcib4: ACPI PCI-PCI bridge at device 6.0 on pci0 pci5: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 0.0 on pci5 pci6: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 0.2 on pci5 pci10: ACPI PCI bus on pcib6 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x2000-0x201f irq 16 at device 29.0 on pci0 usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x2020-0x203f irq 19 at device 29.1 on pci0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x2040-0x205f irq 18 at device 29.2 on pci0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x2060-0x207f irq 16 at device 29.3 on pci0 usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: serial bus, USB at device 29.7 (no driver attached) pcib7: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib7 pci1: display, VGA at device 3.0 (no driver attached) pci1: base peripheral at device 4.0 (no driver attached) pci1: base peripheral at device 4.2 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0x500-0x50f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 acpi_tz0: Thermal Zone on acpi0 atkbdc0: Keyboard
Re: UPDATE panics on 5.4-RELEASE-p1
Vivek Khera a écrit : On Jun 13, 2005, at 11:01 AM, Philippe PEGON wrote: I contacted the author of the PR and he said he has the same problem on two servers which seems to work fine with Linux : a HP Proliant ML110 and an IBM. The only workaround he found is to disable SMP and HTT. For information our server is a HP DL380 with two cpu and I would like to use them ;) can you try a non bge ethernet? i had lockups on one system until i turned off the motherboard bge and plugged in an intel NIC. did you see the same panic with your bge ? Vivek Khera, Ph.D. +1-301-869-4449 x806 -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CARP and VLAN interfaces (5.4)
Paul Civati wrote: Has anyone tested this? yes, it doesn't work, carp with vlan aren't supported on FreeBSD. There is a thread about that on freebsd-pf : http://lists.freebsd.org/mailman/htdig/freebsd-pf/2005-May/001033.html It doesn't seem to work for me (although from some brief googling I got the impression it should). In my testing the carp0 for em3 interface negotiates MASTER/BACKUP as it should, however the carp1 interface never leaves the 'INIT' state. From another host in the 111 .1q VLAN/subnet I can ping .67 and .66 (the other CARP partner). em3: flags=18943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,POLLING mtu 1500 options=4bRXCSUM,TXCSUM,VLAN_MTU,POLLING inet X.X.X.3 netmask 0xffc0 broadcast X.X.X.63 inet6 fe80::230:48ff:fe83:4807%em3 prefixlen 64 scopeid 0x4 ether 00:30:48:83:48:07 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 carp0: flags=41UP,RUNNING mtu 1500 inet X.X.X.1 netmask 0xffc0 carp: BACKUP vhid 1 advbase 1 advskew 100 vlan111: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet Y.Y.Y.67 netmask 0xffe0 broadcast Y.Y.Y.95 inet6 fe80::230:48ff:fe83:4806%vlan111 prefixlen 64 scopeid 0x7 ether 00:30:48:83:48:07 media: Ethernet autoselect (100baseTX full-duplex) status: active vlan: 111 parent interface: em3 carp1: flags=0 mtu 1500 inet Y.Y.Y.65 netmask 0xffe0 carp: INIT vhid 2 advbase 1 advskew 100 -Paul- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CARP and VLAN interfaces (5.4)
Paul Civati a écrit : Philippe PEGON [EMAIL PROTECTED] wrote: Has anyone tested this? yes, it doesn't work, carp with vlan aren't supported on FreeBSD. There is a thread about that on freebsd-pf : http://lists.freebsd.org/mailman/htdig/freebsd-pf/2005-May/001033.html Thanks for the pointer, the patch listed below fixes the problem. http://lists.freebsd.org/pipermail/freebsd-net/2005-April/006997.html I also tested it with em card and for me it only runs if I connect the network card after the boot, otherwise I have the INIT symptom on carp's interfaces. Could someone commit this to -STABLE, or is it not the 'correct' fix? -Paul- -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
UPDATE panics on 5.4-RELEASE-p1
Hi, I searched in the problem report database and I found an open PR which seems to be related to the same panic : kern/74319. I contacted the author of the PR and he said he has the same problem on two servers which seems to work fine with Linux : a HP Proliant ML110 and an IBM. The only workaround he found is to disable SMP and HTT. For information our server is a HP DL380 with two cpu and I would like to use them ;) thanks -- Philippe PEGON Hi, we have a FreeBSD server which regularly panics (almost everyday). Moreover the console on serial port (booting with -h option) lockups the server when it panics, I took a screenshot with a camera and manually recopied it... config file and dmesg output attached. Fatal trap 12: page fault while in kernel mode cpuid = 1: apic id = 06 fault wirtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc062c6e3 stack pointer = 0x10:0xe926c9bc frame pointer = 0x10:0xe926c9c8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 99772 (expect) [thread pid 99772 tid 100159 ] Stopped at knote+0x27: lock cmpxchgl %ecx,0x1c(%edx) db where Tracing pid 99772 tid 100159 td 0xc394cd80 knote(c3b04080,0,0,c3b04010,c3b04000) at knote+0x27 ttwakeup(c3b04000,c3b04000,c3b04000,c3fd8800,e926ca14) at ttwakeup+0x55 ttymodem(c3b04000,1) at ttymodem+0x170 ptcopen(c3fd8800,8003,2000,c394cd80,c08c5fa0) at ptcopen+0x63 spec_open(e926ca80,e926cb3c,c06a68ed,e926ca80,180) at spec_open+0x2b6 spec_vnoperate(e926ca80) at spec_vnoperate+0x13 vn_open_cred(e926cbe4,e926cce4,9a5,c574c700,3) at vn_open_cred+0x419 vn_open(e926cbe4,e926cce4,9a5,3,c060ae07) at vn_open+0x1e kern_open(c394cd80,8060dc7,0,8003,805ebb7) at kern_open+0xeb open(c394cd80,e926cd14,3,2,296) at open+0x18 syscall(2f,2f,2f,3,) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x2819f6bb, esp = 0xbfbfe5cc, ebp = 0xbfbfe5f8 --- thanks in advance -- Philippe PEGON Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE-p1 #2: Thu Jun 9 12:59:40 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CRC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.14-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 2147430400 (2047 MB) avail memory = 2095968256 (1998 MB) ACPI APIC Table: HP 0083 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic1: Changing APIC ID to 9 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard ioapic3 Version 2.0 irqs 72-95 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: HP P52 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x908-0x90b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci13: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 4.0 on pci0 pci6: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.0 on pci6 pci7: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 0.2 on pci6 pci10: ACPI PCI bus on pcib4 ciss0: HP Smart Array 642 port 0x5000-0x50ff mem 0xfdf8-0xfdfb,0xfdff-0xfdff1fff irq 72 at device 1.0 on pci10 pcib5: ACPI PCI-PCI bridge at device 6.0 on pci0 pci3: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 28.0 on pci0 pci2: ACPI PCI bus on pcib6 ciss1: HP Smart Array 6i port 0x4000-0x40ff mem 0xfde8-0xfdeb,0xfdef-0xfdef1fff irq 24 at device 1.0 on pci2 bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfde7-0xfde7 irq 25 at device 2.0 on pci2 miibus0: MII bus on bge0 brgphy0: BCM5704 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:12:79:3c:3d:5b bge1: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfde6-0xfde6 irq 26 at device 2.1 on pci2 miibus1: MII bus on bge1 brgphy1: BCM5704 10/100/1000baseTX PHY on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:12:79:3c:3d:5a
panics on 5.4-RELEASE-p1
Hi, we have a FreeBSD server which regularly panics (almost everyday). Moreover the console on serial port (booting with -h option) lockups the server when it panics, I took a screenshot with a camera and manually recopied it... config file and dmesg output attached. Fatal trap 12: page fault while in kernel mode cpuid = 1: apic id = 06 fault wirtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc062c6e3 stack pointer = 0x10:0xe926c9bc frame pointer = 0x10:0xe926c9c8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 99772 (expect) [thread pid 99772 tid 100159 ] Stopped at knote+0x27: lock cmpxchgl %ecx,0x1c(%edx) db where Tracing pid 99772 tid 100159 td 0xc394cd80 knote(c3b04080,0,0,c3b04010,c3b04000) at knote+0x27 ttwakeup(c3b04000,c3b04000,c3b04000,c3fd8800,e926ca14) at ttwakeup+0x55 ttymodem(c3b04000,1) at ttymodem+0x170 ptcopen(c3fd8800,8003,2000,c394cd80,c08c5fa0) at ptcopen+0x63 spec_open(e926ca80,e926cb3c,c06a68ed,e926ca80,180) at spec_open+0x2b6 spec_vnoperate(e926ca80) at spec_vnoperate+0x13 vn_open_cred(e926cbe4,e926cce4,9a5,c574c700,3) at vn_open_cred+0x419 vn_open(e926cbe4,e926cce4,9a5,3,c060ae07) at vn_open+0x1e kern_open(c394cd80,8060dc7,0,8003,805ebb7) at kern_open+0xeb open(c394cd80,e926cd14,3,2,296) at open+0x18 syscall(2f,2f,2f,3,) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x2819f6bb, esp = 0xbfbfe5cc, ebp = 0xbfbfe5f8 --- thanks in advance -- Philippe PEGON Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE-p1 #2: Thu Jun 9 12:59:40 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CRC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.14-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 2147430400 (2047 MB) avail memory = 2095968256 (1998 MB) ACPI APIC Table: HP 0083 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic1: Changing APIC ID to 9 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard ioapic3 Version 2.0 irqs 72-95 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: HP P52 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x908-0x90b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci13: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 4.0 on pci0 pci6: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.0 on pci6 pci7: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 0.2 on pci6 pci10: ACPI PCI bus on pcib4 ciss0: HP Smart Array 642 port 0x5000-0x50ff mem 0xfdf8-0xfdfb,0xfdff-0xfdff1fff irq 72 at device 1.0 on pci10 pcib5: ACPI PCI-PCI bridge at device 6.0 on pci0 pci3: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 28.0 on pci0 pci2: ACPI PCI bus on pcib6 ciss1: HP Smart Array 6i port 0x4000-0x40ff mem 0xfde8-0xfdeb,0xfdef-0xfdef1fff irq 24 at device 1.0 on pci2 bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfde7-0xfde7 irq 25 at device 2.0 on pci2 miibus0: MII bus on bge0 brgphy0: BCM5704 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:12:79:3c:3d:5b bge1: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfde6-0xfde6 irq 26 at device 2.1 on pci2 miibus1: MII bus on bge1 brgphy1: BCM5704 10/100/1000baseTX PHY on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:12:79:3c:3d:5a pcib7: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib7 pci1: display, VGA at device 3.0 (no driver attached) pci1: base peripheral at device 4.0 (no driver attached) pci1: base peripheral at device 4.2 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel 6300ESB UDMA100 controller port 0x500-0x50f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 18 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1
Re: Panic with amr and 5.4-PRERELEASE
Philippe PEGON wrote: Hi, I have a FreeBSD bi-processor box with amr device in FreeBSD 5.4-prerelease of this week. # uname -a FreeBSD sokaris2.u-strasbg.fr 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #3: Thu Mar 10 15:33:01 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SOKARIS2 i386 Starting a program which continuously polls the state of the raid array (amrstat, see source attached), and making a buildworld at the same time triggers a kernel panic. The problem is fairly easy to reproduce. Features added in the SMP kernel : altq, KDB, DDB, GDB (see config file and dmesg output attached). The kernel is launched with ACPI disabled. A stack trace of the kernel panic and the result of a remote gdb follow. Thank you by advance for your help, Philippe PEGON For information, Scott Long has committed a patch for amr.c in current last sunday which solved this problem. And it's now MFCed in RELENG_5. -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic with amr and 5.4-PRERELEASE
Hi, I have a FreeBSD bi-processor box with amr device in FreeBSD 5.4-prerelease of this week. # uname -a FreeBSD sokaris2.u-strasbg.fr 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #3: Thu Mar 10 15:33:01 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SOKARIS2 i386 Starting a program which continuously polls the state of the raid array (amrstat, see source attached), and making a buildworld at the same time triggers a kernel panic. The problem is fairly easy to reproduce. Features added in the SMP kernel : altq, KDB, DDB, GDB (see config file and dmesg output attached). The kernel is launched with ACPI disabled. A stack trace of the kernel panic and the result of a remote gdb follow. Thank you by advance for your help, Philippe PEGON PANIC lock order reversal 1st 0xc239994c AMR IO Lock (AMR IO Lock) @ /usr/src/sys/dev/amr/amr.c:487 2nd 0xc29fdd28 user map (user map) @ /usr/src/sys/vm/vm_map.c:2998 KDB: stack backtrace: kdb_backtrace(,c08d3f20,c08d4970,c086802c,c08f7f58) at kdb_backtrace+0x29 witness_checkorder(c29fdd28,9,c0821569,bb6,c08ccb60,0,c080cb81,9d) at witness_checkorder+0x49d _sx_xlock(c29fdd28,c0821569,bb6) at _sx_xlock+0x2c _vm_map_lock_read(c29fdce4,c0821569,bb6,28cc360,c2a74b04) at _vm_map_lock_read+0x37 vm_map_lookup(f157aa6c,0,2,f157aa70,f157aa60) at vm_map_lookup+0x28 vm_fault(c29fdce4,0,2,8,c2a75c80) at vm_fault+0x66 trap_pfault(f157ab34,0,0) at trap_pfault+0xd2 trap(c0600018,c0860010,10,0,c2dbd200) at trap+0x2f1 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc04b3696, esp = 0xf157ab74, ebp = 0xf157ab74 --- amr_releasecmd(0,c2dbd1c0,c0865180,c2ce0800,c0865180) at amr_releasecmd+0x6 amr_ioctl(c08ca0d8,c0304301,c2dbd200,1,c2a75c80) at amr_ioctl+0x2cc spec_ioctl(f157ac08,f157acb4,c0669396,f157ac08,c08ade40) at spec_ioctl+0x11d spec_vnoperate(f157ac08) at spec_vnoperate+0x13 vn_ioctl(c26a0dd0,c0304301,c2dbd200,c29cd280,c2a75c80) at vn_ioctl+0x1ee ioctl(c2a75c80,f157ad14,3,1,293) at ioctl+0x344 syscall(2f,2f,2f,bfbfed00,bfbfecf8) at syscall+0x213 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280aeea4, esp = 0xbfbfe2e4, ebp = 0xbfbfe340 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 01 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc04b3696 stack pointer = 0x10:0xf157ab74 frame pointer = 0x10:0xf157ab74 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 11725 (amrstat) [thread pid 11725 tid 100148 ] Stopped at amr_releasecmd+0x6: movl$0,0(%edx) db trace Tracing pid 11725 tid 100148 td 0xc2a75c80 amr_releasecmd(0,c2dbd1c0,c0865180,c2ce0800,c0865180) at amr_releasecmd+0x6 amr_ioctl(c08ca0d8,c0304301,c2dbd200,1,c2a75c80) at amr_ioctl+0x2cc spec_ioctl(f157ac08,f157acb4,c0669396,f157ac08,c08ade40) at spec_ioctl+0x11d spec_vnoperate(f157ac08) at spec_vnoperate+0x13 vn_ioctl(c26a0dd0,c0304301,c2dbd200,c29cd280,c2a75c80) at vn_ioctl+0x1ee ioctl(c2a75c80,f157ad14,3,1,293) at ioctl+0x344 syscall(2f,2f,2f,bfbfed00,bfbfecf8) at syscall+0x213 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280aeea4, esp = 0xbfbfe2e4, ebp = 0xbfbfe340 --- db ps pid proc uid ppid pgrp flag stat wmesgwchan cmd 11725 c2a74a980 493 11725 0004002 [CPU 0] amrstat 11724 c263a1c40 11674 2633 0004002 [SLPQ getblk 0xd633583c][SLP] make 11674 c2a06a980 11672 2633 0004002 [SLPQ wait 0xc2a06a98][SLP] sh 11672 c2af03880 8684 2633 0004002 [SLPQ select 0xc08f8064][SLP] make 8684 c2a7454c0 8681 2633 0004002 [SLPQ wait 0xc2a7454c][SLP] sh 8681 c2af07100 8678 2633 0004002 [SLPQ select 0xc08f8064][SLP] make 8678 c2a030000 8660 2633 0004002 [SLPQ wait 0xc2a03000][SLP] sh 8660 c2a0654c0 2722 2633 0004002 [SLPQ select 0xc08f8064][SLP] make 2722 c2a060000 2675 2633 0004002 [SLPQ wait 0xc2a06000][SLP] sh 2675 c263d7100 2672 2633 0004002 [SLPQ select 0xc08f8064][SLP] make 2672 c263da980 2633 2633 0004002 [SLPQ wait 0xc263da98][SLP] sh 2633 c2a03e200 1191 2633 0004002 [SLPQ select 0xc08f8064][SLP] make 1463 c2a033880 47864 0004000 [SLPQ biord 0xd655787c][SLP] fsck_ufs 1191 c26911c40 930 1191 0004002 [SLPQ wait 0xc26911c4][SLP] bash 930 c263a3880 420 930 100 [SLPQ select 0xc08f8064][SLP] sshd 493 c269454c0 490 493 0004002 [SLPQ wait 0xc269454c][SLP] bash 490 c26941c40 420 490 100 [SLPQ select 0xc08f8064][SLP] sshd 489 c263ac5c0 1 489 0004002 [SLPQ ttyin 0xc25fce10][SLP] login 488 c263ae200 1 488 0004002 [SLPQ ttyin 0xc22c8810][SLP] getty 487 c238fe20
Re: Panic with amr and 5.4-PRERELEASE
My first attachment did not pass.
amrstat.c :
/* amrstat.c 2002/04/10
*
* Author: Pierre David [EMAIL PROTECTED]
*/
#include stdio.h
#include stdlib.h
#include fcntl.h
#include errno.h
#include machine/param.h
#include /usr/src/sys/dev/amr/amr_compat.h
#include /usr/src/sys/dev/amr/amrreg.h
#include /usr/src/sys/dev/amr/amrio.h
#define NATTEMPTS 5
#define SLEEPTIME 10 /* microseconds */
int nattempts = NATTEMPTS ; /* # of attempts before giving up */
int sleeptime = SLEEPTIME ; /* between attempts, in ms */
/*
* Include lookup tables, and a function to match a code to a string.
*
* XXX
* Lookup tables cannot be included, since they require symbols from
* amrreg.h which need in turn the _KERNEL define.
*/
/* #define AMR_DEFINE_TABLES */
/* #include /usr/src/sys/dev/amr/amr_tables.h */
/*
* Offsets in an amr_user_ioctl.au_cmd [] array
* See amrio.h
*/
#define MB_COMMAND 0
#define MB_CHANNEL 1
#define MB_PARAM2
#define MB_PAD 3
#define MB_DRIVE4
#define FIRMWARE_40LD 1
#define FIRMWARE_8LD2
#define NTAB(tab) (sizeof tab / sizeof tab [0])
int amr_enquiry (int fd, size_t bufsize, void *buffer, u_int8_t cmd,
u_int8_t cmdsub, u_int8_t cmdqual)
{
struct amr_user_ioctl am ;
int r, i ;
am.au_cmd [MB_COMMAND] = cmd ;
am.au_cmd [MB_CHANNEL] = cmdsub ;
am.au_cmd [MB_PARAM] = cmdqual ;
am.au_cmd [MB_PAD] = 0 ;
am.au_cmd [MB_DRIVE] = 0 ;
am.au_buffer = buffer ;
am.au_length = bufsize ;
am.au_direction = AMR_IO_READ ;
am.au_status = 0 ;
i = 0 ;
r = -1 ;
while (i nattempts r == -1)
{
r = ioctl (fd, AMR_IO_COMMAND, am) ;
if (r == -1)
{
if (errno != EBUSY)
{
perror (ioctl enquiry) ;
exit (1) ;
}
else usleep (sleeptime) ;
}
i++ ;
}
return am.au_status ;
}
void usage (void)
{
fprintf (stderr, usage: amstat [-v][-f spec][-a #attempts][-t
time][-g][-l lvol]\n) ;
exit (1) ;
}
/**
* Card description
*/
int describe_card (int fd, int verbosity, int globalparam)
{
int r ;
char buffer [2048] ;
struct amr_enquiry *ae ;
int cardtype ;
/*
* Try the 40LD firmware interface
*/
r = amr_enquiry (fd, sizeof buffer, buffer,
AMR_CMD_CONFIG, AMR_CONFIG_PRODUCT_INFO, 0) ;
if (r == AMR_STATUS_SUCCESS)
{
struct amr_prodinfo *ap ;
if (globalparam)
{
ap = (struct amr_prodinfo *) buffer ;
printf (Product =\t%.80s\n, ap-ap_product) ;
printf (Firmware =\t%.16s\n, ap-ap_firmware) ;
printf (BIOS =\t%.16s\n, ap-ap_bios) ;
printf (SCSI Channels =\t%d\n,ap-ap_nschan) ;
printf (Fibre Loops =\t%d\n, ap-ap_fcloops) ;
printf (Memory size =\t%d MB\n, ap-ap_memsize) ;
if (verbosity = 1)
{
printf (Ioctl = %d (%s)\n,FIRMWARE_40LD, 40LD) ;
printf (Signature =\t0x%08x\n, ap-ap_signature) ;
printf (Configsig =\t0x%08x\n, ap-ap_configsig) ;
printf (Subsystem =\t0x%04x\n, ap-ap_subsystem) ;
printf (Subvendor =\t0x%04x\n, ap-ap_subvendor) ;
printf (Notify counters =\t%d\n, ap-ap_numnotifyctr) ;
}
}
return FIRMWARE_40LD ;
}
/*
* Try the 8LD firmware interface
*/
r = amr_enquiry (fd, sizeof buffer, buffer, AMR_CMD_EXT_ENQUIRY2,
0, 0) ;
ae = (struct amr_enquiry *) buffer ;
if (r == AMR_STATUS_SUCCESS)
{
cardtype = ae-ae_signature ;
}
else
{
r = amr_enquiry (fd, 2048, buffer, AMR_CMD_ENQUIRY, 0, 0) ;
cardtype = 0 ;
}
if (r == AMR_STATUS_SUCCESS)
{
if (globalparam)
{
char *product ;
char bios [100], firmware [100] ;
int i ;
static struct {
char *product ;
int signature ;
} prodtable [] = {
Series 431, AMR_SIG_431,
Series 438, AMR_SIG_438,
Series 762, AMR_SIG_762,
Integrated HP NetRAID (T5), AMR_SIG_T5,
Series 466, AMR_SIG_466,
Series 467, AMR_SIG_467,
Integrated HP NetRAID (T7), AMR_SIG_T7,
Series 490, AMR_SIG_490,
} ;
for (i = 0 ; i NTAB (prodtable) ; i++)
{
if (cardtype == prodtable [i].signature)
{
product = prodtable [i].product ;
break ;
}
}
if (product == NULL)
Re: sshd stops accepting connections
Simon L. Nielsen wrote: Hello Today I suddenly couldn't log in via ssh to a server I upgraded to FreeBSD 5.3-RELEASE 4 days ago. When I tried connect to port 22 using telnet(1) the following just happend: [EMAIL PROTECTED]:~] telnet 192.168.3.2 22 Trying 192.168.3.2... Connected to jet.nitro.dk. Escape character is '^]'. Connection closed by foreign host. I'd seen the same problem in 5.3 release. I've found this in the changelog of openssh and it seems to be very similar : ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/ChangeLog and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=252676 ... 20040711 - (dtucker) [auth-pam.c] Check for zero from waitpid() too, which allows the monitor to properly clean up the PAM thread (Debian bug #252676). ... -- Philippe PEGON ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
