-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If I set CONFIG_RTC=m and rebuild, when the kernel autoloads rtc.ko the
system immediately locks hard, not responding even to magic SysRq series.
Backing out either of the rtc-* patches from -mm8 does not seem to fix the
problem.
Hardware is a Fujitsu P2120 with Transmeta TM8500 with ALi chipset:
00:00.0 Host bridge: Transmeta Corporation LongRun Northbridge (rev 03)
00:00.1 RAM memory: Transmeta Corporation SDRAM controller
00:00.2 RAM memory: Transmeta Corporation BIOS scratchpad
00:02.0 USB Controller: ALi Corporation. [ALi] USB 1.1 Controller (rev 03)
00:04.0 Multimedia audio controller: ALi Corporation. [ALi] M5451 PCI
AC-Link Controller Audio Device (rev 01)
00:06.0 Bridge: ALi Corporation. [ALi] M7101 PMU
00:07.0 ISA bridge: ALi Corporation. [ALi] M1533 PCI to ISA Bridge
[Aladdin IV]
00:09.0 USB Controller: NEC Corporation USB (rev 41)
00:09.1 USB Controller: NEC Corporation USB (rev 41)
00:09.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
00:0c.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus
Controller (rev 01)
00:0f.0 IDE interface: ALi Corporation. [ALi] M5229 IDE (rev c3)
00:10.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
00:12.0 Network controller: Harris Semiconductor Prism 2.5 Wavelan chipset
(rev 01)
00:13.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000
Controller (PHY/Link)
00:14.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6
LY
Any additional information needed I'll be happy to provide.
- --nwf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+6TLZR4WVIgmDWjIRAsSNAJ0UZUq/4A4MmQ4DHcl6qnncWcIFDwCfSUYD
mE9xrtTweq57eM95dbs9Tbo=
=iUCG
-----END PGP SIGNATURE-----
On Thu, Jun 12, 2003 at 10:12:06PM -0400, Nathaniel W. Filardo wrote:
> If I set CONFIG_RTC=m and rebuild, when the kernel autoloads rtc.ko the
> system immediately locks hard, not responding even to magic SysRq series.
> Backing out either of the rtc-* patches from -mm8 does not seem to fix the
> problem.
>
> Hardware is a Fujitsu P2120 with Transmeta TM8500 with ALi chipset:
I saw this on the same hardware on 2.4.21-rc7-ac1, and I've seen a
report of the same on -rc1-ac3, but not on module loading, on accessing
the driver. The problem doesn't seem to be present when running the non
-acX kernels.
Alan asked whether it was a specific in or out instruction in the
driver, but I don't know how to find out.
Danek
On Gwe, 2003-06-13 at 03:12, Nathaniel W. Filardo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> If I set CONFIG_RTC=m and rebuild, when the kernel autoloads rtc.ko the
> system immediately locks hard, not responding even to magic SysRq series.
> Backing out either of the rtc-* patches from -mm8 does not seem to fix the
> problem.
It seems to be ALI + ACPI related but I dont yet understand what is
going on
Hi,
> Alan asked whether it was a specific in or out instruction in the
> driver, but I don't know how to find out.
rtc_read never returns. It is busy waiting for a rtc interrupt to arrive.
Which will never do... I blaim ACPI, as it works fine with acpi=off.
Regards,
Florian
On Friday 13 June 2003 01:25, Alan Cox wrote:
> On Gwe, 2003-06-13 at 03:12, Nathaniel W. Filardo wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > If I set CONFIG_RTC=m and rebuild, when the kernel autoloads
> > rtc.ko the system immediately locks hard, not responding even to
> > magic SysRq series. Backing out either of the rtc-* patches from
> > -mm8 does not seem to fix the problem.
>
> It seems to be ALI + ACPI related but I dont yet understand what is
> going on
>
I'm running a Toshiba Libretto L2 (Crusoe, ACPI, ALI). I don't have
any troubles with 2.5.63 (which happens to be my current stable
kernel). However, I've been playing with 2.4.21 with just the swsusp
patches (not -ac) and with most builds I've tried there, invoking
hwclock always hangs the machine (which I assume is rtc related).
Let me know if I can provide any more information...
Eric
Oops. Incorrect swsusp maillist address in previous email...sorry if
people get bounces when they reply to that msg.
--eric
On Tuesday 17 June 2003 12:34, Eric Altendorf wrote:
> On Friday 13 June 2003 01:25, Alan Cox wrote:
> > On Gwe, 2003-06-13 at 03:12, Nathaniel W. Filardo wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > If I set CONFIG_RTC=m and rebuild, when the kernel autoloads
> > > rtc.ko the system immediately locks hard, not responding even
> > > to magic SysRq series. Backing out either of the rtc-* patches
> > > from -mm8 does not seem to fix the problem.
> >
> > It seems to be ALI + ACPI related but I dont yet understand what
> > is going on
>
> I'm running a Toshiba Libretto L2 (Crusoe, ACPI, ALI). I don't
> have any troubles with 2.5.63 (which happens to be my current
> stable kernel). However, I've been playing with 2.4.21 with just
> the swsusp patches (not -ac) and with most builds I've tried there,
> invoking hwclock always hangs the machine (which I assume is rtc
> related).
>
> Let me know if I can provide any more information...
>
> Eric
>
>
> -
> 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/
I can confirm the RTC problems on a Fujitsu LifeBook P2120 (Crusoe
TM5800, ALi, ACPI). In my case I was even more fortunate (??) since
using RTC (either compiled-in in the kernel and/or as a module), any
call to "hwclock" locks the machine rock solid (not even SysRQ
works). So for me the RTC issue is not at all swsusp related.
Back to swsusp: I'm more than happy to annonce that I just discovered
that -pre11 works !! Actually, after reading a bit more closely this
list (*gasp*) and trying the suspend the machine AFTER modules were
unloaded (WLAN, USBs), networking stopped and all non-critical daemons
terminated (basically switching to run-level 1, terminating daemons
and unloading modules), the suspend worked !! And resuming too :)) !!
As such, after a horrible hack of the old suspend.sh script (from
swsusp-beta17) and using "echo -n 4 > /proc/acpi/sleep" the
suspension+resuming process worked (at least once...).
On less extatic but more useful note: It seems that if I start the
suspending process by hand (i.e. swsusp utility) while PCMCIA and USBs
are stopped but __not__ networking, the resume process freezes. I can
use SysRq+T at this point, but since this is a "legacy free" laptop, I
have no idea how to hook on a serial console there and come w/ a
useful bug report. If anyone has an idea how to do that, I'll be more
than happy to help w/ more testing.
HTH,
Florian
Ermm.....Me bad :). I was talking 2.4.21 here...
Anyway, take it for what it's worth.
Florian
Florian-Daniel Otel writes:
>
>
>
> I can confirm the RTC problems on a Fujitsu LifeBook P2120 (Crusoe
> TM5800, ALi, ACPI). In my case I was even more fortunate (??) since
> using RTC (either compiled-in in the kernel and/or as a module), any
> call to "hwclock" locks the machine rock solid (not even SysRQ
> works). So for me the RTC issue is not at all swsusp related.
>
> Back to swsusp: I'm more than happy to annonce that I just discovered
> that -pre11 works !! Actually, after reading a bit more closely this
> list (*gasp*) and trying the suspend the machine AFTER modules were
> unloaded (WLAN, USBs), networking stopped and all non-critical daemons
> terminated (basically switching to run-level 1, terminating daemons
> and unloading modules), the suspend worked !! And resuming too :)) !!
>
> As such, after a horrible hack of the old suspend.sh script (from
> swsusp-beta17) and using "echo -n 4 > /proc/acpi/sleep" the
> suspension+resuming process worked (at least once...).
>
> On less extatic but more useful note: It seems that if I start the
> suspending process by hand (i.e. swsusp utility) while PCMCIA and USBs
> are stopped but __not__ networking, the resume process freezes. I can
> use SysRq+T at this point, but since this is a "legacy free" laptop, I
> have no idea how to hook on a serial console there and come w/ a
> useful bug report. If anyone has an idea how to do that, I'll be more
> than happy to help w/ more testing.
>
>
> HTH,
>
> Florian
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> swsusp-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/swsusp-devel
On Thu, Jun 19, 2003 at 10:41:13AM +0200, Florian-Daniel Otel wrote:
> I can confirm the RTC problems on a Fujitsu LifeBook P2120 (Crusoe
> TM5800, ALi, ACPI). In my case I was even more fortunate (??) since
> using RTC (either compiled-in in the kernel and/or as a module), any
> call to "hwclock" locks the machine rock solid
Ditto. Also an ALi here. I traced it through (printk debugging) and
it appears to lock up in the call to schedule() in rtc_read().
(2.4.21)
Has happened since about 2.4.21-pre3'ish. Haven't had time yet to
establish exactly which release (or ACPI release) started it.
A quirkier but similar bug - this laptop would freeze when writing
to the hardware clock *IF* there was a CD-ROM in the drive (IDE).
This freeze also seemed to occur at midnight most nights. Ejecting
the CD-ROM before saving the hwclock and also at 11:59pm disabled
the problem. This problem existed even without ACPI.
Bernard.
--
Bernard Blackham
bernard at blackham dot com dot au
Hi!
> On less extatic but more useful note: It seems that if I start the
> suspending process by hand (i.e. swsusp utility) while PCMCIA and USBs
> are stopped but __not__ networking, the resume process freezes. I can
> use SysRq+T at this point, but since this is a "legacy free" laptop, I
I guess you need to write suspend/resume
support for your network card...
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...