Hate to say it but 13.37 has too many issues for me to be considered compatible and stable. While it is a nice release, there are too many issues with how the system handles itself for my tastes to be considered usable without a severe fight that I do not wish to continue on with.

I do ask that the developers of Slackware, if they do indeed read this, please take into consideration that 13.1 support needs to be extended until the next version can come out that has the same levels of stability and ease of use 13.1 has.

Sorry, but hope this feedback can be of usage to find out what could be wrong with 13.37.

Not to be negative, but 13.37 did feel a bit BETA.

Could you elaborate on the issues that you have? I'm sure somebody will be able to help you here. Personally, I don't feel that 13.37 is any less stable than the previous version.

Would be helpful if you actually stated the problems you're having so that someone could help... I'm running 13.37 with no problems at all.

I don't think you have to worry about support for 13.1 ending any time soon.

Yes, there's another story. I've just checked and the security patches for Slackware 10.0 were released last month.

Please post the issues that you're having with 13.37 so that we can help you. I'm running 13.37 on four work stations and slackware-current on two computers. All of my PCs are running rock-steady with no issues to speak of.

No problems here. 13.37 running 24/7.

Nope, it isn't. Next time try reporting bugs.

2 members found this post helpful.

Vague complaints about generally poor quality posted by a newbie (to lq) with no specifics...seems like trolling. "Not to be negative", of course.

Brian

Well I'm fairly uncertain where to start because the issue I have doesn't appear on 13.1 oddly and I did nothing but the same thing on 13.37 to cause the problem.

Basically on 13.37 when I start up KDE, my network just stops working totally. Even happens when using wICD also. I've checked ifconfig and it says DHCP is working but nothing will work and if I restart the connecting using either dhcpcd or wICD it just stays dead. This does not happen on 13.1 using the same tools and network configuration for DHCP.

I've double checked my own configuration and even read several documents and I keep hitting dead ends.

Maybe it's something with the way KDE handles something because on 13.1 everything works perfectly with my network and I use an ASIX (LinkSYS) USB300 adapter with a Zoom X6 series ADSL router+modem.

I didn't mean to be vague but after 8.5 hours I'm still lost but needed a working system.

It's just odd this problem happened on 13.37 but not 13.1. But at least temporarily I have a usable system till whatever the issue is can be found.

Hello ReaperX7,

could you please post the output ofwhen the wireless-adapter is connected. And please post the output of and And please provide additional information, you wrote that your wireless-connection stops when you start KDE, is this really true? Does it work before starting KDE, then please post the output of the above commands before and after you started KDE. Also please check if this depends on KDE only (try fluxbox instead for example).

Did you use wicd with 13.1? Or did you install wicd because you've got the network not working with 13.37?

Markus

I just installed 13.37 (32 bit) on an intel atom 330 motherboard, new seagate hd. The keyboard input is extremely slow and the keyboard is practically unusable. The syslog is full of messages having to do with ACPI exception: AE_AML_INFINITE_LOOP and I suspect the processor is spending most of its time on this. I am using a different computer to sent this post, because the keyboard is that bad. I have not found the cause of the error. I was thinking that the 2.6.38 kernel in testing plus mesa and libdrm might help, but I have not tried that yet. I also saw something about disabling Composite in the /etc/X11/xorg.conf.d, but I have not tried that either. When the poster says "too many issues" he may be referring to problems like these.

Well, in this case you could easily kill the X-server and try out if the issue remains without X.

BTW: googling for "AE_AML_INFINITE_LOOP" shows that the forums for several distributions are full of this error and therefore it is at least not a Slackware related issue.

Markus

I upgraded 2 laptops from 13.1 to 13.37 but they then proved to be unstable with crashes and restarts becoming common. I figured it was probably the 2.6.37.6 kernel that was the problem.

With one of the laptops, switching to the 2.6.38.4 kernel fixed the problems. With the other laptop I had to reinstall the 2.6.33.4 kernel. Fortunately, I didn't have to downgrade the packages (but I am not running wireless).

Thanks for the reply. I have made progress. I don't know why my initial google searches did not turn up a solution, because when I tried again I found something that seems to work. Unfortunately, I lost the site when I put in a slightly different query. Here is what I learned:

Intel D945GCLF2, with Atom 330 processor

The error [from /var/log/syslog]:
kernel: [ 5817.708236] ACPI Exception: AE_AML_INFINITE_LOOP, while evaluating GPE method [_L00] (20101013/evgpe-503)

The solution?
append a clock= to the kernel parameters line in lilo.conf

as root, edit /etc/lilo.conf
run the command: lilo
reboot

See /usr/src/linux/Documentation/kernel-parameters.txt [clock (deprecated), clocksource]

I should have added "clocksource=hpet" instead of "clock=acpi_pm" because syslog now reports:
Override clocksource acpi_pm is not HRT compatible. Cannot switch while in HRT/NOHZ mode

and dmesg says:
[ 0.490224] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[ 0.490224] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[ 0.490224] hpet0: 3 comparators, 64-bit 14.318180 MHz counter
[ 0.496034] Switching to clocksource hpet

However, syslog is not adding 37,000+ lines and the system seems to be working much better.

I will change the append line in lilo.conf with clocksource=hpet, reboot, and see what happens.
If that does not work I'll post again, otherwise, problem appears solved.

Added: changed "clock=acpi_pm" to "clocksource=hpet" which seems to work fine (could not resist updating the post).

=== Well, if did not quite work, but I did some more. The problem would seem solved, but then reappear. Since it involves ACPI, I thought perhaps something was looking for things that were not there or otherwise getting wrong responses from the motherboard bios.

I checked the kernel situation and discovered that I did not know what I was running. I thought it was the generic smp kernel, but it wasn't. It was the huge-smp kernel
So I added a symlink to the vmlinuz-generic-smp-2.6.37.6-smp (as root). I recall an error in the past when my image name was too long, so I make symlinks. I could have changed the existing link, but I just added another one.
I thought I needed to get the /boot/initrd.gz situation straightened out, because my /etc/lilo.conf did not mention an initrd.

I am using /usr/share/mkinitrd/mkinitrd_command_generator.sh to create a /etc/mkinitrd.conf file -- use -c option to generate output for a config file and -k [kernel]

Copy the output to /etc/mkinitrd.conf, perhaps changing the name of the OUTPUT_IMAGE="/boot/initrd.gz" to OUTPUT_IMAGE="/boot/initrd-slack.gz" so the existing /boot/initrd is not overwritten.

Then, also as root (the -F option tells mkinird to use the config file:
Then I edited /etc/lilo.conf to change the "stanza" for booting slackware by changing the image, adding the initrd line, and change label to Slackware.
Run lilo
OK, now after rebooting it seems the problem is gone and it has not come back. I guess this means I missed something in the installation, since I would not want to run the huge-smp kernel ordinarily.

I also compiled a custom kernel for this motherboard, since I have a few, but it doesn't make much difference in performance.

Thanks