Re: Re: drm i915kms on 12.1-STABLE (r363237)
On Sat, 8 Aug 2020 at 16:06, Nils Johannsen wrote: > after discussion with Niclas and I explained him that 12.1-RELEASE works but > 12-STABLE not, he mentioned to build and install "drm-fbsd12.0-kmod" from > ports, but also "gpu-firmware-kmod" from ports (instead of prebuild pkg), > what fixed the issue in my case. Now startx and i3 works fine. Yeah, I got the point, thx. I just happened to observe the same issue with the in-tree-abandonware driver. That means we can either fix it or say "now it's really deprecated" and remove it. Riggs ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: drm i915kms on 12.1-STABLE (r363237)
On Tue, 21 Jul 2020 at 12:53, Niclas Zeising wrote: > On 2020-07-17 11:49, Nils Johannsen wrote: > > > yesterday I installed 12.1-STABLE [1] with kernel version `uname -K` > > 1201519 on my ThinkPad E490 with 'Intel UHD Graphics 620' [2]. > > But if I install the 'drm-fbsd12.0-kmod' and load the driver `kldload > > /boot/modules/i915kms.ko` it will only show a black screen until I manually > > poweroff the notebook. > > See the `/var/log/messages` [3] below. The 'drm-fbsd12.0-kmod' from pkg [4] > > behaves the sames as if I build it manually from ports. On 12.1-RELEASE it > > worked just fine. > > You need to upgrade to 13-CURRENT and use drm-devel-kmod. I don't think this is the root cause. I am seeing the exact same issue after upgrading a Sandy Bridge machine with on-chip-GPU to a recent -STABLE. Worked perfectly fine before with the abandonware-i915kms in base as well as with drm-legacy-kmod. Now both are showing a mere black screen, just like Nils reported. Maybe the recent MFCs of linuxkpi stuff broke something. I'll build some kernels and modules and see if I find the issue. Meanwhile, if it's been discovered (and fixed) already, let me know. Riggs ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: State of encrypted-almost-everything on ZFS in 2020
Hi, thank you for the quick response. I think I have a good overview of the state of affairs now, thanks! On Sat, 16 May 2020 at 18:46, Allan Jude wrote: > > - Encrypted ZFS root pool on RAID-Z > > Yes, this has been supported in a few varieties for a few major versions now ... and it's a cool feature, no doubt! Unfortunately, it requires me to supply a password via keyboard, as you explain below, so it does not match my use case. > > - Supply the key for the encrypted root pool during boot via USB thumb drive > > - No keyboard is attached to the machine > > - No /boot on the thumb drive, just the key > > This feature was never implemented for GELIBoot. Currently the bootstrap > code only supports a manually entered passphrase. Thanks for clarifying this! > > - I don't mind if /boot is encrypted or not (the use case is not to > > protect against nation state attackers) > > If you use an unencrypted /boot (as opposed to GELIBoot), then I think > you might be able to use the thumb drive approach to hold the key. You > would need to set the correct loader.conf variables to read the key from > the thumbdrive. It might be easier if the key is written raw into a > partition than if it is on a filesystem since it won't be mounted at > that point. Okay, that sounds like not all hope is lost :-) So, something like this might work IIUC: - Have a small (e.g. 16kB) GPT partition on the USB thumb drive, using geom_label, accessible as /dev/label/foo - dd the key onto /dev/label/foo - Have this in loader.conf: geli_label_crypted_keyfile0_load="YES" geli_label_crypted_keyfile0_type="label/crypted:geli_keyfile0" geli_label_crypted_keyfile0_name="/dev/label/foo" > > - Bonus points if I can use bectl > > However, if you use an unencrypted /boot, then you lose bectl and boot > environments, since the kernel is not part of the root filesystem. That's okay, having. bectl would be nice, but secondary. > > I'd like to have a setup where essentially nothing is stored on the > > USB drive except the keyfile. > > I proposed some ideas on how to do this at BSDCan a few years ago, but > have never had the time or financial backing to develop the feature. I am sorry to hear that. One would expect this was not an unconventional use case. Thanks so much for the response, I'll play with the raw partition idea over the next few days and will report back how it went. Best regards Riggs ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
State of encrypted-almost-everything on ZFS in 2020
Hi, can the following be done these days? - Encrypted ZFS root pool on RAID-Z - Supply the key for the encrypted root pool during boot via USB thumb drive - No keyboard is attached to the machine - No /boot on the thumb drive, just the key - I don't mind if /boot is encrypted or not (the use case is not to protect against nation state attackers) - Bonus points if I can use bectl Every single posting regarding this topic I can find always comes down to either a) One needs /boot on the thumb drive, or b) One uses a keyboard and supplies a passphrase instead of a keyfile. I'd like to have a setup where essentially nothing is stored on the USB drive except the keyfile. Thank you and best regards Riggs ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Is ATH_ENABLE_11N supposed to work on 9-stable?
Hi, from the mailing lists I couldn't figure out whether 11n is supposed to work on stable since the existing mail threads seem to focus on current exclusively. And since the option exists in the stable kernel code as well, albeit neither in GENERIC nor in NOTES, I thought I could give it a try anyway. I had some partial success. Test in station mode, WPA2 associated properly, light traffic (browsing the web) seems to work okay as well. However as soon as I try to really push some data through it, e.g. rsync large files, the card drops all network traffic until I disassociate and re-associate with the access point again (e.g. netif restart). If 11N is just not ready in -stable yet, it's not a problem, but if it's supposed to work, I'd begin to collect debugging information. So, is it supposed to work on a 9-stable as of today? 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: Is ATH_ENABLE_11N supposed to work on 9-stable?
On 14 July 2013 18:41, Adrian Chadd adr...@freebsd.org wrote: Nope. It's a -10 thing. Okay, thanks for clarifying. 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 5:07 PM, Thomas Zander thomas.e.zan...@googlemail.com wrote: 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! After rebuilding xorg and some other ports I have news: It works absolutely fine so far! Acceleration, shadows, compositing, everything I have tried so far works perfectly. I can't thank you enough for your work on this topic and your help in locating my particular issue. After using the vesa driver for some time, accelerated X feels great again :-) 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 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 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 :
KMS on Sandy bridge error device_attach
Hi, I just updated my world to try kms which has recently been merged into stable. However I get this when kldload'ing i915kms: drmn0: Intel SandyBridge (M) on vgapci0 info: [drm] MSI enabled 1 message(s) error: [drm:pid1295:drm_load] *ERROR* Card isn't AGP, or couldn't initialize AGP. device_attach: drmn0 attach returned 12 CPU is this model: CPU: Intel(R) Xeon(R) CPU E31260L @ 2.40GHz (2400.07-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Is this model supposed to work with the current code? 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
Sandy Bridge and MCA UNCOR PCC (problem + solution)
List, here's a rant about a recent problem I had and the surprising solution. I recently had to investigate weird unexpected issues on a workstation. Relevant hardware: Asus P8B-WS, Xeon E3-1260L (Sandy Bride, Intel HD-2000 graphics) Since we don't have kms and friends in STABLE yet, and I can live without accelerated video for now, I am using the vesa driver on this machine. Initially, this had two major drawbacks: 1) 1280x1024 resolution utterly sucks on a 1680x1050 screen. 2) Reproducable unhandled MCA events (and subsequent kernel panics) like the following whenever I switch from X to console: panic: machine check trap ... MCA: CPU 6 UNCOR UNCOR UNCOR PCC PCC PCC internal error 2internal error 2PCC internal error 2 The kernel dump _always_ showed something like: current process = 11 (idle: cpu3) trap number = 28 #1 0x805db167 at panic+0x187 #2 0x808c6820 at trap_fatal+0x290 #3 0x808c6d3a at trap+0x10a #4 0x808ae894 at calltrap+0x8 #5 0x801f6b9a at acpi_cpu_idle+0x20a #6 0x806003af at sched_idletd+0x11f #7 0x805afe6f at fork_exit+0x11f #8 0x808aedde at fork_trampoline+0xe mcelog did not help decoding the MCA output and the internal error2 message made me suspect that this CPU was maybe just broken. However, due to my utter inabilty of producing the slightest other problem with this machine (constantly heavy CPU + IO load) or any problem using other operating systems I derived the wild speculation that there might be something with the Sandy Bridge silicon which this exact sequence of actions on FreeBSD reliably could trigger. Long story short: I got the latest Bios from Asus for this Board. The changelog of course said absolutely nothing about fixing any known problem. Upon boot I entered the Bios settings and noticed that it apparently contained a microcode update. The changelog for microcode from Intel is of course non-existing. And since this boot there has not been a single problem with this machine. Vesa now works in 1680x1050 and switching from X to console and back does not trigger MCA events anymore. I like to believe that for the first time a microcode update from Intel fixed my specific problem. Anyway, now the story is on the list and for Google to find, in case anyone else has this problem as well. Best regards Riggs -- - Now the world has gone to bed | Now I lay me down to sleep- -- Darkness won't engulf my head | Try to count electric sheep -- --- I can see by infra-red | Sweet dream wishes you can keep --- How I hate the night| How I hate the night ___ 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: Interpreting MCA error output
On Tue, Oct 18, 2011 at 09:19, Jeremy Chadwick free...@jdc.parodius.com wrote: That would be absolutely helpful! After all, FreeBSD is primarily a server OS, and where would one have ECC if not on servers. Being able to determine what's wrong with memory would be certainly very valuable for many admins. This has been done, and it was committed a couple days ago as sysutils/mcelog. There are a couple thing about the port which bother me[1], and there is one warning which can be safely ignored (I'm a strong advocate of -Werror) but I do have a fix for that, but otherwise it's functional. Awesome! Thanks, I will install and wait for the next mce to happen! 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: Interpreting MCA error output
Hello Jeremy, first, thank you for the extensive explanation. It cleared some things up for me. I do have some rambling to add, though :-) On Sat, Oct 1, 2011 at 12:23, Jeremy Chadwick free...@jdc.parodius.com wrote: So what should you do? Replace the RAM. Which DIMM? Sadly I don't know how to determine that. Some system BIOSes (particularly on AMD systems I've used) let you do memory tests (similar to memtest86) within the BIOS which can then tell you which DIMM slot experienced a problem. If yours doesn't have that, I would have to say purchase all new RAM (yes, all of it) and test the individual DIMMs later so you can determine which is bad. Well, I wasn't too surprised by the panic. I have read somewhere that in these situations the kernel might simply panic since the system might be in a compromised state. So far so ... well ... acceptable. My question here is how can I be certain right now if any of the DIMMs has gone bad. You mentioned problems you have all the time with DIMMs due to bad cooling in data centers. My machine in question is not located in a data center, that was my home server that tends to have very little load. But being located in my apartment, there are lots of _potential_ problems, including stability of power. In fact this was the first MCA event with these DIMMs ever, in more than a year. But of course you could be right. A DIMM could be rotten. Absolutely. Regarding your suggestion to do memory tests: My BIOS does not support testing, so I booted up memtest86+ after reading your e-mail and let it run for almost a whole day now. It did not encounter a single problem. So, even if I bought new DIMMs at once, it might take weeks to figure out which DIMM is rotten, if at all. Assuming that MCA events stay this infrequent, that is. Of course I'll observe the machine closely, but if the rate stays at one MCA event per year, it'll take some time to figure out the broken DIMM :-) I should really work with John to make mcelog a FreeBSD port and just regularly update it with patches, etc. to work on FreeBSD. DMI support and so on I don't think can be added (at least not by me), but simple ASCII decoding? Very possible. That would be absolutely helpful! After all, FreeBSD is primarily a server OS, and where would one have ECC if not on servers. Being able to determine what's wrong with memory would be certainly very valuable for many admins. An alternative would be for me to make a CGI version where you could just go my site and paste in the FreeBSD MCE and it would siphon it through mcelog and give you the output. I could live with that, too :-) Thanks again for your extensive explanation, I appreciate it very much! Now I am going to watch that machine closely... 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
Interpreting MCA error output
Good morning, just spotted this MCA event (and subsequently kernel panic): Oct 1 10:43:42 marvin kernel: MCA: Bank 4, Status 0xf41b210030080a13 Oct 1 10:43:42 marvin kernel: MCA: Global Cap 0x0105, Status 0x0007 Oct 1 10:43:42 marvin kernel: MCA: Vendor AuthenticAMD, ID 0x40fb2, APIC ID 0 Oct 1 10:43:42 marvin kernel: MCA: CPU 0 UNCOR OVER BUSLG Responder RD Memory Oct 1 10:43:42 marvin kernel: MCA: Address 0xbfa478a0 I'd appreciate if somebody helped in interpreting these messages. Thank you in advance, 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: DTrace (or other monitor) access to LBA of a block device
On Sun, Dec 5, 2010 at 19:02, Artem Belevich fbsdl...@src.cx wrote:
GEOM sounds like a good candidate for probing of that kind.
sudo dtrace -n 'fbt:kernel:g_io_deliver:entry { printf(%s %d %d
%d\n,stringof(args[0]-bio_from-geom-name), args[0]-bio_cmd,
args[0]-bio_offset, args[0]-bio_length); }'
By the way, in order for this to work one would need r207057 applied
to -8. Any chance that could be MFC'ed?
In the meantime, a workaround is an explicit cast. Using
((struct bio *)arg0)
instead of
args[0]
works.
Or wrapped in a tiny d script:
#!/usr/sbin/dtrace -s
#pragma D option quiet
fbt:kernel:g_io_deliver:entry
{
bio = (struct bio *)arg0;
printf(%s %d %d %d\n,stringof(bio-bio_from-geom-name),
bio-bio_cmd, bio-bio_offset, bio-bio_length);
}
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
DTrace (or other monitor) access to LBA of a block device
Hi, do we have any way to monitor which LBAs of which block device are read/written at a given time? I stumbled upon this, http://southbrain.com/south/2008/02/fun-with-dtrace-and-zfs-mirror.html which is pretty intriguing. Unfortunately on FreeBSD we do not have the DTrace io provider, so his dtrace script would not work. Do we have another option to monitor block device access in a similar fashion? 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: How to tell whether ECC (memory) is enabled?
On Fri, Nov 5, 2010 at 20:54, C. P. Ghost cpgh...@cordula.ws wrote: Have you tried 'dmidecode' (as run), from the port sysutils/dmidecode? I have actually, but the output is somewhat unexpected (besides the fact that there are cases in which its report do not match reality. The manpage says often.). In my box in question for example, dmidecode reports about the memory controller: Error Detecting Method: 64-bit ECC Error Correcting Capabilities: None ... Supported Memory Types: Standard SDRAM Memory Module Voltage: 2.9 V Associated Memory Slots: 4 0x0006 0x0007 0x0008 0x0009 Enabled Error Correcting Capabilities: None That seems wrong in at least two positions: First, it clearly lacks ECC in the Supported Memory Types section, and for its voltage I was expecting 1.8 V, not 2.9 V. The output concerning the memory modules itself is also unexpected. Just to pick one: Socket Designation: A0 Bank Connections: 0 1 Current Speed: 5 ns Type: DIMM Installed Size: 2048 MB (Double-bank Connection) Enabled Size: 2048 MB (Double-bank Connection) Error Status: OK While it is correct about the size, I would expect Type: ECC DIMM here. Therefore, I don't tend to trust its output, and a kernel message stating I am running on ECC memory would be lovely :-) 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: How to tell whether ECC (memory) is enabled?
On Fri, Nov 5, 2010 at 22:21, John Baldwin j...@freebsd.org wrote: During POST, die BIOS also tells me that ECC memory is installed, so far so good. But I was a little surprised that the FreeBSD kernel tells me absolutely nothing about it. Or do I have to tune loader.conf variables? I think the EDAC register is using the registers for the QPI PCI buses. There is a driver now to export those PCI buses to the OS in 7.x+. However, someone would need to port the EDAC driver (or something similar) to work with those devices. I see. Thanks for clarification! This means for now I have to trust the BIOS that ECC is enabled and I should see MCA reports in the dmesg output once a bit error is detected? 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
How to tell whether ECC (memory) is enabled?
Dear, is there any way to inspect a running STABLE machine for the presence or state of ECC memory before an MCA error detected message actually occurs? In comparison when I quickly boot the machine in question with a Linux live CD, I find (among other EDAC messages) the following output in its dmesg: ... EDAC amd64: ECC is enabled by BIOS, Proceeding with EDAC module initialization ... During POST, die BIOS also tells me that ECC memory is installed, so far so good. But I was a little surprised that the FreeBSD kernel tells me absolutely nothing about it. Or do I have to tune loader.conf variables? TIA, 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: buildworld WITH_CTF=1 breaks cc1plus on STABLE?
On Sun, Jan 17, 2010 at 14:04, Kostik Belousov kostik...@gmail.com wrote: WITH_CTF=1 results in the broken static binaries after strip(1). Do not use it (yet) for buildworld. Thank you, I must have missed this somehow. Is it maybe worth a footnote in the handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dtrace-enable.html 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
buildworld WITH_CTF=1 breaks cc1plus on STABLE?
Good evening, I am observing that doing a buildworld on stable (r202448) with WITH_CTF=1 breaks /usr/libexec/cc1plus on my amd64. Doing so causes cc1plus to crash with internal errors and ports like devel/popt don't even make it through the configure stage (fails sanity check). Is this behaviour expected? Is it discouraged to build world WITH_CTF? 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: Ath driver causes kernel panic (page fault) on 7.0-STABLE during use
Hi, On Wed, Jul 23, 2008 at 21:37, Edward Ruggeri [EMAIL PROTECTED] wrote: I recently purchased a Lenovo ThinkPad with a ThinkPad 11a/b/g Wireless LAN Mini Express Adapter (based on the AR5212 chipset). I got kernel panics while using the wireless card under 7-STABLE Do you still have this problem or did you find a workaround? Does it look something like this? : http://www.freebsd.org/cgi/query-pr.cgi?pr=126475 I upgraded my notebook from 6.3 to 7-STABLE on the weekend and get reproducible kernel panics ~2 sec of using the ath network card. Riggs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with xl driver (cvsup 2001-06-02)
Hi, Am Sa , dem 02. Jun 2001, um 11:51 + Uhr schrubte Wilko Bulte zum Thema [Re: Problem with xl driver (cvsup 2001-06-02)]: This is most likely PR kern/27722 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27722 Wilko Yes, this was exactly the cure. Everything runs fine now, just as expected :-) Thanks a lot Riggs -- - Die Welt schläft tief schon lange Zeit | Sent with RiggiSmooth [tm] - -- Mich nur flieht die Dunkelheit| - -- --- Denn per Infrarot seh ich| just to fit your --- Die Nacht ist wirklich widerlich. | primitive screen. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Problem with xl driver (cvsup 2001-06-02)
Hi, Am Sa , dem 02. Jun 2001, um 22:25 + Uhr schrubte K Karthik zum Thema [Re: Problem with xl driver (cvsup 2001-06-02)]: No problems for me. My dmesg line: *--* xl0: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 0xf400-0xf47f irq 11 at device 13.0 on pci0 *--* scanpci: *--* pci bus 0x0 cardnum 0x0d function 0x: vendor 0x10b7 device 0x9200 3COM Device unknown *--* Look at the URL Wilko posted in the morning. But you're right, in fact 3com cards 3c905 and 3c905c are quite different. Riggs -- - Die Welt schläft tief schon lange Zeit | Sent with RiggiSmooth [tm] - -- Mich nur flieht die Dunkelheit| - -- --- Denn per Infrarot seh ich| just to fit your --- Die Nacht ist wirklich widerlich. | primitive screen. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Hanging on floppy, ATAPCI detection
Hi, Am Mo , dem 21. Mai 2001, um 17:17 -0400 Uhr schrubte Tom Gottheil zum Thema [Hanging on floppy, ATAPCI detection]: On boot, the system hangs for a couple of minutes after detecting both my ATA PCI RAID card and my floppy drive. They seem to work fine, it just takes a long time to detect them. Has anyone had a simiar problem? (I'm running 4.3-STABLE, cvsupped two days ago, but it also happened with 4.3-RELEASE) Similar here. It takes about 20 seconds to detect. But it's no RAID or something, just that all my harddisks are connected to the promise controller, not the primary or secondary on-board controller. But I don't think this is a 'real' problem. It works fine and quite fast after detection :-) Riggs -- - Die Welt schläft tief schon lange Zeit | Sent with RiggiSmooth [tm] - -- Mich nur flieht die Dunkelheit| - -- --- Denn per Infrarot seh ich| just to fit your --- Die Nacht ist wirklich widerlich. | primitive screen. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
