Re: New em patch for 6.2 BETA 3
On 11/3/06, Kip Macy <[EMAIL PROTECTED]> wrote: If you create a patch against -CURRENT I can test on sun4v. The timeouts with em on sun4v are so severe that I have to use the driver from June for any kind of workload. -Kip I believe Gleb was going to merge code to current so you should have something before long, part of the changes are already there in John's recent checkins. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New em patch for 6.2 BETA 3
If you create a patch against -CURRENT I can test on sun4v. The timeouts with em on sun4v are so severe that I have to use the driver from June for any kind of workload. -Kip On 11/3/06, Jack Vogel <[EMAIL PROTECTED]> wrote: I have been hard at work trying to understand and fix the remaining issues with the em driver. What I have here is a patch that has gotten rid of any issues that I can reproduce. It solves the intermittent watchdogs that have been happening. It also fixes the problem noted with jumbo frame tx I, and re, would very much appreciate any test feedback you can give on this code. I am happy with the changes, I hope these get rid of everyone's issues. Thanks to Gleb and Scott and John for all the help! Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New em patch for 6.2 BETA 3
At 09:16 PM 11/3/2006, Jack Vogel wrote: I, and re, would very much appreciate any test feedback you can Thanks very much for working on this! I was not able to easily reproduce the timeouts in the first place, but so far on the one box I have been testing, it seems to be fine (netrate with various small packets). I will load up some more boxes tomorrow and see how it goes. I tested on an acpi0: on motherboard with the onboard NIC. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New em patch for 6.2 BETA 3
I have been hard at work trying to understand and fix the
remaining issues with the em driver. What I have here is
a patch that has gotten rid of any issues that I can reproduce.
It solves the intermittent watchdogs that have been happening.
It also fixes the problem noted with jumbo frame tx
I, and re, would very much appreciate any test feedback you can
give on this code. I am happy with the changes, I hope these get
rid of everyone's issues.
Thanks to Gleb and Scott and John for all the help!
Jack
diff -Naur stable/dev/em/if_em.c jfv/dev/em/if_em.c
--- stable/dev/em/if_em.c Fri Nov 3 02:02:29 2006
+++ jfv/dev/em/if_em.c Sat Nov 4 09:18:48 2006
@@ -204,7 +204,7 @@
static void em_start(struct ifnet *);
static void em_start_locked(struct ifnet *ifp);
static int em_ioctl(struct ifnet *, u_long, caddr_t);
-static void em_watchdog(struct ifnet *);
+static void em_watchdog(void *);
static void em_init(void *);
static void em_init_locked(struct adapter *);
static void em_stop(void *);
@@ -253,8 +253,7 @@
static int em_82547_fifo_workaround(struct adapter *, int);
static void em_82547_update_fifo_head(struct adapter *, int);
static int em_82547_tx_fifo_reset(struct adapter *);
-static void em_82547_move_tail(void *arg);
-static void em_82547_move_tail_locked(struct adapter *);
+static void em_82547_move_tail(void *);
static int em_dma_malloc(struct adapter *, bus_size_t,
struct em_dma_alloc *, int);
static void em_dma_free(struct adapter *, struct em_dma_alloc *);
@@ -406,8 +405,9 @@
OID_AUTO, "stats", CTLTYPE_INT|CTLFLAG_RW, adapter, 0,
em_sysctl_stats, "I", "Statistics");
- callout_init(&adapter->timer, CALLOUT_MPSAFE);
- callout_init(&adapter->tx_fifo_timer, CALLOUT_MPSAFE);
+ callout_init_mtx(&adapter->timer, &adapter->mtx, 0);
+ callout_init_mtx(&adapter->watchdog, &adapter->mtx, 0);
+ callout_init_mtx(&adapter->tx_fifo_timer, &adapter->mtx, 0);
/* Determine hardware revision */
em_identify_hardware(adapter);
@@ -622,6 +622,9 @@
EM_UNLOCK(adapter);
ether_ifdetach(adapter->ifp);
+ callout_drain(&adapter->timer);
+ callout_drain(&adapter->tx_fifo_timer);
+
em_free_pci_resources(adapter);
bus_generic_detach(dev);
if_free(ifp);
@@ -739,7 +742,7 @@
BPF_MTAP(ifp, m_head);
/* Set timeout in case hardware has problems transmitting. */
- ifp->if_timer = EM_TX_TIMEOUT;
+ callout_reset(&adapter->watchdog, 5 * hz, em_watchdog, adapter);
}
}
@@ -947,17 +950,28 @@
**/
static void
-em_watchdog(struct ifnet *ifp)
+em_watchdog(void *arg)
{
- struct adapter *adapter = ifp->if_softc;
+ struct adapter *adapter = arg;
+ struct ifnet *ifp = adapter->ifp;
+
+ /*
+ ** If we are above the clean threshold disarm callback
+ ** else rearm for 5 secs.
+ */
+ if (adapter->num_tx_desc_avail > EM_TX_CLEANUP_THRESHOLD) {
+ callout_stop(&adapter->watchdog);
+ return;
+ } else if (adapter->num_tx_desc_avail > EM_TX_OP_THRESHOLD) {
+ callout_reset(&adapter->watchdog, 5 * hz, em_watchdog, adapter);
+ return;
+ }
- EM_LOCK(adapter);
/* If we are in this routine because of pause frames, then
* don't reset the hardware.
*/
if (E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF) {
- ifp->if_timer = EM_TX_TIMEOUT;
- EM_UNLOCK(adapter);
+ callout_stop(&adapter->watchdog);
return;
}
@@ -968,7 +982,6 @@
adapter->watchdog_events++;
em_init_locked(adapter);
- EM_UNLOCK(adapter);
}
/*
@@ -1154,6 +1167,8 @@
* Interrupt Service routine
*
*/
+#define EM_MAX_INTR 10
+
static void
em_intr(void *arg)
{
@@ -1162,7 +1177,6 @@
uint32_t reg_icr;
EM_LOCK(adapter);
-
ifp = adapter->ifp;
#ifdef DEVICE_POLLING
@@ -1172,28 +1186,24 @@
}
#endif /* DEVICE_POLLING */
- for (;;) {
- reg_icr = E1000_READ_REG(&adapter->hw, ICR);
- if (adapter->hw.mac_type >= em_82571 &&
- (reg_icr & E1000_ICR_INT_ASSERTED) == 0)
- break;
- else if (reg_icr == 0)
- break;
+ reg_icr = E1000_READ_REG(&adapter->hw, ICR);
- /*
- * XXX: some laptops trigger several spurious interrupts
- * on em(4) when in the resume cycle. The ICR register
- * reports all-ones value in this case. Processing such
- * interrupts would lead to a freeze. I don't know why.
- */
- if (reg_icr == 0x)
- break;
+ if ((reg_icr == 0) || (adapter->hw.mac_type >= em_82571 &&
+ (reg_icr & E1000_ICR_INT_ASSERTED) == 0) ||
+ /*
+ * XXX: some laptops trigger several spurious interrupts
+ * on em(4) when in the resume cycle. The ICR register
+ * reports all-ones value in this case. Processing such
+ * interrupts would lead to a freeze. I don't know why.
+ */
+ (reg_icr == 0x))
+ goto leaving;
+ for (int i = 0;i < EM_MAX_INTR; ++i) {
if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
- em_rxeof(adapter, -1);
+ em_rxeof(adapter, 100)
Re: FreeBSD 6.2-PRE: Jumping box. Worse performance
On Sat, Nov 04, 2006 at 02:08:00AM +0100, O. Hartmann wrote: > Kris Kennaway wrote: > > On Fri, Nov 03, 2006 at 08:57:21PM +0100, O. Hartmann wrote: > > > >> Compiling FreeBSD's world with make -j2 was never a problem while playing > >> sound or doing other work on screen - but this seems to be a big problem > >> now, even when SCHED_4BSD is used! > >> > >> While compiling world mouse stops and jumps, sound gets distorted. I > >> recognise thsi behaviour also when box is doing minor HD access: mouse > >> pointer stops, keyboard input gets stuck, sound stops playing, window > >> operations (opening/closing) seems to freeze. This got even worse whithin > >> the last two weeks (date when it starts getting this worse unknown). > >> This phenomenon occurs on both i386 and amd64 but is much worse on amd64. > >> On AMD64 very short and small HD activities seems to trigger this > >> 'jumping' and stopping. > >> > >> Both boxes are singel core CPUs, AMD64 is a Athlon 3500+, i386 is a HTT > >> enabled P4 at 3.0 GHz. > >> > >> I do not get any error or system fault, simply this jumping and freezing. > >> > >> On both systems PREEMPTION is enabled in the kernel, but the problem also > >> occurs without this option. > >> > >> Any ideas, suggestion, maybe explanations? > >> > > > > Check for interrupt storms (vmstat -i). > > > > Kris > > > Already already checked, nothing suspicious ... Use top -S to check what is using the CPU. Kris pgpnt69csxIUe.pgp Description: PGP signature
Re: panic: kmem_map too small
Am 26.10.2006 um 15:47 schrieb Stefan Bethke: So far, the machines always just hang instead of dumping core; I'll see if I can get them to write a dump. Can umastat be run against a live kernel? Then I could try running it as a cron job to record data up to just before the panic. Still no core, but I've got a fairly short boot to panic snapshot of three commands: date /usr/bin/vmstat -m /sbin/sysctl hw.busdma /root/umastat The output is about 500kB, so I put it on a web server. http://www.lassitu.de/freebsd/kmem_panic/logmem.log-200611040100 -- 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: FreeBSD 6.2-PRE: Jumping box. Worse performance
Kris Kennaway wrote: > On Fri, Nov 03, 2006 at 08:57:21PM +0100, O. Hartmann wrote: > >> Compiling FreeBSD's world with make -j2 was never a problem while playing >> sound or doing other work on screen - but this seems to be a big problem >> now, even when SCHED_4BSD is used! >> >> While compiling world mouse stops and jumps, sound gets distorted. I >> recognise thsi behaviour also when box is doing minor HD access: mouse >> pointer stops, keyboard input gets stuck, sound stops playing, window >> operations (opening/closing) seems to freeze. This got even worse whithin >> the last two weeks (date when it starts getting this worse unknown). >> This phenomenon occurs on both i386 and amd64 but is much worse on amd64. On >> AMD64 very short and small HD activities seems to trigger this 'jumping' and >> stopping. >> >> Both boxes are singel core CPUs, AMD64 is a Athlon 3500+, i386 is a HTT >> enabled P4 at 3.0 GHz. >> >> I do not get any error or system fault, simply this jumping and freezing. >> >> On both systems PREEMPTION is enabled in the kernel, but the problem also >> occurs without this option. >> >> Any ideas, suggestion, maybe explanations? >> > > Check for interrupt storms (vmstat -i). > > Kris > Already already checked, nothing suspicious ... Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding an extra hard disk and adding space to /usr
Your only option here as far as I know is to partition the drive to be the new /usr partition. To acheive this you would preferrably put the system into single user mode, create a partition on the new drive and mount it under /mnt for example. Then copy all the data between. I prefer to use dump and pipe it into restore myself as this preserves all the filesystem flags that would get lost if you would just do a cp or tar. Then just update your fstab pointing /usr to the new drive and reboot the machine. Baldur On Fri, Nov 03, 2006 at 05:17:33PM -0500, Matt Smith wrote: > Hello all, > I have a machine that just had a new HD added to it as ad1 and I want to > ADD this new disk onto the already existing /usr partition. What's the best > and safest way to do it? > > Matt > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: kmem_map too small
Am 26.10.2006 um 15:47 schrieb Stefan Bethke: Am 26.10.2006 um 15:37 schrieb Robert Watson: On Thu, 26 Oct 2006, Stefan Bethke wrote: acpica 3024 159K 20026966 ... db> show uma Zone AllocsFrees UsedCache 64 9990754 9986054 4700 9980755 Looks like acpica has gone crazy performing allocation/freeing at a very high rate, and that for some reason, UMA is failing to properly reuse/release memory. So there are two bugs/problems here: whatever is causing ACPI to behave this way, and then the fact that UMA is failing to deal properly with its misbehavior. We had the machines running with ACPI disabled for a week or so, and we were still getting these panics, but I'll disable it again in the BIOS to make sure. Alternatively, that we have a bug in the way statistics are handled. If you can generate a coredump, it would be quite useful to be able to run umstat (src/tools/tools/umastat in HEAD) on it. The tool probably needs a bit of tweaking to run on the core dump -- in particular, the first and second arguments of kvm_open() need to be the name of the kernel and dumpfile, rather than NULL. This would help confirm what actual state UMA is in. So far, the machines always just hang instead of dumping core; I'll see if I can get them to write a dump. On two of the three boxes, the panics have not happened for a week. On the one I disabled ACPI on, no panics were seen for a week as well, so I enabled it again. Within an hour, the panic occurred. call doadump just hangs, so I won't be able to run umastat. I'll try to kick the box via the IPMI card and wait for the next panic. Fri Nov 3 23:22:58 CET 2006 FreeBSD/i386 (discovery.tallence.de) (ttyd0) login: -0255: *** Error: UtCallocate: Could not allocate size 30 -0255: *** Error: UtCallocate: Could not allocate size 30 -0255: *** Error: UtCallocate: Could not allocate size 30 ACPI-1304: *** Error: Method execution failed [\SWFS] (Node 0xc63ee220), AE_NO_MEMORY ACPI-1304: *** Error: Method execution failed [\RBYT] (Node 0xc63ee1a0), AE_NO_MEMORY ACPI-1304: *** Error: Method execution failed [\RTMP] (Node 0xc63ee380), AE_NO_MEMORY ACPI-1304: *** Error: Method execution failed [\_TZ_.THRM._TMP] (Node 0xc63ede00), AE_NO_MEMORY panic: kmem_malloc(4096): kmem_map too small: 699756544 total allocated KDB: enter: panic [thread pid 1119 tid 100074 ] Stopped at kdb_enter+0x30: leave db> show uma Zone AllocsFrees UsedCache pfosfp 1880 188 193 pfospfen 3450 345 51 pfiaddrpl0000 pfstatescrub0000 pffrcent0000 pffrcache0000 pffrag0000 pffrent0000 pfrkentry20000 pfrkentry0000 pfrktable0000 pfpooladdrpl0000 pfaltqpl0000 pfstatepl 873 844 29 76 pfrulepl 620 62 10 pfsrctrpl101 77 FFS2 dinode 2117 193 1924 11 FFS1 dinode0000 FFS inode 2117 193 1924 48 Mountpoints 190 195 SWAPMETA0000 rtentry 100 10 48 unpcb 664 613 51 33 ripcb0000 sackhole0000 tcpreass990 169 hostcache 390 39 61 syncache 150 1500 78 tcptw 55 550 156 tcpcb 229 198 31 25 inpcb 229 198 31 35 udpcb 979 959 20 24 ipq0000 socket 1873 1771 1028 KNOTE 1242 12420 112
Re: 6.x from i386 to amd64
On Fri, Nov 03, 2006 at 07:33:31PM +1100, Peter Jeremy wrote: > On Thu, 2006-Nov-02 11:12:43 -0800, David Marshall wrote: > > More importantly for us, it's impossible to build a 32-bit > > perl on the amd64, and we don't need a 64-bit perl. Our > > apache/mod_perl servers are 3X bigger on the amd64, and that > > is unsatisfactory. > > In most cases, an amd64 executable will be larger than an i386 > executable. I'm surprised that you've found such a big > difference. > I also found a threefold increase in the memory footprint of apache/mod_php/mod_perl when I switched from i386 to amd64. From what I've read this isn't unheard of on 64 bit linux/apache/php. Most other applications tend to be slightly larger on amd64. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
netstat -ni - A lot of collisions...
Hi there group. I'm having trouble with a fxp0 card. When I ping it there are little lost packets, also the netstat -ni shows a lot collisions. The polling is enabled: kern.polling.idlepoll_sleeping: 1 kern.polling.stalled: 422 kern.polling.suspect: 937141 kern.polling.phase: 0 kern.polling.enable: 1 kern.polling.handlers: 1 kern.polling.residual_burst: 0 kern.polling.pending_polls: 0 kern.polling.lost_polls: 944349 kern.polling.short_ticks: 623 kern.polling.reg_frac: 20 kern.polling.user_frac: 50 kern.polling.poll_in_trap: 0 kern.polling.idle_poll: 0 kern.polling.burst_max: 150 kern.polling.each_burst: 5 kern.polling.burst: 150 hw.acpi.thermal.polling_rate: 10 What are they for? I've taken a look at the man netstat but wasn't able to find description? thanks! Here is the netstat -ni netstat -ni NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll fxp0 1500 00:08:c7:5b:53:5f 4504986 0 2093233 0 185206 fxp0 1500 112.15.128112.15.128.88 1716322 - 2108533 - - plip0 15000 00 0 0 pflog 332080 00 0 0 lo0 16384 4157762 0 4157762 0 0 lo0 16384 127 127.0.0.1 3964179 - 3964179 - - lo0 16384 ::1/128 ::1 191850 - 191850 - - lo0 16384 fe80:5::1/64 fe80:5::10 -0 - - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: adding an extra hard disk and adding space to /usr
Hello all, I have a machine that just had a new HD added to it as ad1 and I want to ADD this new disk onto the already existing /usr partition. What's the best and safest way to do it? Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Latest Info on Large Disk Access?
Anybody know what the latest info getting STABLE up-to-speed with large disks is? Most recent info I could find was here, from 2004-05: http://www.freebsd.org/projects/bigdisk/index.html Are most of the userland tools able to handle > 2TB capacities now? D ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-PRE: Jumping box. Worse performance
On Fri, Nov 03, 2006 at 08:57:21PM +0100, O. Hartmann wrote: > > Compiling FreeBSD's world with make -j2 was never a problem while playing > sound or doing other work on screen - but this seems to be a big problem now, > even when SCHED_4BSD is used! > > While compiling world mouse stops and jumps, sound gets distorted. I > recognise thsi behaviour also when box is doing minor HD access: mouse > pointer stops, keyboard input gets stuck, sound stops playing, window > operations (opening/closing) seems to freeze. This got even worse whithin the > last two weeks (date when it starts getting this worse unknown). > This phenomenon occurs on both i386 and amd64 but is much worse on amd64. On > AMD64 very short and small HD activities seems to trigger this 'jumping' and > stopping. > > Both boxes are singel core CPUs, AMD64 is a Athlon 3500+, i386 is a HTT > enabled P4 at 3.0 GHz. > > I do not get any error or system fault, simply this jumping and freezing. > > On both systems PREEMPTION is enabled in the kernel, but the problem also > occurs without this option. > > Any ideas, suggestion, maybe explanations? Check for interrupt storms (vmstat -i). Kris pgpdtFjQEuZng.pgp Description: PGP signature
Re: panic on 6.2-PRERELEASE (With backtrace)
On Fri, Nov 03, 2006 at 05:33:42PM +0200, Nikolay Pavlov wrote: > Hi, guys. I have a panic running squid as web accelerator on > 6.2-PRERELEASE. Here is a backtrace: > > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ACCEL# kgdb kernel.debug > /var/crash/vmcore.0 > kgdb: kvm_nlist(_stopped_cpus): > kgdb: kvm_nlist(_stoppcbs): > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: > Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated Your kernel ran out of memory. This comes up quite a lot so you can google for the solution. Kris pgpckU52Xic20.pgp Description: PGP signature
FreeBSD 6.2-PRE: Jumping box. Worse performance
Compiling FreeBSD's world with make -j2 was never a problem while playing sound or doing other work on screen - but this seems to be a big problem now, even when SCHED_4BSD is used! While compiling world mouse stops and jumps, sound gets distorted. I recognise thsi behaviour also when box is doing minor HD access: mouse pointer stops, keyboard input gets stuck, sound stops playing, window operations (opening/closing) seems to freeze. This got even worse whithin the last two weeks (date when it starts getting this worse unknown). This phenomenon occurs on both i386 and amd64 but is much worse on amd64. On AMD64 very short and small HD activities seems to trigger this 'jumping' and stopping. Both boxes are singel core CPUs, AMD64 is a Athlon 3500+, i386 is a HTT enabled P4 at 3.0 GHz. I do not get any error or system fault, simply this jumping and freezing. On both systems PREEMPTION is enabled in the kernel, but the problem also occurs without this option. Any ideas, suggestion, maybe explanations? Regards, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Watchdog Timeout - bge device - 6.2-PRERELEASE
On 2 Nov 2006, at 23:50, John Marshall wrote: bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP I'm seeing similar behaviour on a HP DL360g4 running 6.1-RELEASE and a GENERIC kernel. It had similar problems with 5.4. I have 2 other similar machines running 6.1, which don't record these errors, however they never see any sustained throughput whereas this machine does. bge0: mem 0xfde7-0xfde7 irq 25 at device 2.0 on pci2 IRQ is not shared vmstat -i interrupt total rate irq1: atkbd01668 0 irq6: fdc087 0 irq14: ata0 46 0 irq16: uhci049865767 5 irq24: ciss0 6645080 0 irq25: bge0336582162 34 irq26: bge1313542372 32 irq48: mpt0 49865839 5 cpu0: timer 2055753320210 Total 2812256341287 Scott Long said Is it causing stuck connections or other messy problems? Also, is it any worse than 6.1? Fortunately all it seems to be doing is bothering my log files. I'm taking an interest as I have two important production machines using the bge driver both about to be upgraded from 5.3R to 6.1R. I've just grepped the logs on those machines and they both have a sprinkling of timeouts (5 over 18 months on one quite heavily trafficked webserver, the other which continously serves http downloads is clean apart from 1 24hour period when it was having 200GB of files uploaded to it). My concern is that upgrading to 6.1 or 6.2 and then enabling device polling is going to make the issue worse. I'm happy to supply more info. best. greg. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Intel PRO/100 VE extra PCI ID
On 11/3/06, M. Warner Losh <[EMAIL PROTECTED]> wrote: In message: <[EMAIL PROTECTED]> Rink Springer <[EMAIL PROTECTED]> writes: : Hi people, : : Recently, I installed FreeBSD on a Tyan GS14 barebone, which houses an : bge(4) and a fxp(4). However, FreeBSD does not recognize the on-board : fxp(4) NIC by default. : : All that was needed was just an extra PCI ID addition; the patch can be : found at http://rink.nu/tmp/if_fxp.ve.diff. With this patch applies, : pciconf -lv gives: : : -- : [EMAIL PROTECTED]:8:0: class=0x02 card=0x27dc8086 chip=0x10658086 rev=0x04 : hdr=0x00 : vendor = 'Intel Corporation' : device = '82562ET/EZ/GT/GZ PRO/100 VE Ethernet Controller' : class= network : subclass = ethernet : -- : : And the NIC works fine. Are there any objections to committing this? Go for it. Warner Absolutely, happy to have you do it. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
firefox hangs on 6.2-PRERELEASE amd64
Yesterday I updated my amd64 STABLE box to 6.2-PRERELEASE. After the upgrade, firefox started to hang. I can reliably trigger this my clicking on the [Manage...] button in the "Content" tab of the preferences dialog. The same happens when trying to access some websites. Both firefox 1.5.0.7 and 2.0 hang, which suggests something external. I'm running a custum kernel. The only thing I added with the upgrade was: options HWPMC_HOOKS device hwpmc Running a ktrace on firefox didn't give very much; 14732 sh NAMI "/usr/local/lib/firefox/run-mozilla.sh" 14732 sh RET stat 0 14732 sh CALL eaccess(0x523620,0x1) 14732 sh NAMI "/usr/local/lib/firefox/run-mozilla.sh" 14732 sh RET eaccess 0 14732 sh CALL geteuid 14732 sh RET geteuid 0 14732 sh CALL read(0xa,0x520fa0,0x3ff) 14732 sh GIO fd 10 read 439 bytes "hift set -- "$@" "$arg" pass_arg_count=`expr $pass_arg_count + 1` ;; esac done export MRE_HOME ## Start addon scripts moz_pis_startstop_scripts "start" if [ $debugging = 1 ] then echo $dist_bin/run-mozilla.sh $script_args $dist_bin/$MOZILLA_BIN "$\ @" fi "$dist_bin/run-mozilla.sh" $script_args "$dist_bin/$MOZILLA_BIN" "$@" exitcode=$? ## Stop addon scripts moz_pis_startstop_scripts "stop" exit $exitcode # EOF. " 14732 sh RET read 439/0x1b7 14732 sh CALL madvise(0x52a000,0x1000,0x5) 14732 sh RET madvise 0 14732 sh CALL stat(0x525800,0x7fffdeb0) 14732 sh NAMI "/usr/local/lib/firefox/init.d" 14732 sh RET stat 0 14732 sh CALL open(0x525800,0x4,0) 14732 sh NAMI "/usr/local/lib/firefox/init.d" 14732 sh RET open 3 14732 sh CALL fstat(0x3,0x7fffdeb0) 14732 sh RET fstat 0 14732 sh CALL fcntl(0x3,0x2,0x1) 14732 sh RET fcntl 0 14732 sh CALL __sysctl(0x7fffdca0,0x2,0x800acb858,0x7fffdc98,0,0 ) 14732 sh RET __sysctl 0 14732 sh CALL fstatfs(0x3,0x7fffdcd0) 14732 sh RET fstatfs 0 14732 sh CALL getdirentries(0x3,0x52b000,0x1000,0x52a028) 14732 sh RET getdirentries 512/0x200 14732 sh CALL getdirentries(0x3,0x52b000,0x1000,0x52a028) 14732 sh RET getdirentries 0 14732 sh CALL lseek(0x3,0,0,0) 14732 sh RET lseek 0 14732 sh CALL madvise(0x52b000,0x1000,0x5) 14732 sh RET madvise 0 14732 sh CALL madvise(0x52a000,0x1000,0x5) 14732 sh RET madvise 0 14732 sh CALL close(0x3) 14732 sh RET close 0 14732 sh CALL stat(0x525800,0x7fffdeb0) 14732 sh NAMI "/root/.mozilla/firefox/init.d" 14732 sh RET stat -1 errno 2 No such file or directory 14732 sh CALL stat(0x523408,0x7fffdc70) 14732 sh NAMI "/usr/local/lib/firefox/init.d/S*" 14732 sh RET stat -1 errno 2 No such file or directory 14732 sh CALL stat(0x523408,0x7fffdc70) 14732 sh NAMI "/root/.mozilla/firefox/init.d/S*" 14732 sh RET stat -1 errno 2 No such file or directory 14732 sh CALL fork 14732 sh RET fork 14736/0x3990 14732 sh CALL getpgrp 14732 sh RET getpgrp 14732/0x398c 14732 sh CALL wait4(0x,0x7fffe2c4,0x2,0) 14732 sh RET wait4 -1 errno 4 Interrupted system call 14732 sh PSIG SIGINT caught handler=0x415fc0 mask=0x0 code=0x0 14732 sh CALL sigreturn(0x7fffde70) 14732 sh RET sigreturn JUSTRETURN 14732 sh CALL wait4(0x,0x7fffe2c4,0x2,0) 14732 sh RET wait4 14736/0x3990 14732 sh CALL getpid 14732 sh RET getpid 14732/0x398c 14732 sh CALL kill(0x398c,0x2) 14732 sh RET kill 0 14732 sh PSIG SIGINT caught handler=0x415fc0 mask=0x0 code=0x0 14732 sh CALL sigreturn(0x7fffdea0) 14732 sh RET sigreturn JUSTRETURN 14732 sh CALL sigprocmask(0x3,0x7fffe2f0,0) 14732 sh RET sigprocmask 0 14732 sh CALL sigaction(0x2,0x7fffe2b0,0x7fffe290) 14732 sh RET sigaction 0 14732 sh CALL getpid 14732 sh RET getpid 14732/0x398c 14732 sh CALL kill(0x398c,0x2) 14732 sh RET kill 0 14732 sh PSIG SIGINT SIG_DFL After starting firefox, I see a defunct process, that's probably a child of firefox: 16772 v0 I 0:00.00 /bin/sh /usr/local/bin/firefox 16776 v0 I 0:00.00 /bin/sh /usr/local/lib/firefox/run-mozilla.sh /usr/lo 16780 v0 S 0:01.87 /usr/local/lib/firefox/firefox-bin 16785 v0 Z 0:00.01 I tried attaching gdb to a running firefox-bin, but that produced an internal error in gdb which made it dump core. :-( Also, when starting firefox from an xterm, it produces a warning
Re: panic on 6.2-PRERELEASE (With backtrace)
On Friday, 3 November 2006 at 17:33:42 +0200, Nikolay Pavlov wrote:
> Hi, guys. I have a panic running squid as web accelerator on
> 6.2-PRERELEASE. Here is a backtrace:
>
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ACCEL# kgdb kernel.debug
> /var/crash/vmcore.0
> kgdb: kvm_nlist(_stopped_cpus):
> kgdb: kvm_nlist(_stoppcbs):
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd".
>
> Unread portion of the kernel message buffer:
> panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated
> KDB: stack backtrace:
> kdb_backtrace(100,cb83b000,c1040500,c1040500,0,...) at kdb_backtrace+0x29
> panic(c06e0826,1000,1400,dd22b6e8,1000,...) at panic+0xa8
> kmem_malloc(c104b0c0,1000,102,ebc75aec,c063c285,...) at kmem_malloc+0x89
> page_alloc(c103d080,1000,ebc75adf,102,38,...) at page_alloc+0x1a
> slab_zalloc(c103d080,102,c103d0c8,c103d080,c1032d9c,...) at slab_zalloc+0xa1
> uma_zone_slab(c103d080,2) at uma_zone_slab+0xe8
> uma_zalloc_bucket(c103d080,2) at uma_zalloc_bucket+0x11c
> uma_zalloc_arg(c103d080,dd18d100,2) at uma_zalloc_arg+0x2dc
> mb_zinit_pack(dd18d100,100,2) at mb_zinit_pack+0x18
> uma_zalloc_bucket(c103d100,3) at uma_zalloc_bucket+0x168
> uma_zalloc_arg(c103d100,ebc75bfc,2) at uma_zalloc_arg+0x2dc
> sosend(cbb7842c,0,ebc75cbc,0,0,0,cb83b000) at sosend+0x3c5
> soo_write(daa2f870,ebc75cbc,cb68d100,0,cb83b000) at soo_write+0xa1
> dofilewrite(cb83b000,1174,daa2f870,ebc75cbc,,...) at dofilewrite+0x77
> kern_writev(cb83b000,1174,ebc75cbc,cfa4000,1000,...) at kern_writev+0x3b
> write(cb83b000,ebc75d04) at write+0x45
> syscall(82e003b,3b,bfbe003b,e894ea0,e2e40,...) at syscall+0x25b
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (4, FreeBSD ELF32, write), eip = 0xa8319bab, esp = 0xbfbe8cac,
> ebp = 0xbfbe8cd8 ---
> KDB: enter: panic
> panic: from debugger
> Uptime: 5m34s
> Dumping 3967 MB (3 chunks)
> chunk 0: 1MB (159 pages) ... ok
> chunk 1: 3966MB (1015280 pages) 3950 3934 3918 3902 3886 3870 3854 3838
> 3822 3806
> 3790 3774 3758 3742 3726 3710 3694 3678 3662 3646 3630 3614 3598 3582 3566
> 3550
> 3534 3518 3502 3486 3470 3454 3438 3422 3406 3390 3374 3358 3342 3326 3310
> 3294
> 3278 3262 3246 3230 3214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054
> 3038
> 3022 3006 2990 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798
> 2782
> 2766 2750 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542
> 2526
> 2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286
> 2270
> 2254 2238 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030
> 2014
> 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774
> 1758
> 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518
> 1502
> 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262
> 1246
> 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006
> 990
> 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686
> 670
> 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366
> 350
> 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14
> ... ok
> chunk 2: 1MB (128 pages)
>
> #0 doadump () at pcpu.h:165
> 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) quit
>
>
> Some additional information:
>
> [EMAIL PROTECTED]:~# cat /boot/loader.conf
> # --- Loader settings ---
> autoboot_delay="5" # Delay in seconds before autobooting
>
> # --- Kernel tunables ---
> kern.ipc.nmbclusters="131072" # Set the number of mbuf clusters
> kern.cam.scsi_delay="5000" # Delay (in ms) before probing SCSI
> kern.maxdsiz="2560M"# Allow more memory allocation for squid
> kern.dfldsiz="2560M"# Allow more memory allocation for squid
> kern.maxssiz="128M" # Allow more memory allocation for squid
>
> # --- Networking modules ---
> pf_load="YES" # Packet filter
>
> # --- Other modules ---
> accf_data_load="YES" # Wait for data accept filter
> accf_http_load="YES" # Wait for full HTTP request accept filter
>
> [EMAIL PROTECTED]:~# cat /etc/sysctl.conf
>
> # --- MAC access for squid ---
> net.inet.ip.portrange.reservedlow=0
> net.inet.ip.portrange.reservedhigh=0
> security.mac.portacl.rules=uid:100:tcp:80
>
>
> # --- Kernel tunning ---
> kern.ipc.somaxconn=8192
>
> # --- Network tunning and protection ---
> kern.ipc.maxsockbuf=1048576
> net.inet.tc
panic on 6.2-PRERELEASE (With backtrace)
Hi, guys. I have a panic running squid as web accelerator on
6.2-PRERELEASE. Here is a backtrace:
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ACCEL# kgdb kernel.debug
/var/crash/vmcore.0
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated
KDB: stack backtrace:
kdb_backtrace(100,cb83b000,c1040500,c1040500,0,...) at kdb_backtrace+0x29
panic(c06e0826,1000,1400,dd22b6e8,1000,...) at panic+0xa8
kmem_malloc(c104b0c0,1000,102,ebc75aec,c063c285,...) at kmem_malloc+0x89
page_alloc(c103d080,1000,ebc75adf,102,38,...) at page_alloc+0x1a
slab_zalloc(c103d080,102,c103d0c8,c103d080,c1032d9c,...) at slab_zalloc+0xa1
uma_zone_slab(c103d080,2) at uma_zone_slab+0xe8
uma_zalloc_bucket(c103d080,2) at uma_zalloc_bucket+0x11c
uma_zalloc_arg(c103d080,dd18d100,2) at uma_zalloc_arg+0x2dc
mb_zinit_pack(dd18d100,100,2) at mb_zinit_pack+0x18
uma_zalloc_bucket(c103d100,3) at uma_zalloc_bucket+0x168
uma_zalloc_arg(c103d100,ebc75bfc,2) at uma_zalloc_arg+0x2dc
sosend(cbb7842c,0,ebc75cbc,0,0,0,cb83b000) at sosend+0x3c5
soo_write(daa2f870,ebc75cbc,cb68d100,0,cb83b000) at soo_write+0xa1
dofilewrite(cb83b000,1174,daa2f870,ebc75cbc,,...) at dofilewrite+0x77
kern_writev(cb83b000,1174,ebc75cbc,cfa4000,1000,...) at kern_writev+0x3b
write(cb83b000,ebc75d04) at write+0x45
syscall(82e003b,3b,bfbe003b,e894ea0,e2e40,...) at syscall+0x25b
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (4, FreeBSD ELF32, write), eip = 0xa8319bab, esp = 0xbfbe8cac, ebp
= 0xbfbe8cd8 ---
KDB: enter: panic
panic: from debugger
Uptime: 5m34s
Dumping 3967 MB (3 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 3966MB (1015280 pages) 3950 3934 3918 3902 3886 3870 3854 3838 3822
3806
3790 3774 3758 3742 3726 3710 3694 3678 3662 3646 3630 3614 3598 3582 3566 3550
3534 3518 3502 3486 3470 3454 3438 3422 3406 3390 3374 3358 3342 3326 3310 3294
3278 3262 3246 3230 3214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038
3022 3006 2990 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782
2766 2750 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526
2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270
2254 2238 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2014
1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774 1758
1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502
1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246
1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990
974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670
654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350
334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14
... ok
chunk 2: 1MB (128 pages)
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) quit
Some additional information:
[EMAIL PROTECTED]:~# cat /boot/loader.conf
# --- Loader settings ---
autoboot_delay="5" # Delay in seconds before autobooting
# --- Kernel tunables ---
kern.ipc.nmbclusters="131072" # Set the number of mbuf clusters
kern.cam.scsi_delay="5000" # Delay (in ms) before probing SCSI
kern.maxdsiz="2560M"# Allow more memory allocation for squid
kern.dfldsiz="2560M"# Allow more memory allocation for squid
kern.maxssiz="128M" # Allow more memory allocation for squid
# --- Networking modules ---
pf_load="YES" # Packet filter
# --- Other modules ---
accf_data_load="YES" # Wait for data accept filter
accf_http_load="YES" # Wait for full HTTP request accept filter
[EMAIL PROTECTED]:~# cat /etc/sysctl.conf
# --- MAC access for squid ---
net.inet.ip.portrange.reservedlow=0
net.inet.ip.portrange.reservedhigh=0
security.mac.portacl.rules=uid:100:tcp:80
# --- Kernel tunning ---
kern.ipc.somaxconn=8192
# --- Network tunning and protection ---
kern.ipc.maxsockbuf=1048576
net.inet.tcp.sendspace=262144
net.inet.tcp.recvspace=131072
net.inet.tcp.msl=3000
net.inet.icmp.icmplim=50
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1
net.inet.ip.redirect=0
net.inet6.ip6.redirect=0
Kernel was complied with this additional options:
options KDB
options KDB_TRACE
options
Re: Watchdog Timeout - bge device - 6.2-PRERELEASE
"John Marshall" <[EMAIL PROTECTED]> writes: > rwsrv05> dmesg | grep bge > bge0: mem 0xe820-0xe820 > irq 17 at device 4.0 on pci4 > miibus1: on bge0 > bge0: Ethernet address: 00:0b:cd:e7:70:19 > bge0: link state changed to UP > bge0: watchdog timeout -- resetting I have a Tyan S2850 with the same (dual) LAN-chip; I increased BGE_TIMEOUT to 50 (due to reboot problems on a good-old 3com 100Mbps-hub which occasionaly gave me : bge1: firmware handshake timed out bge1: RX CPU self-diagnostics failed! ) This box occasionaly freezes under heavy load; with the above change AND compiling in DEVICE_POLLING but not enabling it, I do not have any problem for the time being (though the freeze is very hard to reproduce). Arno ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Intel PRO/100 VE extra PCI ID
In message: <[EMAIL PROTECTED]> Rink Springer <[EMAIL PROTECTED]> writes: : Hi people, : : Recently, I installed FreeBSD on a Tyan GS14 barebone, which houses an : bge(4) and a fxp(4). However, FreeBSD does not recognize the on-board : fxp(4) NIC by default. : : All that was needed was just an extra PCI ID addition; the patch can be : found at http://rink.nu/tmp/if_fxp.ve.diff. With this patch applies, : pciconf -lv gives: : : -- : [EMAIL PROTECTED]:8:0: class=0x02 card=0x27dc8086 chip=0x10658086 rev=0x04 : hdr=0x00 : vendor = 'Intel Corporation' : device = '82562ET/EZ/GT/GZ PRO/100 VE Ethernet Controller' : class= network : subclass = ethernet : -- : : And the NIC works fine. Are there any objections to committing this? Go for it. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent VFS crashes with RELENG_6
On 10/31/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: It now crashes in a different place. Unfortunately I don't have physical access to the machine. A bt full is available at http://night.rdslink.ro/dudu/freebsd/03_11_2006.txt. The stack was corrupted though :( -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Intel PRO/100 VE extra PCI ID
At 05:03 AM 11/3/2006, Rink Springer wrote: Hi people, Recently, I installed FreeBSD on a Tyan GS14 barebone, which houses an bge(4) and a fxp(4). However, FreeBSD does not recognize the on-board fxp(4) NIC by default. All that was needed was just an extra PCI ID addition; the patch can be found at http://rink.nu/tmp/if_fxp.ve.diff. With this patch applies, pciconf -lv gives: -- [EMAIL PROTECTED]:8:0: class=0x02 card=0x27dc8086 chip=0x10658086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82562ET/EZ/GT/GZ PRO/100 VE Ethernet Controller' class= network subclass = ethernet -- And the NIC works fine. Are there any objections to committing this? There is another fxp ID as well http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/030169.html Jack Vogel was going to look at it, but I think he is pretty busy with the em issue and it would be nice to get this in prior to 6.2 as this board is becoming common in the retail channel (around here at least) ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Watchdog Timeout - bge device - 6.2-PRERELEASE
> Is it causing stuck connections or other messy problems? Also, is it > any worse than 6.1? I am also seeing the same thing - hard to tell if it is better or worse under 6.2 than 6.1 as I dont have 6.2 out on any production webservers so the only machine running it is a lot more lightly loaded (but does show less watchdog timeouts) -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: I/O deadlock under load
On 10/28/06, Christian S.J. Peron <[EMAIL PROTECTED]> wrote: It almost looks as if a user frequently runs gmirror(8) to query the status of their array. Under a high load situation, the worker is busy, so at one un-lucky momment, gmirror(8) is run: (1) gmirror(8) waits for sc->sc_lock owned by the worker (2) The worker then drops the lock (3) gmirror(8) proceeds (4) Worker wakes up and waits for sc->sc_lock (5) Only gmirror never will because it's waiting on a resource (presumably owned by the worker thread)? I am not certain this is correct, so I have included pjd in the CC loop, hoping he can help shed some light on the subject :) This is just a followup to report that the problem seems unreproducable on an identical kernel if I leave out option PREEMPTION. Performance sucks that way, but at least it's stable now. Pawel seems to be rather busy with his GJOURNAL work and his ZFS port, is someone else able to reproduce the problem? Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] Intel PRO/100 VE extra PCI ID
Hi people, Recently, I installed FreeBSD on a Tyan GS14 barebone, which houses an bge(4) and a fxp(4). However, FreeBSD does not recognize the on-board fxp(4) NIC by default. All that was needed was just an extra PCI ID addition; the patch can be found at http://rink.nu/tmp/if_fxp.ve.diff. With this patch applies, pciconf -lv gives: -- [EMAIL PROTECTED]:8:0: class=0x02 card=0x27dc8086 chip=0x10658086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82562ET/EZ/GT/GZ PRO/100 VE Ethernet Controller' class= network subclass = ethernet -- And the NIC works fine. Are there any objections to committing this? Thanks, -- Rink P.W. Springer- http://rink.nu "It's you isn't it? THE BASTARD OPERATOR FROM HELL!" "In the flesh, on the phone and in your account..." - BOFH #3 pgpC7q81hwlu4.pgp Description: PGP signature
Re: Boot FreeBSD from grub
Joseph Koshy wrote: > sz> How can add FreeBSD into grub menu? I can see FreeBSD file > sz> system via fdisk -l comand. > > Something like the following should work in > "/boot/grub/menu.lst": > > title FreeBSD > root (hd0,a) > kernel /boot/loader > > assuming that the 'a' partition is where the kernel resides. > > There might be a catch: I'm not sure if GRUB understands > UFS2 filesystems, so you might need to ensure that the 'a' > partition is UFS1. > grub knows UFS2. -- Dixi. Sem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.x from i386 to amd64
On Thu, 2006-Nov-02 11:12:43 -0800, David Marshall wrote: >has 6.1/i386. The i386 has a better ubench score. This is not necessarily relevant to real-world performance. Both architectures have their strengths and weaknesses and you really need to make a decision based on how your own application performs. > More importantly >for us, it's impossible to build a 32-bit perl on the amd64, and we >don't need a 64-bit perl. Our apache/mod_perl servers are 3X bigger >on the amd64, and that is unsatisfactory. In most cases, an amd64 executable will be larger than an i386 executable. I'm surprised that you've found such a big difference. -- Peter Jeremy pgpXS8PUKwh0c.pgp Description: PGP signature
