MUT2 buggy edition

[Jesse]

Hi nic2109 & Everitt,

Thanks for the logs, the reason that MUT2 is not showing a hardware list on Dingo, is that the background server is crashing.
From Everitts log:

1203141345.887: DEBUG: TH080F6830 read cmd stat
1203141345.887: DEBUG: TH080F6830 COMMANDS:for sdb
1203141345.887: ERROR: TH080F6830 received SIGSEGV handler
1203141345.887: ERROR: TH080F6830 Unable to free ptr 0X80F97F8 as its not in the list. lib/backtrace.c:64
1203141345.887: ERROR: TH080F6830 Signal 11, Backtrace: [0x8048225][0x8056b49][0x8056bd9][0xffffe420][0x80562e7][0x805662a][0x8056a85][0x804995e][0x804aa6f][0x80689ea][0x8048131]
1203141345.887: BEGINEND: TH080F6830

I quickly tried to use Dingo edition 395, but at boot time with pfix=ram it compained that it could not find pup_395.sfs.
I had a quick look at Dingo from its command line shell and it is certainly using the new /dev/sd nodes for IDE drives, so that is quite a restructure, this must be what is triggering the bug in MUT2.
Also the mut client is not realising that the server connection is being dropped at an inappropriate moment, so this is another bug too.
You guys are great bug spotters! I'll fix these issues up at some point soon, I'm off to watch the motorcycle racing in Paeroa today, there might be some time tonight when I get back to fix up the bugs you spotted.

Jesse

[Jesse]

I've posted some updates that I managed to get done this weekend.
Some tweaks to cd drive ioctl (commands) useage.
Added in swapon/swapoff.
http://www.murga-linux.com/puppy/viewtopic.php?t=26336

Has anyone out there that has an internal SD card (non-USB variety) found it accessible via MUT2? I don't have one to try with. MUT2 doesn't load the drivers for it at this stage, you'll have to do that manually.

Jesse

[Jesse]

Hi Wolf Pup,

Theres were a few cd-control command doubleups that weren't needed that I've removed in latest edition.
can you please check to see if audio pauses are fixed with mut2_1.0.0.1079?

Thanks,
Jesse

[JB4x4]

Jesse,

I tested your latest MUT (mut2_1.0.0.1079), and am happy to report the CD/DVD eject and close now work. One thing though, it seems to "double" the name of the drive (see pic below). The text runs over the ReScan button.

JB

[Jesse]

Hi JB,

That is odd.
Although theres a bit more data in the middle.

I figured it out. The revision ID is 8 bytes for your drive, and linux defines the revision right before the model.

struct hd_driveid {
...
unsigned char fw_rev[8]; /* 0 = not_specified */
unsigned char model[40]; /* 0 = not_specified */
...
}

And that way there is no nul string terminator to stop the string copy.
They probably did that so that all 8 bytes could be used for revision, and programs calling it, like mut, would be unlikely to crash with the apparently longer string.
I've fixed up mut, I'll post another revision in a day or so.
Jesse

[Sit Heel Speak]

Hi Jesse,

Hi Sit Heel Speak,...
..."./mut mutclient" ...
..."./mut mutclient --debug" ...
..."./mut mutclient --debug --foreground --nothreads --nofork"...

The latest (mut2_1.0.0.1079) is throwing these errors in
./mut mutclient --debug. sda is a vintage-1998 2GB Seagate SCSI drive through an old Adaptec 2940UW PCI adapter, allotted as just one reiserfs partition:

1203438987.998: DEBUG: THB5FC3B90 scan_drive_node: sda
1203438987.998: BEGINEND: THB5FC3B90 scan drives sda 8:0
1203438987.999: DEBUG: THB5FC3B90 ensure_dev_node_exists on /dev/sda 8 0
1203438987.999: ERROR: THB5FC3B90 failed to get drive info sda

About 600 lines further down, its last gasp is:

1203438988.244: VERBOSE: TH080F6830 got 1 socks need attention
1203438988.244: DEBUG: TH080F6830 read cmd stat
1203438988.244: DEBUG: TH080F6830 read: <hw_list>
1203438988.244: DEBUG: TH080F6830 reading a line
1203438988.244: ERROR: TH080F6830 received SIGSEGV handler
1203438988.244: ERROR: TH080F6830 Unable to free ptr 0X80FCD48 as its not in the list. lib/backtrace.c:64
1203438988.244: ERROR: TH080F6830 Signal 11, Backtrace: [0x8048225][0x8057191][0x8057221][0xffffe420][0x805692f][0x8056c72][0x8057084][0x80570ba][0x8055277][0x8048ab3][0x8049e6a][0x804aaa3][0x806901a][0x8048131]
1203438988.244: BEGINEND: TH080F6830
1203438988.254: DEBUG: TH080F6830 finished reading <hw_list>
1203438988.254: DEBUG: TH080F6830 hw ctx got.
1203438988.254: BEGINEND: TH080F6830
1203438988.254: ERROR: TH080F6830 DriveContext no pointer? meaning no drives?
1203438988.254: INFO: TH080F6830 main exit code:0
#

I can send you the entire debug output, if you or someone will clue me in on how to enlarge the xterm/rxvt scrollback buffer. Simply piping to debug.txt doesn't work, I copied-and-pasted from the scrollback. If memory serves, at the time I originally set this Puppy up I enlarged it, but have forgotten how...

HTH, SHS

[Sit Heel Speak]

I've noticed another quirk of Puppy 4's new treatment of hdxn partitions as sdxn: Sabayon Gentoo 1.1 PE, which also uses only sdxn, puts the SCSI drive at the top of the chain as sda. Dingo puts it at the bottom, on my system sdd. I don't know whether this is liable to get us into trouble or not.

(the above debug listing is from Puppy 2.17-1, wherein the scsi drive is sda)

[nic2109]

Hi Jesse,

Hi Sit Heel Speak,...
..."./mut mutclient" ...
..."./mut mutclient --debug" ...
..."./mut mutclient --debug --foreground --nothreads --nofork"...

Simply piping to debug.txt doesn't work,....

Hi; I found that this

Code: Select all

 ./mut mutclient > name.of.logfile 

worked for me. In other words use > rather than |.

Hope that helps.

[Jesse]

Hi SHS,

Thats interesting.
The crash you reported has only been reported on Dingo editions so far. But for you it is happening on 2.17-1.
The only thing that is common with your system and the Dingo editions (that I am aware of) is that there is a scsi disk present.
So perhaps the bug in mut2 is related to scsi disk processing.
Putting Puppy edition aside, the crash bug seems to always happen when processing a scsi disk.
I'm not sure how to test that right at the moment, I'll think about it a little while maybe it'll come to me.

Jesse

[Jesse]

Hello,

I've posted a new update. 1.0.0.1109
Some tweaks to cd drive ioctl (commands) useage.
gui window position is saved/restored
Cd disk size added.
Fix hard disk fw revision (JB4x4 bug)
http://www.murga-linux.com/puppy/viewtopic.php?t=26336

All the cdrom controls are finally all working on my PC, be sure to let me know if you have any quirks.

Jesse

[Jesse]

Hello,

Ahem! I don't know how kosher this is, but here is mut looking just like pmount (left), running next to pmount (right), all in Dingo alpha 6, running on another computer I have that usually only gets to play DVDs.
This is mut2_1.0.0.1130, minor hacked pmount included.
The Pmount script is different!! please don't install it over your existing Pmount script, unless you make a backup etc... You'll need to put the mut file next to it if you do install it.
This should save the issues of installing tcl/tk for those Dingo testers.

SCSI disks work with this edition of mut2.
Floppy disks are still rattling about with 1130.

Jesse

[mcewanw]

the mutclient frontend UI wiak idea rip

[Jesse]

Hi mcewanw,
Don't write off your idea already, pmount doesn't have eject buttons for the CDs, its doesn't have everything, neither does mut2s tcl/tk gui. If you check through the history of the two, there are elements of each that different people adore, perhaps there is a better soloution to gui out there that you can make happen?
Jesse

[Wolf Pup]

Hi Wolf Pup,

Theres were a few cd-control command doubleups that weren't needed that I've removed in latest edition.
can you please check to see if audio pauses are fixed with mut2_1.0.0.1079?

Thanks,
Jesse

mut2_1.0.0.1130 does not freeze up puppy anymore, but when play is clicked in MUT2, there is no music played.

[steevieb]

I was getting the same errors as SHS but latest MUT2 (1.0.0.1130) working with LHP215.
Rebooted with LHP301 and working as well, except sda,b,c,d are now sde,f,g,h. Minor problem, as this means the 3 series is now usable for me.
And Pmount is detecting all drives for the first time. These are scsi2/scsi3 drives.

LHP215
drive|0|0|sda|sda|8|0|0|0|disk|BB00911CA0|3B07|COMPAQ|sym53c8xx|scsi|scsi|||
LHP301
drive|0|0|sde|sde|8|64|0|0|disk|BB00911CA0|3B07|COMPAQ|sym53c8xx|scsi|scsi|||

[BarryK]

Ha, Ha, I like what you have done for the Dingo-pmount-mut!

Well, why don't we put a little switch-over button in Pmount, to choose between the default and mut underlying engines? That way, users can choose the one they like, and the choice should be remembered.
You can add more features to the Pmount-with-mut-engine GUI as you wish, without altering the default Pmount.

Probably best to leave the original 'pmount' script alone except put a little bit of code at the beginning to read the users prior choice of engine, and if they had selected mut, then jump to the 'pmount-mut' script.

Does that seem like a good idea?

Or, you could keep them as separate apps. I was just thinking that it would be convenient for the desktop 'mount' icon to have this switch-over capability.

[JB4x4]

Jesse,

Just reporting that the hard drive naming is fixed (not doubled anymore). Keep up the good work.

JB

[Jesse]

mut2_1.0.0.1130 does not freeze up puppy anymore, but when play is clicked in MUT2, there is no music played.

Ok, this could indicate a few different things.
Theres two ways to play cd audio, the application reads and decodes audio data, then sends it to the sound card, the other way is to send the drive comands and have the drive do all the work but this requires a direct connection to the sound card to get the sound out.
The cdaudio controls that mut uses, get the drive to play the audio out its audio cable, which needs to be connected to the sound card (or seperate speakers for external drives), so your sound card needs to have its volume controls set ok for cdaudio, use your sound mixer to check/set these things.
Theres one thing mut may well be not addressing that is causing your problem, the cdrom drive itself has a volume control, mut curently isn't setting or checking this value, if your drive as a default volume setting of zero, this could also cause the problem.
I think gxine reads audio data and sends that to sound card, but I might be mistaken on that, do you have an application that plays audio via drive commands, I think its called "CD Audio Player", is that able to play audio for you?

Jesse

[Jesse]

with LHP301 and working as well, except sda,b,c,d are now sde,f,g,h. Minor problem, as this means the 3 series is now usable for me.

Hi steevieb,
I'm glad some things are working for you. I'm not sure that I can change things about your drive letters changing though. From what I understand about the drive letter allocation, they are assigned in the order that the drives become available to the kernel, so when the drivers are loaded in a different order,other drives are registered first. What I think is happening is that you have something like a usb-chip reader with 4 physical ports (each assigned a scsi drive letter), such that for LHP301 the usb & usb-storage is loaded before your scsi kernel module drivers, and in LHP215 the module order is different which is reflected in the drive order change. Those driver loads happen at boot time, well before mut has a chance to do anything. You might try things like installing and running from a hard disk, or perhaps removing the usb-chip reader. I'm not sure what the best solution for you would be. The best solution will be a complicaed and technical, having puppy linux always load from boot disk all the scsi disk controller drivers before usb might work, and always in a particular order, but that isn't likely to suit all puppy users either. Possibly a boot system where anyone can easilly build their own boot disk (initrd.gz) with scsi/usb in a particular order, is the best solution.
Jesse

[Jesse]

Ha, Ha, I like what you have done for the Dingo-pmount-mut!

Well, why don't we put a little switch-over button in Pmount, to choose between the default and mut underlying engines? That way, users can choose the one they like, and the choice should be remembered.
You can add more features to the Pmount-with-mut-engine GUI as you wish, without altering the default Pmount.

Probably best to leave the original 'pmount' script alone except put a little bit of code at the beginning to read the users prior choice of engine, and if they had selected mut, then jump to the 'pmount-mut' script.

Does that seem like a good idea?

Hi Barry,

Yes you could certainly do things that way, but there is a slightly simpler approach to effectively do all that.
I'll fill in a few blanks you might have missed.
MUT2s application is a multi-app like how busybox operates. There are several applications that can be run from mut that can be invoked via a symlink to the mut executable.
Two of the symlink applications that mut can emulate, are probepart and probedisk. Choosing muts implementation for these is the only real difference I changed for pmount.
If those symlinks are on the path, then all applictions that use those programs will be using muts drive cache information, which provides quicker access to the data than the original probepart/probedisk applications.
The choice between mut and the default engine, as you put it, could simply remap all the symlinks to/from mut and the original apps.
This could provide a speedup in boot time, and other puppy scripts related to disk probes/info.
I hope you like the thought of that idea

Jesse