Puppy 4.3 Final -- bug reports and suggestions

[Lobster]

Yesterday connected a friends Dell to his new modem router by wireless
That is lap dog one
Lap dog 2 is my Dell Inspiron 3500 pentium II
also connected wirelessly without too much trouble

Thanks to Tempestuous and others who work tirelessly for
us Wi-fi enabled Puppys.
.
Thanks Guys

[kjoe]

Hello,
This is a bug reminder with regard to the next release but also a request to anybody who can help me fix the bug causing remasterpup2 script to stop in Puppy 4.30, which I've described here

Thanks

kjoe

Edited Oct 10, 2009: Barry K. has just announced in his blog that he has found the bug that caused the Remaster CD script to crash if there are two optical drives. So this will be fixed in the 4.31 release. Thank you Barry!

kjoe

[Ledster]

First of all - a great guide to building puppy with woof from Iguleder!
Ran through it using puppy 4.3 (2.6.30.5 kernel) and built one with the 2.6.29.6
kernel, and it worked first time.
Now for why I did it. I have an Acer Aspire One on which I run upup alpha 9 from a usb stick
and it works fine. Had to put pciehp:pciehp_force=1 into the addlist section of
/etc/rc.d/modulesconfig to make the sd card slots work, and I can now boot up and
insert cards as and when required. Try the same with puppy 4.3 and the card(s)
must be in the slot(s) whenever I boot or they are not recognised (once booted you
can take them out and put them in at any time). So I wondered if this was anything
to do with the kernel version and built puppy with the same version as upup
(almost! 2.6.29.6 instead of upup's 2.6.29.4).
Made no difference.
So my question is, what difference is there between upup and puppy 4.x causing this?
If it is a simple config change I could probably cope (I am fairly new to linux, though).
It's one of those really annoying little things that I would love to fix.
Anyone any ideas?

Ledster

[gersen]

Can't get puppy 4.3 to recognise my usb joystick. Tried modprobe joydev which fixed it on lighthouse puppy, but doesn't work here.
Strange thing is games running under wine see the joystick just fine, but X-plane which runs natively cant see it.
Running jstest /dev/input/js0 just returns "no such device"
The system is seeing it though, unplugging and replugging the joystick gives me this in /var/log :

Oct 8 22:39:19 (none) user.info kernel: usb 2-6.3: new full speed USB device using ehci_hcd and address 7
Oct 8 22:39:19 (none) user.info kernel: usb 2-6.3: configuration #1 chosen from 1 choice
Oct 8 22:39:19 (none) user.info kernel: input: Saitek Saitek X52 Flight Control System as /devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6.3/2-6.3:1.0/input/input8
Oct 8 22:39:19 (none) user.info kernel: generic-usb 0003:06A3:075C.0005: input: USB HID v1.11 Joystick [Saitek Saitek X52 Flight Control System] on usb-0000:00:1d.7-6.3/input0

Is this a bug or am I missing something, advice appreciated ?

Regards

[rerwin]

Puppy 4.3's expanded dialup and wireless modem coverage may generate many requests for assistance for particular cases. Rather than repeat the various instructions to send several files, compressed into a tarball (which is all a mystery to n00bs) I have created a script to collect everything I can think of that I might need to understand their situations.

This tool requires a small modification to PupScan, to run it "silently" to create the PCI and USB hardware-and-driver files and exit without presenting the dialog. Here are the differences in the pupscan script:

Code: Select all

6a7
> #v431 rerwin: Add --silent option to only generate files, without display.
7a9
> [ "`echo $@ | grep ' *--silent *'`" != "" ] && SILENT=true || SILENT=false #v431
24c26
< [ ! -f /lib/modules/$KERNVER/modules.pcimap ] && load_zdrv #func in functions4puppy4
---
> #[ ! -f /lib/modules/$KERNVER/modules.pcimap ] && load_zdrv #func in functions4puppy4
272c274
< RETSTRING="`echo "$MAINDIALOG" | gtkdialog2 --stdin`"
---
> [ $SILENT != true ] && RETSTRING="`echo "$MAINDIALOG" | gtkdialog2 --stdin`" #v431

Barry, please accept the updated pupscan for 4.3.1, but the utility, pmodemdiag, could merely be added to the repository for user download as needed. (Or maybe it belongs somewhere else.) The dotpet places the script in the home (/root) directory, similar to where scanModem would go. It is intended to be run from a console, so the user gets feedback, but I find that clicking its icon also runs the tool silently; the user has to know where the tarball ends up (/root).

The instruction to a user would be to install the dotpet, in a console type:
./pmodemdiag
and attach the tarball to a posting or PM to the helper.

BTW: The saved version of the wvdial.conf file has the usernames, passwords, and PIN codes replaced by "X"es, to protect privacy.

UPDATE 10/13/09: Changed version to more standard format and added collection of a pgprs-option file, for comparison to what wvdial produces. Added prevention of overwriting an earlier tarball with same name as new one. (This would be "-3" under the old versioning numbers.)
Richard

[panzerpuppy]

@gersen: try 'modprobe joydev' AND 'modprobe analog'

[zygo]

Running the full iso on a live cd - 2GB RAM, no hdd.

I remastered but the new cd did not have my rox preferences. I selected to include customisations for that pc when given the choice by the script.

[gersen]

panzerpuppy, thanks for the advice, didn't help unfortunately.

I've had some luck though, as a long shot I grabbed some old usb joysticks I had and what do you know they all worked with just joydev loaded:

Logitech Extreme 3d Pro, Saitek ST290 and even a Thrustmaster joypad.

Now I have to figure out why the Saitek X52 doesn't. Its the device I use all the time on X-plane.

Regards.

Edit
Just googled for X52 + kernel 2.6.30, turns out there's a bug in 2.6.30 which prevents recognition of the X52.

joydev: blacklist digitizers avoids recognition of Saitek X52
This bug is related to a bad commit to joydev which now blacklists x52
joysticks.(d07a9cba6be5c0e947afc1014b5a62182a86f1f1)

Guess I'll have to wait on next kernel

[rerwin]

I successfully compiled and tested the latest Lucent (kernel-resident) modem driver, but withheld it because it supports the same hardware IDs as the "user-space" Lucent-Agere driver, dev_martian. However, for cases where the martian_dev driver fails to support a Lucent modem, ltmodem could be a fallback. I attach separate dotpets for the firmware update and for the driver itself.

I feel that the firmware update should be included in the bugfix, since the existing firmware would not work with the now-current (ltmodem) driver. The device name has changed to ttySV0 and the old ltserial module no longer exists, necessitating changes to the firmware and files firmware.dep.2.6.30.6, MODULESCONFIG, and 60-dialup-modem.rules. (See the pinstall.sh script.)

I also feel that the driver should NOT be included in Puppy 4.3.1, but should be added to the repository, for users to install as a "last resort" to getting a Lucent/Agere modem working.
Richard

NOTE: As it stands, the firmware dotpet retains the old blacklisting of ltserial-now-ltmodem. That was done to allow the preferred driver, martian_dev, to be loaded, since both drivers were present in Puppy. This is appropriate if Barry were to include ltmodem in 4.3. But for users installing the dotpet, they also must un-blacklist ltmodem in BootManager, as well as then "probe-Erasing" the ttySM0 device selection (in PupDial) and rebooting. If Barry leaves the driver dotpet for the user to install from the repository, I would suggest that the blacklisting be removed (from MODULESCONFIG). That way, the driver dotpet would "just work" when installed.

UPDATE 10/10/09: I have now attached a better version of the firmware update (-2) that eliminates the need to un-blacklist the driver. This is consistent with my recommendation to provide the driver only as a downloadable package and to not build the driver into the Puppy distros.
Richard

[technosaurus]

I have set up an issue tracker on google code for versions 4.4+ and am looking for some volunteers who follows this thread and the bugs forum in general to enter issues into the tracker. (also has project hosting if you are working on any puppy projects or if you would like to be a package maintainer for your favorite programs and keep them up to date)

[EZ4arabs]

I successfully compiled and tested the latest Lucent (kernel-resident) modem driver........
Richard

Thank you Sir.

[puttingau]

When you added a word in the spell check in previous versions, that word would be OK in the spell check when the document was next opened. This is not happening in 4.3.
The file that held the added words in 4.2 was /root/.config/enchant/.en_AU.dic (or en_US.dic). Does any one know what file is applicable (if any) in puppy 4.3?

[rerwin]

Regarding he Lucent driver: EZ4arabs reports too me that his Thinkpad R22 with that driver finds the Lucent modem as ttyS4! That is interesting news and is probably related to the new standard driver, martian_dev's, inability to support it correctly. This is a new development, to me. My Lucent PCI modem gets ttySV0, which is what I expect from what I have read. So, be prepared for this surprise, if you need the driver.
Richard

Further thoughts about this development: My guess is that the Lucent driver refused to support EZ4arabs' modem, but blocked martian_dev from loading. Probing in pupdial then finds the serial modem. I would think we would get the same effect by leaving out the Lucent driver and blacklisting martian_dev (in BootManager). If that works, I can probably make a rule to disable martian_dev for this particular modem.

EZ4arabs, could you test this idea? Simply boot a fresh puppy (pfix=ram), Go into BootManager and blacklist martian_dev, "probe-ERASE" in pupdial, reboot. I would expect no modem to be detected. Then probe for the modem in pupdial. If this works, it will lead to an elegant solution to your problem. Thanks.
Richard

[zygo]

rerwin,

Running the full iso (pup-430.iso) on a live cd - 256MB RAM, no hdd.

Thanks, your modem compilations work fine with my pci conexant modem - vendor: 14f1 device: 2f00 using module hsfpcibasic2. Wvdial reports connection at impossibly fast speeds but it actually connects at the same speed as my 3com external - c.40kb/s.

I'm trying to remaster a slimmer iso. What's the minimum I would need from zp430305.sfs for my modem?

[rerwin]

zygo,
I am in a rush now, but this should be all you need:
/lib/modules/2.6.30.5/hsfmodem/
/lib/modules/all-firmware/hsfmodem.tar.gz
Richard

[gyro]

I may have found why pup-430 wastes some of my loop devices.
Here is my BOOTCONFIG:

Code: Select all

EXTRASFSLIST='my-apps-sfs4.sfs devx_430.sfs wx_cb-sfs4.sfs'
PREVUNIONRECORD='pupsave.2fs pup-430.sfs devx_430.sfs my-apps-sfs4.sfs my-apps.sfs wx_cb-sfs4.sfs wx_cb.sfs zp430305.sfs'
LASTUNIONRECORD='pupsave.2fs pup-430.sfs devx_430.sfs my-apps-sfs4.sfs my-apps.sfs wx_cb-sfs4.sfs wx_cb.sfs zp430305.sfs'

EXTRASFSLIST is correct. PREVUNIONRECORD and LASTUNIONRECORD look wrong since they include "my-apps.sfs" and "wx_cb.sfs", both of which are squashfs version 3, for use by puppy412 and puppy421.
They are also in /initrd/tmp/EXTRASFSS:

Code: Select all

/mnt/dev_save/devx_430.sfs
/mnt/dev_save/my-apps-sfs4.sfs
/mnt/dev_save/my-apps.sfs
/mnt/dev_save/wx_cb-sfs4.sfs
/mnt/dev_save/wx_cb.sfs

I suspect that pup-430 is attempting to mount these as loop devices, when this fails the loop devices remain attached to these files.

gyro

[EZ4arabs]

EZ4arabs, could you test this idea? Simply boot a fresh puppy (pfix=ram), Go into BootManager and blacklist martian_dev, "probe-ERASE" in pupdial, reboot. I would expect no modem to be detected. Then probe for the modem in pupdial. If this works, it will lead to an elegant solution to your problem. Thanks.
Richard

I had the same idea yesterday before reading your request and when I saw the result I was going to post it here but I said to myself rerwin will definitely" say what are you doing man,stop wasting my time? there is something wrong with your modem or you did something wrong."
here is what pupdial found:

Scanning your serial ports for a modem.

Port Scan<*1>: Scanning ttySV0 first, /dev/modem is a link to it.
ttySV0<*1>: ATQ0 V1 E1 -- OK
ttySV0<*1>: ATQ0 V1 E1 Z -- OK
ttySV0<*1>: ATQ0 V1 E1 S0=0 -- OK
ttySV0<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK
ttySV0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK
ttySV0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK
ttySV0<*1>: Modem Identifier: ATI -- LT V.92 Data+Fax Modem Version 8.30
ttySV0<*1>: Speed 4800: AT -- OK
ttySV0<*1>: Speed 9600: AT -- OK
ttySV0<*1>: Speed 19200: AT -- OK
ttySV0<*1>: Speed 38400: AT -- OK
ttySV0<*1>: Speed 57600: AT -- OK
ttySV0<*1>: Speed 115200: AT -- OK
ttySV0<*1>: Speed 230400: AT -- OK
ttySV0<*1>: Speed 460800: AT -- OK
ttySV0<*1>: Max speed is 460800; that should be safe.
ttySV0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK

Found a modem on /dev/ttySV0, using link /dev/modem in config.
Modem configuration written to /etc/wvdial.conf.

my reaction was
wait.....to add more confusion to an already confused newbie here is what dmesg reports:

ltmodem: module license 'mixed' taints kernel.
Disabling lock debugging due to kernel taint
ltmodem loaded
ungrab-serial: detaching 11c1:45c from serial
serial 0000:00:03.1: PCI INT A disabled
e100: eth0: e100_probe: addr 0xfc020000, irq 11, MAC addr 00:03:47:90:27:51
ltmodem 0000:00:03.1: PCI INT A -> Link[LNKC] -> GSI 11 (level, low) -> IRQ 11
IRQ 11/ltmodem: IRQF_DISABLED is not guaranteed on shared IRQs
martian: core vars:
martian: s_x82 = 8086
martian: s_x84 = 2205
martian: s_x86 = 45c
s_x88 = 11c1
martian: x_dsp_mars = 0
martian: x_dsp_mars3 = 3
martian: BaseAddress = 6272
martian: ComAddress = 0
martian: Irq = 11
martian: S[0x7e] = 160
ttySV0 at I/O 0xf0000000 (irq = 0) is a VUART
martian: added device 11c1:45c BaseAddress = 0x1880, CommAddres = 0x0, irq = 11

I did blacklist martian and what you compiled was ltmodem so what martian core vars is doing there and does [VUART) stands for virtual uart?
it would be interesting to see what will happen if it was tried by Diamond in this thread:
http://www.murga-linux.com/puppy/viewto ... 80&t=46613

Thank you Sir for your time and help.

[gyro]

Problem is with the line of code at around line 1223 of "init" in "initrd.gz". The line

Code: Select all

    [ "`echo "$EXTRASFSLIST" | grep "$ONEBASE"`" != "" ] && echo "${ONEEXTRA}" >> /tmp/EXTRASFSS

finds file names that contain ONEBASE as a substring, as well as the one that is identical. This is a problem when you have two files with names like "xxxx.sfs" and "xxxx-sfs4.sfs". grep matches "xxxx.sfs" to the leading "xxxx-sfs" in "xxxx-sfs4.sfs", so "xxxx.sfs" gets written to "/tmp/EXTRASFSS" when it should not be.
The simple solution is to change the line to

Code: Select all

    [ "`echo "$EXTRASFSLIST" | grep -w "$ONEBASE"`" != "" ] && echo "${ONEEXTRA}" >> /tmp/EXTRASFSS

But this still results in the sfs files being mounted in the order of the "ls -1 $SFSSDIR/*.sfs" command rather than the order specified in EXTRASFSLIST. So my suggested fix is to replace

Code: Select all

   ls -1 $SFSSDIR/*.sfs |
   while read ONEEXTRA
   do
    ONEBASE="`basename $ONEEXTRA`"
    exPATTERN="^z|^pup_" #w478
    [ "`echo "$ONEBASE" | grep -E "$exPATTERN"`" != "" ] && continue
    [ "`echo "$EXTRASFSLIST" | grep "$ONEBASE"`" != "" ] && echo "${ONEEXTRA}" >> /tmp/EXTRASFSS
   done

with

Code: Select all

#gyro
   for ONEEXTRA in $EXTRASFSLIST
   do
    [ -f "$SFSSDIR/$ONEEXTRA" ] && echo "$SFSSDIR/$ONEEXTRA" >> /tmp/EXTRASFSS
#gyro
   done

gyro

[prehistoric]

Thanks for the advice on how to clean my mouse. Unfortunately that doesn't apply to my situation. The Dell Inspiron 8200 is a laptop - one of the older laptops that offer both a touchpad and and eraser-style pointer. Just for grins I did pull out a ps/2 external mouse, but that doesn't make any difference. The pointer still disappears every few minutes....

@hiveman,
I don't think this problem has any connection to mouse or touchpad. It sounds like the "invisible cursor" problem I've seen on a number of machines with shared video ram. The fix for that is to edit xorg.conf and uncomment the option for software cursor. I've been campaigning for a simple check box in xorgwizard, and some text to describe the problem, for some time. It doesn't always show up, even on the same model of machine, because it depends on the size and speed of the shared memory.

[prehistoric]

Like some other people with the EeePC I have also had problems with the audio mixer shown in the jwm tray on my ASUS EeePC 900A. I haven't described it before, because we were still dealing with more serious things, like fan control and possibly burning processors. I'll wait until 4.3.1 stabilizes before tackling this specialized problem.

The Xandros system which came installed is really slow, but it does have exactly the right mixer, with controls for both volume and microphone. The sound quality when using Skype and a headset with microphone is excellent. Under 4.3 I've never gotten the microphone adjusted properly, even after following posted advice about using alsamixer. If we could use that mixer supplied with the machine I would be happy. Anyone know how it works? I'm not familiar with Xandros, and ASUS has hidden a number of proprietary things on the EeePC.