Re: PPC login puzzle
snip... Yes, that that is another part of the puzzle as both the /etc/securetty and the /etc/xinetd.d/telnet files are identical in both root filesystems. So, there must be some ither file somewhere keeping me from cooking my toast with a telnet login to the 8541. Seems to me thing you can do is find out why the telnet session is being rejected. Have you done an ethernet capture? Do you have any firewalling setup? In that case you need to make sure your rules are setup properly. The ethernet capture should give you a clue. Are you sure the telnetd can be found on your system that doesn't work? What do the logs tell you on the machine that doesn't work? I think xinetd kicks out a log file, what does that tell you? Have you tried on the 8541, login to the terminal and then telnet to localhost? If you can do that, then I'd say it's a firewalling problem, if not, then it's a telnetd type of problem. Hope that helps. -stv -- /* * Steve Iribarne * Software Engineer * (aka Grunt) */ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: PPC login puzzle
Seems to me thing you can do is find out why the telnet session is being
rejected. Have you done an ethernet capture?
Do you have any firewalling setup? In that case you need to make sure your
rules are setup properly. The ethernet capture should give you a clue.
Are you sure the telnetd can be found on your system that doesn't work? What
do the logs tell you on the machine that doesn't work? I think xinetd kicks
out a log file, what does that tell you?
Have you tried on the 8541, login to the terminal and then telnet to
localhost? If you can do that, then I'd say it's a firewalling problem, if
not, then it's a telnetd type of problem.
Hope that helps.
-stv
--
/*
* Steve Iribarne
* Software Engineer
* (aka Grunt)
*/
It is interesting that 'telnet localhost' fails in a similar way as telnet
across the network, and I appreciate your kind hints, especially about the log
file and /var/log/syslog helps a bit on this problem.
When trying to telnet accross the network, syslog says
in.telnetd[]: connect from x.x.x.x
But entering root doesnt work and the host then says:
sff1 login: root
Login incorrect
There are no further errors on the 8541. When trying to 'telnet localhost',
syslog says
in.telnetd[]: connect from 127.0.0.1
But neither completes the login, so although there is a clue here, the logical
path to conclusion is still escaping me a little bit.
I can see that both targets have the same /etc/xinted.d/telnet file and it
contains:
service telnet
{
flags = REUSE
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/in.telnetd
server_args = -h
log_on_failure += USERID
}
which I think is reasonable in this situation. So, this begs the question of
what other things still bear on this type of problem. Again, I appreciate your
taking the time to help me understand a bit more of how this fits together.
Charles
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] icecube/lite5200b: wakeup from low-power support
Domen Puncer wrote: U-Boot part of Lite5200b low power mode support. Puts SDRAM out of self-refresh and transfers control to address saved at physical 0x0. Hi Domen, As I understand while waking up from the low-power mode the machine is effectively powering on, similarly to the cold reset, so U-Boot runs from the beginning as usual, but after the SDRAM controller has been initialised we detect the wakeup and teleport to the saved DRAM address. Since in case of a wakeup from the low-power mode we skip everything in U-Boot that is happening past initdram(), please clarify the following: - are you sure there are no steps beyond init_func_ram()/board_init_f() that should be performed while waking up? For example: - are all timers settings properly re-stored? - wouldn't the host/PCI bridge need to be re-initialised and re-configured as part of the wakeup process? Did you happen to test some PCI devices and would they survive after wakeup from the the low-power mode? (A similar question would apply to the USB controller) Also, a more general question: isn't time base update required after the wakeup, specially if it's been a long sleep? kind regards, Rafal ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] icecube/lite5200b: wakeup from low-power support
On 31/03/07 19:20 +0200, Rafal Jaworowski wrote: Domen Puncer wrote: U-Boot part of Lite5200b low power mode support. Puts SDRAM out of self-refresh and transfers control to address saved at physical 0x0. Hi Domen, Hi! As I understand while waking up from the low-power mode the machine is effectively powering on, similarly to the cold reset, so U-Boot runs from the beginning as usual, but after the SDRAM controller has been initialised we detect the wakeup and teleport to the saved DRAM address. Right. Since in case of a wakeup from the low-power mode we skip everything in U-Boot that is happening past initdram(), please clarify the following: - are you sure there are no steps beyond init_func_ram()/board_init_f() that should be performed while waking up? For example: - are all timers settings properly re-stored? Hmm... right, I forgot to restart watchdog... but that will be done in Linux code. - wouldn't the host/PCI bridge need to be re-initialised and re-configured as part of the wakeup process? Did you happen to test some PCI devices and would they survive after wakeup from the the low-power mode? (A similar question would apply to the USB controller) Honestly, I don't know for PCI. IIRC some time ago, kernel compiled with CONFIG_PCI didn't boot for me. USB controller/devices survived the wakeup last time I checked. Also, a more general question: isn't time base update required after the wakeup, specially if it's been a long sleep? Lite5200b doesn't have an external time source. Thanks! Domen ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC login puzzle
In message [EMAIL PROTECTED] you wrote: The question is: What are the various things that might cause one toaster to be able to login from a telnet session and another, very similar one to not be able to do this? Different settings of disable = ... in the /etc/xinetd.d/telnet config file? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell,Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] It is easier to port a shell than a shell script. - Larry Wall ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Allocating (placing) BufferDescriptors in Dual-Port RAM (CPM2)
It's probably basic knowledge, but I still having trouble figure it out anyway: Working with a SCC in a CPM (MPC8250 running linux 2.6.13-AM) I need to place Buffer Descriptors (BD) in the Dual-Port RAM (DPRAM) somewhere But two FCCs, SMC1 and SCC1 are in use, and they might use some part of the DPRAM. Is there any way to figure out what part of the DPRAM thats free? And how to reserve the part I need? Robert (SCC3 parameter RAM are at 0x8200 in DPRAM so I just place a struct there and assume that linux stays away from this memory area and don't get mad cause I use it without allocating it. Or have I got this wrong to?) ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
