Re: k3b causing system freeze/panic
on 28/07/2010 06:01 Michael Butler said the following: I have a custom kernel for my laptop which uses ATA_CAM rather than the now aging ATA driver .. You do realize that ATA_CAM just (well, mostly) introduces a wrapper around the now aging ATA driver ? No magic pixie dust to fix the bugs in it, but perhaps more ways to expose them. -- Andriy Gapon ___ 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
mmap() problem
Hi, When is it safe to free memory which has been mmapped to a user-space application? After close() or during close() or before close() or when the process/thread terminates? --HPS ___ 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
MCE machine check exceptions - status, tools?
Hello, By searching the net I was only able to find that better support for 9.0 is on its way. So I'd like to ask if MCEs (like ECC-related messages from, say Supermicro boards) are being already processed by the kernel. Are there any (plans for) tools to handle and process these messages in userland? The amount of memory and memory modules keeps increasing, so MCE logging for non A-brand hardware (these trigger LEDs and/or tools from firmware) appears to gain increasing importance, too. I'd be grateful for hints, URLs, tips etc. If sent as private mails, I'll post a summary back to the list. TIA, Volker -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach ___ 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: mmap() problem
From close(3): The close(2) system call does not unmap pages, see munmap(2) for further information. The pages can be freed when the process terminates. -- Jille Op 28-7-2010 10:56, Hans Petter Selasky schreef: Hi, When is it safe to free memory which has been mmapped to a user-space application? After close() or during close() or before close() or when the process/thread terminates? --HPS ___ 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 ___ 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: MCE machine check exceptions - status, tools?
on 28/07/2010 12:31 V. T. Mueller, Continum said the following: Hello, By searching the net I was only able to find that better support for 9.0 is on its way. So I'd like to ask if MCEs (like ECC-related messages from, say Supermicro boards) are being already processed by the kernel. Are there any (plans for) tools to handle and process these messages in userland? The amount of memory and memory modules keeps increasing, so MCE logging for non A-brand hardware (these trigger LEDs and/or tools from firmware) appears to gain increasing importance, too. I'd be grateful for hints, URLs, tips etc. MCA support is in current and stable/8. I believe that it's enabled by default, so there is not much to configure or to do except watching for MCE reports in system log (or via hw.mca.count). That's for correctable MCEs though, non-correctable would result in panic. See sys/x86/x86/mca.c code for details. John Baldwin has a tool that produces more human-friendly description of the exceptions should you ever get one. -- Andriy Gapon ___ 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: k3b causing system freeze/panic
Andriy Gapon a...@icyb.net.ua writes: Michael Butler i...@protected-networks.net writes: I have a custom kernel for my laptop which uses ATA_CAM rather than the now aging ATA driver .. You do realize that ATA_CAM just (well, mostly) introduces a wrapper around the now aging ATA driver ? Only for legacy drives, but since Micahel's panic message contains current process = 12 (irq15: ata1), his BIOS is probably in legacy mode. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: k3b causing system freeze/panic
Dag-Erling Smørgrav d...@des.no writes: Andriy Gapon a...@icyb.net.ua writes: Michael Butler i...@protected-networks.net writes: I have a custom kernel for my laptop which uses ATA_CAM rather than the now aging ATA driver .. You do realize that ATA_CAM just (well, mostly) introduces a wrapper around the now aging ATA driver ? Only for legacy drives, but since Micahel's panic message contains current process = 12 (irq15: ata1), his BIOS is probably in legacy mode. Sorry, I misparsed ATA_CAM as ahci. Why on earth would anyone want to use ATA_CAM these days? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: k3b causing system freeze/panic
Dag-Erling Smørgrav wrote: Dag-Erling Smørgrav d...@des.no writes: Andriy Gapon a...@icyb.net.ua writes: Michael Butler i...@protected-networks.net writes: I have a custom kernel for my laptop which uses ATA_CAM rather than the now aging ATA driver .. You do realize that ATA_CAM just (well, mostly) introduces a wrapper around the now aging ATA driver ? Only for legacy drives, but since Micahel's panic message contains current process = 12 (irq15: ata1), his BIOS is probably in legacy mode. Sorry, I misparsed ATA_CAM as ahci. Why on earth would anyone want to use ATA_CAM these days? Because there is still a lot of legacy controllers, while ata(4)'s bus management code is buggy in some aspects, that are difficult to fix without complete rewrite. ATA_CAM wrapper replaces all that problematic code and works better now. -- 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: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
on 27/07/2010 20:20 Anton Shterenlikht said the following:
yes, thanks, the panic has gone away.
There still seems to be a problem with this device:
hd...@pci0:0:20:2:class=0x040300 card=0x30c2103c chip=0x43831002 rev=0x00
hdr=0x00
vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
device = 'IXP SB600 High Definition Audio Controller'
class = multimedia
subclass = HDA
hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on
pci0
hdac0: HDA Driver Revision: 20100226_0142
hdac0: [ITHREAD]
hdac0: hdac_get_capabilities: Invalid rirb size (0)
device_attach: hdac0 attach returned 6
I understand from the manual, there should
be devices /dev/pcmX and /dev/dsp, but I have neither.
I'll ask in @questions.
many thanks for a quick fix!
Can you also try the following patch?
If the patch works, could you please report back `dmesg | fgrep -i hda` output?
diff --git a/sys/dev/sound/pci/hda/hdac.c b/sys/dev/sound/pci/hda/hdac.c
index 22ea4c8..a5556d2 100644
--- a/sys/dev/sound/pci/hda/hdac.c
+++ b/sys/dev/sound/pci/hda/hdac.c
@@ -1609,7 +1609,15 @@ hdac_get_capabilities(struct hdac_softc *sc)
else {
device_printf(sc-dev, %s: Invalid corb size (%x)\n,
__func__, corbsize);
- return (ENXIO);
+ if (corbsize == 0) {
+ device_printf(sc-dev, Resetting corb size to 256\n);
+ sc-corb_size = 256;
+ corbsize =
+ HDAC_CORBSIZE_CORBSIZE(HDAC_CORBSIZE_CORBSIZE_256);
+ HDAC_WRITE_1(sc-mem, HDAC_CORBSIZE, corbsize);
+ }
+ else
+ return (ENXIO);
}
rirbsize = HDAC_READ_1(sc-mem, HDAC_RIRBSIZE);
@@ -1625,7 +1633,15 @@ hdac_get_capabilities(struct hdac_softc *sc)
else {
device_printf(sc-dev, %s: Invalid rirb size (%x)\n,
__func__, rirbsize);
- return (ENXIO);
+ if (rirbsize == 0) {
+ device_printf(sc-dev, Resetting rirb size to 256\n);
+ sc-rirb_size = 256;
+ rirbsize =
+ HDAC_RIRBSIZE_RIRBSIZE(HDAC_RIRBSIZE_RIRBSIZE_256);
+ HDAC_WRITE_1(sc-mem, HDAC_RIRBSIZE, rirbsize);
+ }
+ else
+ return (ENXIO);
}
HDA_BOOTVERBOSE(
--
Andriy Gapon
___
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: mmap() problem
In message 201007281056.43100.hsela...@c2i.net, Hans Petter Selasky writes: When is it safe to free memory which has been mmapped to a user-space application? After close() or during close() or before close() or when the process/thread terminates? Assuming you mean memory activated via devsw-mmap: never. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
free(sc, M_DEVBUF) [Was: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)]
on 27/07/2010 19:53 Gavin Atkinson said the following: Thanks. Can you try http://people.freebsd.org/~gavin/mexas-hda-panic.diff and see if that solves things for you? (Credit goes to avg@ for looking into this before me :) BTW, it seems that there is an epidemic of free(sc, M_DEVBUF) in sound drivers. And not only them, but I haven't looked at the other cases - perhaps the code there does something different and thus correct. glimpse -w M_DEVBUF | fgrep -w free | fgrep '(sc,' /usr/src/sys/dev/sound/pci/hda/hdac.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_lagg.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_lagg.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_lagg.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_bridge.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_bridge.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ich.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ich.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/maestro3.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/maestro3.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_enc.c: free(sc, M_DEVBUF); /usr/src/sys/sun4v/sun4v/simdisk.c: free(sc, M_DEVBUF); /usr/src/sys/dev/ofw/ofw_disk.c:free(sc, M_DEVBUF); /usr/src/sys/dev/sound/isa/ess.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/sbus/cs4231.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/atiixp.c:free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10kx-pcm.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10kx-pcm.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10kx-pcm.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ds1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ds1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cmi.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cmi.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/solo.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/als4000.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/als4000.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/vibes.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10k1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10k1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cs4281.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cs4281.c: free(sc, M_DEVBUF); Good example of how get examples get multiplied. P.S. Actually all non-sound case seem to be correct, explicitly malloc-ed memory gets freed. -- Andriy Gapon ___ 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: free(sc, M_DEVBUF) [Was: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)]
On Wed, Jul 28, 2010 at 04:14:10PM +0300, Andriy Gapon wrote: on 27/07/2010 19:53 Gavin Atkinson said the following: Thanks. Can you try http://people.freebsd.org/~gavin/mexas-hda-panic.diff and see if that solves things for you? (Credit goes to avg@ for looking into this before me :) BTW, it seems that there is an epidemic of free(sc, M_DEVBUF) in sound drivers. And not only them, but I haven't looked at the other cases - perhaps the code there does something different and thus correct. glimpse -w M_DEVBUF | fgrep -w free | fgrep '(sc,' /usr/src/sys/dev/sound/pci/hda/hdac.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_lagg.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_lagg.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_lagg.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_bridge.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_bridge.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ich.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ich.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/maestro3.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/maestro3.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_enc.c: free(sc, M_DEVBUF); /usr/src/sys/sun4v/sun4v/simdisk.c: free(sc, M_DEVBUF); /usr/src/sys/dev/ofw/ofw_disk.c:free(sc, M_DEVBUF); /usr/src/sys/dev/sound/isa/ess.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/sbus/cs4231.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/atiixp.c:free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10kx-pcm.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10kx-pcm.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10kx-pcm.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ds1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ds1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cmi.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cmi.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/solo.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/als4000.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/als4000.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/vibes.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10k1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10k1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cs4281.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cs4281.c: free(sc, M_DEVBUF); Good example of how get examples get multiplied. P.S. Actually all non-sound case seem to be correct, explicitly malloc-ed memory gets freed. If anybody goes to make infrastructure work on the sound drivers, it might be not that bad idea to replace clone.c with cdevpriv. pgpBKC2T791a0.pgp Description: PGP signature
Re: BSD grep fixes
Em 2010.07.27. 5:59, b. f. escreveu: Other important differences between bsdgrep and GNU grep: The --include option in bsdgrep does not have the same effect as the corresponding option in GNU grep -- in GNU grep, that option causes _only_ those files matching the file inclusion pattern to be searched. To obtain the same behavior in bsdgrep, one must issue something like --exclude '*' --include pattern. The effect of multiple overlapping --include and --exclude options is different in the two greps. It would be wise to add comments about precedence of such options in the bsdgrep manpage, as is done, for example, in bsdtar(1). Thanks for bringing this up, I'll take a look and try to implement the same behaviour. And I will also document the behaviour. Gabor ___ 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: BSD grep fixes
On 7/28/10, Gabor Kovesdan ga...@freebsd.org wrote: Em 2010.07.27. 5:59, b. f. escreveu: Thanks for bringing this up, I'll take a look and try to implement the same behaviour. And I will also document the behaviour. I don't think that the current behavior of bsdgrep is necessarily bad -- in fact it seems to me to be simple and intuitive: nothing is excluded or included implicitly, and (I think) the last match wins, unlike in gnu grep. I mention it only because it is different, and you may want to consider how closely you want it to mimic the behavior of gnu grep for the sake of compatibility. If bsdgrep already passed a ports exp-run, and build/installworld now work without any problems, then it may be simpler to just retain the current behavior. Either way, though, the effect of overlapping --(in|ex)clude(-dir) options should be explicitly mentioned in the manpage. Thank you, by the way, for your efforts to provide us with good BSD-licensed tools. I hope that you can find the time and energy to continue with the iconv, regex, and other text-processing tool improvements. b. ___ 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: BSD grep fixes
Em 2010.07.28. 17:26, b. f. escreveu: I don't think that the current behavior of bsdgrep is necessarily bad -- in fact it seems to me to be simple and intuitive: nothing is excluded or included implicitly, and (I think) the last match wins, unlike in gnu grep. I mention it only because it is different, and you may want to consider how closely you want it to mimic the behavior of gnu grep for the sake of compatibility. If bsdgrep already passed a ports exp-run, and build/installworld now work without any problems, then it may be simpler to just retain the current behavior. Either way, though, the effect of overlapping --(in|ex)clude(-dir) options should be explicitly mentioned in the manpage. Thank you, by the way, for your efforts to provide us with good BSD-licensed tools. I hope that you can find the time and energy to continue with the iconv, regex, and other text-processing tool improvements. Ok, thanks, then I'll just document it. Actually, I also think this behaviour is more intuitive, that's why I implemented it in this way. As for iconv, it needs a portbuild run and in first phase ports will still use GNU libiconv but BSD iconv will make its way into base if it passes the exp-run. Gabor ___ 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: BSD grep fixes
Gabor Kovesdan ga...@freebsd.org writes: b. f. bf1...@gmail.com writes: I don't think that the current behavior of bsdgrep is necessarily bad -- in fact it seems to me to be simple and intuitive: nothing is excluded or included implicitly, and (I think) the last match wins, unlike in gnu grep. Ok, thanks, then I'll just document it. Uh, no. GNU grep's behavior is consistent with just about everything else that has --include / --exclude options, e.g. tar and rsync. Please change BSD grep's behavior to match GNU grep's. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
On Wed, Jul 28, 2010 at 03:56:34PM +0300, Andriy Gapon wrote:
on 27/07/2010 20:20 Anton Shterenlikht said the following:
yes, thanks, the panic has gone away.
There still seems to be a problem with this device:
hd...@pci0:0:20:2: class=0x040300 card=0x30c2103c chip=0x43831002 rev=0x00
hdr=0x00
vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
device = 'IXP SB600 High Definition Audio Controller'
class = multimedia
subclass = HDA
hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2
on pci0
hdac0: HDA Driver Revision: 20100226_0142
hdac0: [ITHREAD]
hdac0: hdac_get_capabilities: Invalid rirb size (0)
device_attach: hdac0 attach returned 6
I understand from the manual, there should
be devices /dev/pcmX and /dev/dsp, but I have neither.
I'll ask in @questions.
many thanks for a quick fix!
Can you also try the following patch?
If the patch works, could you please report back `dmesg | fgrep -i hda`
output?
here it is:
% dmesg|fgrep -i hda
pci0: multimedia, HDA at device 20.2 (no driver attached)
pci0: multimedia, HDA at device 20.2 (no driver attached)
hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on
pci0
hdac0: HDA Driver Revision: 20100226_0142
hdac0: [ITHREAD]
hdac0: hdac_get_capabilities: Invalid rirb size (0)
device_attach: hdac0 attach returned 6
hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on
pci0
hdac0: HDA Driver Revision: 20100226_0142
hdac0: [ITHREAD]
hdac0: hdac_get_capabilities: Invalid rirb size (0)
hdac0: Resetting rirb size to 256
many thanks
anton
diff --git a/sys/dev/sound/pci/hda/hdac.c b/sys/dev/sound/pci/hda/hdac.c
index 22ea4c8..a5556d2 100644
--- a/sys/dev/sound/pci/hda/hdac.c
+++ b/sys/dev/sound/pci/hda/hdac.c
@@ -1609,7 +1609,15 @@ hdac_get_capabilities(struct hdac_softc *sc)
else {
device_printf(sc-dev, %s: Invalid corb size (%x)\n,
__func__, corbsize);
- return (ENXIO);
+ if (corbsize == 0) {
+ device_printf(sc-dev, Resetting corb size to 256\n);
+ sc-corb_size = 256;
+ corbsize =
+ HDAC_CORBSIZE_CORBSIZE(HDAC_CORBSIZE_CORBSIZE_256);
+ HDAC_WRITE_1(sc-mem, HDAC_CORBSIZE, corbsize);
+ }
+ else
+ return (ENXIO);
}
rirbsize = HDAC_READ_1(sc-mem, HDAC_RIRBSIZE);
@@ -1625,7 +1633,15 @@ hdac_get_capabilities(struct hdac_softc *sc)
else {
device_printf(sc-dev, %s: Invalid rirb size (%x)\n,
__func__, rirbsize);
- return (ENXIO);
+ if (rirbsize == 0) {
+ device_printf(sc-dev, Resetting rirb size to 256\n);
+ sc-rirb_size = 256;
+ rirbsize =
+ HDAC_RIRBSIZE_RIRBSIZE(HDAC_RIRBSIZE_RIRBSIZE_256);
+ HDAC_WRITE_1(sc-mem, HDAC_RIRBSIZE, rirbsize);
+ }
+ else
+ return (ENXIO);
}
HDA_BOOTVERBOSE(
--
Andriy Gapon
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
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: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
on 28/07/2010 19:01 Anton Shterenlikht said the following: here it is: So did it work? :) % dmesg|fgrep -i hda pci0: multimedia, HDA at device 20.2 (no driver attached) pci0: multimedia, HDA at device 20.2 (no driver attached) hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid rirb size (0) device_attach: hdac0 attach returned 6 I presume the above is from previous load attempt? hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid rirb size (0) hdac0: Resetting rirb size to 256 Hmm, so no message about corb, just rirb? Also, no codec and pcm output lines? Did the driver get attached? -- Andriy Gapon ___ 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: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
On Wed, Jul 28, 2010 at 07:07:34PM +0300, Andriy Gapon wrote: on 28/07/2010 19:01 Anton Shterenlikht said the following: here it is: So did it work? :) not as far as I can tell % dmesg|fgrep -i hda pci0: multimedia, HDA at device 20.2 (no driver attached) pci0: multimedia, HDA at device 20.2 (no driver attached) hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid rirb size (0) device_attach: hdac0 attach returned 6 I presume the above is from previous load attempt? yes, probably. I think /var/run/dmesg used to contain only the current boot, but some time ago I noticed that quite a few previous boots are stored. Or maybe it's my misconfiguration.. hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid rirb size (0) hdac0: Resetting rirb size to 256 Hmm, so no message about corb, just rirb? Also, no codec and pcm output lines? Did the driver get attached? As far as I can (cannot) see, the driver didn't attach. There's no /dev/dsp or /dev/pcm. % cat /dev/sndstat FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: % I also get (probably not related) % dmesg|grep dead Event timer i8254 is dead. % many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
on 28/07/2010 19:17 Anton Shterenlikht said the following: On Wed, Jul 28, 2010 at 07:07:34PM +0300, Andriy Gapon wrote: on 28/07/2010 19:01 Anton Shterenlikht said the following: here it is: So did it work? :) not as far as I can tell % dmesg|fgrep -i hda pci0: multimedia, HDA at device 20.2 (no driver attached) pci0: multimedia, HDA at device 20.2 (no driver attached) hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid rirb size (0) device_attach: hdac0 attach returned 6 I presume the above is from previous load attempt? yes, probably. I think /var/run/dmesg used to contain only the current boot, but some time ago I noticed that quite a few previous boots are stored. Or maybe it's my misconfiguration.. Did you just kldload the module? Or do you have hda in your kernel and you performed a reboot? If you didn't reboot, can you do it now? hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid rirb size (0) hdac0: Resetting rirb size to 256 Hmm, so no message about corb, just rirb? So no corb message? This seems very strange, especially given the subject line. Also, no codec and pcm output lines? Did the driver get attached? As far as I can (cannot) see, the driver didn't attach. There's no /dev/dsp or /dev/pcm. What is output of the following command? kldstat -v | egrep 'sound|snd' % cat /dev/sndstat FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: % I also get (probably not related) % dmesg|grep dead Event timer i8254 is dead. % You can try to use a different timer. See sysctl kern.eventtimer, you can override timer1 and timer2 in your loader.conf. -- Andriy Gapon ___ 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: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
On Wed, Jul 28, 2010 at 07:33:44PM +0300, Andriy Gapon wrote: on 28/07/2010 19:17 Anton Shterenlikht said the following: On Wed, Jul 28, 2010 at 07:07:34PM +0300, Andriy Gapon wrote: on 28/07/2010 19:01 Anton Shterenlikht said the following: here it is: So did it work? :) not as far as I can tell % dmesg|fgrep -i hda pci0: multimedia, HDA at device 20.2 (no driver attached) pci0: multimedia, HDA at device 20.2 (no driver attached) hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid rirb size (0) device_attach: hdac0 attach returned 6 I presume the above is from previous load attempt? yes, probably. I think /var/run/dmesg used to contain only the current boot, but some time ago I noticed that quite a few previous boots are stored. Or maybe it's my misconfiguration.. Did you just kldload the module? Or do you have hda in your kernel and you performed a reboot? If you didn't reboot, can you do it now? it's in the kernel, and yes, I did reboot. So no corb message? This seems very strange, especially given the subject line. But I just rebooted again, and reset to defaults in BIOS, now I get: % dmesg | fgrep -i hda hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid corb size (1) device_attach: hdac0 attach returned 6 Also, no codec and pcm output lines? Did the driver get attached? As far as I can (cannot) see, the driver didn't attach. There's no /dev/dsp or /dev/pcm. What is output of the following command? kldstat -v | egrep 'sound|snd' % kldstat -v | egrep 'sound|snd' 139 sound 138 pci/snd_hda 137 hdac/snd_hda_pcm thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
on 28/07/2010 19:44 Anton Shterenlikht said the following: But I just rebooted again, and reset to defaults in BIOS, now I get: % dmesg | fgrep -i hda hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid corb size (1) device_attach: hdac0 attach returned 6 This gets even stranger. Ultimate attempt - can you drop the size == 0 condition, so that reset is always tried when initial value is not correct? Then, of course, build and install new kernel and reboot. If possible, with power down to get the cleanest results. P.S. I lied actually - the ultimate attempt would be to not even try to read CORB and RIRB size and just force them to 256 always. It seems that's what Linux driver does. -- Andriy Gapon ___ 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: free(sc, M_DEVBUF) [Was: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)]
On Wed, Jul 28, 2010 at 04:14:10PM +0300, Andriy Gapon wrote: on 27/07/2010 19:53 Gavin Atkinson said the following: Thanks. Can you try http://people.freebsd.org/~gavin/mexas-hda-panic.diff and see if that solves things for you? (Credit goes to avg@ for looking into this before me :) BTW, it seems that there is an epidemic of free(sc, M_DEVBUF) in sound drivers. And not only them, but I haven't looked at the other cases - perhaps the code there does something different and thus correct. glimpse -w M_DEVBUF | fgrep -w free | fgrep '(sc,' /usr/src/sys/dev/sound/pci/hda/hdac.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_lagg.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_lagg.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_lagg.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_bridge.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_bridge.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ich.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ich.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/maestro3.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/maestro3.c: free(sc, M_DEVBUF); /usr/src/sys/net/if_enc.c: free(sc, M_DEVBUF); /usr/src/sys/sun4v/sun4v/simdisk.c: free(sc, M_DEVBUF); /usr/src/sys/dev/ofw/ofw_disk.c:free(sc, M_DEVBUF); /usr/src/sys/dev/sound/isa/ess.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/sbus/cs4231.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/atiixp.c:free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10kx-pcm.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10kx-pcm.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10kx-pcm.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ds1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/ds1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cmi.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cmi.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/neomagic.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/solo.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/als4000.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/als4000.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/vibes.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10k1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/emu10k1.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cs4281.c: free(sc, M_DEVBUF); /usr/src/sys/dev/sound/pci/cs4281.c: free(sc, M_DEVBUF); Good example of how get examples get multiplied. When I started to write snd_audiocs(4) for sparc64 I also noticed that. The practice of sound driver was to explicitly allocate softc structure in device attach routine and release it after use. I don't remember details but other parts of sound subsystem seemed to rely on the structure and changing it to use standard device_get_softc(9) was not easy task. P.S. Actually all non-sound case seem to be correct, explicitly malloc-ed memory gets freed. -- Andriy Gapon ___ 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: free(sc, M_DEVBUF) [Was: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)]
on 28/07/2010 19:59 Pyun YongHyeon said the following: When I started to write snd_audiocs(4) for sparc64 I also noticed that. The practice of sound driver was to explicitly allocate softc structure in device attach routine and release it after use. I don't remember details but other parts of sound subsystem seemed to rely on the structure and changing it to use standard device_get_softc(9) was not easy task. Oh, I see what you mean. So those drivers do malloc their softc. snd_hda was (is) the only one that got it via device_get_softc, but still used free(9) on it in the case of attachment failure. -- Andriy Gapon ___ 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: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
On Wed, Jul 28, 2010 at 07:51:08PM +0300, Andriy Gapon wrote:
on 28/07/2010 19:44 Anton Shterenlikht said the following:
But I just rebooted again, and reset
to defaults in BIOS, now I get:
% dmesg | fgrep -i hda
hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2
on pci0
hdac0: HDA Driver Revision: 20100226_0142
hdac0: [ITHREAD]
hdac0: hdac_get_capabilities: Invalid corb size (1)
device_attach: hdac0 attach returned 6
This gets even stranger.
Ultimate attempt - can you drop the size == 0 condition, so that reset is
always
tried when initial value is not correct?
you mean drop both
if (corbsize == 0) {}
and
if (rirbsize == 0) {}
?
Or did I get you wrong?
anton
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
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: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
on 28/07/2010 20:13 Anton Shterenlikht said the following:
On Wed, Jul 28, 2010 at 07:51:08PM +0300, Andriy Gapon wrote:
on 28/07/2010 19:44 Anton Shterenlikht said the following:
But I just rebooted again, and reset
to defaults in BIOS, now I get:
% dmesg | fgrep -i hda
hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2
on pci0
hdac0: HDA Driver Revision: 20100226_0142
hdac0: [ITHREAD]
hdac0: hdac_get_capabilities: Invalid corb size (1)
device_attach: hdac0 attach returned 6
This gets even stranger.
Ultimate attempt - can you drop the size == 0 condition, so that reset is
always
tried when initial value is not correct?
you mean drop both
if (corbsize == 0) {}
and
if (rirbsize == 0) {}
?
Change it to if (1) { ...}.
--
Andriy Gapon
___
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
Interrupt Problems
Hi, I have been having interrupt related problems with various subsystems. I suspect this is related to the changes in the event timer infrastructure. The subsystems that have experienced interrupt problems: - hda: this is the easiest to reproduce and what I used to isolate the commits. I get ``pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead'' reported and sound no longer plays. - nfe: this has happened on occasion with no reliable way to reproduce. ``watchdog timeouts'' are reported. After this happens all network traffic dies and doing `ifconfig nfe0 down; ifconfig nfe0 up' panics the computer. - dc: same thing as above. - nvidia: has reported interrupt timeouts. This is independent of the locking problem (that is fixed with recently published patch). No reliable way to reproduce, appears to happen when under heavy load. X freezes as a result. - ata: I had a HDD detach twice. I am not sure if this is related. I have two HDD, each attached to a different controller. I tested this by using a kernel built from a cvsup date of 2010/06/20 and 2010/06/22 (at midnight for both, aka 00:00:00). The former kernel does not exhibit any problems while the latter does. This problem is also present with a kernel from today. The motherboard is a N650SLI-DS4L with one graphics card. See attached for more system information. Is there anything I can do to help diagnose the problem? Regards, David kern.eventtimer.choice: LAPIC(500) HPET(450) HPET1(440) HPET2(440) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 14794 kern.eventtimer.et.LAPIC.quality: 500 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 2500 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 2500 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 2500 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.timer2: HPET kern.eventtimer.timer1: LAPIC kern.eventtimer.singlemul: 2 kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) i8254(0) ACPI-fast(1000) dummy(-100) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 2199550 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 46239 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 2739146685 kern.timecounter.tc.HPET.frequency: 2500 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 2718611985 kern.timecounter.tc.TSC.frequency: 2400025995 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 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 9.0-CURRENT #1: Wed Jul 28 15:47:21 SAST 2010 r...@dragon.dg:/tmp/home/freebsd9/src/sys/GENERIC amd64 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2400.03-MHz 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) avail memory = 6163714048 (5878 MB) Event timer LAPIC frequency 0 Hz quality 500 ACPI APIC Table: GBTNVDAACPI FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 2 ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: GBT NVDAACPI on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, cfef (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 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
Panic booting vmware i386 after SRAT update
I have a 2 cpu virtual image of FreeBSD current. It panics during boot after building in the NUMA support. I'll transcribe the SRAT bootverbose messages and panic message as best I can. Table 'SRAT' at 0xfef07f6 SRAT: Found table at 0xfef07f6 SRAT: Found memory domain 0 addr 0 len a: enabled SRAT: Found memory domain 0 addr 10 len ff0: enabled then some MADT: messages about finding cpu 0 and 1 cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 panic: SRAT: CPU with APIC ID 0 is not known I'm playing around now with trying to figure out what went missing, but I thought I'd send this out now. Thanks, matthew ___ 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: Panic booting vmware i386 after SRAT update
On Wed, Jul 28, 2010 at 10:37 AM, m...@freebsd.org wrote: I have a 2 cpu virtual image of FreeBSD current. It panics during boot after building in the NUMA support. I'll transcribe the SRAT bootverbose messages and panic message as best I can. Table 'SRAT' at 0xfef07f6 SRAT: Found table at 0xfef07f6 SRAT: Found memory domain 0 addr 0 len a: enabled SRAT: Found memory domain 0 addr 10 len ff0: enabled then some MADT: messages about finding cpu 0 and 1 cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 panic: SRAT: CPU with APIC ID 0 is not known I'm playing around now with trying to figure out what went missing, but I thought I'd send this out now. Okay, apparently VMWare is providing two entries of type ACPI_SRAT_TYPE_MEMORY_AFFINITY but no entries of type ACPI_SRAT_TYPE_CPU_AFFINITY. This leads to the assert since no CPUs are enabled; that is there's no affinity information for them. This is probably a VMWare bug. Setting hint.srat.0.disabled=1 in /boot/device.hints works around the issue. Thanks, matthew ___ 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: Interrupt Problems
David Naylor wrote: I have been having interrupt related problems with various subsystems. I suspect this is related to the changes in the event timer infrastructure. The subsystems that have experienced interrupt problems: - hda: this is the easiest to reproduce and what I used to isolate the commits. I get ``pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead'' reported and sound no longer plays. - nfe: this has happened on occasion with no reliable way to reproduce. ``watchdog timeouts'' are reported. After this happens all network traffic dies and doing `ifconfig nfe0 down; ifconfig nfe0 up' panics the computer. - dc: same thing as above. - nvidia: has reported interrupt timeouts. This is independent of the locking problem (that is fixed with recently published patch). No reliable way to reproduce, appears to happen when under heavy load. X freezes as a result. - ata: I had a HDD detach twice. I am not sure if this is related. I have two HDD, each attached to a different controller. I tested this by using a kernel built from a cvsup date of 2010/06/20 and 2010/06/22 (at midnight for both, aka 00:00:00). The former kernel does not exhibit any problems while the latter does. This problem is also present with a kernel from today. The motherboard is a N650SLI-DS4L with one graphics card. See attached for more system information. Is there anything I can do to help diagnose the problem? Hardly I can explain how timer related changes could cause problems with such a long list of devices, using different IRQs. MCP51 seems to have quite bright history of different problems (at least I know about SATA and HDA MSI problems), so I won't be very surprised if it is some one more hardware-specific issue. Does problem happens randomly or can be triggered somehow? Have you tried to look what happens with interrupts during/after the problem appears? Are all of them dying or selectively each time? Is there way to restore operation after problem? Have you tried to switch to using other event timers? HPET event timers were never used before this, so bugs are not studied yet. PS: Verbose dmesg could be more useful. -- 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: Interrupt Problems
David Naylor wrote: I have been having interrupt related problems with various subsystems. I suspect this is related to the changes in the event timer infrastructure. The subsystems that have experienced interrupt problems: - hda: this is the easiest to reproduce and what I used to isolate the commits. I get ``pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead'' reported and sound no longer plays. - nfe: this has happened on occasion with no reliable way to reproduce. ``watchdog timeouts'' are reported. After this happens all network traffic dies and doing `ifconfig nfe0 down; ifconfig nfe0 up' panics the computer. - dc: same thing as above. - nvidia: has reported interrupt timeouts. This is independent of the locking problem (that is fixed with recently published patch). No reliable way to reproduce, appears to happen when under heavy load. X freezes as a result. - ata: I had a HDD detach twice. I am not sure if this is related. I have two HDD, each attached to a different controller. I tested this by using a kernel built from a cvsup date of 2010/06/20 and 2010/06/22 (at midnight for both, aka 00:00:00). The former kernel does not exhibit any problems while the latter does. This problem is also present with a kernel from today. The motherboard is a N650SLI-DS4L with one graphics card. See attached for more system information. Is there anything I can do to help diagnose the problem? When you say midnight on June 22, is that 11:59pm June 22 or 12:01 am June 22? I don't expect it, but there's a possibility that r210377 affected this. Can you check whether sys/sys/_task.h changes between the kernel that does work and the one that doesn't? Thanks, matthew ___ 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: Panic booting vmware i386 after SRAT update
On Wed, Jul 28, 2010 at 7:37 AM, m...@freebsd.org wrote: I have a 2 cpu virtual image of FreeBSD current. It panics during boot after building in the NUMA support. I'll transcribe the SRAT bootverbose messages and panic message as best I can. Table 'SRAT' at 0xfef07f6 SRAT: Found table at 0xfef07f6 SRAT: Found memory domain 0 addr 0 len a: enabled SRAT: Found memory domain 0 addr 10 len ff0: enabled then some MADT: messages about finding cpu 0 and 1 cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 panic: SRAT: CPU with APIC ID 0 is not known I'm playing around now with trying to figure out what went missing, but I thought I'd send this out now. Thanks, matthew ___ 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 I have been seeing this since yesterday with amd64 custom kernels - just compiled a GENERIC kernel a few minutes ago and it shows the same symptom. ___ 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: Panic booting vmware i386 after SRAT update
On Wed, Jul 28, 2010 at 11:19 AM, David Cornejo d...@dogwood.com wrote: On Wed, Jul 28, 2010 at 7:37 AM, m...@freebsd.org wrote: I have a 2 cpu virtual image of FreeBSD current. It panics during boot after building in the NUMA support. I'll transcribe the SRAT bootverbose messages and panic message as best I can. Table 'SRAT' at 0xfef07f6 SRAT: Found table at 0xfef07f6 SRAT: Found memory domain 0 addr 0 len a: enabled SRAT: Found memory domain 0 addr 10 len ff0: enabled then some MADT: messages about finding cpu 0 and 1 cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 panic: SRAT: CPU with APIC ID 0 is not known I'm playing around now with trying to figure out what went missing, but I thought I'd send this out now. I have been seeing this since yesterday with amd64 custom kernels - just compiled a GENERIC kernel a few minutes ago and it shows the same symptom. Is this on VMWare or physical hardware? I isolated my issue to VMWare reporting memory domains properties but not CPU affinity. Setting hint.srat.0.disabled=1 in /boot/device.hints fixes the issue for me. Thanks, matthew ___ 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: Panic booting vmware i386 after SRAT update
On Wed, Jul 28, 2010 at 8:23 AM, m...@freebsd.org wrote: On Wed, Jul 28, 2010 at 10:37 AM, m...@freebsd.org wrote: I have a 2 cpu virtual image of FreeBSD current. It panics during boot after building in the NUMA support. I'll transcribe the SRAT bootverbose messages and panic message as best I can. Table 'SRAT' at 0xfef07f6 SRAT: Found table at 0xfef07f6 SRAT: Found memory domain 0 addr 0 len a: enabled SRAT: Found memory domain 0 addr 10 len ff0: enabled then some MADT: messages about finding cpu 0 and 1 cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 panic: SRAT: CPU with APIC ID 0 is not known I'm playing around now with trying to figure out what went missing, but I thought I'd send this out now. Okay, apparently VMWare is providing two entries of type ACPI_SRAT_TYPE_MEMORY_AFFINITY but no entries of type ACPI_SRAT_TYPE_CPU_AFFINITY. This leads to the assert since no CPUs are enabled; that is there's no affinity information for them. This is probably a VMWare bug. Setting hint.srat.0.disabled=1 in /boot/device.hints works around the issue. Thanks, matthew ___ 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 GENERIC amd64 kernel with the hint dies earlier: WARNING: WITNESS option enabled, expect reduced performance panic: witness_init: pending locks list is too small, bump it cpuid = 0 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at kdb_enter+0x3d: movq$0,0x6d6fb0(%rip) db ___ 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: BSD grep fixes
Em 2010.07.28. 17:48, Dag-Erling Smørgrav escreveu: Gabor Kovesdanga...@freebsd.org writes: b. f.bf1...@gmail.com writes: I don't think that the current behavior of bsdgrep is necessarily bad -- in fact it seems to me to be simple and intuitive: nothing is excluded or included implicitly, and (I think) the last match wins, unlike in gnu grep. Ok, thanks, then I'll just document it. Uh, no. GNU grep's behavior is consistent with just about everything else that has --include / --exclude options, e.g. tar and rsync. Please change BSD grep's behavior to match GNU grep's. Ok, thanks for mentioning this. I already have a patch to implement the same behaviour, I'll discuss it with my mentor and fix soon. Gabor ___ 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
Check out my photos on Facebook
Hi Current, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Aryeh To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=11116366558k=Z6E3Y6VZS4XAZGLJVF2ZP4XWS6BAW43BQRFQr Already have an account? Add this email address to your account: http://www.facebook.com/n/?merge_accounts.phpe=current%40freebsd.orgc=e42687a96930450f5fd9ae6981e0cbd2 === curr...@freebsd.org was invited to join Facebook by Aryeh Friedman. If you do not wish to receive this type of email from Facebook in the future, please click on the link below to unsubscribe. http://www.facebook.com/o.php?k=b43b2au=744619940mid=2bad217G2c61ffa4G0G8 Facebook, Inc. P.O. Box 10005, Palo Alto, CA 94303 ___ 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: k3b causing system freeze/panic
On Wed, Jul 28, 2010 at 01:42:30PM +0200, Dag-Erling Sm??rgrav wrote: Sorry, I misparsed ATA_CAM as ahci. Why on earth would anyone want to use ATA_CAM these days? Well, I am not sure if you really meant ATA_CAM and not ATAPICAM? But in case you meant it, for people who do not use SATA-capable hardware, ATA_CAM is useful. This laptop may be no longer be the most recent model these days, but runs -CURRENT just fine most of the time. Also, if I remember correctly, for people with a bit more recent controllers ATA_CAM offers other advantages, but those do not affect me. So, for me ATA_CAM is just a better version of the ata(4) driver... -- Regards: Szilveszter ADAM Budapest Hungary ___ 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
