Re: Kernel panic when unpluggin AC adaptor
2010/5/25 Giovanni Trematerra : > On Tue, May 25, 2010 at 5:52 PM, David DEMELIER > wrote: >> 2010/5/25 Giovanni Trematerra : >>> On Mon, May 24, 2010 at 9:43 PM, David DEMELIER >>> wrote: 2010/5/12 Giovanni Trematerra : > On Fri, May 7, 2010 at 8:33 PM, Demelier David > wrote: >> Le Vendredi 07 mai 2010 à 18:22 +0200, Giovanni Trematerra a écrit : >>> On Fri, May 7, 2010 at 2:08 PM, Demelier David >>> wrote: >>> > Hi, >>> > I noticed that pluggin the AC adaptor when I boot without it >>> > does not >>> > panic. It only panic when removing it. >>> > >>> > Maybe that could help ? >>> > >>> >>> Good to know. The problem lies somewhere when performance state change. >>> In your case it happens when you remove AC adaptor. Let's hope someone >>> on >>> acpi@ ml comes up with a good idea. >>> >> >> Okay so for the moment no change, I'll wait for someone with an idea >> that could solve my problem. For me because the panic only happens when >> changing profile from ac plugged -> ac unplugged (and not the reverse) I >> would think it's a cpu related acpi issue. >> > > I looked deeper and it seems to me that when you unplug the AC > adapter, acpi_cpu_notify calls acpi_cpu_cx_cst that try to allocate a > new cx_ptr->p_lvlx via acpi_PkgGas. > If acpi_PkgGas set cx_ptr->p_lvlx to NULL for any reasons you'll have > the panic that you reported. > A solution would be to set acpi_cpu_hook to NULL so acpi_cpu_idle won't > call it. > I need some time to have a patch because of the possible race between > acpi_cpu_notify and > acpi_cpu_idle during set acpi_cpu_hook to NULL. > if you have time and want panic your system you could try the attached > patch, just to be > sure that we catch it. > Hi, it paniced today ! I don't know why it randomly panic but it did, the backtrace didn't change. There is a picture about the panic : http://img541.imageshack.us/img541/2773/dsc00388xa.jpg >>> >>> What was you trying? acpi_idle5.diff.txt patch? >>> How did it panic? Unplugging AC adapter? >>> >> >> Hi, I tried this one : lvlx.diff.txt. Yes by unplugging the AC adapter. >> > > This is an old one. Could you try acpi_idle5.diff.txt? I kept you in > Cc when I sent to > the list. If you have problems, let me know, I'll resend to you the patch. > > Thank you. > Hi, it panic'ed with the same backtrace. Thanks. -- Demelier David ___ 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: Buzzing snd_emu10kx enabled card with r206173
On 25/05/2010 20:05, Garrett Cooper wrote: > On Tue, May 25, 2010 at 3:06 AM, Mark Stapper wrote: > >> On 18/05/2010 08:14, Mark Stapper wrote: >> >>> On 18/05/2010 00:22, Garrett Cooper wrote: >>> >>> On Mon, May 17, 2010 at 11:21 AM, Mark Stapper wrote: > On 12/04/2010 16:29, Garrett Cooper wrote: > > > >> On Tue, Apr 6, 2010 at 3:39 AM, Garrett Cooper >> wrote: >> >> >> >> >>> On Mon, Apr 5, 2010 at 12:26 PM, Garrett Cooper >>> wrote: >>> >>> >>> >>> On Mon, Apr 5, 2010 at 11:22 AM, Garrett Cooper wrote: > Hi, >When I first installed FreeBSD on this machine, I had a heck of a > time getting the soundcard's PCM channel to function properly. It > would buzz incessantly when I played any audio on it; I disabled the > onboard snd_hda enabled audio and things magically worked, until > today. After a kernel upgrade and a few warm boots, I'm back to where > I started from -- the PCM channel buzzes whenever I play audio; > line-in works perfectly fine however. I'm not seeing anything out of > the ordinary in commits over the past couple of weeks for the pcm > pieces (the last successful kernel I used was 2~3 weeks old). >Are there any device_printf's I should add or a debug procedure > that you recommend I do to triage the situation? > Thanks, > -Garrett > > # uname -a > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206173M: > Sun Apr 4 19:54:22 PDT 2010 > r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > # pciconf -lv | grep -A 4 emu > emu10...@pci0:8:0:0:class=0x040100 card=0x10211102 chip=0x00081102 > rev=0x00 hdr=0x00 >vendor = 'Creative Technology LTD.' >device = 'sound blaster Audigy 2 (ca0108)' >class = multimedia >subclass = audio > # dmesg | grep 'irq 16' > uhci0: port 0xa800-0xa81f > irq 16 at device 26.0 on pci0 > pcib7: irq 16 at device 28.1 on pci0 > emu10kx0: port 0xec00-0xec3f irq 16 at > device 0.0 on pci8 > # dmesg | grep 'pcm' > pcm0: on emu10kx0 > pcm0: > pcm1: on emu10kx0 > pcm2: on emu10kx0 > pcm3: on emu10kx0 > pcm4: on emu10kx0 > > > > Some more information: 1. snd_emu10kx and sound are both modules loaded on boot, along with if_re, linux, and nvidia. 2. Disabling nvidia -> no change. 3. Disabling acpi -> unbootable system because many drivers can't map interrupts without it (can't test unless I isolate the drivers and enable them one by one -- something I'll try later on). I'm at a loss right now... my hunch is that it's potentially a bad interaction between the snd_emu10kx driver and another driver on the same PCI bus (which is just the ACPI and uhci drivers), but I can't test these claims. There are other funky things about my system that have changed over the past couple of kernel versions, like front USB ports could charge my iPhone, and now they don't... and the fact that ACPI blanking via nvidia now works again... so something may have changed on the backend, but I'm not 100% sure on what I should isolate as the root cause, yet. >>> Grr... it's `healed' itself again. I'll watch out for potential >>> catalysts to the issue in the future. >>> >>> >>> >>> >> Ok. Damn issue came back and here's what happened. Rebooted >> several times with the same kernel and slight modifications, loading >> and unloading snd_emu10kx and sound, testing out snd_emu10k1, and no >> dice. The buzz was bad and it was driving me insane. Again, line-in >> functioned just fine, so I didn't know what the heck was going. I was >> getting desperate, so I finally broke down and booted the Gentoo Linux >> livecd. PCM worked just fine. Then I got irritated enough and finally >> just built the module and the sound support directly into the kernel >> and everything is hunky dorey again. Does anyone have a stab in the >> dark as to what's going on? Is it a potential bus or interrupt >> conflict / race condition that gets alleviated when support is nailed >> into the kernel? Or are other folks as stumped as I am, s.t. I should >> just try emailing current@ instead to see if someone maybe knows >> what's going on there :(...? >> Thanks, >> -Garrett >>
Re: Kernel panic when unpluggin AC adaptor
On Wed, May 26, 2010 at 11:14 AM, David DEMELIER wrote: > 2010/5/25 Giovanni Trematerra : >> On Tue, May 25, 2010 at 5:52 PM, David DEMELIER >> wrote: >>> 2010/5/25 Giovanni Trematerra : On Mon, May 24, 2010 at 9:43 PM, David DEMELIER wrote: > 2010/5/12 Giovanni Trematerra : >> On Fri, May 7, 2010 at 8:33 PM, Demelier David >> wrote: >>> Le Vendredi 07 mai 2010 à 18:22 +0200, Giovanni Trematerra a écrit : On Fri, May 7, 2010 at 2:08 PM, Demelier David wrote: > Hi, > I noticed that pluggin the AC adaptor when I boot without it > does not > panic. It only panic when removing it. > > Maybe that could help ? > Good to know. The problem lies somewhere when performance state change. In your case it happens when you remove AC adaptor. Let's hope someone on acpi@ ml comes up with a good idea. >>> >>> Okay so for the moment no change, I'll wait for someone with an idea >>> that could solve my problem. For me because the panic only happens when >>> changing profile from ac plugged -> ac unplugged (and not the reverse) I >>> would think it's a cpu related acpi issue. >>> >> >> I looked deeper and it seems to me that when you unplug the AC >> adapter, acpi_cpu_notify calls acpi_cpu_cx_cst that try to allocate a >> new cx_ptr->p_lvlx via acpi_PkgGas. >> If acpi_PkgGas set cx_ptr->p_lvlx to NULL for any reasons you'll have >> the panic that you reported. >> A solution would be to set acpi_cpu_hook to NULL so acpi_cpu_idle won't >> call it. >> I need some time to have a patch because of the possible race between >> acpi_cpu_notify and >> acpi_cpu_idle during set acpi_cpu_hook to NULL. >> if you have time and want panic your system you could try the attached >> patch, just to be >> sure that we catch it. >> > > Hi, it paniced today ! I don't know why it randomly panic but it did, > the backtrace didn't change. There is a picture about the panic : > > http://img541.imageshack.us/img541/2773/dsc00388xa.jpg What was you trying? acpi_idle5.diff.txt patch? How did it panic? Unplugging AC adapter? >>> >>> Hi, I tried this one : lvlx.diff.txt. Yes by unplugging the AC adapter. >>> >> >> This is an old one. Could you try acpi_idle5.diff.txt? I kept you in >> Cc when I sent to >> the list. If you have problems, let me know, I'll resend to you the patch. >> >> Thank you. >> > > Hi, it panic'ed with the same backtrace. > Can you please post your dmesg? Thanks -- Gianni ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Kernel panic when unpluggin AC adaptor
2010/5/26 Giovanni Trematerra : > On Wed, May 26, 2010 at 11:14 AM, David DEMELIER > wrote: >> 2010/5/25 Giovanni Trematerra : >>> On Tue, May 25, 2010 at 5:52 PM, David DEMELIER >>> wrote: 2010/5/25 Giovanni Trematerra : > On Mon, May 24, 2010 at 9:43 PM, David DEMELIER > wrote: >> 2010/5/12 Giovanni Trematerra : >>> On Fri, May 7, 2010 at 8:33 PM, Demelier David >>> wrote: Le Vendredi 07 mai 2010 à 18:22 +0200, Giovanni Trematerra a écrit : > On Fri, May 7, 2010 at 2:08 PM, Demelier David > wrote: > > Hi, > > I noticed that pluggin the AC adaptor when I boot without it > > does not > > panic. It only panic when removing it. > > > > Maybe that could help ? > > > > Good to know. The problem lies somewhere when performance state > change. > In your case it happens when you remove AC adaptor. Let's hope > someone on > acpi@ ml comes up with a good idea. > Okay so for the moment no change, I'll wait for someone with an idea that could solve my problem. For me because the panic only happens when changing profile from ac plugged -> ac unplugged (and not the reverse) I would think it's a cpu related acpi issue. >>> >>> I looked deeper and it seems to me that when you unplug the AC >>> adapter, acpi_cpu_notify calls acpi_cpu_cx_cst that try to allocate a >>> new cx_ptr->p_lvlx via acpi_PkgGas. >>> If acpi_PkgGas set cx_ptr->p_lvlx to NULL for any reasons you'll have >>> the panic that you reported. >>> A solution would be to set acpi_cpu_hook to NULL so acpi_cpu_idle won't >>> call it. >>> I need some time to have a patch because of the possible race between >>> acpi_cpu_notify and >>> acpi_cpu_idle during set acpi_cpu_hook to NULL. >>> if you have time and want panic your system you could try the attached >>> patch, just to be >>> sure that we catch it. >>> >> >> Hi, it paniced today ! I don't know why it randomly panic but it did, >> the backtrace didn't change. There is a picture about the panic : >> >> http://img541.imageshack.us/img541/2773/dsc00388xa.jpg > > What was you trying? acpi_idle5.diff.txt patch? > How did it panic? Unplugging AC adapter? > Hi, I tried this one : lvlx.diff.txt. Yes by unplugging the AC adapter. >>> >>> This is an old one. Could you try acpi_idle5.diff.txt? I kept you in >>> Cc when I sent to >>> the list. If you have problems, let me know, I'll resend to you the patch. >>> >>> Thank you. >>> >> >> Hi, it panic'ed with the same backtrace. >> > > Can you please post your dmesg? > Sent ! -- Demelier David Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-PRERELEASE #3: Wed May 26 11:48:16 CEST 2010 r...@melon.malikania.fr:/usr/obj/usr/src/sys/Melon amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz (2094.77-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 3221225472 (3072 MB) avail memory = 3092127744 (2948 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x7000-0x70ff mem 0xc000-0xcfff,0xd840-0xd840 irq 16 at device 0.0 on pci1 acpi_video0: on vgapci0 hdac0: mem 0xd841-0xd8413fff irq 17 at device 0.1 on pci1 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] uhci0: port 0x80a0-0x80bf irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x8080-0x809f irq 17 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x8060-0x807f irq 18 at device 26.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xd8504400-0xd85047ff irq 19 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3:
Re: NFS trouble on 7.3-STABLE i386
On Tue, 25 May 2010 20:59:08 -0400 (EDT) Rick Macklem wrote:
You could try this patch. (It reverts the only vnode locking change that I
can see was done the the nfs server between 7.1 and 7.3.):
--- nfs_serv.c.sav 2010-05-25 19:40:29.0 -0400
+++ nfs_serv.c 2010-05-25 19:41:38.0 -0400
@@ -3236,7 +3236,7 @@
io.uio_rw = UIO_READ;
io.uio_td = NULL;
eofflag = 0;
- vn_lock(vp, LK_SHARED | LK_RETRY, td);
+ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (cookies) {
free((caddr_t)cookies, M_TEMP);
cookies = NULL;
@@ -3518,7 +3518,7 @@
io.uio_rw = UIO_READ;
io.uio_td = NULL;
eofflag = 0;
- vn_lock(vp, LK_SHARED | LK_RETRY, td);
+ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (cookies) {
free((caddr_t)cookies, M_TEMP);
cookies = NULL;
If you get a chance to try it, please let us know if it helps, rick
Thanks, but unfortunately it didn't work. Rebooted it four hours ago with the
patch in place and at the moment I have seven nfsd processes stuck in that
state.
Could it indicate a problem with the underlying disk system? It's an aac0
raid, but it has no errors and the controller indicates all is well, so I doubt
it.
Mark
___
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"
X-pstn-neptune: 0/0/0.00/0
X-pstn-levels: (S:70.94084/99.9 CV:99.9000 FC:95.5390 LC:95.5390
R:95.9108 P:95.9108 M:97.0282 C:98.6951 )
X-pstn-settings: 4 (1.5000:1.5000) s cv gt3 gt2 gt1 r p m c
X-pstn-addresses: from [294/10]
Re: Kernel panic when unpluggin AC adaptor
On Wed, May 26, 2010 at 12:01 PM, David DEMELIER wrote: > 2010/5/26 Giovanni Trematerra : >> On Wed, May 26, 2010 at 11:14 AM, David DEMELIER >> wrote: >>> 2010/5/25 Giovanni Trematerra : On Tue, May 25, 2010 at 5:52 PM, David DEMELIER wrote: > 2010/5/25 Giovanni Trematerra : >> On Mon, May 24, 2010 at 9:43 PM, David DEMELIER >> wrote: >>> 2010/5/12 Giovanni Trematerra : On Fri, May 7, 2010 at 8:33 PM, Demelier David wrote: > Le Vendredi 07 mai 2010 à 18:22 +0200, Giovanni Trematerra a écrit : >> On Fri, May 7, 2010 at 2:08 PM, Demelier David >> wrote: >> > Hi, >> > I noticed that pluggin the AC adaptor when I boot without >> > it does not >> > panic. It only panic when removing it. >> > >> > Maybe that could help ? >> > >> >> Good to know. The problem lies somewhere when performance state >> change. >> In your case it happens when you remove AC adaptor. Let's hope >> someone on >> acpi@ ml comes up with a good idea. >> > > Okay so for the moment no change, I'll wait for someone with an idea > that could solve my problem. For me because the panic only happens > when > changing profile from ac plugged -> ac unplugged (and not the > reverse) I > would think it's a cpu related acpi issue. > I looked deeper and it seems to me that when you unplug the AC adapter, acpi_cpu_notify calls acpi_cpu_cx_cst that try to allocate a new cx_ptr->p_lvlx via acpi_PkgGas. If acpi_PkgGas set cx_ptr->p_lvlx to NULL for any reasons you'll have the panic that you reported. A solution would be to set acpi_cpu_hook to NULL so acpi_cpu_idle won't call it. I need some time to have a patch because of the possible race between acpi_cpu_notify and acpi_cpu_idle during set acpi_cpu_hook to NULL. if you have time and want panic your system you could try the attached patch, just to be sure that we catch it. >>> >>> Hi, it paniced today ! I don't know why it randomly panic but it did, >>> the backtrace didn't change. There is a picture about the panic : >>> >>> http://img541.imageshack.us/img541/2773/dsc00388xa.jpg >> >> What was you trying? acpi_idle5.diff.txt patch? >> How did it panic? Unplugging AC adapter? >> > > Hi, I tried this one : lvlx.diff.txt. Yes by unplugging the AC adapter. > This is an old one. Could you try acpi_idle5.diff.txt? I kept you in Cc when I sent to the list. If you have problems, let me know, I'll resend to you the patch. Thank you. >>> >>> Hi, it panic'ed with the same backtrace. >>> >> >> Can you please post your dmesg? >> > > Sent ! As your PC is in a good mood to make test, :) could you try this patch? Thank you -- Gianni ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Kernel panic when unpluggin AC adaptor
On Wed, May 26, 2010 at 3:55 PM, Giovanni Trematerra
wrote:
> On Wed, May 26, 2010 at 12:01 PM, David DEMELIER
> wrote:
>> 2010/5/26 Giovanni Trematerra :
>>> On Wed, May 26, 2010 at 11:14 AM, David DEMELIER
>>> wrote:
2010/5/25 Giovanni Trematerra :
> On Tue, May 25, 2010 at 5:52 PM, David DEMELIER
> wrote:
>> 2010/5/25 Giovanni Trematerra :
>>> On Mon, May 24, 2010 at 9:43 PM, David DEMELIER
>>> wrote:
2010/5/12 Giovanni Trematerra :
> On Fri, May 7, 2010 at 8:33 PM, Demelier David
> wrote:
>> Le Vendredi 07 mai 2010 à 18:22 +0200, Giovanni Trematerra a écrit :
>>> On Fri, May 7, 2010 at 2:08 PM, Demelier David
>>> wrote:
>>> > Hi,
>>> > I noticed that pluggin the AC adaptor when I boot without
>>> > it does not
>>> > panic. It only panic when removing it.
>>> >
>>> > Maybe that could help ?
>>> >
>>>
>>> Good to know. The problem lies somewhere when performance state
>>> change.
>>> In your case it happens when you remove AC adaptor. Let's hope
>>> someone on
>>> acpi@ ml comes up with a good idea.
>>>
>>
>> Okay so for the moment no change, I'll wait for someone with an idea
>> that could solve my problem. For me because the panic only happens
>> when
>> changing profile from ac plugged -> ac unplugged (and not the
>> reverse) I
>> would think it's a cpu related acpi issue.
>>
>
> I looked deeper and it seems to me that when you unplug the AC
> adapter, acpi_cpu_notify calls acpi_cpu_cx_cst that try to allocate a
> new cx_ptr->p_lvlx via acpi_PkgGas.
> If acpi_PkgGas set cx_ptr->p_lvlx to NULL for any reasons you'll have
> the panic that you reported.
> A solution would be to set acpi_cpu_hook to NULL so acpi_cpu_idle
> won't call it.
> I need some time to have a patch because of the possible race between
> acpi_cpu_notify and
> acpi_cpu_idle during set acpi_cpu_hook to NULL.
> if you have time and want panic your system you could try the attached
> patch, just to be
> sure that we catch it.
>
Hi, it paniced today ! I don't know why it randomly panic but it did,
the backtrace didn't change. There is a picture about the panic :
http://img541.imageshack.us/img541/2773/dsc00388xa.jpg
>>>
>>> What was you trying? acpi_idle5.diff.txt patch?
>>> How did it panic? Unplugging AC adapter?
>>>
>>
>> Hi, I tried this one : lvlx.diff.txt. Yes by unplugging the AC adapter.
>>
>
> This is an old one. Could you try acpi_idle5.diff.txt? I kept you in
> Cc when I sent to
> the list. If you have problems, let me know, I'll resend to you the
> patch.
>
> Thank you.
>
Hi, it panic'ed with the same backtrace.
>>>
>>> Can you please post your dmesg?
>>>
>>
>> Sent !
>
> As your PC is in a good mood to make test, :)
> could you try this patch?
>
> Thank you
>
> --
> Gianni
>
Here the patch :(
diff -r ac95a73d358d sys/dev/acpica/acpi_cpu.c
--- a/sys/dev/acpica/acpi_cpu.c Tue May 18 08:13:40 2010 -0400
+++ b/sys/dev/acpica/acpi_cpu.c Wed May 26 09:44:49 2010 -0400
@@ -88,6 +88,7 @@ struct acpi_cpu_softc {
int cpu_cx_lowest;
charcpu_cx_supported[64];
int cpu_rid;
+struct mtx cpu_lock;
};
struct acpi_cpu_device {
@@ -100,6 +101,10 @@ struct acpi_cpu_device {
#define CPU_SET_REG(reg, width, val) \
(bus_space_write_ ## width(rman_get_bustag((reg)),
\
rman_get_bushandle((reg)), 0, (val)))
+#define ACPI_CPU_LOCK(sc) \
+mtx_lock_spin(&sc->cpu_lock)
+#define ACPI_CPU_UNLOCK(sc)\
+mtx_unlock_spin(&sc->cpu_lock)
#define PM_USEC(x) ((x) >> 2) /* ~4 clocks per usec (3.57955 Mhz) */
@@ -127,7 +132,7 @@ static int cpu_quirks;/* Indicate any
static int cpu_quirks;/* Indicate any hardware bugs. */
/* Runtime state. */
-static int cpu_disable_idle; /* Disable entry to idle function */
+static int cpu_disable_idle; /* Global disable idle function */
static int cpu_cx_count; /* Number of valid Cx states */
/* Values for sysctl. */
@@ -284,6 +289,7 @@ acpi_cpu_attach(device_t dev)
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
sc = device_get_softc(dev);
+mtx_init(&sc->cpu_lock, "ntflck", NULL, MTX_SPIN);
sc->cpu_dev = dev;
sc->cpu_handle = acpi_get_handle(dev);
cpu_id = (int)(intptr_t)acpi_get_private(dev);
@@ -416,20 +422,25 @@ static int
static int
acpi_cpu_suspend(device_t dev)
{
+struc
Re: hung on ufs vnode lock, was Re: NFS trouble on 7.3-STABLE i386
On Tuesday 25 May 2010 8:24:58 pm Rick Macklem wrote: > > On Tue, 25 May 2010, Mark Morley wrote: > > > On Fri, 21 May 2010 11:32:33 -0400 (EDT) Rick Macklem wrote: On Fri, 21 May 2010, Mark Morley wrote: > > > >> Having an issue with a file server here (7.3-STABLE i386) > >> > >> The nfsd processes are hanging. Client access to the nfs shares stops working and the nfsd processes on the server cannot be killed by any means. There are no errors showing up anywhere on the server. The network connection to the server seems fine (ie: anything other than nfs traffic seems ok). Rebooting the server fixes the problem for a while, but it doesn't reboot easily. It times out on terminating the nfsd processes. When it finally does reboot the file system isn't marked clean, resulting in a long wait for fsck (although it doesn't find any problems, it's a multi terrabyte share and it takes a while). > >> > >> This morning it did it again. This time I tried manually killing nfsd but nothing I did would make them die. No errors. > >> > > Next time it happens, do a "ps axlH" to see what the nfsd threads are > > waiting for. It might give you a hint as to what is happening. > > > > Ok, it did it again. ps axlH shows all the nfsd processes stuck in the _ufs_ state. The server isn't doing anything else, no other processes seem to be monopolizing resources or disks in any way. > > If the nfsd threads are sleeping on WCHAN "ufs", I think that means that > they are waiting for a ufs vnode lock. I don't know what has changed > between FreeBSD7.1 and FreeBSD7.3 that might have caused this. I changed > the Subject: line in the hopes that someone who might know the answer to > this will take a look. If you can break into ddb, you can use 'show sleepchain' to investigate. If you built the kernel with debug symbols you can use kgdb to investigate as well. I have something similar to 'show sleepchain' in the gdb scripts at www.freebsd.org/~jhb/gdb/. You can source the gdb6 file and do 'sleepchain ' to see what locks a given thread is blocked on. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Kernel panic when unpluggin AC adaptor
2010/5/26 Giovanni Trematerra : > On Wed, May 26, 2010 at 3:55 PM, Giovanni Trematerra > wrote: >> On Wed, May 26, 2010 at 12:01 PM, David DEMELIER >> wrote: >>> 2010/5/26 Giovanni Trematerra : On Wed, May 26, 2010 at 11:14 AM, David DEMELIER wrote: > 2010/5/25 Giovanni Trematerra : >> On Tue, May 25, 2010 at 5:52 PM, David DEMELIER >> wrote: >>> 2010/5/25 Giovanni Trematerra : On Mon, May 24, 2010 at 9:43 PM, David DEMELIER wrote: > 2010/5/12 Giovanni Trematerra : >> On Fri, May 7, 2010 at 8:33 PM, Demelier David >> wrote: >>> Le Vendredi 07 mai 2010 à 18:22 +0200, Giovanni Trematerra a écrit : On Fri, May 7, 2010 at 2:08 PM, Demelier David wrote: > Hi, > I noticed that pluggin the AC adaptor when I boot without > it does not > panic. It only panic when removing it. > > Maybe that could help ? > Good to know. The problem lies somewhere when performance state change. In your case it happens when you remove AC adaptor. Let's hope someone on acpi@ ml comes up with a good idea. >>> >>> Okay so for the moment no change, I'll wait for someone with an idea >>> that could solve my problem. For me because the panic only happens >>> when >>> changing profile from ac plugged -> ac unplugged (and not the >>> reverse) I >>> would think it's a cpu related acpi issue. >>> >> >> I looked deeper and it seems to me that when you unplug the AC >> adapter, acpi_cpu_notify calls acpi_cpu_cx_cst that try to allocate a >> new cx_ptr->p_lvlx via acpi_PkgGas. >> If acpi_PkgGas set cx_ptr->p_lvlx to NULL for any reasons you'll have >> the panic that you reported. >> A solution would be to set acpi_cpu_hook to NULL so acpi_cpu_idle >> won't call it. >> I need some time to have a patch because of the possible race between >> acpi_cpu_notify and >> acpi_cpu_idle during set acpi_cpu_hook to NULL. >> if you have time and want panic your system you could try the >> attached >> patch, just to be >> sure that we catch it. >> > > Hi, it paniced today ! I don't know why it randomly panic but it did, > the backtrace didn't change. There is a picture about the panic : > > http://img541.imageshack.us/img541/2773/dsc00388xa.jpg What was you trying? acpi_idle5.diff.txt patch? How did it panic? Unplugging AC adapter? >>> >>> Hi, I tried this one : lvlx.diff.txt. Yes by unplugging the AC adapter. >>> >> >> This is an old one. Could you try acpi_idle5.diff.txt? I kept you in >> Cc when I sent to >> the list. If you have problems, let me know, I'll resend to you the >> patch. >> >> Thank you. >> > > Hi, it panic'ed with the same backtrace. > Can you please post your dmesg? >>> >>> Sent ! >> >> As your PC is in a good mood to make test, :) >> could you try this patch? >> >> Thank you >> >> -- >> Gianni >> > > Here the patch :( > Sorry, still the same :-( -- Demelier David ___ 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"
ale stats (AR8121)
Just trying out a MB that has an integrated ale nic and was looking at some of the many stats available. The last one, dev.ale.0.stats.tx.trunc_errs: Truncated frames due to MTU size doesnt seem to make sense. The nic's MTU is set to 1500. What would be generating traffic locally that would have an MTU size that is too big ? or is the counter perhaps recording something else ? # ifconfig ale0 ale0: flags=8843 metric 0 mtu 1500 options=c319a ether e0:cb:4e:42:4b:37 inet 172.16.13.254 netmask 0xff00 broadcast 172.16.13.255 inet 10.230.33.1 netmask 0xff00 broadcast 10.230.33.255 media: Ethernet autoselect (1000baseT ) status: active dev.ale.0.%desc: Atheros AR8121/AR8113/AR8114 PCIe Ethernet dev.ale.0.%driver: ale dev.ale.0.%location: slot=0 function=0 dev.ale.0.%pnpinfo: vendor=0x1969 device=0x1026 subvendor=0x1043 subdevice=0x8226 class=0x02 dev.ale.0.%parent: pci4 dev.ale.0.int_rx_mod: 30 dev.ale.0.int_tx_mod: 1000 dev.ale.0.process_limit: 64 dev.ale.0.reset_brk_seq: 0 dev.ale.0.stats.rx.good_frames: 970368 dev.ale.0.stats.rx.good_bcast_frames: 2338 dev.ale.0.stats.rx.good_mcast_frames: 0 dev.ale.0.stats.rx.pause_frames: 0 dev.ale.0.stats.rx.control_frames: 0 dev.ale.0.stats.rx.crc_errs: 0 dev.ale.0.stats.rx.len_errs: 0 dev.ale.0.stats.rx.good_octets: 1432442744 dev.ale.0.stats.rx.good_bcast_octets: 171236 dev.ale.0.stats.rx.good_mcast_octets: 0 dev.ale.0.stats.rx.runts: 0 dev.ale.0.stats.rx.fragments: 0 dev.ale.0.stats.rx.frames_64: 3685 dev.ale.0.stats.rx.frames_65_127: 10729 dev.ale.0.stats.rx.frames_128_255: 684 dev.ale.0.stats.rx.frames_256_511: 179 dev.ale.0.stats.rx.frames_512_1023: 1 dev.ale.0.stats.rx.frames_1024_1518: 956795 dev.ale.0.stats.rx.frames_1519_max: 0 dev.ale.0.stats.rx.trunc_errs: 0 dev.ale.0.stats.rx.fifo_oflows: 0 dev.ale.0.stats.rx.rrs_errs: 0 dev.ale.0.stats.rx.align_errs: 0 dev.ale.0.stats.rx.filtered: 1705 dev.ale.0.stats.tx.good_frames: 646015 dev.ale.0.stats.tx.good_bcast_frames: 57 dev.ale.0.stats.tx.good_mcast_frames: 0 dev.ale.0.stats.tx.pause_frames: 0 dev.ale.0.stats.tx.control_frames: 0 dev.ale.0.stats.tx.excess_defers: 0 dev.ale.0.stats.tx.defers: 0 dev.ale.0.stats.tx.good_octets: 49564618 dev.ale.0.stats.tx.good_bcast_octets: 0 dev.ale.0.stats.tx.good_mcast_octets: 0 dev.ale.0.stats.tx.frames_64: 3 dev.ale.0.stats.tx.frames_65_127: 603750 dev.ale.0.stats.tx.frames_128_255: 42249 dev.ale.0.stats.tx.frames_256_511: 13 dev.ale.0.stats.tx.frames_512_1023: 0 dev.ale.0.stats.tx.frames_1024_1518: 0 dev.ale.0.stats.tx.frames_1519_max: 0 dev.ale.0.stats.tx.single_colls: 0 dev.ale.0.stats.tx.multi_colls: 0 dev.ale.0.stats.tx.late_colls: 0 dev.ale.0.stats.tx.excess_colls: 0 dev.ale.0.stats.tx.abort: 0 dev.ale.0.stats.tx.underruns: 0 dev.ale.0.stats.tx.desc_underruns: 0 dev.ale.0.stats.tx.len_errs: 0 dev.ale.0.stats.tx.trunc_errs: 9248 a...@pci0:4:0:0:class=0x02 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[48] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1) Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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: ale stats (AR8121)
On Wed, May 26, 2010 at 12:30:20PM -0400, Mike Tancsa wrote: Hi, > Just trying out a MB that has an integrated ale nic and was looking > at some of the many stats available. The last one, > dev.ale.0.stats.tx.trunc_errs: Truncated frames due to MTU size > > doesnt seem to make sense. The nic's MTU is set to 1500. What would > be generating traffic locally that would have an MTU size that is too > big ? or is the counter perhaps recording something else ? > There is a comment on this in driver. 2243 /* 2244 * XXX 2245 * tx_pkts_truncated counter looks suspicious. It constantly 2246 * increments with no sign of Tx errors. This may indicate 2247 * the counter name is not correct one so I've removed the 2248 * counter in output errors. 2249 */ 2250 ifp->if_oerrors += smb->tx_abort + smb->tx_late_colls + 2251 smb->tx_underrun; Anyway I have to ask Atheros what the counter really means. Thanks for reminding it. If I get some feedback I'll let you know. > # ifconfig ale0 > ale0: flags=8843 metric 0 mtu 1500 > > options=c319a > ether e0:cb:4e:42:4b:37 > inet 172.16.13.254 netmask 0xff00 broadcast 172.16.13.255 > inet 10.230.33.1 netmask 0xff00 broadcast 10.230.33.255 > media: Ethernet autoselect (1000baseT ) > status: active > > dev.ale.0.%desc: Atheros AR8121/AR8113/AR8114 PCIe Ethernet > dev.ale.0.%driver: ale > dev.ale.0.%location: slot=0 function=0 > dev.ale.0.%pnpinfo: vendor=0x1969 device=0x1026 subvendor=0x1043 > subdevice=0x8226 class=0x02 > dev.ale.0.%parent: pci4 > dev.ale.0.int_rx_mod: 30 > dev.ale.0.int_tx_mod: 1000 > dev.ale.0.process_limit: 64 > dev.ale.0.reset_brk_seq: 0 > dev.ale.0.stats.rx.good_frames: 970368 > dev.ale.0.stats.rx.good_bcast_frames: 2338 > dev.ale.0.stats.rx.good_mcast_frames: 0 > dev.ale.0.stats.rx.pause_frames: 0 > dev.ale.0.stats.rx.control_frames: 0 > dev.ale.0.stats.rx.crc_errs: 0 > dev.ale.0.stats.rx.len_errs: 0 > dev.ale.0.stats.rx.good_octets: 1432442744 > dev.ale.0.stats.rx.good_bcast_octets: 171236 > dev.ale.0.stats.rx.good_mcast_octets: 0 > dev.ale.0.stats.rx.runts: 0 > dev.ale.0.stats.rx.fragments: 0 > dev.ale.0.stats.rx.frames_64: 3685 > dev.ale.0.stats.rx.frames_65_127: 10729 > dev.ale.0.stats.rx.frames_128_255: 684 > dev.ale.0.stats.rx.frames_256_511: 179 > dev.ale.0.stats.rx.frames_512_1023: 1 > dev.ale.0.stats.rx.frames_1024_1518: 956795 > dev.ale.0.stats.rx.frames_1519_max: 0 > dev.ale.0.stats.rx.trunc_errs: 0 > dev.ale.0.stats.rx.fifo_oflows: 0 > dev.ale.0.stats.rx.rrs_errs: 0 > dev.ale.0.stats.rx.align_errs: 0 > dev.ale.0.stats.rx.filtered: 1705 > dev.ale.0.stats.tx.good_frames: 646015 > dev.ale.0.stats.tx.good_bcast_frames: 57 > dev.ale.0.stats.tx.good_mcast_frames: 0 > dev.ale.0.stats.tx.pause_frames: 0 > dev.ale.0.stats.tx.control_frames: 0 > dev.ale.0.stats.tx.excess_defers: 0 > dev.ale.0.stats.tx.defers: 0 > dev.ale.0.stats.tx.good_octets: 49564618 > dev.ale.0.stats.tx.good_bcast_octets: 0 > dev.ale.0.stats.tx.good_mcast_octets: 0 > dev.ale.0.stats.tx.frames_64: 3 > dev.ale.0.stats.tx.frames_65_127: 603750 > dev.ale.0.stats.tx.frames_128_255: 42249 > dev.ale.0.stats.tx.frames_256_511: 13 > dev.ale.0.stats.tx.frames_512_1023: 0 > dev.ale.0.stats.tx.frames_1024_1518: 0 > dev.ale.0.stats.tx.frames_1519_max: 0 > dev.ale.0.stats.tx.single_colls: 0 > dev.ale.0.stats.tx.multi_colls: 0 > dev.ale.0.stats.tx.late_colls: 0 > dev.ale.0.stats.tx.excess_colls: 0 > dev.ale.0.stats.tx.abort: 0 > dev.ale.0.stats.tx.underruns: 0 > dev.ale.0.stats.tx.desc_underruns: 0 > dev.ale.0.stats.tx.len_errs: 0 > dev.ale.0.stats.tx.trunc_errs: 9248 > > > a...@pci0:4:0:0:class=0x02 card=0x82261043 > chip=0x10261969 rev=0xb0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > class = network > subclass = ethernet > cap 01[40] = powerspec 2 supports D0 D3 current D0 > cap 05[48] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1) > > > > > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications,m...@sentex.net > Providing Internet since 1994www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Buzzing snd_emu10kx enabled card with r206173
On 25/05/2010 20:05, Garrett Cooper wrote: > On Tue, May 25, 2010 at 3:06 AM, Mark Stapper wrote: > >> On 18/05/2010 08:14, Mark Stapper wrote: >> >>> On 18/05/2010 00:22, Garrett Cooper wrote: >>> >>> On Mon, May 17, 2010 at 11:21 AM, Mark Stapper wrote: > On 12/04/2010 16:29, Garrett Cooper wrote: > > > >> On Tue, Apr 6, 2010 at 3:39 AM, Garrett Cooper >> wrote: >> >> >> >> >>> On Mon, Apr 5, 2010 at 12:26 PM, Garrett Cooper >>> wrote: >>> >>> >>> >>> On Mon, Apr 5, 2010 at 11:22 AM, Garrett Cooper wrote: > Hi, >When I first installed FreeBSD on this machine, I had a heck of a > time getting the soundcard's PCM channel to function properly. It > would buzz incessantly when I played any audio on it; I disabled the > onboard snd_hda enabled audio and things magically worked, until > today. After a kernel upgrade and a few warm boots, I'm back to where > I started from -- the PCM channel buzzes whenever I play audio; > line-in works perfectly fine however. I'm not seeing anything out of > the ordinary in commits over the past couple of weeks for the pcm > pieces (the last successful kernel I used was 2~3 weeks old). >Are there any device_printf's I should add or a debug procedure > that you recommend I do to triage the situation? > Thanks, > -Garrett > > # uname -a > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206173M: > Sun Apr 4 19:54:22 PDT 2010 > r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > # pciconf -lv | grep -A 4 emu > emu10...@pci0:8:0:0:class=0x040100 card=0x10211102 chip=0x00081102 > rev=0x00 hdr=0x00 >vendor = 'Creative Technology LTD.' >device = 'sound blaster Audigy 2 (ca0108)' >class = multimedia >subclass = audio > # dmesg | grep 'irq 16' > uhci0: port 0xa800-0xa81f > irq 16 at device 26.0 on pci0 > pcib7: irq 16 at device 28.1 on pci0 > emu10kx0: port 0xec00-0xec3f irq 16 at > device 0.0 on pci8 > # dmesg | grep 'pcm' > pcm0: on emu10kx0 > pcm0: > pcm1: on emu10kx0 > pcm2: on emu10kx0 > pcm3: on emu10kx0 > pcm4: on emu10kx0 > > > > Some more information: 1. snd_emu10kx and sound are both modules loaded on boot, along with if_re, linux, and nvidia. 2. Disabling nvidia -> no change. 3. Disabling acpi -> unbootable system because many drivers can't map interrupts without it (can't test unless I isolate the drivers and enable them one by one -- something I'll try later on). I'm at a loss right now... my hunch is that it's potentially a bad interaction between the snd_emu10kx driver and another driver on the same PCI bus (which is just the ACPI and uhci drivers), but I can't test these claims. There are other funky things about my system that have changed over the past couple of kernel versions, like front USB ports could charge my iPhone, and now they don't... and the fact that ACPI blanking via nvidia now works again... so something may have changed on the backend, but I'm not 100% sure on what I should isolate as the root cause, yet. >>> Grr... it's `healed' itself again. I'll watch out for potential >>> catalysts to the issue in the future. >>> >>> >>> >>> >> Ok. Damn issue came back and here's what happened. Rebooted >> several times with the same kernel and slight modifications, loading >> and unloading snd_emu10kx and sound, testing out snd_emu10k1, and no >> dice. The buzz was bad and it was driving me insane. Again, line-in >> functioned just fine, so I didn't know what the heck was going. I was >> getting desperate, so I finally broke down and booted the Gentoo Linux >> livecd. PCM worked just fine. Then I got irritated enough and finally >> just built the module and the sound support directly into the kernel >> and everything is hunky dorey again. Does anyone have a stab in the >> dark as to what's going on? Is it a potential bus or interrupt >> conflict / race condition that gets alleviated when support is nailed >> into the kernel? Or are other folks as stumped as I am, s.t. I should >> just try emailing current@ instead to see if someone maybe knows >> what's going on there :(...? >> Thanks, >> -Garrett >>
gmirror panic with SiI 3726 when array is degraded
So I've started using gmirror recently to mirror 2 1.5 TB drives however if I reboot the machine or 'gmirror stop -f data1' while the array is been rebuilt I get the panic below. Rebooting without geom_mirror loaded does not cause a panic Rebooting with geom_mirror loaded and the drives disconnected does not cause a panic. The drives are in an "Rosewill RSV-S4-X 4 Bay SATA to eSATA (Port Multiplier) JBOD / RAID 0, 1, 1+0, 5 Enclosure" connected over a SiI 3726 (rev=1706) adapter Rebooting with the drives mounted normally does not cause a panic I'm using the latest and greatest firmware, the panics occurred before the update After rebooting background fsck has to run to fix all mounts every time their is a panic, even if i did a several sync's before running 'reboot' I previously had the drives mirrored using the built-in sata ports and geom_mirror without any panics. The port multiplier: http://www.newegg.com/Product/Product.aspx?Item=N82E16816132029 I've configured the machine to save crash dumps and will try to generate one later. Thanks for any help. _ waiting (max 60 seconds) for system process `bufdaemon` to stop...GEOM_MIRROR: Device data1: provider mirror/data1 destroyed. fatal trap 12: page fault while in kernel mode cpuid =0; apic id =00 fault virtual address = 0x98 fault code = supervisor write data, page not present instruction pointer = 0x20:0x80571105 stack pointer = 0x28:0xff833ba0 frame pointer = 0x28:0xff833bb0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3 (g_up) trap number= 12 panic: page fault cpuid = 0 uptime 19m9s cannot dump. Device not defined or unavailable dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 21:11:58 UTC 2010 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3500+ (2200.10-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20ff2 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 real memory = 1073741824 (1024 MB) avail memory = 953888768 (909 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3ff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xd000-0xd3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci1 atapci0: port 0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f mem 0xfebffc00-0xfebf irq 21 at device 15.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.00 controller with 4 3Gbps ports, PM supported ata2: on atapci0 ata2: port is not ready (timeout 0ms) tfd = 01d0 ata2: software reset clear timeout ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: port is not ready (timeout 0ms) tfd = 01d0 ata4: software reset clear timeout ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xe080-0xe09f irq 20 at device 16.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x usbus0: on uhci0 uhci1: port 0xe000-0xe01f irq 22 at device 16.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x usbus1: on uhci1 uhci2: port 0xdc00-0xdc1f irq 21 at device 16.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x usbus2: on uhci2 uhci3: port 0xd880-0xd89f irq 23 at device 16.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x usbus3: on uhci3 ehci0: mem 0xfebff800-0xfebff8ff irq 22 at device 16.4 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 isab0: at device 17.0 on pci0 isa0: on isab0 pci0: at device 17.5 (no driver attached) vr0: port 0xd000-0xd0ff mem 0xfebff400-0xfebff4ff irq 23 at device 18.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x7c miibus0: on vr0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:00:00:00:01:f8 vr0: [ITHREAD] pcib2: at device 19.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 atapci2: port 0xbc00-0xbc
Re: gmirror panic with SiI 3726 when array is degraded
technews wrote: > So I've started using gmirror recently to mirror 2 1.5 TB drives however > if I reboot the machine or 'gmirror stop -f data1' while the array is > been rebuilt I get the panic below. > Rebooting without geom_mirror loaded does not cause a panic > Rebooting with geom_mirror loaded and the drives disconnected does not > cause a panic. > The drives are in an "Rosewill RSV-S4-X 4 Bay SATA to eSATA (Port > Multiplier) JBOD / RAID 0, 1, 1+0, 5 Enclosure" connected over a SiI > 3726 (rev=1706) adapter > Rebooting with the drives mounted normally does not cause a panic > I'm using the latest and greatest firmware, the panics occurred before > the update It would be nice if you build kernel with debugger and got a stack backtrace to show where problem occurred. Also, if you like your port multiplier to work much faster and stable - I would strongly suggest you to update to 8-STABLE (or wait forthcoming 8.1-RELEASE, if you prefer releases) and use new siis(4) driver for your SiI3132 SATA controller. Port Multiplier support in ata(4) driver left in embryo level and won't be improved. -- Alexander Motin ___ 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"
