Re: Device node - How does kernel know about it
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Ramdisk is also executing fine, just that prints are not coming out of serial. I can see the execution of various user programs with a printk in sys_execve() routine. Ramdisk has all the required files like /dev/console, /dev/ttyS0, etc. * Looking further into tty driver, I noticed that call to tty_write() or do_tty_write() is not happening at all. So, somewhere the interface between kernel and user program is lost. * Just to check it out, I tried to write a small kernel module and a test program. - Attached memtest.c module (not really testing memory there. :-)) - Attached testmemtest.c user program, that just open's it and reads the information - Created a device node using mknod /dev/memtest c 168 0 - When I do insmod memtest.ko inside the ramdisk bootup scripts, I could see all the printk's on the console - When I execute testmemtest next in the same script, it does not display the printk inside of memtest.c module. This only indicates that read call did not really go to the kernel side. - Just to check my program's validity, I checked on a similar machine and all the code works fine. - uname -r also matches with what I built. So, chances of exiting from open call because of mismatch is remote. Since userland cannot print, I have no idea what exactly is happening there. The kernel will simply look at the major:minor numbers - so maybe you simply have a wrong major/minor for /dev/ttyS0 ? in that case you will see nothing but other than that most things will go on working. hofrat -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK hrfpn2RMn5l23ZqCOXV5rd8= =GfsF -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
Wolfgang Denk [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] you wrote: On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote: Michael Buesch [EMAIL PROTECTED] writes: +set +e mkimage -A ppc -O linux -T kernel -C gzip -a -e \ $uboot_version -d $vmz $ofile +[ $? -eq 0 ] || exit 0 +set -e mkimage ... || exit 0 Could you PLEASE increase your verbosity? Why is mkimage || exit 0 any better than my test? Because it works, while your's doesn't. Make runs each command in a new shell. This is a shell script, not a makefile. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
In message [EMAIL PROTECTED] you wrote: On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote: Michael Buesch [EMAIL PROTECTED] writes: +set +e mkimage -A ppc -O linux -T kernel -C gzip -a -e \ $uboot_version -d $vmz $ofile +[ $? -eq 0 ] || exit 0 +set -e mkimage ... || exit 0 Could you PLEASE increase your verbosity? Why is mkimage || exit 0 any better than my test? Because it works, while your's doesn't. Make runs each command in a new shell. Your set +e is in vain, and so is your test of the return code. Um... doesn't make throw an error anyway when the execution of mkimage fails? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Success in marriage is not so much finding the right person as it is being the right person. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
Anton Vorontsov wrote:
I wonder what are the symptoms if microcode is at fault? According
to errata description, hang isn't something I should get on the
transmit attempt.
Well, if the microcode fails, you'll never know. I tried to explain the
need for a unified microcode validation mechanism to the QE microcode
developers, but I didn't get very far.
Well. All I've found is: QERAMPTCH.zip (RAM Microcode Patches for
PowerQUICC II Pro Family QE Errata), which should fix QE_UART5 errata
for MPC8323 Rev 1.1.
I don't know what that is, but it doesn't apply. I'm talking about the
QE and QE UART patches I've posted to this mailing list over the past
month. Once Kumar applies them to them to his for-2.6.25 branch, it'll
make life easier for everyone.
Can I assume it works for MPC8360 too?
No. Microcode is very sensitive to the processor and the revision. A
microcode for 8360 2.1 won't work on 8360 2.0.
I forgot to give you the actual microcode. :-) I'll email it to you later.
Here are dts entries I use:
firmware {
id = Soft-UART;
extended_modes = 0 0;
virtual_traps = 0 0 0 0 0 0 0 0;
};
This entry is created by U-Boot only if it uploads the microcode. This
should not be in the DTS.
[EMAIL PROTECTED] {
device_type = serial;
compatible = ucc_uart;
reg = 0x2400 0x200;
device-id = 5;
port-number = 0;
rx-clock-name = brg7;
tx-clock-name = brg8;
interrupts = 40;
interrupt-parent = qeic;
soft-uart;
};
[EMAIL PROTECTED] {
device_type = serial;
compatible = ucc_uart;
reg = 0x3400 0x200;
device-id = 6;
port-number = 1;
rx-clock-name = brg14;
tx-clock-name = brg14;
interrupts = 41;
interrupt-parent = qeic;
};
You need to have separate BRGs for TX and RX when using soft-uart mode,
and you MUST use soft-uart mode on the 8360.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
On Thu, Dec 27, 2007 at 09:38:23AM -0600, Timur Tabi wrote:
Anton Vorontsov wrote:
I wonder what are the symptoms if microcode is at fault? According
to errata description, hang isn't something I should get on the
transmit attempt.
Well, if the microcode fails, you'll never know. I tried to explain the
need for a unified microcode validation mechanism to the QE microcode
developers, but I didn't get very far.
Well. All I've found is: QERAMPTCH.zip (RAM Microcode Patches for
PowerQUICC II Pro Family QE Errata), which should fix QE_UART5 errata
for MPC8323 Rev 1.1.
I don't know what that is, but it doesn't apply. I'm talking about the
QE and QE UART patches I've posted to this mailing list over the past
month.
:-) I didn't get it wrong. QERAMPTCH.zip is the microcode (they
name it microcode patches) I've tried, it has nothing to do with
your Linux patches.
Once Kumar applies them to them to his for-2.6.25 branch, it'll
make life easier for everyone.
Can I assume it works for MPC8360 too?
No. Microcode is very sensitive to the processor and the revision. A
microcode for 8360 2.1 won't work on 8360 2.0.
I forgot to give you the actual microcode. :-) I'll email it to you later.
Much thanks! Also, could you provide the magic python script to
generate binary firmwares to try loading fw from the linux? Or
just a .bin file.
Here are dts entries I use:
firmware {
id = Soft-UART;
extended_modes = 0 0;
virtual_traps = 0 0 0 0 0 0 0 0;
};
This entry is created by U-Boot only if it uploads the microcode. This
should not be in the DTS.
Sure thing. That was just a quirk for the quick testing, to not tinker
with u-boot part.
[EMAIL PROTECTED] {
device_type = serial;
compatible = ucc_uart;
reg = 0x2400 0x200;
device-id = 5;
port-number = 0;
rx-clock-name = brg7;
tx-clock-name = brg8;
interrupts = 40;
interrupt-parent = qeic;
soft-uart;
};
[EMAIL PROTECTED] {
device_type = serial;
compatible = ucc_uart;
reg = 0x3400 0x200;
device-id = 6;
port-number = 1;
rx-clock-name = brg14;
tx-clock-name = brg14;
interrupts = 41;
interrupt-parent = qeic;
};
You need to have separate BRGs for TX and RX when using soft-uart mode,
and you MUST use soft-uart mode on the 8360.
Yup, I know. In the original email I've explained that I deliberately
configured two uarts differently for the testing purposes.
Thanks!
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Version 17, series to add device tree naming to i2c
On 12/19/07, Jon Smirl [EMAIL PROTECTED] wrote: Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in. Are there any further objections to this patch? Can it all go in through the powerpc trees or do the i2c people want to send it on? -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
On Thursday 27 December 2007 11:14:04 Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote: Michael Buesch [EMAIL PROTECTED] writes: +set +e mkimage -A ppc -O linux -T kernel -C gzip -a -e \ $uboot_version -d $vmz $ofile +[ $? -eq 0 ] || exit 0 +set -e mkimage ... || exit 0 Could you PLEASE increase your verbosity? Why is mkimage || exit 0 any better than my test? Because it works, while your's doesn't. Make runs each command in a new shell. Your set +e is in vain, and so is your test of the return code. Um... doesn't make throw an error anyway when the execution of mkimage fails? I'm not sure what you are talking about at all, sorry. set +e simply disables the abortion of the shell script if the mkimage command fails. The test after that checks whether it failed and returns success in that event, so the calling makefile does _not_ interrupt. It only gives you a mkimage not found message. I did test this patch on my machine where there is no mkimage and it correctly aborts the shell script and throws an error, while it does not abort the makefile process. And that is what we want. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Problems with arch/powerpc
If this should go in linuxppc-embedded please let me know. It seems that
the board supports are getting posted here.
PIKA has an embedded PPC440EP board based on the AMCC Yosemite board. I
got the Linux 2.6.19.2 kernel working by basically copying the Yosemite
configuration. Now I am trying to move from the ppc to the powerpc
architecture using Josh Boyer's for-2.6.25 kernel. And there is no
Yosemite config :( We are using u-boot 1.3.0.
I have the kernel booting, but the OS runs very strange. I cannot run
the ash shell, it fails on the first setjmp. But I can run the hush
shell (we are using busybox). So it goes, many things work, others don't.
I am mounting the root filesystem over NFS, so the ethernet seem to work
well.
But cat /proc/interrupts shows:
CPU0
16:126 UIC Level serial
17:520 UIC Level MAL TX EOB
18:804 UIC Level MAL RX EOB
19: 0 UIC Level MAL SERR
20: 0 UIC Level MAL TX DE
21: 0 UIC Level MAL RX DE
28: 0 UIC Level EMAC
BAD: 0
Which is quite different from the older kernel:
CPU0
0: 3075 UIC0 Level serial
2: 1526 UIC0 Level IBM IIC
7: 0 UIC0 Level IBM IIC
10: 1388 UIC0 Level MAL TX EOB
11: 1839 UIC0 Level MAL RX EOB
32: 0 UIC1 Level MAL SERR
33: 0 UIC1 Level MAL TX DE
34: 0 UIC1 Level MAL RX DE
40: 1 UIC1 Level ohci_hcd:usb1
60: 0 UIC1 Level EMAC
BAD: 0
I have attached the dts file. It is based on the bamboo. I can provide
any other config, the only thing I can't provide is the hardware ;)
Since the new kernel doesn't show UIC0 or UIC1, just UIC I am wondering
if something is wrong with the dts.
I have to admit the dts file confuses me a bit. So I suspect that is
where the problem is. If anybody has any other ideas, don't hesitate to
suggest!
Cheers,
Sean
/*
* Device Tree Source for PIKA Taco
*
* Copyright 2007 PIKA Technologies
*
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed as is without
* any warranty of any kind, whether express or implied.
*/
/ {
#address-cells = 2;
#size-cells = 1;
model = pika,taco;
compatible = pika,taco;
dcr-parent = /cpus/[EMAIL PROTECTED];
aliases {
ethernet0 = EMAC0;
serial0 = UART0;
};
cpus {
#address-cells = 1;
#size-cells = 0;
[EMAIL PROTECTED] {
device_type = cpu;
model = PowerPC,440EP;
reg = 0;
clock-frequency = 0; /* Filled in by zImage */
timebase-frequency = 0; /* Filled in by zImage */
i-cache-line-size = 20;
d-cache-line-size = 20;
i-cache-size = 8000;
d-cache-size = 8000;
dcr-controller;
dcr-access-method = native;
};
};
memory {
device_type = memory;
reg = 0 0 0; /* Filled in by zImage */
};
UIC0: interrupt-controller0 {
compatible = ibm,uic-440ep,ibm,uic;
interrupt-controller;
cell-index = 0;
dcr-reg = 0c0 009;
#address-cells = 0;
#size-cells = 0;
#interrupt-cells = 2;
};
UIC1: interrupt-controller1 {
compatible = ibm,uic-440ep,ibm,uic;
interrupt-controller;
cell-index = 1;
dcr-reg = 0d0 009;
#address-cells = 0;
#size-cells = 0;
#interrupt-cells = 2;
interrupts = 1e 4 1f 4; /* cascade */
interrupt-parent = UIC0;
};
SDR0: sdr {
compatible = ibm,sdr-440ep;
dcr-reg = 00e 002;
};
CPR0: cpr {
compatible = ibm,cpr-440ep;
dcr-reg = 00c 002;
};
plb {
compatible = ibm,plb-440ep, ibm,plb-440gp, ibm,plb4;
#address-cells = 2;
#size-cells = 1;
ranges;
clock-frequency = 0; /* Filled in by zImage */
SDRAM0: sdram {
compatible = ibm,sdram-440ep, ibm,sdram-405gp;
dcr-reg = 010 2;
};
DMA0: dma {
compatible = ibm,dma-440ep, ibm,dma-440gp;
dcr-reg = 100 027;
};
MAL0: mcmal {
compatible = ibm,mcmal-440ep, ibm,mcmal-440gp,
ibm,mcmal;
update: RE: nap/dfs on 7448
Turns out the Tundra TSI109 has various problems trying to nap -- its not a 7448 issue... We're working with tundra to get a workaround (in software, they won't respin the part). It seems DMA while napping is an issue, we have to turn off the tsi109 ethernet queues before entering nap mode... If anyone needs this work, let me know (it will be covered under GPL). marty -Original Message- From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 2:02 AM To: Leisner, Martin Cc: linuxppc-dev Subject: Re: nap/dfs on 7448 On Mon, 2007-10-01 at 17:32 -0400, Leisner, Martin wrote: I asked this on linuxppc-embedded a week ago (I didn't even know this list existed until last week -- another reason to get rid of linuxpcc-embedded). Has anyone gotten NAP/DFS to reliably work on a 7448? I'm seeing strange problems with peripherals...(using a ram disk works fine). Could it be that your host bridge isn't properly waking up the CPU to DOZE state for snooping DMA ? (It might require some delays on QACK in some cases, I know Apple had workarounds in those areas, maybe something along those lines need to be configured in the chipset). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems with arch/powerpc
On Thu, 27 Dec 2007 17:20:09 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: If this should go in linuxppc-embedded please let me know. It seems that the board supports are getting posted here. PIKA has an embedded PPC440EP board based on the AMCC Yosemite board. I got the Linux 2.6.19.2 kernel working by basically copying the Yosemite configuration. Now I am trying to move from the ppc to the powerpc architecture using Josh Boyer's for-2.6.25 kernel. And there is no Yosemite config :( We are using u-boot 1.3.0. Yeah, I've no Yosemite board so no port for it yet. I have the kernel booting, but the OS runs very strange. I cannot run the ash shell, it fails on the first setjmp. But I can run the hush shell (we are using busybox). So it goes, many things work, others don't. I am mounting the root filesystem over NFS, so the ethernet seem to work well. But cat /proc/interrupts shows: CPU0 16:126 UIC Level serial 17:520 UIC Level MAL TX EOB 18:804 UIC Level MAL RX EOB 19: 0 UIC Level MAL SERR 20: 0 UIC Level MAL TX DE 21: 0 UIC Level MAL RX DE 28: 0 UIC Level EMAC BAD: 0 Looks fairly normal to me. Which is quite different from the older kernel: CPU0 0: 3075 UIC0 Level serial 2: 1526 UIC0 Level IBM IIC 7: 0 UIC0 Level IBM IIC 10: 1388 UIC0 Level MAL TX EOB 11: 1839 UIC0 Level MAL RX EOB 32: 0 UIC1 Level MAL SERR 33: 0 UIC1 Level MAL TX DE 34: 0 UIC1 Level MAL RX DE 40: 1 UIC1 Level ohci_hcd:usb1 60: 0 UIC1 Level EMAC BAD: 0 There's no support for the i2c devices on 440 in arch/powerpc yet, which is why those don't show up. As for the USB interrupt, you might be missing the device-tree enabled USB driver in your config. The interrupt numbers will differ based on various things, so I wouldn't worry about that. I have attached the dts file. It is based on the bamboo. I can provide any other config, the only thing I can't provide is the hardware ;) Since the new kernel doesn't show UIC0 or UIC1, just UIC I am wondering if something is wrong with the dts. I didn't see anything wrong in my cursory glance. But I need to look at it a bit closer to be sure. Can you post the full boot messages (send privately if you'd like). One thing to make sure of is if all the properties in the DTS file that say Filled in by zImage wrapper are actually getting filled in. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems with arch/powerpc
Josh Boyer wrote: Can you post the full boot messages (send privately if you'd like). One thing to make sure of is if all the properties in the DTS file that say Filled in by zImage wrapper are actually getting filled in. I have attached a boot log. The ethernet and IP addresses have been modified, but everything else is correct. I checked all the dts entries marked by /* Filled in by zImage */ by checking /proc/device-tree and they all match what is printed after the log message Uncompressing Kernel Image ... OK. FYI: It is a 533MHz PPC but the HW guys read the spec wrong and are running the system clock at 66.0MHz rather than 66.6MHz, so the 528MHz value is correct. Cheers, Sean U-Boot 1.3.0-gf92edbd8-dirty (Dec 7 2007 - 11:06:34) CPU: AMCC PowerPC 440EP Rev. C at 533.333 MHz (PLB=133, OPB=66, EBC=66 MHz) I2C boot EEPROM enabled Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) , PCI async ext clock used 32 kB I-Cache 32 kB D-Cache Board: PIKA Embedded Appliance I2C: ready DRAM: 256 MB FLASH: 64 MB NAND: 64 MiB In:serial Out: serial Err: serial Protected 2 sectors FPGA download...complete. FPGA code revision 1.2.2.0 Starting board diagnostics: 1. RAM walking bit test, first bank... test complete. 2. RAM walking bit test, second bank... test complete. 3. FPGA walking bit test... test complete. 4. Skipping user test - start_test_addr or end_test_addr env. vars not set. Board diagnostics complete. Net: ppc_4xx_eth0 Type run flash_nfs to mount root filesystem over NFS Hit any key to stop autoboot: 0 Waiting for PHY auto negotiation to complete. done ENET Speed is 100 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 192.168.0.164; our IP address is 192.168.0.99 Filename 'uImage'. Load address: 0x20 Loading: # # # # done Bytes transferred = 1308159 (13f5ff hex) ## Booting image at 0020 ... Image Name: Linux-2.6.24-rc6-pika Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1308095 Bytes = 1.2 MB Load Address: 0040 Entry Point: 004003c8 Verifying Checksum ... OK Uncompressing Kernel Image ... OK CPU clock-frequency - 0x1f78a400 (528MHz) CPU timebase-frequency - 0x1f78a400 (528MHz) /plb: clock-frequency - 7de2900 (132MHz) /plb/opb: clock-frequency - 3ef1480 (66MHz) /plb/opb/ebc: clock-frequency - 3ef1480 (66MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) Memory - 0x0 0x0 0x1000 (256MB) ENET0: local-mac-address - mac address zImage starting: loaded at 0x0040 (sp: 0x0ff2a558) Allocating 0x2b84a0 bytes for kernel ... gunzipping (0x - 0x0040d000:0x006ba364)...done 0x297408 bytes Linux/PowerPC load: root=/dev/nfs rw nfsroot=192.168.x.x:/usr/src/eldk/taco ip=192.168.x.x:192.168.x.x:192.168.x.x:255.255.252.0:tigger:eth0:off panic=1 console=ttyS0,1150 Finalizing device tree... flat tree at 0x6c7300 Using Taco machine description Linux version 2.6.24-rc6-pika ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #14 Thu Dec 27 16:33:16 EST 2007 console [udbg0] enabled setup_arch: bootmem arch: exit Zone PFN ranges: DMA 0 -65536 Normal 65536 -65536 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -65536 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/nfs rw nfsroot=192.168.x.x:/usr/src/eldk/taco ip=192.168.x.x:192.168.x.x:192.168.x.x:255.255.252.0:tigger:eth0:off panic=1 console=ttyS0,110 UIC0 (32 IRQ sources) at DCR 0xc0 UIC1 (32 IRQ sources) at DCR 0xd0 PID hash table entries: 1024 (order: 10, 4096 bytes) clocksource: timebase mult[79364e] shift[22] registered Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 256768k/262144k available (2516k kernel code, 5056k reserved, 116k data, 129k bss, 140k init) Mount-cache hash table entries: 512
RE: Device node - How does kernel know about it
Thank you Jon and Nicholas. I already have console=ttyS0 in the kernel command line. That is not helping me. I looked at the major/minor numbers with a good working system and it looks correct for the nodes created in ramdisk. What is the kernel routine that is first called when there is, for example a read() function call from user program? I would like to start debugging from there and see if any thing at all happens when there is a call. Appreciate your help with this question. Thanks Siva -Original Message- From: Nicholas Mc Guire [mailto:[EMAIL PROTECTED] Sent: Friday, December 28, 2007 12:39 AM To: Siva Prasad Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: Device node - How does kernel know about it -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Ramdisk is also executing fine, just that prints are not coming out of serial. I can see the execution of various user programs with a printk in sys_execve() routine. Ramdisk has all the required files like /dev/console, /dev/ttyS0, etc. * Looking further into tty driver, I noticed that call to tty_write() or do_tty_write() is not happening at all. So, somewhere the interface between kernel and user program is lost. * Just to check it out, I tried to write a small kernel module and a test program. - Attached memtest.c module (not really testing memory there. :-)) - Attached testmemtest.c user program, that just open's it and reads the information - Created a device node using mknod /dev/memtest c 168 0 - When I do insmod memtest.ko inside the ramdisk bootup scripts, I could see all the printk's on the console - When I execute testmemtest next in the same script, it does not display the printk inside of memtest.c module. This only indicates that read call did not really go to the kernel side. - Just to check my program's validity, I checked on a similar machine and all the code works fine. - uname -r also matches with what I built. So, chances of exiting from open call because of mismatch is remote. Since userland cannot print, I have no idea what exactly is happening there. The kernel will simply look at the major:minor numbers - so maybe you simply have a wrong major/minor for /dev/ttyS0 ? in that case you will see nothing but other than that most things will go on working. hofrat -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK hrfpn2RMn5l23ZqCOXV5rd8= =GfsF -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] [POWERPC] smp_call_function_map should be static
smp_call_function_map should be static, and for consistency prepend it
with __ like other local helper functions in the same file.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 338950a..cefeee8 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -181,12 +181,13 @@ static struct call_data_struct {
* wait If true, wait (atomically) until function has completed on other
CPUs.
* [RETURNS] 0 on success, else a negative status code. Does not return until
* remote CPUs are nearly ready to execute func or are or have executed.
+ * map is a cpu map of the cpus to send IPI to.
*
* You must not call this function with disabled interrupts or from a
* hardware interrupt handler or from a bottom half handler.
*/
-int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
- int wait, cpumask_t map)
+static int __smp_call_function_map(void (*func) (void *info), void *info,
+ int nonatomic, int wait, cpumask_t map)
{
struct call_data_struct data;
int ret = -1, num_cpus;
@@ -265,7 +266,8 @@ int smp_call_function_map(void (*func) (void *info), void
*info, int nonatomic,
static int __smp_call_function(void (*func)(void *info), void *info,
int nonatomic, int wait)
{
- return smp_call_function_map(func,info,nonatomic,wait,cpu_online_map);
+ return __smp_call_function_map(func, info, nonatomic, wait,
+ cpu_online_map);
}
int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
@@ -278,8 +280,8 @@ int smp_call_function(void (*func) (void *info), void
*info, int nonatomic,
}
EXPORT_SYMBOL(smp_call_function);
-int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
int nonatomic,
- int wait)
+int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
+int nonatomic, int wait)
{
cpumask_t map = CPU_MASK_NONE;
int ret = 0;
@@ -292,7 +294,7 @@ int smp_call_function_single(int cpu, void (*func) (void
*info), void *info, int
cpu_set(cpu, map);
if (cpu != get_cpu())
- ret = smp_call_function_map(func,info,nonatomic,wait,map);
+ ret = __smp_call_function_map(func, info, nonatomic, wait, map);
else {
local_irq_disable();
func(info);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] [POWERPC] Make smp_send_stop() handle panic and xmon reboot
smp_send_stop() will send an IPI to all other cpus to shut them down.
However, for the case of xmon-based reboots (as well as potentially some
panics), the other cpus are (or might be) spinning with interrupts off,
and won't take the IPI.
Current code will drop us into the debugger when the IPI fails, which
means we're in an infinite loop that we can't get out of without an
external reset of some sort.
Instead, make the smp_send_stop() IPI call path just print the warning
about being unable to send IPIs, but make it return so the rest of the
shutdown sequence can continue. It's not perfect, but the lesser of
two evils.
Also move the call_lock handling outside of smp_call_function_map so we
can avoid deadlocks in smp_send_stop().
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index cefeee8..8730687 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -76,6 +76,8 @@ void smp_call_function_interrupt(void);
int smt_enabled_at_boot = 1;
+static int ipi_fail_ok;
+
static void (*crash_ipi_function_ptr)(struct pt_regs *) = NULL;
#ifdef CONFIG_PPC64
@@ -204,8 +206,6 @@ static int __smp_call_function_map(void (*func) (void
*info), void *info,
if (wait)
atomic_set(data.finished, 0);
- spin_lock(call_lock);
-
/* remove 'self' from the map */
if (cpu_isset(smp_processor_id(), map))
cpu_clear(smp_processor_id(), map);
@@ -232,7 +232,8 @@ static int __smp_call_function_map(void (*func) (void
*info), void *info,
printk(smp_call_function on cpu %d: other cpus not
responding (%d)\n, smp_processor_id(),
atomic_read(data.started));
- debugger(NULL);
+ if (!ipi_fail_ok)
+ debugger(NULL);
goto out;
}
}
@@ -259,15 +260,18 @@ static int __smp_call_function_map(void (*func) (void
*info), void *info,
out:
call_data = NULL;
HMT_medium();
- spin_unlock(call_lock);
return ret;
}
static int __smp_call_function(void (*func)(void *info), void *info,
int nonatomic, int wait)
{
- return __smp_call_function_map(func, info, nonatomic, wait,
+ int ret;
+ spin_lock(call_lock);
+ ret =__smp_call_function_map(func, info, nonatomic, wait,
cpu_online_map);
+ spin_unlock(call_lock);
+ return ret;
}
int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
@@ -293,9 +297,11 @@ int smp_call_function_single(int cpu, void (*func) (void
*info), void *info,
return -EINVAL;
cpu_set(cpu, map);
- if (cpu != get_cpu())
+ if (cpu != get_cpu()) {
+ spin_lock(call_lock);
ret = __smp_call_function_map(func, info, nonatomic, wait, map);
- else {
+ spin_unlock(call_lock);
+ } else {
local_irq_disable();
func(info);
local_irq_enable();
@@ -307,7 +313,22 @@ EXPORT_SYMBOL(smp_call_function_single);
void smp_send_stop(void)
{
- __smp_call_function(stop_this_cpu, NULL, 1, 0);
+ int nolock;
+
+ /* It's OK to fail sending the IPI, since the alternative is to
+* be stuck forever waiting on the other CPU to take the interrupt.
+*
+* It's better to at least continue and go through reboot, since this
+* function is usually called at panic or reboot time in the first
+* place.
+*/
+ ipi_fail_ok = 1;
+
+ /* Don't deadlock in case we got called through panic */
+ nolock = !spin_trylock(call_lock);
+ __smp_call_function_map(stop_this_cpu, NULL, 1, 0, cpu_online_map);
+ if (!nolock)
+ spin_unlock(call_lock);
}
void smp_call_function_interrupt(void)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device node - How does kernel know about it
On 12/27/07, Siva Prasad [EMAIL PROTECTED] wrote: Thank you Jon and Nicholas. I already have console=ttyS0 in the kernel command line. That is not helping me. Do you have CONFIG_EARLY_PRINTK=y in .config? I looked at the major/minor numbers with a good working system and it looks correct for the nodes created in ramdisk. What is the kernel routine that is first called when there is, for example a read() function call from user program? I would like to start debugging from there and see if any thing at all happens when there is a call. Appreciate your help with this question. Thanks Siva -Original Message- From: Nicholas Mc Guire [mailto:[EMAIL PROTECTED] Sent: Friday, December 28, 2007 12:39 AM To: Siva Prasad Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: Device node - How does kernel know about it -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Ramdisk is also executing fine, just that prints are not coming out of serial. I can see the execution of various user programs with a printk in sys_execve() routine. Ramdisk has all the required files like /dev/console, /dev/ttyS0, etc. * Looking further into tty driver, I noticed that call to tty_write() or do_tty_write() is not happening at all. So, somewhere the interface between kernel and user program is lost. * Just to check it out, I tried to write a small kernel module and a test program. - Attached memtest.c module (not really testing memory there. :-)) - Attached testmemtest.c user program, that just open's it and reads the information - Created a device node using mknod /dev/memtest c 168 0 - When I do insmod memtest.ko inside the ramdisk bootup scripts, I could see all the printk's on the console - When I execute testmemtest next in the same script, it does not display the printk inside of memtest.c module. This only indicates that read call did not really go to the kernel side. - Just to check my program's validity, I checked on a similar machine and all the code works fine. - uname -r also matches with what I built. So, chances of exiting from open call because of mismatch is remote. Since userland cannot print, I have no idea what exactly is happening there. The kernel will simply look at the major:minor numbers - so maybe you simply have a wrong major/minor for /dev/ttyS0 ? in that case you will see nothing but other than that most things will go on working. hofrat -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK hrfpn2RMn5l23ZqCOXV5rd8= =GfsF -END PGP SIGNATURE- -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Device node - How does kernel know about it
Jon, Yes!... I have CONFIG_EARLY_PRINTK=y, and I could see early prints during booting the kernel. Afterwards, printk's also work as expected. Only printf's from user space has problem. - Siva -Original Message- From: Jon Smirl [mailto:[EMAIL PROTECTED] Sent: Thursday, December 27, 2007 8:16 PM To: Siva Prasad Cc: Nicholas Mc Guire; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: Device node - How does kernel know about it On 12/27/07, Siva Prasad [EMAIL PROTECTED] wrote: Thank you Jon and Nicholas. I already have console=ttyS0 in the kernel command line. That is not helping me. Do you have CONFIG_EARLY_PRINTK=y in .config? I looked at the major/minor numbers with a good working system and it looks correct for the nodes created in ramdisk. What is the kernel routine that is first called when there is, for example a read() function call from user program? I would like to start debugging from there and see if any thing at all happens when there is a call. Appreciate your help with this question. Thanks Siva -Original Message- From: Nicholas Mc Guire [mailto:[EMAIL PROTECTED] Sent: Friday, December 28, 2007 12:39 AM To: Siva Prasad Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: Device node - How does kernel know about it -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Ramdisk is also executing fine, just that prints are not coming out of serial. I can see the execution of various user programs with a printk in sys_execve() routine. Ramdisk has all the required files like /dev/console, /dev/ttyS0, etc. * Looking further into tty driver, I noticed that call to tty_write() or do_tty_write() is not happening at all. So, somewhere the interface between kernel and user program is lost. * Just to check it out, I tried to write a small kernel module and a test program. - Attached memtest.c module (not really testing memory there. :-)) - Attached testmemtest.c user program, that just open's it and reads the information - Created a device node using mknod /dev/memtest c 168 0 - When I do insmod memtest.ko inside the ramdisk bootup scripts, I could see all the printk's on the console - When I execute testmemtest next in the same script, it does not display the printk inside of memtest.c module. This only indicates that read call did not really go to the kernel side. - Just to check my program's validity, I checked on a similar machine and all the code works fine. - uname -r also matches with what I built. So, chances of exiting from open call because of mismatch is remote. Since userland cannot print, I have no idea what exactly is happening there. The kernel will simply look at the major:minor numbers - so maybe you simply have a wrong major/minor for /dev/ttyS0 ? in that case you will see nothing but other than that most things will go on working. hofrat -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK hrfpn2RMn5l23ZqCOXV5rd8= =GfsF -END PGP SIGNATURE- -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: update: RE: nap/dfs on 7448
On Thu, 2007-12-27 at 17:37 -0500, Leisner, Martin wrote: Turns out the Tundra TSI109 has various problems trying to nap -- its not a 7448 issue... We're working with tundra to get a workaround (in software, they won't respin the part). It seems DMA while napping is an issue, we have to turn off the tsi109 ethernet queues before entering nap mode... If anyone needs this work, let me know (it will be covered under GPL). This looks like yet another f*cked up bridge ... I wonder if we'll ever get a half decent working northbridge for those processors... Unfortunately, it looks like the market for those is limited to junk from vendor A and shit from vendor B... Is the problem limited to the TSI internal ethernet or it happens with any DMA ? Looks to me like turning off DMA in NAP mode basically makes NAP mode unuseable, perdiod. You can't start loosing packets because your processor is idle. So no power saving, and let's eat the watts since they won't respin the part. Great ! Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
On Thu, 27 Dec 2007 11:15:37 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
FUJITA Tomonori wrote:
On Thu, 27 Dec 2007 10:08:25 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
FUJITA Tomonori wrote:
On Mon, 24 Dec 2007 10:18:50 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
[snip]
I might break the IOMMU code. Can you reproduce it easily? If so,
reverting my IOMMU patches (I've attached a patch to revert them) fix
the problem?
[snip]
Yes, this patch fixes the problem for me.
Thanks, so you can reproduce it easily, right?
Yes, quite easily
The problem is that I don't want to revert these changes. I'll see
how these changes cause the problem shortly.
I'll try and find some bandwidth to review/test the patches and help you
figure out the right solution.
Thanks,
Can you try this?
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
index e7d8544..495575a 100644
--- a/lib/iommu-helper.c
+++ b/lib/iommu-helper.c
@@ -8,15 +8,20 @@
static unsigned long find_next_zero_area(unsigned long *map,
unsigned long size,
unsigned long start,
-unsigned int nr)
+unsigned int nr,
+unsigned long align_mask)
{
unsigned long index, end, i;
again:
index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) ~align_mask;
+
end = index + nr;
- if (end size)
+ if (end = size)
return -1;
- for (i = index + 1; i end; i++) {
+ for (i = index; i end; i++) {
if (test_bit(i, map)) {
start = i+1;
goto again;
@@ -50,9 +55,8 @@ unsigned long iommu_area_alloc(unsigned long *map, unsigned
long size,
{
unsigned long index;
again:
- index = find_next_zero_area(map, size, start, nr);
+ index = find_next_zero_area(map, size, start, nr, align_mask);
if (index != -1) {
- index = (index + align_mask) ~align_mask;
if (is_span_boundary(index, nr, shift, boundary_size)) {
/* we could do more effectively */
start = index + 1;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
2.6.10 kernel hangs after timer_init
2.6.10 kernel hangs on my board with PPC64 processors. The log is below. There must be a fix for this somewhere because it boots just fine on 2.6.14 kernel. Could someone please point me to the fix for this? time_init: decrementer frequency = 112.50 MHz time_init: processor frequency = 1800.00 MHz - set_preferred_console() stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED],2/[EMAIL PROTECTED] Found serial console at ttyS0 smp_prepare_cpus smp_mpic_probe()... nr_cpus: 2 smp: kicking cpu 1 - Never miss a thing. Make Yahoo your homepage.___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems with arch/powerpc
Josh Boyer wrote: As for the USB interrupt, you might be missing the device-tree enabled USB driver in your config. The interrupt numbers will differ based on various things, so I wouldn't worry about that. Just so I am not all bad news, I got the usb going. I borrowed the usb config from bamboo.dts. I then had to patch the top level usb Kconfig. It basically relies on PCI, and the taco has no PCI, so I added the taco as a special case. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems with arch/powerpc
And one more thought, could uClibc be causing problems with the new kernel? It just seems strange that kernel stuff seems to work (e.g. no problems mounting a usbkey) yet a simple setjmp in a user mode app reeks havoc. We are going to be moving away from uClibc in the short term (I am the only one left using it). So if this could be an issue I might have to bite the bullet and switch now. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
FUJITA Tomonori wrote:
[snip]
Thanks,
Can you try this?
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
index e7d8544..495575a 100644
--- a/lib/iommu-helper.c
+++ b/lib/iommu-helper.c
@@ -8,15 +8,20 @@
static unsigned long find_next_zero_area(unsigned long *map,
unsigned long size,
unsigned long start,
- unsigned int nr)
+ unsigned int nr,
+ unsigned long align_mask)
{
unsigned long index, end, i;
again:
index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) ~align_mask;
+
end = index + nr;
- if (end size)
+ if (end = size)
return -1;
- for (i = index + 1; i end; i++) {
+ for (i = index; i end; i++) {
if (test_bit(i, map)) {
start = i+1;
goto again;
@@ -50,9 +55,8 @@ unsigned long iommu_area_alloc(unsigned long *map, unsigned
long size,
{
unsigned long index;
again:
- index = find_next_zero_area(map, size, start, nr);
+ index = find_next_zero_area(map, size, start, nr, align_mask);
if (index != -1) {
- index = (index + align_mask) ~align_mask;
if (is_span_boundary(index, nr, shift, boundary_size)) {
/* we could do more effectively */
start = index + 1;
This on top of -mm? Or on top of the reverted iommu patch.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
