Re: Safe card to replace for ICP Vortex GDT8514RZ ...
On Jul 31, 2006, at 7:49 PM, User Freebsd wrote: I have a remote server, running the above RAID controller, that, as most ppl here have seen over the past few weeks, is causing endless headaches ... Official word from Adaptec is that FreeBSD is no longer a supported platform, so, I either live with the deadlocks, or try and figure out a suitable replacement for the card ... So, can anyone recommend a card to replace this with? Its a remote server, so I'm looking for something that will be plug-n-play, same slot that the GDT is in ... I realize that I'll have to reformat the server afterwards ... You may want to consider the LSI MegaRAID cards... There are various ones. Do you need the low profile format? Look at the 320-1lp for that otehrwise the 320-1 or 320-2x They have freebsd drivers and a command line management app. I am looking at this to replace an adaptec 2200s eventually (for different reasons than the OP). I have not used the SCSI LSI MegaRAID cards through I have some of their SATA RAID cards. Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Help my Harddrive stopped working!
I have an old Pentium III computer with FreeBSD 5.3 and I am using GEOM GBDE encryption on a few IDE-disks that are mounted on a PCI-ide controller. I had some important files on a less than 1 year old 300gb Maxtor harddrive (ad5) when it stopped working. The harddrive had been working ok, and it had been in the computer all the time, so no risk physical damage. Then I mounted and attached it and tried to move a few gb's of files to it and I got lots of WRITE_DMA errors all over the terminal. Then the computer crashed, next reboot I could attach it with gbde but not mount, due to I/O errors, and fsck said incorrect superblock. After second restart the computer could not find it, and the dmesg from the third restart is shown below. What shall I do to get my data back? I have approx 200mb of critical data there that I need to get back.. dmesg: Copyright (c) 1992-2004 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.3-RELEASE-p31 #1: Tue Jul 25 19:45:52 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (602.19-MHz 686-class CPU) Origin = GenuineIntel Id = 0x681 Stepping = 1 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 201310208 (191 MCool avail memory = 187326464 (178 MCool npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P3V_4X on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 cpu0: ACPI CPU (3 Cx states) on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xe400-0xe7ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C596B UDMA66 controller port 0xd800-0xd80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 5 at device 4.2 on pci0 uhci0: [GIANT-LOCKED] usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, HOST-PCI at device 4.3 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0xd000-0xd0ff mem 0xd580-0xd58000ff at device 9.0 on pci0 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:10:a7:09:57:f9 atapci1: SiI 0680 UDMA133 controller port 0xa400-0xa40f,0xa800-0xa803,0xb000-0xb007,0xb400-0xb403,0xb800-0xb807 mem 0xd500-0xd5ff irq 10 at device 11.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 rl1: RealTek 8139 10/100BaseTX port 0xa000-0xa0ff mem 0xd480-0xd48000ff at device 13.0 on pci0 miibus1: MII bus on rl1 rlphy1: RealTek internal media interface on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:10:a7:16:26:cc fdc0: floppy drive controller port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: ECP parallel printer port port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: Parallel port bus on ppc0 plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 orm0: ISA Option ROM at iomem 0xc-0xcafff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 602191945 Hz quality 800 Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to accept, logging unlimited acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% ad0: 6149MB WDC AC26400R/15.01J15 [13328/15/63] at ata0-master UDMA66 ad4: 190782MB WDC WD2000JB-00EVA0/15.05R15 [387621/16/63] at ata2-master UDMA100 ad5:
Re: em device hangs on ifconfig alias ...
Any status on this patch being merged in?
On Mon, 10 Jul 2006, Atanas wrote:
Pyun YongHyeon said the following on 7/7/06 8:32 PM:
On Fri, Jul 07, 2006 at 10:38:01PM +0100, Robert Watson wrote:
Yes -- basically, there are two problems:
(1) A little problem, in which an arp announcement is sent before the
link has
settled after reset.
(2) A big problem, in which the interface is gratuitously recent
requiring
long settling times.
I'd really like to see a fix to the second of these problems (not
resetting when an IP is added or removed, resulting in link
renegotiation); the first one I'm less concerned about, although it
would make some amount of sense to do an arp announcement when the link
goes up.
Ah, I see. Thanks for the insight.
How about the attached patch?
This patch seems to fix both of the issues, or at least this is what I see
now:
- the card no longer gets reset when adding an alias;
- the arp packet gets delivered;
- adding 250 aliases takes less than a second;
I haven't fully tested whether all 250 IP aliases were accessible (I used
non-routable IP addresses), but I suppose so. Also I couldn't stress the
patched driver enough to see whether it performs as expected.
But in overall it looks good. I guess some more testing might be needed in
order to merge the patch into the source tree.
Regards,
Atanas
Index: if_em.c
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.116
diff -u -r1.116 if_em.c
--- if_em.c 6 Jun 2006 08:03:49 - 1.116
+++ if_em.c 8 Jul 2006 03:30:36 -
@@ -67,6 +67,7 @@
#include netinet/in_systm.h
#include netinet/in.h
+#include netinet/if_ether.h
#include netinet/ip.h
#include netinet/tcp.h
#include netinet/udp.h
@@ -692,6 +693,9 @@
EM_LOCK_ASSERT(sc);
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
+ return;
if (!sc-link_active)
return;
@@ -745,6 +749,7 @@
{
struct em_softc *sc = ifp-if_softc;
struct ifreq *ifr = (struct ifreq *)data;
+ struct ifaddr *ifa = (struct ifaddr *)data;
int error = 0;
if (sc-in_detach)
@@ -752,9 +757,22 @@
switch (command) {
case SIOCSIFADDR:
- case SIOCGIFADDR:
- IOCTL_DEBUGOUT(ioctl rcv'd: SIOCxIFADDR (Get/Set Interface
Addr));
- ether_ioctl(ifp, command, data);
+ if (ifa-ifa_addr-sa_family == AF_INET) {
+ /*
+* XXX
+* Since resetting hardware takes a very long time
+* we only initialize the hardware only when it is
+* absolutely required.
+*/
+ ifp-if_flags |= IFF_UP;
+ if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ EM_LOCK(sc);
+ em_init_locked(sc);
+ EM_UNLOCK(sc);
+ }
+ arp_ifinit(ifp, ifa);
+ } else
+ error = ether_ioctl(ifp, command, data);
break;
case SIOCSIFMTU:
{
@@ -802,17 +820,19 @@
IOCTL_DEBUGOUT(ioctl rcv'd: SIOCSIFFLAGS (Set Interface
Flags));
EM_LOCK(sc);
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_flags ^ sc-if_flags)
+ IFF_PROMISC) {
+ em_disable_promisc(sc);
+ em_set_promisc(sc);
+ }
+ } else
em_init_locked(sc);
- }
-
- em_disable_promisc(sc);
- em_set_promisc(sc);
} else {
- if (ifp-if_drv_flags IFF_DRV_RUNNING) {
+ if (ifp-if_drv_flags IFF_DRV_RUNNING)
em_stop(sc);
- }
}
+ sc-if_flags = ifp-if_flags;
EM_UNLOCK(sc);
break;
case SIOCADDMULTI:
@@ -878,8 +898,8 @@
break;
}
default:
- IOCTL_DEBUGOUT1(ioctl received: UNKNOWN (0x%x),
(int)command);
- error = EINVAL;
+ error = ether_ioctl(ifp, command, data);
+ break;
}
return (error);
Index: if_em.h
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.h,v
retrieving revision 1.44
diff
ncplogin panic
Hi,
i had the same problem. See my thread on the freebsd-fs mailinglist
http://lists.freebsd.org/pipermail/freebsd-fs/2006-July/002060.html
After some research i use the attached patch against ncp_sock.c.
So it is not the real solution to this problem it only avoids the panics. I'm
using it quiet a while without any other known
problems.
Hopefully someone with more knowledge can help on this.
I also get some md_get_mem(461): incomplete copy messages which seem to do no
harm, so far.
Regards,
Maik
!!! Use atyour own risk !!!
--- ncp_sock.c.origFri Jan 7 02:45:49 2005
+++ ncp_sock.c Thu Jul 20 14:12:45 2006
@@ -189,7 +189,12 @@
struct thread *td = curthread;
struct ucred *cred = NULL;
-return so-so_proto-pr_usrreqs-pru_sopoll(so, events, cred, td);
+if ( td-td_selq.tqh_last == NULL ) {
+printf(ncp_poll: td-td_selq.tqh_last == NULL\n);
+return 0;
+}
+
+ return so-so_proto-pr_usrreqs-pru_sopoll(so, events, cred, td);
}
int
pach ends here ---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Safe card to replace for ICP Vortex GDT8514RZ ...
Hi! On Mon, Jul 31, 2006 at 10:49:27PM -0300, User Freebsd wrote: Official word from Adaptec is that FreeBSD is no longer a supported platform, so, I either live with the deadlocks, or try and figure out a suitable replacement for the card ... That's really really bad news. Oddly, ICP Vortex Germany told me the opposite wr/t to their new line of cards. They said, they were working on full FreeBSD support. I'll check what they have to say about the GDT controllers. We run typo3.org on four heavily loaded systems with these cards. We did not update to 6.x yet, because of fear of the mythical NFS deadlocks. Now things seem to get even worse. So, can anyone recommend a card to replace this with? Its a remote server, so I'm looking for something that will be plug-n-play, same slot that the GDT is in ... I realize that I'll have to reformat the server afterwards ... We just ordered this box here: http://www.intel.com/design/servers/storage/ssr212cc/ It contains two Intel SRCS28X RAID Controllers, that are supposedly supported by the amr driver and the Linux Megamgr utility. The system should arrive in about two weeks - if you're interested, I'll keep you updated. Regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Safe card to replace for ICP Vortex GDT8514RZ ...
On Mon, Jul 31, 2006 at 10:49:27PM -0300, User Freebsd wrote: I have a remote server, running the above RAID controller, that, as most ppl here have seen over the past few weeks, is causing endless headaches ... Official word from Adaptec is that FreeBSD is no longer a supported platform, so, I either live with the deadlocks, or try and figure out a suitable replacement for the card ... So, can anyone recommend a card to replace this with? Its a remote server, so I'm looking for something that will be plug-n-play, same slot that the GDT is in ... I realize that I'll have to reformat the server afterwards ... I contacted Achim Leubner not long ago, about wheather he still maintains and supports the iir(4) driver, as claimed in the SEE ALSO section of the manpage. His answer was yes. That all I know. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgpRkI7UGHFhN.pgp Description: PGP signature
Re: Safe card to replace for ICP Vortex GDT8514RZ ...
Hello! On Tue, Aug 01, 2006 at 09:51:59AM +0200, Patrick M. Hausen wrote: That's really really bad news. Oddly, ICP Vortex Germany told me the opposite wr/t to their new line of cards. They said, they were working on full FreeBSD support. I'll check what they have to say about the GDT controllers. OK - so here's the deal: The GDT products are officially EOE (End Of Engineering). ICP Vortex will not provide capacity to update their own driver for FreeBSD 6. The new products will feature full FreeBSD support, eventually. (couple of weeks, he said) Technically, the ICP guy was quite confident, that ICP's own driver for FreeBSD 4.x and 5.x didn't show the problems we have on FreeBSD 6 with the FreeBSD iir driver. He recommended using ICP's driver source as a reference when trying to fix the FreeBSD 6 driver. I'm not a kernel developer so I cannot really comment on this. HTH, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help my Harddrive stopped working!
On Tue, 2006-Aug-01 08:23:43 +0200, Lasse Edlund wrote: I had some important files on a less than 1 year old 300gb Maxtor harddrive (ad5) when it stopped working. The harddrive had been working ok, and it had been in the computer all the time, so no risk physical damage. Have you touched anything in the box? I'd check all the cables on the off-chance that one is lose as well as re-seating the controller. If none of this helps, I suspect you have a choice of restoring from backups or using the services of one of the data recovery companies. -- Peter Jeremy pgpyWSowBGs8m.pgp Description: PGP signature
Re: Help my Harddrive stopped working!
Le 1 août 2006 à 08:23, Lasse Edlund a écrit : I have an old Pentium III computer with FreeBSD 5.3 and I am using GEOM GBDE encryption on a few IDE-disks that are mounted on a PCI-ide controller. I had some important files on a less than 1 year old 300gb Maxtor harddrive (ad5) when it stopped working. The harddrive had been working ok, and it had been in the computer all the time, so no risk physical damage. Then I mounted and attached it and tried to move a few gb's of files to it and I got lots of WRITE_DMA errors all over the terminal. Then the computer crashed, next reboot I could attach it with gbde but not mount, due to I/O errors, and fsck said incorrect superblock. After second restart the computer could not find it, and the dmesg from the third restart is shown below. What shall I do to get my data back? I have approx 200mb of critical data there that I need to get back.. I had this kind of problem recently, and I was able to recover the entire data by finding a functional identical drive and swapping the logic boards. But then again I was lucky to find an identical drive, and the issue was a malfuntionning logic board... -- See you!!! PAIG Chong Woo. E-Mail : [EMAIL PROTECTED] ICQ : 1305386 Page web : http://www.valken.org --- Q: My Etch-A-Sketch has lines that prevent me from doing my art project. A: Pick it up and shake it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GIANT in arcmsr(4)
Dear Nikolas Britton, Thanks for your comment about UNIX format with arcmsr. I will change its coding style at 1.20.00.13. Generally, areca put its release driver on its ftp site ftp://ftp.areca.com.tw . But this site maintained by areca support team. And the driver always need passed their long term testing procedure but not last new pack. If I modify it and done a testing procedure by me. I will send it to you all. Best Regards Erich Chen - Original Message - From: Nikolas Britton [EMAIL PROTECTED] To: erich [EMAIL PROTECTED] Cc: (廣安科技)安可O [EMAIL PROTECTED]; [EMAIL PROTECTED]; FreeBSD Stable List freebsd-stable@freebsd.org Sent: Tuesday, August 01, 2006 10:47 AM Subject: Re: GIANT in arcmsr(4) On 7/31/06, erich [EMAIL PROTECTED] wrote: Dear Nikolas Britton, Sorry I had new arcmsr driver version 1.20.00.13 for FreeBSD i386/amd64/ppc plateform. This version add ARECA new generation RAID adapters ( SATA / SAS ) into arcmsr. Its xfer rate more than 800MB/sec. I need more time to test arcmsr on PowerMac G5 even SPARC machine in my Lab. Any comments and opinion with this driver will win acceptance. Best Regards Erich Chen Do you have a link to download v1.20.00.13? and have you MFC'd the changes we made back into your new code?: Here are the changes we made to 1.20.00.02: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/arcmsr/arcmsr.c Could I also suggest sed 's/.$//' to convert those pesky CR+LF Windows files to UNIX format. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic
On Tue, 25 Jul 2006, Graham Menhennitt wrote: Fatal trap 12: page fault while in kernel mode current process = 479 (mountd) I have the same panic reproducibly. Shutting off nfs_server_enable (i.e. mountd) in rc.conf prevents it. This is with 6-STABLE cvsupped yesterday. I'll get some more info and follow up the PR. I rebuilt my kernel (to enable debugging) and now it doesn't panic. So it seems that an old kernel (from around the end of May) with a new mountd (from Sunday) will crash. But a new kernel with a new mountd won't. FYI, I've managed to reproduce this on a 7-CURRENT kernel, so will try to take a look at this in detail in the next few days. It looks like a race during socket connect/accept for UNIX domain sockets, likely involving simultaneous close, which may be a sign of a bug in mountd (or the like) that triggers it. Of course, the kernel shouldn't panic under those circumstances. :-) Thanks, Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
GEOM_BDE: where is my partition?
Hi Folks, I have 4 GEOM_BDE encrypted partitions in one FreeBSD 6.1-PRERELEASE Server. Since the server anormally shutdown (power cut), one of partitions isn't more available. Here is the partitions: [EMAIL PROTECTED] /dev]# ls -laF /etc/gbde/ total 12 drwxr-xr-x 2 root wheel 512 Mar 23 15:33 ./ drwxr-xr-x 19 root wheel 2048 Jul 13 11:34 ../ -rw--- 1 root wheel16 Sep 26 2005 ad0s1g -rw--- 1 root wheel16 Sep 26 2005 ad1s1d -rw--- 1 root wheel16 Sep 27 2005 ad2s1d -rw--- 1 root wheel16 Mar 23 15:33 ad5s1c ad0s1g, ad1s1d, and ad2s1d are correctly mounted: [EMAIL PROTECTED] /dev]# mount | grep bde /dev/ad0s1g.bde on /data (ufs, NFS exported, local, soft-updates) /dev/ad1s1d.bde on /data1 (ufs, NFS exported, local, soft-updates) /dev/ad2s1d.bde on /data2 (ufs, NFS exported, local, soft-updates) But /dev/ad5s1c doesn't exist anymore!!! [EMAIL PROTECTED] /dev]# /sbin/gbde attach /dev/ad5s1c -l /etc/gbde/ad5s1c Enter passphrase: gbde: Attach to ad5s1c failed: Provider not found [EMAIL PROTECTED] /dev]# ls /dev/ad5s1c ls: /dev/ad5s1c: No such file or directory [EMAIL PROTECTED] /dev]# Any idea of how to recover the partition? What could happend? =/ Here is some info about my kernel: [EMAIL PROTECTED] /dev]# cat /usr/src/sys/i386/conf/KERNEL4 | grep GEOM options GEOM_GPT# GUID Partition Tables. options GEOM_BDE And about my system: [EMAIL PROTECTED] /dev]# uname -a FreeBSD xingu.xxx 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Mon Feb 20 16:47:57 BRT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KERNEL4 i386 Thank you, Felipe Neuwald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic
On Tue, 1 Aug 2006, Robert Watson wrote: On Tue, 25 Jul 2006, Graham Menhennitt wrote: Fatal trap 12: page fault while in kernel mode current process = 479 (mountd) I have the same panic reproducibly. Shutting off nfs_server_enable (i.e. mountd) in rc.conf prevents it. This is with 6-STABLE cvsupped yesterday. I'll get some more info and follow up the PR. I rebuilt my kernel (to enable debugging) and now it doesn't panic. So it seems that an old kernel (from around the end of May) with a new mountd (from Sunday) will crash. But a new kernel with a new mountd won't. FYI, I've managed to reproduce this on a 7-CURRENT kernel, so will try to take a look at this in detail in the next few days. It looks like a race during socket connect/accept for UNIX domain sockets, likely involving simultaneous close, which may be a sign of a bug in mountd (or the like) that triggers it. Of course, the kernel shouldn't panic under those circumstances. :-) On further reflection, this is simply a bug in the UNIX domain socket code, and has to do with a race between an attempt to connect to a socket and the socket being closed, such as may happen during a reboot. I'll do some more digging and see about a possible fix for this. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Safe card to replace for ICP Vortex GDT8514RZ ...
On Tue, 1 Aug 2006, Patrick M. Hausen wrote: Hi! On Mon, Jul 31, 2006 at 10:49:27PM -0300, User Freebsd wrote: Official word from Adaptec is that FreeBSD is no longer a supported platform, so, I either live with the deadlocks, or try and figure out a suitable replacement for the card ... That's really really bad news. Oddly, ICP Vortex Germany told me the opposite wr/t to their new line of cards. They said, they were working on full FreeBSD support. Great, that definitely wasn't the feel that I got from them ... I've been using Adaptec products since early 90's, mainly because they have always been the 'tried-n-true' product ... As I mentioned to someone else, I'm willing to endure having the server hang up a few times in order to debug the problem, and fix the driver, but any correspondance that I actually got answers back on gave me the feel that I was on my own ... my previous email to this was meant to warn others to think twice, especially with newer FreeBSD boxes, about going with anything that runs on the iir(4) driver ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Safe card to replace for ICP Vortex GDT8514RZ ...
On Tue, 1 Aug 2006, Christian Brueffer wrote: On Mon, Jul 31, 2006 at 10:49:27PM -0300, User Freebsd wrote: I have a remote server, running the above RAID controller, that, as most ppl here have seen over the past few weeks, is causing endless headaches ... Official word from Adaptec is that FreeBSD is no longer a supported platform, so, I either live with the deadlocks, or try and figure out a suitable replacement for the card ... So, can anyone recommend a card to replace this with? Its a remote server, so I'm looking for something that will be plug-n-play, same slot that the GDT is in ... I realize that I'll have to reformat the server afterwards ... I contacted Achim Leubner not long ago, about wheather he still maintains and supports the iir(4) driver, as claimed in the SEE ALSO section of the manpage. His answer was yes. I email'd him several weeks back, as soon as it was determined that the problem I've been experiencing with the deadlocks looked to be iir related, and didn't hear anything back :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM_BDE: where is my partition?
(Please do *not* crosspost.) Am 01.08.2006 um 15:36 schrieb Felipe Neuwald: [EMAIL PROTECTED] /dev]# ls /dev/ad5s1c ls: /dev/ad5s1c: No such file or directory Is the actual disk probed? (dmesg output should show that.) If the hardware is still detected, what does fdisk say about the slices on that disk? 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: [IMPORTANT] Adaptec no longer supporting iir(4) driver ...
A quick follow up on this email ... please note that I have not, in this email, pointed to anything but the iir(4) driver, and, more specifically, the GDT controller card ... I have been using Adaptec products since the early 90's, and, until upgrading to FreeBSD 6.x, *never* had a complaint with them ... this email was meant to be a 'caveat emptor' for anyone looking to use the iir(4) driver, and is not meant to apply to *all* Adaptec cards, as they don't all use the iir(4) driver ... Apologies to all who took this as a broad attack against Adaptec, it was not meant as such ... On Mon, 31 Jul 2006, User Freebsd wrote: 'k, I finally got ahold of someone @ adaptec, and the official word seems to be: FreeBSD 6 is not officially supported for the GDT based ICP RAID controllers. Nevertheless the inbox driver should work. Great, well, the inbox driver doesn't work with FreeBSD 6.x, and support doesn't exist to get it fixed, mainly since, as most ppl here know, the specs are closed, so even a non-Adaptec person can't do much to fix the problem(s) ... For those that haven't been following the discussion on this, the iir(4) driver in FreeBSD 6.x appears to have a deadlock issue under medium to heavy load, where the 'blocked' state just continues to rise until file accesses just no longer work ... So, if you are running a server that is using the iir(4) device driver and are considering upgrading to FreeBSD 6.x and beyond, or are looking to build a new machine using a device that relies on this driver, do so at your own peril ... Please note that this deadlock issue exists on *both* the ICP Vortex cards, *and* the Intel based RAID controllers ... If anyone from Adaptec is out there and is actually interested in seeing this problem fixed, *please* let me know ... I have three servers, all three exhibiting this problem, and one of them is fully loaded with the kernel debug stuff so that I can (I think) give you almost *anything* you want in the way of information concerning the problem ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
iir(4) driver (Was: Re: Safe card to replace for ICP Vortex GDT851...)
On Tue, 1 Aug 2006, Patrick M. Hausen wrote: Hello! On Tue, Aug 01, 2006 at 09:51:59AM +0200, Patrick M. Hausen wrote: That's really really bad news. Oddly, ICP Vortex Germany told me the opposite wr/t to their new line of cards. They said, they were working on full FreeBSD support. I'll check what they have to say about the GDT controllers. OK - so here's the deal: The GDT products are officially EOE (End Of Engineering). ICP Vortex will not provide capacity to update their own driver for FreeBSD 6. The new products will feature full FreeBSD support, eventually. (couple of weeks, he said) 'k, just to clarify here ... the new products won't be based on the iir(4) driver then? Basically, should the iir(4) driver be considered EOE also? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM_BDE: where is my partition?
Stefan, Yes, the disk have been detected: [EMAIL PROTECTED] /home/felipe]# dmesg | grep ad5 ad5: 194481MB Maxtor 6B200P0 BAH41B70 at ata2-slave UDMA66 [EMAIL PROTECTED] /home/felipe]# ls -laF /dev/ad5 crw-r- 1 root operator0, 62 Aug 1 10:39 /dev/ad5 And here is the fdisk output: [EMAIL PROTECTED] /home/felipe]# fdisk /dev/ad5 *** Working on device /dev/ad5 *** parameters extracted from in-core disklabel are: cylinders=395136 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=395136 heads=16 sectors/track=63 (1008 blks/cyl) fdisk: invalid fdisk partition table found Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 398297025 (194480 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 895/ head 15/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Felipe. Stefan Bethke escreveu: (Please do *not* crosspost.) Am 01.08.2006 um 15:36 schrieb Felipe Neuwald: [EMAIL PROTECTED] /dev]# ls /dev/ad5s1c ls: /dev/ad5s1c: No such file or directory Is the actual disk probed? (dmesg output should show that.) If the hardware is still detected, what does fdisk say about the slices on that disk? 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: GEOM_BDE: where is my partition?
Am 01.08.2006 um 16:41 schrieb Felipe Neuwald: Stefan, Yes, the disk have been detected: [EMAIL PROTECTED] /home/felipe]# dmesg | grep ad5 ad5: 194481MB Maxtor 6B200P0 BAH41B70 at ata2-slave UDMA66 [EMAIL PROTECTED] /home/felipe]# ls -laF /dev/ad5 crw-r- 1 root operator0, 62 Aug 1 10:39 /dev/ad5 And here is the fdisk output: ... fdisk: invalid fdisk partition table found Well, there you go: that's why there is no ad5s1, and thus ad5s1c. Maybe you got lucky, and only the first sector of the disk got lost in that crash. If you know how you had partitioned that disk *exactly*, or you have another disk of the same size that is partitioned *exactly* the same, you might try to re-create the slices usign fdisk, or copying over the first sector with dd. Otherwise, you need to restore from backup. 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: Odd PCI and ACPI messages on 'INSYDE RSDT_000' laptop
On Mon, Jul 31, 2006 at 12:33:58AM +0200, Ed Schouten wrote: Hello, Last week I got a laptop from a few friends of mine with a broken screen. I removed the screen from the device and connected a regular CRT to it to install FreeBSD 6.1 on it for serving as a jukebox (silent, doesn't consume too much power). I first tried FreeSBIE 1.1, which just deadlocked during the bootsplash. After that I downloaded a FreeBSD 6.1 CD. When I boot FreeBSD 6.1 without the ACPI kernel module, it panics (fatal trap 12) right after probing uhci0. When I boot with ACPI, it boots like it should. Because the laptop doesn't have a serial connector, I didn't copy the kernel backtrace. If it is really needed, I'll boot the CD once again and type over the screen contents. Anyway, I installed FreeBSD 6.1 on it, with the ACPI module loaded, but I still get some really strange messages in my dmesg I thought would be useful to mention: | ... | cpu0: ACPI CPU on acpi0 | acpi_perf0: ACPI CPU Frequency Control on cpu0 | acpi_perf0: failed in PERF_STATUS attach | device_attach: acpi_perf0 attach returned 6 | ... | acpi_perf0: ACPI CPU Frequency Control on cpu0 | acpi_perf0: failed in PERF_STATUS attach | device_attach: acpi_perf0 attach returned 6 | ... This means you can't get configuration for speedstep on this processor via ACPI because something is broken into the bios. But since we have that: CPU: Intel(R) Pentium(R) M processor 1500MHz (1498.73-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 ^^^ speedstep should work if you put: cpufreq_load=YES into /boot/loader.conf and you don't need acpi_perf anyway. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iir(4) driver (Was: Re: Safe card to replace for ICP Vortex GDT851...)
Hello! 'k, just to clarify here ... the new products won't be based on the iir(4) driver then? Yes, they won't. Basically, should the iir(4) driver be considered EOE also? As far as Adaptec and ICP Vortex are concerned, yes. Since the driver is Open Source, there is no enforced EOE, just orphanage, if nobody is willing to work on it. Regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iir(4) driver (Was: Re: Safe card to replace for ICP Vortex GDT851...)
Ok guys, time for a small breather here. All these claims about EoE and orphanage and whatnot are a bit premature and underinformed. First, the iir driver is being worked on when the need arises. Several bugs were fixed in it a few months ago, and until Mark's recent series of mails on it, no other problems had been reported. So far there is only one person reporting unhappiness with it, which doesn't necessarily mean that there is systematic trouble with the driver or the hardware. Second, various Adaptec sources have confirmed that they do support FreeBSD. Making big statements in public that they don't, or that it's not up to ones' standards or hopes, isn't terribly useful or productive. I'd hate for FreeBSD to turn into That Other BSD that publically abuses and harasses vendors for percieved sleights. There are much more positive and product ways to fix problems and form good relationships, and those ways are actively being pursued by some people right now. And here again is my standard disclaimer: I highly recommend that anyone who takes their data integrity seriously should spend time qualifying any RAID solution that they are interested in before putting it into production. What works for your workload might not work for someone else's workload, and vice-versa. Scott Patrick M. Hausen wrote: Hello! 'k, just to clarify here ... the new products won't be based on the iir(4) driver then? Yes, they won't. Basically, should the iir(4) driver be considered EOE also? As far as Adaptec and ICP Vortex are concerned, yes. Since the driver is Open Source, there is no enforced EOE, just orphanage, if nobody is willing to work on it. Regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iir(4) driver (Was: Re: Safe card to replace for ICP Vortex GDT851...)
On Tue, 1 Aug 2006, Scott Long wrote: Ok guys, time for a small breather here. All these claims about EoE and orphanage and whatnot are a bit premature and underinformed. First, the iir driver is being worked on when the need arises. Several bugs were fixed in it a few months ago, and until Mark's recent series of mails on it, no other problems had been reported. So far there is only one person reporting unhappiness with it, which doesn't necessarily mean that there is systematic trouble with the driver or the hardware. Second, various Adaptec sources have confirmed that they do support FreeBSD. Making big statements in public that they don't, or that it's not up to ones' standards or hopes, isn't terribly useful or productive. I'd hate for FreeBSD to turn into That Other BSD that publically abuses and harasses vendors for percieved sleights. There are much more positive and product ways to fix problems and form good relationships, and those ways are actively being pursued by some people right now. As email'd previous, I do apologize if my email was taken as disgruntled against Adaptec, for it was not meant as such ... it was merely meant as a warning to others, similar to your disclaimer below, that if you are running a card using the iir(4) driver, and are looking to move up to FreeBSD 6.x, that they might experience issues ... Please also note that until I hit what, from most angles, was appearing to be major brick walls, I was doing everything I could to, and am still willing to, provide all of the information I can towards diagnosing and fixing the issue ... I had tried all avenues that I knew about ... I tried email'ng the listed MAINTAINER, no response ... I got an email from one developer telling me that there wasn't much that could be done, due to the closed specs, without being able to get ahold of said MAINTAINER ... and the response I got back from ICP Vortex was one of the inbox driver should work fine, but we don't official support FreeBSD ... it doesn't leave much of a warm feeling that the driver is anything but orphaned :( My email was meant as a warning so that others could hopefully avoid the several weeks it took me to get to the point that all *appeared* lost ... Also, please note that in my email, I did finish it off with a plea that if anyone from Adaptec, or working with them, was out there, that my server was pretty much at their disposal to fix the problem, even at the risk of losing clients due to the downtime ... And here again is my standard disclaimer: I highly recommend that anyone who takes their data integrity seriously should spend time qualifying any RAID solution that they are interested in before putting it into production. What works for your workload might not work for someone else's workload, and vice-versa. In this case, we're talking about 3 servers that ran flawlessly with the iir(4) driver under 4.x, that are no exhibiting the deadlock/hang issues, after upgrading to FreeBSD 6.x ... Up until upgrading to FreeBSD 6.x, I've *never* had a problem with either an Adaptec controller, or running one with FreeBSD ... Scott Patrick M. Hausen wrote: Hello! 'k, just to clarify here ... the new products won't be based on the iir(4) driver then? Yes, they won't. Basically, should the iir(4) driver be considered EOE also? As far as Adaptec and ICP Vortex are concerned, yes. Since the driver is Open Source, there is no enforced EOE, just orphanage, if nobody is willing to work on it. Regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Odd PCI and ACPI messages on 'INSYDE RSDT_000' laptop
Hello Bruno, * Bruno Ducrot [EMAIL PROTECTED] wrote: This means you can't get configuration for speedstep on this processor via ACPI because something is broken into the bios. But since we have that: CPU: Intel(R) Pentium(R) M processor 1500MHz (1498.73-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 ^^^ speedstep should work if you put: cpufreq_load=YES into /boot/loader.conf and you don't need acpi_perf anyway. I built the cpufreq module and rebooted. I now have an est0 and p4tcc0 device. Powerd now sets the processor to a lower clockrate. Thanks a lot! Yours, -- Ed Schouten [EMAIL PROTECTED] WWW: http://g-rave.nl/ pgp1ecVq3zNXK.pgp Description: PGP signature
problem with lib/libpam/modules/pam_ssh
Hello All,
I have problem with make buildworld on my 2 different servers
FreeBSD 6.1-STABLE/i386/RELENG_6 (CVSup'ed today)
cut here===
=== lib/libpam/modules/pam_self (all)
cc -O2 -pipe -march=pentium4 -I/usr/src/lib/libpam/modules/pam_self/../../../..
building static pam_self library
ranlib libpam_self.a
=== lib/libpam/modules/pam_ssh (all)
make: don't know how to make ssh_namespace.h. Stop
*** Error code 2
Stop in /usr/src/lib/libpam/modules.
*** Error code 1
Stop in /usr/src/lib/libpam.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
===
I tried to find file ssh_namespace.h, but it does not exist
Makefile (/usr/src/lib/libpam/modules/pam_ssh/Makefile) has reference
to ${OBJS} ${POBJS} ${SOBJS}: ssh_namespace.h
cut here===
# PAM module for SSH
# $FreeBSD: src/lib/libpam/modules/pam_ssh/Makefile,v 1.20.2.2 2006/07/14 16:48:
52 ru Exp $
===
Any ideas?
--
WBR, Pavel Pisarenko
nic-hdl: PPA11-RIPE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
On Thu, Jul 27, 2006 at 04:47:16PM -0700, Sam Leffler wrote: Andrew Thompson wrote: On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote: Henrik Brix Andersen wrote: Oh? Sounds interesting, where can I find these patches? The work has always been in perforce.freebsd.org; look in the sam_wifi branch. The code will not hit head until folks show up to fix legacy drivers that use net80211. I got stuck holding the bag when I committed the wpa support and it ain't going to happen again. Do you have a list of drivers that are stalling this? The changes decouple scanning from the net80211 state machine so any driver that uses ieee80211_new_state is affected: tubby% grep -l ieee80211_new_state */*.c ath/if_ath.c awi/awi.c ipw/if_ipw.c iwi/if_iwi.c ral/rt2560.c ral/rt2661.c usb/if_ural.c wi/if_wi.c I know how to convert ath and ral. iwi and ipw might not be too bad now that they've been changed to not abuse the state machine so much. awi, ural, and wi will break. ural might be ok after the new usb stack comes in but that's not clear. So I guess I'd take responsibility for ath and ral and want help with all other drivers. IMO, losing awi in the process wouldn't be a big deal. We'll be maintaining 6.x until well into 2008 and all the awi cards are defunct. -- Brooks pgplprNnsvXkH.pgp Description: PGP signature
Re: Safe card to replace for ICP Vortex GDT8514RZ ...
On Mon, July 31, 2006 11:05 pm, Chad Leigh -- Shire.Net LLC wrote: On Jul 31, 2006, at 7:49 PM, User Freebsd wrote: I have a remote server, running the above RAID controller, that, as most ppl here have seen over the past few weeks, is causing endless headaches ... Official word from Adaptec is that FreeBSD is no longer a supported platform, so, I either live with the deadlocks, or try and figure out a suitable replacement for the card ... So, can anyone recommend a card to replace this with? Its a remote server, so I'm looking for something that will be plug-n-play, same slot that the GDT is in ... I realize that I'll have to reformat the server afterwards ... You may want to consider the LSI MegaRAID cards... There are various ones. Do you need the low profile format? Look at the 320-1lp for that otehrwise the 320-1 or 320-2x They have freebsd drivers and a command line management app. We've been bitten bad by these cards. LSI MegaRAID 150-6 SATA RAID controllers (PCI-X format). The management tools are crap, the throughput is crap, the onboard SATA chipset is a Silicon Image. And they will not run reliably when plugged into a riser card. Testing with FreeBSD 6.0 32-bit and 64-bit, and Debian Linux testing (32-bit and 64-bit) has shown these cards to not be worth the time, hassle, money, or effort. We lost data on several servers before narrowing down the cause to these cards. We lost several weeks of time diagnosing these things. And we lost several hundred dollars when the vendor wouldn't take them all back (we got them to trade most of them for 3Ware 9550SX cards). In our experience, these cards are crap, and their tech support isn't much better. Freddie Cash [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: Monitoring temperature with acpi (sysctls)
On Monday 31 July 2006 09:35, Oliver Fromme wrote:
John Baldwin wrote:
Mike Jakubik wrote:
I tried that, unfortunately it does not work. All i want to know is if
this a shortcoming of freebsd or the motherboard, if its the later, i
will contact the manufacturer.
If ACPI doesn't include the sysctl's that's due to your BIOS, not
FreeBSD.
You can verify by doing an acpidump and seeing if you have any thermal
zones listed in your ASL.
I have a similar problem. This is what sysctl says:
hw.acpi.thermal.tz0.temperature: 8.3C
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.passive_cooling: 1
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: 9.8C
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 31.3C
hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
dev.acpi_tz.0.%desc: Thermal Zone
dev.acpi_tz.0.%driver: acpi_tz
dev.acpi_tz.0.%location: handle=\_TZ_.THM0
dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0
The value of tz0.temperature is always 8.3C and never seems
to change. In reality it should be rathe 20C and change
slightly during day and night.
This is an excerpt from acpidump -d on that machine, which
seems to imply that it _should_ support thermal readings
(but I'm not a low-level ACPI expert):
Scope (_TZ)
{
Name (\TEMP, 0x0AFF)
ThermalZone (THM0)
{
Name (_TSP, 0x3C)
Name (_TC1, 0x04)
Name (_TC2, 0x04)
Name (_PSL, Package (0x01)
{
\_PR.CPU0
})
Method (_PSV, 0, NotSerialized)
{
Store (_PSV Method, Debug)
Return (0x0B0E)
}
Method (_SCP, 1, NotSerialized)
{
Notify (THM0, 0x81)
}
Method (_TMP, 0, NotSerialized)
{
Store (_TMP Method, Debug)
Return (TEMP)
}
Method (_CRT, 0, NotSerialized)
{
Store (_CRT Method, Debug)
Return (0x0BE5)
}
}
}
Is it a bug in the ACPI BIOS or a bug in FreeBSD code?
Well, your _TMP method just returns the TEMP constant. It may be that your
BIOS is supposed to be overwriting the TEMP constant periodically. It's not
a bug in FreeBSD though.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ncplogin panic
On Monday 31 July 2006 15:15, ejc wrote: I am having a problem getting ncplogin to work on my 6.1-stable system. When I run ncplogin I get the following panic (hand transcribed): Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc052d0a7 stack pointer = 0x28:0xc6021a98 stack frame = 0x28:0xc6021ab4 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 = 863 (ncplogin) trap number = 12 panic: page fault cpuid = 1 Can you run 'gdb /path/to/kernel.debug' and do 'l *0xc052d0a7' (the value of instruction pointer above)? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ncplogin panic
On 8/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
i had the same problem. See my thread on the freebsd-fs mailinglist
http://lists.freebsd.org/pipermail/freebsd-fs/2006-July/002060.html
After some research i use the attached patch against ncp_sock.c.
So it is not the real solution to this problem it only avoids the panics. I'm
using it quiet a while without any other known
problems.
Hopefully someone with more knowledge can help on this.
I also get some md_get_mem(461): incomplete copy messages which seem to do no
harm, so far.
Regards,
Maik
!!! Use atyour own risk !!!
--- ncp_sock.c.origFri Jan 7 02:45:49 2005
+++ ncp_sock.c Thu Jul 20 14:12:45 2006
@@ -189,7 +189,12 @@
struct thread *td = curthread;
struct ucred *cred = NULL;
-return so-so_proto-pr_usrreqs-pru_sopoll(so, events, cred, td);
+if ( td-td_selq.tqh_last == NULL ) {
+printf(ncp_poll: td-td_selq.tqh_last == NULL\n);
+return 0;
+}
+
+ return so-so_proto-pr_usrreqs-pru_sopoll(so, events, cred, td);
}
int
pach ends here ---
After setting my bios to only use one CPU I was able to get a core
dump and the panic is happening at the exact same place as yours:
in selrecord (../../../kern/sys_generic.c:1105)
1100 * it alone as we've already added pointed it at us
and added it to
1101 * our list.
1102 */
1103if (sip-si_thread == NULL) {
1104sip-si_thread = selector;
1105TAILQ_INSERT_TAIL(selector-td_selq, sip, si_thrlist);
1106} else if (sip-si_thread != selector) {
1107sip-si_flags |= SI_COLL;
1108}
1109
I found your backtrace by digging a bit through the freebsd-fs list
and we appear to be reaching selrecord though different paths. Mine
is in sopoll() at ../../../kern/uipc_socket.c:2059
I don't know if it makes a difference, but I'm trying to use IP
instead of IPX to access our server.
My dump backtrace is attached.
Thanks
Eric
dump.out
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ncplogin panic
On Tuesday 01 August 2006 14:28, ejc wrote:
On 8/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
i had the same problem. See my thread on the freebsd-fs mailinglist
http://lists.freebsd.org/pipermail/freebsd-fs/2006-July/002060.html
After some research i use the attached patch against ncp_sock.c.
So it is not the real solution to this problem it only avoids the panics.
I'm using it quiet a while without any other known
problems.
Hopefully someone with more knowledge can help on this.
I also get some md_get_mem(461): incomplete copy messages which seem to
do no harm, so far.
Regards,
Maik
!!! Use atyour own risk !!!
--- ncp_sock.c.origFri Jan 7 02:45:49 2005
+++ ncp_sock.c Thu Jul 20 14:12:45 2006
@@ -189,7 +189,12 @@
struct thread *td = curthread;
struct ucred *cred = NULL;
-return so-so_proto-pr_usrreqs-pru_sopoll(so, events, cred, td);
+if ( td-td_selq.tqh_last == NULL ) {
+printf(ncp_poll: td-td_selq.tqh_last == NULL\n);
+return 0;
+}
+
+ return so-so_proto-pr_usrreqs-pru_sopoll(so, events, cred, td);
}
int
pach ends here ---
After setting my bios to only use one CPU I was able to get a core
dump and the panic is happening at the exact same place as yours:
in selrecord (../../../kern/sys_generic.c:1105)
1100 * it alone as we've already added pointed it at us
and added it to
1101 * our list.
1102 */
1103if (sip-si_thread == NULL) {
1104sip-si_thread = selector;
1105TAILQ_INSERT_TAIL(selector-td_selq, sip,
si_thrlist);
1106} else if (sip-si_thread != selector) {
1107sip-si_flags |= SI_COLL;
1108}
1109
I found your backtrace by digging a bit through the freebsd-fs list
and we appear to be reaching selrecord though different paths. Mine
is in sopoll() at ../../../kern/uipc_socket.c:2059
I don't know if it makes a difference, but I'm trying to use IP
instead of IPX to access our server.
My dump backtrace is attached.
It would be very helpful if you could get the symbols loaded for the modules
in you backtrace. You can either compile everything into a static kernel or
you can use the 'asf' tool to generate appropriate gdb script commands to
source to get symbols for your modules. You can find a kldstat gdb command
in src/tools/debugscripts/ that would be helpful to use with asf.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
