Re: Radeon r6/7xx support merged to -STABLE
On Sun, Mar 15, 2009 at 10:27:53PM -0500, Robert Noland wrote: > On Sun, 2009-03-15 at 23:33 +0200, Kostik Belousov wrote: > > On Sun, Mar 15, 2009 at 01:49:12PM -0500, Robert Noland wrote: > > > I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago. > > > > > > The current xorg drivers will not enable it by default on R600+ chips. > > > You will need to be using xf86-video-ati-6.12.0, > > > xf86-video-radeonhd-devel or possibly even better git master of either. > > > > > > You will need to add the following to the Device section of your > > > xorg.conf to enable it. If you are experiencing issues, commenting > > > these two options out, will prevent Xorg from auto-loading the kernel > > > module. > > > > > > Options "DRI" > > > Options "AccelMethod" "EXA" > > > > With this code and ati 6.12.0, I get the awful performance. > > Kernel says > > drm0: on vgapci0 > > vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xd002 > > vgapci0: child drm0 requested pci_enable_busmaster > > info: [drm] Initialized radeon 1.29.0 20080528 > > vgapci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc000 > > info: [drm] Setting GART location based on new memory map > > error: [drm:pid1494:r600_do_init_cp] *ERROR* Need gart offset from userspace > > Your card was agp right? No, this is PCIe card. It is reported correctly as Radeon HD 2600 XT. Motherboard chipset is Intel P43, if this makes any useful information. > > What happens if you force pci mode? > > Options "BusType" "PCI" > > robert. > > > Then, the Xorg.0.log > > ... > > (II) RADEON(0): [drm] register handle = 0xd002 > > (II) RADEON(0): [dri] Visual configs initialized > > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > > (II) RADEON(0): MC_FB_LOCATION : 0x00df00c0 0x00df00c0 > > (II) RADEON(0): MC_AGP_LOCATION : 0x003f > > (==) RADEON(0): Backing store disabled > > (II) RADEON(0): [DRI] installation complete > > (II) RADEON(0): [drm] removed 1 reserved context for kernel > > (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc731d000 at 0x286fd000 > > (II) RADEON(0): [drm] Closed DRM master. > > (WW) RADEON(0): Direct rendering disabled > > (EE) RADEON(0): Acceleration initialization failed > > ... > -- > Robert Noland > FreeBSD pgpZo5J5wp1gX.pgp Description: PGP signature
bge0: EEPROM read timed
Hi. I got this on today's RELENG_6 with Broadcom BCM5722 A0, ASIC rev. 0xa200. >From dmesg (bge related): bge0: mem 0xe840-0xe840 irq 16 at device 0.0 on pci2 bge0: firmware handshake timed out, found 0x4b657654 bge0: firmware handshake timed out, found 0x4b657654 bge0: EEPROM read timed out bge0: failed to read EEPROM device_attach: bge0 attach returned 6 bge1: mem 0xe860-0xe860 irq 21 at device 1.0 on pci3 miibus0: on bge1 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: 00:21:5e:4d:05:c8 any hints? P.S. I see EEPROM timeout fixes were already merged to RELENG_6 (I have post-fix version certainly). May that issue be somehow related? -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mergemaster annoyance or not?
Doug Barton wrote: > The attached patch adds a -F option to automatically install files > when only the FreeBSD $Ids differ. I've tested this and it seems to do > what the people concerned about this issue are asking for. That seems to be a useful feature. You need to quote the dollar signs, though. However, maybe the best solution is to add a new keyword for mergemaster.rc, so the user can exactly specify which kind of changes should be always installed. So the new -L option (which could still exist as a short-cut) would be the same as the following line in mergemaster.rc: AUTO_INSTALL_DIFF='-I[$]FreeBSD:.*[$]' For example, if someone is not interested in pure white- space changes and changes to #-style comments, he could let those be auto-installed thusly: AUTO_INSTALL_DIFF='-Bb -I#.* -I[$]FreeBSD:.*[$]' What do you think? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge0: EEPROM read timed
2009/3/16 pluknet : > Hi. > > I got this on today's RELENG_6 with Broadcom BCM5722 A0, ASIC rev. 0xa200. > > From dmesg (bge related): > > bge0: mem > 0xe840-0xe840 irq 16 at device 0.0 on pci2 > bge0: firmware handshake timed out, found 0x4b657654 > bge0: firmware handshake timed out, found 0x4b657654 > bge0: EEPROM read timed out > bge0: failed to read EEPROM > device_attach: bge0 attach returned 6 > bge1: mem > 0xe860-0xe860 irq 21 at device 1.0 on pci3 > miibus0: on bge1 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bge1: Ethernet address: 00:21:5e:4d:05:c8 > > > any hints? > > P.S. I see EEPROM timeout fixes were already merged to RELENG_6 (I > have post-fix version certainly). > May that issue be somehow related? > I guess it's a regression. Below are my speculations. I tried to build on 6.2-R the bge(4) sources checked from later RELENG_6 just after BCM5722 support (from if_bgereg.h 1.36.2.11/ if_bge.c1.91.2.26) in order to backport BCM5722 support into 6.2-R. After some tweaks it was built, so.. What I got in dmesg (after native statically built bge(4) replacement in boot loader prompt) is: FreeBSD 6.2-RELEASE-p8 #13: Thu Feb 19 14:52:30 MSK 2009 [..snip..] bgex0: mem 0xe840-0xe840 irq 16 at device 0.0 on pci2 bgex0: Ethernet address: 00:21:5e:4d:05:c7 Whoohoo.. So, here it even reached macaddr designation. (and going to panic at nfs boot time (probably to different locking scheme between 6.2 and 6.4, but it's an another story)). -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FIB (routing table) question with jailed service
Hello, I set up a second routingtable and told rc.d/jail to use the FIB1. Now I wonder why the SSHd in the jail isn't responding. I set the default router to a local address and the second default router in FIB1 to the ISP router, reachable via a second NIC. Does the FIb only work for outgoing, intiating connections? Best regards, -Harry signature.asc Description: OpenPGP digital signature
Re: Radeon r6/7xx support merged to -STABLE
On Mon, 2009-03-16 at 11:43 +0200, Kostik Belousov wrote: > On Sun, Mar 15, 2009 at 10:27:53PM -0500, Robert Noland wrote: > > On Sun, 2009-03-15 at 23:33 +0200, Kostik Belousov wrote: > > > On Sun, Mar 15, 2009 at 01:49:12PM -0500, Robert Noland wrote: > > > > I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago. > > > > > > > > The current xorg drivers will not enable it by default on R600+ chips. > > > > You will need to be using xf86-video-ati-6.12.0, > > > > xf86-video-radeonhd-devel or possibly even better git master of either. > > > > > > > > You will need to add the following to the Device section of your > > > > xorg.conf to enable it. If you are experiencing issues, commenting > > > > these two options out, will prevent Xorg from auto-loading the kernel > > > > module. > > > > > > > > Options "DRI" > > > > Options "AccelMethod" "EXA" > > > > > > With this code and ati 6.12.0, I get the awful performance. > > > Kernel says > > > drm0: on vgapci0 > > > vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xd002 > > > vgapci0: child drm0 requested pci_enable_busmaster > > > info: [drm] Initialized radeon 1.29.0 20080528 > > > vgapci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc000 > > > info: [drm] Setting GART location based on new memory map > > > error: [drm:pid1494:r600_do_init_cp] *ERROR* Need gart offset from > > > userspace > > > > Your card was agp right? > No, this is PCIe card. It is reported correctly as Radeon HD 2600 XT. > Motherboard chipset is Intel P43, if this makes any useful information. Ok, let me look over the code again and figure out how we get into this state. I may need more details, let me figure out what I need. robert. > > > > What happens if you force pci mode? > > > > Options "BusType" "PCI" > > > > robert. > > > > > Then, the Xorg.0.log > > > ... > > > (II) RADEON(0): [drm] register handle = 0xd002 > > > (II) RADEON(0): [dri] Visual configs initialized > > > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > > > (II) RADEON(0): MC_FB_LOCATION : 0x00df00c0 0x00df00c0 > > > (II) RADEON(0): MC_AGP_LOCATION : 0x003f > > > (==) RADEON(0): Backing store disabled > > > (II) RADEON(0): [DRI] installation complete > > > (II) RADEON(0): [drm] removed 1 reserved context for kernel > > > (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc731d000 at > > > 0x286fd000 > > > (II) RADEON(0): [drm] Closed DRM master. > > > (WW) RADEON(0): Direct rendering disabled > > > (EE) RADEON(0): Acceleration initialization failed > > > ... > > -- > > Robert Noland > > FreeBSD > > -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: Panic in radeon_get_vblank_counter()
On Sun, 15 Mar 2009, Robert Noland wrote: On Sun, 2009-03-15 at 14:27 +0100, Fabian Keil wrote: Robert Noland wrote: On Fri, 2009-03-13 at 23:33 -0500, Sean C. Farley wrote: On Fri, 13 Mar 2009, Robert Noland wrote: If I start rebooting before it is printed, the system locks up. Of course, this is only after rebooting several times. Here is a successful start and shutdown: http://people.freebsd.org/~scf/drm-dmesg.log http://people.freebsd.org/~scf/Xorg.0.log Ok, I'll spend some time staring at the current code... Thanks for the backtrace too, it's nice to get those... This seems to be the same panic I mentioned in the "Filesystems being eaten?" thread on freebsd-current. I reproducible got this panic on: FreeBSD 8.0-CURRENT #39: Sat Mar 7 20:37:29 CET 2009 when shutting Xorg down. I can no longer reproduce it with: FreeBSD 8.0-CURRENT #42: Sat Mar 14 00:47:09 CET 2009 Ok, everything from HEAD is merged... Give it a little while for the mirrors to catch up and give it a shot. I tried several times, and I was unable to get it to panic again. Thank you! Sean -- s...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
IPv6 gif(4) MTU: manpage vs src inconsistency?
Hi, it seems I have trouble to reach some websites using IPv6 through a gif tunnel. Most websites work, except for these two: www.freebsd.org www.kame.net I've searched for problems and it seems, I cannot send ping packets larger than 1232 from the host behind my router. That's why I wanted to decrease the MTU on gif from 1280 to 1240, as the manpage gif(4) suggests: "If the outer protocol is IPv6, path MTU discovery for encapsulated packets may affect communication over the interface. The first bigger-than- pmtu packet may be lost. To avoid the problem, you may want to set the interface MTU for gif to 1240 or smaller, when the outer header is IPv6 and the inner header is IPv4." And I tried it: # ifconfig gif0 mtu 1240 ifconfig: ioctl (set mtu): Invalid argument It does not work, because in source, you can find: if_gif.h: #define GIF_MTU (1280) /* Default MTU */ #define GIF_MTU_MIN (1280) /* Minimum MTU */ #define GIF_MTU_MAX (8192) /* Maximum MTU */ What now? One of the values is wrong, in my opinion. I still don't know the exact cause of the IPv6 website problems. Is there anyone who has a solution for this? I can access ALL WEBSITES from my router directly that has configured the gif tunnel. But all hosts that use the router for default route cannot access the two websites. I have also no issues with traffic to IRC server and so on. I've just found these two hosts that are "different" somehow. This is confusing. Router configuration: tun0: flags=8051 metric 0 mtu 1492 inet xx.xx.xx.xx --> yy.yy.yy.yy netmask 0x Opened by PID 433 gif0: flags=8051 metric 0 mtu 1280 tunnel inet xx.xx.xx.xx --> 192.88.99.1 inet6 2002::::1 prefixlen 64 Host behind the router that chokes on the two websites: re0: flags=8843 metric 0 mtu 1500 options=389b ether zz:zz:zz:zz:zz:zz inet6 fe80:::::%re0 prefixlen 64 scopeid 0x1 inet 192.168.0.12 netmask 0xff00 broadcast 192.168.0.255 inet6 fde2::::::: prefixlen 64 autoconf inet6 2002:::1:::: prefixlen 64 autoconf media: Ethernet autoselect (100baseTX ) status: active -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
GCC build causes panic: page already inserted
I saw that someone else had this happen last week... It is not a hardware failure. While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a core dump with the message vm_page_insert: page already inserted I build this port every week on a Toshiba laptop (1.8GHz Core 2 Duo, 1 GB RAM, 160 GB HD, plenty of free space, RELENG_7). I have never seen this until today. Just before building this port I completely built the kernel and world and installed them, so I am as up-to-date as you could be. I suspect recent changes to vm code... perhaps in /usr/src/sys/vm/ vm_meter.c or vm_page.c ? The compressed core dump is 41 MB. Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic in radeon_get_vblank_counter()
On Mon, 2009-03-16 at 12:40 -0500, Sean C. Farley wrote: > On Sun, 15 Mar 2009, Robert Noland wrote: > > > On Sun, 2009-03-15 at 14:27 +0100, Fabian Keil wrote: > >> Robert Noland wrote: > >>> On Fri, 2009-03-13 at 23:33 -0500, Sean C. Farley wrote: > On Fri, 13 Mar 2009, Robert Noland wrote: > >> > If I start rebooting before it is printed, the system locks up. Of > course, this is only after rebooting several times. > > Here is a successful start and shutdown: > http://people.freebsd.org/~scf/drm-dmesg.log > http://people.freebsd.org/~scf/Xorg.0.log > >>> > >>> Ok, I'll spend some time staring at the current code... Thanks for > >>> the backtrace too, it's nice to get those... > >> > >> This seems to be the same panic I mentioned in the > >> "Filesystems being eaten?" thread on freebsd-current. > >> > >> I reproducible got this panic on: > >> FreeBSD 8.0-CURRENT #39: Sat Mar 7 20:37:29 CET 2009 > >> when shutting Xorg down. I can no longer reproduce it with: > >> FreeBSD 8.0-CURRENT #42: Sat Mar 14 00:47:09 CET 2009 > > > > Ok, everything from HEAD is merged... Give it a little while for the > > mirrors to catch up and give it a shot. > > I tried several times, and I was unable to get it to panic again. Cool, glad it worked out. robert. > Thank you! > > Sean -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: GCC build causes panic: page already inserted
On Mon, Mar 16, 2009 at 12:59 PM, Dan Allen wrote: > I saw that someone else had this happen last week... It is not a hardware > failure. > I have not seen that. I have only seen an assertion failure that would have nothing to do with your reported panic. > > While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a core > dump with the message > >vm_page_insert: page already inserted > > I build this port every week on a Toshiba laptop (1.8GHz Core 2 Duo, 1 GB > RAM, 160 GB HD, plenty of free space, RELENG_7). I have never seen this > until today. Just before building this port I completely built the kernel > and world and installed them, so I am as up-to-date as you could be. > > I suspect recent changes to vm code... perhaps in > /usr/src/sys/vm/vm_meter.c or vm_page.c ? > > The compressed core dump is 41 MB. > For now, can you just provide the stack trace? Regards, Alan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.1 panic "vm_page_startup: inconsistent page counts"
Peter Jeremy wrote: On 2009-Mar-12 08:46:50 -0400, John Baldwin wrote: On Thursday 12 March 2009 12:36:46 am Peter Jeremy wrote: I'm trying to upgrade an 11 month old FreeBSD 7 image in a VMware 4.5.2 guest to an up-to-date -stable and it panics as above. I've added a printf to report the two counts and there's a difference of one page. I don't have any problems with the old 7-stable image or up-to-date 6-stable or -current using the same VMware version. A screendump for a verbose boot can be found at http://imagebin.ca/img/wahNNw.gif Can I safely delete the assert? I don't think so, I would report it to Alan. The one earlier report of this didn't include the detail that it was only off by one page. This is a bit moot now since you've disabled the test but rolling back to a kernel from 26th Feb (before the superpages MFC) doesn't have the page count discrepancy. It's useful to know that the older kernel doesn't fail the assertion. Thanks. Alan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Radeon r6/7xx support merged to -STABLE
On Mon, Mar 16, 2009 at 12:33:26PM -0500, Robert Noland wrote: > On Mon, 2009-03-16 at 11:43 +0200, Kostik Belousov wrote: > > On Sun, Mar 15, 2009 at 10:27:53PM -0500, Robert Noland wrote: > > > On Sun, 2009-03-15 at 23:33 +0200, Kostik Belousov wrote: > > > > On Sun, Mar 15, 2009 at 01:49:12PM -0500, Robert Noland wrote: > > > > > I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago. > > > > > > > > > > The current xorg drivers will not enable it by default on R600+ chips. > > > > > You will need to be using xf86-video-ati-6.12.0, > > > > > xf86-video-radeonhd-devel or possibly even better git master of > > > > > either. > > > > > > > > > > You will need to add the following to the Device section of your > > > > > xorg.conf to enable it. If you are experiencing issues, commenting > > > > > these two options out, will prevent Xorg from auto-loading the kernel > > > > > module. > > > > > > > > > > Options "DRI" > > > > > Options "AccelMethod" "EXA" > > > > > > > > With this code and ati 6.12.0, I get the awful performance. > > > > Kernel says > > > > drm0: on vgapci0 > > > > vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xd002 > > > > vgapci0: child drm0 requested pci_enable_busmaster > > > > info: [drm] Initialized radeon 1.29.0 20080528 > > > > vgapci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc000 > > > > info: [drm] Setting GART location based on new memory map > > > > error: [drm:pid1494:r600_do_init_cp] *ERROR* Need gart offset from > > > > userspace > > > > > > Your card was agp right? > > No, this is PCIe card. It is reported correctly as Radeon HD 2600 XT. > > Motherboard chipset is Intel P43, if this makes any useful information. > > Ok, let me look over the code again and figure out how we get into this > state. I may need more details, let me figure out what I need. > > robert. > > > > > > > What happens if you force pci mode? > > > > > > Options "BusType" "PCI" For the record. It appeared that I already had this option in the xorg.conf, and it was the cause of the problem. DRI works after removing this line. > > > > > > robert. > > > > > > > Then, the Xorg.0.log > > > > ... > > > > (II) RADEON(0): [drm] register handle = 0xd002 > > > > (II) RADEON(0): [dri] Visual configs initialized > > > > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > > > > (II) RADEON(0): MC_FB_LOCATION : 0x00df00c0 0x00df00c0 > > > > (II) RADEON(0): MC_AGP_LOCATION : 0x003f > > > > (==) RADEON(0): Backing store disabled > > > > (II) RADEON(0): [DRI] installation complete > > > > (II) RADEON(0): [drm] removed 1 reserved context for kernel > > > > (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc731d000 at > > > > 0x286fd000 > > > > (II) RADEON(0): [drm] Closed DRM master. > > > > (WW) RADEON(0): Direct rendering disabled > > > > (EE) RADEON(0): Acceleration initialization failed > > > > ... > > > -- > > > Robert Noland > > > FreeBSD > > > > > -- > Robert Noland > FreeBSD pgp1Gg6IhRzUt.pgp Description: PGP signature
Re: GCC build causes panic: page already inserted
On 16 Mar 2009, at 1:01 PM, Alan Cox wrote: For now, can you just provide the stack trace? How do I do this? Is there a tool that I run against the core dump? BTW, I just did the same gcc-4.4 build on my Mac and it built fine without any core dumps... Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GCC build causes panic: page already inserted
Le Mon, 16 Mar 2009 14:49:43 -0600, Dan Allen : > > For now, can you just provide the stack trace? > > How do I do this? Is there a tool that I run against the core dump? See http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GCC build causes panic: page already inserted
On 16 Mar 2009, at 3:42 PM, Patrick Lamaizière wrote: Le Mon, 16 Mar 2009 14:49:43 -0600, Dan Allen : For now, can you just provide the stack trace? How do I do this? Is there a tool that I run against the core dump? See http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Regards. Thanks! It turns out that one must have a debug kernel around. I use STABLE as a production system. There is no "kernel.debug" on my system. I guess I therefore cannot provide a stack trace. Sorry. Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Calling NUT users in America (and other 110V countries)
Does anyone have a 110V MGE Pulsar connected to NUT via RS232? The reason I am asking is that we ship systems overseas (from Australia land of 230V) and typically have the customer purchase a UPS (or arrange for one to be delivered to the site) and I find that I can't communicate with them using NUT. All of the MGE UPSs we have shipped from Australia work fine, and the hardware and software is identical to 110V sites (Super micro C2SBA, FreeBSD 6.3). I have talked to the NUT maintainers but they are primarily Linux oriented and haven't yet cranked up a FreeBSD box to have a look at it. The symptoms are that it can talk to the UPS but there are frequent drops in communication (very annoying as it fills the logs with crap), yet 230V units work flawlessly. I am not using USB because it was not reliable until very recently (and still reconnects alarmingly often..) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: GCC build causes panic: page already inserted
On 16 Mar 2009, at 1:01 PM, Alan Cox wrote: For now, can you just provide the stack trace? As I mentioned, I am unable to do so - I have no kernel.debug. However, I am trying to reproduce the bug again. (It takes a while.) Although it has not yet crashed, I noticed another unusual behavior: Normally during my gcc builds the 1 GB of swap space is never touched. My main 1 GB of RAM is sufficient and there is always at least 100 MB of free memory. Today I saw a STATE listed when running top that I have never seen, called "wdrain". This happened when I saw my free memory plummet down to only 20 MB free (out of 1 GB). This state appears to be set in / usr/src/sys/kern/vfs_bio.c in a routine called waitrunningbufspace(). This file also was modified March 1st. I do not know if there is a connection... The last time I built gcc-4.4 was probably just before this. (I build gcc whenever there is a new version, within a couple of days of it being added to ports. There was about two weeks with no new versions this first half of March so it has been a couple of weeks...) I am tempted to go back to about Feb 28th kernel-wise and try the gcc build again and see if it works or panics. Any suggestions as to how I can help narrow this down? Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
