I have done a manual install of puppy-4.00-k2.6.21.7....
using grub
title pup..
rootnoverify (hd0,2)
kernel /puppy400/vmlinuz pmedia=idehd psubdir=puppy400
initrd /puppy400/initrd.gz
The initial boot seems to work fine; though because of my lack of knowledge I have used the technique of infinite monkeys to establish the ethernet card connection to the internet. The problem starts with the final question of the initial boot - "Bypass serial probing" . Whether I respond yes of no to this question the reboot fails. From the text presented as the last input on the initial shutdown I should answer 'no' . I seem to get around the problem of the reboot by answering 'yes' and then modifying the boot parameters as follows:
kernel /puppy400/vmlinuz pmedia=idehd psubdir=puppy400/n
pfix=nomodem
I would very much like to understand the mechanics of the problem and the solution. Just because this seems to work I don't know is there is a more logical solution, and I didn't find the documentation that
would lead me to make the guess that seems to work. As of now I would guess that either my problem is a flaw in the hardware that I am using or an artifact of the boot process.
Reboot of puppy4 install fails at "Detecting analog modem...
boot failure
The changes made to the menu.lst did not correct the failure to boot.
rather the boot became problematic - that is the boot fails most of the time. The fact is that I am sending this message using puppy4.00 on the same system that has been giving the problem. I think that there is a timing problem in the startup that may have to do with the code to initialize a serial modem; which in fact I am not using on this system.
Is there a boot argument that I could use to prevent the modem from being initialized at startup? With that I could test the theory.
rather the boot became problematic - that is the boot fails most of the time. The fact is that I am sending this message using puppy4.00 on the same system that has been giving the problem. I think that there is a timing problem in the startup that may have to do with the code to initialize a serial modem; which in fact I am not using on this system.
Is there a boot argument that I could use to prevent the modem from being initialized at startup? With that I could test the theory.
working your "detecting analog modem" hang problem
kapper,
I would like to work with you regarding the apparent hangup while detecting modems. I made the most recent upgrade to modem support, so need to understand what is happening, in case I introduced a bug.
Would you fill me in on your setup -- your computer, your type of installation (probably "frugal"), and especially what your modem situation is? I believe that your response to the "bypass serial..." relates to the future boot-ups, but not the current one. That option assumes that whatever your serial-device configuration is, that it will always remain the same, so no need to keep checking it.
Just in case there is logic in the serial-detection code that is relied-on by the modem code, please always reply "no", since that's what I tested with. I can review that issue after we get you going.
I am somewhat confused by your conflicting statements about running Puppy. Your problem is that puppy hangs while detecting analog modems. But then you say you are running puppy successfully on the same machine! I take it that the problem-boot is from the hard drive. How were you successful in booting? And what was the outcome of the modem detection?
This could take a while and involve some debugging. I hope you will stick with me to resolve this.
Richard
I would like to work with you regarding the apparent hangup while detecting modems. I made the most recent upgrade to modem support, so need to understand what is happening, in case I introduced a bug.
Would you fill me in on your setup -- your computer, your type of installation (probably "frugal"), and especially what your modem situation is? I believe that your response to the "bypass serial..." relates to the future boot-ups, but not the current one. That option assumes that whatever your serial-device configuration is, that it will always remain the same, so no need to keep checking it.
Just in case there is logic in the serial-detection code that is relied-on by the modem code, please always reply "no", since that's what I tested with. I can review that issue after we get you going.
I am somewhat confused by your conflicting statements about running Puppy. Your problem is that puppy hangs while detecting analog modems. But then you say you are running puppy successfully on the same machine! I take it that the problem-boot is from the hard drive. How were you successful in booting? And what was the outcome of the modem detection?
This could take a while and involve some debugging. I hope you will stick with me to resolve this.
Richard
-
Bruce B
Kapper,
If I'm reading right, it looks like it was you who was wanting help. Now it looks like a two way street.
In booting Puppy we can tell others the text that was on the screen when it hung. Setting loglevel=7 gives us much more screen feedback, maybe it will hang at different text.
If you can boot, maybe you can give us the tail end of dmesg output. Otherwise the loglevel will help.
Hoping you continue participating in this two way cycle of debugging.
Bruce
If I'm reading right, it looks like it was you who was wanting help. Now it looks like a two way street.
In booting Puppy we can tell others the text that was on the screen when it hung. Setting loglevel=7 gives us much more screen feedback, maybe it will hang at different text.
If you can boot, maybe you can give us the tail end of dmesg output. Otherwise the loglevel will help.
Hoping you continue participating in this two way cycle of debugging.
Bruce
rerwin
PostPosted: Yesterday, at 11:04 pm Post subject: working your "detecting analog modem" hang problem
kapper,
my setup: copies 4 files linuz initrd.gz and pup_*.sfsfrom the iso image to hda3/puppy400/
edited /boot/grub/menu.lst by adding:
title Puppy Linux 4.00 frugal
rootnoverify (hd0,2)
kernel /puppy400/vmlinuz pmedia=idehd psubdir=puppy400 acpi=off loglevel=4 modem=off
initrd /puppy400/initrd.gz
---------
The boot as shown work for the current session that I am using now to communicate with - though the parameters are present as a desperation move to make the boot reliable.
There is a modem on the computer which in fact I no longer use.
-----------------
(quote) I believe that your response to the "bypass serial..." relates to the future boot-ups, but not the current one. That option assumes that whatever your serial-device configuration is, that it will always remain the same, so no need to keep checking it.(end quote).
That is my understanding as well given the message from the first time shutdown.
(quote)Just in case there is logic in the serial-detection code that is relied-on by the modem code, please always reply "no"(end quote) The next time I experience a boot failure I will delete the pup_save.2fs file and will then respond to the final shut down question with 'no"
(quote)statements about running Puppy.(end quote)
a restatement of the boot problem:
I am running from hard disk; the boot fails, but not consistently.
In general -that is- when the boot does fail the last message presented on screen from the startup process is: " Detecting analog modem. modem... Trying to get IP address from DHCP server (60sec timeout) ... " Then there is no further system output until I reboot.
This is now a successful boot, the content of /tmp/serialstuff is :
Type:PS2-mouse|Port:/dev/input/mice
Type:modem|Port:/dev/ttyS1|Speed:230400
(END)
I am attaching the plain text file from /tmp/bootsyssinit.log which seem to contain some relevant information. The next time I have a failure to boot I will review the /tmp file accessing with a different operating system, to see if any information remains in /tmp.
(file is contained in a tar.gz file)
I would be happy to provide any additional information that I am capable of.
====================
Bruce B
PostPosted: Today, at 12:49 am Post subject:
(quote)If you can boot, maybe you can give us the tail end of dmesg output. Otherwise the loglevel will help.(end quote)
following is a repeat of the the final message from a failed boot:
Trying to get IP address from DHCP server (60sec timeout) ...
a copy of the dmesg is contained in a tar.gz file attached.
Thank you all.
PostPosted: Yesterday, at 11:04 pm Post subject: working your "detecting analog modem" hang problem
kapper,
my setup: copies 4 files linuz initrd.gz and pup_*.sfsfrom the iso image to hda3/puppy400/
edited /boot/grub/menu.lst by adding:
title Puppy Linux 4.00 frugal
rootnoverify (hd0,2)
kernel /puppy400/vmlinuz pmedia=idehd psubdir=puppy400 acpi=off loglevel=4 modem=off
initrd /puppy400/initrd.gz
---------
The boot as shown work for the current session that I am using now to communicate with - though the parameters are present as a desperation move to make the boot reliable.
There is a modem on the computer which in fact I no longer use.
-----------------
(quote) I believe that your response to the "bypass serial..." relates to the future boot-ups, but not the current one. That option assumes that whatever your serial-device configuration is, that it will always remain the same, so no need to keep checking it.(end quote).
That is my understanding as well given the message from the first time shutdown.
(quote)Just in case there is logic in the serial-detection code that is relied-on by the modem code, please always reply "no"(end quote) The next time I experience a boot failure I will delete the pup_save.2fs file and will then respond to the final shut down question with 'no"
(quote)statements about running Puppy.(end quote)
a restatement of the boot problem:
I am running from hard disk; the boot fails, but not consistently.
In general -that is- when the boot does fail the last message presented on screen from the startup process is: " Detecting analog modem. modem... Trying to get IP address from DHCP server (60sec timeout) ... " Then there is no further system output until I reboot.
This is now a successful boot, the content of /tmp/serialstuff is :
Type:PS2-mouse|Port:/dev/input/mice
Type:modem|Port:/dev/ttyS1|Speed:230400
(END)
I am attaching the plain text file from /tmp/bootsyssinit.log which seem to contain some relevant information. The next time I have a failure to boot I will review the /tmp file accessing with a different operating system, to see if any information remains in /tmp.
(file is contained in a tar.gz file)
I would be happy to provide any additional information that I am capable of.
====================
Bruce B
PostPosted: Today, at 12:49 am Post subject:
(quote)If you can boot, maybe you can give us the tail end of dmesg output. Otherwise the loglevel will help.(end quote)
following is a repeat of the the final message from a failed boot:
Trying to get IP address from DHCP server (60sec timeout) ...
a copy of the dmesg is contained in a tar.gz file attached.
Thank you all.
- Attachments
-
- att.5.19.tar.gz
- contains two ascii files
- (4.45 KiB) Downloaded 250 times
Detecting anaolg modem
Hi Kapper,
I'm in a similar situation. I tried to upgrade from 3.01 version to 4.00 booting from CD with a puppy pfix=ram (I read this in another topic) option but the sequence hangs at step "detecting analog modem".
I've an old HP XE2 PII 366MHz with a full 3.01 installation and the modem Xircon card works well for Internet connection through a ethernet cable + ADSL modem.
I'm in a similar situation. I tried to upgrade from 3.01 version to 4.00 booting from CD with a puppy pfix=ram (I read this in another topic) option but the sequence hangs at step "detecting analog modem".
I've an old HP XE2 PII 366MHz with a full 3.01 installation and the modem Xircon card works well for Internet connection through a ethernet cable + ADSL modem.
My last two boots of puppy-4.00 have been successful - there has been no change in the grub/menu.lst
the only point of interest is the last several line of the file /tmp/bootsysinit.log. which are as follows
(current boot)
cups: started scheduler,
The following interfaces have been found: eth0
Trying to connect
Trying to get IP address from DHCP server (60sec timeout)...
/dev/ttyS1 at 0xdfe0 (irq = 0) is a 16550A
SUCCESS initializing interface eth0.!
bootsysinit.log lines 13-23/ byte 895/895 (END) (press RETURN)
# I am using less to view the file.
(current boot minus one)
Setting up ALSA with default values
The following interfaces have been found: eth0
Trying to connect
Trying to get IP address from DHCP server (60sec timeout)...
cups: started scheduler.
A network interface is up, unwise to run setserial
SUCCESS initializing interface eth0.!
bootsysinit.log lines 14-24/24 byte 939/939 (END) (press RETURN)
There is other message line in these files that are interesting; but are not relevant to the question I posed. The difference in the order of the messages in these two examples I think illustrate that there is a timing consideration relevant to my sometimes boot.
Thank you all.
the only point of interest is the last several line of the file /tmp/bootsysinit.log. which are as follows
(current boot)
cups: started scheduler,
The following interfaces have been found: eth0
Trying to connect
Trying to get IP address from DHCP server (60sec timeout)...
/dev/ttyS1 at 0xdfe0 (irq = 0) is a 16550A
SUCCESS initializing interface eth0.!
bootsysinit.log lines 13-23/ byte 895/895 (END) (press RETURN)
# I am using less to view the file.
(current boot minus one)
Setting up ALSA with default values
The following interfaces have been found: eth0
Trying to connect
Trying to get IP address from DHCP server (60sec timeout)...
cups: started scheduler.
A network interface is up, unwise to run setserial
SUCCESS initializing interface eth0.!
bootsysinit.log lines 14-24/24 byte 939/939 (END) (press RETURN)
There is other message line in these files that are interesting; but are not relevant to the question I posed. The difference in the order of the messages in these two examples I think illustrate that there is a timing consideration relevant to my sometimes boot.
Thank you all.
kapper,
Thanks for the additional info. When you say "There is a modem on the computer which in fact I no longer use.", do you mean one is plugged in, or is it built-in?
I need to see results from a basic type of run. I do not know about the modem=off or pfix=nomodem parameters, so please omit them. The other parameters look fine. I want to see puppy detecting the built-in modem, without the external (I assume) serial modem. If there is both a built-in and plugged-in modem, that might be where the problem is.
I will probably be slow to respond for the next week, as I will be away until about the end of the month. I plan to check the forum most evenings, but won't be able to test anything.
In your bootsysinit excerpts, the first shows the serial device detected. The second does not have it. What does that reflect? Does either case hang?
Anyway, I struggle to keep up with your test. It would be best to start with a minimal setup -- everything unplugged, no PC cards, no USB stuff, and no workarounds -- to see what we get. I expect to see evidence that your built-in modem is detected and set up. Then we can try blacklisting the driver (which we will know when we see what device it resolves to (most likely ttyLT0->ltserial, ttySL0->slamr) and still nothing plugged in. Then run with the blacklist item and the modem plugged in. Capture the bootsysinit.log and PupScan PCI and USB interface listings for each case.
You may be onto something regarding a timing issue. The "Trying to get IP address..." message is generated by a background process, so the message placement is independent of those of the modem detection logic.
That's enough for now. If you do get it to hang, try ctrl-c (in case it might work) to break out, then enter "cat /tmp/bootsysint.log" to see where it ends.
Richard
Thanks for the additional info. When you say "There is a modem on the computer which in fact I no longer use.", do you mean one is plugged in, or is it built-in?
I need to see results from a basic type of run. I do not know about the modem=off or pfix=nomodem parameters, so please omit them. The other parameters look fine. I want to see puppy detecting the built-in modem, without the external (I assume) serial modem. If there is both a built-in and plugged-in modem, that might be where the problem is.
I will probably be slow to respond for the next week, as I will be away until about the end of the month. I plan to check the forum most evenings, but won't be able to test anything.
In your bootsysinit excerpts, the first shows the serial device detected. The second does not have it. What does that reflect? Does either case hang?
Anyway, I struggle to keep up with your test. It would be best to start with a minimal setup -- everything unplugged, no PC cards, no USB stuff, and no workarounds -- to see what we get. I expect to see evidence that your built-in modem is detected and set up. Then we can try blacklisting the driver (which we will know when we see what device it resolves to (most likely ttyLT0->ltserial, ttySL0->slamr) and still nothing plugged in. Then run with the blacklist item and the modem plugged in. Capture the bootsysinit.log and PupScan PCI and USB interface listings for each case.
You may be onto something regarding a timing issue. The "Trying to get IP address..." message is generated by a background process, so the message placement is independent of those of the modem detection logic.
That's enough for now. If you do get it to hang, try ctrl-c (in case it might work) to break out, then enter "cat /tmp/bootsysint.log" to see where it ends.
Richard
referencing rerwin
PostPosted: Today, at 5:16 pm Post subject:
plugged in, or is it built-in modem ? It has been a long time since I looked in the chassis, it is an internal modem I will determine if it is slotted or on the system board in my next message.
(quote)I need to see results from a basic type of run.(/quote)
I have been experimenting with difference parameter forms because I don't know when a particular argument is interpreted. (but i did see the from grub/menu.lst pfix=clean did take affect.
" modem=off and pfix=nomodem" have no effect and they are removed now. "serial modem" yes... and there is only one modem, .
I have tried booting several time, where the answer to the final question of the initial shutdown was "no". I am not able to reboot under that condition. Where the answer for the initial shutdown is "yes' I have
better results.
"I will probably be slow ...." I am grateful for any input .
In your bootsysinit excerpts, the first shows the serial device detected. The second does not have it. What does that reflect? Does either case hang? -- any output that I have until now is from a puppy 4.00 that has booted and with witch I can communicate over the net.
---------------------------------------------------------------------------
Anyway, I struggle to keep up with your test. It would be best to start with a minimal setup -- everything unplugged, no PC cards, no USB stuff, and no workarounds -- to see what we get. I expect to see evidence that your built-in modem is detected and set up. Then we can try blacklisting the driver (which we will know when we see what device it resolves to (most likely ttyLT0->ltserial, ttySL0->slamr) and still nothing plugged in. Then run with the blacklist item and the modem plugged in. Capture the bootsysinit.log and PupScan PCI and USB interface listings for each case.
------------------------------------------------------------------------------------
I don't fully understand what you are saying here, though I do get the just of it. I will digest the rest in time. I still trying to orient myself to both hardware and software also I am guessing as what good net etiquette is. So excuse me, in advance if I put my foot in my mouth.
You may be onto something... Would it be reasonable to set a trap (speaking loosely) and build (let's call it) a history table of events involved in the startup. Something that could be present only during testing. A table that could be found even after a system crash.
I have been looking at rc.local0 around lines 430 .. 480 from the point of view of understanding what is happening. I have not idea if that is the right place to look; but that is what frustration will do...
try ctrl-c (in case it might work) to break out, then enter "cat /tmp/bootsysint.log" Is there other file that I should be interested in.
It would be nice to have a log of especially after a failure to complete.
Sorry that I am so long winded, and thank you.
Gilbert (kapper)
PostPosted: Today, at 5:16 pm Post subject:
plugged in, or is it built-in modem ? It has been a long time since I looked in the chassis, it is an internal modem I will determine if it is slotted or on the system board in my next message.
(quote)I need to see results from a basic type of run.(/quote)
I have been experimenting with difference parameter forms because I don't know when a particular argument is interpreted. (but i did see the from grub/menu.lst pfix=clean did take affect.
" modem=off and pfix=nomodem" have no effect and they are removed now. "serial modem" yes... and there is only one modem, .
I have tried booting several time, where the answer to the final question of the initial shutdown was "no". I am not able to reboot under that condition. Where the answer for the initial shutdown is "yes' I have
better results.
"I will probably be slow ...." I am grateful for any input .
In your bootsysinit excerpts, the first shows the serial device detected. The second does not have it. What does that reflect? Does either case hang? -- any output that I have until now is from a puppy 4.00 that has booted and with witch I can communicate over the net.
---------------------------------------------------------------------------
Anyway, I struggle to keep up with your test. It would be best to start with a minimal setup -- everything unplugged, no PC cards, no USB stuff, and no workarounds -- to see what we get. I expect to see evidence that your built-in modem is detected and set up. Then we can try blacklisting the driver (which we will know when we see what device it resolves to (most likely ttyLT0->ltserial, ttySL0->slamr) and still nothing plugged in. Then run with the blacklist item and the modem plugged in. Capture the bootsysinit.log and PupScan PCI and USB interface listings for each case.
------------------------------------------------------------------------------------
I don't fully understand what you are saying here, though I do get the just of it. I will digest the rest in time. I still trying to orient myself to both hardware and software also I am guessing as what good net etiquette is. So excuse me, in advance if I put my foot in my mouth.
You may be onto something... Would it be reasonable to set a trap (speaking loosely) and build (let's call it) a history table of events involved in the startup. Something that could be present only during testing. A table that could be found even after a system crash.
I have been looking at rc.local0 around lines 430 .. 480 from the point of view of understanding what is happening. I have not idea if that is the right place to look; but that is what frustration will do...
try ctrl-c (in case it might work) to break out, then enter "cat /tmp/bootsysint.log" Is there other file that I should be interested in.
It would be nice to have a log of especially after a failure to complete.
Sorry that I am so long winded, and thank you.
Gilbert (kapper)
Kapper
Thanks for telling me about removing your PCcard/PCMCIA serial modem card, to avoid the random hangup during boot-up. I have been trusting that Barry's code for serial modems is correct; but the fact that the modem is a PCcard is important. For 4.00 I updated logic for handling PCcards, so would like you to try something in case there is an easy remedy to the hang.
Activating PCcards is a two-step process. First, the PCMCIA controller must be discovered and its driver loaded. Then a pause while the controller "gets its act together." At that point the card should be visible to Puppy, so the driver can be loaded. The question is "how long to wait." Currently Puppy waits one second. Since your hangup is intermittant, it could be that Puppy is not waiting quite long enough.
To test this possibility, could you modify (4.00) file /etc/rc.d/rc.modules, nearly half way down, the statement:
to change the "1" to "10", for now? (I am on Win... so cannot see the line number.) You can do that without the card inserted. Then shut down, insert the card and boot up (with no workarounds). If successful, reboot several times, to be sure that is solid. If so, then change that statement so that the "10" is changed to a "2". Reboot several times to verify 100% success. If it still hangs sometimes, try "3"; we want the shortest delay that will work reliably.
Even if you don't plan to use the modem, verifying this possible fix will "rescue" many others. Thanks for helping me with this.
Could you post the name and model number of your modem, just for the record? Thanks.
Richard
Thanks for telling me about removing your PCcard/PCMCIA serial modem card, to avoid the random hangup during boot-up. I have been trusting that Barry's code for serial modems is correct; but the fact that the modem is a PCcard is important. For 4.00 I updated logic for handling PCcards, so would like you to try something in case there is an easy remedy to the hang.
Activating PCcards is a two-step process. First, the PCMCIA controller must be discovered and its driver loaded. Then a pause while the controller "gets its act together." At that point the card should be visible to Puppy, so the driver can be loaded. The question is "how long to wait." Currently Puppy waits one second. Since your hangup is intermittant, it could be that Puppy is not waiting quite long enough.
To test this possibility, could you modify (4.00) file /etc/rc.d/rc.modules, nearly half way down, the statement:
Code: Select all
[ "$MODLDED" = "true" ] && sleep 1 #v3.99 wait for PCMCIA to initializeEven if you don't plan to use the modem, verifying this possible fix will "rescue" many others. Thanks for helping me with this.
Could you post the name and model number of your modem, just for the record? Thanks.
Richard
I have been working on another opsys for the past week. During the next few days I will try you suggestion.
----------------
I wonder: ... ( my speculation may not deserve and answer.)
Is there some way that I could control testing from boot parameters, so that I would alternate between a test and "production".?
Would it make sense to use pfix=rdsh to have move control over a test?
Is there an interrupt that can be used to determine the presence of the modem and that the modem is ready?
I wont take it personally should you consider that my curiosity doesn't deserve a reply.
----------------
----------------
I wonder: ... ( my speculation may not deserve and answer.)
Is there some way that I could control testing from boot parameters, so that I would alternate between a test and "production".?
Would it make sense to use pfix=rdsh to have move control over a test?
Is there an interrupt that can be used to determine the presence of the modem and that the modem is ready?
I wont take it personally should you consider that my curiosity doesn't deserve a reply.
----------------
kapper,
For testing, I use a frugal install and separate pup_save files for testing. While not a boot parameter, you then select a pupsave file during boot-up. If you use a full install or a pupsave partition, you could add a frugal installation just for testing -- in the same partition. Then set up menu.lst to point to the added frugal install subdirectory.
I am unfamiliar with using pfix=rdsh, so cannot advise on that.
As for an interrupt associated with modem activation, I think that is too low-level for us to consider. I am waiting for Barry's work on hotplugging of USB devices, to see what that makes possible. For now, (I believe) all modems must be plugged in before booting up. That's when they are detected and established as the operating modem.
My modem work has focussed on making that detection predictable and reliable. I rely on scripts to make that work, and do not get into changing compiled code. I have not touched pupdial (yet) and feel that the probe function is not very useful. Today I worked on making the pupdial probe "find" the correct linmodem (LT, ESS, PCTEL) of those that all appear to be detected whenever any of their drivers/modules is loaded. That much works, but I can't get beyond that right now.
Back to your PCcard modem, that issue involves PCcard detection, which is a different fix from just modems. I too have an old PCcard 33.8 serial modem (actually a combo, with ethernet) that worked in puppy 1 and 2, but now is not recognized. I think I tried extending the delay, without success; so am curious to see how yours fares.
Richard
For testing, I use a frugal install and separate pup_save files for testing. While not a boot parameter, you then select a pupsave file during boot-up. If you use a full install or a pupsave partition, you could add a frugal installation just for testing -- in the same partition. Then set up menu.lst to point to the added frugal install subdirectory.
I am unfamiliar with using pfix=rdsh, so cannot advise on that.
As for an interrupt associated with modem activation, I think that is too low-level for us to consider. I am waiting for Barry's work on hotplugging of USB devices, to see what that makes possible. For now, (I believe) all modems must be plugged in before booting up. That's when they are detected and established as the operating modem.
My modem work has focussed on making that detection predictable and reliable. I rely on scripts to make that work, and do not get into changing compiled code. I have not touched pupdial (yet) and feel that the probe function is not very useful. Today I worked on making the pupdial probe "find" the correct linmodem (LT, ESS, PCTEL) of those that all appear to be detected whenever any of their drivers/modules is loaded. That much works, but I can't get beyond that right now.
Back to your PCcard modem, that issue involves PCcard detection, which is a different fix from just modems. I too have an old PCcard 33.8 serial modem (actually a combo, with ethernet) that worked in puppy 1 and 2, but now is not recognized. I think I tried extending the delay, without success; so am curious to see how yours fares.
Richard
I have read your message #13. I tested before seeing your message; but hope that I covered most of what will be of use to you.
1. Before running a test I check the output from lspci on puppy4.00
(see below)
2. As you suggested I changes the sleep command to 10 seconds from 1 second, and also added an echo to the file to see if I come back from the sleep.
3. Then replaced the modem card.
The card had a part number attached to the rj-11 connection i.e., '3cp3298-del' a search returned a like suspect : "US Robotics 56K v.90 Hardware PCI Modem with voice".
4. Ran a boot which failed. my "normal" gurb - which is probably the same as one would have if they had done the frugal inastall from puppy.
rootnoverify (hd0,2)
kernel /puppy400/vmlinuz pmedia=idehd psubdir=puppy400 loglevel=7
initrd /puppy400/initrd.gz
5. Ran a boot (this message is sent from that, second, boot) this time
I add to the kernel line:
pcmcia=no nopcmcia pfix=rdsh . I don't think that the first two had any effect, either they were picked off by a stage in grub or just dropped when the go to puppy initialization. The only real effect of using pfix=rdsh is to give the user access to a limited command shell during the initialization process before the pup_save.2fs is loaded. If I knew more about the system, that might have been useful. In any case I used [Ctrl+s] and [Ctrl+q] to slow the message output from startup.
The final messages before the gui presented were:
Detecting analog modem... ttyS1
done
Executing personal config script /etc/rc.d/rc.local ... ip_tables: (c) 2000-2006 Netfilter Core Team.
ip_conntrack version 2.4 (4904 buckets, 32752 max) -228 bytes per conntrack
done
This script will run X windows for you.
---------------end of startup--------------
6. the lspci file:
the difference between the pretest dump of the file and after a successful boot with the card in place is the last line of output
( eleven lines of output from the pretest , twelve lines from the working system with modem installed :
00:00.0 Class 0600: 8086:1130 (rev 02)
00:01.0 Class 0604: 8086:1131 (rev 02)
00:1e.0 Class 0604: 8086:244e (rev 02)
00:1f.0 Class 0601: 8086:2440 (rev 02)
00:1f.0 Class 0101: 8086:244b (rev 02)
00:1f.0 Class 0c03: 8086:2442 (rev 02)
00:1f.0 Class 0c05: 8086:2443 (rev 02)
01:00.0 Class 0300: 10de:002d (rev 15)
02:09.0 Class 0200: 10b7:9200 (rev 78) < if you see a smiley here
02:0c.0 Class 0401: 1102:0002 (rev 07) it is an artifact of the
02:0c.0 Class 0980: 1102:7002 (rev 07) browser or message
02:0d.0 Class 0700: 12b9:1008 (rev 01) composition. it should
------------------------------------------------- rev 78
1. Before running a test I check the output from lspci on puppy4.00
(see below)
2. As you suggested I changes the sleep command to 10 seconds from 1 second, and also added an echo to the file to see if I come back from the sleep.
3. Then replaced the modem card.
The card had a part number attached to the rj-11 connection i.e., '3cp3298-del' a search returned a like suspect : "US Robotics 56K v.90 Hardware PCI Modem with voice".
4. Ran a boot which failed. my "normal" gurb - which is probably the same as one would have if they had done the frugal inastall from puppy.
rootnoverify (hd0,2)
kernel /puppy400/vmlinuz pmedia=idehd psubdir=puppy400 loglevel=7
initrd /puppy400/initrd.gz
5. Ran a boot (this message is sent from that, second, boot) this time
I add to the kernel line:
pcmcia=no nopcmcia pfix=rdsh . I don't think that the first two had any effect, either they were picked off by a stage in grub or just dropped when the go to puppy initialization. The only real effect of using pfix=rdsh is to give the user access to a limited command shell during the initialization process before the pup_save.2fs is loaded. If I knew more about the system, that might have been useful. In any case I used [Ctrl+s] and [Ctrl+q] to slow the message output from startup.
The final messages before the gui presented were:
Detecting analog modem... ttyS1
done
Executing personal config script /etc/rc.d/rc.local ... ip_tables: (c) 2000-2006 Netfilter Core Team.
ip_conntrack version 2.4 (4904 buckets, 32752 max) -228 bytes per conntrack
done
This script will run X windows for you.
---------------end of startup--------------
6. the lspci file:
the difference between the pretest dump of the file and after a successful boot with the card in place is the last line of output
( eleven lines of output from the pretest , twelve lines from the working system with modem installed :
00:00.0 Class 0600: 8086:1130 (rev 02)
00:01.0 Class 0604: 8086:1131 (rev 02)
00:1e.0 Class 0604: 8086:244e (rev 02)
00:1f.0 Class 0601: 8086:2440 (rev 02)
00:1f.0 Class 0101: 8086:244b (rev 02)
00:1f.0 Class 0c03: 8086:2442 (rev 02)
00:1f.0 Class 0c05: 8086:2443 (rev 02)
01:00.0 Class 0300: 10de:002d (rev 15)
02:09.0 Class 0200: 10b7:9200 (rev 78) < if you see a smiley here
02:0c.0 Class 0401: 1102:0002 (rev 07) it is an artifact of the
02:0c.0 Class 0980: 1102:7002 (rev 07) browser or message
02:0d.0 Class 0700: 12b9:1008 (rev 01) composition. it should
------------------------------------------------- rev 78
kapper,
It appears that I have concluded incorrectly about the system you are having the problem with. I assumed you have a laptop and a PCcard in it. The "PCI" in the hardware description tells me you have a desktop/tower type. So my "sleep 10" mod is ineffective for a PCI card.
Although U.S. Robotics winmodems are not supported in linux, I see that USR provides a linux package for at least some of its "hardware" modems. I found the one for yours in this section of
http://www.usr.com/support/product-temp ... d=oem#3298
If you are "up" for some experimentation, you could extract this into a fresh (pfix=ram) pupsave environment, reboot creating a pup_save file, and see what happens. Be sure no other modem is connected, to keep things unconfounded.
It appears to run a configuration script and program, otherwise relying on the linux serial-device support. The modem should appear as ttyS3, according to the script.
Would you post the "PCI Interfaces" list produced by PupScan, so I can be sure it is in the hardware-to-driver list file? The relevant entry will probably show the "module" as either "serial" or "unknown".
Thanks for working with me on this, if you care to.
Richard
It appears that I have concluded incorrectly about the system you are having the problem with. I assumed you have a laptop and a PCcard in it. The "PCI" in the hardware description tells me you have a desktop/tower type. So my "sleep 10" mod is ineffective for a PCI card.
Although U.S. Robotics winmodems are not supported in linux, I see that USR provides a linux package for at least some of its "hardware" modems. I found the one for yours in this section of
http://www.usr.com/support/product-temp ... d=oem#3298
I downloaded the rpm file and put the contents into an archive for extraction to the / directory.Windows install files for OEM product 3298. Extract the install file to a temporary location and follow the installation instructions that were included with your modem. This file should NOT be used with any other product.
Win9x - 3298.exe file size: 245760 bytes
WinNT - 3298nt.exe file size: 207960 bytes
Red Hat Package Manager - BETA test file - LNUX_3ComMdm-1.0-1.i386.rpm file size: 7987 bytes
If you are "up" for some experimentation, you could extract this into a fresh (pfix=ram) pupsave environment, reboot creating a pup_save file, and see what happens. Be sure no other modem is connected, to keep things unconfounded.
It appears to run a configuration script and program, otherwise relying on the linux serial-device support. The modem should appear as ttyS3, according to the script.
Would you post the "PCI Interfaces" list produced by PupScan, so I can be sure it is in the hardware-to-driver list file? The relevant entry will probably show the "module" as either "serial" or "unknown".
Thanks for working with me on this, if you care to.
Richard
- Attachments
-
- LNUX_3ComMdm-1.0-1.i386.tar.gz
- USR hardware modem package for ONLY modem:
"US Robotics 56K v.90 Hardware PCI Modem with voice", model 3cp3298.
(Also for models 3cp2976 and 3cp2977.) - (6.48 KiB) Downloaded 246 times
I am responding to a crisis at present; therefore , there will a delay till i implement your suggestion. I will not drop the ball - so to speak.
A point of interest until I return. I have two dev_save.sfs files one of 256M, the other 512M. The boot will complete more frequently with the 256M save file.
A point of interest until I return. I have two dev_save.sfs files one of 256M, the other 512M. The boot will complete more frequently with the 256M save file.
duplicate message to make sure that I have included the my log.
- Attachments
-
- 3comMdm.gz
- (1.42 KiB) Downloaded 240 times
xircom
dell latitude c600,256ram,xircom rbem56g-100 cardbus modem,novatech wireless g card. dual boot win xppro with puppy214 on hd. with 214 everything works.
live cd puppy301 no usb - xircom in
ok usb -xircom out
wireless card in -usb ok
live cd puppy4 dingo xircom in puppy fails at detectjng analog modem.
xircom out -puppy loads, ok usb works
i have noticed on dial up
the xircom with xp is
connecting at 33 not 56. hope this helps a bit.
live cd puppy301 no usb - xircom in
ok usb -xircom out
wireless card in -usb ok
live cd puppy4 dingo xircom in puppy fails at detectjng analog modem.
xircom out -puppy loads, ok usb works
i have noticed on dial up
the xircom with xp is
connecting at 33 not 56. hope this helps a bit.
tqwe,
Thanks for joining this thread. I have improved the PCcard support in puppy 4.00, so it would help if you would try running with it. In addition, I have continued work on straightening out the modem support, by providing updates for particular problems. The main issue is getting Puppy to recognize hardware, by adding entries to an "override" list.
I see that your modem ID may be 0105:0103, so can add that to the override list. But I need to be sure of the driver to be associated with the modem. In 2.14, could you post the results from the "lspci" and "lsmod" commands?
Thanks.
Richard
Thanks for joining this thread. I have improved the PCcard support in puppy 4.00, so it would help if you would try running with it. In addition, I have continued work on straightening out the modem support, by providing updates for particular problems. The main issue is getting Puppy to recognize hardware, by adding entries to an "override" list.
I see that your modem ID may be 0105:0103, so can add that to the override list. But I need to be sure of the driver to be associated with the modem. In 2.14, could you post the results from the "lspci" and "lsmod" commands?
Thanks.
Richard