Re: boot hang with certain Phenom II cpu models
On Fri, 2018-12-14 11:56 +0200, Andriy Gapon wrote: > On 13/12/2018 12:56, Sascha Klauder wrote: > > So far, I tried (unsuccessfully) to disable obvious ACPI sub- > > systems (cpu, mwait, quirks) and debug settings (acpi.cpu_unordered, > > acpi.max_threads). Anyone got a hint where to look or debug this > > further? > Are you able to identify if you have a hardware or a software hang? > E.g., are you able to enter ddb? Hardware; can't enter ddb and can't toggle caps lock. I could probably setup remote GDB (serial) but would need some pointer how to proceed from there. Cheers, -sascha ___ 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: boot hang with certain Phenom II cpu models
Hello Marek, On Thu, 2018-12-13 14:24 +0100, Marek Zarychta wrote: > Try to boot FreeBSD with GRUB2 as a workaround. My hardware configuration > also suffered from similar issue[1] so I had never successfully booted > FreeBSD using standard loader, but GRUB2 allowed to install and use FreeBSD > on this PC. > > [1]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=151122 thanks for the suggestion. Unfortunately, it did not help; kernel still hangs :| Cheers, -sascha ___ 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"
boot hang with certain Phenom II cpu models
Hi all, I've recently upgraded my Athlon II based home box (happily running FreeBSD for several years) to a Phenom II X4 960T CPU. Now, kernel (11.2) hangs in early hardware initialization. Mainboard is a nForce 720 based Gigabyte GA-M720-US3 rev 1.0, BIOS is latest and the CPU is on Gigabyte's CPU support list for this board. A parallel Windows 7 installation continues to work flawlessly and the system is stable running prime95. Memtest86 reports no errors. I've tried several other OS boot media (DragonFly 5.4, OpenBSD 6.4, Linux 4.9) -- all boot fine with no problems (see dmesg output linked below). I've found two very similiar problem reports on the FreeBSD forums. Both involve Phenom II cpu's and nForce-based mainboards, so I think we're missing some BIOS/ACPI quirk here. https://forums.freebsd.org/threads/10-1-installer-wont-boot-past-acpi.50015/ https://forums.freebsd.org/threads/boot-hangs-after-cpu-upgrade.64410/ So far, I tried (unsuccessfully) to disable obvious ACPI sub- systems (cpu, mwait, quirks) and debug settings (acpi.cpu_unordered, acpi.max_threads). Anyone got a hint where to look or debug this further? kernel boot messages (obtained from 10.4 amd64): https://lair.griffinsplace.de/~sascha/phenom/dmesg-freeze-FreeBSD10.txt boot messages with the previous Athlon II cpu in this system: https://lair.griffinsplace.de/~sascha/phenom/dmesg-FreeBSD-AthlonII.txt boot messages from DFly, OpenBSD and Linux: https://lair.griffinsplace.de/~sascha/phenom/ Cheers, -sascha ___ 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"
AUTO: Sascha Klauder ist außer Haus (Rückkehr am 10/25/2016)
Ich kehre zurück am 10/25/2016. Sehr geehrte Damen und Herren, ich bin vom 26.08.2016 bis 25.10.2016 in Elternzeit und kann E-Mail nur unregelmäßig bearbeiten. Ihre Nachricht wird nicht weitergeleitet. Bitte wenden Sie sich ggf. an supp...@nt.ag. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "Re: Nvidia_load not working" gesendet am 19.09.2016 04:02:55. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. ___ 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"
ATA timeout with TRIM flag set
Hi all, I've bought a 60 GB Intel 330 series SSD, connected to a Promise TX4 (FastTrak 4310) SATA300 controller (PDC40719). Running 9.0-STABLE dated mid-January 2012. Writing to any filesystem that has TRIM enabled will make the disk timeout and eventually panic the system. atapci0: Promise PDC40719 SATA300 controller port 0xe000-0xe07f,0xd000-0xd0ff mem 0xf6042000-0xf6042fff,0xf600-0xf601 irq 11 at device 8.0 on pci0 ata5: SIGNATURE: 0101 ada0 at ata5 bus 0 scbus5 target 0 lun 0 ada0: INTEL SSDSC2CT060A3 300i ATA-9 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) Writing to a TRIM-enabled UFS filesystem will almost immediately stall whatever process running in ufs or wdrain, with the disk seemingly dropping off the bus after about 15s: ata5: SIGNATURE: 0101 ata5: SIGNATURE: ata5: timeout waiting to issue command ata5: error issuing ATA_IDENTIFY command ata5: SIGNATURE: (ada0:ata5:0:0:0): lost device ata5: timeout waiting to issue command ata5: error issuing unknown CMD (0x06) command ata5: SIGNATURE: g_vfs_done():ada0s1a[WRITE(offset=40711716864, length=32768)]error = 6 /dev: got error 6 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error Uptime: 14m36s ata5: timeout waiting to issue command ata5: error issuing FLUSHCACHE48 command ata5: SIGNATURE: (ada0:ata5:0:0:0): Synchronize cache failed The drive works fine without TRIM on this controller. I also had no issues whatsoever with two SATA harddisks pre- viously running on the same card for several months. I believe there's an issue with the controller since I've verified that the drive works fine with TRIM enabled on two different SATA controllers (nForce3 and nForce MCP77 AHCI on Gigabyte mainboards). Any use opening a PR or should I get another controller? I'm aware there are issues at least with PDC40718-based cards. Cheers, -sascha ___ 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
ale(4) not attaching after suspend/resume cycle
Hi all, I'm trying to get suspend/resume functionality to work on my Acer Aspire One D250 netbook. I'm running 8.2-STABLE i386 as of 2011-02-25. Suspend was doing fine, but it would freeze on resume. By trial and error I've been able to pinpoint the problematic driver as ale(4). The machine will correctly resume once I un- load if_ale before suspending. I wouldn't mind that as a workaround, however, it fails to reattach after a suspend/resume cycle: pci0: driver added pci1: driver added found- vendor=0x1969, dev=0x1026, revid=0xb0 domain=0, bus=1, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0407, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D3 current D3 MSI supports 1 message, 64 bit pci0:1:0:0: reprobing on driver added pci0:1:0:0: Transition from D3 to D0 ale0: Atheros AR8121/AR8113/AR8114 PCIe Ethernet port 0x3000-0x307f mem 0x9520-0x9523 irq 16 at device 0.0 on pci1 pcib1: ale0 requested memory range 0x9520-0x9523: good ale0: phy write timeout : 29 ale0: phy write timeout : 30 ale0: phy write timeout : 29 ale0: phy write timeout : 30 ale0: phy write timeout : 29 ale0: phy write timeout : 30 ale0: phy write timeout : 29 ale0: phy write timeout : 29 ale0: phy write timeout : 29 ale0: phy write timeout : 29 ale0: master reset timeout! ale0: reset timeout(0x)! ale0: PCI device revision : 0x00b0 ale0: Chip id/revision : 0x ale0: chip revision : 0x, 4294967295 Tx FIFO 4294967295 Rx FIFO -- not initialized? device_attach: ale0 attach returned 6 It does attach and work correctly even if loaded after booting. Repeated loading and unloading works as well. Anything obvious that I could try? Complete dmesg is available here: http://arwen.shopkeeper.de/~sascha/acer/dmesg.verbose Cheers, -sascha ___ 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: hifn(4) causing system lockup
On Tue, Mar 18, 2008 at 10:25:03AM -0400, Vivek Khera wrote: On Mar 17, 2008, at 4:05 PM, Sascha Klauder wrote: I've got a Soekris vpn1401 card to help with GELI disk en- cryption. Reading from a GELI volume is causing the system to freeze completely, which does not happen if software crypto is used (i.e. hifn.ko not loaded). I can't enter kernel debugger (ctrl+alt+esc doesn't work anymore) and my (remote) kgdb-fu isn't up to par anyway. I've had the exact same kind of issue with the vpn1401 PCI card in a Dell box for my firewall running pfSense (at the tie it was based on FreeBSD 6.1 I believe). It would lock up the firewall within 2 hours to 4 days of uptime. Once we removed the card, no lockups. Soekris never responded to my questions about such behavior. Interesting. But then, like I already wrote, I had it running fine for months on 6.2-STABLE. Now that both 6.3 and 7.0 exhibit this lockup behaviour, I naturally suspected some issue with the driver, even more so since revision 1.40 seems to have brought in several changes. I blame the card. Hmpf. Cheers, -sascha ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
hifn(4) causing system lockup
Hi all, can someone comment on the state of the hifn(4) driver? I've recently upgraded my 6.2-STABLE workstation to RELENG_7, and I'm now experiencing system lockups that seem to be caused by the hifn(4) driver. I've got a Soekris vpn1401 card to help with GELI disk en- cryption. Reading from a GELI volume is causing the system to freeze completely, which does not happen if software crypto is used (i.e. hifn.ko not loaded). I can't enter kernel debugger (ctrl+alt+esc doesn't work anymore) and my (remote) kgdb-fu isn't up to par anyway. PR kern/92716, which is quite old already, describes somewhat similar symptoms. I had no such problems on the previous 6.2 install (dated from July 2007), and have verified that 6.3 shows the lockup behaviour as well. dmesg output available here: http://evenstar.shopkeeper.de/~sascha/avalon.dmesg7 Cheers, -sascha ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_t4dwave(4) broken in RELENG_7?
On Fri, Nov 09, 2007 at 12:36:49AM +0800, Ariff Abdullah wrote: On Fri, 9 Nov 2007 00:13:20 +0800 Ariff Abdullah [EMAIL PROTECTED] wrote: On Thu, 8 Nov 2007 16:04:08 +0100 Sascha Klauder [EMAIL PROTECTED] wrote: I could provide ssh access to my system, if that would help. Thanks for the offer, but I'm kind of busy right now. Maybe after a week or two from now, I'll contact you again. Ok, just tell me if you need to do further testing. Try this one: http://people.freebsd.org/~ariff/test/t4dwave.c It's working fine, thank you Ariff! Cheers, -sascha ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
snd_t4dwave(4) broken in RELENG_7?
Hi all, can someone verify whether snd_t4dwave is working in RELENG_7? After upgrading my 6.2-STABLE (from March 2006) to 7.0-BETA2, I get pcm0:play:dsp0.p1: play interrupt timeout, channel dead errors a few seconds after playback started. It's a HP nx9005 laptop, so I'm not sure if it could be ACPI- related, but sound was working fine ever since I installed 5.2 on it. Disabling ACPI makes no difference. Verbose dmesg available here: http://evenstar.shopkeeper.de/~sascha/nx9005/misc/dmesg-7-verbose (actually still from a -CURRENT shortly before the branch) Cheers, -sascha ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_t4dwave(4) broken in RELENG_7?
On Thu, Nov 08, 2007 at 10:43:06PM +0800, Ariff Abdullah wrote: On Thu, 8 Nov 2007 14:46:51 +0100 Sascha Klauder [EMAIL PROTECTED] wrote: Verbose dmesg available here: http://evenstar.shopkeeper.de/~sascha/nx9005/misc/dmesg-7-verbose (actually still from a -CURRENT shortly before the branch) Try changing #define TR_MAXPLAYCH from 4 to 1, in sys/dev/sound/pci/t4dwave.c Thanks, that did help! The driver is virtually unchanged ever since 5.x . I'm at lost (no hardware to test). I could provide ssh access to my system, if that would help. Cheers, -sascha ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
