Re: Network unavailable when booting directly to FreeBSD.
On Thu, Jun 21, 2012 at 02:05:33PM -0500, Pedro Giffuni wrote: Hello; I noticed a regression from 9.0 and I cannot boot directly FreeBSD and access the network. Unfortunately I cannot recall the exact commit where this started happening. uname -a FreeBSD pcbsd-8555 9.0-STABLE FreeBSD 9.0-STABLE #12: Wed May 30 11:16:35 PDT 2012 r...@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC amd64 From my dmesg __ ... pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pcib0: Length mismatch for 4 range: 81 vs 7f pci0: ACPI PCI bus on pcib0 pci0: memory, RAM at device 0.0 (no driver attached) pci0: memory, RAM at device 0.1 (no driver attached) pci0: memory, RAM at device 0.2 (no driver attached) pci0: memory, RAM at device 0.3 (no driver attached) pci0: memory, RAM at device 0.4 (no driver attached) pci0: memory, RAM at device 0.5 (no driver attached) pci0: memory, RAM at device 0.6 (no driver attached) pci0: memory, RAM at device 0.7 (no driver attached) pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 3.0 on pci0 pci2: ACPI PCI bus on pcib2 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x00b002 mem 0xfdef-0xfdef irq 16 at device 0.0 on pci2 bge0: CHIP ID 0xb002; ASIC REV 0x0b; CHIP REV 0xb0; PCI-E miibus0: MII bus on bge0 brgphy0: BCM5754/5787 1000BASE-T media interface PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:18:8b:76:a4:1e pcib3: ACPI PCI-PCI bridge at device 4.0 on pci0 pci3: ACPI PCI bus on pcib3 Cuse4BSD v0.1.23 @ /dev/cuse bge0: watchdog timeout -- resetting bge0: watchdog timeout -- resetting WARNING: attempt to domain_add(bluetooth) after domainfinalize() fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP _ Iff I boot Windows first and then reboot to start FreeBSD the network works fine. This looks strange and I can't narrow down what other changes made since 9.0-RELEASE broke the driver. Would you try reverting r235821? If that does not solve the issue, would you try a WIP version at the following URL? It's mainly written to improve BCM5720 with APE firmware support and it exactly follows recommendations suggested by Broadcom so it may have some differences. http://people.freebsd.org/~yongari/bge/if_bge.c http://people.freebsd.org/~yongari/bge/if_bgereg.h http://people.freebsd.org/~yongari/bge/brgphy.c Pedro. ___ 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: fsck_ufs running too often
Next time you'll see fsck, you should t least run ps axd (to see it's parent and to try guess what was that). -- Regards, Alexander Yerenkow ___ 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: fsck_ufs running too often
On 23/06/2012, at 7:47 AM, Leonardo M. Ramé wrote: Hi, since a few of days ago, I noticed my home server turns very slow more than once a day, so every time I run top to see what's processes are running, I can see fsck_ufs at the very top, and the hard drive working like mad. I've checked my crontab and there's nothing related to fsck_ufs, where can I start searching for the cause of the problem?, I thought this process should run only at boot or shutdown, but this time it is running -apparently- without a cause. Background fsck. Your server crashed, rebooted, started up and fsck is running in the background while everything else continues. Ways to avoid background fsck: * Disable it completely in /etc/rc.conf: background_fsck=NO. Then fsck finishes completely before the OS continues booting, so there may be extended delays if a crash occurs. * Use gjournal so fsck doesn't need to churn over the disks * Turn on softupdates-journaling for a similar effect. The more important thing is to find out why it crashed - if there was a power outage, hardware or software issue. uname -a: FreeBSD server.my.local 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Regards, Leonardo M. Ramé http://leonardorame.blogspot.com ___ 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 ___ 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: KMS on Sandy bridge error device_attach
On Sat, Jun 23, 2012 at 09:25:40AM +0200, Thomas Zander wrote: On Fri, Jun 22, 2012 at 8:38 PM, Konstantin Belousov kostik...@gmail.com wrote: Thank you for your quick response. Output is attached. This is probably one of the relatively rarely sold CPUs, so I might have an edge case here... Yes, indeed, this is something Intel calls 'SandyBridge server Integrated Graphics'. The device id is known to agp driver, but probably it failed to attach due to some (mis)interpretation of the state. Your dmesg is not complete, the hda output displaced the previous messages which contained the agp attach diagnostic. Take agp or hda out from kernel, and rerun the test. Or, increase MSGBUF_SIZE, see conf/NOTES for description. Okay, thanks again. As you suggested, I have removed a few kernel modules from the boot process and it seems that the verbose dmesg output now fits into the buffer, see attached dmesg output. However I don't see more GPU attach diagnostic. Do I miss something? Ok, but you did not tried to load i915kms, at least the dmesg you posted lacks an indication. Let me repeat: I need to see the lines related to the agp probe and attachment, I believe that it will show us the next direction to investigate. pgphMGOfie5e6.pgp Description: PGP signature
Re: Xorg in swwrt
On 2011-Feb-06 15:19:12 +1030, Daniel O'Connor dar...@dons.net.au wrote: I updated ports (portmaster -a basically) on this 8.2-PRE box and now I find X takes a long, long time to start up and uses lots of CPU. It shows the wchan as swwrt. FWIW, I've run into this a couple of times recently when logging out of X. This is with X.Org X Server 1.10.6 and a ATI Radeon HD 2400 Pro on 8-STABLE r235229. The problem seems to go away after a couple of hours. -- Peter Jeremy pgpiZRKfLAQrH.pgp Description: PGP signature
Re: KMS on Sandy bridge error device_attach
On Sat, Jun 23, 2012 at 10:59 AM, Konstantin Belousov kostik...@gmail.com wrote: Ok, but you did not tried to load i915kms, at least the dmesg you posted lacks an indication. Actually, it did. i915kms was in loader.conf. dmesg, line 37f: Preloaded elf obj module /boot/kernel/i915kms.ko at 0x8113a820. Preloaded elf obj module /boot/kernel/drm2.ko at 0x8113ae88. ... dmesg, lines 482-489: vgapci0: VGA-compatible display port 0xf000-0xf03f mem 0xfb40-0xfb7f,0xd000-0xdfff irq 16 at device 2.0 on pci0 drmn0: Intel SandyBridge (M) on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 vgapci0: using IRQ 264 for MSI info: [drm] MSI enabled 1 message(s) error: [drm:pid0:drm_load] *ERROR* Card isn't AGP, or couldn't initialize AGP. device_attach: drmn0 attach returned 12 Let me repeat: I need to see the lines related to the agp probe and attachment, I believe that it will show us the next direction to investigate. I did understand what you were after, but sorry, there is nothing more in the dmesg output. Do I need to perform additional steps besides verbose boot to obtain this data? Best regards Riggs ___ 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: KMS on Sandy bridge error device_attach
On Sat, Jun 23, 2012 at 01:38:35PM +0200, Thomas Zander wrote:
On Sat, Jun 23, 2012 at 10:59 AM, Konstantin Belousov
kostik...@gmail.com wrote:
Ok, but you did not tried to load i915kms, at least the dmesg you posted
lacks an indication.
Actually, it did. i915kms was in loader.conf.
dmesg, line 37f:
Preloaded elf obj module /boot/kernel/i915kms.ko at 0x8113a820.
Preloaded elf obj module /boot/kernel/drm2.ko at 0x8113ae88.
...
dmesg, lines 482-489:
vgapci0: VGA-compatible display port 0xf000-0xf03f mem
0xfb40-0xfb7f,0xd000-0xdfff irq 16 at device 2.0 on
pci0
drmn0: Intel SandyBridge (M) on vgapci0
vgapci0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 264 to local APIC 0 vector 59
vgapci0: using IRQ 264 for MSI
info: [drm] MSI enabled 1 message(s)
error: [drm:pid0:drm_load] *ERROR* Card isn't AGP, or couldn't initialize AGP.
device_attach: drmn0 attach returned 12
Do you have agp.ko loaded from loader.conf ? If not, what happens
if you add it there ?
The i915kms does have a dependency on agp, so it should have been
auto-loaded if not loaded explicitely. And agp should be probed at
least.
Loading i915kms from loader.conf is something I do not encourage
right now, since you loose VGA console somewhere during the kernel
startup.
Let me repeat: I need to see the lines related to the agp probe and
attachment, I believe that it will show us the next direction to
investigate.
I did understand what you were after, but sorry, there is nothing more
in the dmesg output. Do I need to perform additional steps besides
verbose boot to obtain this data?
Hmm, I probably see an issue. Please try the patch below.
diff --git a/sys/dev/agp/agp_i810.c b/sys/dev/agp/agp_i810.c
index a181ad7..c0f592c 100644
--- a/sys/dev/agp/agp_i810.c
+++ b/sys/dev/agp/agp_i810.c
@@ -700,7 +700,7 @@ static const struct agp_i810_match {
.driver = agp_i810_sb_driver
},
{
- .devid = 0x01088086,
+ .devid = 0x010a8086,
.name = SandyBridge server IG,
.driver = agp_i810_sb_driver
},
pgpq164jYhyOl.pgp
Description: PGP signature
Re: KMS on Sandy bridge error device_attach
On Sat, Jun 23, 2012 at 2:08 PM, Konstantin Belousov
kostik...@gmail.com wrote:
Hmm, I probably see an issue. Please try the patch below.
diff --git a/sys/dev/agp/agp_i810.c b/sys/dev/agp/agp_i810.c
index a181ad7..c0f592c 100644
--- a/sys/dev/agp/agp_i810.c
+++ b/sys/dev/agp/agp_i810.c
@@ -700,7 +700,7 @@ static const struct agp_i810_match {
.driver = agp_i810_sb_driver
},
{
- .devid = 0x01088086,
+ .devid = 0x010a8086,
.name = SandyBridge server IG,
.driver = agp_i810_sb_driver
},
I believe you were right with the device ID.
agp attaches now with these messages:
agp0: SandyBridge server IG on vgapci0
agp0: aperture size is 256M, detected 65532k stolen memory
After applying the patch, when kldload'ing i915drm, there is quite
some dmesg output (attached).
I am going to build xorg and let you know whether it works. Thanks
again for your help so far!
Best,
Riggs
drmn0: Intel SandyBridge (M) on vgapci0
info: [drm] MSI enabled 1 message(s)
info: [drm] AGP at 0xd000 256MB
iicbus0: Philips I2C bus on iicbb0 addr 0xff
iic0: I2C generic I/O on iicbus0
iic1: I2C generic I/O on iicbus1
iicbus2: Philips I2C bus on iicbb1 addr 0xff
iic2: I2C generic I/O on iicbus2
iic3: I2C generic I/O on iicbus3
iicbus4: Philips I2C bus on iicbb2 addr 0xff
iic4: I2C generic I/O on iicbus4
iic5: I2C generic I/O on iicbus5
iicbus6: Philips I2C bus on iicbb3 addr 0xff
iic6: I2C generic I/O on iicbus6
iic7: I2C generic I/O on iicbus7
iicbus8: Philips I2C bus on iicbb4 addr 0xff
iic8: I2C generic I/O on iicbus8
iic9: I2C generic I/O on iicbus9
iicbus10: Philips I2C bus on iicbb5 addr 0xff
iic10: I2C generic I/O on iicbus10
iic11: I2C generic I/O on iicbus11
iicbus12: Philips I2C bus on iicbb6 addr 0xff
iic12: I2C generic I/O on iicbus12
iic13: I2C generic I/O on iicbus13
iicbus14: Philips I2C bus on iicbb7 addr 0xff
iic14: I2C generic I/O on iicbus14
iic15: I2C generic I/O on iicbus15
info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
[drm:KMS:pid1349:intel_detect_pch] Found CougarPoint PCH
[drm:KMS:pid1349:init_vbt_defaults] Set default to SSC at 100MHz
[drm:KMS:pid1349:intel_parse_bios] Using VBT from OpRegion: $VBT
SNB/IVB-DESKTOPd
[drm:KMS:pid1349:parse_general_features] BDB_GENERAL_FEATURES int_tv_support 0
int_crt_support 1 lvds_use_ssc 0 lvds_ssc_freq 120 display_clock_mode 0
[drm:KMS:pid1349:parse_general_definitions] crt_ddc_bus_pin: 2
[drm:KMS:pid1349:parse_lfp_panel_data] Found panel mode in BIOS VBT tables:
[drm:KMS:pid1349:drm_mode_debug_printmodeline] Modeline 0:1024x768 0 65000
1024 1048 1184 1344 768 771 777 806 0x8 0xa
[drm:KMS:pid1349:parse_sdvo_panel_data] Found SDVO panel mode in BIOS VBT
tables:
[drm:KMS:pid1349:drm_mode_debug_printmodeline] Modeline 0:1600x1200 0 162000
1600 1664 1856 2160 1200 1201 1204 1250 0x8 0xa
[drm:KMS:pid1349:parse_sdvo_device_mapping] No SDVO device info is found in VBT
[drm:KMS:pid1349:intel_modeset_init] 2 display pipes available.
[drm:KMS:pid1349:intel_lvds_init] LVDS is not present in VBT
[drm:KMS:pid1349:intel_crt_init] pch crt adpa set to 0xf4
[drm:KMS:pid1349:intel_setup_outputs] HDMIB 1 PCH_DP_B 1 HDMIC 0 HDMID 0
PCH_DP_C 0 PCH_DP_D 0 LVDS 0
[drm:KMS:pid1349:intel_sdvo_read_byte] i2c transfer returned 2
[drm:KMS:pid1349:intel_sdvo_init] No SDVO device found on SDVOB
[drm:KMS:pid1349:intel_dp_i2c_init] i2c_init DPDDC-B
[drm:KMS:pid1349:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f
[drm:KMS:pid1349:intel_dp_i2c_aux_ch] aux_ch failed -60
[drm:KMS:pid1349:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f
[drm:KMS:pid1349:intel_dp_i2c_aux_ch] aux_ch failed -60
[drm:KMS:pid1349:ironlake_crtc_dpms] crtc 0/0 dpms off
[drm:KMS:pid1349:intel_wait_for_vblank] vblank wait timed out
[drm:KMS:pid1349:intel_update_fbc]
[drm:KMS:pid1349:ironlake_crtc_dpms] crtc 1/1 dpms off
[drm:KMS:pid1349:intel_update_fbc]
[drm:KMS:pid1349:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_pch_edp 0
has_cpu_edp 0 has_ck505 0
[drm:KMS:pid1349:ironlake_init_pch_refclk] Disabling SSC entirely
info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off
drmn0: taking over the fictitious range 0xd000-0xe000
[drm:KMS:pid1349:drm_helper_probe_single_connector_modes] [CONNECTOR:7:VGA-1]
[drm:KMS:pid1349:intel_ironlake_crt_detect_hotplug] trigger hotplug detect
cycle: adpa=0xf4
[drm:KMS:pid1349:intel_ironlake_crt_detect_hotplug] ironlake hotplug
adpa=0xf4, result 0
[drm:KMS:pid1349:intel_crt_detect] CRT not detected via hotplug
[drm:KMS:pid1349:drm_helper_probe_single_connector_modes] [CONNECTOR:7:VGA-1]
disconnected
[drm:KMS:pid1349:drm_helper_probe_single_connector_modes]
[CONNECTOR:10:HDMI-A-1]
[drm:KMS:pid1349:drm_edid_to_eld] ELD: no CEA Extension found
[drm:KMS:pid1349:drm_helper_probe_single_connector_modes]
[CONNECTOR:10:HDMI-A-1] probed modes :
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 3:44 PM, Devin Teske wrote: On Jun 22, 2012, at 3:32 PM, Devin Teske wrote: On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote: When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. This was on-purpose because there is a discrepancy in passwd(5) manual regarding what a value of zero (0) means for these fields. From passwd(5): The change field is the number of seconds from the epoch, UTC, until the password for the account must be changed. This field may be left empty to turn off the password aging feature. Nowhere in the manual does it say that zero is a synonym to being left empty. And yet, this is how the system treats zero (was my complaint). The user root (and toor, and several other system users) come with a default value of zero for this field. If zero was treated according to the manual, then root would be disabled by default. But that's clearly not the case in a default installation which has a value of zero. So, when you're using bsdconfig to view an existing user that has a value of zero, you will notice that the default calendar date/time that is chosen corresponds to zero seconds from the epoch, UTC, despite the fact that I know (and you know) that zero is synonymous with NULL. So I'm a fan of updating the man page and when that is done, I am happy to change bsdconfig to treat zero as-such. But right now I wanted to stay true to the manual (which plainly states that any non-NULL value is treated as seconds from the epoch). In an effort to get the passwd(5) manual updated (pre-requisite to fixing the bsdconfig(8) functionality to coincide with the manual change), I've filed PR ports/169354. http://www.FreeBSD.org/cgi/query-pr.cgi?pr=169354 -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: STABLE/9 SMP ACPI suspend/resume - video mode not being restored
Hi, FWIW, Xorg suspend/resume via the switch to VTY before suspending hack works on this Thinkpad T60. It's not optimal but hey, it _does_ work. :) Your T60 has a Radeon graphic adapter, right? Could you try the radeon suspend/resume patch and kldload radeon.ko before suspending? http://people.freebsd.org/~iwasaki/acpi/drm-radeon_suspend-20120623.diff Thanks Hi, No, I didn't have vesa loaded. I'll load that now and try tomorrow after a reboot. Yes, I tried switching VTYs, each VTY had the same issue. I guess the driver isn't doing a VGA mode change when I switch VTYs unless the screens are in different modes? FWIW, Xorg suspend/resume via the switch to VTY before suspending hack works on this Thinkpad T60. It's not optimal but hey, it _does_ work. :) Adrian ___ 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: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote: 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). I've made the necessary changes to support vlan0-vlan9 (though the system will only support up to vlan65534). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. I do not know what sysctl subtree do you refer to. If you're using em(4) device, try: sysctl dev.em.0.%desc Otherwise (for example), if using fxp(4), try: sysctl dev.fxp.0.%desc Or for your vlan: sysctl dev.vlan.16.%desc And try for your ipfw(4) interface: sysctl dev.ipfw.0.%desc Are each of those meaningful? NOTE: They aren't available unless you have the hardware -- so I can't (for example) try sysctl dev.fxp.0.%desc unless I have an fxp0 device displayed in ifconfig(8). That's driver-dependent. For example, lagg does not presents %desc nor ipfw0 and I suppose pretty many others do not. You could use %desc if it's present and fall back to internal static list otherwise. Ok, I've added that functionality, but … since neither lagg(4) nor ipfw(4) provide %desc MIB, … what should we provide as static fallbacks? Just something cosmetic but when I add a user when it comes to select the shell it does not have a title like: Select a shell I fixed this too. Also it said that my user add failed but it was actually added as uid 1005. I'm working on this one. I'm changing the routines to allow the UNIX pw(8) errors to filter through, rather than masking them with a static error on non-success. I added another user and it stated the uid 1005 when I was creating it but showed 1006 in the summary screen. It also said that adding the user failed. pw usernext is executed to get the next uid/gid pair that is available. It's possible a user was added in the process. I've not witnessed this, but will try to replicate. Perhaps I used to short a password as there was no password field entered in /etc/master.passwd twat:*:1005:1005::1340540161:1340626570:twat:/home/twat:/bin/sh test1:*:1006:1006::1340454020:1340496000:test1:/home/test1:/bin/tcsh The password is only set (as a separate command) if the pw(8) useradd succeeded. I'm working on catching errors in edge-cases where we should proceed despite non-success. When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. I filed PR docs/169354 against the passwd(5) manual. If nobody picks up the PR in a timely fashion, I'll pro-actively modify bsdconfig to follow what the man-page _should_ say versus what it _does_ say about how to treat the value of zero (the default). -- Thanks for testing!, Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: Network unavailable when booting directly to FreeBSD.
Hello; --- Sab 23/6/12, YongHyeon PYUN pyu...@gmail.com ha scritto: ... amd64 From my dmesg __ ... pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pcib0: Length mismatch for 4 range: 81 vs 7f pci0: ACPI PCI bus on pcib0 pci0: memory, RAM at device 0.0 (no driver attached) pci0: memory, RAM at device 0.1 (no driver attached) pci0: memory, RAM at device 0.2 (no driver attached) pci0: memory, RAM at device 0.3 (no driver attached) pci0: memory, RAM at device 0.4 (no driver attached) pci0: memory, RAM at device 0.5 (no driver attached) pci0: memory, RAM at device 0.6 (no driver attached) pci0: memory, RAM at device 0.7 (no driver attached) pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 3.0 on pci0 pci2: ACPI PCI bus on pcib2 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x00b002 mem 0xfdef-0xfdef irq 16 at device 0.0 on pci2 bge0: CHIP ID 0xb002; ASIC REV 0x0b; CHIP REV 0xb0; PCI-E miibus0: MII bus on bge0 brgphy0: BCM5754/5787 1000BASE-T media interface PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:18:8b:76:a4:1e pcib3: ACPI PCI-PCI bridge at device 4.0 on pci0 pci3: ACPI PCI bus on pcib3 Cuse4BSD v0.1.23 @ /dev/cuse bge0: watchdog timeout -- resetting bge0: watchdog timeout -- resetting WARNING: attempt to domain_add(bluetooth) after domainfinalize() fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP _ Iff I boot Windows first and then reboot to start FreeBSD the network works fine. This looks strange and I can't narrow down what other changes made since 9.0-RELEASE broke the driver. Would you try reverting r235821? I reverted it manually but things didn't change. If that does not solve the issue, would you try a WIP version at the following URL? It's mainly written to improve BCM5720 with APE firmware support and it exactly follows recommendations suggested by Broadcom so it may have some differences. http://people.freebsd.org/~yongari/bge/if_bge.c http://people.freebsd.org/~yongari/bge/if_bgereg.h http://people.freebsd.org/~yongari/bge/brgphy.c No joy either :( Pedro. ___ 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: fsck_ufs running too often
On Sat, Jun 23, 2012 at 06:23:58PM +1000, Sean wrote: On 23/06/2012, at 7:47 AM, Leonardo M. Ram? wrote: Hi, since a few of days ago, I noticed my home server turns very slow more than once a day, so every time I run top to see what's processes are running, I can see fsck_ufs at the very top, and the hard drive working like mad. I've checked my crontab and there's nothing related to fsck_ufs, where can I start searching for the cause of the problem?, I thought this process should run only at boot or shutdown, but this time it is running -apparently- without a cause. Background fsck. Your server crashed, rebooted, started up and fsck is running in the background while everything else continues. [...] The more important thing is to find out why it crashed - if there was a power outage, hardware or software issue. Another thing to do is look in the logs to see if background fsck is failing for some reason. I've seen it happen in some cases that background fsck fails and asks for a manual run, in which case the filesystem remains dirty, and further reboots will continue to fail until a manual fsck is run. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL - Portland, OR USA ___ 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: fsck_ufs running too often
On Sat, Jun 23, 2012 at 06:36:24PM -0700, Greg Byshenk wrote: On Sat, Jun 23, 2012 at 06:23:58PM +1000, Sean wrote: On 23/06/2012, at 7:47 AM, Leonardo M. Ram? wrote: Hi, since a few of days ago, I noticed my home server turns very slow more than once a day, so every time I run top to see what's processes are running, I can see fsck_ufs at the very top, and the hard drive working like mad. I've checked my crontab and there's nothing related to fsck_ufs, where can I start searching for the cause of the problem?, I thought this process should run only at boot or shutdown, but this time it is running -apparently- without a cause. Background fsck. Your server crashed, rebooted, started up and fsck is running in the background while everything else continues. [...] The more important thing is to find out why it crashed - if there was a power outage, hardware or software issue. Another thing to do is look in the logs to see if background fsck is failing for some reason. I've seen it happen in some cases that background fsck fails and asks for a manual run, in which case the filesystem remains dirty, and further reboots will continue to fail until a manual fsck is run. At one point it was proven that background fsck was not benefitial. I am not sure what ever came out of that but it was advised to turn it off. I usually go with these to aid in something useful for things I do not really care about. You might consider to/not use fsck_y_enable but they help. fsck_y_enable=YES background_fsck=NO -- - (2^(N-1)) pgpxCyZ4jPFaI.pgp Description: PGP signature
Re: fsck_ufs running too often
On Sat, Jun 23, 2012 at 9:54 PM, Jason Hellenthal jhellent...@dataix.netwrote: At one point it was proven that background fsck was not benefitial. Where can we find this proof? -- Adam Vande More ___ 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: Xorg in swwrt
On 23/06/2012, at 19:02, Peter Jeremy wrote: On 2011-Feb-06 15:19:12 +1030, Daniel O'Connor dar...@dons.net.au wrote: I updated ports (portmaster -a basically) on this 8.2-PRE box and now I find X takes a long, long time to start up and uses lots of CPU. It shows the wchan as swwrt. FWIW, I've run into this a couple of times recently when logging out of X. This is with X.Org X Server 1.10.6 and a ATI Radeon HD 2400 Pro on 8-STABLE r235229. The problem seems to go away after a couple of hours. I think it's a memory fragmentation issue but I am only really guessing. Certainly after putting more RAM in the system in question the problem happened less frequently. -- 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 ___ 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
