Bug 187015
| Summary: | agp(4): Panic make_dev_credv: bad si_name (error=17, si_name=agpgart) | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Sergey Matveychuk <sem> |
| Component: | kern | Assignee: | Mark Johnston <markj> |
| Status: | In Progress --- | ||
| Severity: | Affects Some People | CC: | JxxxBxxxx, bfsct+freebsdbugzilla, cem, dominik.muth, dumbbell, fred+freebsdbugzilla, gayantha_kodikara, geoff, kennedy.greg, kib, linimon, markj, mi, ota, pi, tatsuki_makino, tingox+freebsd, tookmund |
| Priority: | Normal | Keywords: | crash |
| Version: | 12.0-RELEASE | Flags: | koobs:
mfc-stable13?
|
| Hardware: | Any | ||
| OS: | Any | ||
| See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=136327 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266999 |
||
| Attachments: | |||
|
Description
Sergey Matveychuk
2014-02-25 03:00:00 UTC
A little addition. I have the lines in my dmesg: ACPI BIOS Error (bug): A valid RSDP was not found (20130823/tbxfroot-223) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. It looks like agp_generic_attach is trying to create two device nodes both named "/dev/agpgart" with no unit numbers. That's a no-no, which is why you're getting EEXIST (errno 17). As a workaround, try disabling merely one of your two AGP devices. That will probably fix the panic. The next question is: why do you have two AGP devices? Created attachment 145022 [details]
test patch for 9-STABLE.
This problem also occurs my computer that is used Intel 855 GME chipset.
This problem also occurs in versions below.
9.3-RELEASE
9.2-RELEASE
10.0-RELEASE
9-STABLE
And I expect it also occurs in CURRENT, but I have not checked it yet.
The patch can avoid panic. And some informations are added to dmesg.boot.
Quote of part of the dmesg.boot:
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <Intel 82855GM host to AGP bridge> on hostb0
agp0: ==== make_dev agpgart for 0x35808086 ====
agp0: ==== sc->as_devnode: 0xc52e9c00 ====
agp0: ==== sc->as_devnode->si_drv1: 0 ====
agp0: ==== sc->as_devnode->si_drv1: 0xc52e8980 ====
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0x1800-0x1807 mem 0xe8000000-0xefffffff,0xe0000000-0xe007ffff irq 9 at device 2.0 on pci0
agp1: <Intel 82855GME (855GME GMCH) SVGA controller> on vgapci0
agp1: ==== make_dev agpgart for 0x35828086 ====
agp1: ==== sc->as_devnode: 0 ====
agp1: aperture size is 128M, detected 8060k stolen memory
vgapci0: Boot video device
vgapci1: <VGA-compatible display> mem 0xf0000000-0xf7ffffff,0xe0080000-0xe00fffff at device 2.1 on pci0
Perhaps, agp0 is calling agp_generic_attach from sys/dev/agp/agp_intel.c. and agp1 is calling agp_generic_attach from agp_generic_attach from sys/dev/agp/agp_i810.c. But /dev/agpgart is already exists in second time of calling agp_generic_attach.
Perhaps, this patch's agpgart is referring to agp0. It is not right.
Created attachment 145023 [details]
test patch for 8-STABLE
8.4-RELEASE and 8.4-STABLE has same problem. But 8.4 doesn't cause panic.
Because devfs of 8.4 allows make duplicate entry.
Quote of part of the dmesg.boot when the patch is used:
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <Intel 82855GM host to AGP bridge> on hostb0
agp0: ==== make_dev agpgart for 0x35808086 ====
agp0: ==== sc->as_devnode: 0xc52a4300 ====
agp0: ==== sc->as_devnode->si_drv1: 0 ====
agp0: ==== sc->as_devnode->si_drv1: 0xc52a1000 ====
pci0: <base peripheral> at device 0.1 (no driver attached)
pci0: <base peripheral> at device 0.3 (no driver attached)
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0x1800-0x1807 mem 0xe8000000-0xefffffff,0xe0000000-0xe007ffff irq 9 at device 2.0 on pci0
agp1: <Intel 82855GME (855GME GMCH) SVGA controller> on vgapci0
agp1: ==== make_dev agpgart for 0x35828086 ====
agp1: ==== sc->as_devnode: 0xc52a4400 ====
agp1: ==== sc->as_devnode->si_drv1: 0 ====
agp1: ==== sc->as_devnode->si_drv1: 0xc5295480 ====
agp1: aperture size is 128M, detected 8060k stolen memory
vgapci1: <VGA-compatible display> mem 0xf0000000-0xf7ffffff,0xe0080000-0xe00fffff at device 2.1 on pci0
sc->as_devnode refers to a different pointer. I do not know how it work correctly.
10.1-BETA1 r271727 couldn't be booted. But It could be booted after typing below on loader prompt set hint.agp.0.disabled=1 boot-conf Encountering the same kernel panic with FreeBSD 10.1 RC3 installer (memstick img) (screenshot) http://pix.toile-libre.org/upload/original/1414061308.jpg Same intel 855GME adapter, on an Xploretech ix104c3 tablet PC. Booting with hint.agp.0.disabled=1 helped go further, but then I had to disable ACPI as well otherwise another type of kernel panic occured. Now blocked at "still waiting xpt_config" messages. If more details needed please ask (I'm new to FreeBSD). My 855GME is needed to write lines below to boot 10.2-RELEASE because agp2 is appeared. hint.agp.0.disabled=1 hint.agp.2.disabled=1 I appear to have been bitten by the same bug in 10.2-RELEASE Interestingly it did not happen in 10.1-STABLE but occurs in 10.2 RELEASE and 10.3 at least up to Revision 294986 (what I tested today) Putting this line (as suggested below) in loader.conf worked: hint.agp.1.disabled=1 The backtrace: agp1: <Intel 82855GME (855GME GMCH) SVGA controller> on vgapci1 panic: make_dev_sv: bad si_name (error=17, si_name=agpgart) cpuid = 0 KDB: stack backtrace: #0 0xc0b79682 at kdb_backtrace+0x52 #1 0xc0b3a1ab at vpanic+0x11b #2 0xc0b3a08b at panic0x1b #3 0xc0adf593 at make_dev_sv+0x2f3 #4 0xc0adf61a at make_dev+0x7a #5 0xc0571514 at agp_generic_attach+0x124 #6 0xc0f573eb at agp_i810_attach+0x7b #7 0xc0b6fd94 at device_attach+0x474 #8 0xc0b70e2b at bus_generic_attach+0x2b #9 0xc08669ca at vga_pci_attach+0x4a #10 0xc0b6fd94 at device_attach+0x474 #11 0xc0b70e2b at bus_generic_attach+0x2b #12 0xc055175b at acpi_pci_attach+0x18b #13 0xc0b6fd94 at device_attach+0x474 #14 0xc0b70e2b at bus_generic_attach+0x2b #15 0xc05543dc at acpi_pcib_attach+0x25c #16 0xc05543dc at acpi_pcib_acpi_attach+0x2ec #17 0xc0b6fd94 at device_attach+0x474 (In reply to tookmund from comment #8) I forgot to add that I am using a Thinkpad R51 I'm experiencing this in 10.3 Release on a Toshiba Satelite L10-104. The hints respectively patches mentioned make it boot. However it crashes when starting xorg with the intel driver. It works with the vesa driver, but I need hardware acceleration (2D is OK, no need for OpenGL). Anybody ever running FreeBSD with xorg and the Intel driver on a 855GM successfully? (In reply to dominik.muth from comment #10) For completeness I attached my patch for 10.3-RELEASE. It add unit numbers to the agpgart device files to resolve the naming conflict. Created attachment 175656 [details]
Resolve agpgart naming conflict by adding unit numbers to the device files.
Created attachment 176606 [details]
Patch for FreeBSD 11 to remove kernel panic and number agpgart devices
I was affected when I installed FreeBSD 11 on a 2004 Toshiba laptop with an Intel 855 graphics chip and an external VGA port. There was a kernel panic as the PCI bus was checked for devices. Each graphics port has a separate set of memory addresses and shows up separately during the PCI probe.
The patch uses make_dev_s with MAKEDEV_CHECKNAME to prevent a kernel panic if something goes wrong but includes logging and state cleanup on error.
The patch creates /dev/agpgart for the first AGP device found on the bus and numbers each unit after that (/dev/agpgart2, ...).
Without the patch, the work-around is to stop the boot loader and enter the following commands:
set hint.agp.1.disabled=1
boot
Once booted, the following line is added to /boot/loader.conf:
hint.agp.1.disabled=1
These fixes have been tested with X11 and a dual monitor setup.
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open" laptop HP pavilion ze4900
FreeBSD-11.2-RELEASE-i386-bootonly.iso
at boot (first time)
set hint.agp.1.disabled=1
boot
to fix (subsequent boots)
add hint.agp.1.disabled=1 to /boot/loader.conf
/error
module_register_init: MOD_LOAD (vesa, 0xc10180a0, 0) error 19
panic: make_dev_sv: bad si_name (error=17, si_name=agpgart)
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 04:09:26 UTC 2018
root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (base on LLVM 6.0.0)
VT(vga): resolution 640x480
CPU: Intel(R) Pentium(R) M processor 1500MHz (1498.76-MHz 686-class CPU)
Origin="GenuineIntel" Id=0x695 Family=0x6 Model=0x9 Stepping=5
Features=0xa7e949bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE>
Features2=0x180<EST,TM2>
real memory = 268435456 (256 MB)
avail memory = 196849664 (187 MB)
Timecounter "TSC" frequency 1498757565 Hz quality 800
random: entropy device external interface
kbd1 at kbdmux0
module_register_init: MOD_LOAD (vesa, 0xc10180a0, 0) error 19
nexus0
vtvga0: <VT VGA driver> on motherboard
cryptosoft0: <software crypto> on motherboard
acpi0: <HP 3084> on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0: <AT realtime clock> port 0x70-0x77 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
acpi_ec0: <Embedded Controller: GPE 0x1d> port 0x62,0x66 on acpi0
acpi_acad0: <AC Adapter> on acpi0
battery0: <ACPI Control Method Battery> on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> port 0x1800-0x1807 mem 0xe8000000-0xefffffff,0xe0000000-0xe007ffff irq 10 at device 2.0 on pci0
agp0: <Intel 8285xM (85xGM GMCH) SVGA controller> on vgapci0
agp0: aperture size is 128M, detected 32636k stolen memory
vgapci0: Boot video device
vgapci1: <VGA-compatible display> mem 0xf0000000-0xf7ffffff,0xe0080000-0xe00fffff at device 2.1 on pci0
agp1: <Intel 8285xM (85xGM GMCH) SVGA controller> on vgapci1
panic: make_dev_sv: bad si_name (error=17, si_name=agpgart)
cpuid = 0
KDB: stack backtrace:
#0 0xc0bcdae at kdb_backtrace+0x4e
#1 0xc0b8c9f8 at vpanic+0x108
#2 0xc0b8c8e4 at panic+0x14
#3 0xc0b373f8 at make_dev_sv+0x2e8
#4 0xc0b3746a at make_dev+0x6a
#5 0xc059fa78 at agp_generic_attach+0x118
#6 0xc0fab422 at agp_i810_attach+0x62
#7 0xc0bc1851 at device_attach+0x311
#8 0xc0bc287a at bus_generic_attach+0x2a
#9 0xc0863806 at vga_pci_attach+0x36
#10 0xc0bc1851 at device_attach+0x311
#11 0xc0bc287a at bus_generic_attach+0x2a
#12 0xc085925f at pci_attach+0xbf
#13 0xc0bc1851 at device_attach+0x311
#14 0xc0bc287a at bus_generic_attach+0x2a
#15 0xc05837c0 at acpi_pcib_acpi_attach+0x3c0
#16 0xc0bc1851 at device_attach+0x311
#17 0xc0bc287a at bus_generic_attach+0x2a
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
By the way, how many PCs are affected by this bug in the whole world? My 855GME will no longer boot. orz I was just bit by this on my ancient Sony Vaio. Tried both 12.0 and 11.2 snapshots as of April 11, 2019. Machine was booting happily with 8.2, listing two vgapci-devices: vgapci0: <VGA-compatible display> port 0x1800-0x1807 mem 0xe8000000-0xefffffff,0 xe0000000-0xe007ffff irq 9 at device 2.0 on pci0 agp0: <Intel 8285xM (85xGM GMCH) SVGA controller> on vgapci0 agp0: detected 3964k stolen memory agp0: aperture size is 128M vgapci1: <VGA-compatible display> mem 0xf0000000-0xf7ffffff,0xe0080000-0xe00ffff f at device 2.1 on pci0 The original work-around helped avoid the panic. And now I am also blocked by the xpt_config's endlessly looping -- as was mentioned in Comment #6 five years ago... (In reply to fred+freebsdbugzilla from comment #6) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=136327 discusses the xpt issue. Created attachment 204441 [details] Panic screenshot: 10.1 RC33 Intel 855GME Attach screenshot from comment 6 in case it goes away We need an updated patch against latest CURRENT confirmed to resolve the issue dumbbell and kib may be able to help given graphics expertise and (not quite so recent) commits to this area of the tree. /dev/agpgart must point to real agp instead of the ghost sibling, but the order of enumeration is not strictly defined. So I think that both nodes should be created as /dev/agpgart0 and /dev/agpgart1, and then a symlink, the alias device in devfs term, created to point to one of them. Perhaps use pci function number as the unit number, and them symlink to function 0. I wonder if Gen3 or earlier hw work with the current off-tree drm kmod. If it does not, then perhaps this report should be closed as 'not fix'. (In reply to Konstantin Belousov from comment #21) I have a hardware that I run 13-current, I need and have been using loader.rc work-around, and switched to use ports' DRM module. I have last updated around March 2019. I can help testing. I can test as well. Compaq Presario 2200 notebook with Intel 845GM soldered into on-board AGP. Kernel panic still happens in 12.0-p5 without the workaround. Comment on attachment 145022 [details]
test patch for 9-STABLE.
Overcome by events. The patch for -11 should still be applicable.
Comment on attachment 145023 [details]
test patch for 8-STABLE
Overcome by events. The patch for -11 should still be applicable.
Comment on attachment 175656 [details]
Resolve agpgart naming conflict by adding unit numbers to the device files.
Overcome by events. The patch for -11 should still be applicable.
Is the patch being taken? It will be nice if a system works without a work-around. Can someone take a look at this? This has been long standing and also multiple fixes have been suggested. I started using pxeboot and pxeboot doesn't seem to loder.conf. As a result, a machine started crashing; it requires setting hint.agp.1.disabled=1 at loader prompt every time. laptop Fujitsu S6120 FreeBSD 13.0-RELEASE-i386-memstick.img needs set hint.agp.1.disabled=1 at boot loader prompt in order to boot without kernel panic. More info, including normal and verbose dmesg is available here http://tingo.homedns.org/machines/fujitsu_lifebook_s6120/freebsd/ *** Bug 210194 has been marked as a duplicate of this bug. *** A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=437ea82ce7fc3e664447b9e7d08f5c135a7e2f31 commit 437ea82ce7fc3e664447b9e7d08f5c135a7e2f31 Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2021-11-25 16:27:49 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2021-11-25 16:36:33 +0000 agp: Handle multiple devices more gracefully Currently agp(4) effectively assumes that only one driver instance exists, as the generic attach routine attempts to create /dev/agpgart and triggers a panic if it already exists. Instead, handle this situation by creating /dev/agpgart<unit> and making /dev/agpgart an alias of /dev/agpgart0 for compatibility. PR: 187015 Reviewed by: imp, kib Tested by: Yoshihiro Ota <ota@j.email.ne.jp> (earlier version) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D33068 sys/dev/agp/agp.c | 33 ++++++++++++++++++++++++++++----- sys/dev/agp/agppriv.h | 1 + 2 files changed, 29 insertions(+), 5 deletions(-) (In reply to commit-hook from comment #31) It seems that agpgart always points to agpgart0, is that a solution? My laptop was using hint.agp.*.disable=1 to leave only 1. Doesn't this mean that agpgart should be pointing to agpgart1? However, my laptop (Panasonic Let'snote Y2 (toughbook CF-Y2)) is already broken and cannot be tested :) So if you have a laptop that was sold in 2004-2005, please gather here :) (In reply to commit-hook from comment #31) I tested the new patch and the machine booted fine. This change will help diskless boot; otherwise, I have to type in the hint from console every time as diskless boot doesn't seem to use loader.conf. (In reply to ota from comment #33) I would like to see the results of X.org selecting the correct agpgart and testing that the agpgart is effective. But, I don't know what effect it has :) ^Triage: Assign to committer resolving (see comment 31) @Mark did this end up being merged to stable/{13,12}? Please set mfc-stable* flags accordingly, and is there anything left to do here? (In reply to commit-hook from comment #31) I am trying to install FreeBSD on a Thinkpad X40 laptop. I started installing FreeBSD 13.1 and tried all the previous versions until version 10. When I try to install it, it shows the below message and restarts. Code: agp1: <Intel 82855GME (855GME GMCH) SVGA controller> on vgapci1 panic: make_dev_sv: bad si_name (erroe=17, si_name=agpgart) cpuid =0 time = 1 KDB: stack backtrace: #0 0x107540f at kdb_backtrace+0x4f ...... ...... #17 0x1065a03 at device_attach+0x303 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort. ---------------------------------------------------------------------- Then I tried both, set hint.agp.0.disabled=1 set hint.agp.1.disabled=1 But it didn't work. Then I tried using a pre-installed FreeBSD 13 hard disk (from Thinkpad X41), but it also gave the same error and rebooted within 15 seconds during the booting process. I also tried the FreeBSD 14.0-CURRENT, but the error was the same. Both the BIOS and Embedded controller programs of this machine are the last updated versions. Finally, I end up with installing NetBSD on Thinkpad X40(it works well). But, I really want to install FreeBSD and am very happy to use this machine to test any updates. Thank you. ^Triage: FreeBSD 12 is now EOL.(In reply to Gayantha Kodikara from comment #36) (In reply to Gayantha Kodikara from comment #36) ^Triage: note to commenter: we really don't have a good way to track new comments on PRs once a commit has been done. If you are still having this problem, we can help you open a new PR. (In reply to Mark Linimon from comment #38) Thank you so much for the comment. I didn't try with the FreeBSD 14 release. I will try will update you soon. Thank you. |
