Re: [1/2] 2.6.21-rc7: known regressions
At Fri, 20 Apr 2007 20:26:10 +0200, I wrote: > > At Fri, 20 Apr 2007 11:18:07 -0700, > Andrew Morton wrote: > > > > On Fri, 20 Apr 2007 12:34:18 +0200 > > Takashi Iwai <[EMAIL PROTECTED]> wrote: > > > > > Good to hear! I forgot the patch description and sign-off, so here it > > > is again: > > > > > > > > > [PATCH] ALSA: intel8x0 - Fix Oops in crash kernel > > > > > > When intel8x0 driver is loaded in the crash kernel, it gets Oops > > > occasionally. This is because the irq handler gets called before > > > the proper hardware initialization. Now defer it after > > > snd_intel8x0_chip_init(). > > > > Neat, thanks. > > > > Do we think this is safe enough and important enough for 2.6.21? > > And if so, do you want me to merge it? > > It should be safe (as I already merged ALSA tree for 2.6.22), but I'd > like to test the following before merging 2.6.21: > - suspend/resume works > - no severe problem even if request_irq() fails > I'll check this in this weekend, so let's hold on. Both seem OK as far as I tested. So, feel free to push it to 2.6.21 if it's still allowed. Otherwise I'll queue it up to stable tree later. Thanks, Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
At Fri, 20 Apr 2007 20:26:10 +0200, I wrote: At Fri, 20 Apr 2007 11:18:07 -0700, Andrew Morton wrote: On Fri, 20 Apr 2007 12:34:18 +0200 Takashi Iwai [EMAIL PROTECTED] wrote: Good to hear! I forgot the patch description and sign-off, so here it is again: [PATCH] ALSA: intel8x0 - Fix Oops in crash kernel When intel8x0 driver is loaded in the crash kernel, it gets Oops occasionally. This is because the irq handler gets called before the proper hardware initialization. Now defer it after snd_intel8x0_chip_init(). Neat, thanks. Do we think this is safe enough and important enough for 2.6.21? And if so, do you want me to merge it? It should be safe (as I already merged ALSA tree for 2.6.22), but I'd like to test the following before merging 2.6.21: - suspend/resume works - no severe problem even if request_irq() fails I'll check this in this weekend, so let's hold on. Both seem OK as far as I tested. So, feel free to push it to 2.6.21 if it's still allowed. Otherwise I'll queue it up to stable tree later. Thanks, Takashi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
At Fri, 20 Apr 2007 11:18:07 -0700, Andrew Morton wrote: > > On Fri, 20 Apr 2007 12:34:18 +0200 > Takashi Iwai <[EMAIL PROTECTED]> wrote: > > > Good to hear! I forgot the patch description and sign-off, so here it > > is again: > > > > > > [PATCH] ALSA: intel8x0 - Fix Oops in crash kernel > > > > When intel8x0 driver is loaded in the crash kernel, it gets Oops > > occasionally. This is because the irq handler gets called before > > the proper hardware initialization. Now defer it after > > snd_intel8x0_chip_init(). > > Neat, thanks. > > Do we think this is safe enough and important enough for 2.6.21? > And if so, do you want me to merge it? It should be safe (as I already merged ALSA tree for 2.6.22), but I'd like to test the following before merging 2.6.21: - suspend/resume works - no severe problem even if request_irq() fails I'll check this in this weekend, so let's hold on. Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
On Fri, 20 Apr 2007 12:34:18 +0200 Takashi Iwai <[EMAIL PROTECTED]> wrote: > Good to hear! I forgot the patch description and sign-off, so here it > is again: > > > [PATCH] ALSA: intel8x0 - Fix Oops in crash kernel > > When intel8x0 driver is loaded in the crash kernel, it gets Oops > occasionally. This is because the irq handler gets called before > the proper hardware initialization. Now defer it after > snd_intel8x0_chip_init(). Neat, thanks. Do we think this is safe enough and important enough for 2.6.21? And if so, do you want me to merge it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
At Thu, 19 Apr 2007 22:03:16 +0200,
Michal Piotrowski wrote:
>
> Hi Takashi,
>
> Takashi Iwai napisał(a):
> > At Mon, 16 Apr 2007 17:44:57 -0400,
> > Chuck Ebbert wrote:
> >> Adrian Bunk wrote:
> >>
> >>> This email lists some known regressions in Linus' tree compared to 2.6.20.
> >>>
> >>> Subject: snd_intel8x0: divide error:
> >>> References : http://lkml.org/lkml/2007/3/5/252
> >>> Submitter : Michal Piotrowski <[EMAIL PROTECTED]>
> >>> Status : unknown
> >>>
> >> Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of
> >> the interrupt handler:
> >>
> >> Line 751:
> >>
> >> ichdev->position += step * ichdev->fragsize1;
> >> if (! chip->in_measurement)
> >> ichdev->position %= ichdev->size;
> >>
> >> ichdev->size is 0. Interrupt happened upon request_irq().
> >>
> >> Does chip->in_measurement need to be reset because this is a
> >> crashdump kernel?
> >
> > No, the problem seems to be the timing of request_irq() and the
> > initialization of hardware. The irq handler shouldn't get called
> > there at all.
> >
> > How about the patch below?
(snip)
>
> This patch solves the problem for me. Thanks!
Good to hear! I forgot the patch description and sign-off, so here it
is again:
[PATCH] ALSA: intel8x0 - Fix Oops in crash kernel
When intel8x0 driver is loaded in the crash kernel, it gets Oops
occasionally. This is because the irq handler gets called before
the proper hardware initialization. Now defer it after
snd_intel8x0_chip_init().
(reference: http://lkml.org/lkml/2007/3/5/252)
Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
---
sound/pci/intel8x0.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff -r 202af90f8e68 -r a3f021fd290c sound/pci/intel8x0.c
--- a/sound/pci/intel8x0.c Thu Apr 19 15:22:56 2007 +0200
+++ b/sound/pci/intel8x0.c Fri Apr 20 12:30:28 2007 +0200
@@ -2493,6 +2493,7 @@ static int intel8x0_resume(struct pci_de
return -EIO;
}
pci_set_master(pci);
+ snd_intel8x0_chip_init(chip, 0);
if (request_irq(pci->irq, snd_intel8x0_interrupt,
IRQF_SHARED, card->shortname, chip)) {
printk(KERN_ERR "intel8x0: unable to grab IRQ %d, "
@@ -2502,7 +2503,6 @@ static int intel8x0_resume(struct pci_de
}
chip->irq = pci->irq;
synchronize_irq(chip->irq);
- snd_intel8x0_chip_init(chip, 0);
/* re-initialize mixer stuff */
if (chip->device_type == DEVICE_INTEL_ICH4 && !spdif_aclink) {
@@ -2862,16 +2862,7 @@ static int __devinit snd_intel8x0_create
ICH_REG_ALI_INTERRUPTSR : ICH_REG_GLOB_STA;
chip->int_sta_mask = int_sta_masks;
- /* request irq after initializaing int_sta_mask, etc */
- if (request_irq(pci->irq, snd_intel8x0_interrupt,
- IRQF_SHARED, card->shortname, chip)) {
- snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
- snd_intel8x0_free(chip);
- return -EBUSY;
- }
- chip->irq = pci->irq;
pci_set_master(pci);
- synchronize_irq(chip->irq);
switch(chip->device_type) {
case DEVICE_INTEL_ICH4:
@@ -2900,6 +2891,15 @@ static int __devinit snd_intel8x0_create
snd_intel8x0_free(chip);
return err;
}
+
+ /* request irq after initializaing int_sta_mask, etc */
+ if (request_irq(pci->irq, snd_intel8x0_interrupt,
+ IRQF_SHARED, card->shortname, chip)) {
+ snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
+ snd_intel8x0_free(chip);
+ return -EBUSY;
+ }
+ chip->irq = pci->irq;
if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, )) < 0) {
snd_intel8x0_free(chip);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
At Thu, 19 Apr 2007 22:03:16 +0200,
Michal Piotrowski wrote:
Hi Takashi,
Takashi Iwai napisał(a):
At Mon, 16 Apr 2007 17:44:57 -0400,
Chuck Ebbert wrote:
Adrian Bunk wrote:
This email lists some known regressions in Linus' tree compared to 2.6.20.
Subject: snd_intel8x0: divide error:
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski [EMAIL PROTECTED]
Status : unknown
Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of
the interrupt handler:
Line 751:
ichdev-position += step * ichdev-fragsize1;
if (! chip-in_measurement)
ichdev-position %= ichdev-size;
ichdev-size is 0. Interrupt happened upon request_irq().
Does chip-in_measurement need to be reset because this is a
crashdump kernel?
No, the problem seems to be the timing of request_irq() and the
initialization of hardware. The irq handler shouldn't get called
there at all.
How about the patch below?
(snip)
This patch solves the problem for me. Thanks!
Good to hear! I forgot the patch description and sign-off, so here it
is again:
[PATCH] ALSA: intel8x0 - Fix Oops in crash kernel
When intel8x0 driver is loaded in the crash kernel, it gets Oops
occasionally. This is because the irq handler gets called before
the proper hardware initialization. Now defer it after
snd_intel8x0_chip_init().
(reference: http://lkml.org/lkml/2007/3/5/252)
Signed-off-by: Takashi Iwai [EMAIL PROTECTED]
---
sound/pci/intel8x0.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff -r 202af90f8e68 -r a3f021fd290c sound/pci/intel8x0.c
--- a/sound/pci/intel8x0.c Thu Apr 19 15:22:56 2007 +0200
+++ b/sound/pci/intel8x0.c Fri Apr 20 12:30:28 2007 +0200
@@ -2493,6 +2493,7 @@ static int intel8x0_resume(struct pci_de
return -EIO;
}
pci_set_master(pci);
+ snd_intel8x0_chip_init(chip, 0);
if (request_irq(pci-irq, snd_intel8x0_interrupt,
IRQF_SHARED, card-shortname, chip)) {
printk(KERN_ERR intel8x0: unable to grab IRQ %d,
@@ -2502,7 +2503,6 @@ static int intel8x0_resume(struct pci_de
}
chip-irq = pci-irq;
synchronize_irq(chip-irq);
- snd_intel8x0_chip_init(chip, 0);
/* re-initialize mixer stuff */
if (chip-device_type == DEVICE_INTEL_ICH4 !spdif_aclink) {
@@ -2862,16 +2862,7 @@ static int __devinit snd_intel8x0_create
ICH_REG_ALI_INTERRUPTSR : ICH_REG_GLOB_STA;
chip-int_sta_mask = int_sta_masks;
- /* request irq after initializaing int_sta_mask, etc */
- if (request_irq(pci-irq, snd_intel8x0_interrupt,
- IRQF_SHARED, card-shortname, chip)) {
- snd_printk(KERN_ERR unable to grab IRQ %d\n, pci-irq);
- snd_intel8x0_free(chip);
- return -EBUSY;
- }
- chip-irq = pci-irq;
pci_set_master(pci);
- synchronize_irq(chip-irq);
switch(chip-device_type) {
case DEVICE_INTEL_ICH4:
@@ -2900,6 +2891,15 @@ static int __devinit snd_intel8x0_create
snd_intel8x0_free(chip);
return err;
}
+
+ /* request irq after initializaing int_sta_mask, etc */
+ if (request_irq(pci-irq, snd_intel8x0_interrupt,
+ IRQF_SHARED, card-shortname, chip)) {
+ snd_printk(KERN_ERR unable to grab IRQ %d\n, pci-irq);
+ snd_intel8x0_free(chip);
+ return -EBUSY;
+ }
+ chip-irq = pci-irq;
if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, ops)) 0) {
snd_intel8x0_free(chip);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
On Fri, 20 Apr 2007 12:34:18 +0200 Takashi Iwai [EMAIL PROTECTED] wrote: Good to hear! I forgot the patch description and sign-off, so here it is again: [PATCH] ALSA: intel8x0 - Fix Oops in crash kernel When intel8x0 driver is loaded in the crash kernel, it gets Oops occasionally. This is because the irq handler gets called before the proper hardware initialization. Now defer it after snd_intel8x0_chip_init(). Neat, thanks. Do we think this is safe enough and important enough for 2.6.21? And if so, do you want me to merge it? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
At Fri, 20 Apr 2007 11:18:07 -0700, Andrew Morton wrote: On Fri, 20 Apr 2007 12:34:18 +0200 Takashi Iwai [EMAIL PROTECTED] wrote: Good to hear! I forgot the patch description and sign-off, so here it is again: [PATCH] ALSA: intel8x0 - Fix Oops in crash kernel When intel8x0 driver is loaded in the crash kernel, it gets Oops occasionally. This is because the irq handler gets called before the proper hardware initialization. Now defer it after snd_intel8x0_chip_init(). Neat, thanks. Do we think this is safe enough and important enough for 2.6.21? And if so, do you want me to merge it? It should be safe (as I already merged ALSA tree for 2.6.22), but I'd like to test the following before merging 2.6.21: - suspend/resume works - no severe problem even if request_irq() fails I'll check this in this weekend, so let's hold on. Takashi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
Hi Takashi,
Takashi Iwai napisał(a):
> At Mon, 16 Apr 2007 17:44:57 -0400,
> Chuck Ebbert wrote:
>> Adrian Bunk wrote:
>>
>>> This email lists some known regressions in Linus' tree compared to 2.6.20.
>>>
>>> Subject: snd_intel8x0: divide error:
>>> References : http://lkml.org/lkml/2007/3/5/252
>>> Submitter : Michal Piotrowski <[EMAIL PROTECTED]>
>>> Status : unknown
>>>
>> Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of
>> the interrupt handler:
>>
>> Line 751:
>>
>> ichdev->position += step * ichdev->fragsize1;
>> if (! chip->in_measurement)
>> ichdev->position %= ichdev->size;
>>
>> ichdev->size is 0. Interrupt happened upon request_irq().
>>
>> Does chip->in_measurement need to be reset because this is a
>> crashdump kernel?
>
> No, the problem seems to be the timing of request_irq() and the
> initialization of hardware. The irq handler shouldn't get called
> there at all.
>
> How about the patch below?
>
>
> Takashi
>
> diff -r 4b6ed4ef4820 sound/pci/intel8x0.c
> --- a/sound/pci/intel8x0.cMon Apr 16 19:20:17 2007 +0200
> +++ b/sound/pci/intel8x0.cTue Apr 17 11:02:49 2007 +0200
> @@ -2493,6 +2493,7 @@ static int intel8x0_resume(struct pci_de
> return -EIO;
> }
> pci_set_master(pci);
> + snd_intel8x0_chip_init(chip, 0);
> if (request_irq(pci->irq, snd_intel8x0_interrupt,
> IRQF_SHARED, card->shortname, chip)) {
> printk(KERN_ERR "intel8x0: unable to grab IRQ %d, "
> @@ -2502,7 +2503,6 @@ static int intel8x0_resume(struct pci_de
> }
> chip->irq = pci->irq;
> synchronize_irq(chip->irq);
> - snd_intel8x0_chip_init(chip, 0);
>
> /* re-initialize mixer stuff */
> if (chip->device_type == DEVICE_INTEL_ICH4 && !spdif_aclink) {
> @@ -2862,16 +2862,7 @@ static int __devinit snd_intel8x0_create
> ICH_REG_ALI_INTERRUPTSR : ICH_REG_GLOB_STA;
> chip->int_sta_mask = int_sta_masks;
>
> - /* request irq after initializaing int_sta_mask, etc */
> - if (request_irq(pci->irq, snd_intel8x0_interrupt,
> - IRQF_SHARED, card->shortname, chip)) {
> - snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
> - snd_intel8x0_free(chip);
> - return -EBUSY;
> - }
> - chip->irq = pci->irq;
> pci_set_master(pci);
> - synchronize_irq(chip->irq);
>
> switch(chip->device_type) {
> case DEVICE_INTEL_ICH4:
> @@ -2900,6 +2891,15 @@ static int __devinit snd_intel8x0_create
> snd_intel8x0_free(chip);
> return err;
> }
> +
> + /* request irq after initializaing int_sta_mask, etc */
> + if (request_irq(pci->irq, snd_intel8x0_interrupt,
> + IRQF_SHARED, card->shortname, chip)) {
> + snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
> + snd_intel8x0_free(chip);
> + return -EBUSY;
> + }
> + chip->irq = pci->irq;
>
> if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, )) < 0) {
> snd_intel8x0_free(chip);
>
This patch solves the problem for me. Thanks!
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
Hi Takashi,
Takashi Iwai napisał(a):
At Mon, 16 Apr 2007 17:44:57 -0400,
Chuck Ebbert wrote:
Adrian Bunk wrote:
This email lists some known regressions in Linus' tree compared to 2.6.20.
Subject: snd_intel8x0: divide error:
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski [EMAIL PROTECTED]
Status : unknown
Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of
the interrupt handler:
Line 751:
ichdev-position += step * ichdev-fragsize1;
if (! chip-in_measurement)
ichdev-position %= ichdev-size;
ichdev-size is 0. Interrupt happened upon request_irq().
Does chip-in_measurement need to be reset because this is a
crashdump kernel?
No, the problem seems to be the timing of request_irq() and the
initialization of hardware. The irq handler shouldn't get called
there at all.
How about the patch below?
Takashi
diff -r 4b6ed4ef4820 sound/pci/intel8x0.c
--- a/sound/pci/intel8x0.cMon Apr 16 19:20:17 2007 +0200
+++ b/sound/pci/intel8x0.cTue Apr 17 11:02:49 2007 +0200
@@ -2493,6 +2493,7 @@ static int intel8x0_resume(struct pci_de
return -EIO;
}
pci_set_master(pci);
+ snd_intel8x0_chip_init(chip, 0);
if (request_irq(pci-irq, snd_intel8x0_interrupt,
IRQF_SHARED, card-shortname, chip)) {
printk(KERN_ERR intel8x0: unable to grab IRQ %d,
@@ -2502,7 +2503,6 @@ static int intel8x0_resume(struct pci_de
}
chip-irq = pci-irq;
synchronize_irq(chip-irq);
- snd_intel8x0_chip_init(chip, 0);
/* re-initialize mixer stuff */
if (chip-device_type == DEVICE_INTEL_ICH4 !spdif_aclink) {
@@ -2862,16 +2862,7 @@ static int __devinit snd_intel8x0_create
ICH_REG_ALI_INTERRUPTSR : ICH_REG_GLOB_STA;
chip-int_sta_mask = int_sta_masks;
- /* request irq after initializaing int_sta_mask, etc */
- if (request_irq(pci-irq, snd_intel8x0_interrupt,
- IRQF_SHARED, card-shortname, chip)) {
- snd_printk(KERN_ERR unable to grab IRQ %d\n, pci-irq);
- snd_intel8x0_free(chip);
- return -EBUSY;
- }
- chip-irq = pci-irq;
pci_set_master(pci);
- synchronize_irq(chip-irq);
switch(chip-device_type) {
case DEVICE_INTEL_ICH4:
@@ -2900,6 +2891,15 @@ static int __devinit snd_intel8x0_create
snd_intel8x0_free(chip);
return err;
}
+
+ /* request irq after initializaing int_sta_mask, etc */
+ if (request_irq(pci-irq, snd_intel8x0_interrupt,
+ IRQF_SHARED, card-shortname, chip)) {
+ snd_printk(KERN_ERR unable to grab IRQ %d\n, pci-irq);
+ snd_intel8x0_free(chip);
+ return -EBUSY;
+ }
+ chip-irq = pci-irq;
if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, ops)) 0) {
snd_intel8x0_free(chip);
This patch solves the problem for me. Thanks!
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
At Mon, 16 Apr 2007 17:44:57 -0400,
Chuck Ebbert wrote:
>
> Adrian Bunk wrote:
>
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> >
> > Subject: snd_intel8x0: divide error:
> > References : http://lkml.org/lkml/2007/3/5/252
> > Submitter : Michal Piotrowski <[EMAIL PROTECTED]>
> > Status : unknown
> >
>
> Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of
> the interrupt handler:
>
> Line 751:
>
> ichdev->position += step * ichdev->fragsize1;
> if (! chip->in_measurement)
> ichdev->position %= ichdev->size;
>
> ichdev->size is 0. Interrupt happened upon request_irq().
>
> Does chip->in_measurement need to be reset because this is a
> crashdump kernel?
No, the problem seems to be the timing of request_irq() and the
initialization of hardware. The irq handler shouldn't get called
there at all.
How about the patch below?
Takashi
diff -r 4b6ed4ef4820 sound/pci/intel8x0.c
--- a/sound/pci/intel8x0.c Mon Apr 16 19:20:17 2007 +0200
+++ b/sound/pci/intel8x0.c Tue Apr 17 11:02:49 2007 +0200
@@ -2493,6 +2493,7 @@ static int intel8x0_resume(struct pci_de
return -EIO;
}
pci_set_master(pci);
+ snd_intel8x0_chip_init(chip, 0);
if (request_irq(pci->irq, snd_intel8x0_interrupt,
IRQF_SHARED, card->shortname, chip)) {
printk(KERN_ERR "intel8x0: unable to grab IRQ %d, "
@@ -2502,7 +2503,6 @@ static int intel8x0_resume(struct pci_de
}
chip->irq = pci->irq;
synchronize_irq(chip->irq);
- snd_intel8x0_chip_init(chip, 0);
/* re-initialize mixer stuff */
if (chip->device_type == DEVICE_INTEL_ICH4 && !spdif_aclink) {
@@ -2862,16 +2862,7 @@ static int __devinit snd_intel8x0_create
ICH_REG_ALI_INTERRUPTSR : ICH_REG_GLOB_STA;
chip->int_sta_mask = int_sta_masks;
- /* request irq after initializaing int_sta_mask, etc */
- if (request_irq(pci->irq, snd_intel8x0_interrupt,
- IRQF_SHARED, card->shortname, chip)) {
- snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
- snd_intel8x0_free(chip);
- return -EBUSY;
- }
- chip->irq = pci->irq;
pci_set_master(pci);
- synchronize_irq(chip->irq);
switch(chip->device_type) {
case DEVICE_INTEL_ICH4:
@@ -2900,6 +2891,15 @@ static int __devinit snd_intel8x0_create
snd_intel8x0_free(chip);
return err;
}
+
+ /* request irq after initializaing int_sta_mask, etc */
+ if (request_irq(pci->irq, snd_intel8x0_interrupt,
+ IRQF_SHARED, card->shortname, chip)) {
+ snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
+ snd_intel8x0_free(chip);
+ return -EBUSY;
+ }
+ chip->irq = pci->irq;
if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, )) < 0) {
snd_intel8x0_free(chip);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
At Mon, 16 Apr 2007 17:44:57 -0400,
Chuck Ebbert wrote:
Adrian Bunk wrote:
This email lists some known regressions in Linus' tree compared to 2.6.20.
Subject: snd_intel8x0: divide error:
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski [EMAIL PROTECTED]
Status : unknown
Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of
the interrupt handler:
Line 751:
ichdev-position += step * ichdev-fragsize1;
if (! chip-in_measurement)
ichdev-position %= ichdev-size;
ichdev-size is 0. Interrupt happened upon request_irq().
Does chip-in_measurement need to be reset because this is a
crashdump kernel?
No, the problem seems to be the timing of request_irq() and the
initialization of hardware. The irq handler shouldn't get called
there at all.
How about the patch below?
Takashi
diff -r 4b6ed4ef4820 sound/pci/intel8x0.c
--- a/sound/pci/intel8x0.c Mon Apr 16 19:20:17 2007 +0200
+++ b/sound/pci/intel8x0.c Tue Apr 17 11:02:49 2007 +0200
@@ -2493,6 +2493,7 @@ static int intel8x0_resume(struct pci_de
return -EIO;
}
pci_set_master(pci);
+ snd_intel8x0_chip_init(chip, 0);
if (request_irq(pci-irq, snd_intel8x0_interrupt,
IRQF_SHARED, card-shortname, chip)) {
printk(KERN_ERR intel8x0: unable to grab IRQ %d,
@@ -2502,7 +2503,6 @@ static int intel8x0_resume(struct pci_de
}
chip-irq = pci-irq;
synchronize_irq(chip-irq);
- snd_intel8x0_chip_init(chip, 0);
/* re-initialize mixer stuff */
if (chip-device_type == DEVICE_INTEL_ICH4 !spdif_aclink) {
@@ -2862,16 +2862,7 @@ static int __devinit snd_intel8x0_create
ICH_REG_ALI_INTERRUPTSR : ICH_REG_GLOB_STA;
chip-int_sta_mask = int_sta_masks;
- /* request irq after initializaing int_sta_mask, etc */
- if (request_irq(pci-irq, snd_intel8x0_interrupt,
- IRQF_SHARED, card-shortname, chip)) {
- snd_printk(KERN_ERR unable to grab IRQ %d\n, pci-irq);
- snd_intel8x0_free(chip);
- return -EBUSY;
- }
- chip-irq = pci-irq;
pci_set_master(pci);
- synchronize_irq(chip-irq);
switch(chip-device_type) {
case DEVICE_INTEL_ICH4:
@@ -2900,6 +2891,15 @@ static int __devinit snd_intel8x0_create
snd_intel8x0_free(chip);
return err;
}
+
+ /* request irq after initializaing int_sta_mask, etc */
+ if (request_irq(pci-irq, snd_intel8x0_interrupt,
+ IRQF_SHARED, card-shortname, chip)) {
+ snd_printk(KERN_ERR unable to grab IRQ %d\n, pci-irq);
+ snd_intel8x0_free(chip);
+ return -EBUSY;
+ }
+ chip-irq = pci-irq;
if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, ops)) 0) {
snd_intel8x0_free(chip);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
Adrian Bunk wrote: > This email lists some known regressions in Linus' tree compared to 2.6.20. > > Subject: snd_intel8x0: divide error: > References : http://lkml.org/lkml/2007/3/5/252 > Submitter : Michal Piotrowski <[EMAIL PROTECTED]> > Status : unknown > Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of the interrupt handler: Line 751: ichdev->position += step * ichdev->fragsize1; if (! chip->in_measurement) ichdev->position %= ichdev->size; ichdev->size is 0. Interrupt happened upon request_irq(). Does chip->in_measurement need to be reset because this is a crashdump kernel? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
Adrian Bunk wrote: This email lists some known regressions in Linus' tree compared to 2.6.20. Subject: snd_intel8x0: divide error: References : http://lkml.org/lkml/2007/3/5/252 Submitter : Michal Piotrowski [EMAIL PROTECTED] Status : unknown Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of the interrupt handler: Line 751: ichdev-position += step * ichdev-fragsize1; if (! chip-in_measurement) ichdev-position %= ichdev-size; ichdev-size is 0. Interrupt happened upon request_irq(). Does chip-in_measurement need to be reset because this is a crashdump kernel? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[1/2] 2.6.21-rc7: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: snd_hda_intel doesn't work with ASUS M2V mainboard References : http://bugzilla.kernel.org/show_bug.cgi?id=8273 Submitter : Hans-Georg Rist <[EMAIL PROTECTED]> Status : unknown Subject: snd_intel8x0: divide error: References : http://lkml.org/lkml/2007/3/5/252 Submitter : Michal Piotrowski <[EMAIL PROTECTED]> Status : unknown Subject: ali_pata: boot from CD fails References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark <[EMAIL PROTECTED]> Status : unknown Subject: kernels fail to boot with drives on ATIIXP controller (ACPI/IRQ related) References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 http://lkml.org/lkml/2007/3/4/257 Submitter : Michal Jaegermann <[EMAIL PROTECTED]> Status : unknown Subject: boot failure: rtl8139: exception in interrupt routine References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark <[EMAIL PROTECTED]> Status : unknown Subject: laptops with e1000: lockups References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Submitter : Dave Jones <[EMAIL PROTECTED]> Handled-By : Jesse Brandeburg <[EMAIL PROTECTED]> Status : problem is being debugged Subject: forcedeth: interface hangs under load References : http://lkml.org/lkml/2007/4/3/39 http://www.spinics.net/lists/netdev/msg28981.html Submitter : Ingo Molnar <[EMAIL PROTECTED]> Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Ayaz Abdulla <[EMAIL PROTECTED]> David Miller <[EMAIL PROTECTED]> Status : problem is being debugged Subject: hal daemon crashes after pulling a USB serial device References : http://www.opensubscriber.com/message/[EMAIL PROTECTED]/6369800.html Submitter : Andi Kleen <[EMAIL PROTECTED]> Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Status : problem is being debugged Subject: Oops when changing USB DVB-T adapter References : http://lkml.org/lkml/2007/3/9/212 http://lkml.org/lkml/2007/4/5/154 Submitter : CIJOML <[EMAIL PROTECTED]> Handled-By : Markus Rechberger <[EMAIL PROTECTED]> Status : patches available - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[1/2] 2.6.21-rc7: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: snd_hda_intel doesn't work with ASUS M2V mainboard References : http://bugzilla.kernel.org/show_bug.cgi?id=8273 Submitter : Hans-Georg Rist [EMAIL PROTECTED] Status : unknown Subject: snd_intel8x0: divide error: References : http://lkml.org/lkml/2007/3/5/252 Submitter : Michal Piotrowski [EMAIL PROTECTED] Status : unknown Subject: ali_pata: boot from CD fails References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark [EMAIL PROTECTED] Status : unknown Subject: kernels fail to boot with drives on ATIIXP controller (ACPI/IRQ related) References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 http://lkml.org/lkml/2007/3/4/257 Submitter : Michal Jaegermann [EMAIL PROTECTED] Status : unknown Subject: boot failure: rtl8139: exception in interrupt routine References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark [EMAIL PROTECTED] Status : unknown Subject: laptops with e1000: lockups References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Submitter : Dave Jones [EMAIL PROTECTED] Handled-By : Jesse Brandeburg [EMAIL PROTECTED] Status : problem is being debugged Subject: forcedeth: interface hangs under load References : http://lkml.org/lkml/2007/4/3/39 http://www.spinics.net/lists/netdev/msg28981.html Submitter : Ingo Molnar [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Ayaz Abdulla [EMAIL PROTECTED] David Miller [EMAIL PROTECTED] Status : problem is being debugged Subject: hal daemon crashes after pulling a USB serial device References : http://www.opensubscriber.com/message/[EMAIL PROTECTED]/6369800.html Submitter : Andi Kleen [EMAIL PROTECTED] Handled-By : Oliver Neukum [EMAIL PROTECTED] Status : problem is being debugged Subject: Oops when changing USB DVB-T adapter References : http://lkml.org/lkml/2007/3/9/212 http://lkml.org/lkml/2007/4/5/154 Submitter : CIJOML [EMAIL PROTECTED] Handled-By : Markus Rechberger [EMAIL PROTECTED] Status : patches available - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
