From: Michael M. <mma...@gm...> - 2005-04-26 02:46:26
|
I've encountered a hang (during boot) with the 2.6.11.4 kernel (SUSE 9.3) if IRDA is enabled. From the sysrq P output it seems to cycle in sir_kthread.c delay_pmtmr irda_tx_complete_fsm irda_config_fsm Hardware: HP nx7010 laptop IRDA works ok when the boot is completed Any ideas/pointers?=20 What debug output would be useful (enable IRDA_DEBUG ?) |
From: Martin D. <li...@md...> - 2005-04-27 20:05:29
|
On Tue, 26 Apr 2005, Michael Marxmeier wrote: > I've encountered a hang (during boot) with the 2.6.11.4 kernel (SUSE 9.3) > if IRDA is enabled. > > >From the sysrq P output it seems to cycle in sir_kthread.c > delay_pmtmr > irda_tx_complete_fsm > irda_config_fsm strange - irda_tx_complete_fsm doesn't call delay_pmtmr directly. It calls some delays, yes, but it seems these are done using some special PM timer in your case - personally, I haven't seen this yet. Please try with CONFIG_X86_PM_TIMER disabled (somewhere in the ACPI-section). And im wondering why it hangs there in the first place. delay_pmtmr seems to be just a busy loop waiting for some special timer providing the delay. So I think this can only happen if the loop parameter gets miscalculated there. I think the very idea of this timer is to get independent from PM and cpufreq time warps, so I don't see why it might fail here... Wait, I'm just spotting delay_pmtmr is calling rdtscl() - shouldn't this just call read_pmtmr() instead!? Maybe the patch below would help then... > Hardware: HP nx7010 laptop What kind of irda-hardware: onboard-uart (ttySx) or some usb-to-serial bridge (i.e. serial dongle on usb, maybe combined casing like ma620)? > IRDA works ok when the boot is completed > Any ideas/pointers? > What debug output would be useful (enable IRDA_DEBUG ?) Yes, enable it in the kernel config and set /proc/sys/net/irda/debug to 3. Must be something special during boot - sounds like some odd interaction with this special timer (acpi-related?). I don't have this hardware to reproduce, so if the above doesn't help, we need to find out, how it happens to get into delay_pmtmr from irda sir_kthread. Please send the recorded SysRq+P output (maybe catched from serial console, if not possible locally). But first, lets see if the above suggestions help. Please try: 1) With CONFIG_X86_PM_TIMER disabled 2) With CONFIG_X86_PM_TIMER enabled and the patch below applied HTH, Martin ------------------------- --- linux-2.6.11/arch/i386/kernel/timers/timer_pm.c 2005-03-02 08:37:48.000000000 +0100 +++ v2.6.11-md/arch/i386/kernel/timers/timer_pm.c 2005-04-27 21:50:03.730926256 +0200 @@ -214,11 +214,11 @@ static void delay_pmtmr(unsigned long lo { unsigned long bclock, now; - rdtscl(bclock); + bclock = read_pmtmr(); do { rep_nop(); - rdtscl(now); + now = read_pmtmr(); } while ((now-bclock) < loops); } |
From: Dominik B. <li...@do...> - 2005-05-04 21:06:03
|
Hi, Did this get fixed yet? On Wed, Apr 27, 2005 at 09:04:59PM +0200, Martin Diehl wrote: > Wait, I'm just spotting delay_pmtmr is calling rdtscl() - shouldn't this > just call read_pmtmr() instead!? Maybe the patch below would help then... pmtmr takes much longer to access and seemed to cause other trouble (which may be fixed in the meantime[*]), therefore it is (currently) not used for delay_pmtmr. John, should we be brave and try it out again in -mm for a while? Thanks, Dominik [*] previously, the number of ticks to be spent in the loop were rounded _down_. For TSC, this doesn't matter much as getting to the loop takes a few instructions. For other timers with lesser granularity, fixing up the calculations was much more important. |
From: john s. <joh...@us...> - 2005-05-04 21:57:20
|
On Wed, 2005-05-04 at 23:05 +0200, Dominik Brodowski wrote: > Hi, > > Did this get fixed yet? > > On Wed, Apr 27, 2005 at 09:04:59PM +0200, Martin Diehl wrote: > > Wait, I'm just spotting delay_pmtmr is calling rdtscl() - shouldn't this > > just call read_pmtmr() instead!? Maybe the patch below would help then... > > pmtmr takes much longer to access and seemed to cause other trouble (which > may be fixed in the meantime[*]), therefore it is (currently) not used for > delay_pmtmr. John, should we be brave and try it out again in -mm for a > while? > > Thanks, > Dominik > > [*] previously, the number of ticks to be spent in the loop were rounded > _down_. For TSC, this doesn't matter much as getting to the loop takes a few > instructions. For other timers with lesser granularity, fixing up the > calculations was much more important. Sounds like an ok idea. Is there an actual bug that is being seen from this? I might say just be lazy and just use a looped based delay as accessing the pmtmr three times is going to take a couple usecs. That puts a big latency on the smallest delay time. Using a loop based delay would still be prone to cpufreq changes, but at least it wouldn't have issues w/ unsynced TSCs. An audit of the callers of __delay() is probably in order. If we can know what smallest wait time is expected to be. thanks -john |
From: Daniel <dan...@cs...> - 2005-05-05 16:19:41
|
I have a USB dongle that is suppose to be an IR device. But lsusb reports the product ID as 7703, which is suppose to be a usb 2 serial bridge. lsusb: ID 9710:7703 If this is just IR ontop of a usb2rs232 device can it still be used with IRDA? Do I have to run irattach? I tried using the generic usb-serial device but had no success either receving or sending to another (nsc) irda device. Anyone see something like this before? Is there a driver for the msc7703? -Daniel |
From: Dominik B. <li...@do...> - 2005-05-04 22:49:56
|
Hi, On Wed, May 04, 2005 at 02:57:06PM -0700, john stultz wrote: > Sounds like an ok idea. Is there an actual bug that is being seen from > this? IIRC there were some touchpad users complaining back when pmtmr was introduced with pmtmr-based delay loops at first. Whether this is still true I do not know. > I might say just be lazy and just use a looped based delay as accessing > the pmtmr three times is going to take a couple usecs. That puts a big > latency on the smallest delay time. Using a loop based delay would still > be prone to cpufreq changes, but at least it wouldn't have issues w/ > unsynced TSCs. >=20 > An audit of the callers of __delay() is probably in order. If we can > know what smallest wait time is expected to be.=20 {u,n}delay calls on my notebook since 4 min=20 between x and y nanoseconds: 0 - 9 : 0000000000=20 10 - 99 : 0000000000 100 - 999 : 0000031731 1000 - 9999 : 0000005631 10000 - 99999 : 0000001682 100000 - 999999 : 0000000072 1000000 - 9999999 : 0000000010 >=3D10000000 : 0000000000 =3D=3D> with pmtmr having ~3.6 ticks per us, and all calls (even up to now)= to delay routines passing ndelay > 100, pmtmr looks like a valid option... However, we might only read out _one_ value, and just re-read it if it doesn't look valid, e.g. if (loops >=3D ACPI_PM_MASK) panic("we'd sleep too long!\n"); bclock =3D inl(pmtmr_ioport); now =3D bclock; do { rep_nop(); check =3D now + 100; now =3D inl(pmtmr_ioport); if (((now-bclock) & ACPI_PM_MASK) < ((now-check) & ACPI_PM_MASK)) { /* something went bad. Play it safe now. */ bclock =3D read_pmtmr(); continue; } } while (((now-bclock) & ACPI_PM_MASK) < loops); =09 Oh, and we need to disable the loops_per_jiffy adjustment by cpufreq... or, even ebtter, move the multiplication with loops_per_jiffy inside each timer's ->delay(); function... or, even better, merge your tod rework first ;) Thanks, Dominik BTW: the ratio of delay() calls didn't change much in between starting the mail and now... uptime is 20 min now. |