Re: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg attached)
> Here we can see detected: 4 (not 6!) SATA channels on AHCI controller, > one PATA channel and 2 SATA channels in legacy emulation (why?). It's "native" mode selected by BIOS setup as "default" I hope, this diffs can be useful by some way: ===ahci -> "native"=== 25c25 < real memory = 1609236480 (1534 MB) --- > real memory = 1610285056 (1535 MB) 29,33c29,33 < 0x00c25000 - 0x5e365fff, 1567887360 bytes (382785 pages) < avail memory = 1569984512 (1497 MB) < Table 'FACP' at 0x5feb0290 < Table 'APIC' at 0x5feb0390 < MADT: Found table at 0x5feb0390 --- > 0x00c25000 - 0x5e460fff, 1568915456 bytes (383036 pages) > avail memory = 1571012608 (1498 MB) > Table 'FACP' at 0x5ffb0290 > Table 'APIC' at 0x5ffb0390 > MADT: Found table at 0x5ffb0390 62,70c62,70 < ACPI: XSDT @ 0x0x5feb0100/0x0054 (v 1 092208 XSDT1629 0x20080922 MSFT 0x0097) < ACPI: FACP @ 0x0x5feb0290/0x00F4 (v 3 092208 FACP1629 0x20080922 MSFT 0x0097) < ACPI: DSDT @ 0x0x5feb0440/0x7214 (v 1 A78GM A78GM922 0x0004 INTL 0x20051117) < ACPI: FACS @ 0x0x5febe000/0x0040 < ACPI: APIC @ 0x0x5feb0390/0x006C (v 1 092208 APIC1629 0x20080922 MSFT 0x0097) < ACPI: MCFG @ 0x0x5feb0400/0x003C (v 1 092208 OEMMCFG 0x20080922 MSFT 0x0097) < ACPI: OEMB @ 0x0x5febe040/0x0071 (v 1 092208 OEMB1629 0x20080922 MSFT 0x0097) < ACPI: HPET @ 0x0x5feb7660/0x0038 (v 1 092208 OEMHPET 0x20080922 MSFT 0x0097) < ACPI: SSDT @ 0x0x5feb76a0/0x0350 (v 1 A M I POWERNOW 0x0001 AMD 0x0001) --- > ACPI: XSDT @ 0x0x5ffb0100/0x0054 (v 1 092208 XSDT1629 0x20080922 MSFT > 0x0097) > ACPI: FACP @ 0x0x5ffb0290/0x00F4 (v 3 092208 FACP1629 0x20080922 MSFT > 0x0097) > ACPI: DSDT @ 0x0x5ffb0440/0x7214 (v 1 A78GM A78GM922 0x0004 INTL > 0x20051117) > ACPI: FACS @ 0x0x5ffbe000/0x0040 > ACPI: APIC @ 0x0x5ffb0390/0x006C (v 1 092208 APIC1629 0x20080922 MSFT > 0x0097) > ACPI: MCFG @ 0x0x5ffb0400/0x003C (v 1 092208 OEMMCFG 0x20080922 MSFT > 0x0097) > ACPI: OEMB @ 0x0x5ffbe040/0x0071 (v 1 092208 OEMB1629 0x20080922 MSFT > 0x0097) > ACPI: HPET @ 0x0x5ffb7660/0x0038 (v 1 092208 OEMHPET 0x20080922 MSFT > 0x0097) > ACPI: SSDT @ 0x0x5ffb76a0/0x0350 (v 1 A M I POWERNOW 0x0001 AMD > 0x0001) 134c134 < acpi0: wakeup code va 0x83275000 pa 0x1000 --- > acpi0: wakeup code va 0x8327b000 pa 0x1000 258c258 < acpi0: reservation of 10, 5fe0 (3) failed --- > acpi0: reservation of 10, 5ff0 (3) failed 264,267d263 < Initial Probe 0 11 N 0 4 7 10 11 12 14 15 < Validation 0 11 N 0 4 7 10 11 12 14 15 < After Disable 0 255 N 0 4 7 10 11 12 14 15 < pci_link1:Index IRQ Rtd Ref IRQs 270a267,270 > pci_link1:Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 4 7 10 11 12 14 15 > Validation 0 11 N 0 4 7 10 11 12 14 15 > After Disable 0 255 N 0 4 7 10 11 12 14 15 321c321 < found-> vendor=0x1002, dev=0x4391, revid=0x00 --- > found-> vendor=0x1002, dev=0x4390, revid=0x00 323c323 < class=01-06-01, hdrtype=0x00, mfdev=0 --- > class=01-01-8f, hdrtype=0x00, mfdev=0 341c341 < intpin=a, irq=11 --- > intpin=a, irq=10 350c350 < intpin=a, irq=11 --- > intpin=a, irq=10 359c359 < intpin=b, irq=10 --- > intpin=b, irq=11 379c379 < map[10]: type Memory, range 32, base 0xfe8f7000, size 12, enabled --- > map[10]: type Memory, range 32, base 0xfe8fb000, size 12, enabled 389c389 < map[10]: type Memory, range 32, base 0xfe8f6800, size 8, enabled --- > map[10]: type Memory, range 32, base 0xfe8fa800, size 8, enabled 410c410 < intpin=a, irq=11 --- > intpin=a, irq=10 412c412 < map[10]: type Memory, range 64, base 0xfe8f, size 14, enabled --- > map[10]: type Memory, range 64, base 0xfe8f4000, size 14, enabled 431c431 < map[10]: type Memory, range 32, base 0xfe8f5000, size 12, enabled --- > map[10]: type Memory, range 32, base 0xfe8f9000, size 12, enabled 541c541 < atapci0: port 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f mem 0xfe8ff800-0xfe8ffbff irq 22 at device 17.0 on pci0 --- > atapci0: port > 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f mem > 0xfe8ff800-0xfe8ffbff irq 22 at device 17.0 on pci0 547c547 < atapci0: AHCI Version 01.10 controller with 6 ports detected --- > atapci0: AHCI Version 01.10 controller with 4 ports detected 569,578d568 < ata6: on atapci0 < ata6: SATA connect status= < ata6: ahci_reset devices=0x0 < ata6: [MPSAFE] < ata6: [ITHREAD] < ata7: on atapci0 < ata7: SATA connect status= < ata7: ahci_reset devices=0x0 < ata7: [MPSAFE] < ata7: [ITHREAD] === ahci -> ahci + combined mode enabled === 264,267d263 < Initial Probe 0 11 N 0 4 7 10 11 12 14 15 < Validation 0 11 N 0 4 7 10 11 12 14 15 < After Disable 0 255 N 0 4 7 10 11 12
(no subject)
Hi, I got 4 new SATA disks (WD Green, 1TB, WD10EADS) I want to use to replace my old 250GB disks attached to my 3ware controller. I want to reuse the old 250GB disks in some systems running old PATA disks ight now as system drives. So what I did now was gathering SATA performance tatistics with the new 1TB drive to just find out what would be the maximum performance I would get out of these disks to compare them later with my 3ware when they are configured as RAID-5. A colleague of mine has the same disks in a new Nvidia Atom 330 system and he told me that he reaches around 70MB/sec write speed with a single large file on a single disk running linux 2.6. I hooked the disk up to my client: FreeBSD 7.2-STABLE #0: Tue Jul 28 12:59:47 CEST 2009 CPU: AMD Athlon(tm) 64 Processor 3500+ (2200.10-MHz K8-class CPU) usable memory = 2138615808 (2039 MB) atapci0: port 0xd000-0xd007,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xb800-0xb80f,0xb400 -0xb4ff irq 20 at device 15.0 on pci0 ad4: 953869MB at ata2-master SATA150 because the on-board controller is a VIA 6420 I had to set the SATA150 Jumper on the harddisk to have the controller detect the drive. On FreeBSD I used gpart+gpt to create a 1TB partition and then simply ran newfs /dev/ad4p1 and mounted the new filesystem afterwards. I then ran a dd in=/dev/zero of=/mnt/tmp/test.dd bs=1M count=4069 and dd reported me a write speed of around 25MB/sec. This made me feel kinda bad so I gave bonnie++ a try. The result was: Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP kartoffel.salats 4G 548 96 28924 3 14617 2 1141 96 36869 3 199.7 2 Latency 167ms 71702us1759ms 23957us 75351us 2286ms Version 1.96 --Sequential Create-- Random Create kartoffel.salatschu -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 552 1 + +++ 1486 2 531 1 + +++ 1278 1 Latency 91403us 156us 28424us 22901us 87us 22820us 1.96,1.96,kartoffel.salatschuessel.net,1,1254282805,4G,,548,96,28924,3,14617 ,2,1141,96,36869,3,199.7,2,16,552,1,+,+++,1486,2,531,1,+,+++,127 8,1,167ms,71702us,1759ms,23957us,75351us,2286ms,91403us,156us,28424us,22901u s,87us,22820us This also did not look that good comparing to the bonnie output the colleague gave me from his shiny new ION system. I then booted the latest knoppix (Also a 2.6.whatever linux kernel), created a filesystem on /dev/sd1a (mkfs.ext3 /dev/sd1a) and mounted the filesystem as well. The same dd I ran on FreeBSD I also ran on Knoppix and this gave me 57.3MB/sec (wow compared to 25MB/sec). I then also started bonnie++ just to see that this one is also much better: Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP Microknoppix 4G 305 99 55905 18 31896 9 959 98 80414 10 211.7 3 Latency 28579us1075ms1046ms 26376us 20962us272ms Version 1.96 --Sequential Create-- Random Create Microknoppix-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 27135 59 + +++ + +++ 29369 62 + +++ + +++ Latency 23535us9969us9927us 11680us1182us 9985us 1.96,1.96,Microknoppix,1,1254262392,4G,,305,99,55905,18,31896,9,959,98,80414 ,10,211.7,3,16,27135,59,+,+++,+,+++,29369,62,+,+++,+,+++ ,28579us,1075ms,1046ms,26376us,20962us,272ms,23535us,9969us,9927us,11680us,1 182us,9985us Does anyone know if there is something I can tune on FreeBSD to get more speed? hw.ata.wc is enabled of course. hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma_check_80pin: 1 hw.ata.ata_dma: 1 I'll retest both setups with a plugged in Promise SATA300 PCI controller but I doubt that it will get faster. I tried the controller before, and on an dual PIII-850 system with L440GX chipset and 2GB of RAM the controller gave me around 40MB/sec on write and on my amd64 system I also only got around 25MB/sec (even this makes no sense to me why my old PIII is faster then my much newer amd64) but I'll come back with better numbers for this controller later. ___ 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: Laggy X11 after updating to 8.0-RC1
On Wed, 30 Sep 2009, Rohit Grover wrote: I did have 'AllowEmptyInput "off"' in my xorg.conf previously. Aha! I should have stressed that more. The mixed libraries were an unrelated issue. -Warren Block * Rapid City, South Dakota USA ___ 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: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg attached)
On Monday 28 September 2009 02:21 pm, Alexander Motin wrote: > Here we can see detected: 4 (not 6!) SATA channels on AHCI > controller, one PATA channel and 2 SATA channels in legacy > emulation (why?). Actually, the same happens if I comment out all > that device class magic. Looks like the only thing really required > to fix problem with two lost channels is this part of patch: > > -/* IXP600 & IXP700 only have 1 PATA channel */ > -if ((ctlr->chip->chipid == ATA_ATI_IXP600) || > - (ctlr->chip->chipid == ATA_ATI_IXP700)) > +/* IXP600 only have 1 PATA channel */ > +if (ctlr->chip->chipid == ATA_ATI_IXP600) > > Looks like part of changing device class just not working. Today I > have bought IXP700 based board and can acknowledge that the same > situation I can see with recent HEAD. `pciconf -l` reports to me > original PATA device class and only 4 channels reported by AHCI. > > So jkim@, could you please comment, how should it really work and > why it doesn't? My patch fixed two things: a) "combined mode" and b) the above fix. The combined mode is very unusual. When combined mode is turned on from BIOS, two SATA ports appear as legacy ATA device. Depending on the configurations, device ID changes. :-( To enable this feature, some BIOSes allow flexible (and yet confusing) combinations like this: http://people.freebsd.org/~jkim/sb700-ata.png Also, almost all SB700 BIOSes out there have broken ACPI DSDT which do not set these bits properly. Thus, some ports disappear if we don't force setting the subclass and progif. Note it should be *partially* worked around by the latest ACPICA on -CURRENT, though. > PS: I have tried to disable all that ATI-specific code and found > that both legacy PCI ATA and AHCI drivers looks like working fine > with IXP700. Do we really need AHCI forcing for IXP700? It enables all six SATA ports as SATA and one PATA channel as PATA in the combined mode by forcing the mode. It is not absolutely necessary but it is better than without it, IMHO. :-) Jung-uk Kim ___ 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: Laggy X11 after updating to 8.0-RC1
On Tue, Sep 29, 2009 at 9:04 PM, Warren Block wrote: > On Tue, 29 Sep 2009, Rohit Grover wrote: >> >> I did a 'pkg_delete -a' to delete all packages, and then installed >> fresh packages from the 8.0-RC1 DVD as necessary. I'm back to a useful >> system and X11 isn't lagging anymore. >> >> I hope someone investigates why X11 didn't behave well right after >> updating the kernel/world/some-packages. > > Please confirm the presence or absence of the AllowEmptyInput option in your > xorg.conf. > > I tested yesterday and found that "AllowEmptyInput" "off" with dbus/hal > running produced exactly the behavior you describe. > > A FreeBSD major version upgrade with mixed old a new libraries can certainly > cause problems, but the specific "laggy X11" problem is more likely due to > that option. > I did have 'AllowEmptyInput "off"' in my xorg.conf previously. ___ 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: 8.0-RC1 panic attaching ppc
In article <4ac0f173.10...@cs.rice.edu> you write: >Daniel O'Connor wrote: >> On Sun, 27 Sep 2009, Alan Cox wrote: >> >>> Ok, now I can explain what is happening. The kernel is using 1GB >>> pages to implement the direct map. Unfortunately, pmap_extract() >>> doesn't know how to handle a 1GB page mapping. pmap_kextract() only >>> works by an "accident" of its different implementation. In other >>> words, it should not be relied upon to work either. >>> >>> Please revert whatever patch John gave you and try the attached >>> patch. It simply disables the use of 1GB page mapping by the direct >>> map. >>> >> >> Your patch fixes (works around?) the problem. >> > >Thanks. I've committed the patch. > >Yes, it's a work around. Fortunately(?), on my test machine, I don't >see any measurable effect from disabling the use of 1GB pages by the >direct map. Btw I had reported the same issue back in June already, http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008709.html and yes your patch fixes it for me too. Thanx! (And of the other two issues mentioned in the next posting, http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008711.html the tdq_notify trap appears to be solved, but the ata issue was never fixed, I had to work around it by putting the affected optical drive on a pcie sata card driven by siis(4).) Cheers, Juergen ___ 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: FreeBSD 7.2-STABLE boot freeze
On Tue, 29 Sep 2009, Andriy Gapon wrote: > Serial console and remote debugging perhaps? ILO is serial console or rather console++, since you can even see the whole bootup sequence, change bios. But thats if you connect through their webinterface Just point me what other options I could try to get a proper dump or bt. > Anyway, I'll try to see if I can reproduce undefined symbol issue here. > > Not that it would matter much for resolution of your main problem (freeze). > Honestly, I have no clue about it. Ok. Hopefully someone else knows what can produce these freezes. /Bjorn ___ 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: Signing Request
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 FYI, cross-posting to more than one list is discouraged. J. Hellenthal wrote: > On Wed, 23 Sep 2009 11:40 -, jhellenthal wrote: > >> >> If you do not need to pgp/gpg sign email message to the lists please >> don't. I think a lot of people would define "need" differently than you do. Part of being on a public mailing list is dealing with traffic in formats that you don't necessarily like or would choose to use. The robustness principle fits here, "Be liberal in what you accept, and conservative in what you send." >> I know I probably don't have your pgp public key and a lot more >> users probably do not either. There are ways to address that problem. I see that you're using Alpine, not sure what you're using for PGP in association with that. My own mail/pine-pgp-filters port works quite well for this purpose. You can also include the following in your gpg.conf: keyserver-options auto-key-retrieve which will retrieve the keys for you without intervention. (FWIW, I also recommend the options no-include-revoked, import-clean, and export-clean.) Personally I keep the keys that I care about in their own keyring files, and allow the "random" keys to be imported into pubring.gpg. That way I can nuke that ring, or keys on it any time and know I'm not losing anything important. I'll leave that configuration as an exercise for the reader. :) > If I do not have your public key in my keyring then I do not want it, do > not need it and have no use for it at this time. This keeps my keyring > small and manageable. Well yay for you! :) However explaining your reasoning isn't making you sound any more reasonable. The "public" part of "public key cryptography" is often messy, you need to learn how to deal with it. hth, Doug (who signed this message so everyone would know it's from me, no tweak intended) - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (FreeBSD) iEYEAREDAAYFAkrCSygACgkQyIakK9Wy8PvZBQCcCSp1KEprBdrmG2nN4HZCkxA2 4GAAoPVZN5OXxsDjYzNtVOd3IAvBYQ08 =fRlR -END PGP SIGNATURE- ___ 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: Laggy X11 after updating to 8.0-RC1
Rohit Grover wrote: > I did a 'pkg_delete -a' to delete all packages, and then installed > fresh packages from the 8.0-RC1 DVD as necessary. I'm back to a useful > system and X11 isn't lagging anymore. > > I hope someone investigates why X11 didn't behave well right after > updating the kernel/world/some-packages. There is no mystery. Mixtures of new and old binaries and libraries is an unsupported configuration. Doug -- This .signature sanitized for your protection ___ 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: Booting FreeBSD 8.0-RC1 from usb stick
On Tue, 2009-09-29 at 16:51 +0200, Marius Nünnerich wrote:
> On Tue, Sep 29, 2009 at 16:03, Gavin Atkinson wrote:
> > On Tue, 2009-09-29 at 14:40 +0200, Marius Nünnerich wrote:
> >> 2009/9/29 Andrey V. Elsukov :
> >> > Marius Nu"nnerich wrote:
> >> >>
> >> >> Explicitly setting the root partition
> >> >> (vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not
> >> >> help either: Again, the system knows which partition it should mount
> >> >> to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set
> >> >> too).
> >> >
> >> > It's known problem and we are waiting for fix. There is a race between
> >> > USB and CAM/SCSI subsystems.
> >>
> >> OK, thank you! Is there a PR open for this?
> >
> > I think your problem is probably usb/138798.
>
> Thanks! I hoped there would be some quick fix like putting some DELAY
> into CAM or usb to go ahead for now but it isn't. Anyone has an idea
> for where to put this or a patch to try? I suppose usb should finish
> before CAM comes along?
Hmm, that PR might not be your problem. Do you see the USB stick probe
and appear after the kernel has tried to mount it, like in that PR, or
do you see the USB stick probe before mountroot is attempted, but it
still fails?
Either way, you could try the attached hack. Be aware that this really
is not the correct fix, but might at least be enough to get you going
until the correct fix is in place.
No guarantees, warranty etc.
Gavin
Index: sys/kern/vfs_mount.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_mount.c,v
retrieving revision 1.308
diff -u -r1.308 vfs_mount.c
--- sys/kern/vfs_mount.c 5 Jun 2009 14:55:22 - 1.308
+++ sys/kern/vfs_mount.c 29 Sep 2009 17:08:25 -
@@ -1645,6 +1645,9 @@
options = NULL;
+ /* NASTY HACK: wait for USB sticks to appear */
+ pause("usbhack", hz * 10);
+
root_mount_prepare();
mount_zone = uma_zcreate("Mountpoints", sizeof(struct mount),
___
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: Booting FreeBSD 8.0-RC1 from usb stick
On Tue, Sep 29, 2009 at 16:03, Gavin Atkinson wrote: > On Tue, 2009-09-29 at 14:40 +0200, Marius Nünnerich wrote: >> 2009/9/29 Andrey V. Elsukov : >> > Marius Nu"nnerich wrote: >> >> >> >> Explicitly setting the root partition >> >> (vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not >> >> help either: Again, the system knows which partition it should mount >> >> to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set >> >> too). >> > >> > It's known problem and we are waiting for fix. There is a race between >> > USB and CAM/SCSI subsystems. >> >> OK, thank you! Is there a PR open for this? > > I think your problem is probably usb/138798. Thanks! I hoped there would be some quick fix like putting some DELAY into CAM or usb to go ahead for now but it isn't. Anyone has an idea for where to put this or a patch to try? I suppose usb should finish before CAM comes along? ___ 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: Booting FreeBSD 8.0-RC1 from usb stick
On Tue, 2009-09-29 at 14:40 +0200, Marius Nünnerich wrote: > 2009/9/29 Andrey V. Elsukov : > > Marius Nu"nnerich wrote: > >> > >> Explicitly setting the root partition > >> (vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not > >> help either: Again, the system knows which partition it should mount > >> to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set > >> too). > > > > It's known problem and we are waiting for fix. There is a race between > > USB and CAM/SCSI subsystems. > > OK, thank you! Is there a PR open for this? I think your problem is probably usb/138798. Gavin ___ 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: FreeBSD 7.2-STABLE boot freeze
on 29/09/2009 09:58 Bjorn Hellqvist said the following: > On Mon, 28 Sep 2009, kama wrote: > >> >> On Mon, 28 Sep 2009, Andriy Gapon wrote: >> >>> on 28/09/2009 10:21 kama said the following: On Fri, 25 Sep 2009, Andriy Gapon wrote: > on 25/09/2009 12:04 kama said the following: >> On Thu, 24 Sep 2009, kama wrote: >> >>> I am currently building the source on another machine. Lets see if it >>> will >>> build it any better. >> Building the the world on another machine and install it on the DL385 >> machine made it also to freeze. > Did you still get the message about unresolved symbol? I did not try with ACPI_DEBUG enabled. Another week, so I can start testing again... >>> I did not ask that :-) >>> I asked - when you got your latest freeze, did you see that 'unresolved' >>> message or not? >> But that only appears when I enable ACPI_DEBUG. OK, then I was thoroughly confused all this time. I thought that the message appeared when didn't have ACPI_DEBUG. > And yes. It stills gets the same undefined symbols. (I presume its these > you are referring to...) > > # dmesg | grep -i acpi > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0ed31d8. > link_elf: symbol AcpiDmDumpMethodInfo undefined > KLD file acpi.ko - could not finalize loading > > # nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo > /boot/kernel/acpi.ko: U AcpiDmDumpMethodInfo > /boot/kernel/acpi.ko.symbols: U AcpiDmDumpMethodInfo > nm: /boot/kernel/linker.hints: File format not recognized > > # uname -a > FreeBSD g24.gs.pvp.se 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon Sep 28 > 13:39:01 CEST 2009 r...@s11.gs.pvp.se:/usr/obj/usr/src/sys/ddb i386 > > # diff -ub /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/ddb > --- /usr/src/sys/i386/conf/GENERIC 2009-07-15 10:32:19.0 > +0200 > +++ /usr/src/sys/i386/conf/ddb 2009-09-28 13:25:20.0 +0200 > @@ -67,6 +67,10 @@ > optionsAUDIT # Security event auditing > #options KDTRACE_HOOKS # Kernel DTrace hooks > > +optionsKDB > +optionsDDB > +options ACPI_DEBUG > + > # To make an SMP kernel, the next two lines are needed > optionsSMP # Symmetric MultiProcessor Kernel > device apic# I/O APIC > # > > > Its too bad that I cant get into the debugger. The server gets > unresponsive when the freeze occurs. Is there any other option that I can > add so it goes to the debugger? Serial console and remote debugging perhaps? Anyway, I'll try to see if I can reproduce undefined symbol issue here. Not that it would matter much for resolution of your main problem (freeze). Honestly, I have no clue about it. -- Andriy Gapon ___ 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: Laggy X11 after updating to 8.0-RC1
On Tue, 29 Sep 2009, Rohit Grover wrote: I did a 'pkg_delete -a' to delete all packages, and then installed fresh packages from the 8.0-RC1 DVD as necessary. I'm back to a useful system and X11 isn't lagging anymore. I hope someone investigates why X11 didn't behave well right after updating the kernel/world/some-packages. Please confirm the presence or absence of the AllowEmptyInput option in your xorg.conf. I tested yesterday and found that "AllowEmptyInput" "off" with dbus/hal running produced exactly the behavior you describe. A FreeBSD major version upgrade with mixed old a new libraries can certainly cause problems, but the specific "laggy X11" problem is more likely due to that option. -Warren Block * Rapid City, South Dakota USA ___ 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: Booting FreeBSD 8.0-RC1 from usb stick
2009/9/29 Andrey V. Elsukov : > Marius Nu"nnerich wrote: >> >> Explicitly setting the root partition >> (vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not >> help either: Again, the system knows which partition it should mount >> to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set >> too). > > It's known problem and we are waiting for fix. There is a race between > USB and CAM/SCSI subsystems. OK, thank you! Is there a PR open for this? ___ 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: 8.0RC1, ZFS: deadlock
On Sep 29, 2009, at 10:29 AM, Borja Marcos wrote: I have observed a deadlock condition when using ZFS. We are making a heavy usage of zfs send/zfs receive to keep a replica of a dataset on a remote machine. It can be done at one minute intervals. Maybe we're doing a somehow atypical usage of ZFS, but, well, seems to be a great solution to keep filesystem replicas once this is sorted out. Not sure the backtraces screenshots will get through... First one is the backtrace for the zfs command. Second one, a tar process doing a "cf - ." on the dataset being replicated, sending to a pipe. Third one, the receiving tar process, doing an "xf -" on a second dataset. ___ 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: Excessivly cheap USB device issue
On Tue, 2009-09-29 at 23:16 +1300, Andrew Thompson wrote: > On Tue, Sep 29, 2009 at 05:11:24AM -0500, Robert Noland wrote: > > On Tue, 2009-09-29 at 14:35 +0930, Daniel O'Connor wrote: > > > On Mon, 28 Sep 2009, Mike Tancsa wrote: > > > > >I also have a similar device, which I've been messing with a bit the > > > > >last couple of days. In your case, it isn't seeing the media, just > > > > > the "drive". I've had to try various combinations of unplugging > > > > > the adapter from usb, inserting the media then plugging it back in. > > > > > It does seem to work fairly reliably if you boot with the media > > > > > already inserted, but it doesn't seem to detect media change at > > > > > all. > > > > > > > > I get around it (on my cheap reader) by always doing a > > > > cat /dev/null > /dev/da1 > > > > whever I change or insert new media into the reader > > > > > > > > That seems to work with the gear I have 99% of the time. > > > > > > Hmm OK, I sort of expected fdisk da1 to fail straightaway though (it > > > takes ~30 seconds to fail for me). > > > > > > I have unplugged it for now, it interacts annoyingly with SANE because > > > that scans the SCSI bus(es) looking for scanner and each umass takes > > > 30+ seconds to fail. > > > > FWIW, on yesterdays kernel, mine seems to be working properly and > > detecting media change. I'm not sure what change helped. Note that I > > am running -CURRENT. > > Was that after the sync to Hans's repo? There were around 20 commits so > if anyone can narrow it down to a single rev then it may be able to be > merged. Looks like I'm at r197575, now. robert. > > Andrew > ___ > 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" -- Robert Noland FreeBSD ___ 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: Excessivly cheap USB device issue
On Tue, Sep 29, 2009 at 05:11:24AM -0500, Robert Noland wrote: > On Tue, 2009-09-29 at 14:35 +0930, Daniel O'Connor wrote: > > On Mon, 28 Sep 2009, Mike Tancsa wrote: > > > >I also have a similar device, which I've been messing with a bit the > > > >last couple of days. In your case, it isn't seeing the media, just > > > > the "drive". I've had to try various combinations of unplugging > > > > the adapter from usb, inserting the media then plugging it back in. > > > > It does seem to work fairly reliably if you boot with the media > > > > already inserted, but it doesn't seem to detect media change at > > > > all. > > > > > > I get around it (on my cheap reader) by always doing a > > > cat /dev/null > /dev/da1 > > > whever I change or insert new media into the reader > > > > > > That seems to work with the gear I have 99% of the time. > > > > Hmm OK, I sort of expected fdisk da1 to fail straightaway though (it > > takes ~30 seconds to fail for me). > > > > I have unplugged it for now, it interacts annoyingly with SANE because > > that scans the SCSI bus(es) looking for scanner and each umass takes > > 30+ seconds to fail. > > FWIW, on yesterdays kernel, mine seems to be working properly and > detecting media change. I'm not sure what change helped. Note that I > am running -CURRENT. Was that after the sync to Hans's repo? There were around 20 commits so if anyone can narrow it down to a single rev then it may be able to be merged. Andrew ___ 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: glabel+gmirror (8.0-RC1 problem)
Oliver Lehmann writes: > I noticed that even when I boot in multiuser, change fstab, then return > into single user mode and remount / read-only, the label cannot be set. > I need to boot directly into single user mode. Looks like writing the > label is denied when the partition was once mounted rw before - even if > it is actually mounted ro. IIRC, the underlying GEOM is promoted from ro to rw when you mount the file system, but it is never "demoted" back to ro. I don't know if that's fixable. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Booting FreeBSD 8.0-RC1 from usb stick
Marius Nu"nnerich wrote: Explicitly setting the root partition (vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not help either: Again, the system knows which partition it should mount to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set too). It's known problem and we are waiting for fix. There is a race between USB and CAM/SCSI subsystems. -- WBR, Andrey V. Elsukov ___ 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: Excessivly cheap USB device issue
On Tue, 2009-09-29 at 14:35 +0930, Daniel O'Connor wrote: > On Mon, 28 Sep 2009, Mike Tancsa wrote: > > >I also have a similar device, which I've been messing with a bit the > > >last couple of days. In your case, it isn't seeing the media, just > > > the "drive". I've had to try various combinations of unplugging > > > the adapter from usb, inserting the media then plugging it back in. > > > It does seem to work fairly reliably if you boot with the media > > > already inserted, but it doesn't seem to detect media change at > > > all. > > > > I get around it (on my cheap reader) by always doing a > > cat /dev/null > /dev/da1 > > whever I change or insert new media into the reader > > > > That seems to work with the gear I have 99% of the time. > > Hmm OK, I sort of expected fdisk da1 to fail straightaway though (it > takes ~30 seconds to fail for me). > > I have unplugged it for now, it interacts annoyingly with SANE because > that scans the SCSI bus(es) looking for scanner and each umass takes > 30+ seconds to fail. FWIW, on yesterdays kernel, mine seems to be working properly and detecting media change. I'm not sure what change helped. Note that I am running -CURRENT. robert. -- Robert Noland FreeBSD ___ 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"
Booting FreeBSD 8.0-RC1 from usb stick
Hi all,
FreeBSD 8.0-RC1 was installed onto hard disk. The root filesystem was
transferred to a usb memory stick via
#pwd
/
# find -print . -x | cpio -pdm /mnt/usbstick
The fstab on the stick was modified such that "/" was to be mounted
from /dev/da0s1a, the ufs fs on the usb stick.
This had proven to work perfectly with 7.2.
In 8.0-RC1, however, this approach fails. After booting the kernel,
the system does not automatically mount the "/" partition. Instead, it
asks for a partition to mount to "/", and when exactly the same
location is entered ("ufs:/dev/da0s1a"), it mounts this partition and
works perfectly.
Explicitly setting the root partition
(vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not
help either: Again, the system knows which partition it should mount
to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set
too).
Any ideas?
Marius
___
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: Laggy X11 after updating to 8.0-RC1
On Tue, Sep 29, 2009 at 11:55 AM, Scott Lambert wrote: > On Mon, Sep 28, 2009 at 07:29:46PM -0600, Warren Block wrote: >> On Tue, 29 Sep 2009, Rohit Grover wrote: >> > >> >On Tue, Sep 29, 2009 at 7:30 AM, Warren Block wrote: >> >>On Tue, 29 Sep 2009, Rohit Grover wrote: >> >> >> >>>I have upgraded to 8.0-RC1 (from 7.2-STABLE) on my MacBook 4,1. I >> >>>did so by checking out stable/8 under /usr/src, rebuilding >> >>>kernel/world, and using portupgrade to update all installed ports >> >>>from packages available on the 8.0RC1 DVD-iso. >> >>> >> >>>Since the update, my X11 is laggy. Now, I often have to move the >> >>>mouse before keystrokes/button presses take effect. >> >> >> >>Make sure hal and dbus are enabled in rc.conf and running. In >> >>xorg.conf, remove Option "AllowEmptyInput" "off". >> >> >> >>A bonus of using hal is that you can remove the keyboard and mouse >> >>sections from xorg.conf. >> >> >> >>>As I've mentioned, I've updated the kernel/world, and updated >> >>>libpciaccess. Perhaps I'm having issues because I need to remove >> >>>old libs. How do I remove old libs? >> >> >> >>cd /usr/src make check-old-libs make delete-old-libs >> > >> > >> >I deleted old libs using 'make delete-old-libs' from /usr/src, >> >but that has led to many other problems. It seems many libraries >> >currently in use were deleted in the process. I'm having to >> >rebuild/reinstall many of my applications to get them working again. > > I'm seeing something similar to OP, apparent keyboard buffer delays, but > maybe not exactly. When I click from one xterm to another, it may be > 1 - 30 seconds before my key entries show. Firefox seems to have less > delay after clicks into text fields, but sometimes it is noticeable maybe > 0.25 to 1 second. Just two xterms, the fluxbox toolbar, and firefox > running. No frufru stuff. > > I haven't had time to systematically try to narrow down the actual > problem. > > Wiggling the mouse, hitting various keys all seemed like they helped > at one time or another, but I think I was just trying things until the > buffer released. If I leave it alone, the delays seem to be of about > the same length as when I'm trying random things to break it loose. > > Only clicking in a window (particularly an xterm) seems to stall the > keyboard buffer. Just wiggling the mouse above or around the focused > window is no problem. Clicks take effect immediately. I can drag > the window by the title bar or resize the window without stalling the > keyboard buffer. > > I haven't lost a key press that I've noticed. Now I just type blind > until it catches up or I actually need to see the results of my typing. > > Oh, it seems like if there is something in the xterm which can use the > mouse input, it may not be stalling the keyboard buffer. I need to > watch that more closely. > > I've tried with and without an explicit xorg.conf. Switching > back to the console works better without. With doesn't leave me a > usable display outside of X. > > It seems like the delays get longer and longer the longer the X session > has been up. But sometimes there will be no delay. If I switch > windows/desktops with alt-tab, ctrl-f#, there is no delay. I've been > wondering if it could be due to the synaptics touchpad. I enabled the > synaptics features about the same time to try to get rid of tap events > from the touchpad. I hate touchpads and still haven't figured out how > to kill tapping. > > agp0: on vgapci0 > > I've done the delete-old stuff and got mad at KDE4 and did a pkg_delete > -a in a fit of rage. I went back with fluxbox, took about 2 to 3 hours > to compile everything from source to have my multiple xterms back. > Firefox took another 2 hours. But I was able to *work* while that > built. > > I was running FreeBSD 8-CURRENT pre-beta cycle. KDE4 was giving me so > many fits that I would just run Windows instead so I could get work > done, sad. I don't know if I would have noticed an input buffer delay > before I upgraded to BETA2 and replaced KDE with fluxbox. I just > couldn't stand to spend that much time in X. Windows finally annoyed me > enough to try something different (fluxbox). This problem has been with > me through the BETAs and now into RC1, as far as I can remember. I've > been busy and trying really hard to ignore workstation issues to get > work done ever since my PowerBook died. > >> When upgrading from one major release of FreeBSD to another, the >> standard recommendation is to delete all installed applications >> (pkg_delete -a) and then reinstall everything. There may be some >> incantation of portupgrade or portmaster that will do it. pkg_libchk >> from sysutils/bsdadminscripts may help. But that is likely to take >> longer than just pkg_delete -a and reinstalling applications. > > portmaster's man page suggests pkg_delete -a. It has explicit > instructions so you don't miss anything putting them back on. Not > that I've used the instructions yet. Rage i
Re: 8.0RC1, ZFS: deadlock
On Sep 29, 2009, at 10:29 AM, Borja Marcos wrote: Hello, I have observed a deadlock condition when using ZFS. We are making a heavy usage of zfs send/zfs receive to keep a replica of a dataset on a remote machine. It can be done at one minute intervals. Maybe we're doing a somehow atypical usage of ZFS, but, well, seems to be a great solution to keep filesystem replicas once this is sorted out. How to reproduce: Set up two systems. A dataset with heavy I/O activity is replicated from the first to the second one. I've used a dataset containing / usr/obj while I did a make buildworld. Replicate the dataset from the first machine to the second one using an incremental send zfs send -i pool/data...@nminus1 pool/data...@n | ssh destination zfs receive -d pool When there is read activity on the second system, reading the replicated system, I mean, having read access while zfs receive is updating it, there can be a deadlock. We have discovered this doing a test on a hopefully soon in production server, with 8 GB RAM. A Bacula backup agent was running and ZFS deadlocked. Sorry, forgot to explain what was happening on the second system (the one receiving the incremental snapshots) for the deadlock to happen. It was just running an endless loop, copying the contents of /usr/obj to another dataset, in order to keep the reading activity going on. That's how it has deadlocked. On the original test system an rsync did the same trick. Borja ___ 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.0RC1, ZFS: deadlock
Hello, I have observed a deadlock condition when using ZFS. We are making a heavy usage of zfs send/zfs receive to keep a replica of a dataset on a remote machine. It can be done at one minute intervals. Maybe we're doing a somehow atypical usage of ZFS, but, well, seems to be a great solution to keep filesystem replicas once this is sorted out. How to reproduce: Set up two systems. A dataset with heavy I/O activity is replicated from the first to the second one. I've used a dataset containing /usr/ obj while I did a make buildworld. Replicate the dataset from the first machine to the second one using an incremental send zfs send -i pool/data...@nminus1 pool/data...@n | ssh destination zfs receive -d pool When there is read activity on the second system, reading the replicated system, I mean, having read access while zfs receive is updating it, there can be a deadlock. We have discovered this doing a test on a hopefully soon in production server, with 8 GB RAM. A Bacula backup agent was running and ZFS deadlocked. I have set up a couple of VMWare Fussion virtual machines in order to test this, and it has deadlocked as well. The virtual machines have little memory, 512 MB, but I don't believe this is the actual problem. There is no complaint about lack of memory. A running top shows processes stuck on "zfsvfs" last pid: 2051; load averages: 0.00, 0.07, 0.55up 0+01:18:25 12:05:48 37 processes: 1 running, 36 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 18M Active, 20M Inact, 114M Wired, 40K Cache, 59M Buf, 327M Free Swap: 1024M Total, 1024M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1914 root1 620 11932K 2564K zfsvfs 0 0:51 0.00% bsdtar 1093 borjam 1 440 8304K 2464K CPU11 0:32 0.00% top 1913 root1 540 11932K 2600K rrl->r 0 0:19 0.00% bsdtar 1019 root1 440 25108K 4812K select 0 0:05 0.00% sshd 2008 root1 760 13600K 1904K tx->tx 0 0:04 0.00% zfs 1089 borjam 1 440 37040K 5216K select 1 0:04 0.00% sshd 995 root1 760 8252K 2652K pause 0 0:02 0.00% csh 840 root1 440 11044K 3828K select 1 0:02 0.00% sendmail 1086 root1 760 37040K 5156K sbwait 1 0:01 0.00% sshd 850 root1 440 6920K 1612K nanslp 0 0:01 0.00% cron 607 root1 440 5992K 1540K select 1 0:01 0.00% syslogd 1090 borjam 1 760 8252K 2636K pause 1 0:01 0.00% csh 990 borjam 1 440 37040K 5220K select 0 0:00 0.00% sshd 985 root1 480 37040K 5160K sbwait 1 0:00 0.00% sshd 911 root1 440 8252K 2608K ttyin 0 0:00 0.00% csh 991 borjam 1 560 8252K 2636K pause 0 0:00 0.00% csh 844 smmsp 1 460 11044K 3852K pause 0 0:00 0.00% sendmail Interestingly, this has blocked access to all the filesystems. I cannot, for instance, ssh into the machine anymore, even though all the system-important filesystems are on ufs, I was just using ZFS for a test. Any ideas on what information might be useful to collect? I have the vmware machine right now. I've made a couple of VMWare snapshots of it, first before breaking into DDB with the deadlock just started, the second being into DDB (I've broken into DDB with sysctl). Also, a copy of the VMWare virtual machine with snapshots is avaiable on request. Your choice ;) Borja. ___ 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: FreeBSD 7.2-STABLE boot freeze
On Mon, 28 Sep 2009, kama wrote: > > > On Mon, 28 Sep 2009, Andriy Gapon wrote: > > > on 28/09/2009 10:21 kama said the following: > > > > > > On Fri, 25 Sep 2009, Andriy Gapon wrote: > > > > > >> on 25/09/2009 12:04 kama said the following: > > >>> On Thu, 24 Sep 2009, kama wrote: > > >>> > > I am currently building the source on another machine. Lets see if it > > will > > build it any better. > > >>> Building the the world on another machine and install it on the DL385 > > >>> machine made it also to freeze. > > >> Did you still get the message about unresolved symbol? > > > > > > I did not try with ACPI_DEBUG enabled. > > > > > > Another week, so I can start testing again... > > > > I did not ask that :-) > > I asked - when you got your latest freeze, did you see that 'unresolved' > > message or not? > > But that only appears when I enable ACPI_DEBUG. And yes. It stills gets the same undefined symbols. (I presume its these you are referring to...) # dmesg | grep -i acpi Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0ed31d8. link_elf: symbol AcpiDmDumpMethodInfo undefined KLD file acpi.ko - could not finalize loading # nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo /boot/kernel/acpi.ko: U AcpiDmDumpMethodInfo /boot/kernel/acpi.ko.symbols: U AcpiDmDumpMethodInfo nm: /boot/kernel/linker.hints: File format not recognized # uname -a FreeBSD g24.gs.pvp.se 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon Sep 28 13:39:01 CEST 2009 r...@s11.gs.pvp.se:/usr/obj/usr/src/sys/ddb i386 # diff -ub /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/ddb --- /usr/src/sys/i386/conf/GENERIC 2009-07-15 10:32:19.0 +0200 +++ /usr/src/sys/i386/conf/ddb 2009-09-28 13:25:20.0 +0200 @@ -67,6 +67,10 @@ optionsAUDIT # Security event auditing #options KDTRACE_HOOKS # Kernel DTrace hooks +optionsKDB +optionsDDB +options ACPI_DEBUG + # To make an SMP kernel, the next two lines are needed optionsSMP # Symmetric MultiProcessor Kernel device apic# I/O APIC # Its too bad that I cant get into the debugger. The server gets unresponsive when the freeze occurs. Is there any other option that I can add so it goes to the debugger? /Bjorn ___ 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"
