Re: [regression] unable to boot: no GEOM devices found.
David Naylor wrote: I am running -current and since a few days ago (at least 2011/04/11) I am unable to boot. The boot process stops when it looks to find a bootable device. The prompt (when pressing '?') does not display any device and yielding one second (or more) to the kernel (by pressing '.') does not improve the situation. A known working date is 2011/02/20. I am running amd64 on a nVidia MCP51 chipset. MCP51... again... I am willing to help any way I can. You could start from capturing and showing verbose dmesg. Full or at least in parts related to disks. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: amd family 15h topology detection
On Mon, 11 Apr 2011 21:44:04 +0300 Andriy Gapon a...@freebsd.org wrote: Here is a patch that should prepare us for AMD Bulldozer CPUs: http://people.freebsd.org/~avg/amd-f15h-topo.diff The patch should not affect pre-10h systems at all, on 10h systems the new code path should be taken, but the result should be the same as the legacy method. I can verify that there are no changes for my pre-f10h model. I have an old f6b stepping 2 model and AFAICT the output is the same. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vmware-tools-freebsd No drivers for x.org version: 7.6.5.
El día Monday, April 11, 2011 a las 09:31:47AM +0200, Matthias Apitz escribió: Hello, I removed the VMware' vmware-tools-freebsd and installed from the ports x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware; When I now run 'X -configure' the X.org server Seg faults after loading the /usr/local/lib/xorg/modules/drivers/vmware_drv.so (a complete Xorg.0.log is attached) Any ideas or should I file a bug report? I filed a bug report http://www.freebsd.org/cgi/query-pr.cgi?pr=156330 which was ofc closed because I should update the ports tree (mine is from November 2010); I will do this later in another VM. To overcome the current problem I have just copied over the file /etc/X11/xorg.conf from another VM where it was generated using the VMware's driver in 8.x; it works just fine there in 9-CURRENT with the x11-drivers/xf86-video-vmware driver in high res 1920x1200 and cutpaste between the VM's and Win apps. Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] ifconfig(8) flag to display IPv4 netmasks in dot-decimal format
On Mon, Apr 11, 2011 at 04:11:27PM +0400, Sergey Vinogradov wrote: Hi, I've written a tiny-tiny patch, which adds the '-t' flag to ifconfig(8). It modifies the output to display IPv4 netmasks in dotted decimal notation: Sorry but as much as I would like to see this happen and change the display of the netmask I just cannot seem to come to a genuine consensus that justifies adding a '-t' flag or any flag for that matter just to modify the output of one field in the display of ifconfig(8) In general flags to programs usually should carry some sort of meaning to what they are meant to do and I dont really see that for '-t' and netmask display. What I feel would be a better approach to this is checking the environ(7) for some sort of variable that can be specified on a per-user basis or the system as a whole. As to what that variable would be called I could only suggest in a naming convention to be ``HUMANIZE'' or something similiar and then ifconfig(8) could be the first consumer of that variable and probably shortly following du(1) df(1). This variable could also be one that acts as BLOCKSIZE does to df(1) output and also be available for consumption by other utilities that may need fine tuning without breaking existing interfaces. /STRONG-OPINION -- Regards, J. Hellenthal pgphAtxdZ2IbB.pgp Description: PGP signature
Re: Any success stories for HAST + ZFS?
Everything is detected correctly, everything comes up correctly. See a new option (reload) in the RC script for hast. success story snipped same here - have patched the master databse achines, all came up fine, everything running erfectly, have flip-flopped between the two machines with no ill effects whatsoever, and all looking very good. cheers, -pete. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] ifconfig(8) flag to display IPv4 netmasks in dot-decimal format
Sergey Vinogradov boo...@lazybytes.org writes: Hi, I've written a tiny-tiny patch, which adds the '-t' flag to ifconfig(8). It modifies the output to display IPv4 netmasks in dotted decimal notation: [...] % ifconfig -t msk0 [...] inet 10.10.0.1 netmask 255.255.255.0 broadcast 10.10.0.255 Isn't netstat(8) a better place for such an option? domask() already converts netmask to CIDR notation if possible, e.g. `netstat -ni' 10.10.0.1/24 10.10.0.10xff00ff00 Unfortunately, Network column is always truncated to 13 characters even with -W flag while it can be up to 26 characters long with `-n' flag or more with a symbolic network name. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
background fsck high load on 8.1
Hello, we've experienced that background fsck on 8.1 degrades server performance on a higher degree than in previous fbsd versions (6.3, 7.3; amd64). We've noticed it after upgrading - same hardware - to a 8.1-RELEASE. Now, performance of other services (i.e. apache, mysql) during a background fsck falls miserably. Is there any way to calm fsck down?, nice(1)?, some sysctl? We have also gmirror, but we prevent to rebuild it if there is a fsck running in background. Thanks for your help, regards, Sergi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT]RT28xx/RT30xx wireless was [CFR]RT305xF support, w/o attachment
On 31 March 2011 16:50, Sevan / Venture37 ventur...@gmail.com wrote: On 31 March 2011 10:07, Aleksandr Rybalko r...@dlink.ua wrote: Now good peoples help me with rework of driver, then this driver will be available under ral(4). So you need to wait some time. Excellent, I'm happy to be a tester for patches, the card is a Azurewave RT2700E out of a EEPC if I remember right AzureWave AW-NE766-VOA to be exact Model No: RT2700E I will post dmesg pciconf output tomorrow once I have an ethernet cable or removable media near me if you need more info. Yeah, post please. at minimum I've interesting which RF used in your device. rt28600: Ralink RT2790 PCIe mem 0xf7f0-0xf7f0 irq 17 at device 0.0 on pci3 rt28600: invalid EEPROM LNA gain #2: 0x00 rt28600: invalid EEPROM LNA gain #3: 0x00 rt28600: invalid EEPROM powersave level rt28600: MAC/BBP RT2860 (rev 0x28720200), RF RT3022 2.4G 2T2R rt28600: skip channel 10, could not find extension channel rt28600: skip channel 11, could not find extension channel rt28600: skip channel 12, could not find extension channel rt28600: skip channel 13, could not find extension channel rt28600: skip channel 14, could not find extension channel rt28600@pci0:3:0:0: class=0x028000 card=0x27901814 chip=0x07811814 rev=0x00 hdr=0x00 vendor = 'Ralink Technology, Corp.' device = 'Wireless (RT2860/RT2890)' class = network Sevan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
make release
I am trying to make a release with the following arguments: make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES however /usr/home/current is being ignored completely and everything ends up in /usr/obj/usr/src. Am I doing something wrong ? Thanks -- George Kontostanos aisecure.net http://www.aisecure.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release
On 12/04/2011, at 17:02, George Kontostanos wrote: I am trying to make a release with the following arguments: make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES however /usr/home/current is being ignored completely and everything ends up in /usr/obj/usr/src. Am I doing something wrong ? I found this too, I think it's the new way. (I think the makefile still mentions CHROOTDIR though.. not sure if it does anything with it or not though) -- 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release
On 04/12/11 10:02, George Kontostanos wrote: I am trying to make a release with the following arguments: make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES however /usr/home/current is being ignored completely and everything ends up in /usr/obj/usr/src. Am I doing something wrong ? Following switching the default installer away from sysinstall, make release works differently now (see release(7), which has been updated to reflect the new release-building process). The closest analog to the command above (though you may want to do something different) is: cd /usr/src/release ./generate-release.sh head /usr/home/current -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release
Sorry I didn't read the man pages lately!
releaseMeta-target to build all release media and distributions
applicable to this platform. All output goes to
${.OBJDIR}, which will likely be either src/release or
the
equivalent path in /usr/obj.
The following sequence of commands can be used to build a ``-CURRENT
snapshot'' in a clean environment, including ports and documentation:
cd /usr/src
make buildworld
cd release
export CVSUP_HOST=cvsupN.freebsd.org
sh generate-release.sh head /local3/release
On Tue, Apr 12, 2011 at 6:14 PM, Nathan Whitehorn nwhiteh...@freebsd.orgwrote:
On 04/12/11 10:02, George Kontostanos wrote:
I am trying to make a release with the following arguments:
make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT
EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES
however /usr/home/current is being ignored completely and everything ends
up
in /usr/obj/usr/src. Am I doing something wrong ?
Following switching the default installer away from sysinstall, make
release works differently now (see release(7), which has been updated to
reflect the new release-building process). The closest analog to the command
above (though you may want to do something different) is:
cd /usr/src/release
./generate-release.sh head /usr/home/current
-Nathan
--
George Kontostanos
aisecure.net http://www.aisecure.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [regression] unable to boot: no GEOM devices found.
On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: David Naylor wrote: I am running -current and since a few days ago (at least 2011/04/11) I am unable to boot. The boot process stops when it looks to find a bootable device. The prompt (when pressing '?') does not display any device and yielding one second (or more) to the kernel (by pressing '.') does not improve the situation. A known working date is 2011/02/20. I am running amd64 on a nVidia MCP51 chipset. MCP51... again... I am willing to help any way I can. You could start from capturing and showing verbose dmesg. Full or at least in parts related to disks. I captured the dmesg output for both the old (working) kernel and the new (bad) kernel. See attached for the difference between the two. If you need the full dmesg please let me know. One thing I found is that the old kernel would not boot if I simply rebooted from the bad kernel. I had to do a hard power off before the old kernel would work again. Is some device state surviving between reboots? Regards, David --- dmesg.old 2011-04-12 21:26:44.0 +0200 +++ dmesg.new 2011-04-12 21:24:12.0 +0200 @@ -16,17 +16,17 @@ APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) -MADT: Found CPU APIC ID 3 ACPI ID 1: enabled -SMP: Added CPU 3 (AP) -MADT: Found CPU APIC ID 1 ACPI ID 2: enabled +MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) +MADT: Found CPU APIC ID 3 ACPI ID 2: enabled +SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 2 ACPI ID 3: enabled SMP: Added CPU 2 (AP) Copyright (c) 1992-2011 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 9.0-CURRENT #0: Mon Mar 7 17:47:26 SAST 2011 +FreeBSD 9.0-CURRENT #0: Tue Apr 12 21:09:23 SAST 2011 r...@dragon.dg:/tmp/home/freebsd9/src/sys/DRAGON amd64 Table 'FACP' at 0xcfff30c0 Table 'HPET' at 0xcfff7940 @@ -35,25 +35,24 @@ Table 'SSDT' at 0xcfff7a40 Table 'SSDT' at 0xcfff7ff0 ACPI: No SRAT table found -Preloaded elf kernel /boot/dragon/kernel at 0x819ce000. -Preloaded elf obj module /boot/modules/cuse4bsd.ko at 0x819ce1d0. -Preloaded elf obj module /boot/dragon/geom_sched.ko at 0x819ce7c0. -Preloaded elf obj module /boot/dragon/gsched_rr.ko at 0x819cee70. -Preloaded elf obj module /boot/modules/nvidia.ko at 0x819cf3e0. -Calibrating TSC clock ... TSC clock: 2400024582 Hz -CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2400.02-MHz K8-class CPU) +Preloaded elf kernel /boot/kernel/kernel at 0x81a01000. +Preloaded elf obj module /boot/modules/cuse4bsd.ko at 0x81a011d0. +Preloaded elf obj module /boot/kernel/geom_sched.ko at 0x81a017c0. +Preloaded elf obj module /boot/kernel/gsched_rr.ko at 0x81a01e70. +Preloaded elf obj module /boot/modules/nvidia.ko at 0x81a023e0. +CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (K8-class CPU) Origin = GenuineIntel Id = 0x6f7 Family = 6 Model = f Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF - TSC: P-state invariant real memory = 6442450944 (6144 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) -0x01a01000 - 0xc34d3fff, 3249352704 bytes (793299 pages) +0x0010 - 0x001f, 1048576 bytes (256 pages) +0x01a34000 - 0xc34d3fff, 3249143808 bytes (793248 pages) 0x0001 - 0x0001affe, 2952724480 bytes (720880 pages) -avail memory = 6161305600 (5875 MB) +avail memory = 6162554880 (5877 MB) Event timer LAPIC quality 400 ACPI APIC Table: GBTNVDAACPI INTR: Adding local APIC 1 as a target @@ -65,14 +64,14 @@ cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 +APIC: CPU 0 has ACPI ID 0 +APIC: CPU 1 has ACPI ID 1 +APIC: CPU 2 has ACPI ID 3 +APIC: CPU 3 has ACPI ID 2 x86bios: IVT 0x00-0x0004ff at 0xfe00 x86bios: SSEG 0x001000-0x001fff at 0xff82a000 x86bios: EBDA 0x09f000-0x09 at 0xfe09f000 x86bios: ROM 0x0a-0x0fefff at 0xfe0a -APIC: CPU 0 has ACPI ID 0 -APIC: CPU 1 has ACPI ID 2 -APIC: CPU 2 has ACPI ID 3 -APIC: CPU 3 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 @@ -99,12 +98,12 @@ lapic0: Routing NMI - LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high -lapic3: Routing NMI - LINT1 -lapic3: LINT1 trigger: edge -lapic3: LINT1 polarity: high lapic1: Routing NMI - LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1
Re: [regression] unable to boot: no GEOM devices found.
David Naylor wrote: On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: David Naylor wrote: I am running -current and since a few days ago (at least 2011/04/11) I am unable to boot. The boot process stops when it looks to find a bootable device. The prompt (when pressing '?') does not display any device and yielding one second (or more) to the kernel (by pressing '.') does not improve the situation. A known working date is 2011/02/20. I am running amd64 on a nVidia MCP51 chipset. MCP51... again... I am willing to help any way I can. You could start from capturing and showing verbose dmesg. Full or at least in parts related to disks. I captured the dmesg output for both the old (working) kernel and the new (bad) kernel. See attached for the difference between the two. If you need the full dmesg please let me know. One thing I found is that the old kernel would not boot if I simply rebooted from the bad kernel. I had to do a hard power off before the old kernel would work again. Is some device state surviving between reboots? +ata2: reiniting channel .. +ata2: SATA connect time=0ms status=0113 +ata2: reset tp1 mask=01 ostat0=58 ostat1=00 +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 +ata2: reset tp2 stat0=50 stat1=00 devices=0x1 +ata2: reinit done .. +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 As soon as all devices detected but not responding to commands, I would suppose that there is something wrong with ATA interrupts. There is a long chain of interrupt problems in this chipset. I have already tried to debug one case where ATA wasn't generating interrupts at all. Unfortunately, without success -- requests were executing, but not generating interrupts, it wasn't looked like ATA driver problem. What's about possible candidate to revision triggering your problem, I would look on this message: +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and it is interrupt related. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
On Mon Apr 11 11, Kenneth D. Merry wrote: On Thu, Apr 07, 2011 at 13:59:35 +0300, Alexander Motin wrote: Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... funny thing is i found the following in scsi_pass.c: softc-device_stats = devstat_new_entry(pass, periph-unit_number, 0, DEVSTAT_NO_BLOCKSIZE | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), softc-pd_type | DEVSTAT_TYPE_IF_SCSI | DEVSTAT_TYPE_PASS, DEVSTAT_PRIORITY_PASS); ...so pass* *should* show up under iostat -t scsi. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. Hmm, pass devices for adaX should not be SCSI though, they should be ide I think. i think the situation with ATA_CAM should be discussed further. still besides this issue there are many more with devstat(3). i'll try to track all the devstat_new_entry() occurrences and see if some issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch i just tried again with ATA_CAM and the patch works perfectly. iostat -t scsi doesn't show any devices and iostat -t ide shows all my ata/sata devices in addition to pass* under iostat -t pass and md* under iostat -t other. +1 for committing it. :) cheers. alex Any objections? Or SCSI/IDE there expected to mean command set? For what it's worth, I think the above patch is the right approach. The device type stuff in devstat has been broken since GEOM went in, so I'm glad to see you step up to fix it! Ken -- Kenneth Merry k...@freebsd.org -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [regression] unable to boot: no GEOM devices found.
YongHyeon PYUN wrote: On Tue, Apr 12, 2011 at 11:12:55PM +0300, Alexander Motin wrote: David Naylor wrote: On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: David Naylor wrote: I am running -current and since a few days ago (at least 2011/04/11) I am unable to boot. The boot process stops when it looks to find a bootable device. The prompt (when pressing '?') does not display any device and yielding one second (or more) to the kernel (by pressing '.') does not improve the situation. A known working date is 2011/02/20. I am running amd64 on a nVidia MCP51 chipset. MCP51... again... I am willing to help any way I can. You could start from capturing and showing verbose dmesg. Full or at least in parts related to disks. I captured the dmesg output for both the old (working) kernel and the new (bad) kernel. See attached for the difference between the two. If you need the full dmesg please let me know. One thing I found is that the old kernel would not boot if I simply rebooted from the bad kernel. I had to do a hard power off before the old kernel would work again. Is some device state surviving between reboots? +ata2: reiniting channel .. +ata2: SATA connect time=0ms status=0113 +ata2: reset tp1 mask=01 ostat0=58 ostat1=00 +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 +ata2: reset tp2 stat0=50 stat1=00 devices=0x1 +ata2: reinit done .. +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 As soon as all devices detected but not responding to commands, I would suppose that there is something wrong with ATA interrupts. There is a long chain of interrupt problems in this chipset. I have already tried to debug one case where ATA wasn't generating interrupts at all. Unfortunately, without success -- requests were executing, but not generating interrupts, it wasn't looked like ATA driver problem. What's about possible candidate to revision triggering your problem, I would look on this message: +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and it is interrupt related. Does the driver disable MSI for MCP51? ata(4) doesn't uses MSI by default and I doubt this controller supports them any way. But if I am not mixing something, there were very strange situations with MSI on that chipset, when enabling them one one device caused interrupt problems on another. I think jhb's patch fixed one MSI issue of all MCP chipset. I am not telling it is wrong. It could just trigger something. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [regression] unable to boot: no GEOM devices found.
On Tue, Apr 12, 2011 at 11:12:55PM +0300, Alexander Motin wrote: David Naylor wrote: On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: David Naylor wrote: I am running -current and since a few days ago (at least 2011/04/11) I am unable to boot. The boot process stops when it looks to find a bootable device. The prompt (when pressing '?') does not display any device and yielding one second (or more) to the kernel (by pressing '.') does not improve the situation. A known working date is 2011/02/20. I am running amd64 on a nVidia MCP51 chipset. MCP51... again... I am willing to help any way I can. You could start from capturing and showing verbose dmesg. Full or at least in parts related to disks. I captured the dmesg output for both the old (working) kernel and the new (bad) kernel. See attached for the difference between the two. If you need the full dmesg please let me know. One thing I found is that the old kernel would not boot if I simply rebooted from the bad kernel. I had to do a hard power off before the old kernel would work again. Is some device state surviving between reboots? +ata2: reiniting channel .. +ata2: SATA connect time=0ms status=0113 +ata2: reset tp1 mask=01 ostat0=58 ostat1=00 +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 +ata2: reset tp2 stat0=50 stat1=00 devices=0x1 +ata2: reinit done .. +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 As soon as all devices detected but not responding to commands, I would suppose that there is something wrong with ATA interrupts. There is a long chain of interrupt problems in this chipset. I have already tried to debug one case where ATA wasn't generating interrupts at all. Unfortunately, without success -- requests were executing, but not generating interrupts, it wasn't looked like ATA driver problem. What's about possible candidate to revision triggering your problem, I would look on this message: +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and it is interrupt related. Does the driver disable MSI for MCP51? I think jhb's patch fixed one MSI issue of all MCP chipset. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [regression] unable to boot: no GEOM devices found.
On Tue, Apr 12, 2011 at 2:08 PM, Alexander Motin m...@freebsd.org wrote: YongHyeon PYUN wrote: On Tue, Apr 12, 2011 at 11:12:55PM +0300, Alexander Motin wrote: David Naylor wrote: On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: David Naylor wrote: I am running -current and since a few days ago (at least 2011/04/11) I am unable to boot. The boot process stops when it looks to find a bootable device. The prompt (when pressing '?') does not display any device and yielding one second (or more) to the kernel (by pressing '.') does not improve the situation. A known working date is 2011/02/20. I am running amd64 on a nVidia MCP51 chipset. MCP51... again... I am willing to help any way I can. You could start from capturing and showing verbose dmesg. Full or at least in parts related to disks. I captured the dmesg output for both the old (working) kernel and the new (bad) kernel. See attached for the difference between the two. If you need the full dmesg please let me know. One thing I found is that the old kernel would not boot if I simply rebooted from the bad kernel. I had to do a hard power off before the old kernel would work again. Is some device state surviving between reboots? +ata2: reiniting channel .. +ata2: SATA connect time=0ms status=0113 +ata2: reset tp1 mask=01 ostat0=58 ostat1=00 +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 +ata2: reset tp2 stat0=50 stat1=00 devices=0x1 +ata2: reinit done .. +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 As soon as all devices detected but not responding to commands, I would suppose that there is something wrong with ATA interrupts. There is a long chain of interrupt problems in this chipset. I have already tried to debug one case where ATA wasn't generating interrupts at all. Unfortunately, without success -- requests were executing, but not generating interrupts, it wasn't looked like ATA driver problem. What's about possible candidate to revision triggering your problem, I would look on this message: +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and it is interrupt related. Does the driver disable MSI for MCP51? ata(4) doesn't uses MSI by default and I doubt this controller supports them any way. But if I am not mixing something, there were very strange situations with MSI on that chipset, when enabling them one one device caused interrupt problems on another. I think jhb's patch fixed one MSI issue of all MCP chipset. I am not telling it is wrong. It could just trigger something. Could the OP try disabling MSI[X] to see whether or not the issue still occurs then? -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: use_generic and usb probing
Well, I think that that's what probe priorities actually for. I also think that typically ivars should be set by a bus driver. So maybe it's not such a good idea to pass data from probe to attach via ivars in child drivers. But I could be mistaken about that. Practically speaking, you most likely don't have to worry about that for drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And there is only a few generic drivers that can be handled on a case by case basis. Newbus priorities where specifically implemented on my request by Doug Rabson to cater for fallback attachments: usb.h (the old code) contained a list of priorities. ugen had the lowest priority and attached if no one else did. An example was a keyboard with a built-in mouse on one interface. It would be attached by either mouse or keyboard but not both. An additional driver could probide both devices. We ended up implementing that differently though: attachment to interfaces instead of devices. A probe should not pass any information to the attach phase if it can at all avoid it. Or at least that is the assumption. If a driver needs info in both phases, it needs to regenerate it again. The fact that usb_probe is called again is a kludge, specifically for the description. I guess that documenting this kludge and updating the comment to state this fact would be sufficient to solve the problem. Nick___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [regression] unable to boot: no GEOM devices found.
On Tuesday 12 April 2011 23:39:30 Garrett Cooper wrote: On Tue, Apr 12, 2011 at 2:08 PM, Alexander Motin m...@freebsd.org wrote: YongHyeon PYUN wrote: On Tue, Apr 12, 2011 at 11:12:55PM +0300, Alexander Motin wrote: David Naylor wrote: On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: David Naylor wrote: I am running -current and since a few days ago (at least 2011/04/11) I am unable to boot. The boot process stops when it looks to find a bootable device. The prompt (when pressing '?') does not display any device and yielding one second (or more) to the kernel (by pressing '.') does not improve the situation. A known working date is 2011/02/20. I am running amd64 on a nVidia MCP51 chipset. MCP51... again... I am willing to help any way I can. You could start from capturing and showing verbose dmesg. Full or at least in parts related to disks. I captured the dmesg output for both the old (working) kernel and the new (bad) kernel. See attached for the difference between the two. If you need the full dmesg please let me know. One thing I found is that the old kernel would not boot if I simply rebooted from the bad kernel. I had to do a hard power off before the old kernel would work again. Is some device state surviving between reboots? +ata2: reiniting channel .. +ata2: SATA connect time=0ms status=0113 +ata2: reset tp1 mask=01 ostat0=58 ostat1=00 +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 +ata2: reset tp2 stat0=50 stat1=00 devices=0x1 +ata2: reinit done .. +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 As soon as all devices detected but not responding to commands, I would suppose that there is something wrong with ATA interrupts. There is a long chain of interrupt problems in this chipset. I have already tried to debug one case where ATA wasn't generating interrupts at all. Unfortunately, without success -- requests were executing, but not generating interrupts, it wasn't looked like ATA driver problem. What's about possible candidate to revision triggering your problem, I would look on this message: +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and it is interrupt related. Does the driver disable MSI for MCP51? ata(4) doesn't uses MSI by default and I doubt this controller supports them any way. But if I am not mixing something, there were very strange situations with MSI on that chipset, when enabling them one one device caused interrupt problems on another. I think jhb's patch fixed one MSI issue of all MCP chipset. I am not telling it is wrong. It could just trigger something. Could the OP try disabling MSI[X] to see whether or not the issue still occurs then? -Garrett I added: hw.pci.enable_msi=0 hw.pci.enable_msix=0 to loader.conf but the problem persisted. @mav: I will revert r219737 and r219740 and try again but this will be in +10 hours... Thanks signature.asc Description: This is a digitally signed message part.
