Bug 162936
| Summary: | fails boot and destabilizes other OSes on FreeBSD 9 RC2 with MSI P6N SLI Platinum | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Kevin Ar18 <kevinar18> |
| Component: | amd64 | Assignee: | Mark Linimon <linimon> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Kevin Ar18
2011-11-29 02:40:07 UTC
On Monday, November 28, 2011 9:35:08 pm Kevin Ar18 wrote: > >Synopsis: fails boot and destabilizes other OSes on FreeBSD 9 RC2 with MSI P6N SLI Platinum > ... > >Release: FreeBSD 9 RC2 > >Organization: > >Environment: > * MSI P6N SLI Plantium (nForce 650i northbridge)(nForce 430i southbridge) > * Intel Q6600 > * USB Memory > * 1x IDE drive > * 1x SATA drive > >Description: > Summary: > -------- > Using the "FreeBSD-8.2-RELEASE-amd64-memstick.img" Hm, here you say 8.2, bit your title says 9? On a whim, if this is 9, can you try setting 'debug.acpi.disabled=hostres' from the loader prompt? -- John Baldwin Apologees, it is definitely 9 RC2. I just copied the wrong name. I was using this one for most tests: ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.0/FreeBSD-9.0-RC2-amd64-memstick.img I also tried a nightly build (built with LLVM+Clang) that someone else made: http://forums.freebsd.org/showthread.php?p=156243 It was the "freebsd-head-clang.amd64-r228148.img" It also did not work... although I got the db (debugger?) ... Tried debug.acpi.disabled="hostres" by adding that line to /boot/boot.conf and /boot/loader.conf Also, on boot, I escaped to the loader and typed in: set debug.acpi.disabled=hostres and debug.acpi.disabled=hostres (Is one of those right?) Anyways, same errors. Including failed boot, no devices listed in GEOM, and Windows blue screen. I looked through the file system to see if it made any logs; no logs were made, so can't paste any info from that. ------------ Also, I should note, that DragonFlyBSD boots and detects just fine. Here's a piece of the log that might be relevant from DragonFly: ohci0.pci0.pcib0.acpi0.nexus0.root0 ohci0: <OHCI (generic) USB controller> [tentative] mem 0xf9fff000-0xf9ffffff irq 5 at device 11.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xf9fff000 usb0: OHCI version 1.0, legacy support usb0.ohci0.pci0.pcib0.acpi0.nexus0.root0 usb0: <OHCI (generic) USB controller> [tentative] on ohci0 usb0: USB revision 1.0 uhub0.usb0.ohci0.pci0.pcib0.acpi0.nexus0.root0 uhub0: <nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> [tentative] on usb0 uhub0: 8 ports with 8 removable, self powered uhub0: <nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> [attached!] on usb0 usb0: <OHCI (generic) USB controller> [attached!] on ohci0 ohci0: <OHCI (generic) USB controller> [attached!] mem 0xf9fff000-0xf9ffffff irq 5 at device 11.0 on pci0 ehci0.pci0.pcib0.acpi0.nexus0.root0 ehci0: <EHCI (generic) USB 2.0 controller> [tentative] mem 0xf9ffec00-0xf9ffecff irq 10 at device 11.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xf9ffec00 usb1: waiting for BIOS to give up control usb1: EHCI version 1.0 usb1: companion controller, 8 ports each: usb0 usb1.ehci0.pci0.pcib0.acpi0.nexus0.root0 usb1: <EHCI (generic) USB 2.0 controller> [tentative] on ehci0 usb1: USB revision 2.0 uhub1.usb1.ehci0.pci0.pcib0.acpi0.nexus0.root0 uhub1: <nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> [tentative] on usb1 uhub1: 8 ports with 8 removable, self powered uhub1: <nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> [attached!] on usb1 umass0.uhub1.usb1.ehci0.pci0.pcib0.acpi0.nexus0.root0 umass0: <PNY Technologies USB 2.0 FD, class 0/0, rev 2.00/11.00, addr 2> [tentative] on uhub1 umass0:2:0:-1: Attached to scbus2 umass0: <PNY Technologies USB 2.0 FD, class 0/0, rev 2.00/11.00, addr 2> [attached!] on uhub1 usb1: <EHCI (generic) USB 2.0 controller> [attached!] on ehci0 ehci0: <EHCI (generic) USB 2.0 controller> [attached!] mem 0xf9ffec00-0xf9ffecff irq 10 at device 11.1 on pci0 atapci0.pci0.pcib0.acpi0.nexus0.root0 atapci0: <nVidia nForce MCP51 UDMA133 controller> [tentative] port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 13.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 I think it is in this same area that FreeBSD comes up with all kinds of errors like: usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) I also noticed FreeBSD does not detect the exact controller model in some lines, but just a generic "nvidia" Other details: FreeBSD will bluescreen Windows even if I run another os first. For example (1) Try to boot FreeBSD; it fails (2) Run DragonFlyBSD (3) Run Windows and get a blue screen from the failed FreeBSD boot. = For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped Unfortunately this PR was never addressed before these versions of FreeBSD went out of support. Sorry. If this is still a problem, please open a new PR. Thanks. |
