sio = uart: one port is gone
This is a fairly standard and old machine with 2 COM ports. Recently (last Friday) I decided to update my RELENG_7 system and also to transition from sio to uart. This what I had before the upgrade: kernel: sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 kernel: sio0: type 16550A kernel: sio0: [FILTER] kernel: sio1: 16550A-compatible COM port port 0x2e8-0x2ef irq 3 on acpi0 kernel: sio1: type 16550A kernel: sio1: [FILTER] This is what I have now: uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] This is what I have in device.hints for uart: hint.uart.0.at=isa hint.uart.0.port=0x3F8 hint.uart.0.flags=0x10 hint.uart.0.irq=4 hint.uart.1.at=isa hint.uart.1.port=0x2F8 hint.uart.1.irq=3 hint.uart.2.at=isa Precisely the same hints (s/uart/sio/) I had for sio. Please advise. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sio = uart: one port is gone
On Mon, 15 Sep 2008, Andriy Gapon wrote: This is a fairly standard and old machine with 2 COM ports. Recently (last Friday) I decided to update my RELENG_7 system and also to transition from sio to uart. This what I had before the upgrade: kernel: sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 kernel: sio0: type 16550A kernel: sio0: [FILTER] kernel: sio1: 16550A-compatible COM port port 0x2e8-0x2ef irq 3 on acpi0 kernel: sio1: type 16550A kernel: sio1: [FILTER] This is what I have now: uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] This is what I have in device.hints for uart: hint.uart.0.at=isa hint.uart.0.port=0x3F8 hint.uart.0.flags=0x10 hint.uart.0.irq=4 hint.uart.1.at=isa hint.uart.1.port=0x2F8 but it's shown as 0x2e8 above .. hint.uart.1.irq=3 hint.uart.2.at=isa Precisely the same hints (s/uart/sio/) I had for sio. 0x2f8 is 'standard COM2' address .. did sio1 work ok at 0x2e8 before? cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Suddenly frozen fcntl/stat call on NFS over TCP with MTU 9000
Currently I was running a mail server using a netapp filer as backend storage. From time to time, the whole system get stuck and lasted for 3-5 minutes. But after that, everything recovers normally. During the stuck moment, using ps auxw shows 200-300 of mail delivery agent(MDA) processes staying in D status. The command df certainly does not reponse either. System configuration: 1. NFS server: NetApp FAS3020 2. NFS client: acting as a smtp/pop3/imap server. freebsd 7.0-stable (almost 7.1-prelease) hardware: IBM x3550 server network interface: bce1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) mem 0xc800-0xc9ff irq 18 at device 0.0 on pci4 miibus0: MII bus on bce0 brgphy0: BCM5708C 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce1: Ethernet address: 00:1a:64:--:--:-- bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x04000305); Flags( MFW MSI ) ifconfig: bce1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 9000 options=1bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4 ether 00:1a:64:--:--:-- inet 192.168.1.166 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseTX full-duplex) status: active software: postfix 2.5.4 courier-imap 4.4.1 maildrop 2.0.4 After further investigation, I found that the situation is most severe when nfs over tcp and using mtu 9000. If nfs mount is changed to either (over udp and mtu 9000) or (over tcp and mtu 1500), things get significantly improvement. The frequency of suddenly hang decreases from every 10-15 min to several hours. Another observation is the freeze happens more frequently when server load is high, especially working hours. So I believed it is tightly related to server load (or nfs load). I tried to modify the source code of MDA (maildrop) and adding some debug code to identify the problem. What I found is: 1) MDA processing time always approximate 0 sec or 1 sec when things work normally. 2) MDA processing time may up to 30 second when system got stuck. If the incoming email continues to come, later emails may cost up to 200 second to complete. At this time, using ps auxw shows MDAs were in D status. 3) Detail trace shows the processing time spent were waiting around the fcntl (lock) and stat(fstat) code. One more thing to note: I've tried to turn on and off rpc.statd,rpc.lockd, -L mount, even compile NFSLOCKD in kernel. All were in vain, things still got stuck when using NFS over TCP with mtu 9000. We have already lots of mail servers whose hardware were different and OS is freebsd 6-stable. Softwares were all the same but with prior version. Those servers didn't show any of the above strange behavior. Based on all of the above experiment and observation, I guess there might be something wrong with: 1) NFS or network stack of freebsd 7 2) fcntl/stat over NFS 3) bce driver Need your help/suggestion to solve the problem! Thanks very much. Sincerely, Tim Chen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crossbuilding of RELENG_7 broken?
Peter Jeremy wrote:
On 2008-Sep-14 18:21:45 +0200, Dominic Fandrey [EMAIL PROTECTED] wrote:
Building them works fine, but when I nfs-mount /usr/obj and /usr/src on the
target system, install does not work. Neiter installkernel nor installworld.
You're going to have to give more detail - like your exact command and
the last few dozen lines of the make install{world,kernel} output.
So well, here it is:
Command on the amd64 build machine:
# env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7 make -j4 buildworld buildkernel
KERNCONF=VECTRA-7
It builds without incident and yes I did try without -j4 and it didn't work
either.
On the i386 target machine, /usr/src and /usr/obj are NFS mounts:
===
# env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 make installkernel
KERNCONF=VECTRA-7
--
Installing kernel
--
cd /usr/obj/VECTRA-7/i386/usr/src/sys/VECTRA-7;
MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 MACHINE_ARCH=i386 MACHINE=i386
CPUTYPE=pentium4
GROFF_BIN_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/sbin:/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin:/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/games:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/sbin:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/bin:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
make KERNEL=kernel install
thiskernel=`sysctl -n kern.bootfile` ; if [ ! `dirname $thiskernel` -ef
/boot/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel
; else if [ -d /boot/kernel.old ] ; then chflags -R noschg
/boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel
/boot/kernel.old ; sysctl kern.bootfile=/boot/kernel.old/`basename
$thiskernel` ; fi
mkdir -p /boot/kernel
install -p -m 555 -o root -g wheel kernel /boot/kernel
[EMAIL PROTECTED]: not found
@@ææððWðW: not found
ELF: not found
/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin/install: 19: Syntax error:
) unexpected
*** Error code 2
Stop in /usr/obj/VECTRA-7/i386/usr/src/sys/VECTRA-7.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
===
I can successfully install the kernel with the following
command:
# cd /usr/obj/VECTRA-7/i386/usr/src/sys/boot/i386
# make install
The system boots fine with a kernel installed like this.
I have found no such workaround for installing world.
===
# env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 make installworld
mkdir -p /tmp/install.LaibTyRC
for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep find grep
install-info ln lockf make mkdir mtree mv pwd_mkdb rm sed sh sysctl test true
uname wc zic; do cp `which $prog` /tmp/install.LaibTyRC; done
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 MACHINE_ARCH=i386
MACHINE=i386 CPUTYPE=pentium4
GROFF_BIN_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/sbin:/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin:/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/games:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/sbin:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/bin:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/games:/tmp/install.LaibTyRC
make -f Makefile.inc1 reinstall
--
Making hierarchy
--
cd /usr/src; make -f Makefile.inc1 hierarchy
cd /usr/src/etc;make distrib-dirs
mtree -eU -f /usr/src/etc/mtree/BSD.root.dist -p /
root changed
type expected dir found link
mtree -eU -f /usr/src/etc/mtree/BSD.var.dist -p /var
tmp changed
type expected dir found link
./tmp/vi.recover missing (created)
mtree -eU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr
mtree -eU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/include
mtree -deU -f /usr/src/etc/mtree/BIND.chroot.dist -p /var/named
mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p /
cd /; rm -f /sys; ln -s usr/src/sys sys
cd /usr/share/man/en.ISO8859-1; ln -sf ../man* .
cd /usr/share/man; set - `grep ^[a-zA-Z] /usr/src/etc/man.alias`; while [
$# -gt 0 ] ; do rm -rf $1; ln -s $2 $1; shift; shift; done
cd /usr/share/openssl/man; set - `grep ^[a-zA-Z] /usr/src/etc/man.alias`;
while [ $# -gt 0 ] ; do rm -rf $1; ln -s $2 $1; shift; shift; done
cd /usr/share/openssl/man/en.ISO8859-1; ln -sf ../man* .
cd /usr/share/nls; set -
Re: sio = uart: one port is gone
on 15/09/2008 17:36 Ian Smith said the following: On Mon, 15 Sep 2008, Andriy Gapon wrote: This is a fairly standard and old machine with 2 COM ports. Recently (last Friday) I decided to update my RELENG_7 system and also to transition from sio to uart. This what I had before the upgrade: kernel: sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 kernel: sio0: type 16550A kernel: sio0: [FILTER] kernel: sio1: 16550A-compatible COM port port 0x2e8-0x2ef irq 3 on acpi0 kernel: sio1: type 16550A kernel: sio1: [FILTER] This is what I have now: uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] This is what I have in device.hints for uart: hint.uart.0.at=isa hint.uart.0.port=0x3F8 hint.uart.0.flags=0x10 hint.uart.0.irq=4 hint.uart.1.at=isa hint.uart.1.port=0x2F8 but it's shown as 0x2e8 above .. hint.uart.1.irq=3 hint.uart.2.at=isa Precisely the same hints (s/uart/sio/) I had for sio. 0x2f8 is 'standard COM2' address .. did sio1 work ok at 0x2e8 before? Ian, thank you, I guess I had a typo in my hints, but the port did work. Looking at the old dmesg I see that sio devices are found 'on acpi0' as opposed to uart now being found on 'isa0'. Maybe this is another difference. Maybe sio was attached using some information from acpi, so hints were not that important. But maybe the same acpi information is not applied to uart, so it does depend on the hints. If this guess is correct then this is a regression in sio=uart transition, if not, then I'll just correct my device.hints and shut up :-) -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sio = uart: one port is gone
On Mon, 15 Sep 2008, Andriy Gapon wrote: on 15/09/2008 17:36 Ian Smith said the following: On Mon, 15 Sep 2008, Andriy Gapon wrote: This is a fairly standard and old machine with 2 COM ports. Recently (last Friday) I decided to update my RELENG_7 system and also to transition from sio to uart. This what I had before the upgrade: kernel: sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 kernel: sio0: type 16550A kernel: sio0: [FILTER] kernel: sio1: 16550A-compatible COM port port 0x2e8-0x2ef irq 3 on acpi0 kernel: sio1: type 16550A kernel: sio1: [FILTER] This is what I have now: uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] This is what I have in device.hints for uart: hint.uart.0.at=isa hint.uart.0.port=0x3F8 hint.uart.0.flags=0x10 hint.uart.0.irq=4 hint.uart.1.at=isa hint.uart.1.port=0x2F8 but it's shown as 0x2e8 above .. hint.uart.1.irq=3 hint.uart.2.at=isa Precisely the same hints (s/uart/sio/) I had for sio. 0x2f8 is 'standard COM2' address .. did sio1 work ok at 0x2e8 before? thank you, I guess I had a typo in my hints, but the port did work. Looking at the old dmesg I see that sio devices are found 'on acpi0' as opposed to uart now being found on 'isa0'. Maybe this is another difference. Does sound a bit odd; looks like the ACPI info trumped hints for sio. Maybe sio was attached using some information from acpi, so hints were not that important. But maybe the same acpi information is not applied to uart, so it does depend on the hints. Sounds a reasonable theory .. so does fixing that hint find the UART? Maybe a verbose dmesg would provide more clues re uart's attachment? If this guess is correct then this is a regression in sio=uart transition, if not, then I'll just correct my device.hints and shut up :-) Or both :) You'd think if ACPI info is available uart should use it, but then if it's attaching to the isa bus instead, maybe not .. hmm. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 5, 2008, at 1:19 PM, Ben Kaduk wrote: Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. I don't remember seeing any speculation about 6.4 being an extended release, so, EoL is 12 months after release, whenever that actually happens. Okay, so 6.3 will EoL at roughly the same time as 6.4. Why should anyone spend any effort on 6.4? That's the difference between a long-term-support branch and a regular branch; many OSes do that. If you want to run the same machines for a long time and not have to do a huge battery of tests (at the expense of getting new features and better performance in the interim), you use long-term branches. The regular branches that get released later, will then become unsupported at the same time as the (older) long-term branch. Yes, it's poor when a long-term branch goes EoL before there's another one ready to take its place, but if the new one isn't ready, then you just use whichever regular release is current and then snag a long-term release when it becomes available. Yes, it's more work, but that's life. Is it just me, or does this make no sense at all? This does make it clear to me why the release team can't find the resources to do longer support. Who can convince their company to put resources into the mainstream release effort, when this kind of cycle basically forces every company to run their own internal release process. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 6, 2008, at 4:06 AM, Robert Watson wrote: Unfortunately, it's a little hard to tell at time-of-release whether a particular release will become extended life or not. This is because extended support status is dependent on the success of the release ... from earlier branch adopters. How long we keep release 6.x releases will depend entirely on how successful 7.x is; I think there's a reasonable expectation that 6.4 or 6.5 will be the last 6.x release, in which case we would want to grant it extended support status. But what happens depends a lot on how successful 7.1 is. My hopes are high, but there's nothing like real-world deployment to shed light on things :-). Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business. I was also told that I should have been more active in the release cycle process for 6.3, etc. Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing. How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an appropriately supported release when the decision for the support cycle is completely up in the air? How does one talk to management about getting resources assigned to help with the freebsd release testing process, when one cannot make any valid predictions for that release will even be supported long enough to justify the effort involved in upgrading? What you are saying is completely reasonable from a developers point of view. But those of us who use freebsd in an environment which requires extensive testing and long-term planning for support have trouble with this. In short, I can't imagine how I could possibly make any business case to get support for helping the freebsd dev/rel process at all. Why? Because frankly we're going to be forced to run our own internal release management process instead. I guess this is not surprising, as this appears to be what every other business using significant amounts of freebsd in production are doing today. My point to you is that if this wasn't being forced upon every company that uses FreeBSD, those companies could commit more resources to help the core (main branch, whatever - not Core) freebsd development. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sio = uart: one port is gone
On Mon, Sep 15, 2008 at 06:38:02PM +0300, Andriy Gapon wrote: on 15/09/2008 17:36 Ian Smith said the following: On Mon, 15 Sep 2008, Andriy Gapon wrote: This is a fairly standard and old machine with 2 COM ports. Recently (last Friday) I decided to update my RELENG_7 system and also to transition from sio to uart. This what I had before the upgrade: kernel: sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 kernel: sio0: type 16550A kernel: sio0: [FILTER] kernel: sio1: 16550A-compatible COM port port 0x2e8-0x2ef irq 3 on acpi0 kernel: sio1: type 16550A kernel: sio1: [FILTER] This is what I have now: uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] This is what I have in device.hints for uart: hint.uart.0.at=isa hint.uart.0.port=0x3F8 hint.uart.0.flags=0x10 hint.uart.0.irq=4 hint.uart.1.at=isa hint.uart.1.port=0x2F8 but it's shown as 0x2e8 above .. hint.uart.1.irq=3 hint.uart.2.at=isa Precisely the same hints (s/uart/sio/) I had for sio. 0x2f8 is 'standard COM2' address .. did sio1 work ok at 0x2e8 before? Ian, thank you, I guess I had a typo in my hints, but the port did work. Looking at the old dmesg I see that sio devices are found 'on acpi0' as opposed to uart now being found on 'isa0'. Maybe this is another difference. Maybe sio was attached using some information from acpi, so hints were not that important. But maybe the same acpi information is not applied to uart, so it does depend on the hints. If this guess is correct then this is a regression in sio=uart transition, if not, then I'll just correct my device.hints and shut up :-) I've CC'd Marcel Moolenaar, who can very likely explain what's going on here. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crossbuilding of RELENG_7 broken?
On 2008-Sep-15 18:18:28 +0200, Dominic Fandrey [EMAIL PROTECTED] wrote:
Peter Jeremy wrote:
On 2008-Sep-14 18:21:45 +0200, Dominic Fandrey [EMAIL PROTECTED] wrote:
Building them works fine, but when I nfs-mount /usr/obj and /usr/src on the
target system, install does not work. Neiter installkernel nor installworld.
You're going to have to give more detail - like your exact command and
the last few dozen lines of the make install{world,kernel} output.
So well, here it is:
Command on the amd64 build machine:
# env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7 make -j4 buildworld buildkernel
KERNCONF=VECTRA-7
It builds without incident and yes I did try without -j4 and it didn't work
either.
On the i386 target machine, /usr/src and /usr/obj are NFS mounts:
===
# env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 make installkernel
KERNCONF=VECTRA-7
I didn't understand exactly what you were doing before. The
install{world,kernel} must be executed on the same architecture (and
similar FreeBSD version) as the build{world,kernel} because the
install{world,kernel} executes code that was built as part of the
buildworld.
Rather than NFS mounting the buildhost onto the target and running
install{world,kernel} on the target, you need to NFS mount the target
/ and /usr onto the buildhost and use DESTDIR to point the install at
the correct location. This will work, modulo some chflags issues
(chflags isn't supported over NFS - I don't recall offhand where this
is discussed but google should be able to help).
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpMesWTNa4uv.pgp
Description: PGP signature
ssh to FreeBSD 4 systems: xmalloc: zero size
Hi, With the latest FreeBSD 7.1 PRE-RELEASE, I am having trouble ssh'ing to FreeBSD 4 systems. I am getting this error: OpenSSH_5.1p1 FreeBSD-20080901, OpenSSL 0.9.8e 23 Feb 2007 debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connection established. debug1: identity file /homes/rodrigc/.ssh/identity type -1 debug1: identity file /homes/rodrigc/.ssh/id_rsa type -1 debug1: identity file /homes/rodrigc/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 FreeBSD-20060930 debug1: match: OpenSSH_3.5p1 FreeBSD-20060930 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-cbc hmac-md5 none debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'bbuild47.juniper.net' is known and matches the DSA host key. debug1: Found key in /homes/rodrigc/.ssh/known_hosts:100 debug1: ssh_dss_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received xmalloc: zero size At this point I cannot log in. The system I am trying to log into is: 4.11-RELEASE-p26 Any ideas? This is a big problem for me, because I have a lot of FreeBSD 4.x servers that I need to log into. Thanks. -- Craig Rodrigues [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: Suddenly frozen fcntl/stat call on NFS over TCP with MTU 9000
On Monday 15 September 2008 11:57:02 am Tim Chen wrote: Currently I was running a mail server using a netapp filer as backend storage. From time to time, the whole system get stuck and lasted for 3-5 minutes. But after that, everything recovers normally. During the stuck moment, using ps auxw shows 200-300 of mail delivery agent(MDA) processes staying in D status. The command df certainly does not reponse either. Can you use 'ps axl' to determine the wait mesg (wchan) of the stuck threads when they hang? If it is lockf, then make sure you have an up-to-date RELENG_6 kernel as there was a recent fix for a lockf hang. Alternatively, if things are stuck in nfsreq, it may be useful to use tcpdump to look at the NFS requests your client is making. nfsstat can also be useful as you can see which counters are increasing during a hang. -- 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: ACPI regression on recent 7.0-STABLE: HPET stops working
On Friday 12 September 2008 07:28:50 pm Bruce Cran wrote: On Wed, 23 Jul 2008 11:16:02 -0400 John Baldwin [EMAIL PROTECTED] wrote: I've committed the patch. However, I think this actually points out a slightly bigger issue in that the HPET timer is probably piggybacking on the ichsmb0 device's BAR, and they really should both be able to attach somehow. A way to fix that would be to make the HPET device actually borrow the PCI device's resource instead of allocating its own perhaps. I think the HPET ACPI device and the table tell us the PCI deviec the HPET lives in. I just upgraded from 7.0-p3 to 7.1-PRERELEASE on my Dell I1501 laptop and hit this problem too. I noticed the patch was committed to HEAD - are there any plans to MFC it for 7.1? I will MFC it. -- 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: ssh to FreeBSD 4 systems: xmalloc: zero size
On Mon, Sep 15, 2008 at 08:08:38PM +, Craig Rodrigues wrote: Hi, With the latest FreeBSD 7.1 PRE-RELEASE, I am having trouble ssh'ing to FreeBSD 4 systems. xmalloc: zero size This looks like the same problem: https://bugzilla.mindrot.org/show_bug.cgi?id=1496 -- Craig Rodrigues [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: ssh to FreeBSD 4 systems: xmalloc: zero size
Hi, I can confirm that this patch solves my problem: https://bugzilla.mindrot.org/attachment.cgi?id=1554 That patch is part of this ssh bug: https://bugzilla.mindrot.org/show_bug.cgi?id=1496 Can we get this fix into FreeBSD before the 7.1 RELEASE? Thanks. -- Craig Rodrigues [EMAIL PROTECTED] On Mon, Sep 15, 2008 at 08:08:38PM +, Craig Rodrigues wrote: Hi, With the latest FreeBSD 7.1 PRE-RELEASE, I am having trouble ssh'ing to FreeBSD 4 systems. I am getting this error: OpenSSH_5.1p1 FreeBSD-20080901, OpenSSL 0.9.8e 23 Feb 2007 debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connection established. debug1: identity file /homes/rodrigc/.ssh/identity type -1 debug1: identity file /homes/rodrigc/.ssh/id_rsa type -1 debug1: identity file /homes/rodrigc/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 FreeBSD-20060930 debug1: match: OpenSSH_3.5p1 FreeBSD-20060930 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-cbc hmac-md5 none debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'bbuild47.juniper.net' is known and matches the DSA host key. debug1: Found key in /homes/rodrigc/.ssh/known_hosts:100 debug1: ssh_dss_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received xmalloc: zero size At this point I cannot log in. The system I am trying to log into is: 4.11-RELEASE-p26 Any ideas? This is a big problem for me, because I have a lot of FreeBSD 4.x servers that I need to log into. Thanks. -- Craig Rodrigues [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: Apache-worker stuck at 100% CPU
2008/9/13 Alfred Perlstein [EMAIL PROTECTED]: Yes, it's multithreaded apache. This did help somewhat - when I show threads in top I see that it's not actually stuck in umtxn - there's one thread that consumes the CPU and it's apparently always running (in state CPUx). PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND 7212 www 1030 30340K 7932K CPU2 2 444:23 99.02% httpd I'm currently upgrading the system to 7-STABLE, to see if it helps. It didn't help. Exactly the same symptom happened again. It looks like it happens a few days after the last system reboot. After it happens the first time, restarting Apache immediately produces one such stuck thread - it looks like some system state gets corrupted over time. How do I pick what thread to backtrace in gdb? i think the command is 'info threads' or 'show threads' then i think you just type 'thread FOO' to select the thread. Both commands don't work / don't exist. Any others? (background: apache22-worker port, no mod_php, on 7.0 and 7-STABLE suddenly gets stuck at 100% CPU; the same setup worked on 6-STABLE. I'm looking for ideas) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible UDP related deadlock in 7.1-PRERELEASE
On September 15, 2008, Gavin Atkinson wrote: On Sun, 2008-09-14 at 12:19 -0700, Norbert Papke wrote: Symptoms: * I can trigger this lockup reliably by starting ktorrent. After a short while (one to two minutes), it locks up. Other commands, e.g., netstat, also lock up. * The console generates nfe0: watchdog timeout error messages. * The system becomes unusable and must be rebooted. Attempted Diagnosis: If I break into DDB, the 'ps' output shows a number of processes that seem to be locked related to udp. [irq18:dc0]L *udp ktorrent L *udpinp hald L *udp ntpd L *udp Unfortunately, I am rapidly getting out of my depth here. I have no idea how to go about further analyzing this problem and would appreciate help. Can you add: options WITNESS options WITNESS_SKIPSPIN to your kernel, recompile and wait for the problem to happen again? When it does, from the debugger issue sh alllocks and make a note of the output? With WITNESS enabled, I now experience panics and could not follow your instructions. There is no core dump. The following gets logged to /var/log/messages: shared lock of (rw) udpinp @ /usr/src/sys/netinet/udp_usrreq.c:864 while exclusively locked from /usr/src/sys/netinet6/udp6_usrreq.c:940 panic: share-excl KDB: stack backtrace: db_trace_self_wrapper(c06fda7c,f6b96978,c052046a,c06fbb5d,c07695c0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c06fbb5d,c07695c0,c06febd1,f6b96984,f6b96984,...) at kdb_backtrace+0x29 panic(c06febd1,c070c409,3ac,c0709eee,360,...) at panic+0xaa witness_checkorder(ccd5209c,1,c0709eee,360,8,...) at witness_checkorder+0x17c _rw_rlock(ccd5209c,c0709eee,360,c07780e0,cd4652c8,...) at _rw_rlock+0x2a udp_send(d3942000,0,c580f400,c68faa00,0,...) at udp_send+0x197 udp6_send(d3942000,0,c580f400,c68faa00,0,...) at udp6_send+0x140 sosend_generic(d3942000,c68faa00,f6b96be8,0,0,...) at sosend_generic+0x50d sosend(d3942000,c68faa00,f6b96be8,0,0,...) at sosend+0x3f kern_sendit(cd465230,f,f6b96c64,0,0,...) at kern_sendit+0x106 sendit(0,871b9fe,0,c68faa00,1c,...) at sendit+0x182 sendto(cd465230,f6b96cfc,18,cd465230,c072bab8,...) at sendto+0x4f syscall(f6b96d38) at syscall+0x293 Note that I do not use IPv6, none of my network interfaces is configured for it. Also, since I enabled WITNESS, I get the following logged during system startup: Enabling pf. lock order reversal: 1st 0xc09af92c pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contri b/pf/net/pf_ioctl.c:1394 2nd 0xc07b4d68 ifnet (ifnet) @ /usr/src/sys/net/if.c:1558 KDB: stack backtrace: db_trace_self_wrapper(c06fda7c,f4914a60,c0552c75,c06fed11,c07b4d68,...) at db_tr ace_self_wrapper+0x26 kdb_backtrace(c06fed11,c07b4d68,c0703ca2,c0703ca2,c0703c73,...) at kdb_backtrace +0x29 witness_checkorder(c07b4d68,9,c0703c73,616,572,...) at witness_checkorder+0x5e5 _mtx_lock_flags(c07b4d68,0,c0703c73,616,c0104414,...) at _mtx_lock_flags+0x34 ifunit(c6ef5c20,0,c09adfb5,572,c0703a71,...) at ifunit+0x2f pfioctl(c566ce00,c0104414,c6ef5c20,3,c60c38c0,...) at pfioctl+0x2b43 devfs_ioctl_f(c588bb94,c0104414,c6ef5c20,c54bb900,c60c38c0,...) at devfs_ioctl_f +0xe6 kern_ioctl(c60c38c0,3,c0104414,c6ef5c20,100,...) at kern_ioctl+0x243 ioctl(c60c38c0,f4914cfc,c,c0718d59,c072b350,...) at ioctl+0x134 syscall(f4914d38) at syscall+0x293 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281ab6f3, esp = 0xbfbfde3c, ebp = 0xbfbfde68 --- pf enabled I tried to unload 'pf' to see if it was the culprit. However, even without pf loaded, I experience the panic. Is there anything else I can try to provide better insight into what might be going on? Cheers, -- Norbert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
unsupported NVIDIA SATA controller
Hello,
I have the following SATA controller card on my system that appears to
be unsupported by FreeBSD 7-STABLE. Does anybody know if this card is
supported or will be supported in the near future?
[EMAIL PROTECTED]:0:14:0: class=0x010485 card=0x01371025 chip=0x07f810de
rev=0xa2 hdr=0x00
vendor = 'Nvidia Corp'
class = mass storage
subclass = RAID
I have a SATA hard disk and DVD drive connedted to this controller that is not
detected
as a result. I have Ubuntu loaded on the SATA disk.
In an attempt to see if I could get FreeBSD 7-STABLE to work, I made the
following changes to the source. But it didn't seem to work.
/*** Begin change #1 ***/
[/usr/src/sys/dev/ata]
[EMAIL PROTECTED] diff -u ata-pci.h ata-pci.h.orig
--- ata-pci.h 2008-09-15 20:40:30.0 -0500
+++ ata-pci.h.orig 2008-09-15 20:37:36.0 -0500
@@ -242,7 +242,6 @@
#define ATA_NFORCE_MCP650x044810de
#define ATA_NFORCE_MCP670x056010de
#define ATA_NFORCE_MCP730x056c10de
-#define ATA_NFORCE_MCP73_S1 0x07f810de
#define ATA_NFORCE_MCP770x075910de
#define ATA_PROMISE_ID 0x105a
/*** End change #1 ***/
/*** Begin change #2 ***/
[/usr/src/sys/dev/ata]
[EMAIL PROTECTED] diff -u ata-chipset.c ata-chipset.c.orig
--- ata-chipset.c 2008-09-15 20:47:55.0 -0500
+++ ata-chipset.c.orig 2008-09-15 20:40:43.0 -0500
@@ -3051,7 +3051,6 @@
{ ATA_NFORCE_MCP65,0, AMDNVIDIA, NVIDIA, ATA_UDMA6, nForce MCP65 },
{ ATA_NFORCE_MCP67,0, AMDNVIDIA, NVIDIA, ATA_UDMA6, nForce MCP67 },
{ ATA_NFORCE_MCP73,0, AMDNVIDIA, NVIDIA, ATA_UDMA6, nForce MCP73 },
- { ATA_NFORCE_MCP73_S1, 0, 0, NV4|NVQ, ATA_SA300, nForce MCP73 },
{ ATA_NFORCE_MCP77,0, AMDNVIDIA, NVIDIA, ATA_UDMA6, nForce MCP77 },
{ 0, 0, 0, 0, 0, 0}} ;
/*** End change #2 ***/
After making the above changes, I rebuilt the kernel and got the card a
driver assigned to it. But my DVD drive nor the SATA hard disk was
detected. I must admit that I did not quite understand the changes that
I made. It was just an attempt. Any insight or help will be greatly
appreciated.
[EMAIL PROTECTED]:0:14:0:class=0x010485 card=0x01371025 chip=0x07f810de
rev=0xa2 hdr=0x00
vendor = 'Nvidia Corp'
class = mass storage
subclass = RAID
/*** Begin dmesg ***/
Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-PRERELEASE #4: Mon Sep 15 20:55:34 CDT 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SNOW
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1799.96-MHz K8-class CPU)
Origin = GenuineIntel Id = 0x6fd Stepping = 13
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=0xe39dSSE3,RSVD2,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x20100800SYSCALL,NX,LM
AMD Features2=0x1LAHF
Cores per package: 2
usable memory = 793821184 (757 MB)
avail memory = 764108800 (728 MB)
ACPI APIC Table: 012908 APIC1443
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
ioapic0 Version 1.1 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: ACRSYS ACRPRDCT on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of fed45000, febfb000 (3) failed
acpi0: reservation of fec0, 1000 (3) failed
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 3ff0 (3) failed
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 32-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: memory, RAM at device 0.1 (no driver attached)
pci0: memory, RAM at device 1.0 (no driver attached)
pci0: memory, RAM at device 1.1 (no driver attached)
pci0: memory, RAM at device 1.2 (no driver attached)
pci0: memory, RAM at device 1.3 (no driver attached)
pci0: memory, RAM at device 1.4 (no driver attached)
pci0: memory, RAM at device 1.5 (no driver attached)
pci0: memory, RAM at device 1.6 (no driver attached)
pci0: memory, RAM at device 2.0 (no driver attached)
isab0: PCI-ISA bridge port 0x4f00-0x4fff at device 3.0 on pci0
isa0: ISA bus on isab0
pci0: serial bus, SMBus at device 3.1 (no driver attached)
pci0: memory, RAM at device 3.2 (no driver attached)
pci0: processor at device 3.3 (no driver attached)
pci0: memory, RAM at device 3.4 (no driver attached)
ohci0: OHCI (generic) USB controller mem 0xfea7f000-0xfea7 irq 22 at
device 4.0 on pci0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
Re: Apache-worker stuck at 100% CPU
* Ivan Voras [EMAIL PROTECTED] [080915 16:05] wrote: 2008/9/13 Alfred Perlstein [EMAIL PROTECTED]: Yes, it's multithreaded apache. This did help somewhat - when I show threads in top I see that it's not actually stuck in umtxn - there's one thread that consumes the CPU and it's apparently always running (in state CPUx). PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND 7212 www 1030 30340K 7932K CPU2 2 444:23 99.02% httpd I'm currently upgrading the system to 7-STABLE, to see if it helps. It didn't help. Exactly the same symptom happened again. It looks like it happens a few days after the last system reboot. After it happens the first time, restarting Apache immediately produces one such stuck thread - it looks like some system state gets corrupted over time. How do I pick what thread to backtrace in gdb? i think the command is 'info threads' or 'show threads' then i think you just type 'thread FOO' to select the thread. Both commands don't work / don't exist. Any others? (background: apache22-worker port, no mod_php, on 7.0 and 7-STABLE suddenly gets stuck at 100% CPU; the same setup worked on 6-STABLE. I'm looking for ideas) I'm sorry, I really can't help at this point other than to look through the documents myself to figure out how to do a backtrace/select threads. Give it a shot, and let us know and we can go further. Apologies, -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
