Re: Kernel symbol file alternate location
Daniel O'Connor wrote: On 06/08/2010, at 2:38, Oliver Fromme wrote: I think this is the main reason / has had to grow - the actual kernel is relatively small so even a 256Mb / could hold several, but with the symbol files it is not possible. I think a very simple solution would be to install the symbol files elsewhere (probably configurable via make.conf), and install symlinks in the kernel directory. If you do this, tools using the symbol files won't have to be changed. This would probably be a fairly trivial change to the install- kernel target, I guess. I don't have patches, though. Yeah, I don't think it's hard to move them, however I'm worried what it will break :) The only thing I can see that would have to change would be kgdb so it tells gdb where to find the symbols. That's why I suggested to place symlinks in the kernel directory. No change to kgdb necessary. It might even be possible to not install the symbol files at all, but keep them under /usr/obj, so the installkernel target would have to do nothing more than create symlinks. This could be controlled by a make.conf variable, like SYMLINK_SYMBOLS=YES (NO would be the existing behaviour of installing the actual symbol files in /boot/kernel). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn ___ 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: Kernel symbol file alternate location
On 06/08/2010, at 16:59, Oliver Fromme wrote: Yeah, I don't think it's hard to move them, however I'm worried what it will break :) The only thing I can see that would have to change would be kgdb so it tells gdb where to find the symbols. That's why I suggested to place symlinks in the kernel directory. No change to kgdb necessary. Ahh of course. Although that does make it harder because you have to modify all the links when the old kernel is moved out of the way. It might even be possible to not install the symbol files at all, but keep them under /usr/obj, so the installkernel target would have to do nothing more than create symlinks. This could be controlled by a make.conf variable, like SYMLINK_SYMBOLS=YES (NO would be the existing behaviour of installing the actual symbol files in /boot/kernel). Hmm, I think they would need to go elsewhere otherwise they wouldn't be available to people who do binary installs, hence the usefulness of bug reports would go down. -- 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
Re: Kernel symbol file alternate location
Daniel O'Connor wrote: On 06/08/2010, at 16:59, Oliver Fromme wrote: Yeah, I don't think it's hard to move them, however I'm worried what it will break :) The only thing I can see that would have to change would be kgdb so it tells gdb where to find the symbols. That's why I suggested to place symlinks in the kernel directory. No change to kgdb necessary. Ahh of course. Although that does make it harder because you have to modify all the links when the old kernel is moved out of the way. Right. Maybe make a symlink to a directory, so only that symlink has to be changed: /boot/kernel/symbols - /var/db/symbols/kernel /boot/kernel/kernel.symbols - symbols/kernel.symbols /boot/kernel/acpi.symbols - symbols/acpi.symbols .. and so on. When the kernel is rotated to kernel.old, only one symlink has to be changed: /boot/kernel.old/symbols - /var/db/symbols/kernel.old Of course, /var/db is just an example off the top of my head. The symbols directory should be configurable via make.conf, too. It might even be possible to not install the symbol files at all, but keep them under /usr/obj, so the installkernel target would have to do nothing more than create symlinks. This could be controlled by a make.conf variable, like SYMLINK_SYMBOLS=YES (NO would be the existing behaviour of installing the actual symbol files in /boot/kernel). Hmm, I think they would need to go elsewhere otherwise they wouldn't be available to people who do binary installs, hence the usefulness of bug reports would go down. Right, I was thinking of developers only, who usually have a populated /usr/obj directory ... But there's a world full of non-developers, too. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper. -- Ralf Hildebrandt ___ 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: Where's the space? raidz2
On Mon, Aug 2, 2010 at 4:27 PM, Dan Langille d...@langille.org wrote: On 8/2/2010 7:11 PM, Dan Langille wrote: I recently altered an existing raidz2 pool from using 7 vdevs of about 931G to 1.81TB. In fact, the existing pool used half of each HDD. I then wanted to go to using [almost] all of each HDD. I offline'd each vdev, adjusted the HDD paritions using gpart, then replaced the vdev. After letting the resilver occur, I did the next vdev. The space available after this process did not go up as I expected. I have about 4TB in the pool, not the 8 or 9TB I expected. This fixed it: # zpool export storage # zpool import storage There's a version of ZFS includes a new *autoexpand* property that could be set on the pool. With that set, the available space will be made available automatically as soon as the last disk in a vdev is replaced. I don't know the exact version or whether it's supported in FreeBSD's port of ZFS. But it will be available at some point. :) -- Freddie Cash fjwc...@gmail.com ___ 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: Kernel symbol file alternate location
On Fri, Aug 06, 2010 at 09:29:31AM +0200, Oliver Fromme wrote: Daniel O'Connor wrote: On 06/08/2010, at 2:38, Oliver Fromme wrote: I think this is the main reason / has had to grow - the actual kernel is relatively small so even a 256Mb / could hold several, but with the symbol files it is not possible. I think a very simple solution would be to install the symbol files elsewhere (probably configurable via make.conf), and install symlinks in the kernel directory. If you do this, tools using the symbol files won't have to be changed. This would probably be a fairly trivial change to the install- kernel target, I guess. I don't have patches, though. Yeah, I don't think it's hard to move them, however I'm worried what it will break :) The only thing I can see that would have to change would be kgdb so it tells gdb where to find the symbols. That's why I suggested to place symlinks in the kernel directory. No change to kgdb necessary. It might even be possible to not install the symbol files at all, but keep them under /usr/obj, so the installkernel target would have to do nothing more than create symlinks. This could be controlled by a make.conf variable, like SYMLINK_SYMBOLS=YES (NO would be the existing behaviour of installing the actual symbol files in /boot/kernel). If you keep /usr/obj around, you do not need symbol files at all, and INSTALL_NODEBUG?=true in make.conf is enough. You can always use kernel.debug and modules with debugging symbols from build directory for kgdb. pgpaoijv6x887.pgp Description: PGP signature
Re: Kernel symbol file alternate location
Kostik Belousov kostik...@gmail.com wrote: If you keep /usr/obj around, you do not need symbol files at all, and INSTALL_NODEBUG?=true in make.conf is enough. You can always use kernel.debug and modules with debugging symbols from build directory for kgdb. OK ... But that won't work for /boot/kernel.old. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a God to make them do anything useful. ___ 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: Where's the space? raidz2
It's in V16 afaik On Fri, Aug 6, 2010 at 11:36 AM, Freddie Cash fjwc...@gmail.com wrote: On Mon, Aug 2, 2010 at 4:27 PM, Dan Langille d...@langille.org wrote: On 8/2/2010 7:11 PM, Dan Langille wrote: I recently altered an existing raidz2 pool from using 7 vdevs of about 931G to 1.81TB. In fact, the existing pool used half of each HDD. I then wanted to go to using [almost] all of each HDD. I offline'd each vdev, adjusted the HDD paritions using gpart, then replaced the vdev. After letting the resilver occur, I did the next vdev. The space available after this process did not go up as I expected. I have about 4TB in the pool, not the 8 or 9TB I expected. This fixed it: # zpool export storage # zpool import storage There's a version of ZFS includes a new *autoexpand* property that could be set on the pool. With that set, the available space will be made available automatically as soon as the last disk in a vdev is replaced. I don't know the exact version or whether it's supported in FreeBSD's port of ZFS. But it will be available at some point. :) -- Freddie Cash fjwc...@gmail.com ___ 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 ___ 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
Watchdog resets on 82575
If you have this adapter and have been getting watchdogs you need to pick up the small update I checked into HEAD today. When I added the SR-IOV support for the 82576 adapter I removed a call to set the MAC type in an early routine, thinking it was unnecessary, since a slightly later shared code init does the same thing. I also saw no problem when I did this on the 82576 well, it did have a bad effect that I did not notice, the slightly later call, igb_setup_msix() did not have the mac set and this resulted in the 82575 creating more queues than it is really able to handle. So, bottom line, this is a critical fix for 82575: SVN rev 210968 Cheers, Jack ___ 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
Dumpdev issue in 6.4-STABLE
Hello Stable I have an issue with a kernel panic on bootup where the dumpdev loader variable is ignored. I rebuilt my 6.4-STABLE amd64 kernel with the following options to try an track down an issue with a patch. options KDB options DDB options GDB options BREAK_TO_DEBUGGER options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_VFS_LOCK I then built and installed the resulting kernel.debug no issues there I then set in /boot/loader.conf dumpdev=/dev/da0s1b When I reboot and crash the box on the new kernel at the db prompt I cant call doadump to work or get an automated one from continue both complain about no dumpdev defined . Does anyone have a solution for this ? -- Mark Saad mark.s...@ymail.com ___ 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: Dumpdev issue in 6.4-STABLE
On 08/06/2010 02:24 PM, Mark Saad wrote: I then set in /boot/loader.conf dumpdev=/dev/da0s1b On 8-STABLE dumpdev should be defined in rc.conf(5). Not sure about 6-STABLE offhand. -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
Re: Dumpdev issue in 6.4-STABLE
wrote: I then set in /boot/loader.conf dumpdev=/dev/da0s1b On 8-STABLE dumpdev should be defined in rc.conf(5). Not sure about 6-STABLE offhand. The box dies before init is started so dumpdev in rc.conf is pointless. -- Benjamin Lee http://www.b1c1l1.com/ -- Mark Saad mark.s...@ymail.com ___ 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: Dumpdev issue in 6.4-STABLE
Mark Saad wrote: wrote: I then set in /boot/loader.conf dumpdev=/dev/da0s1b On 8-STABLE dumpdev should be defined in rc.conf(5). Not sure about 6-STABLE offhand. The box dies before init is started so dumpdev in rc.conf is pointless. I'm afraid you can't set dumpdev from the loader. In ancient times it was possible to hardcode the dumpdev via the kernel configuration, but that option is long gone, AFAIK. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'. -- Oddbjorn Steffensen ___ 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: Dumpdev issue in 6.4-STABLE
Mark Saad wrote: wrote: I then set in /boot/loader.conf dumpdev=/dev/da0s1b On 8-STABLE dumpdev should be defined in rc.conf(5). Not sure about 6-STABLE offhand. The box dies before init is started so dumpdev in rc.conf is pointless. I'm afraid you can't set dumpdev from the loader. In ancient times it was possible to hardcode the dumpdev via the kernel configuration, but that option is long gone, AFAIK. Oliver so how do I get a core file of what the kernel is doing ? What is the new way of doing this ? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'. -- Oddbjorn Steffensen -- Mark Saad mark.s...@ymail.com ___ 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: Dumpdev issue in 6.4-STABLE
Mark, Perhaps remote GDB via serial console... http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-gdb.html This explain it in very good detail. ~Paul On Fri, Aug 06, 2010 at 06:37:37PM -0400, Mark Saad wrote: Mark Saad wrote: wrote: I then set in /boot/loader.conf dumpdev=/dev/da0s1b On 8-STABLE dumpdev should be defined in rc.conf(5).? Not sure about 6-STABLE offhand. The box dies before init is started so dumpdev in rc.conf is pointless. I'm afraid you can't set dumpdev from the loader. In ancient times it was possible to hardcode the dumpdev via the kernel configuration, but that option is long gone, AFAIK. Oliver so how do I get a core file of what the kernel is doing ? What is the new way of doing this ? Best regards ???Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606,? Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758,? Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr:? http://www.secnetix.de/bsd I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'. ? ? ? ? -- Oddbjorn Steffensen -- Mark Saad mark.s...@ymail.com ___ 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 This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: Dumpdev issue in 6.4-STABLE
On Fri, Aug 06, 2010 at 03:37:37PM -0700, Mark Saad wrote: Mark Saad wrote: wrote: I then set in /boot/loader.conf dumpdev=/dev/da0s1b On 8-STABLE dumpdev should be defined in rc.conf(5). Not sure about 6-STABLE offhand. The box dies before init is started so dumpdev in rc.conf is pointless. I'm afraid you can't set dumpdev from the loader. In ancient times it was possible to hardcode the dumpdev via the kernel configuration, but that option is long gone, AFAIK. Oliver so how do I get a core file of what the kernel is doing ? What is the new way of doing this ? Use of dumpdev in /etc/rc.conf is utilised by /etc/rc.d/dumpon. This rc script runs /sbin/dumpon, specifying the device, which tells the kernel what device to dump stuff to using an ioctl() call for DIOCSKERNELDUMP. There doesn't appear to be a way to make an ioctl call from within DDB. I would say you're basically out of luck; someone on freebsd-hackers may know of a secret way. Otherwise I would say DDB needs to be extended to provide a dumpdev command or something along those lines which would do the ioctl() equivalent. You can drop to DDB interactively by pressing Control-Alt-Escape. You can examine the system state from there, but even call doadump probably won't work given that the kernel doesn't know what dump device to use (re: the ioctl() call above). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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
8-STABLE Slow Write Speeds on ESXI 4.0
Hello, I'm experiencing slow write speeds on 8-STABLE running on an ESXI 4.0 server, despite whatever tunables I've thrown at it. Read speeds are slower than they should be, but acceptable. Note, this is a thick provisioned disk, not thin. Speeds on Windows hosts are as expected for an MD3000 DAS, 250MB/s or so. [r...@git ~]# dd if=/dev/da0 of=/dev/null bs=1M count=500 500+0 records in 500+0 records out 524288000 bytes transferred in 3.304514 secs (158658118 bytes/sec [r...@git ~]# dd if=/dev/zero of=/var/testfile bs=1M count=500 500+0 records in 500+0 records out 524288000 bytes transferred in 52.083421 secs (10066313 bytes/sec) Output of gstat during write: L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 6 82 0 00.0 82 10520 82.5 100.7| da0 [r...@git ~]# vmstat da0 2 procs memory page disk faults cpu r b w avmfre flt re pi pofr sr da0 in sy cs us sy id 0 0 0664M 3684M28 0 0 059 0 04 90 347 0 2 98 0 0 0664M 3667M 1 0 0 044 0 149 152 120 1340 0 3 97 0 0 0664M 3646M 0 0 0 0 0 0 163 166 123 1385 0 2 98 0 0 0664M 3626M 0 0 0 0 0 0 160 162 119 1393 0 4 96 0 0 0664M 3605M 1 0 0 0 1 0 164 165 156 1435 0 4 96 [r...@git ~]# camcontrol tags da0 (pass0:mpt0:0:0:0): device openings: 127 [r...@git ~]# camcontrol devlist VMware Virtual disk 1.0 at scbus0 target 0 lun 0 (da0,pass0) And now, for the rest of the information: [r...@git ~]# uname -ar FreeBSD git.openfisma.org 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Mon Jun 28 17:46:33 EDT 2010 r...@git.openfisma.org:/usr/obj/usr/src/sys/GENERIC amd64 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 8.1-PRERELEASE #0: Mon Jun 28 17:46:33 EDT 2010 r...@git.openfisma.org:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Quad-Core AMD Opteron(tm) Processor 2350 (1999.81-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f23 Family = 10 Model = 2 Stepping = 3 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x80802001SSE3,CX16,POPCNT,b31 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x1e9LAHF,ExtAPIC,ABM,SSE4A,MAS,Prefetch TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4099297280 (3909 MB) ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 4 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: INTEL 440BX on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x10c0-0x10cf at device 7.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] pci0: bridge at device 7.3 (no driver attached) pci0: base peripheral at device 7.7 (no driver attached) vgapci0: VGA-compatible display port 0x10d0-0x10df mem 0xd400-0xd7ff,0xd800-0xd87f irq 16 at device 15.0 on pci0 pcib2: ACPI PCI-PCI bridge at device 17.0 on pci0 pci2: ACPI PCI bus on pcib2 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f mem 0xd882-0xd883,0xd880-0xd880 irq 18 at device 0.0 on pci2 em0: Memory Access and/or Bus Master bits were not set! em0: [FILTER] em0: Ethernet address: 00:50:56:81:3c:c8 pcib3: ACPI PCI-PCI bridge at device 21.0 on pci0 pci3: ACPI PCI bus on pcib3 mpt0: LSILogic SAS/SATA Adapter port 0x4000-0x40ff mem 0xd9c04000-0xd9c07fff,0xd9c1-0xd9c1 irq 18 at device 0.0 on pci3 mpt0: [ITHREAD] mpt0: MPI Version=1.5.0.0 pcib4: ACPI PCI-PCI bridge at device 21.1 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 21.2 on pci0 pci5: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 21.3 on pci0 pci6: ACPI PCI bus on pcib6 pcib7: ACPI PCI-PCI bridge at device 21.4 on pci0 pci7: ACPI PCI bus on pcib7 pcib8: ACPI PCI-PCI bridge at device 21.5 on pci0
Re: Kernel symbol file alternate location
On 06/08/2010, at 17:45, Oliver Fromme wrote: Daniel O'Connor wrote: On 06/08/2010, at 16:59, Oliver Fromme wrote: Yeah, I don't think it's hard to move them, however I'm worried what it will break :) The only thing I can see that would have to change would be kgdb so it tells gdb where to find the symbols. That's why I suggested to place symlinks in the kernel directory. No change to kgdb necessary. Ahh of course. Although that does make it harder because you have to modify all the links when the old kernel is moved out of the way. Right. Maybe make a symlink to a directory, so only that symlink has to be changed: /boot/kernel/symbols - /var/db/symbols/kernel /boot/kernel/kernel.symbols - symbols/kernel.symbols /boot/kernel/acpi.symbols - symbols/acpi.symbols .. and so on. When the kernel is rotated to kernel.old, only one symlink has to be changed: /boot/kernel.old/symbols - /var/db/symbols/kernel.old Of course, /var/db is just an example off the top of my head. The symbols directory should be configurable via make.conf, too. Yes that makes sense. I guess the next thing is to make patches :) Hmm, I think they would need to go elsewhere otherwise they wouldn't be available to people who do binary installs, hence the usefulness of bug reports would go down. Right, I was thinking of developers only, who usually have a populated /usr/obj directory ... But there's a world full of non-developers, too. :-) Yeah and they find lots of bugs :( -- 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
