Puppy Dingo 392 testing, bug reporting

Please post any bugs you have found
Message
Author
User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#106 Post by BarryK »

veronicathecow wrote:Hi tempestuous, thanks for tip, sadly however so little works on this new board with Puppy and as I suffer with RSI I have had to stick to PCLinux which seems to make it all work (Apart from having to use the Xvesa)
I will probably try again in 6 months.
Cheers
I am going to experiment with Dingo and the 2.6.24 kernel -- as soon as it is released -- it's currently at 2.6.24.rc4.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

Re: probepart

#107 Post by BarryK »

raffy wrote:Here's the result of probepart on Compaq Presario PC (with SATA, firewire):

Code: Select all

# probepart
/dev/sda1|vfat|10506446
/dev/sda2|ntfs|144793844
/dev/sda3|swap|1060290
/dev/sdg1|none|511968
/dev/sdh1|none|1003486
/dev/sdb|none|0
/dev/sdc|none|0
/dev/sdd|none|0
/dev/sde|none|0
/dev/sdf|none|0
/dev/hdc|iso9660|0
Things of note:
- the capacities displayed are 2x the actual capacities (ie, sdg1 is actually a 256-MB USB drive).
- I cannot do a manual mount of partitions g1 and h1.
The sizes are in 512 byte blocks. You need the '-k' and '-m' parameters for KB and MB units.

So what are the filesystems of sdg1 and sdh1 actually?

The filesystem type of the the partitions is determined by a utility application written by Jesse, the same as he uses in MUT. So, if probepart returns a f.s. type of "none", so to will MUT.
The utility is '/usr/lib/mut/bin/guess_fstype' and although I don't have MUT in Dingo, I have retained this utility, as PET package 'guess_fs-29dec2007'. Ditto, probepart in Puppy 3.01 also uses guess_fstype.

My guess is that if you do have some filesystems in those partitions, it is either not a fat/ntfs or normal Linux partition (ext2, ext3, reiserfs), or is somehow misconfigured.
You might want to check with 'guess_fstype' directly. I can't recall exactly, but I think that probepart has some screening and will return 'none' for any f.s.'s that cannot be mounted by Puppy.
[url]https://bkhome.org/news/[/url]

raffy
Posts: 4798
Joined: Wed 25 May 2005, 12:20
Location: Manila

fstype

#108 Post by raffy »

The fstype is VFAT in USB, and the USB drives are working very reliably, and are being used to boot Puppy in other machines.

There must be some distinction here. MUT can mount these USB partitions even if probepart cant see them; please refer to the 2.13 info above. MUT has a lot of your own changes, too, so surely one or a few line/s in there could help solve this problem.

User avatar
HairyWill
Posts: 2928
Joined: Fri 26 May 2006, 23:29
Location: Southampton, UK

#109 Post by HairyWill »

Béèm wrote:My laptop with ipw2100 wireless interface does see my access point, but I need WEP to connect to it and obtain an IP.
Altho I give the correct WEP key a live network isn't found.
(same for Pwireless scanner)

I find also unprotected access points.
I can obtain an IP of one of these and connect to the internet.

So it looks like a WEP issue.
Beem I'm confused, you said here
http://www.murga-linux.com/puppy/viewto ... 498#157498
that it was working properly.

I have compared the zdrv file from 3.01 with 3.92 and noticed things missing from 3.92 that might be important specifically
zdrv-301/lib/modules/2.6.21.7/kernel/net/ieee80211/ieee80211_crypt_ccmp.ko
zdrv-301/lib/modules/2.6.21.7/kernel/net/ieee80211/ieee80211_crypt_tkip.ko
zdrv-301/lib/modules/2.6.21.7/kernel/net/ieee80211/ieee80211_crypt_wep.ko

this might be the reason why modprobe ieee80211_crypt_wep fails


I'm not sure if it is relevant but 3.01 loads a module
00:1f.3 0C0500 8086:2483 <i801_smbus>
this is not loaded in 3.01

Any ideas anyone?
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

Re: fstype

#110 Post by BarryK »

raffy wrote:The fstype is VFAT in USB, and the USB drives are working very reliably, and are being used to boot Puppy in other machines.

There must be some distinction here. MUT can mount these USB partitions even if probepart cant see them; please refer to the 2.13 info above. MUT has a lot of your own changes, too, so surely one or a few line/s in there could help solve this problem.
raffy, can you please test guess_fstype:
# /usr/lib/mut/bin/guess_fstype /dev/sdg1
# /usr/lib/mut/bin/guess_fstype /dev/sdh1
and let me know what it returns.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#111 Post by BarryK »

HairyWill wrote:
Béèm wrote:My laptop with ipw2100 wireless interface does see my access point, but I need WEP to connect to it and obtain an IP.
Altho I give the correct WEP key a live network isn't found.
(same for Pwireless scanner)

I find also unprotected access points.
I can obtain an IP of one of these and connect to the internet.

So it looks like a WEP issue.
Beem I'm confused, you said here
http://www.murga-linux.com/puppy/viewto ... 498#157498
that it was working properly.

I have compared the zdrv file from 3.01 with 3.92 and noticed things missing from 3.92 that might be important specifically
zdrv-301/lib/modules/2.6.21.7/kernel/net/ieee80211/ieee80211_crypt_ccmp.ko
zdrv-301/lib/modules/2.6.21.7/kernel/net/ieee80211/ieee80211_crypt_tkip.ko
zdrv-301/lib/modules/2.6.21.7/kernel/net/ieee80211/ieee80211_crypt_wep.ko

this might be the reason why modprobe ieee80211_crypt_wep fails


I'm not sure if it is relevant but 3.01 loads a module
00:1f.3 0C0500 8086:2483 <i801_smbus>
this is not loaded in 3.01

Any ideas anyone?
The fault is that Dingo alpha1 and alpha2 have a cutdown zrdv file, which has been cutdown a bit too much. All of kernel/net/ieee80211 directory is missing. I've fixed that, for alpha3.

I also screened out too much from the sound modules. I had removed all the oss and alsa-isa modules, but that is probably going to far. My thinking is that Puppy should only be supporting computers with a PCI but, not any pre-PCI computers, but maybe that is too harsh. So, I have restored all the alsa ISA-bus modules, but have still left out the old oss modules.
[url]https://bkhome.org/news/[/url]

User avatar
Béèm
Posts: 11763
Joined: Wed 22 Nov 2006, 00:47
Location: Brussels IBM Thinkpad R40, 256MB, 20GB, WiFi ipw2100. Frugal Lin'N'Win

#112 Post by Béèm »

@HairyWill,
When I wrote that post you referenced the issue was about 3.90, which works ok with WEP.
When I tried 3.92 I had the problem with WEP, but can connect to unprotected access points.
Also when the issue is about 3.01 I say the my connection works with WEP.
So when I answer a post it's always considering the given context.

Well seeing the post of Barry, I'll wait the alpha 3 then.
Time savers:
Find packages in a snap and install using Puppy Package Manager (Menu).
[url=http://puppylinux.org/wikka/HomePage]Consult Wikka[/url]
Use peppyy's [url=http://wellminded.com/puppy/pupsearch.html]puppysearch[/url]

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#113 Post by PaulBx1 »

Barry, I wonder why zdrv should be cut down at all? I thought the whole point of zdrv was to separate it from the part of Puppy that's loaded into memory, thus allowing it to fill up with all sorts of drivers and better support the hardware (while not consuming memory or affecting performance). In other words, it was supposed to balloon out.

The only drawback I can see is downloading time on a big file.

Perhaps you can have 2 zdrv files, one for more common hardware and an extra one for old ISA stuff, oddball drivers and whatnot. That way those stuck with old hardware still can get their drivers, or if too much is inadvertently cut out of the first zdrv, it's still available in the second. In fact it makes it easier for you to get aggressive cutting stuff out of the first because it's not a disaster if you go too far with that.

nic2109
Posts: 405
Joined: Mon 01 Jan 2007, 20:24
Location: Hayslope, near Middlemarch, Midlands, England

#114 Post by nic2109 »

BarryK wrote:
I also screened out too much from the sound modules. I had removed all the oss and alsa-isa modules, but that is probably going to far. My thinking is that Puppy should only be supporting computers with a PCI but, not any pre-PCI computers, but maybe that is too harsh. So, I have restored all the alsa ISA-bus modules, but have still left out the old oss modules.
Will this get hda-intel devices working in Puppy? Looking in the Forum for help these seem particularly troublesome - it's never really worked for me, hence the Forum searching!

By way of comparison ubuntu produces sound to knock your socks off from the same PC, so I had a grep around in the output from modprobe on both. Dingo returns :-

Code: Select all

/lib/modules/2.6.21.7/kernel/sound/pci/hda/snd-hda-intel.ko
and ububtu 6.06 returns this :

Code: Select all

/lib/modules/2.6.15-29-386/kernel/sound/pci/hda/snd-hda-intel.ko
/lib/modules/2.6.15-29-386/kernel/sound/pci/hda/snd-hda-codec.ko
Is the absence of the codec in Dingo (and Puppy 3.01) significant?

raffy
Posts: 4798
Joined: Wed 25 May 2005, 12:20
Location: Manila

guess_fstype

#115 Post by raffy »

can you please test guess_fstype
Result: unknown

2.13 MUT's guess_fstype in /usr/lib/mut/bin produces the same result: unknown. But for some reason, MUT sees it in the GUI.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#116 Post by BarryK »

PaulBx1 wrote:Barry, I wonder why zdrv should be cut down at all? I thought the whole point of zdrv was to separate it from the part of Puppy that's loaded into memory, thus allowing it to fill up with all sorts of drivers and better support the hardware (while not consuming memory or affecting performance). In other words, it was supposed to balloon out.

The only drawback I can see is downloading time on a big file.

Perhaps you can have 2 zdrv files, one for more common hardware and an extra one for old ISA stuff, oddball drivers and whatnot. That way those stuck with old hardware still can get their drivers, or if too much is inadvertently cut out of the first zdrv, it's still available in the second. In fact it makes it easier for you to get aggressive cutting stuff out of the first because it's not a disaster if you go too far with that.
There's a lot of modules in the full zdrv that are very unlikely to be needed, and I'm aiming for Puppy to meet the needs of 99% of users. That extra 1% will be able to obtain the full zdrv file.
[url]https://bkhome.org/news/[/url]

jonyo

#117 Post by jonyo »

BarryK wrote:[and I'm aiming for Puppy to meet the needs of 99% of users.
Good to hear. :)

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#118 Post by BarryK »

nic2109 wrote:
BarryK wrote:
I also screened out too much from the sound modules. I had removed all the oss and alsa-isa modules, but that is probably going to far. My thinking is that Puppy should only be supporting computers with a PCI but, not any pre-PCI computers, but maybe that is too harsh. So, I have restored all the alsa ISA-bus modules, but have still left out the old oss modules.
Will this get hda-intel devices working in Puppy? Looking in the Forum for help these seem particularly troublesome - it's never really worked for me, hence the Forum searching!

By way of comparison ubuntu produces sound to knock your socks off from the same PC, so I had a grep around in the output from modprobe on both. Dingo returns :-

Code: Select all

/lib/modules/2.6.21.7/kernel/sound/pci/hda/snd-hda-intel.ko
and ububtu 6.06 returns this :

Code: Select all

/lib/modules/2.6.15-29-386/kernel/sound/pci/hda/snd-hda-intel.ko
/lib/modules/2.6.15-29-386/kernel/sound/pci/hda/snd-hda-codec.ko
Is the absence of the codec in Dingo (and Puppy 3.01) significant?
ALSA, as used in Puppy, does not have the snd-hda-codec.ko module. So, I have no idea what it is.

My laptop uses snd-hda-intel.ko and it works. Prior to Puppy3 it did not work, so the upgrade of ALSA fixed it. Dingo will be having another upgrade of ALSA soon.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

Re: guess_fstype

#119 Post by BarryK »

raffy wrote:
can you please test guess_fstype
Result: unknown

2.13 MUT's guess_fstype in /usr/lib/mut/bin produces the same result: unknown. But for some reason, MUT sees it in the GUI.
Ok, we have something weird. Do you have an email address for Jesse? -- I don't think he has been to the forum for awhile. We could tell him about this problem with guess_fstype and can he please fix it. But, I wonder what he did in MUT? -- he must have some fallback method of determining the f.s.

Well, how about this:
# fdisk -l
...could you try this, let me know if this reports correct f.s.
If this reports the correct f.s. then no need to contact Jesse, I can use that as fallback in pmount.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#120 Post by BarryK »

raffy, while you're at it, do this too:
# disktype /dev/sdg1

I'm reluctant to use 'disktype' as a fallback, as it does a complete probe which is slow. But, I guess if we only do it when guess_fstype returns 'unknown' then it's not too bad.
[url]https://bkhome.org/news/[/url]

nic2109
Posts: 405
Joined: Mon 01 Jan 2007, 20:24
Location: Hayslope, near Middlemarch, Midlands, England

#121 Post by nic2109 »

BarryK wrote:ALSA, as used in Puppy, does not have the snd-hda-codec.ko module. So, I have no idea what it is.

My laptop uses snd-hda-intel.ko and it works. Prior to Puppy3 it did not work, so the upgrade of ALSA fixed it. Dingo will be having another upgrade of ALSA soon.
Ubuntu is using ALSA too, so maybe it's a seriously different different version - the kernel is quite a bit older. All I know is that the sound output is SO much better than Puppy's.

Puppy sort of "works", but is very muffled and indistinct. Speech synthesis is really distorted and approaching useless. Even the welcome woof-woof is really hard to hear on my modern laptop, just as it was on its predecessor an ancient desktop which also used snd-hda-intel. :(

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#122 Post by PaulBx1 »

Maybe try unloading snd-hda-intel on that system and see if it ends up sounding like Puppy? Just a thought...

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#123 Post by BarryK »

Yes, there were older versions of ALSA for which the snd_hda driver worked well, then there was a version upgrade and it stopped working on many systems. The developer fixed it and sound works again. Perhaps that '_codecs' driver is for that old ALSA version, from before the broken versions of ALSA.
Sound quality seems ok on my laptop -- but then it's really tinny anyway due to the pathetic little speakers.
[url]https://bkhome.org/news/[/url]

nic2109
Posts: 405
Joined: Mon 01 Jan 2007, 20:24
Location: Hayslope, near Middlemarch, Midlands, England

#124 Post by nic2109 »

BarryK wrote:Perhaps that '_codecs' driver is for that old ALSA version, from before the broken versions of ALSA.
I've just looked at 2.14R and the _codec is present. The sound is OK too, though not everything I'd like. Hi-Fi it isn't, but it's a good deal better than Dingo's.

I'm not sure where this leaves us with Dingo, though. I guess as it "works" it's low priority for attention.

As ever, we'll run with what you give us.

raffy
Posts: 4798
Joined: Wed 25 May 2005, 12:20
Location: Manila

fdisk and disktype results

#125 Post by raffy »

Still on the subject of Compaq Presario PC with Firewire:

Code: Select all

# probedisk
/dev/sda|Direct-Access|ATA     SAMSUNG SP0812C 
/dev/sdb|Direct-Access|Brother DCP-110C        
/dev/sdc|Direct-Access|Generic USB SD Reader   
/dev/sdd|Direct-Access|Generic USB CF Reader   
/dev/sde|Direct-Access|Generic USB SM Reader   
/dev/sdf|Direct-Access|Generic USB MS Reader   
/dev/sdg|Direct-Access|JetFlashTS512MJFV30     
/dev/sdh|Direct-Access|USB 2.0 Flash Disk      
/dev/hdc|cdrom|HL-DT-ST DVDRAM GSA-H10N

# fdisk -l

Disk /dev/sda: 80.0 GB, 80060424192 bytes
255 heads, 63 sectors/track, 9733 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         654     5253223+   c  W95 FAT32 (LBA)
/dev/sda2   *         655        9667    72396922+   7  HPFS/NTFS
/dev/sda3            9668        9733      530145   82  Linux swap / Solaris
Disktype returns "Can't stat ... No such file or directory". But it works well on the SATA drives.
Puppy user since Oct 2004. Want FreeOffice? [url=http://puppylinux.info/topic/freeoffice-2012-sfs]Get the sfs (English only)[/url].

Post Reply