Page 3 of 25

Posted: Mon 16 Jan 2012, 22:23
by DaveS
Fresh install and screen driver issue is gone :)
Yes, its all JWM.

Posted: Mon 16 Jan 2012, 22:58
by James C
01micko wrote: James,
Good nouveau worked for you for a change :lol:
Worked well on the newish quad, working well on my main Athlon XP box with the old Nvidia card.Live pfix=ram at the moment,frugal install to follow in a minute.

# report-video
VIDEO REPORT: Slacko Puppy, version 5.3.1.2

Chip description:
oem: NVidia
product: NV18 () Board Chip Rev A2

Driver used by Xorg:
vesa

Video mode used by Xorg:
Resolution: "1440x900" Depth: Depth 24

...the above also recorded in /tmp/report-video

Actually using nouveau.....but "nv" generally works on the older cards as well.

Code: Select all

[   107.679] (II) LoadModule: "nouveau"
[   107.680] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
-Computer-
Processor : AMD Athlon(tm) XP 2400+
Memory : 1034MB (159MB used)
Operating System : Unknown distribution
User Name : root (root)
Date/Time : Mon 16 Jan 2012 04:55:29 PM CST
-Display-
Resolution : 1440x900 pixels
OpenGL Renderer : Unknown
X11 Vendor : The X.Org Foundation
-Multimedia-
Audio Adapter : VIA8233 - VIA 8235
Ethernet controller : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
VGA compatible controller : nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x]

All good so far.

Posted: Mon 16 Jan 2012, 23:08
by 01micko
Try this hacked report-video pet. If it works I'll bung it in.

It's a known bug that report-video fails when boot to desktop is enabled. Should still work if you use xorgwizard, gets the results from /var/log/Xorg.0.log

Code: Select all

VIDEO REPORT: Slacko Puppy, version 5.3.1.2

Chip description:
oem: NVIDIA
product: G98 Board - 5610002u Chip Rev

Driver used by Xorg:
nouveau

Video mode used by Xorg:
Resolution: "1280x1024"  Depth: Depth 24

...the above also recorded in /tmp/report-video
Note that report-video-glx has the same bug.

Also note that if you have nouveau you can install mesa and get accelerated graphics.

Posted: Mon 16 Jan 2012, 23:17
by James C
Works.

Code: Select all

# report-video
VIDEO REPORT: Slacko Puppy, version 5.3.1.2

Chip description:
oem: NVidia
product: NV18 () Board Chip Rev A2

Driver used by Xorg:
nouveau

Video mode used by Xorg:
Resolution: "1440x900"  Depth: Depth 24

...the above also recorded in /tmp/report-video

I ran the quad through xorgwizard before posting earlier just in case.... :lol:

Posted: Mon 16 Jan 2012, 23:25
by James C
Testing on a fresh manual frugal now.Good so far.

Posted: Mon 16 Jan 2012, 23:42
by 01micko
ALL b43 users, I need kernel logs from a pfix=ram before you load up b43!

I have PMed rerwin and if he decides to help he will likely need those. (maybe other logs too, TBA)

TIA

Posted: Tue 17 Jan 2012, 00:08
by Jim1911
01micko wrote:if you have any feature requests NOW is the time! Next will be beta and feature freeze.
Please consider replacing Barry's shutdownconfig with shinobar's pupsaveconfigwhich is faster and has more features ie: It makes ext4 internal file system of the savefile as the default if the kernel supports ext4.

Thanks,
Jim

Posted: Tue 17 Jan 2012, 00:10
by 01micko
Jim1911 wrote:
01micko wrote:if you have any feature requests NOW is the time! Next will be beta and feature freeze.
Please consider replacing Barry's shutdownconfig with shinobar's pupsaveconfigwhich is faster and has more features ie: It makes ext4 internal file system of the savefile as the default if the kernel supports ext4.

Thanks,
Jim
Already in planning stages.. I guess you saw my beef against pupdialog! :lol:

Posted: Tue 17 Jan 2012, 00:40
by Karl Godt
please note :

/sbin/pup-event_backend_modprobe

load the module

IF

IF

IF

the modalias is supplied in the relevant files in /lib/modules/KERNELVERSION/modules.[alias]

CREATED by depmod || busybox depmod .

I had encountered problems that the code in the kernel source changes .

what had been
alias xzy0123 module.ko

became
alias pci:xzy0123 module.ko

and no module loading anymore .

mostly ALL of my temperature modules i had to load manually OR by bootmanager

[ i still don't understand people using /etc/rc.d/rc.local for this , not bootmanager :evil: ]

Today it was 'option' module again not autoloaded .
modinfo b43 shows

alias: pcmcia:m02D0c0476f*fn*pfn*pa*pb*pc*pd*
alias: pcmcia:m02D0c0448f*fn*pfn*pa*pb*pc*pd*
alias: ssb:v4243id0812rev10*
alias: ssb:v4243id0812rev0F*
alias: ssb:v4243id0812rev0D*
alias: ssb:v4243id0812rev0C*
alias: ssb:v4243id0812rev0B*
alias: ssb:v4243id0812rev0A*
alias: ssb:v4243id0812rev09*
alias: ssb:v4243id0812rev07*
alias: ssb:v4243id0812rev06*
alias: ssb:v4243id0812rev05*

*
This i had added to /sbin/pup_event_backend_modprobe
to reduce "pbb:xzy0321" to "xzy0312" for loading these too

Code: Select all

#find a matching module... (/etc/pup_event_modprobe.conf created in rc.sysinit)
MODULES="`/sbin/modprobe --config /tmp/pup_event_skiplist.conf --show-depends $MODALIAS 2>/dev/null | rev | cut -f 1 -d '/' | rev | cut -f 1 -d '.' | tr '\-' '_'`" #v424
MODULE="`echo "$MODULES" | tail -n 1`" #v424
#[ "$MODULE" = "usb_storage" ] && [ "`echo "$MODULES" | grep '^usbserial$'`" != "" ] && MODULE="`echo "$MODULES" | grep -v -E '^usb_storage$|^usbcore$' | tail -n 1`" #v424
echo $$ 03.0 `$TIME` 'MODULE='"$MODULE" >> $LocalLOG

[ "$MODULE" = "" ] && [ "$RULEMODULE" != "" ] && MODULE="$RULEMODULE" #w463 Use module from argument

echo $$ 03.0 `$TIME` 'MODULE='"$MODULE" >> $LocalLOG

if [ -z "$MODULE" ] ; then
grepPAT=${MODALIAS#*:} ## ${MODALIAS/*:/}
MODULES="`/sbin/modprobe --config /tmp/pup_event_skiplist.conf --show-depends $grepPAT 2>/dev/null | rev | cut -f 1 -d '/' | rev | sed 's/\.ko//g' | tr '-' '_'`"
MODULE="`echo "$MODULES" | tail -n 1 | sed 's/^[[:blank:]]*// ; s/[[:blank:]]*$//'`"
echo $$ 03.5 `$TIME` 'MODULE='"$MODULE" >> $LocalLOG
fi
BUT i have NOT updated the modules.alias files by depmod !!

Posted: Tue 17 Jan 2012, 02:16
by Lobster
Ffmpeg will not be updated to keep compatibility with mlt, a dependency of openshot-1.4. I may offer a 0.9x version in PPM.
I am using Openshot 1.4 in Slacko 5.3.1 [note version number] using the SFS under JWM (which is quite something) There are issues (with Openshot which is still not perfect . . .) for example many processor threads are opened whilst using and after maybe 40 mins I have to save and restart x or ideally reboot. I want to get Openshot working with Blender (another major program) very soon in the new kernel alpha/beta . . . soon . . . I am using the non PAE version very successfully :)

Regarding updates +1 for Shinos work and an extension of Slickpet to full Quickpet status (so as similar to Lucids range)

To our intrepid testers, do be aware that our wiki page here is integrated into Slacko and always needs further work
http://puppylinux.org/wikka/SlackoNews

I am also hoping the latest woof2 with gFTP enhancements (amongst others) is being used to build.
Guys have not abandoned testing. I am with you in spirit if not in software. :oops:
Looking forward to 5.3.3 8)

Posted: Tue 17 Jan 2012, 07:52
by mavrothal
01micko wrote: if you have any feature requests NOW is the time! Next will be beta and feature freeze.
Let the full udev handle devices!
That's what the kernel expects and does a pretty good job too.
You may be surprised how many device/hardware detection issues may go away.
There is a provision for udev in sysinit so should not brake anything, though it needs a new kernel config

Posted: Tue 17 Jan 2012, 08:32
by James C
Quick live pfix=ram hardware check on my PCLOS/Lucid/Slacko box. Everything working and correct on initial boot.

# report-video
VIDEO REPORT: Slacko Puppy, version 5.3.1.2

Chip description:
oem: NVIDIA
product: G98 Board - 5610002u Chip Rev

Driver used by Xorg:
nouveau

Video mode used by Xorg:
Resolution: "1440x900" Depth: Depth 24

...the above also recorded in /tmp/report-video


-Computer-
Processor : Intel(R) Celeron(R) CPU 2.80GHz
Memory : 1033MB (178MB used)
Operating System : Unknown distribution
User Name : root (root)
Date/Time : Tue 17 Jan 2012 02:27:41 AM CST
-Display-
Resolution : 1440x900 pixels
OpenGL Renderer : Unknown
X11 Vendor : The X.Org Foundation
-Multimedia-
Audio Adapter : CMI8738-MC6 - C-Media CMI8738
Audio Adapter : ICH4 - Intel ICH5

Multimedia audio controller : Intel Corporation 82801EB/ER
FireWire (IEEE 1394) : Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller
Ethernet controller : ADMtek NC100 Network Everywhere Fast Ethernet 10/100
Multimedia audio controller : C-Media Electronics Inc CM8738
VGA compatible controller : nVidia Corporation G98 [GeForce 8400 GS]

Everything basically appears to be working correctly.

Posted: Tue 17 Jan 2012, 08:55
by peebee
01micko wrote:ALL b43 users, I need kernel logs from a pfix=ram before you load up b43!

I have PMed rerwin and if he decides to help he will likely need those. (maybe other logs too, TBA)

TIA
OOOOpps - meant 5312 of course....

Hi Mick

Here is the /var/log/messages with added .gz from a pristine manual frugal install of 5312 with no savefile - is this what you wanted?

Also /tmp/bootkernel.log and /tmp/bootsysinit.log (couldn't find pupsysinfo in 5312...)

My wifi is BCM4311 14e4:4312 btw.

From Karl's post I've also attached the modules.alias files from:
Slacko5.3.1
Slacko5.3.1.2
Lupu5.2.8-k3.1.8

(Karl - editing rc.local is quicker than using bootmanager and seems to work and explicitly shows whats missing that's all)

Cheers
peebee

Posted: Tue 17 Jan 2012, 10:01
by maxerro
Mick, may I ask who built the 2.6.37.6 for s530-main?

Re: Slacko 5.3.2-alpha2 ..testing

Posted: Tue 17 Jan 2012, 10:22
by wuxiandianzi
01micko wrote:Slacko .. goes on..
ALL b43 (broadcom wireless)
Hi,01micko:
Thank you for this new release. I want to tell you that k3.1.9 is better than k3.1.8, and b43 modules should be loaded autoly. peebee have told me that k3.1.9 can not find b43 module.But k3.1.8 can, I think this is not have something with kernel configure. I find that B43 firmware has been compressed and when boot it will be decompressed. I think it is not good way to dio this,I ut B43 firmware into /lib/firmware/ directly not tarball. And this can be auto detected by udevd I think.
Kernel configure nearly the same. I think your config is better than mine

It may give you some help,Just my personal opinion.

Posted: Tue 17 Jan 2012, 10:37
by 01micko
This is an extract from rerwin's reply:
rerwin wrote:One thing I saw in reviewing the drivers thread is a conflict between b43 and ssb, which I am proposing to handle with a new preference, "ssb:b43". Since I cannot see what is happening in the cases you cite, I don't know whether that preference is related or not. Another issue in that thread suggests a timing factor, in that the troubleshooting advice was to unload and reload b43 a little later in the initialization sequence -- not sure whether that is still considered effective.

We might make more sense of it all with a little data to work from. Could you obtain from both the lupu variant and your failing puppy the files, /tmp/udevtrace.log, /var/log/messages and /lib/modules/.../modules.alias? And also the hardware ID of the device in question and the output from lsmod.

Before even doing that, could you tell me more about what is happening with the broadcom driver? Does b43 simply get ignored, or is another module loaded in its place? I am trying to determine whether it would be something for tempestuous to examine or for Barry.
Thanks peebee, but if what wuxiandianzi says is true I think we are a step closer. Actually /lib/modules/all-firmware/b43/lib/firmware is empty!!! (WRONG sorry, it's in /lib/firmware/b43),

wuxiandianzi, all firmware is decompressed. No need of compression as the xz compression of the main sfs takes care of it. This was introduced in woof about 3 months ago.

-

maxerro, answer is me.

re

Posted: Tue 17 Jan 2012, 10:48
by wuxiandianzi
at least I download newest B43 firmware into /lib/firmware/ and it is sucess to load B43 at boot.

Re: re

Posted: Tue 17 Jan 2012, 10:54
by 01micko
wuxiandianzi wrote:at least I download newest B43 firmware into /lib/firmware/ and it is sucess to load B43 at boot.
firmware is already there

Posted: Tue 17 Jan 2012, 11:29
by maxerro
01micko wrote:maxerro, answer is me.
yeah, the point is you got the build options right.
it was virtually unbreakable on 99% of machines (even pre-2004-ones), unlike 3.x.x attempts.

Posted: Tue 17 Jan 2012, 11:37
by 01micko
maxerro, I'll keep support for k2.6.37.6 as the "RETRO" instead of "MAIN" verion, and drop the scsi tag, that was a boo boo!