From rsa at us.ibm.com Thu Apr 1 08:16:37 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 31 Mar 2004 16:16:37 -0600 Subject: [PATCH] proposed changes to hvc_console for interrupt driven console Message-ID: <1080771398.9283.52.camel@SigurRos.rchland.ibm.com> The patch located at: http://www-124.ibm.com/linux/patches/?patch_id=1454 contains proposed changes to the hvc_console device driver. I would appreciate any comments that could be given. This patch adds an interrupt driven console I/O mechanism along side the polling I/O mechanism that is already in place in the hvc_console driver. The interrupt driven mechanism is initialized to execute in place of the polling mechanism if the hardware supports virtual terminal interrupts (i.e. Power5). The polling mechanism will continue to function on legacy hardware. Additionally this patch fixes a latent data loss bug when writing to the driver's tty interface during massive console output. This bug is easily reproducible on Power5 hardware using the HMC's terminal console and a simple "ls -la /dev" output test. There is one nuisance that I'd like some help looking at. I have enabled the "Sleep-inside-spinlock checking" kernel config option. When I boot a kernel with the patched driver I get the following output message in the bootlog even though the console works fine: Debug: sleeping function called from invalid context at mm/slab.c:1931 in_atomic():1, irqs_disabled():1 Call Trace: [c000000000094788] .kmem_cache_alloc+0xb8/0xc0 [c000000000225ae0] .radix_tree_node_alloc+0x2c/0xa4 [c000000000225cf8] .radix_tree_extend+0x74/0xd4 [c000000000225ea0] .radix_tree_insert+0x148/0x15c [c00000000003b5d4] .xics_startup+0x48/0x8c [c0000000000133b4] .setup_irq+0x1e4/0x240 [c0000000000136b8] .request_irq+0x9c/0x124 [c0000000002581e0] .hvc_open+0xfc/0x160 [c00000000023e504] .tty_open+0x318/0x49c [c0000000000c6f80] .chrdev_open+0x224/0x474 [c0000000000b6a08] .dentry_open+0x224/0x38c [c0000000000b67dc] .filp_open+0x70/0x78 [c0000000000b6f9c] .sys_open+0x9c/0xd8 [c00000000000c604] .init+0x110/0x1c8 [c0000000000194ac] .kernel_thread+0x4c/0x68 This seems to be due to requesting an irq inside of hvc_open() [patch line 58]. I request the irq outside of a spinlock and the tty_open() invoking function doesn't hold a spinlock when it calls hvc_open(). So I don't see the problem. Barring resolution of the previous problem I will checked these changes into the Ameslab bitkeeper tree in the near future if there are no comments. The patch is against Linux-2.6.5-rc2-ames kernel source. Ryan S. Arnold IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sfr at canb.auug.org.au Thu Apr 1 11:09:12 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 1 Apr 2004 11:09:12 +1000 Subject: [PATCH] create and use DMA_ERROR_CODE Message-ID: <20040401110912.5893a1a4.sfr@canb.auug.org.au> Hi Anton, First patch of a few ... This creates DMA_ERROR_CODE and uses it everywhere instead of PCI_DMA_ERROR_CODE as we really want the three DMA mapping API's to return a singel error code. Also we now have dma_mapping_error and vio_dma_mapping_error - and this latter and pci_dma_mapping_error both just call the former. Also a small fix in the vscsi - dma_map_sg returns 0 to indicate an error. This is relative to today's Ameslab tree and should be merged in. The relevant peices should also go to Linus. Tested for iSeries ... but "obviously correct" :-) -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- diff -ruN ppc64-2.5-iseries/arch/ppc64/kernel/iommu.c ppc64-2.5-iseries.dma.1/arch/ppc64/kernel/iommu.c --- ppc64-2.5-iseries/arch/ppc64/kernel/iommu.c 2004-03-29 12:04:44.000000000 +1000 +++ ppc64-2.5-iseries.dma.1/arch/ppc64/kernel/iommu.c 2004-04-01 10:35:44.000000000 +1000 @@ -32,6 +32,7 @@ #include #include #include +#include #include #include #include @@ -73,7 +74,7 @@ if (unlikely(npages) == 0) { if (printk_ratelimit()) WARN_ON(1); - return PCI_DMA_ERROR_CODE; + return DMA_ERROR_CODE; } if (handle && *handle) @@ -110,7 +111,7 @@ goto again; } else { /* Third failure, give up */ - return PCI_DMA_ERROR_CODE; + return DMA_ERROR_CODE; } } @@ -144,15 +145,15 @@ unsigned int npages, int direction) { unsigned long entry, flags; - dma_addr_t ret = PCI_DMA_ERROR_CODE; + dma_addr_t ret = DMA_ERROR_CODE; spin_lock_irqsave(&(tbl->it_lock), flags); entry = iommu_range_alloc(tbl, npages, NULL); - if (unlikely(entry == PCI_DMA_ERROR_CODE)) { + if (unlikely(entry == DMA_ERROR_CODE)) { spin_unlock_irqrestore(&(tbl->it_lock), flags); - return PCI_DMA_ERROR_CODE; + return DMA_ERROR_CODE; } entry += tbl->it_offset; /* Offset into real TCE table */ @@ -263,7 +264,7 @@ DBG(" - vaddr: %lx, size: %lx\n", vaddr, slen); /* Handle failure */ - if (unlikely(entry == PCI_DMA_ERROR_CODE)) { + if (unlikely(entry == DMA_ERROR_CODE)) { if (printk_ratelimit()) printk(KERN_INFO "iommu_alloc failed, tbl %p vaddr %lx" " npages %lx\n", tbl, vaddr, npages); @@ -327,7 +328,7 @@ */ if (outcount < nelems) { outs++; - outs->dma_address = PCI_DMA_ERROR_CODE; + outs->dma_address = DMA_ERROR_CODE; outs->dma_length = 0; } return outcount; diff -ruN ppc64-2.5-iseries/arch/ppc64/kernel/pci_iommu.c ppc64-2.5-iseries.dma.1/arch/ppc64/kernel/pci_iommu.c --- ppc64-2.5-iseries/arch/ppc64/kernel/pci_iommu.c 2004-03-23 17:07:56.000000000 +1100 +++ ppc64-2.5-iseries.dma.1/arch/ppc64/kernel/pci_iommu.c 2004-04-01 10:35:06.000000000 +1000 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -82,7 +83,7 @@ if (order >= IOMAP_MAX_ORDER) { printk("PCI_DMA: pci_alloc_consistent size too large: 0x%lx\n", size); - return (void *)PCI_DMA_ERROR_CODE; + return (void *)DMA_ERROR_CODE; } tbl = devnode_table(hwdev); @@ -101,7 +102,7 @@ /* Set up tces to cover the allocated range */ mapping = iommu_alloc(tbl, ret, npages, PCI_DMA_BIDIRECTIONAL); - if (mapping == PCI_DMA_ERROR_CODE) { + if (mapping == DMA_ERROR_CODE) { free_pages((unsigned long)ret, order); ret = NULL; } else @@ -139,7 +140,7 @@ size_t size, int direction) { struct iommu_table * tbl; - dma_addr_t dma_handle = PCI_DMA_ERROR_CODE; + dma_addr_t dma_handle = DMA_ERROR_CODE; unsigned long uaddr; unsigned int npages; @@ -153,7 +154,7 @@ if (tbl) { dma_handle = iommu_alloc(tbl, vaddr, npages, direction); - if (dma_handle == PCI_DMA_ERROR_CODE) { + if (dma_handle == DMA_ERROR_CODE) { if (printk_ratelimit()) { printk(KERN_INFO "iommu_alloc failed, tbl %p vaddr %p npages %d\n", tbl, vaddr, npages); diff -ruN ppc64-2.5-iseries/arch/ppc64/kernel/vio.c ppc64-2.5-iseries.dma.1/arch/ppc64/kernel/vio.c --- ppc64-2.5-iseries/arch/ppc64/kernel/vio.c 2004-03-23 17:07:56.000000000 +1100 +++ ppc64-2.5-iseries.dma.1/arch/ppc64/kernel/vio.c 2004-04-01 10:34:40.000000000 +1000 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -418,7 +419,7 @@ size_t size, int direction ) { struct iommu_table *tbl; - dma_addr_t dma_handle = PCI_DMA_ERROR_CODE; + dma_addr_t dma_handle = DMA_ERROR_CODE; unsigned long uaddr; unsigned int npages; @@ -503,7 +504,7 @@ /* It is easier to debug here for the drivers than in the tce tables.*/ if(order >= IOMAP_MAX_ORDER) { printk("VIO_DMA: vio_alloc_consistent size to large: 0x%lx \n", size); - return (void *)PCI_DMA_ERROR_CODE; + return (void *)DMA_ERROR_CODE; } tbl = dev->iommu_table; @@ -516,7 +517,7 @@ memset(ret, 0, npages << PAGE_SHIFT); /* Set up tces to cover the allocated range */ tce = iommu_alloc(tbl, ret, npages, PCI_DMA_BIDIRECTIONAL); - if (tce == PCI_DMA_ERROR_CODE) { + if (tce == DMA_ERROR_CODE) { PPCDBG(PPCDBG_TCE, "vio_alloc_consistent: iommu_alloc failed\n" ); free_pages((unsigned long)ret, order); ret = NULL; diff -ruN ppc64-2.5-iseries/drivers/net/ibmveth.c ppc64-2.5-iseries.dma.1/drivers/net/ibmveth.c --- ppc64-2.5-iseries/drivers/net/ibmveth.c 2004-04-01 10:04:29.000000000 +1000 +++ ppc64-2.5-iseries.dma.1/drivers/net/ibmveth.c 2004-04-01 10:37:06.000000000 +1000 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -406,7 +407,7 @@ if(adapter->buffer_list_addr != NULL) { if(!pci_dma_mapping_error(adapter->buffer_list_dma)) { vio_unmap_single(adapter->vdev, adapter->buffer_list_dma, 4096, PCI_DMA_BIDIRECTIONAL); - adapter->buffer_list_dma = PCI_DMA_ERROR_CODE; + adapter->buffer_list_dma = DMA_ERROR_CODE; } free_page((unsigned long)adapter->buffer_list_addr); adapter->buffer_list_addr = NULL; @@ -415,7 +416,7 @@ if(adapter->filter_list_addr != NULL) { if(!pci_dma_mapping_error(adapter->filter_list_dma)) { vio_unmap_single(adapter->vdev, adapter->filter_list_dma, 4096, PCI_DMA_BIDIRECTIONAL); - adapter->filter_list_dma = PCI_DMA_ERROR_CODE; + adapter->filter_list_dma = DMA_ERROR_CODE; } free_page((unsigned long)adapter->filter_list_addr); adapter->filter_list_addr = NULL; @@ -424,7 +425,7 @@ if(adapter->rx_queue.queue_addr != NULL) { if(!pci_dma_mapping_error(adapter->rx_queue.queue_dma)) { vio_unmap_single(adapter->vdev, adapter->rx_queue.queue_dma, adapter->rx_queue.queue_len, PCI_DMA_BIDIRECTIONAL); - adapter->rx_queue.queue_dma = PCI_DMA_ERROR_CODE; + adapter->rx_queue.queue_dma = DMA_ERROR_CODE; } kfree(adapter->rx_queue.queue_addr); adapter->rx_queue.queue_addr = NULL; @@ -944,9 +945,9 @@ INIT_WORK(&adapter->replenish_task, (void*)ibmveth_replenish_task, (void*)adapter); - adapter->buffer_list_dma = PCI_DMA_ERROR_CODE; - adapter->filter_list_dma = PCI_DMA_ERROR_CODE; - adapter->rx_queue.queue_dma = PCI_DMA_ERROR_CODE; + adapter->buffer_list_dma = DMA_ERROR_CODE; + adapter->filter_list_dma = DMA_ERROR_CODE; + adapter->rx_queue.queue_dma = DMA_ERROR_CODE; atomic_set(&adapter->not_replenishing, 1); diff -ruN ppc64-2.5-iseries/drivers/scsi/ibmvscsi/ibmvscsi.c ppc64-2.5-iseries.dma.1/drivers/scsi/ibmvscsi/ibmvscsi.c --- ppc64-2.5-iseries/drivers/scsi/ibmvscsi/ibmvscsi.c 2004-04-01 02:04:30.000000000 +1000 +++ ppc64-2.5-iseries.dma.1/drivers/scsi/ibmvscsi/ibmvscsi.c 2004-04-01 11:02:19.000000000 +1000 @@ -66,7 +66,6 @@ * layer. */ -#include /* needed only for pci_dma_mapping_error */ #include #include #include @@ -341,9 +340,10 @@ (struct memory_descriptor *)srp_cmd->additional_data; struct indirect_descriptor *indirect = (struct indirect_descriptor *)data; + sg_mapped = dma_map_sg(dev, sg, cmd->use_sg, DMA_BIDIRECTIONAL); - if (pci_dma_mapping_error(sg_dma_address(&sg[0]))) + if (sg_mapped == 0) return 0; /* special case; we can use a single direct descriptor */ @@ -407,7 +407,7 @@ (u64) (unsigned long)dma_map_single(dev, cmd->request_buffer, cmd->request_bufflen, DMA_BIDIRECTIONAL); - if (pci_dma_mapping_error(data->virtual_address)) { + if (dma_mapping_error(data->virtual_address)) { printk(KERN_ERR "ibmvscsi: Unable to map request_buffer for command!\n"); return 0; @@ -690,7 +690,7 @@ &hostdata->madapter_info, sizeof(hostdata->madapter_info), DMA_BIDIRECTIONAL); - if (pci_dma_mapping_error(req.buffer)) { + if (dma_mapping_error(req.buffer)) { printk(KERN_ERR "ibmvscsi: Unable to map request_buffer " "for adapter_info!\n"); @@ -1075,7 +1075,7 @@ host_config.buffer = dma_map_single(hostdata->dev, buffer, length, DMA_BIDIRECTIONAL); - if (pci_dma_mapping_error(host_config.buffer)) { + if (dma_mapping_error(host_config.buffer)) { printk(KERN_ERR "ibmvscsi: dma_mapping error " "getting host config\n"); rc = -1; diff -ruN ppc64-2.5-iseries/drivers/scsi/ibmvscsi/ibmvscsis.c ppc64-2.5-iseries.dma.1/drivers/scsi/ibmvscsi/ibmvscsis.c --- ppc64-2.5-iseries/drivers/scsi/ibmvscsi/ibmvscsis.c 2004-03-31 03:04:32.000000000 +1000 +++ ppc64-2.5-iseries.dma.1/drivers/scsi/ibmvscsi/ibmvscsis.c 2004-04-01 10:49:54.000000000 +1000 @@ -1863,7 +1863,7 @@ queue->size * sizeof(*queue->msgs), PCI_DMA_BIDIRECTIONAL); - if (pci_dma_mapping_error(queue->msg_token)) + if (vio_dma_mapping_error(queue->msg_token)) goto map_failed; rc = plpar_hcall_norets(H_REG_CRQ, adapter->dma_dev->unit_address, queue->msg_token, PAGE_SIZE); diff -ruN ppc64-2.5-iseries/drivers/scsi/ibmvscsi/rpa_vscsi.c ppc64-2.5-iseries.dma.1/drivers/scsi/ibmvscsi/rpa_vscsi.c --- ppc64-2.5-iseries/drivers/scsi/ibmvscsi/rpa_vscsi.c 2004-04-01 08:04:30.000000000 +1000 +++ ppc64-2.5-iseries.dma.1/drivers/scsi/ibmvscsi/rpa_vscsi.c 2004-04-01 10:50:43.000000000 +1000 @@ -174,7 +174,7 @@ queue->size * sizeof(*queue->msgs), PCI_DMA_BIDIRECTIONAL); - if (pci_dma_mapping_error(queue->msg_token)) + if (dma_mapping_error(queue->msg_token)) goto map_failed; rc = plpar_hcall_norets(H_REG_CRQ, diff -ruN ppc64-2.5-iseries/include/asm-ppc64/dma-mapping.h ppc64-2.5-iseries.dma.1/include/asm-ppc64/dma-mapping.h --- ppc64-2.5-iseries/include/asm-ppc64/dma-mapping.h 2004-02-24 16:04:33.000000000 +1100 +++ ppc64-2.5-iseries.dma.1/include/asm-ppc64/dma-mapping.h 2004-04-01 10:39:30.000000000 +1000 @@ -15,6 +15,8 @@ #include #include +#define DMA_ERROR_CODE (~(dma_addr_t)0x0) + extern int dma_supported(struct device *dev, u64 mask); extern int dma_set_mask(struct device *dev, u64 dma_mask); extern void *dma_alloc_coherent(struct device *dev, size_t size, @@ -72,4 +74,9 @@ BUG(); } +static inline int dma_mapping_error(dma_addr_t dma_addr) +{ + return (dma_addr == DMA_ERROR_CODE); +} + #endif /* _ASM_DMA_MAPPING_H */ diff -ruN ppc64-2.5-iseries/include/asm-ppc64/pci.h ppc64-2.5-iseries.dma.1/include/asm-ppc64/pci.h --- ppc64-2.5-iseries/include/asm-ppc64/pci.h 2004-03-28 14:04:42.000000000 +1000 +++ ppc64-2.5-iseries.dma.1/include/asm-ppc64/pci.h 2004-04-01 10:40:07.000000000 +1000 @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -169,10 +170,9 @@ return 0; } -#define PCI_DMA_ERROR_CODE (~(dma_addr_t)0x0) static inline int pci_dma_mapping_error(dma_addr_t dma_addr) { - return (dma_addr == PCI_DMA_ERROR_CODE); + return dma_mapping_error(dma_addr); } extern int pci_domain_nr(struct pci_bus *bus); diff -ruN ppc64-2.5-iseries/include/asm-ppc64/vio.h ppc64-2.5-iseries.dma.1/include/asm-ppc64/vio.h --- ppc64-2.5-iseries/include/asm-ppc64/vio.h 2004-03-02 16:04:37.000000000 +1100 +++ ppc64-2.5-iseries.dma.1/include/asm-ppc64/vio.h 2004-04-01 10:42:25.000000000 +1000 @@ -11,13 +11,14 @@ * 2 of the License, or (at your option) any later version. */ -#ifndef _VIO_H -#define _VIO_H +#ifndef _ASM_VIO_H +#define _ASM_VIO_H #include #include #include #include +#include #include #include #include @@ -137,4 +138,9 @@ return container_of(dev, struct vio_dev, dev); } -#endif /* _PHYP_H */ +static inline int vio_dma_mapping_error(dma_addr_t dma_addr) +{ + return dma_mapping_error(dma_addr); +} + +#endif /* _ASM_VIO_H */ From anton at samba.org Thu Apr 1 12:01:01 2004 From: anton at samba.org (Anton Blanchard) Date: Thu, 1 Apr 2004 12:01:01 +1000 Subject: GDB for ppc-64 Message-ID: <20040401020101.GE27453@krispykreme> Hi Paul, Best to cc linuxppc64-dev at lists.linuxppc.org, most of the kernel guys are on that list. > My job is to make sure that GDB runs on ppc-64 linux at least as well as > it runs on the intel chips under linux, if not better. Excellent :) > I am asking you all for help: > 1) Do you know any areas in GDB/ppc-64 that needs attention? I have > some idea, but I would like your 'take'. A number of things spring to mind. Last time I looked through the ppc32 gdb it was using a mix of new and old interfaces. It seemed like a rewrite of the ppc32 parts would be a good idea. Is the ppc64 code based on the existing ppc32 bits? Also there are areas where we could cooperate with gdb to make life easier. The code to detect signal trampolines in gdb is pretty scary (checking for li r0,7777; sc or li r0,NR_SIGRETURN, sc etc). The kernel should really be providing some debug information around the signal trampoline which gdb could parse. I think the x86 signal trampoline code does this in 2.6. If you come up against other things where it really makes sense to fix the kernel, come hassle us. While its not strictly gdb, getting kgdb to work on ppc64 would be nice. Longer term we should also put more debug information into the kernel to make kgdb work better (eg understanding some of our asm code). PS: Is ppc64 gdb merged into upstream yet? Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sfr at canb.auug.org.au Thu Apr 1 12:57:25 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 1 Apr 2004 12:57:25 +1000 Subject: [PATCH] use enum dma_data_direction for vio_ routines Message-ID: <20040401125725.3e8c701d.sfr@canb.auug.org.au> Hi Anton, This patch uses enum dam_data_direction for the vio DMA api routines. This allows us to remove some include of linux/pci.h. Also missed some pci_dam_mapping_error uses. Relative to my previous patch. Please apply to Ameslab (and maybe upstream). More to come ... -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- diff -ruN ppc64-2.5-iseries.dma.1/arch/ppc64/kernel/dma.c ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/dma.c --- ppc64-2.5-iseries.dma.1/arch/ppc64/kernel/dma.c 2004-02-26 16:04:36.000000000 +1100 +++ ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/dma.c 2004-04-01 11:54:07.000000000 +1000 @@ -77,7 +77,7 @@ return pci_map_single(to_pci_dev(dev), cpu_addr, size, (int)direction); #ifdef CONFIG_PPC_PSERIES if (dev->bus == &vio_bus_type) - return vio_map_single(to_vio_dev(dev), cpu_addr, size, (int)direction); + return vio_map_single(to_vio_dev(dev), cpu_addr, size, direction); #endif BUG(); return (dma_addr_t)0; @@ -91,7 +91,7 @@ pci_unmap_single(to_pci_dev(dev), dma_addr, size, (int)direction); #ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) - vio_unmap_single(to_vio_dev(dev), dma_addr, size, (int)direction); + vio_unmap_single(to_vio_dev(dev), dma_addr, size, direction); #endif else BUG(); @@ -106,7 +106,7 @@ return pci_map_page(to_pci_dev(dev), page, offset, size, (int)direction); #ifdef CONFIG_PPC_PSERIES if (dev->bus == &vio_bus_type) - return vio_map_page(to_vio_dev(dev), page, offset, size, (int)direction); + return vio_map_page(to_vio_dev(dev), page, offset, size, direction); #endif BUG(); return (dma_addr_t)0; @@ -120,7 +120,7 @@ pci_unmap_page(to_pci_dev(dev), dma_address, size, (int)direction); #ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) - vio_unmap_page(to_vio_dev(dev), dma_address, size, (int)direction); + vio_unmap_page(to_vio_dev(dev), dma_address, size, direction); #endif else BUG(); @@ -134,7 +134,7 @@ return pci_map_sg(to_pci_dev(dev), sg, nents, (int)direction); #ifdef CONFIG_PPC_PSERIES if (dev->bus == &vio_bus_type) - return vio_map_sg(to_vio_dev(dev), sg, nents, (int)direction); + return vio_map_sg(to_vio_dev(dev), sg, nents, direction); #endif BUG(); return 0; @@ -148,7 +148,7 @@ pci_unmap_sg(to_pci_dev(dev), sg, nhwentries, (int)direction); #ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) - vio_unmap_sg(to_vio_dev(dev), sg, nhwentries, (int)direction); + vio_unmap_sg(to_vio_dev(dev), sg, nhwentries, direction); #endif else BUG(); @@ -162,7 +162,7 @@ pci_dma_sync_single(to_pci_dev(dev), dma_handle, size, (int)direction); #ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) - vio_dma_sync_single(to_vio_dev(dev), dma_handle, size, (int)direction); + vio_dma_sync_single(to_vio_dev(dev), dma_handle, size, direction); #endif else BUG(); @@ -176,7 +176,7 @@ pci_dma_sync_sg(to_pci_dev(dev), sg, nelems, (int)direction); #ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) - vio_dma_sync_sg(to_vio_dev(dev), sg, nelems, (int)direction); + vio_dma_sync_sg(to_vio_dev(dev), sg, nelems, direction); #endif else BUG(); diff -ruN ppc64-2.5-iseries.dma.1/arch/ppc64/kernel/vio.c ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/vio.c --- ppc64-2.5-iseries.dma.1/arch/ppc64/kernel/vio.c 2004-04-01 10:34:40.000000000 +1000 +++ ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/vio.c 2004-04-01 11:59:33.000000000 +1000 @@ -14,7 +14,6 @@ #include #include -#include #include #include #include @@ -416,14 +415,14 @@ dma_addr_t vio_map_single(struct vio_dev *dev, void *vaddr, - size_t size, int direction ) + size_t size, enum dma_data_direction direction) { struct iommu_table *tbl; dma_addr_t dma_handle = DMA_ERROR_CODE; unsigned long uaddr; unsigned int npages; - BUG_ON(direction == PCI_DMA_NONE); + BUG_ON(direction == DMA_NONE); uaddr = (unsigned long)vaddr; npages = PAGE_ALIGN( uaddr + size ) - ( uaddr & PAGE_MASK ); @@ -432,7 +431,7 @@ tbl = dev->iommu_table; if (tbl) { - dma_handle = iommu_alloc(tbl, vaddr, npages, direction); + dma_handle = iommu_alloc(tbl, vaddr, npages, (int)direction); dma_handle |= (uaddr & ~PAGE_MASK); } @@ -441,12 +440,12 @@ EXPORT_SYMBOL(vio_map_single); void vio_unmap_single(struct vio_dev *dev, dma_addr_t dma_handle, - size_t size, int direction) + size_t size, enum dma_data_direction direction) { struct iommu_table * tbl; unsigned int npages; - BUG_ON(direction == PCI_DMA_NONE); + BUG_ON(direction == DMA_NONE); npages = PAGE_ALIGN( dma_handle + size ) - ( dma_handle & PAGE_MASK ); npages >>= PAGE_SHIFT; @@ -458,11 +457,11 @@ EXPORT_SYMBOL(vio_unmap_single); int vio_map_sg(struct vio_dev *vdev, struct scatterlist *sglist, int nelems, - int direction) + enum dma_data_direction direction) { struct iommu_table *tbl; - BUG_ON(direction == PCI_DMA_NONE); + BUG_ON(direction == DMA_NONE); if (nelems == 0) return 0; @@ -471,16 +470,16 @@ if (!tbl) return 0; - return iommu_alloc_sg(tbl, &vdev->dev, sglist, nelems, direction); + return iommu_alloc_sg(tbl, &vdev->dev, sglist, nelems, (int)direction); } EXPORT_SYMBOL(vio_map_sg); void vio_unmap_sg(struct vio_dev *vdev, struct scatterlist *sglist, int nelems, - int direction) + enum dma_data_direction direction) { struct iommu_table *tbl; - BUG_ON(direction == PCI_DMA_NONE); + BUG_ON(direction == DMA_NONE); tbl = vdev->iommu_table; if (tbl) @@ -516,7 +515,7 @@ /* Page allocation succeeded */ memset(ret, 0, npages << PAGE_SHIFT); /* Set up tces to cover the allocated range */ - tce = iommu_alloc(tbl, ret, npages, PCI_DMA_BIDIRECTIONAL); + tce = iommu_alloc(tbl, ret, npages, (int)DMA_BIDIRECTIONAL); if (tce == DMA_ERROR_CODE) { PPCDBG(PPCDBG_TCE, "vio_alloc_consistent: iommu_alloc failed\n" ); free_pages((unsigned long)ret, order); diff -ruN ppc64-2.5-iseries.dma.1/drivers/net/ibmveth.c ppc64-2.5-iseries.dma.2/drivers/net/ibmveth.c --- ppc64-2.5-iseries.dma.1/drivers/net/ibmveth.c 2004-04-01 10:37:06.000000000 +1000 +++ ppc64-2.5-iseries.dma.2/drivers/net/ibmveth.c 2004-04-01 12:03:13.000000000 +1000 @@ -39,7 +39,6 @@ #include #include #include -#include #include #include #include @@ -218,7 +217,7 @@ ibmveth_assert(index != 0xffff); ibmveth_assert(pool->skbuff[index] == NULL); - dma_addr = vio_map_single(adapter->vdev, skb->data, pool->buff_size, PCI_DMA_FROMDEVICE); + dma_addr = vio_map_single(adapter->vdev, skb->data, pool->buff_size, DMA_FROM_DEVICE); pool->dma_addr[index] = dma_addr; pool->skbuff[index] = skb; @@ -236,7 +235,7 @@ if(lpar_rc != H_Success) { pool->skbuff[index] = NULL; pool->consumer_index--; - vio_unmap_single(adapter->vdev, pool->dma_addr[index], pool->buff_size, PCI_DMA_FROMDEVICE); + vio_unmap_single(adapter->vdev, pool->dma_addr[index], pool->buff_size, DMA_FROM_DEVICE); dev_kfree_skb_any(skb); adapter->replenish_add_buff_failure++; break; @@ -300,7 +299,7 @@ vio_unmap_single(adapter->vdev, pool->dma_addr[i], pool->buff_size, - PCI_DMA_FROMDEVICE); + DMA_FROM_DEVICE); dev_kfree_skb_any(skb); pool->skbuff[i] = NULL; } @@ -338,7 +337,7 @@ vio_unmap_single(adapter->vdev, adapter->rx_buff_pool[pool].dma_addr[index], adapter->rx_buff_pool[pool].buff_size, - PCI_DMA_FROMDEVICE); + DMA_FROM_DEVICE); free_index = adapter->rx_buff_pool[pool].producer_index++ % adapter->rx_buff_pool[pool].size; adapter->rx_buff_pool[pool].free_map[free_index] = index; @@ -405,8 +404,8 @@ static void ibmveth_cleanup(struct ibmveth_adapter *adapter) { if(adapter->buffer_list_addr != NULL) { - if(!pci_dma_mapping_error(adapter->buffer_list_dma)) { - vio_unmap_single(adapter->vdev, adapter->buffer_list_dma, 4096, PCI_DMA_BIDIRECTIONAL); + if(!vio_dma_mapping_error(adapter->buffer_list_dma)) { + vio_unmap_single(adapter->vdev, adapter->buffer_list_dma, 4096, DMA_BIDIRECTIONAL); adapter->buffer_list_dma = DMA_ERROR_CODE; } free_page((unsigned long)adapter->buffer_list_addr); @@ -414,8 +413,8 @@ } if(adapter->filter_list_addr != NULL) { - if(!pci_dma_mapping_error(adapter->filter_list_dma)) { - vio_unmap_single(adapter->vdev, adapter->filter_list_dma, 4096, PCI_DMA_BIDIRECTIONAL); + if(!vio_dma_mapping_error(adapter->filter_list_dma)) { + vio_unmap_single(adapter->vdev, adapter->filter_list_dma, 4096, DMA_BIDIRECTIONAL); adapter->filter_list_dma = DMA_ERROR_CODE; } free_page((unsigned long)adapter->filter_list_addr); @@ -423,8 +422,8 @@ } if(adapter->rx_queue.queue_addr != NULL) { - if(!pci_dma_mapping_error(adapter->rx_queue.queue_dma)) { - vio_unmap_single(adapter->vdev, adapter->rx_queue.queue_dma, adapter->rx_queue.queue_len, PCI_DMA_BIDIRECTIONAL); + if(!vio_dma_mapping_error(adapter->rx_queue.queue_dma)) { + vio_unmap_single(adapter->vdev, adapter->rx_queue.queue_dma, adapter->rx_queue.queue_len, DMA_BIDIRECTIONAL); adapter->rx_queue.queue_dma = DMA_ERROR_CODE; } kfree(adapter->rx_queue.queue_addr); @@ -470,13 +469,13 @@ return -ENOMEM; } - adapter->buffer_list_dma = vio_map_single(adapter->vdev, adapter->buffer_list_addr, 4096, PCI_DMA_BIDIRECTIONAL); - adapter->filter_list_dma = vio_map_single(adapter->vdev, adapter->filter_list_addr, 4096, PCI_DMA_BIDIRECTIONAL); - adapter->rx_queue.queue_dma = vio_map_single(adapter->vdev, adapter->rx_queue.queue_addr, adapter->rx_queue.queue_len, PCI_DMA_BIDIRECTIONAL); - - if((pci_dma_mapping_error(adapter->buffer_list_dma) ) || - (pci_dma_mapping_error(adapter->filter_list_dma)) || - (pci_dma_mapping_error(adapter->rx_queue.queue_dma))) { + adapter->buffer_list_dma = vio_map_single(adapter->vdev, adapter->buffer_list_addr, 4096, DMA_BIDIRECTIONAL); + adapter->filter_list_dma = vio_map_single(adapter->vdev, adapter->filter_list_addr, 4096, DMA_BIDIRECTIONAL); + adapter->rx_queue.queue_dma = vio_map_single(adapter->vdev, adapter->rx_queue.queue_addr, adapter->rx_queue.queue_len, DMA_BIDIRECTIONAL); + + if((vio_dma_mapping_error(adapter->buffer_list_dma) ) || + (vio_dma_mapping_error(adapter->filter_list_dma)) || + (vio_dma_mapping_error(adapter->rx_queue.queue_dma))) { ibmveth_error_printk("unable to map filter or buffer list pages\n"); ibmveth_cleanup(adapter); return -ENOMEM; @@ -642,10 +641,10 @@ /* map the initial fragment */ desc[0].fields.length = nfrags ? skb->len - skb->data_len : skb->len; - desc[0].fields.address = vio_map_single(adapter->vdev, skb->data, desc[0].fields.length, PCI_DMA_TODEVICE); + desc[0].fields.address = vio_map_single(adapter->vdev, skb->data, desc[0].fields.length, DMA_TO_DEVICE); desc[0].fields.valid = 1; - if(pci_dma_mapping_error(desc[0].fields.address)) { + if(vio_dma_mapping_error(desc[0].fields.address)) { ibmveth_error_printk("tx: unable to map initial fragment\n"); adapter->tx_map_failed++; adapter->stats.tx_dropped++; @@ -660,11 +659,11 @@ skb_frag_t *frag = &skb_shinfo(skb)->frags[curfrag]; desc[curfrag+1].fields.address = vio_map_single(adapter->vdev, page_address(frag->page) + frag->page_offset, - frag->size, PCI_DMA_TODEVICE); + frag->size, DMA_TO_DEVICE); desc[curfrag+1].fields.length = frag->size; desc[curfrag+1].fields.valid = 1; - if(pci_dma_mapping_error(desc[curfrag+1].fields.address)) { + if(vio_dma_mapping_error(desc[curfrag+1].fields.address)) { ibmveth_error_printk("tx: unable to map fragment %d\n", curfrag); adapter->tx_map_failed++; adapter->stats.tx_dropped++; @@ -673,7 +672,7 @@ vio_unmap_single(adapter->vdev, desc[curfrag+1].fields.address, desc[curfrag+1].fields.length, - PCI_DMA_TODEVICE); + DMA_TO_DEVICE); curfrag++; } dev_kfree_skb(skb); @@ -710,7 +709,7 @@ } do { - vio_unmap_single(adapter->vdev, desc[nfrags].fields.address, desc[nfrags].fields.length, PCI_DMA_TODEVICE); + vio_unmap_single(adapter->vdev, desc[nfrags].fields.address, desc[nfrags].fields.length, DMA_TO_DEVICE); } while(--nfrags >= 0); dev_kfree_skb(skb); diff -ruN ppc64-2.5-iseries.dma.1/drivers/scsi/ibmvscsi/ibmvscsis.c ppc64-2.5-iseries.dma.2/drivers/scsi/ibmvscsi/ibmvscsis.c --- ppc64-2.5-iseries.dma.1/drivers/scsi/ibmvscsi/ibmvscsis.c 2004-04-01 10:49:54.000000000 +1000 +++ ppc64-2.5-iseries.dma.2/drivers/scsi/ibmvscsi/ibmvscsis.c 2004-04-01 11:57:41.000000000 +1000 @@ -39,7 +39,6 @@ #include #include #include -#include #include #include #include @@ -1861,7 +1860,7 @@ queue->msg_token = vio_map_single(adapter->dma_dev, queue->msgs, queue->size * sizeof(*queue->msgs), - PCI_DMA_BIDIRECTIONAL); + DMA_BIDIRECTIONAL); if (vio_dma_mapping_error(queue->msg_token)) goto map_failed; @@ -1891,7 +1890,7 @@ req_irq_failed: plpar_hcall_norets(H_FREE_CRQ, adapter->dma_dev->unit_address); reg_crq_failed: - vio_unmap_single(adapter->dma_dev, queue->msg_token, queue->size * sizeof(*queue->msgs), PCI_DMA_BIDIRECTIONAL); + vio_unmap_single(adapter->dma_dev, queue->msg_token, queue->size * sizeof(*queue->msgs), DMA_BIDIRECTIONAL); map_failed: free_page((unsigned long)queue->msgs); malloc_failed: @@ -1906,7 +1905,7 @@ info("releasing crq\n"); free_irq(adapter->dma_dev->irq, adapter); plpar_hcall_norets(H_FREE_CRQ, adapter->dma_dev->unit_address); - vio_unmap_single(adapter->dma_dev, queue->msg_token, queue->size * sizeof(*queue->msgs), PCI_DMA_BIDIRECTIONAL); + vio_unmap_single(adapter->dma_dev, queue->msg_token, queue->size * sizeof(*queue->msgs), DMA_BIDIRECTIONAL); free_page((unsigned long)queue->msgs); } diff -ruN ppc64-2.5-iseries.dma.1/drivers/scsi/ibmvscsi/rpa_vscsi.c ppc64-2.5-iseries.dma.2/drivers/scsi/ibmvscsi/rpa_vscsi.c --- ppc64-2.5-iseries.dma.1/drivers/scsi/ibmvscsi/rpa_vscsi.c 2004-04-01 10:50:43.000000000 +1000 +++ ppc64-2.5-iseries.dma.2/drivers/scsi/ibmvscsi/rpa_vscsi.c 2004-04-01 12:05:10.000000000 +1000 @@ -78,7 +78,7 @@ dma_unmap_single(hostdata->dev, queue->msg_token, queue->size * sizeof(*queue->msgs), - PCI_DMA_BIDIRECTIONAL); + DMA_BIDIRECTIONAL); free_page((unsigned long)queue->msgs); } @@ -172,7 +172,7 @@ queue->msg_token = dma_map_single(hostdata->dev, queue->msgs, queue->size * sizeof(*queue->msgs), - PCI_DMA_BIDIRECTIONAL); + DMA_BIDIRECTIONAL); if (dma_mapping_error(queue->msg_token)) goto map_failed; @@ -217,7 +217,7 @@ dma_unmap_single(hostdata->dev, queue->msg_token, queue->size * sizeof(*queue->msgs), - PCI_DMA_BIDIRECTIONAL); + DMA_BIDIRECTIONAL); map_failed: free_page((unsigned long)queue->msgs); malloc_failed: diff -ruN ppc64-2.5-iseries.dma.1/include/asm-ppc64/vio.h ppc64-2.5-iseries.dma.2/include/asm-ppc64/vio.h --- ppc64-2.5-iseries.dma.1/include/asm-ppc64/vio.h 2004-04-01 10:42:25.000000000 +1000 +++ ppc64-2.5-iseries.dma.2/include/asm-ppc64/vio.h 2004-04-01 11:48:29.000000000 +1000 @@ -17,7 +17,6 @@ #include #include #include -#include #include #include #include @@ -58,13 +57,13 @@ int vio_disable_interrupts(struct vio_dev *dev); dma_addr_t vio_map_single(struct vio_dev *dev, void *vaddr, - size_t size, int direction); + size_t size, enum dma_data_direction direction); void vio_unmap_single(struct vio_dev *dev, dma_addr_t dma_handle, - size_t size, int direction); + size_t size, enum dma_data_direction direction); int vio_map_sg(struct vio_dev *vdev, struct scatterlist *sglist, - int nelems, int direction); + int nelems, enum dma_data_direction direction); void vio_unmap_sg(struct vio_dev *vdev, struct scatterlist *sglist, - int nelems, int direction); + int nelems, enum dma_data_direction direction); void *vio_alloc_consistent(struct vio_dev *dev, size_t size, dma_addr_t *dma_handle); void vio_free_consistent(struct vio_dev *dev, size_t size, void *vaddr, @@ -81,18 +80,18 @@ static inline void vio_dma_sync_single(struct vio_dev *hwdev, - dma_addr_t dma_handle, - size_t size, int direction) + dma_addr_t dma_handle, size_t size, + enum dma_data_direction direction) { - BUG_ON(direction == PCI_DMA_NONE); + BUG_ON(direction == DMA_NONE); /* nothing to do */ } static inline void vio_dma_sync_sg(struct vio_dev *hwdev, - struct scatterlist *sg, - int nelems, int direction) + struct scatterlist *sg, int nelems, + enum dma_data_direction direction) { - BUG_ON(direction == PCI_DMA_NONE); + BUG_ON(direction == DMA_NONE); /* nothing to do */ } static inline int vio_set_dma_mask(struct vio_dev *dev, u64 mask) { return -EIO; } From sfr at canb.auug.org.au Thu Apr 1 14:02:15 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 1 Apr 2004 14:02:15 +1000 Subject: [PATCH] use enum dma_data_direction for everything except generic pci_dma routines Message-ID: <20040401140215.093f64be.sfr@canb.auug.org.au> Hi Anton, This is just a clenaup to use enum dma_data_direction for all APIs except the pci_dma_ ones (since they are defined generically). Also make most of the functions in arch/ppc64/kernel/pci_iommu.c static. Relative to previous patches. Built and booted on iSeries, build for default pSeries config, not tested for pmac. Let me know when I go to far ... :-) -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- diff -ruN ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/iSeries_iommu.c ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/iSeries_iommu.c --- ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/iSeries_iommu.c 2004-03-30 12:04:37.000000000 +1000 +++ ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/iSeries_iommu.c 2004-04-01 13:25:10.000000000 +1000 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -69,7 +70,7 @@ static void tce_build_iSeries(struct iommu_table *tbl, long index, long npages, - unsigned long uaddr, int direction) + unsigned long uaddr, enum dma_data_direction direction) { u64 rc; union tce_entry tce; @@ -82,12 +83,12 @@ /* Virtual Bus */ tce.te_bits.tb_valid = 1; tce.te_bits.tb_allio = 1; - if (direction != PCI_DMA_TODEVICE) + if (direction != DMA_TO_DEVICE) tce.te_bits.tb_rdwr = 1; } else { /* PCI Bus */ tce.te_bits.tb_rdwr = 1; /* Read allowed */ - if (direction != PCI_DMA_TODEVICE) + if (direction != DMA_TO_DEVICE) tce.te_bits.tb_pciwr = 1; } diff -ruN ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/iommu.c ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/iommu.c --- ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/iommu.c 2004-04-01 10:35:44.000000000 +1000 +++ ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/iommu.c 2004-04-01 13:19:08.000000000 +1000 @@ -31,7 +31,6 @@ #include #include #include -#include #include #include #include @@ -142,7 +141,7 @@ } dma_addr_t iommu_alloc(struct iommu_table *tbl, void *page, - unsigned int npages, int direction) + unsigned int npages, enum dma_data_direction direction) { unsigned long entry, flags; dma_addr_t ret = DMA_ERROR_CODE; @@ -227,7 +226,8 @@ } int iommu_alloc_sg(struct iommu_table *tbl, struct device *dev, - struct scatterlist *sglist, int nelems, int direction) + struct scatterlist *sglist, int nelems, + enum dma_data_direction direction) { dma_addr_t dma_next, dma_addr; unsigned long flags; diff -ruN ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/pSeries_iommu.c ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pSeries_iommu.c --- ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/pSeries_iommu.c 2004-03-30 12:04:37.000000000 +1000 +++ ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pSeries_iommu.c 2004-04-01 13:26:11.000000000 +1000 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -46,7 +47,7 @@ static void tce_build_pSeries(struct iommu_table *tbl, long index, long npages, unsigned long uaddr, - int direction) + enum dma_data_direction direction) { union tce_entry t; union tce_entry *tp; @@ -54,7 +55,7 @@ t.te_word = 0; t.te_rdwr = 1; // Read allowed - if (direction != PCI_DMA_TODEVICE) + if (direction != DMA_TO_DEVICE) t.te_pciwr = 1; tp = ((union tce_entry *)tbl->it_base) + index; diff -ruN ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/pSeries_lpar.c ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pSeries_lpar.c --- ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/pSeries_lpar.c 2004-03-30 12:04:37.000000000 +1000 +++ ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pSeries_lpar.c 2004-04-01 13:23:32.000000000 +1000 @@ -21,6 +21,7 @@ #include #include +#include #include #include #include @@ -30,7 +31,6 @@ #include #include #include -#include #include #include #include @@ -129,8 +129,9 @@ lbuf[1]); } -static void tce_build_pSeriesLP(struct iommu_table *tbl, long tcenum, long npages, - unsigned long uaddr, int direction ) +static void tce_build_pSeriesLP(struct iommu_table *tbl, long tcenum, + long npages, unsigned long uaddr, + enum dma_data_direction direction) { u64 rc; union tce_entry tce; @@ -138,7 +139,7 @@ tce.te_word = 0; tce.te_rpn = (virt_to_abs(uaddr)) >> PAGE_SHIFT; tce.te_rdwr = 1; - if (direction != PCI_DMA_TODEVICE) + if (direction != DMA_TO_DEVICE) tce.te_pciwr = 1; while (npages--) { diff -ruN ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/pci_dma_direct.c ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pci_dma_direct.c --- ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/pci_dma_direct.c 2004-03-30 12:04:37.000000000 +1000 +++ ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pci_dma_direct.c 2004-04-01 13:50:24.000000000 +1000 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include @@ -49,18 +50,18 @@ } static dma_addr_t pci_direct_map_single(struct pci_dev *hwdev, void *ptr, - size_t size, int direction) + size_t size, enum dma_data_direction direction) { return virt_to_abs(ptr); } static void pci_direct_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr, - size_t size, int direction) + size_t size, enum dma_data_direction direction) { } static int pci_direct_map_sg(struct pci_dev *hwdev, struct scatterlist *sg, - int nents, int direction) + int nents, enum dma_data_direction direction) { int i; @@ -73,7 +74,7 @@ } static void pci_direct_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, - int nents, int direction) + int nents, enum dma_data_direction direction) { } diff -ruN ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/pci_iommu.c ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pci_iommu.c --- ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/pci_iommu.c 2004-04-01 10:35:06.000000000 +1000 +++ ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pci_iommu.c 2004-04-01 13:53:18.000000000 +1000 @@ -66,7 +66,7 @@ * Returns the virtual address of the buffer and sets dma_handle * to the dma address (mapping) of the first page. */ -void *pci_iommu_alloc_consistent(struct pci_dev *hwdev, size_t size, +static void *pci_iommu_alloc_consistent(struct pci_dev *hwdev, size_t size, dma_addr_t *dma_handle) { struct iommu_table *tbl; @@ -100,7 +100,7 @@ memset(ret, 0, size); /* Set up tces to cover the allocated range */ - mapping = iommu_alloc(tbl, ret, npages, PCI_DMA_BIDIRECTIONAL); + mapping = iommu_alloc(tbl, ret, npages, DMA_BIDIRECTIONAL); if (mapping == DMA_ERROR_CODE) { free_pages((unsigned long)ret, order); @@ -112,7 +112,7 @@ } -void pci_iommu_free_consistent(struct pci_dev *hwdev, size_t size, +static void pci_iommu_free_consistent(struct pci_dev *hwdev, size_t size, void *vaddr, dma_addr_t dma_handle) { struct iommu_table *tbl; @@ -136,15 +136,15 @@ * need not be page aligned, the dma_addr_t returned will point to the same * byte within the page as vaddr. */ -dma_addr_t pci_iommu_map_single(struct pci_dev *hwdev, void *vaddr, - size_t size, int direction) +static dma_addr_t pci_iommu_map_single(struct pci_dev *hwdev, void *vaddr, + size_t size, enum dma_data_direction direction) { struct iommu_table * tbl; dma_addr_t dma_handle = DMA_ERROR_CODE; unsigned long uaddr; unsigned int npages; - BUG_ON(direction == PCI_DMA_NONE); + BUG_ON(direction == DMA_NONE); uaddr = (unsigned long)vaddr; npages = PAGE_ALIGN(uaddr + size) - (uaddr & PAGE_MASK); @@ -167,13 +167,13 @@ } -void pci_iommu_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_handle, - size_t size, int direction) +static void pci_iommu_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_handle, + size_t size, enum dma_data_direction direction) { struct iommu_table *tbl; unsigned int npages; - BUG_ON(direction == PCI_DMA_NONE); + BUG_ON(direction == DMA_NONE); npages = (PAGE_ALIGN(dma_handle + size) - (dma_handle & PAGE_MASK)) >> PAGE_SHIFT; @@ -185,12 +185,12 @@ } -int pci_iommu_map_sg(struct pci_dev *pdev, struct scatterlist *sglist, int nelems, - int direction) +static int pci_iommu_map_sg(struct pci_dev *pdev, struct scatterlist *sglist, + int nelems, enum dma_data_direction direction) { struct iommu_table * tbl; - BUG_ON(direction == PCI_DMA_NONE); + BUG_ON(direction == DMA_NONE); if (nelems == 0) return 0; @@ -202,12 +202,12 @@ return iommu_alloc_sg(tbl, &pdev->dev, sglist, nelems, direction); } -void pci_iommu_unmap_sg(struct pci_dev *pdev, struct scatterlist *sglist, int nelems, - int direction) +static void pci_iommu_unmap_sg(struct pci_dev *pdev, struct scatterlist *sglist, + int nelems, enum dma_data_direction direction) { struct iommu_table *tbl; - BUG_ON(direction == PCI_DMA_NONE); + BUG_ON(direction == DMA_NONE); tbl = devnode_table(pdev); if (!tbl) diff -ruN ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/pmac_iommu.c ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pmac_iommu.c --- ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/pmac_iommu.c 2004-03-30 12:04:37.000000000 +1000 +++ ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pmac_iommu.c 2004-04-01 13:27:45.000000000 +1000 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -141,7 +142,7 @@ static void dart_build_pmac(struct iommu_table *tbl, long index, long npages, unsigned long uaddr, - int direction) + enum dma_data_direction direction) { unsigned int *dp; unsigned int rpn; diff -ruN ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/vio.c ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/vio.c --- ppc64-2.5-iseries.dma.2/arch/ppc64/kernel/vio.c 2004-04-01 11:59:33.000000000 +1000 +++ ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/vio.c 2004-04-01 13:13:53.000000000 +1000 @@ -431,7 +431,7 @@ tbl = dev->iommu_table; if (tbl) { - dma_handle = iommu_alloc(tbl, vaddr, npages, (int)direction); + dma_handle = iommu_alloc(tbl, vaddr, npages, direction); dma_handle |= (uaddr & ~PAGE_MASK); } @@ -470,7 +470,7 @@ if (!tbl) return 0; - return iommu_alloc_sg(tbl, &vdev->dev, sglist, nelems, (int)direction); + return iommu_alloc_sg(tbl, &vdev->dev, sglist, nelems, direction); } EXPORT_SYMBOL(vio_map_sg); @@ -515,7 +515,7 @@ /* Page allocation succeeded */ memset(ret, 0, npages << PAGE_SHIFT); /* Set up tces to cover the allocated range */ - tce = iommu_alloc(tbl, ret, npages, (int)DMA_BIDIRECTIONAL); + tce = iommu_alloc(tbl, ret, npages, DMA_BIDIRECTIONAL); if (tce == DMA_ERROR_CODE) { PPCDBG(PPCDBG_TCE, "vio_alloc_consistent: iommu_alloc failed\n" ); free_pages((unsigned long)ret, order); diff -ruN ppc64-2.5-iseries.dma.2/include/asm-ppc64/iommu.h ppc64-2.5-iseries.dma.3/include/asm-ppc64/iommu.h --- ppc64-2.5-iseries.dma.2/include/asm-ppc64/iommu.h 2004-03-23 17:07:56.000000000 +1100 +++ ppc64-2.5-iseries.dma.3/include/asm-ppc64/iommu.h 2004-04-01 13:20:43.000000000 +1000 @@ -25,6 +25,7 @@ #include #include #include +#include /* * IOMAP_MAX_ORDER defines the largest contiguous block @@ -132,14 +133,15 @@ /* allocates a range of tces and sets them to the pages */ extern dma_addr_t iommu_alloc(struct iommu_table *, void *page, - unsigned int numPages, int direction); + unsigned int numPages, + enum dma_data_direction direction); extern void iommu_free(struct iommu_table *tbl, dma_addr_t dma_addr, unsigned int npages); /* same with sg lists */ extern int iommu_alloc_sg(struct iommu_table *table, struct device *dev, struct scatterlist *sglist, int nelems, - int direction); + enum dma_data_direction direction); extern void iommu_free_sg(struct iommu_table *tbl, struct scatterlist *sglist, int nelems); diff -ruN ppc64-2.5-iseries.dma.2/include/asm-ppc64/machdep.h ppc64-2.5-iseries.dma.3/include/asm-ppc64/machdep.h --- ppc64-2.5-iseries.dma.2/include/asm-ppc64/machdep.h 2004-03-23 17:07:56.000000000 +1100 +++ ppc64-2.5-iseries.dma.3/include/asm-ppc64/machdep.h 2004-04-01 13:28:36.000000000 +1000 @@ -12,6 +12,7 @@ #include #include #include +#include struct pt_regs; struct pci_bus; @@ -58,7 +59,7 @@ long index, long npages, unsigned long uaddr, - int direction); + enum dma_data_direction direction); void (*tce_free)(struct iommu_table *tbl, long index, long npages); diff -ruN ppc64-2.5-iseries.dma.2/include/asm-ppc64/pci-bridge.h ppc64-2.5-iseries.dma.3/include/asm-ppc64/pci-bridge.h --- ppc64-2.5-iseries.dma.2/include/asm-ppc64/pci-bridge.h 2004-02-12 23:04:44.000000000 +1100 +++ ppc64-2.5-iseries.dma.3/include/asm-ppc64/pci-bridge.h 2004-04-01 13:30:51.000000000 +1000 @@ -2,6 +2,8 @@ #ifndef _ASM_PCI_BRIDGE_H #define _ASM_PCI_BRIDGE_H +#include + /* * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License diff -ruN ppc64-2.5-iseries.dma.2/include/asm-ppc64/pci.h ppc64-2.5-iseries.dma.3/include/asm-ppc64/pci.h --- ppc64-2.5-iseries.dma.2/include/asm-ppc64/pci.h 2004-04-01 10:40:07.000000000 +1000 +++ ppc64-2.5-iseries.dma.3/include/asm-ppc64/pci.h 2004-04-01 13:48:08.000000000 +1000 @@ -64,13 +64,13 @@ void *vaddr, dma_addr_t dma_handle); dma_addr_t (*pci_map_single)(struct pci_dev *hwdev, void *ptr, - size_t size, int direction); + size_t size, enum dma_data_direction direction); void (*pci_unmap_single)(struct pci_dev *hwdev, dma_addr_t dma_addr, - size_t size, int direction); + size_t size, enum dma_data_direction direction); int (*pci_map_sg)(struct pci_dev *hwdev, struct scatterlist *sg, - int nents, int direction); + int nents, enum dma_data_direction direction); void (*pci_unmap_sg)(struct pci_dev *hwdev, struct scatterlist *sg, - int nents, int direction); + int nents, enum dma_data_direction direction); int (*pci_dma_supported)(struct pci_dev *hwdev, u64 mask); int (*pci_dac_dma_supported)(struct pci_dev *hwdev, u64 mask); }; @@ -92,25 +92,29 @@ static inline dma_addr_t pci_map_single(struct pci_dev *hwdev, void *ptr, size_t size, int direction) { - return pci_dma_ops.pci_map_single(hwdev, ptr, size, direction); + return pci_dma_ops.pci_map_single(hwdev, ptr, size, + (enum dma_data_direction)direction); } static inline void pci_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr, size_t size, int direction) { - pci_dma_ops.pci_unmap_single(hwdev, dma_addr, size, direction); + pci_dma_ops.pci_unmap_single(hwdev, dma_addr, size, + (enum dma_data_direction)direction); } static inline int pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg, int nents, int direction) { - return pci_dma_ops.pci_map_sg(hwdev, sg, nents, direction); + return pci_dma_ops.pci_map_sg(hwdev, sg, nents, + (enum dma_data_direction)direction); } static inline void pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, int nents, int direction) { - pci_dma_ops.pci_unmap_sg(hwdev, sg, nents, direction); + pci_dma_ops.pci_unmap_sg(hwdev, sg, nents, + (enum dma_data_direction)direction); } static inline void pci_dma_sync_single_for_cpu(struct pci_dev *hwdev, From sfr at canb.auug.org.au Thu Apr 1 16:48:38 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 1 Apr 2004 16:48:38 +1000 Subject: [PATCH] consolidate some of the dma mapping routines Message-ID: <20040401164838.7474ae2b.sfr@canb.auug.org.au> Hi Anton, This patch consolidates some of the iommu DMA mapping routines. Relative to my previous patches. Please apply to Ameslab and consider for upstream. I have built and booted this on iSeries and built it on pSeries and pmac (default configs). -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- diff -ruN ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/iommu.c ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/iommu.c --- ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/iommu.c 2004-04-01 16:46:30.000000000 +1000 +++ ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/iommu.c 2004-04-01 16:19:47.000000000 +1000 @@ -140,7 +140,7 @@ return n; } -dma_addr_t iommu_alloc(struct iommu_table *tbl, void *page, +static dma_addr_t iommu_alloc(struct iommu_table *tbl, void *page, unsigned int npages, enum dma_data_direction direction) { unsigned long entry, flags; @@ -206,7 +206,7 @@ __clear_bit(free_entry+i, tbl->it_map); } -void iommu_free(struct iommu_table *tbl, dma_addr_t dma_addr, +static void iommu_free(struct iommu_table *tbl, dma_addr_t dma_addr, unsigned int npages) { unsigned long flags; @@ -225,9 +225,9 @@ spin_unlock_irqrestore(&(tbl->it_lock), flags); } -int iommu_alloc_sg(struct iommu_table *tbl, struct device *dev, - struct scatterlist *sglist, int nelems, - enum dma_data_direction direction) +int iommu_map_sg(struct device *dev, struct iommu_table *tbl, + struct scatterlist *sglist, int nelems, + enum dma_data_direction direction) { dma_addr_t dma_next, dma_addr; unsigned long flags; @@ -235,6 +235,11 @@ int outcount; unsigned long handle; + BUG_ON(direction == DMA_NONE); + + if ((nelems == 0) || !tbl) + return 0; + outs = s = segstart = &sglist[0]; outcount = 1; handle = 0; @@ -349,11 +354,16 @@ } -void iommu_free_sg(struct iommu_table *tbl, struct scatterlist *sglist, - int nelems) +void iommu_unmap_sg(struct iommu_table *tbl, struct scatterlist *sglist, + int nelems, enum dma_data_direction direction) { unsigned long flags; + BUG_ON(direction == DMA_NONE); + + if (!tbl) + return; + spin_lock_irqsave(&(tbl->it_lock), flags); while (nelems--) { @@ -414,3 +424,104 @@ return tbl; } + +/* Creates TCEs for a user provided buffer. The user buffer must be + * contiguous real kernel storage (not vmalloc). The address of the buffer + * passed here is the kernel (virtual) address of the buffer. The buffer + * need not be page aligned, the dma_addr_t returned will point to the same + * byte within the page as vaddr. + */ +dma_addr_t iommu_map_single(struct iommu_table *tbl, void *vaddr, + size_t size, enum dma_data_direction direction) +{ + dma_addr_t dma_handle = DMA_ERROR_CODE; + unsigned long uaddr; + unsigned int npages; + + BUG_ON(direction == DMA_NONE); + + uaddr = (unsigned long)vaddr; + npages = PAGE_ALIGN(uaddr + size) - (uaddr & PAGE_MASK); + npages >>= PAGE_SHIFT; + + if (tbl) { + dma_handle = iommu_alloc(tbl, vaddr, npages, direction); + if (dma_handle == DMA_ERROR_CODE) { + if (printk_ratelimit()) { + printk(KERN_INFO "iommu_alloc failed, " + "tbl %p vaddr %p npages %d\n", + tbl, vaddr, npages); + } + } else + dma_handle |= (uaddr & ~PAGE_MASK); + } + + return dma_handle; +} + +void iommu_unmap_single(struct iommu_table *tbl, dma_addr_t dma_handle, + size_t size, enum dma_data_direction direction) +{ + BUG_ON(direction == DMA_NONE); + + if (tbl) + iommu_free(tbl, dma_handle, (PAGE_ALIGN(dma_handle + size) - + (dma_handle & PAGE_MASK)) >> PAGE_SHIFT); +} + +/* Allocates a contiguous real buffer and creates mappings over it. + * Returns the virtual address of the buffer and sets dma_handle + * to the dma address (mapping) of the first page. + */ +void *iommu_alloc_consistent(struct iommu_table *tbl, size_t size, + dma_addr_t *dma_handle) +{ + void *ret = NULL; + dma_addr_t mapping; + unsigned int npages, order; + + size = PAGE_ALIGN(size); + npages = size >> PAGE_SHIFT; + order = get_order(size); + + /* + * Client asked for way too much space. This is checked later + * anyway. It is easier to debug here for the drivers than in + * the tce tables. + */ + if (order >= IOMAP_MAX_ORDER) { + printk("iommu_alloc_consistent size too large: 0x%lx\n", size); + return (void *)DMA_ERROR_CODE; + } + + if (!tbl) + return NULL; + + /* Alloc enough pages (and possibly more) */ + ret = (void *)__get_free_pages(GFP_ATOMIC, order); + if (!ret) + return NULL; + memset(ret, 0, size); + + /* Set up tces to cover the allocated range */ + mapping = iommu_alloc(tbl, ret, npages, DMA_BIDIRECTIONAL); + if (mapping == DMA_ERROR_CODE) { + free_pages((unsigned long)ret, order); + ret = NULL; + } else + *dma_handle = mapping; + return ret; +} + +void iommu_free_consistent(struct iommu_table *tbl, size_t size, + void *vaddr, dma_addr_t dma_handle) +{ + unsigned int npages; + + if (tbl) { + size = PAGE_ALIGN(size); + npages = size >> PAGE_SHIFT; + iommu_free(tbl, dma_handle, npages); + free_pages((unsigned long)vaddr, get_order(size)); + } +} diff -ruN ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pci_iommu.c ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/pci_iommu.c --- ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/pci_iommu.c 2004-04-01 16:46:30.000000000 +1000 +++ ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/pci_iommu.c 2004-04-01 16:26:03.000000000 +1000 @@ -43,8 +43,6 @@ #include #endif /* CONFIG_PPC_ISERIES */ -#define DBG(...) - static inline struct iommu_table *devnode_table(struct pci_dev *dev) { if (!dev) @@ -69,64 +67,14 @@ static void *pci_iommu_alloc_consistent(struct pci_dev *hwdev, size_t size, dma_addr_t *dma_handle) { - struct iommu_table *tbl; - void *ret = NULL; - dma_addr_t mapping; - unsigned int npages, order; - - size = PAGE_ALIGN(size); - npages = size >> PAGE_SHIFT; - order = get_order(size); - - /* Client asked for way too much space. This is checked later anyway */ - /* It is easier to debug here for the drivers than in the tce tables.*/ - if (order >= IOMAP_MAX_ORDER) { - printk("PCI_DMA: pci_alloc_consistent size too large: 0x%lx\n", - size); - return (void *)DMA_ERROR_CODE; - } - - tbl = devnode_table(hwdev); - - if (!tbl) - return NULL; - - /* Alloc enough pages (and possibly more) */ - ret = (void *)__get_free_pages(GFP_ATOMIC, order); - - if (!ret) - return NULL; - - memset(ret, 0, size); - - /* Set up tces to cover the allocated range */ - mapping = iommu_alloc(tbl, ret, npages, DMA_BIDIRECTIONAL); - - if (mapping == DMA_ERROR_CODE) { - free_pages((unsigned long)ret, order); - ret = NULL; - } else - *dma_handle = mapping; - - return ret; + return iommu_alloc_consistent(devnode_table(hwdev), size, dma_handle); } static void pci_iommu_free_consistent(struct pci_dev *hwdev, size_t size, void *vaddr, dma_addr_t dma_handle) { - struct iommu_table *tbl; - unsigned int npages; - - size = PAGE_ALIGN(size); - npages = size >> PAGE_SHIFT; - - tbl = devnode_table(hwdev); - - if (tbl) { - iommu_free(tbl, dma_handle, npages); - free_pages((unsigned long)vaddr, get_order(size)); - } + iommu_free_consistent(devnode_table(hwdev), size, vaddr, dma_handle); } @@ -139,81 +87,28 @@ static dma_addr_t pci_iommu_map_single(struct pci_dev *hwdev, void *vaddr, size_t size, enum dma_data_direction direction) { - struct iommu_table * tbl; - dma_addr_t dma_handle = DMA_ERROR_CODE; - unsigned long uaddr; - unsigned int npages; - - BUG_ON(direction == DMA_NONE); - - uaddr = (unsigned long)vaddr; - npages = PAGE_ALIGN(uaddr + size) - (uaddr & PAGE_MASK); - npages >>= PAGE_SHIFT; - - tbl = devnode_table(hwdev); - - if (tbl) { - dma_handle = iommu_alloc(tbl, vaddr, npages, direction); - if (dma_handle == DMA_ERROR_CODE) { - if (printk_ratelimit()) { - printk(KERN_INFO "iommu_alloc failed, tbl %p vaddr %p npages %d\n", - tbl, vaddr, npages); - } - } else - dma_handle |= (uaddr & ~PAGE_MASK); - } - - return dma_handle; + return iommu_map_single(devnode_table(hwdev), vaddr, size, direction); } static void pci_iommu_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_handle, size_t size, enum dma_data_direction direction) { - struct iommu_table *tbl; - unsigned int npages; - - BUG_ON(direction == DMA_NONE); - - npages = (PAGE_ALIGN(dma_handle + size) - (dma_handle & PAGE_MASK)) - >> PAGE_SHIFT; - - tbl = devnode_table(hwdev); - - if (tbl) - iommu_free(tbl, dma_handle, npages); + iommu_unmap_single(devnode_table(hwdev), dma_handle, size, direction); } static int pci_iommu_map_sg(struct pci_dev *pdev, struct scatterlist *sglist, int nelems, enum dma_data_direction direction) { - struct iommu_table * tbl; - - BUG_ON(direction == DMA_NONE); - - if (nelems == 0) - return 0; - - tbl = devnode_table(pdev); - if (!tbl) - return 0; - - return iommu_alloc_sg(tbl, &pdev->dev, sglist, nelems, direction); + return iommu_map_sg(&pdev->dev, devnode_table(pdev), sglist, + nelems, direction); } static void pci_iommu_unmap_sg(struct pci_dev *pdev, struct scatterlist *sglist, int nelems, enum dma_data_direction direction) { - struct iommu_table *tbl; - - BUG_ON(direction == DMA_NONE); - - tbl = devnode_table(pdev); - if (!tbl) - return; - - iommu_free_sg(tbl, sglist, nelems); + iommu_unmap_sg(devnode_table(pdev), sglist, nelems, direction); } /* We support DMA to/from any memory page via the iommu */ diff -ruN ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/vio.c ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/vio.c --- ppc64-2.5-iseries.dma.3/arch/ppc64/kernel/vio.c 2004-04-01 16:46:30.000000000 +1000 +++ ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/vio.c 2004-04-01 16:12:05.000000000 +1000 @@ -417,141 +417,43 @@ dma_addr_t vio_map_single(struct vio_dev *dev, void *vaddr, size_t size, enum dma_data_direction direction) { - struct iommu_table *tbl; - dma_addr_t dma_handle = DMA_ERROR_CODE; - unsigned long uaddr; - unsigned int npages; - - BUG_ON(direction == DMA_NONE); - - uaddr = (unsigned long)vaddr; - npages = PAGE_ALIGN( uaddr + size ) - ( uaddr & PAGE_MASK ); - npages >>= PAGE_SHIFT; - - tbl = dev->iommu_table; - - if (tbl) { - dma_handle = iommu_alloc(tbl, vaddr, npages, direction); - dma_handle |= (uaddr & ~PAGE_MASK); - } - - return dma_handle; + return iommu_map_single(dev->iommu_table, vaddr, size, direction); } EXPORT_SYMBOL(vio_map_single); void vio_unmap_single(struct vio_dev *dev, dma_addr_t dma_handle, size_t size, enum dma_data_direction direction) { - struct iommu_table * tbl; - unsigned int npages; - - BUG_ON(direction == DMA_NONE); - - npages = PAGE_ALIGN( dma_handle + size ) - ( dma_handle & PAGE_MASK ); - npages >>= PAGE_SHIFT; - - tbl = dev->iommu_table; - if(tbl) - iommu_free(tbl, dma_handle, npages); + iommu_unmap_single(dev->iommu_table, dma_handle, size, direction); } EXPORT_SYMBOL(vio_unmap_single); int vio_map_sg(struct vio_dev *vdev, struct scatterlist *sglist, int nelems, enum dma_data_direction direction) { - struct iommu_table *tbl; - - BUG_ON(direction == DMA_NONE); - - if (nelems == 0) - return 0; - - tbl = vdev->iommu_table; - if (!tbl) - return 0; - - return iommu_alloc_sg(tbl, &vdev->dev, sglist, nelems, direction); + return iommu_map_sg(&vdev->dev, vdev->iommu_table, sglist, + nelems, direction); } EXPORT_SYMBOL(vio_map_sg); void vio_unmap_sg(struct vio_dev *vdev, struct scatterlist *sglist, int nelems, enum dma_data_direction direction) { - struct iommu_table *tbl; - - BUG_ON(direction == DMA_NONE); - - tbl = vdev->iommu_table; - if (tbl) - iommu_free_sg(tbl, sglist, nelems); + iommu_unmap_sg(vdev->iommu_table, sglist, nelems, direction); } EXPORT_SYMBOL(vio_unmap_sg); void *vio_alloc_consistent(struct vio_dev *dev, size_t size, dma_addr_t *dma_handle) { - struct iommu_table * tbl; - void *ret = NULL; - unsigned int npages, order; - dma_addr_t tce; - - size = PAGE_ALIGN(size); - npages = size >> PAGE_SHIFT; - order = get_order(size); - - /* Client asked for way to much space. This is checked later anyway */ - /* It is easier to debug here for the drivers than in the tce tables.*/ - if(order >= IOMAP_MAX_ORDER) { - printk("VIO_DMA: vio_alloc_consistent size to large: 0x%lx \n", size); - return (void *)DMA_ERROR_CODE; - } - - tbl = dev->iommu_table; - - if (tbl) { - /* Alloc enough pages (and possibly more) */ - ret = (void *)__get_free_pages(GFP_ATOMIC, order); - if (ret) { - /* Page allocation succeeded */ - memset(ret, 0, npages << PAGE_SHIFT); - /* Set up tces to cover the allocated range */ - tce = iommu_alloc(tbl, ret, npages, DMA_BIDIRECTIONAL); - if (tce == DMA_ERROR_CODE) { - PPCDBG(PPCDBG_TCE, "vio_alloc_consistent: iommu_alloc failed\n" ); - free_pages((unsigned long)ret, order); - ret = NULL; - } else { - *dma_handle = tce; - } - } - else PPCDBG(PPCDBG_TCE, "vio_alloc_consistent: __get_free_pages failed for size = %d\n", size); - } - else PPCDBG(PPCDBG_TCE, "vio_alloc_consistent: get_iommu_table failed for 0x%016lx\n", dev); - - PPCDBG(PPCDBG_TCE, "\tvio_alloc_consistent: dma_handle = 0x%16.16lx\n", *dma_handle); - PPCDBG(PPCDBG_TCE, "\tvio_alloc_consistent: return = 0x%16.16lx\n", ret); - return ret; + return iommu_alloc_consistent(dev->iommu_table, size, dma_handle); } EXPORT_SYMBOL(vio_alloc_consistent); void vio_free_consistent(struct vio_dev *dev, size_t size, void *vaddr, dma_addr_t dma_handle) { - struct iommu_table *tbl; - unsigned int npages; - - PPCDBG(PPCDBG_TCE, "vio_free_consistent:\n"); - PPCDBG(PPCDBG_TCE, "\tdev = 0x%16.16lx, size = 0x%16.16lx, dma_handle = 0x%16.16lx, vaddr = 0x%16.16lx\n", dev, size, dma_handle, vaddr); - - size = PAGE_ALIGN(size); - npages = size >> PAGE_SHIFT; - - tbl = dev->iommu_table; - - if ( tbl ) { - iommu_free(tbl, dma_handle, npages); - free_pages((unsigned long)vaddr, get_order(size)); - } + iommu_free_consistent(dev->iommu_table, size, vaddr, dma_handle); } EXPORT_SYMBOL(vio_free_consistent); diff -ruN ppc64-2.5-iseries.dma.3/include/asm-ppc64/iommu.h ppc64-2.5-iseries.dma.4/include/asm-ppc64/iommu.h --- ppc64-2.5-iseries.dma.3/include/asm-ppc64/iommu.h 2004-04-01 16:46:30.000000000 +1000 +++ ppc64-2.5-iseries.dma.4/include/asm-ppc64/iommu.h 2004-04-01 16:18:57.000000000 +1000 @@ -19,8 +19,8 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#ifndef _PCI_DMA_H -#define _PCI_DMA_H +#ifndef _ASM_IOMMU_H +#define _ASM_IOMMU_H #include #include @@ -131,20 +131,20 @@ */ extern struct iommu_table *iommu_init_table(struct iommu_table * tbl); -/* allocates a range of tces and sets them to the pages */ -extern dma_addr_t iommu_alloc(struct iommu_table *, void *page, - unsigned int numPages, - enum dma_data_direction direction); -extern void iommu_free(struct iommu_table *tbl, dma_addr_t dma_addr, - unsigned int npages); - -/* same with sg lists */ -extern int iommu_alloc_sg(struct iommu_table *table, struct device *dev, - struct scatterlist *sglist, int nelems, - enum dma_data_direction direction); -extern void iommu_free_sg(struct iommu_table *tbl, struct scatterlist *sglist, - int nelems); - +extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl, + struct scatterlist *sglist, int nelems, + enum dma_data_direction direction); +extern void iommu_unmap_sg(struct iommu_table *tbl, struct scatterlist *sglist, + int nelems, enum dma_data_direction direction); + +extern void *iommu_alloc_consistent(struct iommu_table *tbl, size_t size, + dma_addr_t *dma_handle); +extern void iommu_free_consistent(struct iommu_table *tbl, size_t size, + void *vaddr, dma_addr_t dma_handle); +extern dma_addr_t iommu_map_single(struct iommu_table *tbl, void *vaddr, + size_t size, enum dma_data_direction direction); +extern void iommu_unmap_single(struct iommu_table *tbl, dma_addr_t dma_handle, + size_t size, enum dma_data_direction direction); extern void tce_init_pSeries(void); extern void tce_init_iSeries(void); @@ -154,4 +154,4 @@ extern int ppc64_iommu_off; -#endif +#endif /* _ASM_IOMMU_H */ From mattias at virtutech.se Thu Apr 1 19:01:35 2004 From: mattias at virtutech.se (=?ISO-8859-1?Q?Mattias Engdeg=E5rd?=) Date: Thu, 1 Apr 2004 11:01:35 +0200 Subject: GDB for ppc-64 In-Reply-To: <20040401020101.GE27453@krispykreme> (message from Anton Blanchard on Thu, 1 Apr 2004 12:01:01 +1000) References: <20040401020101.GE27453@krispykreme> Message-ID: <200404010901.i3191Zk20329@virtutech.se> >> 1) Do you know any areas in GDB/ppc-64 that needs attention? I have >> some idea, but I would like your 'take'. When I'm debugging ppc64 code, I keep getting confused by procedure descriptors and the actual function addresses. ie: (gdb) p do_select $1 = {int (int, fd_set_bits *, long int *)} 0xc0000000000c471c (gdb) x 0xc0000000000c471c 0xc0000000000c471c : 0x7d800026 (gdb) x 0xc0000000004f6810 0xc0000000004f6810 : 0xc0000000 -- I'm never really sure which one I get. Since parsing .identifiers (symbols preceded by a dot) is tricky in C code I'm not sure what the best way to resolve this would be. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sergiy at cs.unm.edu Fri Apr 2 04:40:47 2004 From: sergiy at cs.unm.edu (Sergiy Kyrylkov) Date: Thu, 1 Apr 2004 11:40:47 -0700 Subject: getcontext on Linux PPC64 Message-ID: Hi, Since getcontext is not implemented on Linux the following thing worked for me on Linux PPC void cTrapHandler(int signum, siginfo_t *siginfo, void* arg3) { sigcontext* context = getLinuxSavedContext(signum, arg3); printf("SIGSEGV = %d\n", SIGSEGV); printf("signum = %d\n", signum); printf("(siginfo->si_addr) = 0x%p\n", (siginfo->si_addr)); ..... } sigcontext* getLinuxSavedContext(int signum, void* arg3) { return &((ucontext_t*)arg3)->uc_mcontext; } It doesn't seem to work on Linux PPC64. Instead of getting the correct faulting address: SIGSEGV = 11 Signum = 11 (siginfo->si_addr) = 0xffffffff4 like it was on the 32-bit PPC, I get SIGSEGV = 11 Signum = 11 (siginfo->si_addr) = 0x0000000000000380 (instead of 0xffffffffffffffe8) which is totally wrong. Does somebody have any idea what will work on Linux PPC64? Sergiy ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sjmunroe at us.ibm.com Fri Apr 2 05:32:22 2004 From: sjmunroe at us.ibm.com (Steve Munroe) Date: Thu, 1 Apr 2004 11:32:22 -0800 Subject: getcontext on Linux PPC64 In-Reply-To: Message-ID: Sergiy Kyrylkov wrote on 04/01/2004 10:40:47 AM: > > Hi, > > Since getcontext is not implemented on Linux the following thing worked for > me on Linux PPC > get/setcontext is implemented in Linux PPC64, in glibc-2.3.2 and got kernels 2.4.21 and newer. Steven J. Munroe Linux on Power Toolchain Architect IBM Corporation, Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sergiy at cs.unm.edu Fri Apr 2 07:04:21 2004 From: sergiy at cs.unm.edu (Sergiy Kyrylkov) Date: Thu, 1 Apr 2004 14:04:21 -0700 Subject: getcontext on Linux PPC64 In-Reply-To: Message-ID: According to the output I get on YDL 3.0 with 2.6.4 ppc64 kernel it is not the case on my machine (Apple G5): #include #include #include int main() { ucontext_t* pointer; int result = getcontext(pointer); printf("error: %s\n", strerror(errno)); } [sergiy at zeta _test]$ rpm -qa | grep kernel kernel-source-2.6.4-1.1321 kernel-2.6.4-1.1321 [sergiy at zeta _test]$ uname -a Linux zeta 2.6.4-1.1321 #1 SMP Tue Mar 16 03:07:10 EST 2004 ppc64 ppc64 ppc64 GNU/Linux [sergiy at zeta _test]$ gcc -m64 -mpowerpc64 contTest.c [sergiy at zeta _test]$ file a.out a.out: ELF 64-bit MSB executable, PowerPC or cisco 7500, version 1 (SYSV), for GNU/Linux 2.4.19, dynamically linked (uses shared libs), not stripped [sergiy at zeta _test]$ ./a.out error: Function not implemented Any suggestions? Sergiy > -----Original Message----- > From: owner-linuxppc64-dev at lists.linuxppc.org > [mailto:owner-linuxppc64-dev at lists.linuxppc.org] On Behalf Of > Steve Munroe > Sent: Thursday, April 01, 2004 12:32 PM > To: sergiy at cs.unm.edu > Cc: linuxppc64-dev at lists.linuxppc.org > Subject: Re: getcontext on Linux PPC64 > > > Sergiy Kyrylkov wrote on 04/01/2004 10:40:47 AM: > > > > > Hi, > > > > Since getcontext is not implemented on Linux the following thing > > worked > for > > me on Linux PPC > > > > get/setcontext is implemented in Linux PPC64, in glibc-2.3.2 > and got kernels 2.4.21 and newer. > > Steven J. Munroe > Linux on Power Toolchain Architect > IBM Corporation, Linux Technology Center > > > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sjmunroe at us.ibm.com Fri Apr 2 07:31:21 2004 From: sjmunroe at us.ibm.com (Steve Munroe) Date: Thu, 1 Apr 2004 13:31:21 -0800 Subject: getcontext on Linux PPC64 In-Reply-To: Message-ID: Sergiy Kyrylkov wrote on 04/01/2004 01:04:21 PM: > > According to the output I get on YDL 3.0 with 2.6.4 ppc64 kernel it is not > the case on my machine (Apple G5): > ... > [sergiy at zeta _test]$ ./a.out > error: Function not implemented > > Any suggestions? > They must have built the glibc on 2.4.19 kernel, It does not matter what kernel you have now. It matters what they told glibc when they built it! ENTRY(__getcontext) #ifdef __ASSUME_NEW_RT_SIGRETURN_SYSCALL std r0,(SIGCONTEXT_GP_REGS+(PT_R0*8))(r3) std r1,(SIGCONTEXT_GP_REGS+(PT_R1*8))(r3) .... #else /* If the kernel is not at least 2.4.21 then generate a ENOSYS stub. */ mflr r0 std r0,FRAME_LR_SAVE(r1) stdu r1,-128(r1) li r3,ENOSYS bl JUMPTARGET(__syscall_error) nop li r3,-1 #endif Steven J. Munroe Linux on Power Toolchain Architect IBM Corporation, Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Fri Apr 2 10:33:20 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 1 Apr 2004 18:33:20 -0600 Subject: [PATCH] kallsyms fix to kdbasupport.c Message-ID: <20040401183320.A58840@forte.austin.ibm.com> Anton, I don't have write access to ameslab; please apply the following patch: -- fixes symbol printing to use kallsyms Olaf Herring reported this bug, exception fram addrs were being printed incorrectly. -- removes some obsolete/unused code -- fixes a whole lot of horrible whitespace/indentation problems Linas. p.s. I notice the earlier patch from ananth for printing out iommu is not yet in ameslab. Since it probably conflicts with this patch, I'll try to resend an updated version of it tommorrow. (although the actual conflict should be minimal/trivial.) -------------- next part -------------- --- ameslab-2.6.5-rc3-1april/arch/ppc64/kdb/kdbasupport.c.orig 2004-04-01 16:41:46.000000000 -0600 +++ ameslab-2.6.5-rc3-1april/arch/ppc64/kdb/kdbasupport.c 2004-04-01 18:23:47.000000000 -0600 @@ -1,5 +1,5 @@ /* - * Kernel Debugger Architecture Independent Support Functions + * Kernel Debugger Architecture Dependent Support Functions * * Copyright (C) 1999 Silicon Graphics, Inc. * Copyright (C) Scott Lurndal (slurn at engr.sgi.com) @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include @@ -63,7 +64,8 @@ extern int kdb_ps(int argc, const char * extern int kdb_parse(const char *cmdstr, struct pt_regs *regs); -/* 60secs * 1000*1000 usecs/sec. HMC interface requires larger amount of time,.. */ +/* 60secs * 1000*1000 usecs/sec. + * HMC interface requires larger amount of time,.. */ #define KDB_RESET_TIMEOUT 60*1000*1000 /* kdb will use UDBG */ @@ -424,7 +426,7 @@ kdba_getpc(kdb_eframe_t ef) int kdba_setpc(kdb_eframe_t ef, kdb_machreg_t newpc) { -/* for ppc64, newpc passed in is actually a function descriptor for kdb. */ + /* for ppc64, newpc passed in is actually a function descriptor for kdb. */ ef->nip = kdba_getword(newpc+8, 8); KDB_STATE_SET(IP_ADJUSTED); return 0; @@ -471,38 +473,38 @@ kdba_main_loop(kdb_reason_t reason, kdb_ { struct pt_regs regs; asm volatile ("std 0,0(%0)\n\ - std 1,8(%0)\n\ - std 2,16(%0)\n\ - std 3,24(%0)\n\ - std 4,32(%0)\n\ - std 5,40(%0)\n\ - std 6,48(%0)\n\ - std 7,56(%0)\n\ - std 8,64(%0)\n\ - std 9,72(%0)\n\ - std 10,80(%0)\n\ - std 11,88(%0)\n\ - std 12,96(%0)\n\ - std 13,104(%0)\n\ - std 14,112(%0)\n\ - std 15,120(%0)\n\ - std 16,128(%0)\n\ - std 17,136(%0)\n\ - std 18,144(%0)\n\ - std 19,152(%0)\n\ - std 20,160(%0)\n\ - std 21,168(%0)\n\ - std 22,176(%0)\n\ - std 23,184(%0)\n\ - std 24,192(%0)\n\ - std 25,200(%0)\n\ - std 26,208(%0)\n\ - std 27,216(%0)\n\ - std 28,224(%0)\n\ - std 29,232(%0)\n\ - std 30,240(%0)\n\ - std 31,248(%0)" : : "b" (®s)); - /* one extra step back.. this frame disappears */ + std 1,8(%0)\n\ + std 2,16(%0)\n\ + std 3,24(%0)\n\ + std 4,32(%0)\n\ + std 5,40(%0)\n\ + std 6,48(%0)\n\ + std 7,56(%0)\n\ + std 8,64(%0)\n\ + std 9,72(%0)\n\ + std 10,80(%0)\n\ + std 11,88(%0)\n\ + std 12,96(%0)\n\ + std 13,104(%0)\n\ + std 14,112(%0)\n\ + std 15,120(%0)\n\ + std 16,128(%0)\n\ + std 17,136(%0)\n\ + std 18,144(%0)\n\ + std 19,152(%0)\n\ + std 20,160(%0)\n\ + std 21,168(%0)\n\ + std 22,176(%0)\n\ + std 23,184(%0)\n\ + std 24,192(%0)\n\ + std 25,200(%0)\n\ + std 26,208(%0)\n\ + std 27,216(%0)\n\ + std 28,224(%0)\n\ + std 29,232(%0)\n\ + std 30,240(%0)\n\ + std 31,248(%0)" : : "b" (®s)); + /* one extra step back.. this frame disappears */ regs.gpr[1] = kdba_getword(regs.gpr[1], 8); /* Fetch the link reg for this stack frame. NOTE: the prev kdb_printf fills in the lr. */ @@ -556,7 +558,8 @@ int kdba_getcurrentframe(struct pt_regs *regs) { regs->gpr[1] = getsp(); - /* this stack pointer becomes invalid after we return, so take another step back. */ + /* this stack pointer becomes invalid after we return, + * so take another step back. */ regs->gpr[1] = kdba_getword(regs->gpr[1], 8); return 0; } @@ -748,17 +751,17 @@ kdba_getword(unsigned long addr, size_t * is a user address, we use get_user() to verify validity. */ - if (!valid_ppc64_kernel_address(addr, width)) { - /* - * Would appear to be an illegal kernel address; - * Print a message once, and don't print again until - * a legal address is used. - */ - if (!KDB_STATE(SUPPRESS)) { - kdb_printf(" kdb: Not a kernel-space address 0x%lx \n",addr); - KDB_STATE_SET(SUPPRESS); - } - return 0L; + if (!valid_ppc64_kernel_address(addr, width)) { + /* + * Would appear to be an illegal kernel address; + * Print a message once, and don't print again until + * a legal address is used. + */ + if (!KDB_STATE(SUPPRESS)) { + kdb_printf(" kdb: Not a kernel-space address 0x%lx \n",addr); + KDB_STATE_SET(SUPPRESS); + } + return 0L; } @@ -1008,8 +1011,6 @@ kdba_callback_debug(struct pt_regs *regs } - - /* * kdba_adjust_ip * @@ -1037,18 +1038,19 @@ kdba_adjust_ip(kdb_reason_t reason, int } - /* * kdba_find_tb_table * - * Find the traceback table (defined by the ELF64 ABI) located at + * Find the traceback table (defined by the ELF64 ABI) located at * the end of the function containing pc. * * Parameters: - * nip starting instruction addr. does not need to be at the start of the func. + * nip starting instruction addr. + * does not need to be at the start of the func. * tab table to populate if successful * Returns: - * non-zero if successful. unsuccessful means that a valid tb table was not found + * non-zero if successful. unsuccessful means that + * a valid tb table was not found * Locking: * None. * Remarks: @@ -1066,7 +1068,8 @@ int kdba_find_tb_table(kdb_machreg_t nip return 0; memset(tab, 0, sizeof(tab)); - if (nip < PAGE_OFFSET) { /* this is gonna fail for userspace, at least for now.. */ + if (nip < PAGE_OFFSET) { + /* this is gonna fail for userspace, at least for now.. */ return 0; } @@ -1222,8 +1225,8 @@ kdba_getarea_size(void *to, unsigned lon if (is_valid_kern_addr) { memcpy(to, (void *)from_xxx, size); } else { - /* user space address, just return. */ - diag = -1; + /* user space address, just return. */ + diag = -1; } return diag; @@ -1239,20 +1242,18 @@ kdba_getarea_size(void *to, unsigned lon int kdba_readarea_size(unsigned long from_xxx,void *to, size_t size) { - int is_valid_kern_addr = valid_ppc64_kernel_address(from_xxx, size); + int is_valid_kern_addr = valid_ppc64_kernel_address(from_xxx, size); + + *((volatile char *)to) = '\0'; + *((volatile char *)to + size - 1) = '\0'; - *((volatile char *)to) = '\0'; - *((volatile char *)to + size - 1) = '\0'; + if (is_valid_kern_addr) { + memcpy(to, (void *)from_xxx, size); + return size; + } - if (is_valid_kern_addr) { - memcpy(to, (void *)from_xxx, size); - return size; - } else { - /* user-space, just return... */ + /* user-space, just return... */ return 0; - } - /* wont get here */ - return 0; } @@ -1283,46 +1284,6 @@ int hexdigit(int c); void machine_halt(void); - -/* - A traceback table typically follows each function. - The find_tb_table() func will fill in this struct. Note that the struct - is not an exact match with the encoded table defined by the ABI. It is - defined here more for programming convenience. - */ -struct tbtable { - unsigned long flags; /* flags: */ -#define TBTAB_FLAGSGLOBALLINK (1L<<47) -#define TBTAB_FLAGSISEPROL (1L<<46) -#define TBTAB_FLAGSHASTBOFF (1L<<45) -#define TBTAB_FLAGSINTPROC (1L<<44) -#define TBTAB_FLAGSHASCTL (1L<<43) -#define TBTAB_FLAGSTOCLESS (1L<<42) -#define TBTAB_FLAGSFPPRESENT (1L<<41) -#define TBTAB_FLAGSNAMEPRESENT (1L<<38) -#define TBTAB_FLAGSUSESALLOCA (1L<<37) -#define TBTAB_FLAGSSAVESCR (1L<<33) -#define TBTAB_FLAGSSAVESLR (1L<<32) -#define TBTAB_FLAGSSTORESBC (1L<<31) -#define TBTAB_FLAGSFIXUP (1L<<30) -#define TBTAB_FLAGSPARMSONSTK (1L<<0) - unsigned char fp_saved; /* num fp regs saved f(32-n)..f31 */ - unsigned char gpr_saved; /* num gpr's saved */ - unsigned char fixedparms; /* num fixed point parms */ - unsigned char floatparms; /* num float parms */ - unsigned char parminfo[32]; /* types of args. null terminated */ -#define TBTAB_PARMFIXED 1 -#define TBTAB_PARMSFLOAT 2 -#define TBTAB_PARMDFLOAT 3 - unsigned int tb_offset; /* offset from start of func */ - unsigned long funcstart; /* addr of start of function */ - char name[64]; /* name of function (null terminated)*/ -}; - - -static int find_tb_table(unsigned long codeaddr, struct tbtable *tab); - - /* Very cheap human name for vector lookup. */ static const char *getvecname(unsigned long vec) @@ -1351,15 +1312,32 @@ kdba_halt(int argc, const char **argv, c { kdb_printf("halting machine. "); machine_halt(); -return 0; + return 0; } +static inline void +kdba_printname (unsigned long addr) +{ + const char *name; + char *modname; + long size, offset; + char tmpstr[128]; + + name = kallsyms_lookup(addr, &size, &offset, &modname, tmpstr); + if (name) { + if (modname) + kdb_printf(" (%s:%s+0x%lx)", modname, name, offset); + else + kdb_printf(" (%s+0x%lx)", name, offset); + } +} + int -kdba_excprint(int argc, const char **argv, const char **envp, struct pt_regs *fp) +kdba_excprint(int argc, const char **argv, + const char **envp, struct pt_regs *fp) { struct task_struct *c; - struct tbtable tab; #ifdef CONFIG_SMP kdb_printf("cpu %d: ", smp_processor_id()); @@ -1367,18 +1345,12 @@ kdba_excprint(int argc, const char **arg kdb_printf("Vector: %lx %s at [%p]\n", fp->trap, getvecname(fp->trap), fp); kdb_printf(" pc: %lx", fp->nip); - if (find_tb_table(fp->nip, &tab) && tab.name[0]) { - /* Got a nice name for it */ - int delta = fp->nip - tab.funcstart; - kdb_printf(" (%s+0x%x)", tab.name, delta); - } + + kdba_printname (fp->nip); kdb_printf("\n"); kdb_printf(" lr: %lx", fp->link); - if (find_tb_table(fp->link, &tab) && tab.name[0]) { - /* Got a nice name for it */ - int delta = fp->link - tab.funcstart; - kdb_printf(" (%s+0x%x)", tab.name, delta); - } + kdba_printname (fp->link); + kdb_printf("\n"); kdb_printf(" sp: %lx\n", fp->gpr[1]); kdb_printf(" msr: %lx\n", fp->msr); @@ -1396,182 +1368,78 @@ kdba_excprint(int argc, const char **arg kdb_printf(" current = %p, pid = %ld, comm = %s\n", c, (unsigned long)c->pid, (char *)c->comm); } -return 0; -} - - -/* Starting at codeaddr scan forward for a tbtable and fill in the - given table. Return non-zero if successful at doing something. - */ -static int -find_tb_table(unsigned long codeaddr, struct tbtable *tab) -{ - unsigned long codeaddr_max; - unsigned long tbtab_start; - int nr; - int instr; - int num_parms; - - if (tab == NULL) - return 0; - memset(tab, 0, sizeof(tab)); - - /* Scan instructions starting at codeaddr for 128k max */ - for (codeaddr_max = codeaddr + 128*1024*4; - codeaddr < codeaddr_max; - codeaddr += 4) { - nr=kdba_readarea_size(codeaddr,&instr,4); - if (nr != 4) - return 0; /* Bad read. Give up promptly. */ - if (instr == 0) { - /* table should follow. */ - int version; - unsigned long flags; - tbtab_start = codeaddr; /* save it to compute func start addr */ - codeaddr += 4; - nr = kdba_readarea_size(codeaddr,&flags,8); - if (nr != 8) - return 0; /* Bad read or no tb table. */ - tab->flags = flags; - version = (flags >> 56) & 0xff; - if (version != 0) - continue; /* No tb table here. */ - /* Now, like the version, some of the flags are values - that are more conveniently extracted... */ - tab->fp_saved = (flags >> 24) & 0x3f; - tab->gpr_saved = (flags >> 16) & 0x3f; - tab->fixedparms = (flags >> 8) & 0xff; - tab->floatparms = (flags >> 1) & 0x7f; - codeaddr += 8; - num_parms = tab->fixedparms + tab->floatparms; - if (num_parms) { - unsigned int parminfo; - int parm; - if (num_parms > 32) - return 1; /* incomplete */ - nr = kdba_readarea_size(codeaddr,&parminfo,4); - if (nr != 4) - return 1; /* incomplete */ - /* decode parminfo...32 bits. - A zero means fixed. A one means float and the - following bit determines single (0) or double (1). - */ - for (parm = 0; parm < num_parms; parm++) { - if (parminfo & 0x80000000) { - parminfo <<= 1; - if (parminfo & 0x80000000) - tab->parminfo[parm] = TBTAB_PARMDFLOAT; - else - tab->parminfo[parm] = TBTAB_PARMSFLOAT; - } else { - tab->parminfo[parm] = TBTAB_PARMFIXED; - } - parminfo <<= 1; - } - codeaddr += 4; - } - if (flags & TBTAB_FLAGSHASTBOFF) { - nr = kdba_readarea_size(codeaddr,&tab->tb_offset,4); - if (nr != 4) - return 1; /* incomplete */ - if (tab->tb_offset > 0) { - tab->funcstart = tbtab_start - tab->tb_offset; - } - codeaddr += 4; - } - /* hand_mask appears to be always be omitted. */ - if (flags & TBTAB_FLAGSHASCTL) { - /* Assume this will never happen for C or asm */ - return 1; /* incomplete */ - } - if (flags & TBTAB_FLAGSNAMEPRESENT) { - short namlen; - nr = kdba_readarea_size(codeaddr,&namlen,2); - if (nr != 2) - return 1; /* incomplete */ - if (namlen >= sizeof(tab->name)) - namlen = sizeof(tab->name)-1; - codeaddr += 2; - nr = kdba_readarea_size(codeaddr,tab->name,namlen); - tab->name[namlen] = '\0'; - codeaddr += namlen; - } - return 1; - } - } - return 0; /* hit max...sorry. */ + return 0; } int kdba_dissect_msr(int argc, const char **argv, const char **envp, struct pt_regs *regs) { - long int msr; + long int msr; - if (argc==0) - msr = regs->msr; -/* msr = get_msr(); */ - else + if (argc==0) + msr = regs->msr; + else kdbgetularg(argv[1], &msr); - kdb_printf("msr: %lx (",msr); - { - if (msr & MSR_SF) kdb_printf("SF "); - if (msr & MSR_ISF) kdb_printf("ISF "); - if (msr & MSR_HV) kdb_printf("HV "); - if (msr & MSR_VEC) kdb_printf("VEC "); - if (msr & MSR_POW) kdb_printf("POW/"); /* pow/we share */ - if (msr & MSR_WE) kdb_printf("WE "); - if (msr & MSR_TGPR) kdb_printf("TGPR/"); /* tgpr/ce share */ - if (msr & MSR_CE) kdb_printf("CE "); - if (msr & MSR_ILE) kdb_printf("ILE "); - if (msr & MSR_EE) kdb_printf("EE "); - if (msr & MSR_PR) kdb_printf("PR "); - if (msr & MSR_FP) kdb_printf("FP "); - if (msr & MSR_ME) kdb_printf("ME "); - if (msr & MSR_FE0) kdb_printf("FE0 "); - if (msr & MSR_SE) kdb_printf("SE "); - if (msr & MSR_BE) kdb_printf("BE/"); /* be/de share */ - if (msr & MSR_DE) kdb_printf("DE "); - if (msr & MSR_FE1) kdb_printf("FE1 "); - if (msr & MSR_IP) kdb_printf("IP "); - if (msr & MSR_IR) kdb_printf("IR "); - if (msr & MSR_DR) kdb_printf("DR "); - if (msr & MSR_PE) kdb_printf("PE "); - if (msr & MSR_PX) kdb_printf("PX "); - if (msr & MSR_RI) kdb_printf("RI "); - if (msr & MSR_LE) kdb_printf("LE "); - } - kdb_printf(")\n"); - - if (msr & MSR_SF) kdb_printf(" 64 bit mode enabled \n"); - if (msr & MSR_ISF) kdb_printf(" Interrupt 64b mode valid on 630 \n"); - if (msr & MSR_HV) kdb_printf(" Hypervisor State \n"); - if (msr & MSR_VEC) kdb_printf(" Enable Altivec \n"); - if (msr & MSR_POW) kdb_printf(" Enable Power Management \n"); - if (msr & MSR_WE) kdb_printf(" Wait State Enable \n"); - if (msr & MSR_TGPR) kdb_printf(" TLB Update registers in use \n"); - if (msr & MSR_CE) kdb_printf(" Critical Interrupt Enable \n"); - if (msr & MSR_ILE) kdb_printf(" Interrupt Little Endian \n"); - if (msr & MSR_EE) kdb_printf(" External Interrupt Enable \n"); - if (msr & MSR_PR) kdb_printf(" Problem State / Privilege Level \n"); - if (msr & MSR_FP) kdb_printf(" Floating Point enable \n"); - if (msr & MSR_ME) kdb_printf(" Machine Check Enable \n"); - if (msr & MSR_FE0) kdb_printf(" Floating Exception mode 0 \n"); - if (msr & MSR_SE) kdb_printf(" Single Step \n"); - if (msr & MSR_BE) kdb_printf(" Branch Trace \n"); - if (msr & MSR_DE) kdb_printf(" Debug Exception Enable \n"); - if (msr & MSR_FE1) kdb_printf(" Floating Exception mode 1 \n"); - if (msr & MSR_IP) kdb_printf(" Exception prefix 0x000/0xFFF \n"); - if (msr & MSR_IR) kdb_printf(" Instruction Relocate \n"); - if (msr & MSR_DR) kdb_printf(" Data Relocate \n"); - if (msr & MSR_PE) kdb_printf(" Protection Enable \n"); - if (msr & MSR_PX) kdb_printf(" Protection Exclusive Mode \n"); - if (msr & MSR_RI) kdb_printf(" Recoverable Exception \n"); - if (msr & MSR_LE) kdb_printf(" Little Endian \n"); - kdb_printf(".\n"); + kdb_printf("msr: %lx (",msr); + { + if (msr & MSR_SF) kdb_printf("SF "); + if (msr & MSR_ISF) kdb_printf("ISF "); + if (msr & MSR_HV) kdb_printf("HV "); + if (msr & MSR_VEC) kdb_printf("VEC "); + if (msr & MSR_POW) kdb_printf("POW/"); /* pow/we share */ + if (msr & MSR_WE) kdb_printf("WE "); + if (msr & MSR_TGPR) kdb_printf("TGPR/"); /* tgpr/ce share */ + if (msr & MSR_CE) kdb_printf("CE "); + if (msr & MSR_ILE) kdb_printf("ILE "); + if (msr & MSR_EE) kdb_printf("EE "); + if (msr & MSR_PR) kdb_printf("PR "); + if (msr & MSR_FP) kdb_printf("FP "); + if (msr & MSR_ME) kdb_printf("ME "); + if (msr & MSR_FE0) kdb_printf("FE0 "); + if (msr & MSR_SE) kdb_printf("SE "); + if (msr & MSR_BE) kdb_printf("BE/"); /* be/de share */ + if (msr & MSR_DE) kdb_printf("DE "); + if (msr & MSR_FE1) kdb_printf("FE1 "); + if (msr & MSR_IP) kdb_printf("IP "); + if (msr & MSR_IR) kdb_printf("IR "); + if (msr & MSR_DR) kdb_printf("DR "); + if (msr & MSR_PE) kdb_printf("PE "); + if (msr & MSR_PX) kdb_printf("PX "); + if (msr & MSR_RI) kdb_printf("RI "); + if (msr & MSR_LE) kdb_printf("LE "); + } + kdb_printf(")\n"); + + if (msr & MSR_SF) kdb_printf(" 64 bit mode enabled \n"); + if (msr & MSR_ISF) kdb_printf(" Interrupt 64b mode valid on 630 \n"); + if (msr & MSR_HV) kdb_printf(" Hypervisor State \n"); + if (msr & MSR_VEC) kdb_printf(" Enable Altivec \n"); + if (msr & MSR_POW) kdb_printf(" Enable Power Management \n"); + if (msr & MSR_WE) kdb_printf(" Wait State Enable \n"); + if (msr & MSR_TGPR) kdb_printf(" TLB Update registers in use \n"); + if (msr & MSR_CE) kdb_printf(" Critical Interrupt Enable \n"); + if (msr & MSR_ILE) kdb_printf(" Interrupt Little Endian \n"); + if (msr & MSR_EE) kdb_printf(" External Interrupt Enable \n"); + if (msr & MSR_PR) kdb_printf(" Problem State / Privilege Level \n"); + if (msr & MSR_FP) kdb_printf(" Floating Point enable \n"); + if (msr & MSR_ME) kdb_printf(" Machine Check Enable \n"); + if (msr & MSR_FE0) kdb_printf(" Floating Exception mode 0 \n"); + if (msr & MSR_SE) kdb_printf(" Single Step \n"); + if (msr & MSR_BE) kdb_printf(" Branch Trace \n"); + if (msr & MSR_DE) kdb_printf(" Debug Exception Enable \n"); + if (msr & MSR_FE1) kdb_printf(" Floating Exception mode 1 \n"); + if (msr & MSR_IP) kdb_printf(" Exception prefix 0x000/0xFFF \n"); + if (msr & MSR_IR) kdb_printf(" Instruction Relocate \n"); + if (msr & MSR_DR) kdb_printf(" Data Relocate \n"); + if (msr & MSR_PE) kdb_printf(" Protection Enable \n"); + if (msr & MSR_PX) kdb_printf(" Protection Exclusive Mode \n"); + if (msr & MSR_RI) kdb_printf(" Recoverable Exception \n"); + if (msr & MSR_LE) kdb_printf(" Little Endian \n"); + kdb_printf(".\n"); -return 0; + return 0; } int @@ -1600,7 +1468,7 @@ kdba_super_regs(int argc, const char **a // Dump out relevant Paca data areas. kdb_printf("Paca: \n"); ptrPaca = (struct paca_struct*)get_sprg3(); - + kdb_printf(" Local Processor Control Area (LpPaca): \n"); ptrLpPaca = ptrPaca->xLpPacaPtr; kdb_printf(" Saved Srr0=%.16lx Saved Srr1=%.16lx \n", ptrLpPaca->xSavedSrr0, ptrLpPaca->xSavedSrr1); @@ -1710,318 +1578,340 @@ kdba_dump_tce_table(int argc, const char #endif int -kdba_kernelversion(int argc, const char **argv, const char **envp, struct pt_regs *regs){ - extern char *linux_banner; - - kdb_printf("%s\n",linux_banner); - - return 0; +kdba_kernelversion(int argc, const char **argv, + const char **envp, struct pt_regs *regs) +{ + extern char *linux_banner; + kdb_printf("%s\n",linux_banner); + return 0; } static void * kdba_dump_pci(struct device_node *dn, void *data) { - struct pci_controller *phb; - char *device_type; - char *status; - - phb = (struct pci_controller *)data; - device_type = get_property(dn, "device_type", 0); - status = get_property(dn, "status", 0); - - dn->phb = phb; - kdb_printf("dn: %p \n",dn); - kdb_printf(" phb : %p\n",dn->phb); - kdb_printf(" name : %s\n",dn->name); - kdb_printf(" full_name: %s\n",dn->full_name); - kdb_printf(" busno : 0x%x\n",dn->busno); - kdb_printf(" devfn : 0x%x\n",dn->devfn); - // XXX fix me later, bring up to date - // kdb_printf(" tce_table: %p\n",dn->tce_table); - return NULL; + struct pci_controller *phb; + char *device_type; + char *status; + + phb = (struct pci_controller *)data; + device_type = get_property(dn, "device_type", 0); + status = get_property(dn, "status", 0); + + dn->phb = phb; + kdb_printf("dn: %p \n",dn); + kdb_printf(" phb : %p\n",dn->phb); + kdb_printf(" name : %s\n",dn->name); + kdb_printf(" full_name: %s\n",dn->full_name); + kdb_printf(" busno : 0x%x\n",dn->busno); + kdb_printf(" devfn : 0x%x\n",dn->devfn); + // XXX fix me later, bring up to date + // kdb_printf(" tce_table: %p\n",dn->tce_table); + return NULL; } int -kdba_dump_pci_info(int argc, const char **argv, const char **envp, struct pt_regs *regs){ - - kdb_printf("kdba_dump_pci_info\n"); - -/* call this traverse function with my function pointer.. it takes care of traversing, my func just needs to parse the device info.. */ - traverse_all_pci_devices(kdba_dump_pci); - return 0; +kdba_dump_pci_info(int argc, const char **argv, const char **envp, + struct pt_regs *regs) +{ + kdb_printf("kdba_dump_pci_info\n"); + + /* call this traverse function with my function pointer.. + * it takes care of traversing, my func just needs to + * parse the device info.. */ + traverse_all_pci_devices(kdba_dump_pci); + return 0; } char *kdb_dumpall_cmds[] = { - "excp\n", - "bt\n", - "rd\n", - "dmesg\n", - "msr\n", - "superreg\n", - "pci_info\n", - "ps\n", - "cpu\n", - "set BTAPROMPT=none\n", - "bta\n", - 0 + "excp\n", + "bt\n", + "rd\n", + "dmesg\n", + "msr\n", + "superreg\n", + "pci_info\n", + "ps\n", + "cpu\n", + "set BTAPROMPT=none\n", + "bta\n", + 0 }; char *kdb_dumpbasic_cmds[] = { - "excp\n", - "bt\n", - "rd\n", - "dmesg 25\n", - "msr\n", - "superreg\n", - "ps\n", - "cpu\n", - 0 + "excp\n", + "bt\n", + "rd\n", + "dmesg 25\n", + "msr\n", + "superreg\n", + "ps\n", + "cpu\n", + 0 }; - -/* dump with "all" parm will dump all. all other variations dump basic. See the dump*_cmds defined above */ +/* dump with "all" parm will dump all. + * all other variations dump basic. + * See the dump*_cmds defined above + */ int kdba_dump(int argc, const char **argv, const char **envp, struct pt_regs *fp) { - int i, diag; - kdb_printf("dump-all\n"); - if ((argc==1)&& (strcmp(argv[1], "all")==0)) { - for (i = 0; kdb_dumpall_cmds[i]; ++i) { - kdb_printf("kdb_cmd[%d]%s: %s", - i, " ", kdb_dumpall_cmds[i]); - diag = kdb_parse(kdb_dumpall_cmds[i], fp); - if (diag) - kdb_printf("command failed, kdb diag %d\n", diag); - } - } else { - kdb_printf("dump-basic\n"); - for (i = 0; kdb_dumpbasic_cmds[i]; ++i) { - kdb_printf("kdb_cmd[%d]%s: %s", - i, " ", kdb_dumpbasic_cmds[i]); - diag = kdb_parse(kdb_dumpbasic_cmds[i], fp); - if (diag) - kdb_printf("command failed, kdb diag %d\n", diag); + int i, diag; + kdb_printf("dump-all\n"); + if ((argc==1)&& (strcmp(argv[1], "all")==0)) { + for (i = 0; kdb_dumpall_cmds[i]; ++i) { + kdb_printf("kdb_cmd[%d]%s: %s", + i, " ", kdb_dumpall_cmds[i]); + diag = kdb_parse(kdb_dumpall_cmds[i], fp); + if (diag) + kdb_printf("command failed, kdb diag %d\n", diag); + } + } else { + kdb_printf("dump-basic\n"); + for (i = 0; kdb_dumpbasic_cmds[i]; ++i) { + kdb_printf("kdb_cmd[%d]%s: %s", + i, " ", kdb_dumpbasic_cmds[i]); + diag = kdb_parse(kdb_dumpbasic_cmds[i], fp); + if (diag) + kdb_printf("command failed, kdb diag %d\n", diag); + } } - } - return 0; + return 0; } -/* Toggle the ppcdbg options. kdb_parse tokenizes the parms, so need to account for that here. */ +/* Toggle the ppcdbg options. + * kdb_parse tokenizes the parms, + * so need to account for that here. + */ int kdba_ppcdbg(int argc, const char **argv, const char **envp, struct pt_regs *fp) { - extern char *trace_names[PPCDBG_NUM_FLAGS]; + extern char *trace_names[PPCDBG_NUM_FLAGS]; - int i,j; - unsigned long mask; - int onoff; - if (argc==0) + int i,j; + unsigned long mask; + int onoff; + if (argc==0) goto ppcdbg_exit; - for (i=1;i<=argc;i++) { - onoff = 1; /* default */ - if (argv[i][0] == '+' || argv[i][0] == '-') { + for (i=1;i<=argc;i++) { + onoff = 1; /* default */ + if (argv[i][0] == '+' || argv[i][0] == '-') { /* explicit on or off */ - onoff = (argv[i][0] == '+'); - argv[i]++; - } - - for (j=0;jdebug_switch |= mask; - else - naca->debug_switch &= ~mask; + + for (j=0;jdebug_switch |= mask; + else + naca->debug_switch &= ~mask; + } + } } - } } - } - ppcdbg_exit: - kdb_printf("naca->debug_switch 0x%lx\n",naca->debug_switch); - return 0; + +ppcdbg_exit: + kdb_printf("naca->debug_switch 0x%lx\n",naca->debug_switch); + return 0; } /* enable or disable surveillance.. based on rtasd.c function. - no arguments - display current timeout value. - one argument - 'off' or '0' turn off surveillance. - - '1-255' set surveillance timeout to argument. */ -int -kdba_surveillance(int argc, const char **argv, const char **envp, struct pt_regs *fp) -{ - unsigned long timeout; - int ibm_indicator_token = 9000; - int error; - unsigned long ret; - - if (argc==0) { - goto surveillance_status; - } else if (((argc==1)&& (strcmp(argv[1], "off")==0))) { - timeout=0; - } else { - kdbgetularg(argv[1], &timeout); - } + * no arguments - display current timeout value. + * one argument - 'off' or '0' turn off surveillance. + * - '1-255' set surveillance timeout to argument. + */ - error = rtas_call(rtas_token("set-indicator"), 3, 1, &ret, - ibm_indicator_token, 0, timeout); - /* kdb_printf("Surveillance set-indicator returned value: 0x%x\n",ret); */ - - if (error) - kdb_printf("surveillance rtas_call failure 0x%x \n",error); - - surveillance_status: - rtas_call(rtas_token("get-sensor-state"), 2, 2, &ret, - ibm_indicator_token, - 0/* instance */); - kdb_printf("Current surveillance timeout is %ld minutes%s",ret, - ret==0?" (disabled).\n":".\n"); - return 0; +int +kdba_surveillance(int argc, const char **argv, + const char **envp, struct pt_regs *fp) +{ + unsigned long timeout; + int ibm_indicator_token = 9000; + int error; + unsigned long ret; + + if (argc==0) { + goto surveillance_status; + } else if (((argc==1)&& (strcmp(argv[1], "off")==0))) { + timeout=0; + } else { + kdbgetularg(argv[1], &timeout); + } + + error = rtas_call(rtas_token("set-indicator"), 3, 1, &ret, + ibm_indicator_token, 0, timeout); + /* kdb_printf("Surveillance set-indicator returned value: 0x%x\n",ret); */ + + if (error) + kdb_printf("surveillance rtas_call failure 0x%x \n",error); + +surveillance_status: + rtas_call(rtas_token("get-sensor-state"), 2, 2, &ret, + ibm_indicator_token, + 0 /* instance */); + kdb_printf("Current surveillance timeout is %ld minutes%s", + ret, ret==0?" (disabled).\n":".\n"); + return 0; } -/* generic debugger() hooks into kdb. These eliminate the need to add - ifdef CONFIG_KDB goop to traps.c and fault.c */ +/* generic debugger() hooks into kdb. + * These eliminate the need to add + * ifdef CONFIG_KDB goop to traps.c and fault.c + */ void -kdb_reset_debugger(struct pt_regs *regs) { - int cpu=smp_processor_id(); - static int reset_cpu = -1; - static spinlock_t reset_lock = SPIN_LOCK_UNLOCKED; - spin_lock(&reset_lock); - if (reset_cpu == -1 || reset_cpu == cpu) { - reset_cpu = cpu; - spin_unlock(&reset_lock); - if (kdb_on) { - ppc64_attention_msg(0x3200+cpu,"KDB Call "); - kdb(KDB_REASON_ENTER, regs->trap, (kdb_eframe_t) regs); - ppc64_attention_msg(0x3300+cpu,"KDB Done "); +kdb_reset_debugger(struct pt_regs *regs) +{ + int cpu=smp_processor_id(); + static int reset_cpu = -1; + static spinlock_t reset_lock = SPIN_LOCK_UNLOCKED; + + spin_lock(&reset_lock); + if (reset_cpu == -1 || reset_cpu == cpu) { + reset_cpu = cpu; + spin_unlock(&reset_lock); + if (kdb_on) { + ppc64_attention_msg(0x3200+cpu,"KDB Call "); + kdb(KDB_REASON_ENTER, regs->trap, (kdb_eframe_t) regs); + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + } else { + kdb_on=1; + kdb_do_reboot=1; + ppc64_attention_msg(0x3600+cpu,"KDB Enabled "); + udelay(KDB_RESET_TIMEOUT); + kdb_on=0; + if (kdb_do_reboot) { + ppc64_attention_msg(0x3900+cpu,"Rebooting "); + ppc_md.restart("rebooting..."); + return; /* not reached */ + } else { + ppc64_attention_msg(0x3800+cpu,"KDB skip reboot "); + return; + } + } } else { - kdb_on=1; - kdb_do_reboot=1; - ppc64_attention_msg(0x3600+cpu,"KDB Enabled "); - udelay(KDB_RESET_TIMEOUT); - kdb_on=0; - if (kdb_do_reboot) { - ppc64_attention_msg(0x3900+cpu,"Rebooting "); - ppc_md.restart("rebooting..."); - return; /* not reached */ - } else { - ppc64_attention_msg(0x3800+cpu,"KDB skip reboot "); + spin_unlock(&reset_lock); return; - } } - } else { - spin_unlock(&reset_lock); - return; - } } int kdb_debugger(struct pt_regs *regs) { - if (regs) - if (regs->trap==0x100) { - kdb_reset_debugger(regs); - } else - kdb(KDB_REASON_ENTER,regs->trap,regs); /* ok */ - else /* regs invalid */ - kdb(KDB_REASON_SILENT,0,regs); - + if (regs) { + if (regs->trap==0x100) { + kdb_reset_debugger(regs); + } else { + kdb(KDB_REASON_ENTER,regs->trap,regs); /* ok */ + } + } else { /* regs invalid */ + kdb(KDB_REASON_SILENT,0,regs); + } return 0; } int -kdb_debugger_bpt(struct pt_regs *regs) { - if (regs) - return kdb(KDB_REASON_BREAK,regs->trap,regs); - else /* regs invalid */ - return kdb(KDB_REASON_SILENT,0,regs); +kdb_debugger_bpt(struct pt_regs *regs) +{ + if (regs) + return kdb(KDB_REASON_BREAK,regs->trap,regs); + else /* regs invalid */ + return kdb(KDB_REASON_SILENT,0,regs); } int -kdb_debugger_sstep(struct pt_regs *regs) { - if (regs) - return kdb(KDB_REASON_DEBUG,regs->trap,regs); /* ok */ - else /* regs invalid */ - return kdb(KDB_REASON_SILENT,0,regs); +kdb_debugger_sstep(struct pt_regs *regs) +{ + if (regs) + return kdb(KDB_REASON_DEBUG,regs->trap,regs); /* ok */ + else /* regs invalid */ + return kdb(KDB_REASON_SILENT,0,regs); } int -kdb_debugger_iabr_match(struct pt_regs *regs) { - if (regs) - return kdb(KDB_REASON_BREAK,regs->trap,regs); - else /* regs invalid */ - return kdb(KDB_REASON_SILENT,0,regs); +kdb_debugger_iabr_match(struct pt_regs *regs) +{ + if (regs) + return kdb(KDB_REASON_BREAK,regs->trap,regs); + else /* regs invalid */ + return kdb(KDB_REASON_SILENT,0,regs); } int -kdb_debugger_dabr_match(struct pt_regs *regs) { - if (regs) - return kdb(KDB_REASON_BREAK,regs->trap,regs); - else /* regs invalid */ - return kdb(KDB_REASON_SILENT,0,regs); +kdb_debugger_dabr_match(struct pt_regs *regs) +{ + if (regs) + return kdb(KDB_REASON_BREAK,regs->trap,regs); + else /* regs invalid */ + return kdb(KDB_REASON_SILENT,0,regs); } void -kdb_debugger_fault_handler(struct pt_regs *regs) { - if (regs) - kdb(KDB_REASON_FAULT,regs->trap,regs); - else /* regs invalid */ - kdb(KDB_REASON_SILENT,0,regs); - return; +kdb_debugger_fault_handler(struct pt_regs *regs) +{ + if (regs) + kdb(KDB_REASON_FAULT,regs->trap,regs); + else /* regs invalid */ + kdb(KDB_REASON_SILENT,0,regs); + return; } - - int kdba_state(int argc, const char **argv, const char **envp, struct pt_regs *fp) { - int i; - for (i=0;i References: <20040327020111.GC18611@homesrv.constantdata.com> <20040327152244.GG18611@homesrv.constantdata.com> <20040328185417.GA25515@suse.de> Message-ID: <20040402030856.GC6698@homesrv.constantdata.com> I solved this problem. If anyone else cares how to compile a program that needs to call stat() on iSeries using the cross-compiler, let me know. As soon as I understand why what I did works, I'll submit a patch. -justinb -- Justin Banks Constant Data, Inc. http://www.constantdata.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sfr at canb.auug.org.au Fri Apr 2 15:33:00 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Fri, 2 Apr 2004 15:33:00 +1000 Subject: [PATCH] move the iSeries virtual devices to vio Message-ID: <20040402153300.3895566b.sfr@canb.auug.org.au> Hi Anton, This patch changes the iSeries virtual device drivers to use the vio infrastructure for DMA mapping instead of the PCI infrastructure. This is a ste alogn the way to integrating them correctly into the driver model. Patch relative to my previous patches. Built and booted on iSeries, built on pSeries and pmac. Please apply to Ameslab. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- diff -ruN ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/Makefile ppc64-2.5-iseries.vio.1/arch/ppc64/kernel/Makefile --- ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/Makefile 2004-03-20 23:04:34.000000000 +1100 +++ ppc64-2.5-iseries.vio.1/arch/ppc64/kernel/Makefile 2004-04-01 16:58:24.000000000 +1000 @@ -11,7 +11,7 @@ udbg.o binfmt_elf32.o sys_ppc32.o ioctl32.o \ ptrace32.o signal32.o rtc.o init_task.o \ lmb.o cputable.o cpu_setup_power4.o idle_power4.o \ - iommu.o + iommu.o vio.o obj-$(CONFIG_PPC_OF) += of_device.o @@ -34,7 +34,7 @@ obj-$(CONFIG_PPC_PSERIES) += pSeries_pci.o pSeries_lpar.o pSeries_hvCall.o \ eeh.o nvram.o pSeries_nvram.o rtasd.o ras.o \ open_pic.o xics.o pSeries_htab.o rtas.o \ - chrp_setup.o i8259.o prom.o vio.o pSeries_iommu.o + chrp_setup.o i8259.o prom.o pSeries_iommu.o obj-$(CONFIG_PROC_FS) += proc_ppc64.o obj-$(CONFIG_RTAS_FLASH) += rtas_flash.o diff -ruN ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/dma.c ppc64-2.5-iseries.vio.1/arch/ppc64/kernel/dma.c --- ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/dma.c 2004-04-02 13:52:26.000000000 +1000 +++ ppc64-2.5-iseries.vio.1/arch/ppc64/kernel/dma.c 2004-04-02 13:53:18.000000000 +1000 @@ -5,14 +5,11 @@ * the pci and vio busses */ -#include #include #include /* Include the busses we support */ #include -#ifdef CONFIG_PPC_PSERIES #include -#endif #include #include @@ -20,10 +17,8 @@ { if (dev->bus == &pci_bus_type) return pci_dma_supported(to_pci_dev(dev), mask); -#ifdef CONFIG_PPC_PSERIES if (dev->bus == &vio_bus_type) return vio_dma_supported(to_vio_dev(dev), mask); -#endif BUG(); return 0; } @@ -33,10 +28,8 @@ { if (dev->bus == &pci_bus_type) return pci_set_dma_mask(to_pci_dev(dev), dma_mask); -#ifdef CONFIG_PPC_PSERIES if (dev->bus == &vio_bus_type) return vio_set_dma_mask(to_vio_dev(dev), dma_mask); -#endif BUG(); return 0; } @@ -47,10 +40,8 @@ { if (dev->bus == &pci_bus_type) return pci_alloc_consistent(to_pci_dev(dev), size, dma_handle); -#ifdef CONFIG_PPC_PSERIES if (dev->bus == &vio_bus_type) return vio_alloc_consistent(to_vio_dev(dev), size, dma_handle); -#endif BUG(); return 0; } @@ -61,10 +52,8 @@ { if (dev->bus == &pci_bus_type) pci_free_consistent(to_pci_dev(dev), size, cpu_addr, dma_handle); -#ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) vio_free_consistent(to_vio_dev(dev), size, cpu_addr, dma_handle); -#endif else BUG(); } @@ -75,10 +64,8 @@ { if (dev->bus == &pci_bus_type) return pci_map_single(to_pci_dev(dev), cpu_addr, size, (int)direction); -#ifdef CONFIG_PPC_PSERIES if (dev->bus == &vio_bus_type) return vio_map_single(to_vio_dev(dev), cpu_addr, size, direction); -#endif BUG(); return (dma_addr_t)0; } @@ -89,10 +76,8 @@ { if (dev->bus == &pci_bus_type) pci_unmap_single(to_pci_dev(dev), dma_addr, size, (int)direction); -#ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) vio_unmap_single(to_vio_dev(dev), dma_addr, size, direction); -#endif else BUG(); } @@ -104,10 +89,8 @@ { if (dev->bus == &pci_bus_type) return pci_map_page(to_pci_dev(dev), page, offset, size, (int)direction); -#ifdef CONFIG_PPC_PSERIES if (dev->bus == &vio_bus_type) return vio_map_page(to_vio_dev(dev), page, offset, size, direction); -#endif BUG(); return (dma_addr_t)0; } @@ -118,10 +101,8 @@ { if (dev->bus == &pci_bus_type) pci_unmap_page(to_pci_dev(dev), dma_address, size, (int)direction); -#ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) vio_unmap_page(to_vio_dev(dev), dma_address, size, direction); -#endif else BUG(); } @@ -132,10 +113,8 @@ { if (dev->bus == &pci_bus_type) return pci_map_sg(to_pci_dev(dev), sg, nents, (int)direction); -#ifdef CONFIG_PPC_PSERIES if (dev->bus == &vio_bus_type) return vio_map_sg(to_vio_dev(dev), sg, nents, direction); -#endif BUG(); return 0; } @@ -146,10 +125,8 @@ { if (dev->bus == &pci_bus_type) pci_unmap_sg(to_pci_dev(dev), sg, nhwentries, (int)direction); -#ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) vio_unmap_sg(to_vio_dev(dev), sg, nhwentries, direction); -#endif else BUG(); } @@ -160,10 +137,8 @@ { if (dev->bus == &pci_bus_type) pci_dma_sync_single(to_pci_dev(dev), dma_handle, size, (int)direction); -#ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) vio_dma_sync_single(to_vio_dev(dev), dma_handle, size, direction); -#endif else BUG(); } @@ -174,10 +149,8 @@ { if (dev->bus == &pci_bus_type) pci_dma_sync_sg(to_pci_dev(dev), sg, nelems, (int)direction); -#ifdef CONFIG_PPC_PSERIES else if (dev->bus == &vio_bus_type) vio_dma_sync_sg(to_vio_dev(dev), sg, nelems, direction); -#endif else BUG(); } diff -ruN ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/iSeries_iommu.c ppc64-2.5-iseries.vio.1/arch/ppc64/kernel/iSeries_iommu.c --- ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/iSeries_iommu.c 2004-04-02 13:52:30.000000000 +1000 +++ ppc64-2.5-iseries.vio.1/arch/ppc64/kernel/iSeries_iommu.c 2004-04-02 15:20:25.000000000 +1000 @@ -2,24 +2,24 @@ * arch/ppc64/kernel/iSeries_iommu.c * * Copyright (C) 2001 Mike Corrigan & Dave Engebretsen, IBM Corporation - * - * Rewrite, cleanup: + * + * Rewrite, cleanup: * * Copyright (C) 2004 Olof Johansson , IBM Corporation * * Dynamic DMA mapping support, iSeries-specific parts. * - * + * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. - * + * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. - * + * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA @@ -44,28 +44,12 @@ #include #include #include -#include #include #include "pci.h" -static struct iommu_table veth_iommu_table; /* Tce table for virtual ethernet */ -static struct iommu_table vio_iommu_table; /* Tce table for virtual I/O */ - -static struct iSeries_Device_Node veth_dev_node = { .LogicalSlot = 0xFF, .iommu_table = &veth_iommu_table }; -static struct iSeries_Device_Node vio_dev_node = { .LogicalSlot = 0xFF, .iommu_table = &vio_iommu_table }; - -static struct pci_dev _veth_dev = { .sysdata = &veth_dev_node }; -static struct pci_dev _vio_dev = { .sysdata = &vio_dev_node, .dev.bus = &pci_bus_type }; - -struct pci_dev *iSeries_veth_dev = &_veth_dev; -struct device *iSeries_vio_dev = &_vio_dev.dev; - -EXPORT_SYMBOL(iSeries_veth_dev); -EXPORT_SYMBOL(iSeries_vio_dev); - extern struct list_head iSeries_Global_Device_List; @@ -74,7 +58,7 @@ { u64 rc; union tce_entry tce; - + while (npages--) { tce.te_word = 0; tce.te_bits.tb_rpn = virt_to_abs(uaddr) >> PAGE_SHIFT; @@ -91,9 +75,9 @@ if (direction != DMA_TO_DEVICE) tce.te_bits.tb_pciwr = 1; } - - rc = HvCallXm_setTce((u64)tbl->it_index, - (u64)index, + + rc = HvCallXm_setTce((u64)tbl->it_index, + (u64)index, tce.te_word); if (rc) panic("PCI_DMA: HvCallXm_setTce failed, Rc: 0x%lx\n", rc); @@ -114,7 +98,7 @@ (u64)index, tce.te_word); - if (rc) + if (rc) panic("PCI_DMA: HvCallXm_setTce failed, Rc: 0x%lx\n", rc); index++; @@ -122,50 +106,10 @@ } -void __init iommu_vio_init(void) -{ - struct iommu_table *t; - struct iommu_table_cb cb; - unsigned long cbp; - - cb.itc_busno = 255; /* Bus 255 is the virtual bus */ - cb.itc_virtbus = 0xff; /* Ask for virtual bus */ - - cbp = virt_to_abs(&cb); - HvCallXm_getTceTableParms(cbp); - - veth_iommu_table.it_size = cb.itc_size / 2; - veth_iommu_table.it_busno = cb.itc_busno; - veth_iommu_table.it_offset = cb.itc_offset; - veth_iommu_table.it_index = cb.itc_index; - veth_iommu_table.it_type = TCE_VB; - veth_iommu_table.it_entrysize = sizeof(union tce_entry); - veth_iommu_table.it_blocksize = 1; - - t = iommu_init_table(&veth_iommu_table); - - if (!t) - printk("Virtual Bus VETH TCE table failed.\n"); - - vio_iommu_table.it_size = cb.itc_size - veth_iommu_table.it_size; - vio_iommu_table.it_busno = cb.itc_busno; - vio_iommu_table.it_offset = cb.itc_offset + - veth_iommu_table.it_size * (PAGE_SIZE/sizeof(union tce_entry)); - vio_iommu_table.it_index = cb.itc_index; - vio_iommu_table.it_type = TCE_VB; - vio_iommu_table.it_entrysize = sizeof(union tce_entry); - vio_iommu_table.it_blocksize = 1; - - t = iommu_init_table(&vio_iommu_table); - - if (!t) - printk("Virtual Bus VIO TCE table failed.\n"); -} - /* * This function compares the known tables to find an iommu_table - * that has already been built for hardware TCEs. + * that has already been built for hardware TCEs. */ static struct iommu_table *iommu_table_find(struct iommu_table * tbl) { @@ -173,26 +117,26 @@ for (dp = (struct iSeries_Device_Node *)iSeries_Global_Device_List.next; dp != (struct iSeries_Device_Node *)&iSeries_Global_Device_List; - dp = (struct iSeries_Device_Node *)dp->Device_List.next) + dp = (struct iSeries_Device_Node *)dp->Device_List.next) if (dp->iommu_table != NULL && dp->iommu_table->it_type == TCE_PCI && dp->iommu_table->it_offset == tbl->it_offset && dp->iommu_table->it_index == tbl->it_index && - dp->iommu_table->it_size == tbl->it_size) + dp->iommu_table->it_size == tbl->it_size) return dp->iommu_table; - + return NULL; } /* * Call Hv with the architected data structure to get TCE table info. - * info. Put the returned data into the Linux representation of the - * TCE table data. - * The Hardware Tce table comes in three flavors. - * 1. TCE table shared between Buses. - * 2. TCE table per Bus. - * 3. TCE Table per IOA. + * info. Put the returned data into the Linux representation of the + * TCE table data. + * The Hardware Tce table comes in three flavors. + * 1. TCE table shared between Buses. + * 2. TCE table per Bus. + * 3. TCE Table per IOA. */ static void iommu_table_getparms(struct iSeries_Device_Node* dn, struct iommu_table* tbl) @@ -201,7 +145,7 @@ parms = (struct iommu_table_cb*)kmalloc(sizeof(*parms), GFP_KERNEL); - if (parms == NULL) + if (parms == NULL) panic("PCI_DMA: TCE Table Allocation failed."); memset(parms, 0, sizeof(*parms)); diff -ruN ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/iSeries_pci.c ppc64-2.5-iseries.vio.1/arch/ppc64/kernel/iSeries_pci.c --- ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/iSeries_pci.c 2004-03-30 12:04:37.000000000 +1000 +++ ppc64-2.5-iseries.vio.1/arch/ppc64/kernel/iSeries_pci.c 2004-04-02 14:28:49.000000000 +1000 @@ -46,7 +46,6 @@ #include #include #include -#include #include "iSeries_IoMmTable.h" #include "pci.h" @@ -243,11 +242,6 @@ iSeries_IoMmTable_Status(); iSeries_activate_IRQs(); mf_displaySrc(0xC9000200); - - /* Now set up virtual bus device information */ - if (device_register(iSeries_vio_dev)) { - printk("pcibios error registering iSeries_vio_dev\n"); - } } void pcibios_fixup_bus(struct pci_bus *PciBus) diff -ruN ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/vio.c ppc64-2.5-iseries.vio.1/arch/ppc64/kernel/vio.c --- ppc64-2.5-iseries.dma.4/arch/ppc64/kernel/vio.c 2004-04-02 13:52:34.000000000 +1000 +++ ppc64-2.5-iseries.vio.1/arch/ppc64/kernel/vio.c 2004-04-02 14:38:03.000000000 +1000 @@ -25,6 +25,8 @@ #include #include #include +#include +#include #define DBGENTER() pr_debug("%s entered\n", __FUNCTION__) @@ -32,9 +34,31 @@ struct iommu_table *vio_build_iommu_table(struct vio_dev *dev); +#ifdef CONFIG_PPC_PSERIES static int vio_num_address_cells; +#endif static struct vio_dev *vio_bus_device; /* fake "parent" device */ +#ifdef CONFIG_PPC_ISERIES +static struct iommu_table veth_iommu_table; +static struct iommu_table vio_iommu_table; + +static struct vio_dev _veth_dev = { + .iommu_table = &veth_iommu_table, + .dev.bus = &vio_bus_type +}; +static struct vio_dev _vio_dev = { + .iommu_table = &vio_iommu_table, + .dev.bus = &vio_bus_type +}; + +struct vio_dev *iSeries_veth_dev = &_veth_dev; +struct device *iSeries_vio_dev = &_vio_dev.dev; + +EXPORT_SYMBOL(iSeries_veth_dev); +EXPORT_SYMBOL(iSeries_vio_dev); +#endif + /* convert from struct device to struct vio_dev and pass to driver. * dev->driver has already been set by generic code because vio_bus_match * succeeded. */ @@ -117,21 +141,67 @@ { DBGENTER(); +#ifdef CONFIG_PPC_PSERIES while (ids->type) { if ((strncmp(dev->archdata->type, ids->type, strlen(ids->type)) == 0) && device_is_compatible((struct device_node*)dev->archdata, ids->compat)) return ids; ids++; } +#endif return NULL; } +#ifdef CONFIG_PPC_ISERIES +void __init iommu_vio_init(void) +{ + struct iommu_table *t; + struct iommu_table_cb cb; + unsigned long cbp; + + cb.itc_busno = 255; /* Bus 255 is the virtual bus */ + cb.itc_virtbus = 0xff; /* Ask for virtual bus */ + + cbp = virt_to_abs(&cb); + HvCallXm_getTceTableParms(cbp); + + veth_iommu_table.it_size = cb.itc_size / 2; + veth_iommu_table.it_busno = cb.itc_busno; + veth_iommu_table.it_offset = cb.itc_offset; + veth_iommu_table.it_index = cb.itc_index; + veth_iommu_table.it_type = TCE_VB; + veth_iommu_table.it_entrysize = sizeof(union tce_entry); + veth_iommu_table.it_blocksize = 1; + + t = iommu_init_table(&veth_iommu_table); + + if (!t) + printk("Virtual Bus VETH TCE table failed.\n"); + + vio_iommu_table.it_size = cb.itc_size - veth_iommu_table.it_size; + vio_iommu_table.it_busno = cb.itc_busno; + vio_iommu_table.it_offset = cb.itc_offset + + veth_iommu_table.it_size * (PAGE_SIZE/sizeof(union tce_entry)); + vio_iommu_table.it_index = cb.itc_index; + vio_iommu_table.it_type = TCE_VB; + vio_iommu_table.it_entrysize = sizeof(union tce_entry); + vio_iommu_table.it_blocksize = 1; + + t = iommu_init_table(&vio_iommu_table); + + if (!t) + printk("Virtual Bus VIO TCE table failed.\n"); +} +#endif + /** * vio_bus_init: - Initialize the virtual IO bus */ static int __init vio_bus_init(void) { +#ifdef CONFIG_PPC_PSERIES struct device_node *node_vroot, *of_node; +#endif int err; err = bus_register(&vio_bus_type); @@ -156,6 +226,7 @@ return err; } +#ifdef CONFIG_PPC_PSERIES node_vroot = find_devices("vdevice"); if ((node_vroot == NULL) || (node_vroot->child == NULL)) { /* this machine doesn't do virtual IO, and that's ok */ @@ -175,6 +246,7 @@ vio_register_device(of_node); } +#endif return 0; } @@ -182,6 +254,7 @@ __initcall(vio_bus_init); +#ifdef CONFIG_PPC_PSERIES /* vio_dev refcount hit 0 */ static void __devinit vio_dev_release(struct device *dev) { @@ -412,6 +485,7 @@ return rc; } EXPORT_SYMBOL(vio_disable_interrupts); +#endif dma_addr_t vio_map_single(struct vio_dev *dev, void *vaddr, diff -ruN ppc64-2.5-iseries.dma.4/drivers/net/iseries_veth.c ppc64-2.5-iseries.vio.1/drivers/net/iseries_veth.c --- ppc64-2.5-iseries.dma.4/drivers/net/iseries_veth.c 2004-03-31 16:04:29.000000000 +1000 +++ ppc64-2.5-iseries.vio.1/drivers/net/iseries_veth.c 2004-04-02 14:32:02.000000000 +1000 @@ -78,10 +78,11 @@ #include #include #include +#include #include "iseries_veth.h" -extern struct pci_dev *iSeries_veth_dev; +extern struct vio_dev *iSeries_veth_dev; MODULE_AUTHOR("Kyle Lucke "); MODULE_DESCRIPTION("iSeries Virtual ethernet driver"); @@ -899,12 +900,12 @@ } dma_length = skb->len; - dma_address = pci_map_single(iSeries_veth_dev, skb->data, - dma_length, PCI_DMA_TODEVICE); + dma_address = vio_map_single(iSeries_veth_dev, skb->data, + dma_length, DMA_TO_DEVICE); /* Is it really necessary to check the length and address * fields of the first entry here? */ - if (!pci_dma_mapping_error(dma_address)) { + if (!vio_dma_mapping_error(dma_address)) { msg->skb = skb; msg->data.addr[0] = dma_address; msg->data.len[0] = dma_length; @@ -1028,8 +1029,8 @@ dma_address = myMsg->data.addr[0]; dma_length = myMsg->data.len[0]; - pci_unmap_single(iSeries_veth_dev, dma_address, dma_length, - PCI_DMA_TODEVICE); + vio_unmap_single(iSeries_veth_dev, dma_address, dma_length, + DMA_TO_DEVICE); if (myMsg->skb) { dev_kfree_skb_any(myMsg->skb); diff -ruN ppc64-2.5-iseries.dma.4/drivers/scsi/ibmvscsi/iseries_vscsi.c ppc64-2.5-iseries.vio.1/drivers/scsi/ibmvscsi/iseries_vscsi.c --- ppc64-2.5-iseries.dma.4/drivers/scsi/ibmvscsi/iseries_vscsi.c 2004-03-31 10:04:35.000000000 +1000 +++ ppc64-2.5-iseries.vio.1/drivers/scsi/ibmvscsi/iseries_vscsi.c 2004-04-02 14:38:57.000000000 +1000 @@ -32,17 +32,16 @@ #include #include #include -#include +#include #include #include "ibmvscsi.h" static void noop_release(struct device *dev) {}; /* global variables */ -extern struct device *iSeries_vio_dev; static struct ibmvscsi_host_data *single_host_data; -static struct pci_dev iseries_vscsi_dev = { - .dev.bus = &pci_bus_type, +static struct vio_dev iseries_vscsi_dev = { + .dev.bus = &vio_bus_type, .dev.bus_id = "vscsi", .dev.release = noop_release }; @@ -142,7 +141,7 @@ int __init ibmvscsi_module_init(void) { - iseries_vscsi_dev.sysdata = to_pci_dev(iSeries_vio_dev)->sysdata; + iseries_vscsi_dev.archdata = to_vio_dev(iSeries_vio_dev)->archdata; if (device_register(&iseries_vscsi_dev.dev)) { printk(KERN_ERR "ibmvscsi: failed to register device\n"); return 1; From hollisb at us.ibm.com Sat Apr 3 01:02:22 2004 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Fri, 2 Apr 2004 09:02:22 -0600 Subject: ppc64 cross-compiler on iSeries and stat() In-Reply-To: <20040402030856.GC6698@homesrv.constantdata.com> References: <20040327020111.GC18611@homesrv.constantdata.com> <20040327152244.GG18611@homesrv.constantdata.com> <20040328185417.GA25515@suse.de> <20040402030856.GC6698@homesrv.constantdata.com> Message-ID: On Apr 1, 2004, at 9:08 PM, Justin Banks wrote: > > I solved this problem. If anyone else cares how to compile a program > that needs to call stat() on iSeries using the cross-compiler, let > me know. I don't care in that I need to do it, but I care in that I'd like to know the resolution. If you're going to post to the mailing list, you might as well post the answer (rather than "email me for the answer")... -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Sat Apr 3 13:20:48 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Fri, 2 Apr 2004 21:20:48 -0600 (CST) Subject: NUMA memory block size Message-ID: Hi, Some of our new hardware has an LMB size of 16MB, which results in the memory device nodes covering only 16MB each. Right now the numa code will round up and down each device node to start at MEMORY_INCREMENT boundaries, which is 256MB (old LMB size). If the break between domains still happens on 256MB boundaries, things will go OK since the overlapped entries will just be skipped, but if the break is not on an even 256MB boundary bad things happen: ... memory region 72000000 to 73000000 maps to domain 0 memory region 73000000 to 74000000 maps to domain 1 ... This results in one 256MB region being added to both domains, since the 0x74000000 will be rounded down (and 0x70000000 is rounded up) Below patch fixes this by setting a 16MB MEMORY_INCREMENT instead. It sure helps on systems with 16MB LMB, but I don't have enough detail knowledge of the numa aspects to tell if it might break something else. Anyone else care to share wisdom? Anton? Dave? If there are no significant problems caused by this I'd like to feed this upstream soon. Thanks, Olof Olof Johansson Office: 4F005/905 Linux on Power Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ===== include/asm-ppc64/mmzone.h 1.18 vs edited ===== --- 1.18/include/asm-ppc64/mmzone.h Fri Mar 12 21:18:15 2004 +++ edited/include/asm-ppc64/mmzone.h Fri Apr 2 20:38:13 2004 @@ -25,7 +25,7 @@ #define MAX_MEMORY (1UL << 41) /* 256MB regions */ -#define MEMORY_INCREMENT_SHIFT 28 +#define MEMORY_INCREMENT_SHIFT 24 #define MEMORY_INCREMENT (1UL << MEMORY_INCREMENT_SHIFT) /* NUMA debugging, will not work on a DLPAR machine */ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Sat Apr 3 13:58:37 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Fri, 02 Apr 2004 19:58:37 -0800 Subject: NUMA memory block size In-Reply-To: References: Message-ID: <1080964716.8956.162.camel@nighthawk> On Fri, 2004-04-02 at 19:20, Olof Johansson wrote: ... > Below patch fixes this by setting a 16MB MEMORY_INCREMENT instead. It sure > helps on systems with 16MB LMB, but I don't have enough detail knowledge > of the numa aspects to tell if it might break something else. > > Anyone else care to share wisdom? Anton? Dave? > > If there are no significant problems caused by this I'd like to feed this > upstream soon. I don't see it doing much besides making that array 16 times bigger. It's right at 1MB now. I guess it will compress down, but that's an awful lot of uniform initialized variables to be sitting in an executable image. Should we leave it uninitialized and compile time, and run through the whole thing once we're booted up? > #define MAX_MEMORY (1UL << 41) > /* 256MB regions */ > -#define MEMORY_INCREMENT_SHIFT 28 > +#define MEMORY_INCREMENT_SHIFT 24 > #define MEMORY_INCREMENT (1UL << MEMORY_INCREMENT_SHIFT) Might want to change the 256MB comment :) Another place that CONFIG_NONLINEAR could be used, btw... -- Dave ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Sat Apr 3 16:50:13 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Sat, 3 Apr 2004 00:50:13 -0600 (CST) Subject: NUMA memory block size In-Reply-To: <1080964716.8956.162.camel@nighthawk> Message-ID: On Fri, 2 Apr 2004, Dave Hansen wrote: > On Fri, 2004-04-02 at 19:20, Olof Johansson wrote: > > If there are no significant problems caused by this I'd like to feed this > > upstream soon. > > I don't see it doing much besides making that array 16 times bigger. > It's right at 1MB now. I guess it will compress down, but that's an > awful lot of uniform initialized variables to be sitting in an > executable image. Should we leave it uninitialized and compile time, > and run through the whole thing once we're booted up? Yes, that's a big increase in wasted memory. Note that unless DEBUG_NUMA is defined, it's initialized to 0 so it'll go in the BSS anyway. Still, it needs a new solution since MAX_MEMORY will increase in the not so distant future too. A couple of questions pop up: 1. Why do we use a full int for node ID? It's quite unlikely that we will have 2 billion nodes anytime soon. Current limit is 16. :-) Switching to a char instead of int might be worth it. 2. A lmb_alloc() approach has the benefit of only allocating as much table as we actually have physical memory in the system. At least this way we'd only allocate in proportion to how much memory the machine has. 1MB table for a 2TB machine isn't too bad. On a 128GB system, size will be the same as before (32KB). I'll take it as a later todo to look at a better data structure for this, to avoid wasting too much space (but keep lookups fast). > Might want to change the 256MB comment :) DOH, yes. New patch below. -Olof ===== include/asm-ppc64/mmzone.h 1.18 vs edited ===== --- 1.18/include/asm-ppc64/mmzone.h Fri Mar 12 21:18:15 2004 +++ edited/include/asm-ppc64/mmzone.h Sat Apr 3 00:29:44 2004 @@ -19,13 +19,13 @@ */ extern int numa_cpu_lookup_table[]; -extern int numa_memory_lookup_table[]; +extern int *numa_memory_lookup_table; extern cpumask_t numa_cpumask_lookup_table[]; extern int nr_cpus_in_node[]; #define MAX_MEMORY (1UL << 41) -/* 256MB regions */ -#define MEMORY_INCREMENT_SHIFT 28 +/* 16MB regions */ +#define MEMORY_INCREMENT_SHIFT 24 #define MEMORY_INCREMENT (1UL << MEMORY_INCREMENT_SHIFT) /* NUMA debugging, will not work on a DLPAR machine */ ===== arch/ppc64/mm/numa.c 1.30 vs edited ===== --- 1.30/arch/ppc64/mm/numa.c Sat Mar 20 18:59:12 2004 +++ edited/arch/ppc64/mm/numa.c Sat Apr 3 00:31:46 2004 @@ -16,6 +16,7 @@ #include #include #include +#include #if 1 #define dbg(args...) udbg_printf(args) @@ -31,9 +32,7 @@ int numa_cpu_lookup_table[NR_CPUS] = { [ 0 ... (NR_CPUS - 1)] = ARRAY_INITIALISER}; -int numa_memory_lookup_table[MAX_MEMORY >> MEMORY_INCREMENT_SHIFT] = - { [ 0 ... ((MAX_MEMORY >> MEMORY_INCREMENT_SHIFT) - 1)] = - ARRAY_INITIALISER}; +int *numa_memory_lookup_table; cpumask_t numa_cpumask_lookup_table[MAX_NUMNODES]; int nr_cpus_in_node[MAX_NUMNODES] = { [0 ... (MAX_NUMNODES -1)] = 0}; @@ -65,12 +64,20 @@ int *memory_associativity; int depth; int max_domain = 0; + long entries = lmb_end_of_DRAM() >> MEMORY_INCREMENT_SHIFT; + long i; if (strstr(saved_command_line, "numa=off")) { printk(KERN_WARNING "NUMA disabled by user\n"); return -1; } + numa_memory_lookup_table = + (int *)abs_to_virt(lmb_alloc(entries * sizeof(int), 1)); + + for (i = 0; i < entries ; i++) + numa_memory_lookup_table[i] = ARRAY_INITIALISER; + cpu = of_find_node_by_type(NULL, "cpu"); if (!cpu) goto err; @@ -243,6 +250,14 @@ top_of_ram, total_ram); printk(KERN_INFO "Memory hole size: %ldMB\n", (top_of_ram - total_ram) >> 20); + + if (!numa_memory_lookup_table) { + long entries = top_of_ram >> MEMORY_INCREMENT_SHIFT; + numa_memory_lookup_table = + (int *)abs_to_virt(lmb_alloc(entries * sizeof(int), 1)); + for (i = 0; i < entries ; i++) + numa_memory_lookup_table[i] = ARRAY_INITIALISER; + } for (i = 0; i < NR_CPUS; i++) map_cpu_to_node(i, 0); ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Sat Apr 3 21:07:29 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Sat, 03 Apr 2004 03:07:29 -0800 Subject: NUMA memory block size In-Reply-To: References: Message-ID: <1080990449.8956.655.camel@nighthawk> On Fri, 2004-04-02 at 22:50, Olof Johansson wrote: > 1. Why do we use a full int for node ID? Because none of the other NUMA architectures have such insanely small mapping units :) > It's quite unlikely that we will > have 2 billion nodes anytime soon. Current limit is 16. :-) Switching to a > char instead of int might be worth it. Yep. Probably a good idea. > 2. A lmb_alloc() approach has the benefit of only allocating as much table > as we actually have physical memory in the system. At least this way we'd > only allocate in proportion to how much memory the machine has. 1MB table > for a 2TB machine isn't too bad. On a 128GB system, size will be the same > as before (32KB). How about using the bootmem_alloc() functions instead of the LMB ones? They're a bit more standard, and everyone else will realize what you're doing. That isn't too early, is it? > I'll take it as a later todo to look at a better data structure for this, > to avoid wasting too much space (but keep lookups fast). There's not a whole lot else you can do. In theory, each 16MB LMB could be going to any node. Any tree-based approach is just going to make the worst-case more cache misses than the 1 that it is now. I like wasting the space and keeping it dirt-simple. -- Dave ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Sat Apr 3 23:43:05 2004 From: anton at samba.org (Anton Blanchard) Date: Sat, 3 Apr 2004 23:43:05 +1000 Subject: NUMA memory block size In-Reply-To: References: <1080964716.8956.162.camel@nighthawk> Message-ID: <20040403134305.GK27453@krispykreme> > 1. Why do we use a full int for node ID? It's quite unlikely that we will > have 2 billion nodes anytime soon. Current limit is 16. :-) Switching to a > char instead of int might be worth it. Agreed, we should switch it to an unsigned char. > 2. A lmb_alloc() approach has the benefit of only allocating as much table > as we actually have physical memory in the system. At least this way we'd > only allocate in proportion to how much memory the machine has. 1MB table > for a 2TB machine isn't too bad. On a 128GB system, size will be the same > as before (32KB). This does add another load: ld 10,.LC1-.LCTOC1(30) /* numa_cpu_lookup_table */ sldi 8,8,2 li 0,17024 ld 7,.LC2-.LCTOC1(30) here ->ld 11,0(10) /* *numa_cpu_lookup_table */ lwax 9,8,11 But always allocating 128kB (2TB, 16MB segments, char for a node id) seems excessive so I like your idea of dynamically allocating the bitmap. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Sun Apr 4 03:48:04 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Sat, 3 Apr 2004 11:48:04 -0600 (CST) Subject: NUMA memory block size In-Reply-To: <1080990449.8956.655.camel@nighthawk> Message-ID: On Sat, 3 Apr 2004, Dave Hansen wrote: > On Fri, 2004-04-02 at 22:50, Olof Johansson wrote: > > How about using the bootmem_alloc() functions instead of the LMB ones? > They're a bit more standard, and everyone else will realize what you're > doing. That isn't too early, is it? I think it is. The array is built first thing in do_init_bootmem, so I wouldn't expect bootmem stuff to be available yet. > > I'll take it as a later todo to look at a better data structure for this, > > to avoid wasting too much space (but keep lookups fast). > > There's not a whole lot else you can do. In theory, each 16MB LMB could > be going to any node. Any tree-based approach is just going to make the > worst-case more cache misses than the 1 that it is now. I like wasting > the space and keeping it dirt-simple. Sure. -Olof ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Sun Apr 4 04:13:33 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Sat, 3 Apr 2004 12:13:33 -0600 (CST) Subject: NUMA memory block size In-Reply-To: <20040403134305.GK27453@krispykreme> Message-ID: On Sat, 3 Apr 2004, Anton Blanchard wrote: > > 1. Why do we use a full int for node ID? It's quite unlikely that we will > > have 2 billion nodes anytime soon. Current limit is 16. :-) Switching to a > > char instead of int might be worth it. > > Agreed, we should switch it to an unsigned char. If we switch it to a signed char, sign extension back to int will work properly for DEBUG_NUMA cases where entries are initialized to -1. 127 nodes is still plenty. > > 2. A lmb_alloc() approach has the benefit of only allocating as much table > > as we actually have physical memory in the system. At least this way we'd > > only allocate in proportion to how much memory the machine has. 1MB table > > for a 2TB machine isn't too bad. On a 128GB system, size will be the same > > as before (32KB). > > This does add another load: > > ld 10,.LC1-.LCTOC1(30) /* numa_cpu_lookup_table */ > sldi 8,8,2 > li 0,17024 > ld 7,.LC2-.LCTOC1(30) > here ->ld 11,0(10) /* *numa_cpu_lookup_table */ > lwax 9,8,11 > > But always allocating 128kB (2TB, 16MB segments, char for a node id) > seems excessive so I like your idea of dynamically allocating the > bitmap. Well, if it makes a visible impact on performance numbers we can always fall back to 128KB array. New (final?) patch below. -Olof ===== include/asm-ppc64/mmzone.h 1.18 vs edited ===== --- 1.18/include/asm-ppc64/mmzone.h Fri Mar 12 21:18:15 2004 +++ edited/include/asm-ppc64/mmzone.h Sat Apr 3 11:42:31 2004 @@ -19,13 +19,13 @@ */ extern int numa_cpu_lookup_table[]; -extern int numa_memory_lookup_table[]; +extern char *numa_memory_lookup_table; extern cpumask_t numa_cpumask_lookup_table[]; extern int nr_cpus_in_node[]; #define MAX_MEMORY (1UL << 41) -/* 256MB regions */ -#define MEMORY_INCREMENT_SHIFT 28 +/* 16MB regions */ +#define MEMORY_INCREMENT_SHIFT 24 #define MEMORY_INCREMENT (1UL << MEMORY_INCREMENT_SHIFT) /* NUMA debugging, will not work on a DLPAR machine */ ===== arch/ppc64/mm/numa.c 1.30 vs edited ===== --- 1.30/arch/ppc64/mm/numa.c Sat Mar 20 18:59:12 2004 +++ edited/arch/ppc64/mm/numa.c Sat Apr 3 11:42:10 2004 @@ -16,6 +16,7 @@ #include #include #include +#include #if 1 #define dbg(args...) udbg_printf(args) @@ -31,9 +32,7 @@ int numa_cpu_lookup_table[NR_CPUS] = { [ 0 ... (NR_CPUS - 1)] = ARRAY_INITIALISER}; -int numa_memory_lookup_table[MAX_MEMORY >> MEMORY_INCREMENT_SHIFT] = - { [ 0 ... ((MAX_MEMORY >> MEMORY_INCREMENT_SHIFT) - 1)] = - ARRAY_INITIALISER}; +char *numa_memory_lookup_table; cpumask_t numa_cpumask_lookup_table[MAX_NUMNODES]; int nr_cpus_in_node[MAX_NUMNODES] = { [0 ... (MAX_NUMNODES -1)] = 0}; @@ -65,12 +64,20 @@ int *memory_associativity; int depth; int max_domain = 0; + long entries = lmb_end_of_DRAM() >> MEMORY_INCREMENT_SHIFT; + long i; if (strstr(saved_command_line, "numa=off")) { printk(KERN_WARNING "NUMA disabled by user\n"); return -1; } + numa_memory_lookup_table = + (int *)abs_to_virt(lmb_alloc(entries * sizeof(char), 1)); + + for (i = 0; i < entries ; i++) + numa_memory_lookup_table[i] = ARRAY_INITIALISER; + cpu = of_find_node_by_type(NULL, "cpu"); if (!cpu) goto err; @@ -243,6 +250,14 @@ top_of_ram, total_ram); printk(KERN_INFO "Memory hole size: %ldMB\n", (top_of_ram - total_ram) >> 20); + + if (!numa_memory_lookup_table) { + long entries = top_of_ram >> MEMORY_INCREMENT_SHIFT; + numa_memory_lookup_table = + (int *)abs_to_virt(lmb_alloc(entries * sizeof(char), 1)); + for (i = 0; i < entries ; i++) + numa_memory_lookup_table[i] = ARRAY_INITIALISER; + } for (i = 0; i < NR_CPUS; i++) map_cpu_to_node(i, 0); ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Sun Apr 4 04:48:51 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Sat, 3 Apr 2004 12:48:51 -0600 (CST) Subject: NUMA memory block size In-Reply-To: Message-ID: > New (final?) patch below. I missed the change of int->char in the casts of return values from abs_to_virt(lmb_alloc()). It'll be fixed on any upstream-fed patch. -Olof ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Mon Apr 5 08:48:32 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 05 Apr 2004 08:48:32 +1000 Subject: NUMA memory block size In-Reply-To: References: Message-ID: <1081118911.1426.113.camel@gaston> On Sun, 2004-04-04 at 03:48, Olof Johansson wrote: > On Sat, 3 Apr 2004, Dave Hansen wrote: > > > On Fri, 2004-04-02 at 22:50, Olof Johansson wrote: > > > > How about using the bootmem_alloc() functions instead of the LMB ones? > > They're a bit more standard, and everyone else will realize what you're > > doing. That isn't too early, is it? > > I think it is. The array is built first thing in do_init_bootmem, so I > wouldn't expect bootmem stuff to be available yet. Still... That goes along with that work going on to clean up the interface between prom_init and the rest of the kernel. I haven't looked at the NUMA code proper in details yet, but at least one things that stinks with the current LMBs is that the same data struture (fixed array etc...) is used for the physical memory ranges detected _and_ reservation of early boot memory. >From experience, this is a huge waste of memory. A must small mecanism could/should be used for reserving ranges of memory. In fact, the whole thing could probably be killed in prom_init. By making sure that copy_device_tree() is done _last_ in prom_init(), it's fairly easy to _add_ OF nodes using OF "setprop" callback. The LMB for existing physical memory can be completely removed, they aren't useful at this point, a simple allocator can be built instead that parses the memory nodes to "find" areas, and creates a "linux,reserved" property in thoses with the reserved regions. Then, from MMU init for example, (or whatever C code that is run late enough to actually be out of the limited prom.c environment), the memory nodes can be parsed to build the proper data structures, it's even possible that we may have a working bootmem allocator at this point. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Mon Apr 5 13:19:41 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Sun, 04 Apr 2004 20:19:41 -0700 Subject: NUMA memory block size In-Reply-To: References: Message-ID: <1081135181.8956.1528.camel@nighthawk> On Sat, 2004-04-03 at 09:48, Olof Johansson wrote: > On Sat, 3 Apr 2004, Dave Hansen wrote: > > On Fri, 2004-04-02 at 22:50, Olof Johansson wrote: > > > > How about using the bootmem_alloc() functions instead of the LMB ones? > > They're a bit more standard, and everyone else will realize what you're > > doing. That isn't too early, is it? > > I think it is. The array is built first thing in do_init_bootmem, so I > wouldn't expect bootmem stuff to be available yet. Actually, I think that the ppc64 do_init_bootmem() overuses the LMB allocator a bit. Look at the regular do_init_bootmem() case in arch/ppc64/mm/init.c. It LMB-reserves the bootmem bitmap. But, look at the way i386 setup_memory() does it. It calls reserve_bootmem() *on* the bootmem bitmap itself just after bootmem has been set up. It's a bit counter-intuitive, but it obviously works. Now, the two approaches are made equivalent as soon as the loop to bootmem_reserve() of all of the LMB-reserved areas occur, but I think I like the i386 method better. Are there some {pa,page,pfn}_to_nid() operations that occur before the ppc64 do_init_bootmem()? I'm pretty sure there at least can't be any page_* operations yet because there's no mem_map, yet. If we can delay numa_memory_lookup_table[] until after the bootmem init is done, then it could be bootmem-alloc'd, and sized more appropriately for the actual memory amount. That reminds me. Are the htab sizes user-adjustable at all, or are they completely fixed in size by what the hardware wants? It would be really nice to be able to disable relocation as early as possible and avoid any of the klimit or lmb-style memory allocations and leave them all up to the arch-independent bootmem allocator. That's effectively what x86 does by having a few pagetable structures actually defined in the kernel image. -- Dave ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Mon Apr 5 19:42:41 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 05 Apr 2004 19:42:41 +1000 Subject: NUMA memory block size In-Reply-To: <1081135181.8956.1528.camel@nighthawk> References: <1081135181.8956.1528.camel@nighthawk> Message-ID: <1081158160.1286.139.camel@gaston> > That reminds me. Are the htab sizes user-adjustable at all, or are they > completely fixed in size by what the hardware wants? It would be really > nice to be able to disable relocation as early as possible and avoid any > of the klimit or lmb-style memory allocations and leave them all up to > the arch-independent bootmem allocator. That's effectively what x86 > does by having a few pagetable structures actually defined in the kernel > image. There are a few things that, unfortunately, have to be "allocated" early, that is when the OF client interface is still up. RTAS is one, I think TCE tables too, the hash table is a bit nasty as we need it up & running way before we get to setting up the bootmem. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From kravetz at us.ibm.com Tue Apr 6 03:36:11 2004 From: kravetz at us.ibm.com (Mike Kravetz) Date: Mon, 5 Apr 2004 10:36:11 -0700 Subject: NUMA memory block size In-Reply-To: References: <1080964716.8956.162.camel@nighthawk> Message-ID: <20040405173611.GA16339@w-mikek2.beaverton.ibm.com> On Sat, Apr 03, 2004 at 12:50:13AM -0600, Olof Johansson wrote: > > 2. A lmb_alloc() approach has the benefit of only allocating as much table > as we actually have physical memory in the system. > Yes and no (if I understand correctly). The lmb array is currently limited to 128 entries. In practice, most of the lmbs are physically contiguous so they are coalesced into a much smaller number. However, couldn't there be a worst case scenario where we could only support 128 16MB lmbs? Does anyone see a need to be concerned about this? -OR- Is this just too unlikely to occur? Does the hypervisor try to take this type of fragmentation into account? -- Mike ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Tue Apr 6 04:44:17 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Mon, 05 Apr 2004 13:44:17 -0500 Subject: NUMA memory block size In-Reply-To: <20040405173611.GA16339@w-mikek2.beaverton.ibm.com> References: <1080964716.8956.162.camel@nighthawk> <20040405173611.GA16339@w-mikek2.beaverton.ibm.com> Message-ID: <4071A901.7060507@austin.ibm.com> Mike Kravetz wrote: > On Sat, Apr 03, 2004 at 12:50:13AM -0600, Olof Johansson wrote: > >>2. A lmb_alloc() approach has the benefit of only allocating as much table >>as we actually have physical memory in the system. >> > > > Yes and no (if I understand correctly). The lmb array is currently > limited to 128 entries. In practice, most of the lmbs are physically > contiguous so they are coalesced into a much smaller number. However, > couldn't there be a worst case scenario where we could only support > 128 16MB lmbs? Does anyone see a need to be concerned about this? > -OR- Is this just too unlikely to occur? Does the hypervisor try to > take this type of fragmentation into account? (This is not directly related to the NUMA stuff though, since there's nothing in NUMA that stops the aggregation in the LMB layers. It's just that the "memory blocks" that numa keeps track of need to be small enough to reflect node id's on the same granularity that the system assigns them in.) I'm guessing the 128 LMB limit can be reached on a system with _very_ fragmented memory, such that the hypervisor can't allocate contigous LMBs more than a few in a row. I would be surprised if it happened in reality, but I guess one could always set up a testcase that will make it break. :-) -Olof -- Olof Johansson Office: 4F005/905 Linux on Power Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Tue Apr 6 07:46:20 2004 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Mon, 5 Apr 2004 16:46:20 -0500 Subject: [PATCH] move the iSeries virtual devices to vio In-Reply-To: <20040402153300.3895566b.sfr@canb.auug.org.au> References: <20040402153300.3895566b.sfr@canb.auug.org.au> Message-ID: <200404051646.20706.hollisb@us.ibm.com> On Thursday 01 April 2004 23:33, Stephen Rothwell wrote: > > This patch changes the iSeries virtual device drivers to use the > vio infrastructure for DMA mapping instead of the PCI infrastructure. > This is a ste alogn the way to integrating them correctly into the > driver model. Cool. :) The parts you ifdeffed from vio_bus_init() could be split into their own vio_arch_bus_init() couldn't they? Then ifdef the definition of that. Or make a vio_pseries_bus_init() and ifdef the call. Either way is just a little less mid-function ifdefs, which is probably a good thing. iSeries is a bit of a mystery to me still. :) I guess you don't ever call vio_register_*() then... I thought iSeries had its own vio_disable_interrupts()? Can't find it now, so maybe I'm misremembering. If it does though, that could be moved to vio.c as well. -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sfr at canb.auug.org.au Tue Apr 6 08:51:14 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Tue, 6 Apr 2004 08:51:14 +1000 (EST) Subject: [PATCH] move the iSeries virtual devices to vio Message-ID: <200404052251.i35MpE09002964@supreme.pcug.org.au> Hi Hollis, From: Hollis Blanchard > > On Thursday 01 April 2004 23:33, Stephen Rothwell wrote: > > > > This patch changes the iSeries virtual device drivers to use the > > vio infrastructure for DMA mapping instead of the PCI infrastructure. > > This is a ste alogn the way to integrating them correctly into the > > driver model. > > Cool. :) Thanks :-) > The parts you ifdeffed from vio_bus_init() could be split into their own > vio_arch_bus_init() couldn't they? Then ifdef the definition of that. Or make > a vio_pseries_bus_init() and ifdef the call. Either way is just a little less > mid-function ifdefs, which is probably a good thing. > > iSeries is a bit of a mystery to me still. :) I guess you don't ever call > vio_register_*() then... Mystery to me as well ... I don't call register (yet). > I thought iSeries had its own vio_disable_interrupts()? Can't find it now, so > maybe I'm misremembering. If it does though, that could be moved to vio.c as > well. Thanks for the comments, I will incorporate them soon. Small steps. :-) Cheers, Stephen Rothwell ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Wed Apr 7 05:35:56 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Tue, 6 Apr 2004 14:35:56 -0500 (CDT) Subject: [PATCH] Fix failure return codes from {pci,vio}_alloc_consistent() Message-ID: Hi, A bug snuck in during the rewrite of ppc64 IOMMU code. When a {pci,vio}_alloc_consistent() call fails, DMA_ERROR_CODE is returned instead of NULL. Please apply. Thanks, -Olof Olof Johansson Office: 4F005/905 Linux on Power Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ===== arch/ppc64/kernel/pci_iommu.c 1.5 vs edited ===== --- 1.5/arch/ppc64/kernel/pci_iommu.c Fri Apr 2 13:32:01 2004 +++ edited/arch/ppc64/kernel/pci_iommu.c Tue Apr 6 14:21:31 2004 @@ -83,7 +83,7 @@ if (order >= IOMAP_MAX_ORDER) { printk("PCI_DMA: pci_alloc_consistent size too large: 0x%lx\n", size); - return (void *)DMA_ERROR_CODE; + return NULL; } tbl = devnode_table(hwdev); ===== arch/ppc64/kernel/vio.c 1.14 vs edited ===== --- 1.14/arch/ppc64/kernel/vio.c Fri Apr 2 13:32:01 2004 +++ edited/arch/ppc64/kernel/vio.c Tue Apr 6 14:31:47 2004 @@ -504,8 +504,8 @@ /* Client asked for way to much space. This is checked later anyway */ /* It is easier to debug here for the drivers than in the tce tables.*/ if(order >= IOMAP_MAX_ORDER) { - printk("VIO_DMA: vio_alloc_consistent size to large: 0x%lx \n", size); - return (void *)DMA_ERROR_CODE; + printk("VIO_DMA: vio_alloc_consistent size too large: 0x%lx \n", size); + return NULL; } tbl = dev->iommu_table; ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Wed Apr 7 07:20:35 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Tue, 06 Apr 2004 16:20:35 -0500 Subject: RAS uses RTAS arguments that might be above RMO/4GB Message-ID: <40731F23.5080805@austin.ibm.com> The EPOW stuff in ras.c passes pointers from the stack into RTAS. There's a risk that they end up above 4GB and/or above RMO, which makes RTAS choke. We're seeing a couple of these at the moment, so I'd like to fix this to rule it out. Does attached patch look sane? I'm not 100% sure what context it might be called from, but I figured doing local structure copies is safer than holding the lock over log_error(). Thanks. -Olof -- Olof Johansson Office: 4F005/905 Linux on Power Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ras-log-buf Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040406/38e46324/attachment.txt From olof at austin.ibm.com Wed Apr 7 08:33:26 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Tue, 06 Apr 2004 17:33:26 -0500 Subject: RAS uses RTAS arguments that might be above RMO/4GB In-Reply-To: <40731F23.5080805@austin.ibm.com> References: <40731F23.5080805@austin.ibm.com> Message-ID: <40733036.2060504@austin.ibm.com> Olof Johansson wrote: > Does attached patch look sane? I'm not 100% sure what context it might > be called from, but I figured doing local structure copies is safer than > holding the lock over log_error(). DOH, that doesn't even build. Change "spin_lock log_lock" to "spinlock_t log_lock". -Olof -- Olof Johansson Office: 4F005/905 Linux on Power Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Thu Apr 8 03:04:42 2004 From: greg at kroah.com (Greg KH) Date: Wed, 7 Apr 2004 10:04:42 -0700 Subject: PCI Hotplug Slot Naming Scheme In-Reply-To: <40731ECC.4090606@ltcfwd.linux.ibm.com> References: <40731ECC.4090606@ltcfwd.linux.ibm.com> Message-ID: <20040407170442.GF19083@kroah.com> On Tue, Apr 06, 2004 at 04:19:08PM -0500, Linda Xie wrote: > Hi Greg, > > Since php core exepects an u32 address value from a php driver and it > converts the value > into "%04x:%02x:%02x" string, we can't use "address" attribute file to > store the physical > location of a slot (in our case it is a long string like > "U7311.D11.104CE9A-P1-C2" ). > > I'd like to know if we can add a new attribute file called > "phy_location" or "location" for storing > physical location (a regular ASCII string) of a slot. Sure, I don't have a problem with that. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Thu Apr 8 11:49:21 2004 From: anton at samba.org (Anton Blanchard) Date: Thu, 8 Apr 2004 11:49:21 +1000 Subject: [PATCH] KDB updates to Ameslab - includes kallsyms, tce and sstep fixes In-Reply-To: <20040407143005.GA794@in.ibm.com> References: <20040407143005.GA794@in.ibm.com> Message-ID: <20040408014921.GB18493@krispykreme> Hi Ananth, > Here is a consolidated patch for KDB on Ameslab. The patch includes: Thanks. Applied. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sfr at canb.auug.org.au Thu Apr 8 14:51:08 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 8 Apr 2004 14:51:08 +1000 Subject: [PATCH] remove vio_dma_mapping_error Message-ID: <20040408145108.4d6e8087.sfr@canb.auug.org.au> Hi Anton, James Bottomley is right, this was a mistake. This patch replaces vio_dma_mapping_error with dma_mapping_error everywhere. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- diff -ruN ppc64-2.5-iseries.vio.1/drivers/net/ibmveth.c ppc64-2.5-iseries.vio.1.dma.5/drivers/net/ibmveth.c --- ppc64-2.5-iseries.vio.1/drivers/net/ibmveth.c 2004-04-04 17:04:43.000000000 +1000 +++ ppc64-2.5-iseries.vio.1.dma.5/drivers/net/ibmveth.c 2004-04-08 14:23:17.000000000 +1000 @@ -405,7 +405,7 @@ static void ibmveth_cleanup(struct ibmveth_adapter *adapter) { if(adapter->buffer_list_addr != NULL) { - if(!vio_dma_mapping_error(adapter->buffer_list_dma)) { + if(!dma_mapping_error(adapter->buffer_list_dma)) { vio_unmap_single(adapter->vdev, adapter->buffer_list_dma, 4096, PCI_DMA_BIDIRECTIONAL); adapter->buffer_list_dma = DMA_ERROR_CODE; } @@ -414,7 +414,7 @@ } if(adapter->filter_list_addr != NULL) { - if(!vio_dma_mapping_error(adapter->filter_list_dma)) { + if(!dma_mapping_error(adapter->filter_list_dma)) { vio_unmap_single(adapter->vdev, adapter->filter_list_dma, 4096, PCI_DMA_BIDIRECTIONAL); adapter->filter_list_dma = DMA_ERROR_CODE; } @@ -423,7 +423,7 @@ } if(adapter->rx_queue.queue_addr != NULL) { - if(!vio_dma_mapping_error(adapter->rx_queue.queue_dma)) { + if(!dma_mapping_error(adapter->rx_queue.queue_dma)) { vio_unmap_single(adapter->vdev, adapter->rx_queue.queue_dma, adapter->rx_queue.queue_len, PCI_DMA_BIDIRECTIONAL); adapter->rx_queue.queue_dma = DMA_ERROR_CODE; } @@ -474,9 +474,9 @@ adapter->filter_list_dma = vio_map_single(adapter->vdev, adapter->filter_list_addr, 4096, PCI_DMA_BIDIRECTIONAL); adapter->rx_queue.queue_dma = vio_map_single(adapter->vdev, adapter->rx_queue.queue_addr, adapter->rx_queue.queue_len, PCI_DMA_BIDIRECTIONAL); - if((vio_dma_mapping_error(adapter->buffer_list_dma) ) || - (vio_dma_mapping_error(adapter->filter_list_dma)) || - (vio_dma_mapping_error(adapter->rx_queue.queue_dma))) { + if((dma_mapping_error(adapter->buffer_list_dma) ) || + (dma_mapping_error(adapter->filter_list_dma)) || + (dma_mapping_error(adapter->rx_queue.queue_dma))) { ibmveth_error_printk("unable to map filter or buffer list pages\n"); ibmveth_cleanup(adapter); return -ENOMEM; @@ -645,7 +645,7 @@ desc[0].fields.address = vio_map_single(adapter->vdev, skb->data, desc[0].fields.length, PCI_DMA_TODEVICE); desc[0].fields.valid = 1; - if(vio_dma_mapping_error(desc[0].fields.address)) { + if(dma_mapping_error(desc[0].fields.address)) { ibmveth_error_printk("tx: unable to map initial fragment\n"); adapter->tx_map_failed++; adapter->stats.tx_dropped++; @@ -664,7 +664,7 @@ desc[curfrag+1].fields.length = frag->size; desc[curfrag+1].fields.valid = 1; - if(vio_dma_mapping_error(desc[curfrag+1].fields.address)) { + if(dma_mapping_error(desc[curfrag+1].fields.address)) { ibmveth_error_printk("tx: unable to map fragment %d\n", curfrag); adapter->tx_map_failed++; adapter->stats.tx_dropped++; diff -ruN ppc64-2.5-iseries.vio.1/drivers/net/iseries_veth.c ppc64-2.5-iseries.vio.1.dma.5/drivers/net/iseries_veth.c --- ppc64-2.5-iseries.vio.1/drivers/net/iseries_veth.c 2004-04-02 14:32:02.000000000 +1000 +++ ppc64-2.5-iseries.vio.1.dma.5/drivers/net/iseries_veth.c 2004-04-08 14:22:38.000000000 +1000 @@ -905,7 +905,7 @@ /* Is it really necessary to check the length and address * fields of the first entry here? */ - if (!vio_dma_mapping_error(dma_address)) { + if (!dma_mapping_error(dma_address)) { msg->skb = skb; msg->data.addr[0] = dma_address; msg->data.len[0] = dma_length; diff -ruN ppc64-2.5-iseries.vio.1/drivers/scsi/ibmvscsi/ibmvscsis.c ppc64-2.5-iseries.vio.1.dma.5/drivers/scsi/ibmvscsi/ibmvscsis.c --- ppc64-2.5-iseries.vio.1/drivers/scsi/ibmvscsi/ibmvscsis.c 2004-04-02 13:52:26.000000000 +1000 +++ ppc64-2.5-iseries.vio.1.dma.5/drivers/scsi/ibmvscsi/ibmvscsis.c 2004-04-08 14:23:31.000000000 +1000 @@ -1862,7 +1862,7 @@ queue->size * sizeof(*queue->msgs), DMA_BIDIRECTIONAL); - if (vio_dma_mapping_error(queue->msg_token)) + if (dma_mapping_error(queue->msg_token)) goto map_failed; rc = plpar_hcall_norets(H_REG_CRQ, adapter->dma_dev->unit_address, queue->msg_token, PAGE_SIZE); diff -ruN ppc64-2.5-iseries.vio.1/include/asm-ppc64/vio.h ppc64-2.5-iseries.vio.1.dma.5/include/asm-ppc64/vio.h --- ppc64-2.5-iseries.vio.1/include/asm-ppc64/vio.h 2004-04-02 13:52:26.000000000 +1000 +++ ppc64-2.5-iseries.vio.1.dma.5/include/asm-ppc64/vio.h 2004-04-08 14:26:43.000000000 +1000 @@ -137,9 +137,4 @@ return container_of(dev, struct vio_dev, dev); } -static inline int vio_dma_mapping_error(dma_addr_t dma_addr) -{ - return dma_mapping_error(dma_addr); -} - #endif /* _ASM_VIO_H */ From nitin at in.ibm.com Thu Apr 8 16:05:40 2004 From: nitin at in.ibm.com (Nitin Vashisth) Date: 08 Apr 2004 11:35:40 +0530 Subject: [PATCH] ssb fix for KDB Message-ID: <1081404340.2217.14.camel@kumbhkaran.in.ibm.com> Hello, Here is a patch to fix single step till branch command in kdb. Best Regards, Nitin. -- Nitin Vashisth Linux Technology Center IBM Software Lab Bangalore, INDIA Direct 91-80-2504 4611 Board 91-80-2526 2355 / 7117 Extension 3611. diff -Narup ameslab/arch/ppc64/kdb/kdba_bp.c ameslab-new/arch/ppc64/kdb/kdba_bp.c --- ameslab/arch/ppc64/kdb/kdba_bp.c 2004-03-22 14:17:52.000000000 +0530 +++ ameslab-new/arch/ppc64/kdb/kdba_bp.c 2004-04-06 13:32:53.000000000 +0530 @@ -152,27 +152,27 @@ kdba_db_trap(kdb_eframe_t ef, int error_ /* single step */ rv = KDB_DB_SS; /* Indicate single step */ if (KDB_STATE(DOING_SSB)) { - unsigned long instruction; + unsigned long instruction; kdb_id1(ef->nip); kdb_getarea(instruction,ef->nip); - primary=instruction & 0xfc000000; - extended=instruction & 0x000007fe; - if (kdb_getarea(instruction, ef->nip) || /* read failure */ -/* branch conditional */ - (primary==16 )|| -/* branch */ - (primary==18 )|| -/* branch conditional to LR, or branch conditional to CR */ - (primary==19 && (extended==16 || extended == 528) - )) { + primary=instruction & 0xfc00000000000000; + extended=instruction & 0x000007fe00000000; + if ((primary == 0x4800000000000000) || + (primary == 0x4000000000000000) || + ((primary == 0x4c00000000000000) && + ((extended == 0x0000042000000000) || + (extended == 0x0000002000000000)))) { /* * End the ssb command here. */ - KDB_STATE_CLEAR(DOING_SSB); - KDB_STATE_CLEAR(DOING_SS); - } - rv = KDB_DB_SSB; /* Indicate ssb - dismiss immediately */ + KDB_STATE_CLEAR(DOING_SSB); + KDB_STATE_CLEAR(DOING_SS); + } else { + char *argv[] = {"ssb", NULL}; + rv = KDB_DB_SSB; /* Indicate ssb - dismiss immediately */ + kdb_ss(0, (char **)argv, NULL, ef); + } } else { /* * Print current insn diff -Narup ameslab/arch/ppc64/kdb/kdbasupport.c ameslab-new/arch/ppc64/kdb/kdbasupport.c --- ameslab/arch/ppc64/kdb/kdbasupport.c 2004-03-22 14:17:52.000000000 +0530 +++ ameslab-new/arch/ppc64/kdb/kdbasupport.c 2004-04-06 12:02:59.000000000 +0530 @@ -548,8 +548,9 @@ kdba_setsinglestep(struct pt_regs *regs) void kdba_clearsinglestep(struct pt_regs *regs) { - - regs->msr &= ~MSR_SE; + if (!KDB_STATE(DOING_SSB)) { + regs->msr &= ~MSR_SE; + } } int ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Thu Apr 8 16:32:57 2004 From: anton at samba.org (Anton Blanchard) Date: Thu, 8 Apr 2004 16:32:57 +1000 Subject: [PATCH] ssb fix for KDB In-Reply-To: <1081404340.2217.14.camel@kumbhkaran.in.ibm.com> References: <1081404340.2217.14.camel@kumbhkaran.in.ibm.com> Message-ID: <20040408063257.GD18493@krispykreme> > Here is a patch to fix single step till branch command in kdb. Thanks, applied. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Thu Apr 8 17:39:11 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 08 Apr 2004 17:39:11 +1000 Subject: Some hash table races (ouch !) Message-ID: <1081409951.1403.102.camel@gaston> While looking for a different problems, I spotted a subtle race that can be caused by ptep_test_and_clar_* removing the HASHPTE bit from a PTE while leaving this in the hash table. The simple fix is to not remove the HASHPTE bit since it's perfectly safe to evict an entry without clearing the HASHPTE bit (the opposite isn't though). I also slightly optimized those routines so they don't do the atomic operation nor the flush when not necessary. Tests appreciated before I push upstream Ben. ===== include/asm-ppc64/pgtable.h 1.31 vs edited ===== --- 1.31/include/asm-ppc64/pgtable.h Fri Feb 27 23:16:07 2004 +++ edited/include/asm-ppc64/pgtable.h Thu Apr 8 17:30:57 2004 @@ -313,7 +313,9 @@ { unsigned long old; - old = pte_update(ptep, _PAGE_ACCESSED | _PAGE_HPTEFLAGS); + if ((pte_val(*ptep) & (_PAGE_ACCESSED | _PAGE_HASHPTE)) == 0) + return 0; + old = pte_update(ptep, _PAGE_ACCESSED); if (old & _PAGE_HASHPTE) { hpte_update(ptep, old, 0); flush_tlb_pending(); /* XXX generic code doesn't flush */ @@ -326,12 +328,13 @@ * moment we always flush but we need to fix hpte_update and test if the * optimisation is worth it. */ -#if 1 static inline int ptep_test_and_clear_dirty(pte_t *ptep) { unsigned long old; - old = pte_update(ptep, _PAGE_DIRTY | _PAGE_HPTEFLAGS); + if ((pte_val(*ptep) & _PAGE_DIRTY) == 0) + return 0; + old = pte_update(ptep, _PAGE_DIRTY); if (old & _PAGE_HASHPTE) hpte_update(ptep, old, 0); return (old & _PAGE_DIRTY) != 0; @@ -341,7 +344,9 @@ { unsigned long old; - old = pte_update(ptep, _PAGE_RW | _PAGE_HPTEFLAGS); + if ((pte_val(*ptep) & _PAGE_RW) == 0) + return; + old = pte_update(ptep, _PAGE_RW); if (old & _PAGE_HASHPTE) hpte_update(ptep, old, 0); } @@ -358,7 +363,6 @@ #define ptep_clear_flush_young(__vma, __address, __ptep) \ ({ \ int __young = ptep_test_and_clear_young(__ptep); \ - flush_tlb_page(__vma, __address); \ __young; \ }) @@ -369,27 +373,6 @@ flush_tlb_page(__vma, __address); \ __dirty; \ }) - -#else -static inline int ptep_test_and_clear_dirty(pte_t *ptep) -{ - unsigned long old; - - old = pte_update(ptep, _PAGE_DIRTY); - if ((~old & (_PAGE_HASHPTE | _PAGE_RW | _PAGE_DIRTY)) == 0) - hpte_update(ptep, old, 1); - return (old & _PAGE_DIRTY) != 0; -} - -static inline void ptep_set_wrprotect(pte_t *ptep) -{ - unsigned long old; - - old = pte_update(ptep, _PAGE_RW); - if ((~old & (_PAGE_HASHPTE | _PAGE_RW | _PAGE_DIRTY)) == 0) - hpte_update(ptep, old, 1); -} -#endif static inline pte_t ptep_get_and_clear(pte_t *ptep) { ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From meissner at suse.de Fri Apr 9 00:26:19 2004 From: meissner at suse.de (Marcus Meissner) Date: Thu, 8 Apr 2004 16:26:19 +0200 Subject: eeh patch Message-ID: <20040408142619.GA11173@suse.de> Hi, Trivial eeh patch, drivers/pci/hotplug/rpaphp.ko needs it. Ciao, Marcus --- arch/ppc64/kernel/eeh.c.blub 2004-04-08 14:23:43.000000000 +0000 +++ arch/ppc64/kernel/eeh.c 2004-04-08 14:23:22.000000000 +0000 @@ -396,6 +396,7 @@ { eeh_disable_slot = func; } +EXPORT_SYMBOL(eeh_register_disable_func); /** * eeh_event_handler - handle any eeh events to see if we can disable ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From willy at debian.org Fri Apr 9 02:43:02 2004 From: willy at debian.org (Matthew Wilcox) Date: Thu, 8 Apr 2004 17:43:02 +0100 Subject: [Pcihpd-discuss] Re: PCI Hotplug Slot Naming Scheme In-Reply-To: <20040407170442.GF19083@kroah.com> References: <40731ECC.4090606@ltcfwd.linux.ibm.com> <20040407170442.GF19083@kroah.com> Message-ID: <20040408164302.GF18329@parcelfarce.linux.theplanet.co.uk> On Wed, Apr 07, 2004 at 10:04:42AM -0700, Greg KH wrote: > On Tue, Apr 06, 2004 at 04:19:08PM -0500, Linda Xie wrote: > > > > Since php core exepects an u32 address value from a php driver and > > it converts the value into "%04x:%02x:%02x" string, we can't use > > "address" attribute file to store the physical location of a slot > > (in our case it is a long string like "U7311.D11.104CE9A-P1-C2" ). Why not name the slot this in the first place? > > I'd like to know if we can add a new attribute file called > > "phy_location" or "location" for storing physical location (a > > regular ASCII string) of a slot. > > Sure, I don't have a problem with that. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Fri Apr 9 02:48:10 2004 From: greg at kroah.com (Greg KH) Date: Thu, 8 Apr 2004 09:48:10 -0700 Subject: [Pcihpd-discuss] Re: PCI Hotplug Slot Naming Scheme In-Reply-To: <20040408164302.GF18329@parcelfarce.linux.theplanet.co.uk> References: <40731ECC.4090606@ltcfwd.linux.ibm.com> <20040407170442.GF19083@kroah.com> <20040408164302.GF18329@parcelfarce.linux.theplanet.co.uk> Message-ID: <20040408164810.GA10146@kroah.com> On Thu, Apr 08, 2004 at 05:43:02PM +0100, Matthew Wilcox wrote: > On Wed, Apr 07, 2004 at 10:04:42AM -0700, Greg KH wrote: > > On Tue, Apr 06, 2004 at 04:19:08PM -0500, Linda Xie wrote: > > > Hi Greg, > > > > > > Since php core exepects an u32 address value from a php driver and it > > > converts the value > > > into "%04x:%02x:%02x" string, we can't use "address" attribute file to > > > store the physical > > > location of a slot (in our case it is a long string like > > > "U7311.D11.104CE9A-P1-C2" ). > > Why not name the slot this in the first place? Ugh, read the whole thread about this to see why that's not a good idea. greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Fri Apr 9 23:21:27 2004 From: anton at samba.org (Anton Blanchard) Date: Fri, 9 Apr 2004 23:21:27 +1000 Subject: HVC explosion Message-ID: <20040409132127.GG18493@krispykreme> My 630 LPAR is decidedly unhappy with the latest batch of hvc updates. This is just a warning. Your patch is not OK :) Anton Freeing unused kernel memory: 312k freed Uninitialised timer! This is just a warning. Your computer is OK function=0x0000000000000000, data=0x0 Call Trace: [c00000000006c2d8] .del_timer_sync+0x44/0x11c [c0000000002635e0] .hvc_close+0x108/0x17c [c000000000249224] .release_dev+0x3c4/0x89c [c00000000024977c] .tty_release+0x80/0x124 [c0000000000b9d88] .__fput+0x238/0x268 [c0000000000b5924] .filp_close+0x90/0x128 [c0000000000b5aa8] .sys_close+0xec/0x170 [c00000000001063c] .ret_from_syscall_1+0x0/0xa4 Uninitialised timer! This is just a warning. Your computer is OK function=0x0000000000000000, data=0x0 Call Trace: [c00000000006c2d8] .del_timer_sync+0x44/0x11c [c0000000002635ec] .hvc_close+0x114/0x17c [c000000000249224] .release_dev+0x3c4/0x89c [c00000000024977c] .tty_release+0x80/0x124 [c0000000000b9d88] .__fput+0x238/0x268 [c0000000000b5924] .filp_close+0x90/0x128 [c0000000000b5aa8] .sys_close+0xec/0x170 [c00000000001063c] .ret_from_syscall_1+0x0/0xa4 INIT: kernel BUG in queue_delayed_work at kernel/workqueue.c:127! cpu 0: Vector: 700 (Program Check) at [c00000003fd2f5a0] pc: c000000000078494 (.queue_delayed_work+0x88/0xd4) lr: c000000000263474 (.hvc_write+0x618/0x67c) sp: c00000003fd2f820 msr: 8000000000021032 current = 0xc000000005edf240 paca = 0xc000000000588000 pid = 1, comm = init press ? for help 0:mon> ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Sat Apr 10 01:11:27 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 09 Apr 2004 10:11:27 -0500 Subject: HVC explosion In-Reply-To: <20040409132127.GG18493@krispykreme> References: <20040409132127.GG18493@krispykreme> Message-ID: <1081523488.27192.85.camel@SigurRos.rchland.ibm.com> On Fri, 2004-04-09 at 08:21, Anton Blanchard wrote: > > My 630 LPAR is decidedly unhappy with the latest batch of hvc updates. > This is just a warning. Your patch is not OK :) > > Anton > I put in the patch so I'll take a look. Ryan Arnold IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Sat Apr 10 01:46:17 2004 From: greg at kroah.com (Greg KH) Date: Fri, 9 Apr 2004 08:46:17 -0700 Subject: HVC explosion In-Reply-To: <1081523488.27192.85.camel@SigurRos.rchland.ibm.com> References: <20040409132127.GG18493@krispykreme> <1081523488.27192.85.camel@SigurRos.rchland.ibm.com> Message-ID: <20040409154617.GA14667@kroah.com> On Fri, Apr 09, 2004 at 10:11:27AM -0500, Ryan Arnold wrote: > > On Fri, 2004-04-09 at 08:21, Anton Blanchard wrote: > > > > My 630 LPAR is decidedly unhappy with the latest batch of hvc updates. > > This is just a warning. Your patch is not OK :) > > > > Anton > > > I put in the patch so I'll take a look. I recommend backing that whole patch out now, as it was not reviewed by anyone. Yes, it was posted to lkml months ago, but there was no followup patch based on all of the comments given. Please, post your work publicly. Don't try to slip it in the tree because of a deadline or any other reason. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Sat Apr 10 02:38:54 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 09 Apr 2004 11:38:54 -0500 Subject: HVC explosion In-Reply-To: <20040409154617.GA14667@kroah.com> References: <20040409132127.GG18493@krispykreme> <1081523488.27192.85.camel@SigurRos.rchland.ibm.com> <20040409154617.GA14667@kroah.com> Message-ID: <1081528736.27192.88.camel@SigurRos.rchland.ibm.com> On Fri, 2004-04-09 at 10:46, Greg KH wrote: > I recommend backing that whole patch out now, as it was not reviewed by > anyone. > > Yes, it was posted to lkml months ago, but there was no followup patch > based on all of the comments given. > > Please, post your work publicly. Don't try to slip it in the tree > because of a deadline or any other reason. > > thanks, > > greg k-h The hvcs portion of this patch is not what is broken. I included some unrelated hvc_console fixes in the patch which is what seems to be broken. Ryan Arnold ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Sat Apr 10 02:53:02 2004 From: greg at kroah.com (Greg KH) Date: Fri, 9 Apr 2004 09:53:02 -0700 Subject: HVC explosion In-Reply-To: <1081528736.27192.88.camel@SigurRos.rchland.ibm.com> References: <20040409132127.GG18493@krispykreme> <1081523488.27192.85.camel@SigurRos.rchland.ibm.com> <20040409154617.GA14667@kroah.com> <1081528736.27192.88.camel@SigurRos.rchland.ibm.com> Message-ID: <20040409165302.GD14961@kroah.com> On Fri, Apr 09, 2004 at 11:38:54AM -0500, Ryan Arnold wrote: > > On Fri, 2004-04-09 at 10:46, Greg KH wrote: > > > I recommend backing that whole patch out now, as it was not reviewed by > > anyone. > > > > Yes, it was posted to lkml months ago, but there was no followup patch > > based on all of the comments given. > > > > Please, post your work publicly. Don't try to slip it in the tree > > because of a deadline or any other reason. > > > > thanks, > > > > greg k-h > The hvcs portion of this patch is not what is broken. I included some > unrelated hvc_console fixes in the patch which is what seems to be > broken. Either way, you pushed code to the repository that was not vetted by anyone. Bad form. greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jschopp at austin.ibm.com Sat Apr 10 05:18:20 2004 From: jschopp at austin.ibm.com (jschopp at austin.ibm.com) Date: Fri, 9 Apr 2004 14:18:20 -0500 (CDT) Subject: [PATCH] code cleanup Message-ID: I was looking at rtas serialization for reasons I won't go into here. While wandering through the code I found that two functions were not properly serialized. phys_call_rtas and phys_call_rtas_display_status are the functions. After looking further they are redundant and not used anywhere at all. Does anybody know of a reason not to remove these functions? A patch below removes them, unless I hear some objections I will push it early next week. -Joel Schopp # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1562 -> 1.1563 # arch/ppc64/kernel/rtas.c 1.37 -> 1.38 # include/asm-ppc64/rtas.h 1.23 -> 1.24 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/04/09 jschopp at threadlp13.austin.ibm.com 1.1563 # Remove a couple of unused, unnecessary functions. # -------------------------------------------- # diff -Nru a/arch/ppc64/kernel/rtas.c b/arch/ppc64/kernel/rtas.c --- a/arch/ppc64/kernel/rtas.c Fri Apr 9 14:04:10 2004 +++ b/arch/ppc64/kernel/rtas.c Fri Apr 9 14:04:10 2004 @@ -64,43 +64,6 @@ spinlock_t rtas_data_buf_lock = SPIN_LOCK_UNLOCKED; char rtas_data_buf[RTAS_DATA_BUF_SIZE]__page_aligned; - -void -phys_call_rtas(int token, int nargs, int nret, ...) -{ - va_list list; - unsigned long offset = reloc_offset(); - struct rtas_args *rtas = PTRRELOC(&(get_paca()->xRtas)); - int i; - - rtas->token = token; - rtas->nargs = nargs; - rtas->nret = nret; - rtas->rets = (rtas_arg_t *)PTRRELOC(&(rtas->args[nargs])); - - va_start(list, nret); - for (i = 0; i < nargs; i++) - rtas->args[i] = (rtas_arg_t)LONG_LSW(va_arg(list, ulong)); - va_end(list); - - enter_rtas(rtas); -} - -void -phys_call_rtas_display_status(char c) -{ - unsigned long offset = reloc_offset(); - struct rtas_args *rtas = PTRRELOC(&(get_paca()->xRtas)); - - rtas->token = 10; - rtas->nargs = 1; - rtas->nret = 1; - rtas->rets = (rtas_arg_t *)PTRRELOC(&(rtas->args[1])); - rtas->args[0] = (int)c; - - enter_rtas(rtas); -} - void call_rtas_display_status(char c) { diff -Nru a/include/asm-ppc64/rtas.h b/include/asm-ppc64/rtas.h --- a/include/asm-ppc64/rtas.h Fri Apr 9 14:04:10 2004 +++ b/include/asm-ppc64/rtas.h Fri Apr 9 14:04:10 2004 @@ -169,8 +169,6 @@ extern void enter_rtas(struct rtas_args *); extern int rtas_token(const char *service); extern long rtas_call(int token, int, int, unsigned long *, ...); -extern void phys_call_rtas(int, int, int, ...); -extern void phys_call_rtas_display_status(char); extern void call_rtas_display_status(char); extern void rtas_restart(char *cmd); extern void rtas_power_off(void); ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Sat Apr 10 09:25:06 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Fri, 9 Apr 2004 18:25:06 -0500 (CDT) Subject: [PATCH] ppc64: Move EPOW log buffer to BSS Message-ID: Hi, RTAS on IBM pSeries runs in real mode, so all pointers being passed in to it need to be in low memory. There's two places in the RAS code that passes in pointers to items on the stack, which might end up being above the limit. Below patch resolves this by creating a buffer in BSS + a lock for serialization. There's no reason to worry about contention on the lock, since rtas_call() also serializes on a single spinlock and this is an infrequent code path in the first place. Patch has been reviewed on linuxppc64-dev. Andrew, please apply. Thanks, Olof Olof Johansson Office: 4F005/905 Linux on Power Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ===== ras.c 1.17 vs edited ===== --- 1.17/arch/ppc64/kernel/ras.c Tue Mar 16 18:46:45 2004 +++ edited/ras.c Tue Apr 6 15:59:18 2004 @@ -109,6 +109,9 @@ } __initcall(init_ras_IRQ); +static struct rtas_error_log log_buf; +static spinlock_t log_lock = SPIN_LOCK_UNLOCKED; + /* * Handle power subsystem events (EPOW). * @@ -123,11 +126,17 @@ unsigned int size = sizeof(log_entry); long status = 0xdeadbeef; + spin_lock(&log_lock); + status = rtas_call(rtas_token("check-exception"), 6, 1, NULL, 0x500, irq, RTAS_EPOW_WARNING | RTAS_POWERMGM_EVENTS, 1, /* Time Critical */ - __pa(&log_entry), size); + __pa(&log_buf), size); + + log_entry = log_buf; + + spin_unlock(&log_lock); udbg_printf("EPOW <0x%lx 0x%lx>\n", *((unsigned long *)&log_entry), status); @@ -156,11 +165,17 @@ long status = 0xdeadbeef; int fatal; + spin_lock(&log_lock); + status = rtas_call(rtas_token("check-exception"), 6, 1, NULL, 0x500, irq, RTAS_INTERNAL_ERROR, 1, /* Time Critical */ - __pa(&log_entry), size); + __pa(&log_buf), size); + + log_entry = log_buf; + + spin_unlock(&log_lock); if ((status == 0) && (log_entry.severity >= SEVERITY_ERROR_SYNC)) fatal = 1; ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxiep at us.ibm.com Sat Apr 10 13:52:53 2004 From: lxiep at us.ibm.com (Linda Xie) Date: Fri, 09 Apr 2004 22:52:53 -0500 Subject: [PATCH] php_phy_location.patch -- please review In-Reply-To: <20040407170442.GF19083@kroah.com> References: <40731ECC.4090606@ltcfwd.linux.ibm.com> <20040407170442.GF19083@kroah.com> Message-ID: <40776F95.1020904@us.ibm.com> Greg KH wrote: >On Tue, Apr 06, 2004 at 04:19:08PM -0500, Linda Xie wrote: > > >>Hi Greg, >> >>Since php core exepects an u32 address value from a php driver and it >>converts the value >>into "%04x:%02x:%02x" string, we can't use "address" attribute file to >>store the physical >>location of a slot (in our case it is a long string like >>"U7311.D11.104CE9A-P1-C2" ). >> >>I'd like to know if we can add a new attribute file called >>"phy_location" or "location" for storing >>physical location (a regular ASCII string) of a slot. >> >> > >Sure, I don't have a problem with that. > >thanks, > >greg k-h > > > Hi All, Hare are changes in the patch: pci_hotplug_core.c -- add "phy_location" attribute for each php slot. rpaphp driver -- intialize "phy_location" with "ibm,loc-code" string. remove some routines that won't be needed due to naming scheme change. rewrite find_slot routine. Comments welcome. Linda -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: php_phy_location.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040409/3e6f7676/attachment.txt From greg at kroah.com Sun Apr 11 02:46:59 2004 From: greg at kroah.com (Greg KH) Date: Sat, 10 Apr 2004 09:46:59 -0700 Subject: [PATCH] php_phy_location.patch -- please review In-Reply-To: <40776F95.1020904@us.ibm.com> References: <40731ECC.4090606@ltcfwd.linux.ibm.com> <20040407170442.GF19083@kroah.com> <40776F95.1020904@us.ibm.com> Message-ID: <20040410164659.GB1317@kroah.com> On Fri, Apr 09, 2004 at 10:52:53PM -0500, Linda Xie wrote: > > pci_hotplug_core.c -- add "phy_location" attribute for each php slot. Wait, no. Why not just add the file for your driver alone, as it's the only one wanting it. Don't modify the core for this. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxiep at us.ibm.com Mon Apr 12 10:51:03 2004 From: lxiep at us.ibm.com (Linda Xie) Date: Sun, 11 Apr 2004 19:51:03 -0500 Subject: [PATCH-revised] php_phy_location.patch -- please review In-Reply-To: <20040410164659.GB1317@kroah.com> References: <40731ECC.4090606@ltcfwd.linux.ibm.com> <20040407170442.GF19083@kroah.com> <40776F95.1020904@us.ibm.com> <20040410164659.GB1317@kroah.com> Message-ID: <4079E7F7.8010801@us.ibm.com> Greg KH wrote: >On Fri, Apr 09, 2004 at 10:52:53PM -0500, Linda Xie wrote: > > >>pci_hotplug_core.c -- add "phy_location" attribute for each php slot. >> >> > >Wait, no. Why not just add the file for your driver alone, as it's the >only one wanting it. Don't modify the core for this. > >thanks, > >greg k-h > > > > > Please see the attachement for a revised patch.(It has no changes to pci core). Thanks, Linda -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: php_phy_location.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040411/242a78b4/attachment.txt From anton at samba.org Mon Apr 12 17:35:08 2004 From: anton at samba.org (Anton Blanchard) Date: Mon, 12 Apr 2004 17:35:08 +1000 Subject: cur_cpu_spec is a pointer Message-ID: <20040412073508.GE22471@krispykreme> Hi, We are using cur_cpu_spec a lot these days. While working on HW profiling support I noticed a fair amount of time in some cur_cpu_spec->cpu_features == X code. .LC15: .tc cur_cpu_spec[TC],cur_cpu_spec ld 11,.LC15 at toc(2) ld 9,0(11) ld 0,16(9) rldicl. 9,0,31,63 bne 0,.L75 Changing it to a struct and not a pointer to a struct saves us one dependent load: ld 9,.LC15 at toc(2) ld 0,16(9) rldicl. 9,0,31,63 bne 0,.L75 This also applies to naca and systemcfg. I guess it was done to make early boot a bit easier (set the naca pointer to point to the early load location, then relocate it when we switch into virtual mode). Even so, these structures are pretty heavily used and there could be a measurable gain in fixing them. A question for Alan, why cant we put variables directly in the TOC? I admit it will become a right pain once you get multiple TOCs. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From dje at watson.ibm.com Tue Apr 13 00:41:46 2004 From: dje at watson.ibm.com (David Edelsohn) Date: Mon, 12 Apr 2004 10:41:46 -0400 Subject: cur_cpu_spec is a pointer In-Reply-To: Message from Anton Blanchard of "Mon, 12 Apr 2004 17:35:08 +1000." <20040412073508.GE22471@krispykreme> References: <20040412073508.GE22471@krispykreme> Message-ID: <200404121441.i3CEfkT35494@makai.watson.ibm.com> >>>>> Anton Blanchard writes: Anton> A question for Alan, why cant we put variables directly in the TOC? I Anton> admit it will become a right pain once you get multiple TOCs. One definitely can store data directly in the TOC. GCC does this for floating-point constants, but does not know how to do this for normal variables nor on a variable-by-variable basis. If one always accesses the data through assembly language, this will not be a problem. The PPC64 ABI specifically provides examples of accessing data directly stored in the TOC. David ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Tue Apr 13 02:43:15 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Mon, 12 Apr 2004 11:43:15 -0500 Subject: [PATCH] code cleanup In-Reply-To: ; from jschopp@austin.ibm.com on Fri, Apr 09, 2004 at 02:18:20PM -0500 References: Message-ID: <20040412114315.H58706@forte.austin.ibm.com> On Fri, Apr 09, 2004 at 02:18:20PM -0500, jschopp at austin.ibm.com wrote: > > I was looking at rtas serialization for reasons I won't go into here. I'd like to know why ... the LTE and others have a stack of bugs that have MSR=9000... and there is some suspicion that bad args sent sent to rtas might be one of the causes of this. > While wandering through the code I found that two functions were not > properly serialized. phys_call_rtas and phys_call_rtas_display_status are Yes. While wandering through the same code, I noticed that some of the locking fails to lock sections of the paca as well, which might (??) cause races in the future (??) if CONFIG_PREEMPT is enabled (maybe). If you're in a cleanup mood, I'd suggest moving those locks to protect the reading/writing of the paca data. > below removes them, unless I hear some objections I will push it > early next week. I don't have any objections. --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Tue Apr 13 03:18:05 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Mon, 12 Apr 2004 12:18:05 -0500 Subject: [PATCH] NULL dn->type deref in EEH code (IPR driver) Message-ID: <20040412121804.I58706@forte.austin.ibm.com> Anton, Can you apply the attached patch to ameslab? The IPR driver appearently has NULL for struct device_node *dn->type where dn was returned by pci_device_to_OF_node(dev); I don't know if its 'normal' to have a NULL here or not. Brian King reported a crash here in his IPR driver, and this patch works around that. --linas -------------- next part -------------- --- arch/ppc64/kernel/eeh.c.orig 2004-04-12 12:02:49.000000000 -0500 +++ arch/ppc64/kernel/eeh.c 2004-04-12 12:04:11.000000000 -0500 @@ -487,9 +487,9 @@ unsigned long eeh_check_failure(void *to dn->eeh_mode & EEH_MODE_NOCHECK) goto ok_return; - /* Make sure we aren't ISA */ - if (!strcmp(dn->type, "isa")) - goto ok_return; + /* Make sure we aren't ISA */ + if (dn->type && !strcmp(dn->type, "isa")) + goto ok_return; if (!dn->eeh_config_addr) goto ok_return; From nathanl at austin.ibm.com Tue Apr 13 03:36:23 2004 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Mon, 12 Apr 2004 12:36:23 -0500 Subject: [PATCH] NULL dn->type deref in EEH code (IPR driver) In-Reply-To: <20040412121804.I58706@forte.austin.ibm.com> References: <20040412121804.I58706@forte.austin.ibm.com> Message-ID: <407AD397.5090107@austin.ibm.com> linas at austin.ibm.com wrote: > The IPR driver appearently has NULL for struct device_node *dn->type > where dn was returned by pci_device_to_OF_node(dev); I don't know > if its 'normal' to have a NULL here or not. Brian King reported > a crash here in his IPR driver, and this patch works around that. If a device_node has a "device_type" property, the dn's 'type' field points to that property's value. Some device nodes do not have the property, so the type field is NULL. So I think the patch is correct. Nathan ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Tue Apr 13 04:00:34 2004 From: greg at kroah.com (Greg KH) Date: Mon, 12 Apr 2004 11:00:34 -0700 Subject: HVC explosion In-Reply-To: References: <20040409165302.GD14961@kroah.com> Message-ID: <20040412180034.GC20692@kroah.com> On Sun, Apr 11, 2004 at 07:39:40PM -0500, David Boutcher wrote: > Greg KH wrote on 04/09/2004 11:53:02 AM: > > Either way, you pushed code to the repository that was not vetted by > > anyone. Bad form. > > Perhaps, but we have typically been using ames as a working > repository. "working repository" is just fine. "Conduit to the distro" is not. That is what happened here, correct? I am concerned about this because stuff gets pushed to the distro, and then the distro engineers complain to me about the level of code being pushed to them and why hasn't it been vetted through the proper channels instead. I'm very tired of constantly hearing this... thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Tue Apr 13 04:49:26 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Mon, 12 Apr 2004 13:49:26 -0500 Subject: [PATCH] php_phy_location.patch -- please review In-Reply-To: <20040410164659.GB1317@kroah.com>; from greg@kroah.com on Sat, Apr 10, 2004 at 09:46:59AM -0700 References: <40731ECC.4090606@ltcfwd.linux.ibm.com> <20040407170442.GF19083@kroah.com> <40776F95.1020904@us.ibm.com> <20040410164659.GB1317@kroah.com> Message-ID: <20040412134926.J58706@forte.austin.ibm.com> On Sat, Apr 10, 2004 at 09:46:59AM -0700, Greg KH wrote: > > On Fri, Apr 09, 2004 at 10:52:53PM -0500, Linda Xie wrote: > > > > pci_hotplug_core.c -- add "phy_location" attribute for each php slot. > > Wait, no. Why not just add the file for your driver alone, as it's the > only one wanting it. Don't modify the core for this. OK, I'm confused: so, stupid question of the day: There was a udev thread in March called "Geographic naming of devices using Udev" which I pretty much ignored. So my stoopid, unrealistic question is "couldn't that framework be applied for this?" --linas p.s. I really liked the idea of calling it "geo_location" instead of "phy_location" since "phy" already tends to mean other things when used in kernel sources, it already has a lot of baggage. On the other hand, 'geo' is fresh and sparkly and has a nice overtone of "the physical location of something". ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Tue Apr 13 04:55:13 2004 From: greg at kroah.com (Greg KH) Date: Mon, 12 Apr 2004 11:55:13 -0700 Subject: [PATCH] php_phy_location.patch -- please review In-Reply-To: <20040412134926.J58706@forte.austin.ibm.com> References: <40731ECC.4090606@ltcfwd.linux.ibm.com> <20040407170442.GF19083@kroah.com> <40776F95.1020904@us.ibm.com> <20040410164659.GB1317@kroah.com> <20040412134926.J58706@forte.austin.ibm.com> Message-ID: <20040412185513.GG21502@kroah.com> On Mon, Apr 12, 2004 at 01:49:26PM -0500, linas at austin.ibm.com wrote: > On Sat, Apr 10, 2004 at 09:46:59AM -0700, Greg KH wrote: > > > > On Fri, Apr 09, 2004 at 10:52:53PM -0500, Linda Xie wrote: > > > > > > pci_hotplug_core.c -- add "phy_location" attribute for each php slot. > > > > Wait, no. Why not just add the file for your driver alone, as it's the > > only one wanting it. Don't modify the core for this. > > OK, I'm confused: so, stupid question of the day: > > There was a udev thread in March called > "Geographic naming of devices using Udev" > which I pretty much ignored. > > So my stoopid, unrealistic question is "couldn't that framework > be applied for this?" udev names device nodes that show up in /dev. It has nothing to do with this, sorry. greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jschopp at austin.ibm.com Tue Apr 13 04:58:32 2004 From: jschopp at austin.ibm.com (jschopp at austin.ibm.com) Date: Mon, 12 Apr 2004 13:58:32 -0500 (CDT) Subject: [PATCH] code cleanup In-Reply-To: <20040412114315.H58706@forte.austin.ibm.com> Message-ID: > > I was looking at rtas serialization for reasons I won't go into here. > > I'd like to know why ... the LTE and others have a stack of bugs > that have MSR=9000... and there is some suspicion that bad args sent > sent to rtas might be one of the causes of this. I was investigating what looked like it had the possibility of being multiple simultaneous rtas calls, causing one of them to fail. It turns out that wasn't the problem at all. Nothing to do with your problem. It was a change in some undocumented behavior > Yes. > While wandering through the same code, I noticed that some of the > locking fails to lock sections of the paca as well, which might (??) > cause races in the future (??) if CONFIG_PREEMPT is enabled (maybe). That sounds non-trivial to investigate. I might keep it in mind for the future, but right now just don't have the time. > > I don't have any objections. I'll push it today then. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Tue Apr 13 08:24:02 2004 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Mon, 12 Apr 2004 17:24:02 -0500 Subject: HVSI serial console review (2.6 patch) Message-ID: <1081808642.29578.52.camel@basalt.austin.ibm.com> Attached is the diff I'm planning on sending upstream soon for the Host Virtual Serial Interface, a firmware feature that few have had the pleasure of using yet. It changes drivers/char/hvc_console.c a little bit; renaming the arch-provided functions and altering that interface somewhat. I'm a little uncertain about the tty_hangup() call; I may need to make it look more like uart_handle_dcd_change(). Nobody should notice any normal (Regatta/JS20) console difference other than an extra function pointer dereference. The bulk of the code is is arch/ppc64/kernel/hvconsole.c. It's an elaborate protocol that allows us to get read/write/ioctl out of a read/write hcall interface. It has seen some testing, and for the most part "works for me". Comments here are welcome too: areas of criticism could range from adding 1KiB to BSS size to overly-complicated buffering to "this is an awful design" (I'll sympathise with the last, but can't change it). If anyone actually cares, I'd be happy to describe the workings in a little more detail. I meant to give an overview of HVSI in the code but forgot, so I'll have to add that in later. -- Hollis Blanchard IBM Linux Technology Center -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hvsi-tolinus-20040412.diff Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040412/9fb9ae2d/attachment.txt From greg at kroah.com Tue Apr 13 08:51:02 2004 From: greg at kroah.com (Greg KH) Date: Mon, 12 Apr 2004 15:51:02 -0700 Subject: HVSI serial console review (2.6 patch) In-Reply-To: <1081808642.29578.52.camel@basalt.austin.ibm.com> References: <1081808642.29578.52.camel@basalt.austin.ibm.com> Message-ID: <20040412225102.GB24178@kroah.com> On Mon, Apr 12, 2004 at 05:24:02PM -0500, Hollis Blanchard wrote: > +static void dump_packet(struct hvsi_header *pkt) > +{ > + int i; > + char *data = payload(pkt); > + > + printk("type 0x%x, len %i, seqno %i:", pkt->type, pkt->len, pkt->seqno); Yeah, I see you are relying on the printk() that happens right before this to give you the proper KERN_ level, but then you loose that level with: > + > + if (len_payload(pkt)) > + printk("\n "); That one. Why put spaces after a \n if you aren't going to set the level? > +static struct hvsi_header *search_for_packet(struct vtty_struct *vtty, int type) > +{ > + /* bring in queued packets */ > + hvsi_load_buffers(vtty); > + > + /* look for the version query response packet */ > + for (; read != write; read = next_desc(read)) { > + struct hvsi_header *pkt = &read->data.hdr; > + > + if (pkt->type == type) { > + desc_clear(read); > + read = next_desc(read); > + return pkt; > + } > + printk("%s: ignoring packet while waiting for type 0x%x:\n", > + __FUNCTION__, type); Again with the KERN_ level missing. Actually, why not use the dev_() macros, aren't these devices on that wierd bus type? Other than those minor nits, looks fine to me, thanks for posting this. greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Tue Apr 13 10:06:19 2004 From: greg at kroah.com (Greg KH) Date: Mon, 12 Apr 2004 17:06:19 -0700 Subject: [PATCH-revised] php_phy_location.patch -- please review In-Reply-To: <4079E7F7.8010801@us.ibm.com> References: <40731ECC.4090606@ltcfwd.linux.ibm.com> <20040407170442.GF19083@kroah.com> <40776F95.1020904@us.ibm.com> <20040410164659.GB1317@kroah.com> <4079E7F7.8010801@us.ibm.com> Message-ID: <20040413000619.GA27593@kroah.com> On Sun, Apr 11, 2004 at 07:51:03PM -0500, Linda Xie wrote: > Please see the attachement for a revised patch.(It has no changes to pci > core). Much nicer, I've applied this thanks. greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at samba.org Tue Apr 13 11:31:46 2004 From: paulus at samba.org (Paul Mackerras) Date: Tue, 13 Apr 2004 11:31:46 +1000 Subject: [PATCH] NULL dn->type deref in EEH code (IPR driver) In-Reply-To: <20040412121804.I58706@forte.austin.ibm.com> References: <20040412121804.I58706@forte.austin.ibm.com> Message-ID: <16507.17154.673247.268560@cargo.ozlabs.ibm.com> linas at austin.ibm.com writes: > The IPR driver appearently has NULL for struct device_node *dn->type > where dn was returned by pci_device_to_OF_node(dev); I don't know > if its 'normal' to have a NULL here or not. Brian King reported > a crash here in his IPR driver, and this patch works around that. It's a bit nasty that we let dn->type (and dn->name) ever be NULL. In ppc32 we set them to "" if there is no device_type (or name) property. We should probably do that in ppc64 as well. Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From amodra at bigpond.net.au Tue Apr 13 12:34:43 2004 From: amodra at bigpond.net.au (Alan Modra) Date: Tue, 13 Apr 2004 12:04:43 +0930 Subject: cur_cpu_spec is a pointer In-Reply-To: <200404121441.i3CEfkT35494@makai.watson.ibm.com> References: <20040412073508.GE22471@krispykreme> <200404121441.i3CEfkT35494@makai.watson.ibm.com> Message-ID: <20040413023443.GJ29660@bubble.modra.org> On Mon, Apr 12, 2004 at 10:41:46AM -0400, David Edelsohn wrote: > > >>>>> Anton Blanchard writes: > > Anton> A question for Alan, why cant we put variables directly in the TOC? I > Anton> admit it will become a right pain once you get multiple TOCs. > > One definitely can store data directly in the TOC. GCC does this > for floating-point constants, but does not know how to do this for normal > variables nor on a variable-by-variable basis. If one always accesses the > data through assembly language, this will not be a problem. The PPC64 ABI > specifically provides examples of accessing data directly stored in the > TOC. Adding a GCC capability to store vars directly in the TOC would likely be limited to static vars because of the problem Anton identified. (And -mminimal-toc probably should limit to function scope static vars). -- Alan Modra IBM OzLabs - Linux Technology Centre ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From dje at watson.ibm.com Tue Apr 13 12:49:35 2004 From: dje at watson.ibm.com (David Edelsohn) Date: Mon, 12 Apr 2004 22:49:35 -0400 Subject: cur_cpu_spec is a pointer In-Reply-To: Message from Alan Modra of "Tue, 13 Apr 2004 12:04:43 +0930." <20040413023443.GJ29660@bubble.modra.org> References: <20040412073508.GE22471@krispykreme> <200404121441.i3CEfkT35494@makai.watson.ibm.com> <20040413023443.GJ29660@bubble.modra.org> Message-ID: <200404130249.i3D2nZT36190@makai.watson.ibm.com> >>>>> Alan Modra writes: Alan> (And -mminimal-toc probably should limit to function scope static vars). We should not have -mminimal-toc and GCC should use a single TOC entry dynamically cached in a register for function scope static pool and constant pool, but that probably is off-topic for this list. David ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Tue Apr 13 18:21:56 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 13 Apr 2004 18:21:56 +1000 Subject: hvc_console & interrupts: reworked patch Message-ID: <1081844516.25144.237.camel@gaston> Hi ! This patch is _TOTALLY UNTESTED_, I'll do that tomorrow, but at least the chosen approach can be discussed here in the meantime. So I rewrote Ryan's patch in a different way that, of course, I personally prefer ;) Note that I know I'm kicking the thread a bit too often on normal writes, I've been toying with the idea of adding a parameter to kick, basically, NOW vs. LATER, the later one only kicking if blocked into schedule(), not into schedule_timeout(), but I was too lazy to add the necessary locking infrastructure for that. Same goes with the interrupt which may trigger the thread spurriously if throttled, though that's easily fixable if it's considered as a real issue. Ryan: I suppose the interrupt acts like an "edge" trigger that gets re-armed when HV returns 0 bytes on a read, right ? Patch is against current ameslab 2.5 Ben. ===== arch/ppc64/kernel/hvconsole.c 1.10 vs edited ===== --- 1.10/arch/ppc64/kernel/hvconsole.c Sat Apr 10 08:11:48 2004 +++ edited/arch/ppc64/kernel/hvconsole.c Tue Apr 13 18:00:08 2004 @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -50,6 +51,7 @@ int (*tiocmset)(struct vtty_struct *vtty, uint16_t set, uint16_t clear); uint16_t seqno; /* HVSI packet sequence number */ uint16_t mctrl; + int irq; }; static struct vtty_struct vttys[MAX_NR_HVC_CONSOLES]; @@ -718,6 +720,7 @@ { struct device_node *vty; int count = 0; + unsigned int *irq_p; for (vty = of_find_node_by_name(NULL, "vty"); vty != NULL; vty = of_find_node_by_name(vty, "vty")) { @@ -732,12 +735,20 @@ break; vtty = &vttys[count]; + vtty->irq = NO_IRQ; if (device_is_compatible(vty, "hvterm1")) { vtty->vtermno = *vtermno; vtty->get_chars = hvc_hvterm_get_chars; vtty->put_chars = hvc_hvterm_put_chars; vtty->tiocmget = NULL; vtty->tiocmset = NULL; + vtty->irq = NO_IRQ; + irq_p = (unsigned int *)get_property(vty, "interrupts", 0); + if (irq_p) { + int virq = virt_irq_create_mapping(*irq_p); + if (virq != NO_IRQ) + vtty->irq = irq_offset_up(virq); + } hvc_instantiate(); count++; } else if (device_is_compatible(vty, "hvterm-protocol")) { @@ -758,6 +769,14 @@ return count; } + +int hvc_interruptible(int index) +{ + struct vtty_struct *vtty = &vttys[index]; + + /* If not interruptible then it'll return NO_IRQ */ + return vtty->irq; +} /* Convert arch specific return codes into relevant errnos. The hvcs * functions aren't performance sensitive, so this conversion isn't an ===== drivers/char/hvc_console.c 1.25 vs edited ===== --- 1.25/drivers/char/hvc_console.c Sat Apr 10 08:11:48 2004 +++ edited/drivers/char/hvc_console.c Tue Apr 13 18:14:54 2004 @@ -38,12 +38,15 @@ #define TIMEOUT ((HZ + 99) / 100) static struct tty_driver *hvc_driver; -static int count; +static int hvc_count; +static int hvc_kicked; +static wait_queue_head_t hvc_wait_queue; #ifdef CONFIG_MAGIC_SYSRQ static int sysrq_pressed; #endif #define N_OUTBUF 16 +#define N_INBUF 16 #define __ALIGNED__ __attribute__((__aligned__(8))) @@ -59,15 +62,34 @@ int do_wakeup; char outbuf[N_OUTBUF] __ALIGNED__; int n_outbuf; + int irq_requested; }; struct hvc_struct hvc_struct[MAX_NR_HVC_CONSOLES]; +static void hvc_kick(void) +{ + hvc_kicked = 1; + wake_up_interruptible(&hvc_wait_queue); +} + +static irqreturn_t hvc_handle_interrupt(int irq, void *dev_instance, struct pt_regs *regs) +{ + hvc_kick(); + return IRQ_HANDLED; +} + +static void hvc_unthrottle(struct tty_struct *tty) +{ + hvc_kick(); +} + static int hvc_open(struct tty_struct *tty, struct file * filp) { int line = tty->index; struct hvc_struct *hp; unsigned long flags; + int irq = NO_IRQ; if (line < 0 || line >= MAX_NR_HVC_CONSOLES) return -ENODEV; @@ -77,7 +99,18 @@ spin_lock_irqsave(&hp->lock, flags); hp->tty = tty; hp->count++; + if (hp->count == 1) { + irq = hvc_interruptible(hp->index); + if (irq != NO_IRQ) + hp->irq_requested = 1; + } spin_unlock_irqrestore(&hp->lock, flags); + /* XX check error, fallback to non-irq ? */ + if (irq != NO_IRQ) + request_irq(irq, hvc_handle_interrupt, SA_INTERRUPT, "hvc_console", hp); + + /* Force wakeup of the polling thread */ + hvc_kick(); return 0; } @@ -86,16 +119,28 @@ { struct hvc_struct *hp = tty->driver_data; unsigned long flags; + int irq = NO_IRQ; - if (tty_hung_up_p(filp)) - return; spin_lock_irqsave(&hp->lock, flags); - if (--hp->count == 0) + if (tty_hung_up_p(filp)) { + if (hp->irq_requested) + irq = hvc_interruptible(hp->index); + hp->irq_requested = 0; + goto bail; + } + + if (--hp->count == 0) { hp->tty = NULL; - else if (hp->count < 0) + if (hp->irq_requested) + irq = hvc_interruptible(hp->index); + hp->irq_requested = 0; + } else if (hp->count < 0) printk(KERN_ERR "hvc_close %lu: oops, count is %d\n", hp - hvc_struct, hp->count); + bail: spin_unlock_irqrestore(&hp->lock, flags); + if (irq != NO_IRQ) + free_irq(irq, hp); } static void hvc_hangup(struct tty_struct *tty) @@ -126,70 +171,94 @@ hp->do_wakeup = 1; } -static int hvc_write(struct tty_struct *tty, int from_user, - const unsigned char *buf, int count) +static inline int __hvc_write_user(struct hvc_struct *hp, + const unsigned char *buf, int count) { - struct hvc_struct *hp = tty->driver_data; char *tbuf, *p; int tbsize, rsize, written = 0; unsigned long flags; - if (from_user) { - tbsize = min(count, (int)PAGE_SIZE); - if (!(tbuf = kmalloc(tbsize, GFP_KERNEL))) - return -ENOMEM; - - while ((rsize = count - written) > 0) { - int wsize; - if (rsize > tbsize) - rsize = tbsize; - - p = tbuf; - rsize -= copy_from_user(p, buf, rsize); - if (!rsize) { - if (written == 0) - written = -EFAULT; - break; - } - buf += rsize; - written += rsize; - - spin_lock_irqsave(&hp->lock, flags); - for (wsize = N_OUTBUF - hp->n_outbuf; rsize && wsize; - wsize = N_OUTBUF - hp->n_outbuf) { - if (wsize > rsize) - wsize = rsize; - memcpy(hp->outbuf + hp->n_outbuf, p, wsize); - hp->n_outbuf += wsize; - hvc_push(hp); - rsize -= wsize; - p += wsize; - } - spin_unlock_irqrestore(&hp->lock, flags); - - if (rsize) - break; + tbsize = min(count, (int)PAGE_SIZE); + if (!(tbuf = kmalloc(tbsize, GFP_KERNEL))) + return -ENOMEM; - if (count < tbsize) - tbsize = count; + while ((rsize = count - written) > 0) { + int wsize; + if (rsize > tbsize) + rsize = tbsize; + + p = tbuf; + rsize -= copy_from_user(p, buf, rsize); + if (!rsize) { + if (written == 0) + written = -EFAULT; + break; } + buf += rsize; - kfree(tbuf); - } else { spin_lock_irqsave(&hp->lock, flags); - while (count > 0 && (rsize = N_OUTBUF - hp->n_outbuf) > 0) { - if (rsize > count) - rsize = count; - memcpy(hp->outbuf + hp->n_outbuf, buf, rsize); - count -= rsize; - buf += rsize; - hp->n_outbuf += rsize; - written += rsize; + for (wsize = N_OUTBUF - hp->n_outbuf; rsize && wsize; + wsize = N_OUTBUF - hp->n_outbuf) { + if (wsize > rsize) + wsize = rsize; + memcpy(hp->outbuf + hp->n_outbuf, p, wsize); + hp->n_outbuf += wsize; hvc_push(hp); + rsize -= wsize; + p += wsize; + written += wsize; } spin_unlock_irqrestore(&hp->lock, flags); + + if (rsize) + break; + + if (count < tbsize) + tbsize = count; } + kfree(tbuf); + + return written; +} + +static inline int __hvc_write_kernel(struct hvc_struct *hp, + const unsigned char *buf, int count) +{ + unsigned long flags; + int rsize, written = 0; + + spin_lock_irqsave(&hp->lock, flags); + while (count > 0 && (rsize = N_OUTBUF - hp->n_outbuf) > 0) { + if (rsize > count) + rsize = count; + memcpy(hp->outbuf + hp->n_outbuf, buf, rsize); + count -= rsize; + buf += rsize; + hp->n_outbuf += rsize; + written += rsize; + hvc_push(hp); + } + spin_unlock_irqrestore(&hp->lock, flags); + + return written; +} + +static int hvc_write(struct tty_struct *tty, int from_user, + const unsigned char *buf, int count) +{ + struct hvc_struct *hp = tty->driver_data; + int written; + + if (from_user) + written = __hvc_write_user(hp, buf, count); + else + written = __hvc_write_kernel(hp, buf, count); + + /* Racy, but harmless, kick thread if there are still pending data */ + if (hp->n_outbuf) + hvc_kick(); + return written; } @@ -207,59 +276,103 @@ return hp->n_outbuf; } -static void hvc_poll(int index) +#define HVC_POLL_READ 0x00000001 +#define HVC_POLL_WRITE 0x00000002 +#define HVC_POLL_QUICK 0x00000004 + +static int hvc_poll(int index) { struct hvc_struct *hp = &hvc_struct[index]; struct tty_struct *tty; - int i, n; - char buf[16] __ALIGNED__; + int i, n, poll_mask = 0; + char buf[N_INBUF] __ALIGNED__; unsigned long flags; + int read_total = 0; spin_lock_irqsave(&hp->lock, flags); + /* Push pending writes */ if (hp->n_outbuf > 0) hvc_push(hp); + /* Reschedule us if still some write pending */ + if (hp->n_outbuf > 0) + poll_mask |= HVC_POLL_WRITE; + /* No tty attached, just skip */ tty = hp->tty; - if (tty) { - for (;;) { - if (TTY_FLIPBUF_SIZE - tty->flip.count < sizeof(buf)) - break; - n = hvc_arch_get_chars(index, buf, sizeof(buf)); - if (n <= 0) { - if (n == -EPIPE) { - printk("tty_hangup\n"); - tty_hangup(tty); - } - break; - } - for (i = 0; i < n; ++i) { -#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */ - if (buf[i] == '\x0f') { /* ^O -- should support a sequence */ - sysrq_pressed = 1; - continue; - } else if (sysrq_pressed) { - handle_sysrq(buf[i], NULL, tty); - sysrq_pressed = 0; - continue; - } -#endif - tty_insert_flip_char(tty, buf[i], 0); + if (tty == NULL) + goto bail; + + /* Now check if we can get data (are we throttled ?) */ + if (test_bit(TTY_THROTTLED, &tty->flags)) + goto throttled; + + /* If we aren't interrupt driven and aren't throttled, we always + * request a reschedule + */ + if (!hvc_interruptible(index)) + poll_mask |= HVC_POLL_READ; + + /* Read data if any */ + for (;;) { + int count = N_INBUF; + if (count > (TTY_FLIPBUF_SIZE - tty->flip.count)) + count = TTY_FLIPBUF_SIZE - tty->flip.count; + + /* If flip is full, just reschedule a later read */ + if (count == 0) { + poll_mask |= HVC_POLL_READ; + break; + } + + n = hvc_arch_get_chars(index, buf, count); + if (n <= 0) { + /* XXX What is that supposed to do ? */ + if (n == -EPIPE) + tty_hangup(tty); + break; + } + for (i = 0; i < n; ++i) { +#ifdef CONFIG_MAGIC_SYSRQ + /* Handle the SysRq Hack */ + if (buf[i] == '\x0f') { /* ^O -- should support a sequence */ + sysrq_pressed = 1; + continue; + } else if (sysrq_pressed) { + handle_sysrq(buf[i], NULL, tty); + sysrq_pressed = 0; + continue; } +#endif /* CONFIG_MAGIC_SYSRQ */ + tty_insert_flip_char(tty, buf[i], 0); } + if (tty->flip.count) tty_schedule_flip(tty); - if (hp->do_wakeup) { - hp->do_wakeup = 0; - if ((tty->flags & (1 << TTY_DO_WRITE_WAKEUP)) - && tty->ldisc.write_wakeup) - (tty->ldisc.write_wakeup)(tty); - wake_up_interruptible(&tty->write_wait); + /* Account the total amount read in one loop, and if above 64 bytes, + * we do a quick schedule loop to let the tty grok the data and + * eventually throttle us + */ + read_total += n; + if (read_total >= 64) { + poll_mask |= HVC_POLL_QUICK; + break; } } - + throttled: + /* Wakeup write queue if necessary */ + if (hp->do_wakeup) { + hp->do_wakeup = 0; + if ((tty->flags & (1 << TTY_DO_WRITE_WAKEUP)) + && tty->ldisc.write_wakeup) + (tty->ldisc.write_wakeup)(tty); + wake_up_interruptible(&tty->write_wait); + } + bail: spin_unlock_irqrestore(&hp->lock, flags); + + return poll_mask; } #if defined(CONFIG_XMON) && defined(CONFIG_SMP) @@ -271,17 +384,37 @@ int khvcd(void *unused) { - int i; + int i, poll_mask; daemonize("khvcd"); for (;;) { + wait_queue_t wait = __WAITQUEUE_INITIALIZER(wait,current); + + poll_mask = 0; + hvc_kicked = 0; + wmb(); if (cpus_empty(cpus_in_xmon)) { for (i = 0; i < MAX_NR_HVC_CONSOLES; ++i) - hvc_poll(i); + poll_mask |= hvc_poll(i); + } else + poll_mask |= HVC_POLL_READ; + if (hvc_kicked) + continue; + if (poll_mask & HVC_POLL_QUICK) { + yield(); + continue; } + add_wait_queue(&hvc_wait_queue, &wait); set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(TIMEOUT); + if (!hvc_kicked) { + if (poll_mask == 0) + schedule(); + else + schedule_timeout(TIMEOUT); + } + set_current_state(TASK_RUNNING); + remove_wait_queue(&hvc_wait_queue, &wait); } } @@ -314,6 +447,7 @@ .close = hvc_close, .write = hvc_write, .hangup = hvc_hangup, + .unthrottle = hvc_unthrottle, .write_room = hvc_write_room, .chars_in_buffer = hvc_chars_in_buffer, .tiocmget = hvc_tiocmget, @@ -322,7 +456,9 @@ int __init hvc_init(void) { - hvc_driver = alloc_tty_driver(count); + init_waitqueue_head(&hvc_wait_queue); + + hvc_driver = alloc_tty_driver(hvc_count); if (!hvc_driver) return -ENOMEM; @@ -340,7 +476,7 @@ if (tty_register_driver(hvc_driver)) panic("Couldn't register hvc console driver\n"); - if (count > 0) + if (hvc_count > 0) kernel_thread(khvcd, NULL, CLONE_KERNEL); else printk(KERN_WARNING "no virtual consoles found\n"); @@ -391,7 +527,7 @@ static int __init hvc_console_setup(struct console *co, char *options) { if (co->index < 0 || co->index >= MAX_NR_HVC_CONSOLES - || co->index >= count) + || co->index >= hvc_count) return -1; return 0; } @@ -410,14 +546,14 @@ { struct hvc_struct *hvc; - if (count >= MAX_NR_HVC_CONSOLES) + if (hvc_count >= MAX_NR_HVC_CONSOLES) return -1; - hvc = &hvc_struct[count]; + hvc = &hvc_struct[hvc_count]; hvc->lock = SPIN_LOCK_UNLOCKED; - hvc->index = count; + hvc->index = hvc_count; - count++; + hvc_count++; return 0; } ===== include/asm-ppc64/hvconsole.h 1.7 vs edited ===== --- 1.7/include/asm-ppc64/hvconsole.h Sat Apr 10 08:11:48 2004 +++ edited/include/asm-ppc64/hvconsole.h Tue Apr 13 18:00:25 2004 @@ -57,6 +57,7 @@ extern int hvcs_get_partner_info(unsigned int unit_address, struct list_head *head); extern int hvcs_register_connection(unsigned int unit_address, unsigned int p_partition_ID, unsigned int p_unit_address); extern int hvcs_free_connection(unsigned int unit_address); +extern int hvc_interruptible(int index); #endif /* _PPC64_HVCONSOLE_H */ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Tue Apr 13 20:52:18 2004 From: anton at samba.org (Anton Blanchard) Date: Tue, 13 Apr 2004 20:52:18 +1000 Subject: ibmveth gcc 3.5 issues Message-ID: <20040413105218.GP22471@krispykreme> Hi, gcc 3.5 doesnt like the mac_addr_p gymnastics and it has the potential to explode if phyp feeds us a bogus mac address. The change was based on the comment above it, can someone verify the new version will work as expected? Anton diff -puN drivers/net/ibmveth.c~gcc-3.5fixes drivers/net/ibmveth.c --- foobar2/drivers/net/ibmveth.c~gcc-3.5fixes 2004-03-01 12:40:37.445129353 +1100 +++ foobar2-anton/drivers/net/ibmveth.c 2004-03-01 12:43:51.646252905 +1100 @@ -865,14 +865,14 @@ static int __devinit ibmveth_probe(struc struct net_device *netdev; struct ibmveth_adapter *adapter; - unsigned int *mac_addr_p; + unsigned char *mac_addr_p; unsigned int *mcastFilterSize_p; ibmveth_debug_printk_no_adapter("entering ibmveth_probe for UA 0x%x\n", dev->unit_address); - mac_addr_p = (unsigned int *) vio_get_attribute(dev, VETH_MAC_ADDR, 0); + mac_addr_p = (unsigned char *) vio_get_attribute(dev, VETH_MAC_ADDR, 0); if(!mac_addr_p) { ibmveth_error_printk("Can't find VETH_MAC_ADDR attribute\n"); return 0; @@ -907,8 +907,8 @@ static int __devinit ibmveth_probe(struc The RPA doc specifies that the first byte must be 10b, so we'll just look for it to solve this 8 vs. 6 byte field issue */ - while (*((char*)mac_addr_p) != (char)(0x02)) - ((char*)mac_addr_p)++; + if (*mac_addr_p != 0x02) + mac_addr_p += 2; adapter->mac_addr = 0; memcpy(&adapter->mac_addr, mac_addr_p, 6); _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Tue Apr 13 20:53:41 2004 From: anton at samba.org (Anton Blanchard) Date: Tue, 13 Apr 2004 20:53:41 +1000 Subject: more gcc 3.5 stuff Message-ID: <20040413105341.GQ22471@krispykreme> Hi, gcc 3.5 doesnt like signal32.c, I made these changes a while ago but didnt get past a quick boot test. Ben, do they look OK? Anton diff -puN arch/ppc64/kernel/signal32.c~gcc-3.5fixes arch/ppc64/kernel/signal32.c --- foobar2/arch/ppc64/kernel/signal32.c~gcc-3.5fixes 2004-02-29 15:59:43.880544559 +1100 +++ foobar2-anton/arch/ppc64/kernel/signal32.c 2004-02-29 16:11:23.472388589 +1100 @@ -297,12 +297,15 @@ long sys32_sigaction(int sig, struct old if (act) { compat_old_sigset_t mask; + compat_uptr_t handler, restorer; - if (get_user((long)new_ka.sa.sa_handler, &act->sa_handler) || - __get_user((long)new_ka.sa.sa_restorer, &act->sa_restorer) || + if (get_user(handler, &act->sa_handler) || + __get_user(restorer, &act->sa_restorer) || __get_user(new_ka.sa.sa_flags, &act->sa_flags) || __get_user(mask, &act->sa_mask)) return -EFAULT; + new_ka.sa.sa_handler = compat_ptr(handler); + new_ka.sa.sa_restorer = compat_ptr(restorer); siginitset(&new_ka.sa.sa_mask, mask); } @@ -353,7 +356,10 @@ long sys32_rt_sigaction(int sig, const s return -EINVAL; if (act) { - ret = get_user((long)new_ka.sa.sa_handler, &act->sa_handler); + compat_uptr_t handler; + + ret = get_user(handler, &act->sa_handler); + new_ka.sa.sa_handler = compat_ptr(handler); ret |= __copy_from_user(&set32, &act->sa_mask, sizeof(compat_sigset_t)); sigset_from_compat(&new_ka.sa.sa_mask, &set32); @@ -618,6 +624,7 @@ int sys32_sigaltstack(u32 newstack, u32 int ret; mm_segment_t old_fs; unsigned long sp; + compat_uptr_t ss_sp; /* * set sp to the user stack on entry to the system call @@ -626,14 +633,16 @@ int sys32_sigaltstack(u32 newstack, u32 sp = regs->gpr[1]; /* Put new stack info in local 64 bit stack struct */ - if (newstack && - (get_user((long)uss.ss_sp, - &((stack_32_t *)(long)newstack)->ss_sp) || - __get_user(uss.ss_flags, - &((stack_32_t *)(long)newstack)->ss_flags) || - __get_user(uss.ss_size, - &((stack_32_t *)(long)newstack)->ss_size))) - return -EFAULT; + if (newstack) { + if (get_user(ss_sp, + &((stack_32_t *)(long)newstack)->ss_sp) || + __get_user(uss.ss_flags, + &((stack_32_t *)(long)newstack)->ss_flags) || + __get_user(uss.ss_size, + &((stack_32_t *)(long)newstack)->ss_size)) + return -EFAULT; + uss.ss_sp = compat_ptr(ss_sp); + } old_fs = get_fs(); set_fs(KERNEL_DS); ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Tue Apr 13 21:02:35 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 13 Apr 2004 21:02:35 +1000 Subject: more gcc 3.5 stuff In-Reply-To: <20040413105341.GQ22471@krispykreme> References: <20040413105341.GQ22471@krispykreme> Message-ID: <1081854155.2135.2.camel@gaston> On Tue, 2004-04-13 at 20:53, Anton Blanchard wrote: > Hi, > > gcc 3.5 doesnt like signal32.c, I made these changes a while ago but > didnt get past a quick boot test. Ben, do they look OK? Looks good, but need testing just in case... Ben. > Anton > > diff -puN arch/ppc64/kernel/signal32.c~gcc-3.5fixes arch/ppc64/kernel/signal32.c > --- foobar2/arch/ppc64/kernel/signal32.c~gcc-3.5fixes 2004-02-29 15:59:43.880544559 +1100 > +++ foobar2-anton/arch/ppc64/kernel/signal32.c 2004-02-29 16:11:23.472388589 +1100 > @@ -297,12 +297,15 @@ long sys32_sigaction(int sig, struct old > > if (act) { > compat_old_sigset_t mask; > + compat_uptr_t handler, restorer; > > - if (get_user((long)new_ka.sa.sa_handler, &act->sa_handler) || > - __get_user((long)new_ka.sa.sa_restorer, &act->sa_restorer) || > + if (get_user(handler, &act->sa_handler) || > + __get_user(restorer, &act->sa_restorer) || > __get_user(new_ka.sa.sa_flags, &act->sa_flags) || > __get_user(mask, &act->sa_mask)) > return -EFAULT; > + new_ka.sa.sa_handler = compat_ptr(handler); > + new_ka.sa.sa_restorer = compat_ptr(restorer); > siginitset(&new_ka.sa.sa_mask, mask); > } > > @@ -353,7 +356,10 @@ long sys32_rt_sigaction(int sig, const s > return -EINVAL; > > if (act) { > - ret = get_user((long)new_ka.sa.sa_handler, &act->sa_handler); > + compat_uptr_t handler; > + > + ret = get_user(handler, &act->sa_handler); > + new_ka.sa.sa_handler = compat_ptr(handler); > ret |= __copy_from_user(&set32, &act->sa_mask, > sizeof(compat_sigset_t)); > sigset_from_compat(&new_ka.sa.sa_mask, &set32); > @@ -618,6 +624,7 @@ int sys32_sigaltstack(u32 newstack, u32 > int ret; > mm_segment_t old_fs; > unsigned long sp; > + compat_uptr_t ss_sp; > > /* > * set sp to the user stack on entry to the system call > @@ -626,14 +633,16 @@ int sys32_sigaltstack(u32 newstack, u32 > sp = regs->gpr[1]; > > /* Put new stack info in local 64 bit stack struct */ > - if (newstack && > - (get_user((long)uss.ss_sp, > - &((stack_32_t *)(long)newstack)->ss_sp) || > - __get_user(uss.ss_flags, > - &((stack_32_t *)(long)newstack)->ss_flags) || > - __get_user(uss.ss_size, > - &((stack_32_t *)(long)newstack)->ss_size))) > - return -EFAULT; > + if (newstack) { > + if (get_user(ss_sp, > + &((stack_32_t *)(long)newstack)->ss_sp) || > + __get_user(uss.ss_flags, > + &((stack_32_t *)(long)newstack)->ss_flags) || > + __get_user(uss.ss_size, > + &((stack_32_t *)(long)newstack)->ss_size)) > + return -EFAULT; > + uss.ss_sp = compat_ptr(ss_sp); > + } > > old_fs = get_fs(); > set_fs(KERNEL_DS); > -- Benjamin Herrenschmidt ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Tue Apr 13 23:02:17 2004 From: anton at samba.org (Anton Blanchard) Date: Tue, 13 Apr 2004 23:02:17 +1000 Subject: ppc64 HW profiling support for oprofile Message-ID: <20040413130217.GU22471@krispykreme> Hi, Support for using HW performance counters in ppc64 oprofile has just been merged into 2.6. Attached is the userspace patch, it should apply against latest CVS. Also attached is a dodgy script used to program the PMCs. POWER4 and 970 have a complex design which is best programmed from userspace. The PMCs are exported via sysfs so userspace programs can do the setup. Oprofile then just counts opaque events (events are called PMC1 - PMC8). pmc_it is that dodgy script and takes an input file in the form: mmcr0:mmcr1:mmcra and applies it to all cpus via sysfs. I expect we will have a better solution soon (maybe opcontrol should call out to something that calculates mmcr0,1,a and programs them). pmc_cycles is a very simple setup, counting cycles on PMC1. More combinations should be on the way soon. An example run: power4/970: # pmc_it pmc_cycles # opcontrol --setup --vmlinux=/root/vmlinux -e PMC1:100000:0:1:1 # opcontrol --start [ do stuff ] # opreport -nl power3/rs64: # opcontrol --setup --vmlinux=/root/vmlinux -e CYCLES:100000:0:1:1 # opcontrol --start [ do stuff ] # opreport -nl -------------- next part -------------- diff --exclude=CVS -urN oprofile.orig/events/Makefile.am oprofile/events/Makefile.am --- oprofile.orig/events/Makefile.am 2004-04-13 22:06:22.739166304 +1000 +++ oprofile/events/Makefile.am 2004-04-13 21:32:11.025170320 +1000 @@ -14,6 +14,11 @@ ia64/ia64/events ia64/ia64/unit_masks \ ia64/itanium2/events ia64/itanium2/unit_masks \ ia64/itanium/events ia64/itanium/unit_masks \ + ppc64/970/events ppc64/970/unit_masks \ + ppc64/rs64/events ppc64/rs64/unit_masks \ + ppc64/power3/events ppc64/power3/unit_masks \ + ppc64/power4/events ppc64/power4/unit_masks \ + ppc64/power5/events ppc64/power5/unit_masks \ rtc/events rtc/unit_masks \ x86-64/hammer/events x86-64/hammer/unit_masks \ arm/xscale1/events arm/xscale1/unit_masks \ diff --exclude=CVS -urN oprofile.orig/events/ppc64/970/events oprofile/events/ppc64/970/events --- oprofile.orig/events/ppc64/970/events 1970-01-01 10:00:00.000000000 +1000 +++ oprofile/events/ppc64/970/events 2004-04-13 21:45:30.066238960 +1000 @@ -0,0 +1,10 @@ +# ppc64 970 events +# +event:0x00 counters:0 um:zero minimum:1000 name:PMC1 : PMC1 +event:0x01 counters:1 um:zero minimum:1000 name:PMC2 : PMC2 +event:0x02 counters:2 um:zero minimum:1000 name:PMC3 : PMC3 +event:0x03 counters:3 um:zero minimum:1000 name:PMC4 : PMC4 +event:0x04 counters:4 um:zero minimum:1000 name:PMC5 : PMC5 +event:0x05 counters:5 um:zero minimum:1000 name:PMC6 : PMC6 +event:0x06 counters:6 um:zero minimum:1000 name:PMC7 : PMC7 +event:0x07 counters:7 um:zero minimum:1000 name:PMC8 : PMC8 diff --exclude=CVS -urN oprofile.orig/events/ppc64/970/unit_masks oprofile/events/ppc64/970/unit_masks --- oprofile.orig/events/ppc64/970/unit_masks 1970-01-01 10:00:00.000000000 +1000 +++ oprofile/events/ppc64/970/unit_masks 2004-04-11 16:06:55.000000000 +1000 @@ -0,0 +1,4 @@ +# ppc64 970 possible unit masks +# +name:zero type:mandatory default:0x0 + 0x0 No unit mask diff --exclude=CVS -urN oprofile.orig/events/ppc64/power3/events oprofile/events/ppc64/power3/events --- oprofile.orig/events/ppc64/power3/events 1970-01-01 10:00:00.000000000 +1000 +++ oprofile/events/ppc64/power3/events 2004-04-13 22:04:54.374155664 +1000 @@ -0,0 +1,8 @@ +# ppc64 POWER3 events +# +event:0x00 counters:0 um:zero minimum:1000 name:CYCLES : Total cycles +# +event:0x5 counters:0 um:zero minimum:1000 name:L1_ICACHE_MISS : Level 1 icache misses +event:0x6 counters:0 um:zero minimum:1000 name:L1_DCACHE_MISS : Level 1 dcache misses +# +event:0x13 counters:0 um:zero minimum:1000 name:TLB_MISS : TLB misses diff --exclude=CVS -urN oprofile.orig/events/ppc64/power3/unit_masks oprofile/events/ppc64/power3/unit_masks --- oprofile.orig/events/ppc64/power3/unit_masks 1970-01-01 10:00:00.000000000 +1000 +++ oprofile/events/ppc64/power3/unit_masks 2004-04-11 16:06:55.000000000 +1000 @@ -0,0 +1,4 @@ +# ppc64 POWER3 possible unit masks +# +name:zero type:mandatory default:0x0 + 0x0 No unit mask diff --exclude=CVS -urN oprofile.orig/events/ppc64/power4/events oprofile/events/ppc64/power4/events --- oprofile.orig/events/ppc64/power4/events 1970-01-01 10:00:00.000000000 +1000 +++ oprofile/events/ppc64/power4/events 2004-04-13 21:46:10.163133624 +1000 @@ -0,0 +1,10 @@ +# ppc64 POWER4 events +# +event:0x00 counters:0 um:zero minimum:1000 name:PMC1 : PMC1 +event:0x01 counters:1 um:zero minimum:1000 name:PMC2 : PMC2 +event:0x02 counters:2 um:zero minimum:1000 name:PMC3 : PMC3 +event:0x03 counters:3 um:zero minimum:1000 name:PMC4 : PMC4 +event:0x04 counters:4 um:zero minimum:1000 name:PMC5 : PMC5 +event:0x05 counters:5 um:zero minimum:1000 name:PMC6 : PMC6 +event:0x06 counters:6 um:zero minimum:1000 name:PMC7 : PMC7 +event:0x07 counters:7 um:zero minimum:1000 name:PMC8 : PMC8 diff --exclude=CVS -urN oprofile.orig/events/ppc64/power4/unit_masks oprofile/events/ppc64/power4/unit_masks --- oprofile.orig/events/ppc64/power4/unit_masks 1970-01-01 10:00:00.000000000 +1000 +++ oprofile/events/ppc64/power4/unit_masks 2004-04-11 16:06:55.000000000 +1000 @@ -0,0 +1,4 @@ +# ppc64 POWER4 possible unit masks +# +name:zero type:mandatory default:0x0 + 0x0 No unit mask diff --exclude=CVS -urN oprofile.orig/events/ppc64/power5/events oprofile/events/ppc64/power5/events --- oprofile.orig/events/ppc64/power5/events 1970-01-01 10:00:00.000000000 +1000 +++ oprofile/events/ppc64/power5/events 2004-04-13 21:45:54.589237048 +1000 @@ -0,0 +1,8 @@ +# ppc64 POWER5 events +# +event:0x00 counters:0 um:zero minimum:1000 name:PMC1 : PMC1 +event:0x01 counters:1 um:zero minimum:1000 name:PMC2 : PMC2 +event:0x02 counters:2 um:zero minimum:1000 name:PMC3 : PMC3 +event:0x03 counters:3 um:zero minimum:1000 name:PMC4 : PMC4 +event:0x04 counters:4 um:zero minimum:1000 name:PMC5 : PMC5 +event:0x05 counters:5 um:zero minimum:1000 name:PMC6 : PMC6 diff --exclude=CVS -urN oprofile.orig/events/ppc64/power5/unit_masks oprofile/events/ppc64/power5/unit_masks --- oprofile.orig/events/ppc64/power5/unit_masks 1970-01-01 10:00:00.000000000 +1000 +++ oprofile/events/ppc64/power5/unit_masks 2004-04-11 16:06:55.000000000 +1000 @@ -0,0 +1,4 @@ +# ppc64 POWER5 possible unit masks +# +name:zero type:mandatory default:0x0 + 0x0 No unit mask diff --exclude=CVS -urN oprofile.orig/events/ppc64/rs64/events oprofile/events/ppc64/rs64/events --- oprofile.orig/events/ppc64/rs64/events 1970-01-01 10:00:00.000000000 +1000 +++ oprofile/events/ppc64/rs64/events 2004-04-13 22:00:18.108223000 +1000 @@ -0,0 +1,12 @@ +# ppc64 RS64 events +# +event:0x01 counters:0,1,2,3,4,5,6,7 um:zero minimum:1000 name:CYCLES : Total cycles +# +event:0x0a counters:1,3,5,7 um:zero minimum:1000 name:L1_ICACHE_MISS : Level 1 icache misses +event:0x0c counters:0,2,4,6 um:zero minimum:1000 name:L1_DCACHE_MISS : Level 1 dcache misses +# +event:0x55 counters:0 um:zero minimum:1000 name:TLB_I_MISS : Instruction TLB misses +event:0x55 counters:2 um:zero minimum:1000 name:TLB_D_MISS : Data TLB misses +# +event:0x5d counters:0 um:zero minimum:1000 name:SLB_I_MISS : Instruction SLB misses +event:0x5d counters:2 um:zero minimum:1000 name:SLB_D_MISS : Data SLB misses diff --exclude=CVS -urN oprofile.orig/events/ppc64/rs64/unit_masks oprofile/events/ppc64/rs64/unit_masks --- oprofile.orig/events/ppc64/rs64/unit_masks 1970-01-01 10:00:00.000000000 +1000 +++ oprofile/events/ppc64/rs64/unit_masks 2004-04-11 16:06:55.000000000 +1000 @@ -0,0 +1,4 @@ +# ppc64 RS64 possible unit masks +# +name:zero type:mandatory default:0x0 + 0x0 No unit mask diff --exclude=CVS -urN oprofile.orig/libop/op_cpu_type.c oprofile/libop/op_cpu_type.c --- oprofile.orig/libop/op_cpu_type.c 2004-04-13 22:06:23.547176640 +1000 +++ oprofile/libop/op_cpu_type.c 2004-04-13 21:34:01.932216160 +1000 @@ -43,6 +43,11 @@ { "Pentium M (P6 core)", "i386/p6_mobile", CPU_P6_MOBILE, 2 }, { "ARM/XScale PMU1", "arm/xscale1", CPU_ARM_XSCALE1, 3 }, { "ARM/XScale PMU2", "arm/xscale2", CPU_ARM_XSCALE2, 5 }, + { "ppc64 RS64", "ppc64/rs64", CPU_PPC64_RS64, 8 }, + { "ppc64 POWER3", "ppc64/power3", CPU_PPC64_POWER3, 8 }, + { "ppc64 POWER4", "ppc64/power4", CPU_PPC64_POWER4, 8 }, + { "ppc64 970", "ppc64/970", CPU_PPC64_970, 8 }, + { "ppc64 POWER5", "ppc64/power5", CPU_PPC64_POWER5, 6 }, }; static size_t const nr_cpu_descrs = sizeof(cpu_descrs) / sizeof(struct cpu_descr); diff --exclude=CVS -urN oprofile.orig/libop/op_cpu_type.h oprofile/libop/op_cpu_type.h --- oprofile.orig/libop/op_cpu_type.h 2004-04-13 22:06:23.572172840 +1000 +++ oprofile/libop/op_cpu_type.h 2004-04-13 21:34:25.528222608 +1000 @@ -39,6 +39,11 @@ CPU_P6_MOBILE, /**< Pentium M series */ CPU_ARM_XSCALE1, /**< ARM XScale 1 */ CPU_ARM_XSCALE2, /**< ARM XScale 2 */ + CPU_PPC64_RS64, /**< ppc64 RS64 family */ + CPU_PPC64_POWER3, /**< ppc64 RS64 family */ + CPU_PPC64_POWER4, /**< ppc64 POWER4 family */ + CPU_PPC64_970, /**< ppc64 970 family */ + CPU_PPC64_POWER5, /**< ppc64 POWER5 family */ MAX_CPU_TYPE } op_cpu; diff --exclude=CVS -urN oprofile.orig/libop/op_events.c oprofile/libop/op_events.c --- oprofile.orig/libop/op_events.c 2004-04-13 22:06:23.897123440 +1000 +++ oprofile/libop/op_events.c 2004-04-13 21:34:51.690239936 +1000 @@ -651,6 +651,14 @@ descr->name = "CPU_CYCLES"; break; + case CPU_PPC64_RS64: + case CPU_PPC64_POWER3: + case CPU_PPC64_POWER4: + case CPU_PPC64_970: + case CPU_PPC64_POWER5: + descr->name = "CYCLES"; + break; + // don't use default, if someone add a cpu he wants a compiler // warning if he forgets to handle it here. case CPU_TIMER_INT: diff --exclude=CVS -urN oprofile.orig/utils/op_help.c oprofile/utils/op_help.c --- oprofile.orig/utils/op_help.c 2004-04-13 22:06:24.407180072 +1000 +++ oprofile/utils/op_help.c 2004-04-13 21:44:10.369240328 +1000 @@ -403,6 +403,14 @@ printf("See Intel XScale Core Developer's Manual\n" "Chapter 8 Performance Monitoring\n"); break; + case CPU_PPC64_RS64: + case CPU_PPC64_POWER3: + case CPU_PPC64_POWER4: + case CPU_PPC64_970: + case CPU_PPC64_POWER5: + printf("See PowerPC Architecture Book 3\n" + "http://www-106.ibm.com/developerworks/eserver/articles/archguide.html\n"); + break; case CPU_RTC: break; -------------- next part -------------- #!/usr/bin/perl -w use strict; my @cpus; open(CPUINFO, "/proc/cpuinfo") || die("could not open /proc/cpuinfo"); while() { if (/processor/) { my ($junk, $cpu) = split(/:/); push @cpus, $cpu; } } close(CPUINFO); while(<>) { if (/^#/) { print $_; next; } chop; my ($mmcr0, $mmcr1, $mmcra) = split(/:/); my $cpu; for $cpu (@cpus) { my $cpufile = sprintf("/sys/devices/system/cpu/cpu%d", $cpu); system("echo $mmcr0 > $cpufile/mmcr0"); system("echo $mmcr1 > $cpufile/mmcr1"); system("echo $mmcra > $cpufile/mmcra"); } } -------------- next part -------------- # format: mmcr0:mmcr1:mmcra # # cycles in PMC1 00000700:0:0 From hozer at hozed.org Wed Apr 14 07:57:06 2004 From: hozer at hozed.org (Troy Benjegerdes) Date: Tue, 13 Apr 2004 16:57:06 -0500 Subject: radeon 9600's dieing in G5's Message-ID: <20040413215705.GD25737@kalmia.hozed.org> For some reason, right after getting a 2.6 kernel built, I've managed to kill 2 radeon 9600 video cards. They don't show up in apple system profiler (I had to ssh into the box runnign OSX), and running linux, radeonfb prints a message about "can't map MMIO region" Has anyone else had problems with this? Is this something related to running linux, or just a known problem with early G5's? -- -------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer at hozed.org ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Wed Apr 14 08:28:24 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 13 Apr 2004 17:28:24 -0500 Subject: hvc_console & interrupts: reworked patch In-Reply-To: <1081844516.25144.237.camel@gaston> References: <1081844516.25144.237.camel@gaston> Message-ID: <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> On Tue, 2004-04-13 at 03:21, Benjamin Herrenschmidt wrote: > This patch is _TOTALLY UNTESTED_, I'll do that tomorrow, but at least > the chosen approach can be discussed here in the meantime. So I rewrote > Ryan's patch in a different way that, of course, I personally prefer ;) Ben, I've given your patch a little look and see some things I'm concerned about but for the most part I think your solution is quite clever. 1.) A printk test reveals that several hvc_open calls are made before any hvc_close calls are paired against them this brings up the following concerns: drivers/char/hvc_console.c line 109 if (irq != NO_IRQ) request_irq(irq, hvc_handle_interrupt, SA_INTERRUPT, "hvc_console", hp); What are the implications of requesting the irq with every hvc_open rather than when hvc_count == 1? Is a redundant request harmless? This call is made every time a user program intends to output something to the console. 2.) drivers/char/hvc_console.c line 140 bail: spin_unlock_irqrestore(&hp->lock, flags); if (irq != NO_IRQ) free_irq(irq, hp); Additionally the irq is freed with every hvc_close call that is made. What is the effect of freeing the irq if there are still several instances of programs that have the tty open? This kind of behavior was the cause of a bug which prevented proper interrupt behavior in my removed patch. I'm interested if the same behavior is exhibited in your patch (I will test it when my system is available). 3.) I've experienced runtime debug warning messages when requesting the irq in hvc_open in my patch and you seem to do the same thing. I never did figure out how/why the system thinks that request_irq is sleeping inside of a spinlock when called from within hvc_open(). If we don't request the irq there I don't know of an appropriate place. 4.) arch/ppc64/kernel/hvconsole.c line 740 irq_p = (unsigned int *)get_property(vty, "interrupts", 0); This seems to return a valid [yet unexpected/undocumented] IRQ on POWER-4 and this is how my patch broke antonb's system. I'm have no idea how firmware reacts with vty interrupts on POWER-4 and I'm reluctant to use the interrupt driven mechanism on that hardware if it does because I was led to believe that this wasn't actually supported until recently on Power-5 systems, and not at all on Power-4. Maybe we need to see what get_property() returns for bogus strings on POWER-4. If we can't just determine that the system is POWER-5 based on the presence of a vty int some other method would have to be used. Ben do you have a power-4 to test this on? 5.) > Ryan: I suppose the interrupt acts like an "edge" trigger that gets > re-armed when HV returns 0 bytes on a read, right ? Ben, yes this is the behavior. Another interrupt will not be dispatched by firmware (HV) until all the data from the original interrupt has been removed from the firmware buffer (meaning HV returns 0 bytes on read). This leads me to believe that we don't need to worry about enabling and disabling interrupts. 6.) drivers/char/hvc_console.c line 357 read_total += n; if (read_total >= 64) { poll_mask |= HVC_POLL_QUICK; break; } This is an interesting technique which I like better than simply rescheduling after every HV read which is wasteful. Does the magic value of 64 have something to do with TTY_THRESHOLD_THROTTLE being 128? You obviously use it TTY throttle predictor anticipator. The danger is that when you push the data if you over estimated the amount of data you could flip you just end up over writing the tty buffer. If you underestimated then the TTY will never throttle and you'll never get the TTY unthrottle callback, hence no hvc_kick() to continue reading data. 7.) drivers/char/hvc_console.c line 328 n = hvc_arch_get_chars(index, buf, count); if (n <= 0) { /* XXX What is that supposed to do ? */ if (n == -EPIPE) tty_hangup(tty); break; } On Power-5 systems the listening client adapter can go away at any time, meaning there would be no-one sending chars and the HV returns H_Closed which hvc_arch_get_chars() in arch/ppc64/hvconsole returns as 0. So, this n == -EPIPE doesn't seem to ever happen. It may seem strange to ignore a negative return value on hvc_arch_get_chars() but I think it may be necessary. If it did return -EPIPE the hangup would the kill the connection of all of the userland programs that have the tty open. I don't think that the tty_hangup is appropriate in this case since the vty is a passive server who simply waits until there is a client adapter connected. Hanging up userland apps like this on Power-5 systems might cause problems when a user switches between HMC console and HVCS console client adapters. 8.) Is there a reason you decided it would be better to converge the int & polling mechanism into this single mechanism when we actually talked about diverging the functions into separate tty_operation callbacks [though I like your new method better]? I'm still concerned about the work_queue scheduling anomalies everyone hints at and I'm wondering if that contributed to your decision since I still use them in another driver. I think it is overall a pretty interesting patch but I'd like to give it a going over with some of my console tests on my power-5 system first. I'll do that on Wednesday. Ryan S. Arnold IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Wed Apr 14 09:41:49 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 14 Apr 2004 09:41:49 +1000 Subject: hvc_console & interrupts: reworked patch In-Reply-To: <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> Message-ID: <1081899709.2134.27.camel@gaston> On Wed, 2004-04-14 at 08:28, Ryan Arnold wrote: > On Tue, 2004-04-13 at 03:21, Benjamin Herrenschmidt wrote: > > > This patch is _TOTALLY UNTESTED_, I'll do that tomorrow, but at least > > the chosen approach can be discussed here in the meantime. So I rewrote > > Ryan's patch in a different way that, of course, I personally prefer ;) > > Ben, I've given your patch a little look and see some things I'm > concerned about but for the most part I think your solution is quite > clever. > > 1.) A printk test reveals that several hvc_open calls are made before > any hvc_close calls are paired against them this brings up the following > concerns: > > drivers/char/hvc_console.c line 109 > if (irq != NO_IRQ) > request_irq(irq, hvc_handle_interrupt, SA_INTERRUPT, > "hvc_console", hp); No, if you look properly, you'll notice that I only fill the "irq" local variable on the first open and last close. > 2.) drivers/char/hvc_console.c line 140 > > bail: > spin_unlock_irqrestore(&hp->lock, flags); > if (irq != NO_IRQ) > free_irq(irq, hp); > > Additionally the irq is freed with every hvc_close call that is made. > What is the effect of freeing the irq if there are still several > instances of programs that have the tty open? Same comment > 3.) I've experienced runtime debug warning messages when requesting the > irq in hvc_open in my patch and you seem to do the same thing. I never > did figure out how/why the system thinks that request_irq is sleeping > inside of a spinlock when called from within hvc_open(). If we don't > request the irq there I don't know of an appropriate place. Which is why I do it outside of the spinlock. request_irq can allocate memory and get deep into procfs when setting up the irq affinity stuff, so it must not be called within a spinlock. > 4.) arch/ppc64/kernel/hvconsole.c line 740 > > irq_p = (unsigned int *)get_property(vty, "interrupts", 0); The above was just copied from your patch ;) > This seems to return a valid [yet unexpected/undocumented] IRQ on > POWER-4 and this is how my patch broke antonb's system. I'm have no > idea how firmware reacts with vty interrupts on POWER-4 and I'm > reluctant to use the interrupt driven mechanism on that hardware if it > does because I was led to believe that this wasn't actually supported > until recently on Power-5 systems, and not at all on Power-4. Ok, I'll have a look. What does the RPA says ? > Maybe we need to see what get_property() returns for bogus strings on > POWER-4. If we can't just determine that the system is POWER-5 based on > the presence of a vty int some other method would have to be used. Ben > do you have a power-4 to test this on? I do. > 5.) > > Ryan: I suppose the interrupt acts like an "edge" trigger that gets > > re-armed when HV returns 0 bytes on a read, right ? > > Ben, yes this is the behavior. Another interrupt will not be dispatched > by firmware (HV) until all the data from the original interrupt has been > removed from the firmware buffer (meaning HV returns 0 bytes on read). > This leads me to believe that we don't need to worry about enabling and > disabling interrupts. Yup. > 6.) drivers/char/hvc_console.c line 357 > read_total += n; > if (read_total >= 64) { > poll_mask |= HVC_POLL_QUICK; > break; > } > > This is an interesting technique which I like better than simply > rescheduling after every HV read which is wasteful. Does the magic > value of 64 have something to do with TTY_THRESHOLD_THROTTLE being 128? Yes, it looks good to use half, but testing may lead us toward a different value. > You obviously use it TTY throttle predictor anticipator. The danger is > that when you push the data if you over estimated the amount of data you > could flip you just end up over writing the tty buffer. > > If you underestimated then the TTY will never throttle and you'll never > get the TTY unthrottle callback, hence no hvc_kick() to continue reading > data. How so ? I don't need kick to continue reading data on a non-throttled line. Just the interrupt or the 10ms timeout on non-interrupt setups. Or is there a bug ? > 7.) drivers/char/hvc_console.c line 328 > > n = hvc_arch_get_chars(index, buf, count); > if (n <= 0) { > /* XXX What is that supposed to do ? */ > if (n == -EPIPE) > tty_hangup(tty); > break; > } > > On Power-5 systems the listening client adapter can go away at any time, > meaning there would be no-one sending chars and the HV returns H_Closed > which hvc_arch_get_chars() in arch/ppc64/hvconsole returns as 0. So, > this n == -EPIPE doesn't seem to ever happen. > > It may seem strange to ignore a negative return value on > hvc_arch_get_chars() but I think it may be necessary. Yes. If we had some kind of hotplug, it would make sense, I don't think we really want to do a hangup which is a bit too drastic imho. > If it did return -EPIPE the hangup would the kill the connection of all > of the userland programs that have the tty open. I don't think that the > tty_hangup is appropriate in this case since the vty is a passive server > who simply waits until there is a client adapter connected. Hanging up > userland apps like this on Power-5 systems might cause problems when a > user switches between HMC console and HVCS console client adapters. Yup. > 8.) Is there a reason you decided it would be better to converge the int > & polling mechanism into this single mechanism when we actually talked > about diverging the functions into separate tty_operation callbacks > [though I like your new method better]? I'm still concerned about the > work_queue scheduling anomalies everyone hints at and I'm wondering if > that contributed to your decision since I still use them in another > driver. Separate tty operations would have been justified if the underlying implementation was really different. After looking at it, it seems the write path can be exactly the same, the only difference is the interrupt 'notification' on reads, so I choose the least changes approach, it's also the better on the line-counter ;) Also, I prefer not loading the workqueues too much. > I think it is overall a pretty interesting patch but I'd like to give it > a going over with some of my console tests on my power-5 system first. > I'll do that on Wednesday. Sure. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Wed Apr 14 11:13:11 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 14 Apr 2004 11:13:11 +1000 Subject: radeon 9600's dieing in G5's In-Reply-To: <20040413215705.GD25737@kalmia.hozed.org> References: <20040413215705.GD25737@kalmia.hozed.org> Message-ID: <1081905191.2127.32.camel@gaston> On Wed, 2004-04-14 at 07:57, Troy Benjegerdes wrote: > For some reason, right after getting a 2.6 kernel built, I've managed to > kill 2 radeon 9600 video cards. They don't show up in apple system > profiler (I had to ssh into the box runnign OSX), and running linux, > radeonfb prints a message about "can't map MMIO region" > > Has anyone else had problems with this? Is this something related to > running linux, or just a known problem with early G5's? My G5 died the same way, I hope it's not caused by Linux =P Apparently, if I let the machine "heat" long enough, then reboot a few times, I would get the video back... sometimes. I got it replaced. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Wed Apr 14 14:00:25 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 14 Apr 2004 14:00:25 +1000 Subject: hvc_console & interrupts: reworked patch In-Reply-To: <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> Message-ID: <1081915223.2134.89.camel@gaston> Ok, here's a new patch, very little differences, it's tested on a POWER4 machine. The machine doesn't claim to have an "interrupts" property so it just works. We need to double check what's up there, the RPA seem to be clear about having that property means we get the interrupt, but maybe we need to explicitely enable it with RTAS ? Ben. ===== arch/ppc64/kernel/hvconsole.c 1.10 vs edited ===== --- 1.10/arch/ppc64/kernel/hvconsole.c Sat Apr 10 08:11:48 2004 +++ edited/arch/ppc64/kernel/hvconsole.c Wed Apr 14 12:09:47 2004 @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -50,6 +51,7 @@ int (*tiocmset)(struct vtty_struct *vtty, uint16_t set, uint16_t clear); uint16_t seqno; /* HVSI packet sequence number */ uint16_t mctrl; + int irq; }; static struct vtty_struct vttys[MAX_NR_HVC_CONSOLES]; @@ -718,6 +720,7 @@ { struct device_node *vty; int count = 0; + unsigned int *irq_p; for (vty = of_find_node_by_name(NULL, "vty"); vty != NULL; vty = of_find_node_by_name(vty, "vty")) { @@ -732,12 +735,19 @@ break; vtty = &vttys[count]; + vtty->irq = NO_IRQ; if (device_is_compatible(vty, "hvterm1")) { vtty->vtermno = *vtermno; vtty->get_chars = hvc_hvterm_get_chars; vtty->put_chars = hvc_hvterm_put_chars; vtty->tiocmget = NULL; vtty->tiocmset = NULL; + irq_p = (unsigned int *)get_property(vty, "interrupts", 0); + if (irq_p) { + int virq = virt_irq_create_mapping(*irq_p); + if (virq != NO_IRQ) + vtty->irq = irq_offset_up(virq); + } hvc_instantiate(); count++; } else if (device_is_compatible(vty, "hvterm-protocol")) { @@ -758,6 +768,14 @@ return count; } + +int hvc_interrupt(int index) +{ + struct vtty_struct *vtty = &vttys[index]; + + /* If not interruptible then it'll return NO_IRQ */ + return vtty->irq; +} /* Convert arch specific return codes into relevant errnos. The hvcs * functions aren't performance sensitive, so this conversion isn't an ===== drivers/char/hvc_console.c 1.25 vs edited ===== --- 1.25/drivers/char/hvc_console.c Sat Apr 10 08:11:48 2004 +++ edited/drivers/char/hvc_console.c Wed Apr 14 13:38:37 2004 @@ -38,12 +38,15 @@ #define TIMEOUT ((HZ + 99) / 100) static struct tty_driver *hvc_driver; -static int count; +static int hvc_count; +static int hvc_kicked; +static wait_queue_head_t hvc_wait_queue; #ifdef CONFIG_MAGIC_SYSRQ static int sysrq_pressed; #endif #define N_OUTBUF 16 +#define N_INBUF 16 #define __ALIGNED__ __attribute__((__aligned__(8))) @@ -59,15 +62,34 @@ int do_wakeup; char outbuf[N_OUTBUF] __ALIGNED__; int n_outbuf; + int irq_requested; }; struct hvc_struct hvc_struct[MAX_NR_HVC_CONSOLES]; +static void hvc_kick(void) +{ + hvc_kicked = 1; + wake_up_interruptible(&hvc_wait_queue); +} + +static irqreturn_t hvc_handle_interrupt(int irq, void *dev_instance, struct pt_regs *regs) +{ + hvc_kick(); + return IRQ_HANDLED; +} + +static void hvc_unthrottle(struct tty_struct *tty) +{ + hvc_kick(); +} + static int hvc_open(struct tty_struct *tty, struct file * filp) { int line = tty->index; struct hvc_struct *hp; unsigned long flags; + int irq = NO_IRQ; if (line < 0 || line >= MAX_NR_HVC_CONSOLES) return -ENODEV; @@ -77,7 +99,18 @@ spin_lock_irqsave(&hp->lock, flags); hp->tty = tty; hp->count++; + if (hp->count == 1) { + irq = hvc_interrupt(hp->index); + if (irq != NO_IRQ) + hp->irq_requested = 1; + } spin_unlock_irqrestore(&hp->lock, flags); + /* XX check error, fallback to non-irq ? */ + if (irq != NO_IRQ) + request_irq(irq, hvc_handle_interrupt, SA_INTERRUPT, "hvc_console", hp); + + /* Force wakeup of the polling thread */ + hvc_kick(); return 0; } @@ -86,16 +119,28 @@ { struct hvc_struct *hp = tty->driver_data; unsigned long flags; + int irq = NO_IRQ; - if (tty_hung_up_p(filp)) - return; spin_lock_irqsave(&hp->lock, flags); - if (--hp->count == 0) + if (tty_hung_up_p(filp)) { + if (hp->irq_requested) + irq = hvc_interrupt(hp->index); + hp->irq_requested = 0; + goto bail; + } + + if (--hp->count == 0) { hp->tty = NULL; - else if (hp->count < 0) + if (hp->irq_requested) + irq = hvc_interrupt(hp->index); + hp->irq_requested = 0; + } else if (hp->count < 0) printk(KERN_ERR "hvc_close %lu: oops, count is %d\n", hp - hvc_struct, hp->count); + bail: spin_unlock_irqrestore(&hp->lock, flags); + if (irq != NO_IRQ) + free_irq(irq, hp); } static void hvc_hangup(struct tty_struct *tty) @@ -126,69 +171,103 @@ hp->do_wakeup = 1; } -static int hvc_write(struct tty_struct *tty, int from_user, - const unsigned char *buf, int count) +static inline int __hvc_write_user(struct hvc_struct *hp, + const unsigned char *buf, int count) { - struct hvc_struct *hp = tty->driver_data; char *tbuf, *p; int tbsize, rsize, written = 0; unsigned long flags; - if (from_user) { - tbsize = min(count, (int)PAGE_SIZE); - if (!(tbuf = kmalloc(tbsize, GFP_KERNEL))) - return -ENOMEM; - - while ((rsize = count - written) > 0) { - int wsize; - if (rsize > tbsize) - rsize = tbsize; - - p = tbuf; - rsize -= copy_from_user(p, buf, rsize); - if (!rsize) { - if (written == 0) - written = -EFAULT; - break; - } - buf += rsize; - written += rsize; - - spin_lock_irqsave(&hp->lock, flags); - for (wsize = N_OUTBUF - hp->n_outbuf; rsize && wsize; - wsize = N_OUTBUF - hp->n_outbuf) { - if (wsize > rsize) - wsize = rsize; - memcpy(hp->outbuf + hp->n_outbuf, p, wsize); - hp->n_outbuf += wsize; - hvc_push(hp); - rsize -= wsize; - p += wsize; - } - spin_unlock_irqrestore(&hp->lock, flags); - - if (rsize) - break; + tbsize = min(count, (int)PAGE_SIZE); + if (!(tbuf = kmalloc(tbsize, GFP_KERNEL))) + return -ENOMEM; - if (count < tbsize) - tbsize = count; + while ((rsize = count - written) > 0) { + int wsize; + if (rsize > tbsize) + rsize = tbsize; + + p = tbuf; + rsize -= copy_from_user(p, buf, rsize); + if (!rsize) { + if (written == 0) + written = -EFAULT; + break; } + buf += rsize; - kfree(tbuf); - } else { spin_lock_irqsave(&hp->lock, flags); - while (count > 0 && (rsize = N_OUTBUF - hp->n_outbuf) > 0) { - if (rsize > count) - rsize = count; - memcpy(hp->outbuf + hp->n_outbuf, buf, rsize); - count -= rsize; - buf += rsize; - hp->n_outbuf += rsize; - written += rsize; + + /* Push pending writes: make some room in buffer */ + if (hp->n_outbuf > 0) hvc_push(hp); + + for (wsize = N_OUTBUF - hp->n_outbuf; rsize && wsize; + wsize = N_OUTBUF - hp->n_outbuf) { + if (wsize > rsize) + wsize = rsize; + memcpy(hp->outbuf + hp->n_outbuf, p, wsize); + hp->n_outbuf += wsize; + hvc_push(hp); + rsize -= wsize; + p += wsize; + written += wsize; } spin_unlock_irqrestore(&hp->lock, flags); + + if (rsize) + break; + + if (count < tbsize) + tbsize = count; + } + + kfree(tbuf); + + return written; +} + +static inline int __hvc_write_kernel(struct hvc_struct *hp, + const unsigned char *buf, int count) +{ + unsigned long flags; + int rsize, written = 0; + + spin_lock_irqsave(&hp->lock, flags); + + /* Push pending writes */ + if (hp->n_outbuf > 0) + hvc_push(hp); + + while (count > 0 && (rsize = N_OUTBUF - hp->n_outbuf) > 0) { + if (rsize > count) + rsize = count; + memcpy(hp->outbuf + hp->n_outbuf, buf, rsize); + count -= rsize; + buf += rsize; + hp->n_outbuf += rsize; + written += rsize; + hvc_push(hp); } + spin_unlock_irqrestore(&hp->lock, flags); + + return written; +} + +static int hvc_write(struct tty_struct *tty, int from_user, + const unsigned char *buf, int count) +{ + struct hvc_struct *hp = tty->driver_data; + int written; + + if (from_user) + written = __hvc_write_user(hp, buf, count); + else + written = __hvc_write_kernel(hp, buf, count); + + /* Racy, but harmless, kick thread if there are still pending data */ + if (hp->n_outbuf) + hvc_kick(); return written; } @@ -207,59 +286,103 @@ return hp->n_outbuf; } -static void hvc_poll(int index) +#define HVC_POLL_READ 0x00000001 +#define HVC_POLL_WRITE 0x00000002 +#define HVC_POLL_QUICK 0x00000004 + +static int hvc_poll(int index) { struct hvc_struct *hp = &hvc_struct[index]; struct tty_struct *tty; - int i, n; - char buf[16] __ALIGNED__; + int i, n, poll_mask = 0; + char buf[N_INBUF] __ALIGNED__; unsigned long flags; + int read_total = 0; spin_lock_irqsave(&hp->lock, flags); + /* Push pending writes */ if (hp->n_outbuf > 0) hvc_push(hp); + /* Reschedule us if still some write pending */ + if (hp->n_outbuf > 0) + poll_mask |= HVC_POLL_WRITE; + /* No tty attached, just skip */ tty = hp->tty; - if (tty) { - for (;;) { - if (TTY_FLIPBUF_SIZE - tty->flip.count < sizeof(buf)) - break; - n = hvc_arch_get_chars(index, buf, sizeof(buf)); - if (n <= 0) { - if (n == -EPIPE) { - printk("tty_hangup\n"); - tty_hangup(tty); - } - break; - } - for (i = 0; i < n; ++i) { -#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */ - if (buf[i] == '\x0f') { /* ^O -- should support a sequence */ - sysrq_pressed = 1; - continue; - } else if (sysrq_pressed) { - handle_sysrq(buf[i], NULL, tty); - sysrq_pressed = 0; - continue; - } -#endif - tty_insert_flip_char(tty, buf[i], 0); + if (tty == NULL) + goto bail; + + /* Now check if we can get data (are we throttled ?) */ + if (test_bit(TTY_THROTTLED, &tty->flags)) + goto throttled; + + /* If we aren't interrupt driven and aren't throttled, we always + * request a reschedule + */ + if (hvc_interrupt(index) == NO_IRQ) + poll_mask |= HVC_POLL_READ; + + /* Read data if any */ + for (;;) { + int count = N_INBUF; + if (count > (TTY_FLIPBUF_SIZE - tty->flip.count)) + count = TTY_FLIPBUF_SIZE - tty->flip.count; + + /* If flip is full, just reschedule a later read */ + if (count == 0) { + poll_mask |= HVC_POLL_READ; + break; + } + + n = hvc_arch_get_chars(index, buf, count); + if (n <= 0) { + /* XXX What is that supposed to do ? */ + if (n == -EPIPE) + tty_hangup(tty); + break; + } + for (i = 0; i < n; ++i) { +#ifdef CONFIG_MAGIC_SYSRQ + /* Handle the SysRq Hack */ + if (buf[i] == '\x0f') { /* ^O -- should support a sequence */ + sysrq_pressed = 1; + continue; + } else if (sysrq_pressed) { + handle_sysrq(buf[i], NULL, tty); + sysrq_pressed = 0; + continue; } +#endif /* CONFIG_MAGIC_SYSRQ */ + tty_insert_flip_char(tty, buf[i], 0); } + if (tty->flip.count) tty_schedule_flip(tty); - if (hp->do_wakeup) { - hp->do_wakeup = 0; - if ((tty->flags & (1 << TTY_DO_WRITE_WAKEUP)) - && tty->ldisc.write_wakeup) - (tty->ldisc.write_wakeup)(tty); - wake_up_interruptible(&tty->write_wait); + /* Account the total amount read in one loop, and if above 64 bytes, + * we do a quick schedule loop to let the tty grok the data and + * eventually throttle us + */ + read_total += n; + if (read_total >= 64) { + poll_mask |= HVC_POLL_QUICK; + break; } } - + throttled: + /* Wakeup write queue if necessary */ + if (hp->do_wakeup) { + hp->do_wakeup = 0; + if ((tty->flags & (1 << TTY_DO_WRITE_WAKEUP)) + && tty->ldisc.write_wakeup) + (tty->ldisc.write_wakeup)(tty); + wake_up_interruptible(&tty->write_wait); + } + bail: spin_unlock_irqrestore(&hp->lock, flags); + + return poll_mask; } #if defined(CONFIG_XMON) && defined(CONFIG_SMP) @@ -271,17 +394,37 @@ int khvcd(void *unused) { - int i; + int i, poll_mask; daemonize("khvcd"); for (;;) { + wait_queue_t wait = __WAITQUEUE_INITIALIZER(wait,current); + + poll_mask = 0; + hvc_kicked = 0; + wmb(); if (cpus_empty(cpus_in_xmon)) { for (i = 0; i < MAX_NR_HVC_CONSOLES; ++i) - hvc_poll(i); + poll_mask |= hvc_poll(i); + } else + poll_mask |= HVC_POLL_READ; + if (hvc_kicked) + continue; + if (poll_mask & HVC_POLL_QUICK) { + yield(); + continue; } + add_wait_queue(&hvc_wait_queue, &wait); set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(TIMEOUT); + if (!hvc_kicked) { + if (poll_mask == 0) + schedule(); + else + schedule_timeout(TIMEOUT); + } + set_current_state(TASK_RUNNING); + remove_wait_queue(&hvc_wait_queue, &wait); } } @@ -314,6 +457,7 @@ .close = hvc_close, .write = hvc_write, .hangup = hvc_hangup, + .unthrottle = hvc_unthrottle, .write_room = hvc_write_room, .chars_in_buffer = hvc_chars_in_buffer, .tiocmget = hvc_tiocmget, @@ -322,7 +466,9 @@ int __init hvc_init(void) { - hvc_driver = alloc_tty_driver(count); + init_waitqueue_head(&hvc_wait_queue); + + hvc_driver = alloc_tty_driver(hvc_count); if (!hvc_driver) return -ENOMEM; @@ -340,7 +486,7 @@ if (tty_register_driver(hvc_driver)) panic("Couldn't register hvc console driver\n"); - if (count > 0) + if (hvc_count > 0) kernel_thread(khvcd, NULL, CLONE_KERNEL); else printk(KERN_WARNING "no virtual consoles found\n"); @@ -391,7 +537,7 @@ static int __init hvc_console_setup(struct console *co, char *options) { if (co->index < 0 || co->index >= MAX_NR_HVC_CONSOLES - || co->index >= count) + || co->index >= hvc_count) return -1; return 0; } @@ -410,14 +556,14 @@ { struct hvc_struct *hvc; - if (count >= MAX_NR_HVC_CONSOLES) + if (hvc_count >= MAX_NR_HVC_CONSOLES) return -1; - hvc = &hvc_struct[count]; + hvc = &hvc_struct[hvc_count]; hvc->lock = SPIN_LOCK_UNLOCKED; - hvc->index = count; + hvc->index = hvc_count; - count++; + hvc_count++; return 0; } ===== include/asm-ppc64/hvconsole.h 1.7 vs edited ===== --- 1.7/include/asm-ppc64/hvconsole.h Sat Apr 10 08:11:48 2004 +++ edited/include/asm-ppc64/hvconsole.h Wed Apr 14 12:09:41 2004 @@ -57,6 +57,7 @@ extern int hvcs_get_partner_info(unsigned int unit_address, struct list_head *head); extern int hvcs_register_connection(unsigned int unit_address, unsigned int p_partition_ID, unsigned int p_unit_address); extern int hvcs_free_connection(unsigned int unit_address); +extern int hvc_interrupt(int index); #endif /* _PPC64_HVCONSOLE_H */ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From taj.subhani at oracle.com Thu Apr 15 01:12:06 2004 From: taj.subhani at oracle.com (Mohammed Tajuddin) Date: Wed, 14 Apr 2004 08:12:06 -0700 Subject: Dwarf Error: mangled line number section In-Reply-To: <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> <1081899709.2134.27.camel@gaston> <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> Message-ID: <407D54C6.6040507@oracle.com> Hello, Has anyone faced "/usr/bin/ld: Dwarf Error: mangled line number section (bad file number)." Error. I saw a bug fix for HP 11 with this error message. Does it apply for Linux power-pc. I am using "Linux version 2.4.21-9.EL (bhcompile at cure81.devel.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-26)) #1 SMP Thu Jan 8 16:57:25 EST 2004" Regards, TAJ > > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Thu Apr 15 01:15:56 2004 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Wed, 14 Apr 2004 10:15:56 -0500 Subject: hvc_console & interrupts: reworked patch In-Reply-To: <1081899709.2134.27.camel@gaston> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> <1081899709.2134.27.camel@gaston> Message-ID: On Apr 13, 2004, at 6:41 PM, Benjamin Herrenschmidt wrote: > > On Wed, 2004-04-14 at 08:28, Ryan Arnold wrote: >> 7.) drivers/char/hvc_console.c line 328 >> >> n = hvc_arch_get_chars(index, buf, count); >> if (n <= 0) { >> /* XXX What is that supposed to do ? */ >> if (n == -EPIPE) >> tty_hangup(tty); >> break; >> } >> >> On Power-5 systems the listening client adapter can go away at any >> time, >> meaning there would be no-one sending chars and the HV returns >> H_Closed >> which hvc_arch_get_chars() in arch/ppc64/hvconsole returns as 0. So, >> this n == -EPIPE doesn't seem to ever happen. >> >> It may seem strange to ignore a negative return value on >> hvc_arch_get_chars() but I think it may be necessary. > > Yes. If we had some kind of hotplug, it would make sense, I don't think > we really want to do a hangup which is a bit too drastic imho. Hi guys, this part was me HVSI. You'll notice that only HVSI code returns EPIPE I hope...? It's just like a serial cable. When the serial cable is unplugged, we lose carrier detect, and tty_hangup() is how we notify userspace. I mentioned this in my patch the other day; it might need to change a little bit, but I'm pretty sure it needs to stay. -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jschopp at austin.ibm.com Thu Apr 15 02:18:30 2004 From: jschopp at austin.ibm.com (jschopp at austin.ibm.com) Date: Wed, 14 Apr 2004 11:18:30 -0500 (CDT) Subject: [PATCH] cpu DLPAR remove Message-ID: On Power4 and earlier hardware there is no need to clear the CPPR (see RPA p 479 section 18.5.4.7.2 for what little info there is on the CPPR) when stopping a cpu. On hardware following Power4 an undocumented change has been made that requires the CPPR to be cleared if an isolate is to be done on the stopped cpu. So the following patch lets cpu DLPAR work on the recent hardware. Since this is small, straightforward, and tested I plan to push it to ameslab late this afternoon, unless of course there are objections. -Joel # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1555 -> 1.1556 # include/asm-ppc64/xics.h 1.13 -> 1.14 # arch/ppc64/kernel/xics.c 1.52 -> 1.53 # arch/ppc64/kernel/smp.c 1.72 -> 1.73 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/04/14 jschopp at threadlp13.austin.ibm.com 1.1556 # Clear the cppr before stopping the cpu. Some hardware isolate calls clear the cppr for you, other hardware expects the cppr to be cleared and will # fail if it is not cleared. None of it is documented in the hardware docs. # -------------------------------------------- # diff -Nru a/arch/ppc64/kernel/smp.c b/arch/ppc64/kernel/smp.c --- a/arch/ppc64/kernel/smp.c Wed Apr 14 11:05:27 2004 +++ b/arch/ppc64/kernel/smp.c Wed Apr 14 11:05:27 2004 @@ -327,6 +327,7 @@ void cpu_die(void) { local_irq_disable(); + pSeriesLP_cppr_info(0, 0); rtas_stop_self(); /* Should never get here... */ BUG(); diff -Nru a/arch/ppc64/kernel/xics.c b/arch/ppc64/kernel/xics.c --- a/arch/ppc64/kernel/xics.c Wed Apr 14 11:05:27 2004 +++ b/arch/ppc64/kernel/xics.c Wed Apr 14 11:05:27 2004 @@ -190,7 +190,7 @@ val64); } -static void pSeriesLP_cppr_info(int n_cpu, u8 value) +void pSeriesLP_cppr_info(int n_cpu, u8 value) { unsigned long lpar_rc; diff -Nru a/include/asm-ppc64/xics.h b/include/asm-ppc64/xics.h --- a/include/asm-ppc64/xics.h Wed Apr 14 11:05:27 2004 +++ b/include/asm-ppc64/xics.h Wed Apr 14 11:05:27 2004 @@ -19,6 +19,9 @@ void xics_setup_cpu(void); void xics_cause_IPI(int cpu); +/* first argument is ignored */ +void pSeriesLP_cppr_info(int n_cpu, u8 value); + struct xics_ipi_struct { volatile unsigned long value; } ____cacheline_aligned; ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Thu Apr 15 08:11:44 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 14 Apr 2004 17:11:44 -0500 Subject: hvc_console & interrupts: reworked patch In-Reply-To: <1081899709.2134.27.camel@gaston> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> <1081899709.2134.27.camel@gaston> Message-ID: <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> Ben, Thanks for the clarifications. On Tue, 2004-04-13 at 18:41, Benjamin Herrenschmidt wrote: > > You obviously use it TTY throttle predictor anticipator. The danger is > > that when you push the data if you over estimated the amount of data you > > could flip you just end up over writing the tty buffer. > > > > If you underestimated then the TTY will never throttle and you'll never > > get the TTY unthrottle callback, hence no hvc_kick() to continue reading > > data. > > How so ? I don't need kick to continue reading data on a non-throttled > line. Just the interrupt or the 10ms timeout on non-interrupt setups. > Or is there a bug ? Well, I'm not sure if there is a bug or not but in my testing today I've found that console input stops working after a few characters on a Power-5 system. I don't think this behavior is related to what I was getting at in my earlier email but I'll investigate. I should be able to track down what is happening pretty easily. My point earlier is that the hypervisor only sends a single interrupt concerning available data until all the data is removed from the HV. This int causes an hvc_kick() which wakes up the task running hvc_poll(). If the hvc_poll() task is reading data and it predicts that our last HV read and tty flip may have throttled the TTY the hvc_poll() function calls yield() on the task and awaits a hvc_unthrottle call to hvc_kick() and wake the task. If we were wrong and the TTY wasn't throttled we won't receive an unthrottle() callback, nor another data interrupt (since we never pulled all the data), which means that the there won't be any further data read until the system returns control to this thread due to the yield() and its long sleeping nature. Ryan S. Arnold IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Thu Apr 15 09:31:44 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 15 Apr 2004 09:31:44 +1000 Subject: hvc_console & interrupts: reworked patch In-Reply-To: <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> <1081899709.2134.27.camel@gaston> <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> Message-ID: <1081985504.2134.112.camel@gaston> > My point earlier is that the hypervisor only sends a single interrupt > concerning available data until all the data is removed from the HV. > This int causes an hvc_kick() which wakes up the task running > hvc_poll(). > > If the hvc_poll() task is reading data and it predicts that our last HV > read and tty flip may have throttled the TTY the hvc_poll() function > calls yield() on the task and awaits a hvc_unthrottle call to hvc_kick() > and wake the task. Ugh ? We don't predict anyting, we just go out to the "quick" path to yield, but that yield should not block, just leave time to other processes and go straight back to poll. We only block if poll returns a mask of 0. > If we were wrong and the TTY wasn't throttled we won't receive an > unthrottle() callback, nor another data interrupt (since we never pulled > all the data), which means that the there won't be any further data read > until the system returns control to this thread due to the yield() and > its long sleeping nature. yield is long sleeping ? I would have expected to be short, maybe we should change it to a simple schedule() ... Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Thu Apr 15 17:44:35 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 15 Apr 2004 17:44:35 +1000 Subject: hvc_console & interrupts: reworked patch In-Reply-To: <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> <1081899709.2134.27.camel@gaston> <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> Message-ID: <1082015074.5657.150.camel@gaston> > Well, I'm not sure if there is a bug or not but in my testing today I've > found that console input stops working after a few characters on a > Power-5 system. I don't think this behavior is related to what I was > getting at in my earlier email but I'll investigate. I should be able > to track down what is happening pretty easily. Couldn't reproduce a problem on a squadron here, apparently interrupts are beeing used. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Fri Apr 16 03:07:42 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 15 Apr 2004 12:07:42 -0500 Subject: hvc_console & interrupts: reworked patch In-Reply-To: <1082015074.5657.150.camel@gaston> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> <1081899709.2134.27.camel@gaston> <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> <1082015074.5657.150.camel@gaston> Message-ID: <1082048864.16102.462.camel@SigurRos.rchland.ibm.com> Ben, there is a bug in your latest patch: @@ -758,6 +768,14 @@ return count; } + +int hvc_interrupt(int index) +{ + struct vtty_struct *vtty = &vttys[index]; + + /* If not interruptible then it'll return NO_IRQ */ + return vtty->irq; +} That should be +int hvc_interruptible(int index) But I'm sure you caught that. If found out why your patch isn't working on my system. Once the getty is displayed and the username and password are entered, for some reason hp->tty == NULL and the hvc_poll() bails out. I have no idea why hp->tty == NULL at this point. Ryan S. Arnold IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Fri Apr 16 08:24:10 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 16 Apr 2004 08:24:10 +1000 Subject: hvc_console & interrupts: reworked patch In-Reply-To: <1082048864.16102.462.camel@SigurRos.rchland.ibm.com> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> <1081899709.2134.27.camel@gaston> <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> <1082015074.5657.150.camel@gaston> <1082048864.16102.462.camel@SigurRos.rchland.ibm.com> Message-ID: <1082067849.2500.169.camel@gaston> > +int hvc_interrupt(int index) > +{ > + struct vtty_struct *vtty = &vttys[index]; > + > + /* If not interruptible then it'll return NO_IRQ */ > + return vtty->irq; > +} > > That should be > > +int hvc_interruptible(int index) No, I renamed the function to hvc_interrupt() since it returns an interrupt number. Calling it interruptible is misleading since it would mean it returns a boolean value, which isn't the case. Especially, NO_IRQ is _NOT_ 0 but -1, which explains probably why your previous patch incorrectly tried to use an interrupt on POWER4 Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Fri Apr 16 08:25:11 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 16 Apr 2004 08:25:11 +1000 Subject: hvc_console & interrupts: reworked patch In-Reply-To: <1082048864.16102.462.camel@SigurRos.rchland.ibm.com> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> <1081899709.2134.27.camel@gaston> <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> <1082015074.5657.150.camel@gaston> <1082048864.16102.462.camel@SigurRos.rchland.ibm.com> Message-ID: <1082067911.2135.171.camel@gaston> Oh, btw, are you testing the _SECOND_ patch I posted ? The one that I actually tested ? :) Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Fri Apr 16 10:41:49 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 16 Apr 2004 10:41:49 +1000 Subject: hvc_console & interrupts: 3rd patch In-Reply-To: <1082048864.16102.462.camel@SigurRos.rchland.ibm.com> References: <1081844516.25144.237.camel@gaston> <1081895306.16102.303.camel@SigurRos.rchland.ibm.com> <1081899709.2134.27.camel@gaston> <1081980704.16102.345.camel@SigurRos.rchland.ibm.com> <1082015074.5657.150.camel@gaston> <1082048864.16102.462.camel@SigurRos.rchland.ibm.com> Message-ID: <1082076109.2499.191.camel@gaston> Ok, here's a third patch that should fix possible problems with the hangup code path (close is never called after a hangup, so we could miss freeing the interrupt, I also avoid calling tty_hangup with the spinlock held, and do my own locking in hvc_hangup). Ryan: I can reproduce none of your problems, and your comments seem to indicate you may have an incomplete or corrupt patch... Ben. ===== arch/ppc64/kernel/hvconsole.c 1.10 vs edited ===== --- 1.10/arch/ppc64/kernel/hvconsole.c Sat Apr 10 08:11:48 2004 +++ edited/arch/ppc64/kernel/hvconsole.c Wed Apr 14 12:09:47 2004 @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -50,6 +51,7 @@ int (*tiocmset)(struct vtty_struct *vtty, uint16_t set, uint16_t clear); uint16_t seqno; /* HVSI packet sequence number */ uint16_t mctrl; + int irq; }; static struct vtty_struct vttys[MAX_NR_HVC_CONSOLES]; @@ -718,6 +720,7 @@ { struct device_node *vty; int count = 0; + unsigned int *irq_p; for (vty = of_find_node_by_name(NULL, "vty"); vty != NULL; vty = of_find_node_by_name(vty, "vty")) { @@ -732,12 +735,19 @@ break; vtty = &vttys[count]; + vtty->irq = NO_IRQ; if (device_is_compatible(vty, "hvterm1")) { vtty->vtermno = *vtermno; vtty->get_chars = hvc_hvterm_get_chars; vtty->put_chars = hvc_hvterm_put_chars; vtty->tiocmget = NULL; vtty->tiocmset = NULL; + irq_p = (unsigned int *)get_property(vty, "interrupts", 0); + if (irq_p) { + int virq = virt_irq_create_mapping(*irq_p); + if (virq != NO_IRQ) + vtty->irq = irq_offset_up(virq); + } hvc_instantiate(); count++; } else if (device_is_compatible(vty, "hvterm-protocol")) { @@ -758,6 +768,14 @@ return count; } + +int hvc_interrupt(int index) +{ + struct vtty_struct *vtty = &vttys[index]; + + /* If not interruptible then it'll return NO_IRQ */ + return vtty->irq; +} /* Convert arch specific return codes into relevant errnos. The hvcs * functions aren't performance sensitive, so this conversion isn't an ===== drivers/char/hvc_console.c 1.25 vs edited ===== --- 1.25/drivers/char/hvc_console.c Sat Apr 10 08:11:48 2004 +++ edited/drivers/char/hvc_console.c Fri Apr 16 10:24:52 2004 @@ -38,12 +38,15 @@ #define TIMEOUT ((HZ + 99) / 100) static struct tty_driver *hvc_driver; -static int count; +static int hvc_count; +static int hvc_kicked; +static wait_queue_head_t hvc_wait_queue; #ifdef CONFIG_MAGIC_SYSRQ static int sysrq_pressed; #endif #define N_OUTBUF 16 +#define N_INBUF 16 #define __ALIGNED__ __attribute__((__aligned__(8))) @@ -59,15 +62,34 @@ int do_wakeup; char outbuf[N_OUTBUF] __ALIGNED__; int n_outbuf; + int irq_requested; }; struct hvc_struct hvc_struct[MAX_NR_HVC_CONSOLES]; +static void hvc_kick(void) +{ + hvc_kicked = 1; + wake_up_interruptible(&hvc_wait_queue); +} + +static irqreturn_t hvc_handle_interrupt(int irq, void *dev_instance, struct pt_regs *regs) +{ + hvc_kick(); + return IRQ_HANDLED; +} + +static void hvc_unthrottle(struct tty_struct *tty) +{ + hvc_kick(); +} + static int hvc_open(struct tty_struct *tty, struct file * filp) { int line = tty->index; struct hvc_struct *hp; unsigned long flags; + int irq = NO_IRQ; if (line < 0 || line >= MAX_NR_HVC_CONSOLES) return -ENODEV; @@ -77,7 +99,18 @@ spin_lock_irqsave(&hp->lock, flags); hp->tty = tty; hp->count++; + if (hp->count == 1) { + irq = hvc_interrupt(hp->index); + if (irq != NO_IRQ) + hp->irq_requested = 1; + } spin_unlock_irqrestore(&hp->lock, flags); + /* XX check error, fallback to non-irq ? */ + if (irq != NO_IRQ) + request_irq(irq, hvc_handle_interrupt, SA_INTERRUPT, "hvc_console", hp); + + /* Force wakeup of the polling thread */ + hvc_kick(); return 0; } @@ -86,24 +119,41 @@ { struct hvc_struct *hp = tty->driver_data; unsigned long flags; + int irq = NO_IRQ; - if (tty_hung_up_p(filp)) - return; spin_lock_irqsave(&hp->lock, flags); - if (--hp->count == 0) + if (tty_hung_up_p(filp)) + goto bail; + + if (--hp->count == 0) { hp->tty = NULL; - else if (hp->count < 0) + if (hp->irq_requested) + irq = hvc_interrupt(hp->index); + hp->irq_requested = 0; + } else if (hp->count < 0) printk(KERN_ERR "hvc_close %lu: oops, count is %d\n", hp - hvc_struct, hp->count); + bail: spin_unlock_irqrestore(&hp->lock, flags); + if (irq != NO_IRQ) + free_irq(irq, hp); } static void hvc_hangup(struct tty_struct *tty) { struct hvc_struct *hp = tty->driver_data; + unsigned long flags; + int irq = NO_IRQ; + spin_lock_irqsave(&hp->lock, flags); hp->count = 0; hp->tty = NULL; + if (hp->irq_requested) + irq = hvc_interrupt(hp->index); + hp->irq_requested = 0; + spin_unlock_irqrestore(&hp->lock, flags); + if (irq != NO_IRQ) + free_irq(irq, hp); } /* called with hp->lock held */ @@ -126,70 +176,104 @@ hp->do_wakeup = 1; } -static int hvc_write(struct tty_struct *tty, int from_user, - const unsigned char *buf, int count) +static inline int __hvc_write_user(struct hvc_struct *hp, + const unsigned char *buf, int count) { - struct hvc_struct *hp = tty->driver_data; char *tbuf, *p; int tbsize, rsize, written = 0; unsigned long flags; - if (from_user) { - tbsize = min(count, (int)PAGE_SIZE); - if (!(tbuf = kmalloc(tbsize, GFP_KERNEL))) - return -ENOMEM; - - while ((rsize = count - written) > 0) { - int wsize; - if (rsize > tbsize) - rsize = tbsize; - - p = tbuf; - rsize -= copy_from_user(p, buf, rsize); - if (!rsize) { - if (written == 0) - written = -EFAULT; - break; - } - buf += rsize; - written += rsize; - - spin_lock_irqsave(&hp->lock, flags); - for (wsize = N_OUTBUF - hp->n_outbuf; rsize && wsize; - wsize = N_OUTBUF - hp->n_outbuf) { - if (wsize > rsize) - wsize = rsize; - memcpy(hp->outbuf + hp->n_outbuf, p, wsize); - hp->n_outbuf += wsize; - hvc_push(hp); - rsize -= wsize; - p += wsize; - } - spin_unlock_irqrestore(&hp->lock, flags); - - if (rsize) - break; + tbsize = min(count, (int)PAGE_SIZE); + if (!(tbuf = kmalloc(tbsize, GFP_KERNEL))) + return -ENOMEM; - if (count < tbsize) - tbsize = count; + while ((rsize = count - written) > 0) { + int wsize; + if (rsize > tbsize) + rsize = tbsize; + + p = tbuf; + rsize -= copy_from_user(p, buf, rsize); + if (!rsize) { + if (written == 0) + written = -EFAULT; + break; } + buf += rsize; - kfree(tbuf); - } else { spin_lock_irqsave(&hp->lock, flags); - while (count > 0 && (rsize = N_OUTBUF - hp->n_outbuf) > 0) { - if (rsize > count) - rsize = count; - memcpy(hp->outbuf + hp->n_outbuf, buf, rsize); - count -= rsize; - buf += rsize; - hp->n_outbuf += rsize; - written += rsize; + + /* Push pending writes: make some room in buffer */ + if (hp->n_outbuf > 0) + hvc_push(hp); + + for (wsize = N_OUTBUF - hp->n_outbuf; rsize && wsize; + wsize = N_OUTBUF - hp->n_outbuf) { + if (wsize > rsize) + wsize = rsize; + memcpy(hp->outbuf + hp->n_outbuf, p, wsize); + hp->n_outbuf += wsize; hvc_push(hp); + rsize -= wsize; + p += wsize; + written += wsize; } spin_unlock_irqrestore(&hp->lock, flags); + + if (rsize) + break; + + if (count < tbsize) + tbsize = count; } + kfree(tbuf); + + return written; +} + +static inline int __hvc_write_kernel(struct hvc_struct *hp, + const unsigned char *buf, int count) +{ + unsigned long flags; + int rsize, written = 0; + + spin_lock_irqsave(&hp->lock, flags); + + /* Push pending writes */ + if (hp->n_outbuf > 0) + hvc_push(hp); + + while (count > 0 && (rsize = N_OUTBUF - hp->n_outbuf) > 0) { + if (rsize > count) + rsize = count; + memcpy(hp->outbuf + hp->n_outbuf, buf, rsize); + count -= rsize; + buf += rsize; + hp->n_outbuf += rsize; + written += rsize; + hvc_push(hp); + } + spin_unlock_irqrestore(&hp->lock, flags); + + return written; +} + +static int hvc_write(struct tty_struct *tty, int from_user, + const unsigned char *buf, int count) +{ + struct hvc_struct *hp = tty->driver_data; + int written; + + if (from_user) + written = __hvc_write_user(hp, buf, count); + else + written = __hvc_write_kernel(hp, buf, count); + + /* Racy, but harmless, kick thread if there are still pending data */ + if (hp->n_outbuf) + hvc_kick(); + return written; } @@ -207,59 +291,106 @@ return hp->n_outbuf; } -static void hvc_poll(int index) +#define HVC_POLL_READ 0x00000001 +#define HVC_POLL_WRITE 0x00000002 +#define HVC_POLL_QUICK 0x00000004 + +static int hvc_poll(int index) { struct hvc_struct *hp = &hvc_struct[index]; struct tty_struct *tty; - int i, n; - char buf[16] __ALIGNED__; + int i, n, poll_mask = 0; + char buf[N_INBUF] __ALIGNED__; unsigned long flags; + int read_total = 0; spin_lock_irqsave(&hp->lock, flags); + /* Push pending writes */ if (hp->n_outbuf > 0) hvc_push(hp); + /* Reschedule us if still some write pending */ + if (hp->n_outbuf > 0) + poll_mask |= HVC_POLL_WRITE; + /* No tty attached, just skip */ tty = hp->tty; - if (tty) { - for (;;) { - if (TTY_FLIPBUF_SIZE - tty->flip.count < sizeof(buf)) - break; - n = hvc_arch_get_chars(index, buf, sizeof(buf)); - if (n <= 0) { - if (n == -EPIPE) { - printk("tty_hangup\n"); - tty_hangup(tty); - } - break; + if (tty == NULL) + goto bail; + + /* Now check if we can get data (are we throttled ?) */ + if (test_bit(TTY_THROTTLED, &tty->flags)) + goto throttled; + + /* If we aren't interrupt driven and aren't throttled, we always + * request a reschedule + */ + if (hvc_interrupt(index) == NO_IRQ) + poll_mask |= HVC_POLL_READ; + + /* Read data if any */ + for (;;) { + int count = N_INBUF; + if (count > (TTY_FLIPBUF_SIZE - tty->flip.count)) + count = TTY_FLIPBUF_SIZE - tty->flip.count; + + /* If flip is full, just reschedule a later read */ + if (count == 0) { + poll_mask |= HVC_POLL_READ; + break; + } + + n = hvc_arch_get_chars(index, buf, count); + if (n <= 0) { + /* Hangup the tty when disconnected from host */ + if (n == -EPIPE) { + spin_unlock_irqrestore(&hp->lock, flags); + tty_hangup(tty); + spin_lock_irqsave(&hp->lock, flags); } - for (i = 0; i < n; ++i) { -#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */ - if (buf[i] == '\x0f') { /* ^O -- should support a sequence */ - sysrq_pressed = 1; - continue; - } else if (sysrq_pressed) { - handle_sysrq(buf[i], NULL, tty); - sysrq_pressed = 0; - continue; - } -#endif - tty_insert_flip_char(tty, buf[i], 0); + break; + } + for (i = 0; i < n; ++i) { +#ifdef CONFIG_MAGIC_SYSRQ + /* Handle the SysRq Hack */ + if (buf[i] == '\x0f') { /* ^O -- should support a sequence */ + sysrq_pressed = 1; + continue; + } else if (sysrq_pressed) { + handle_sysrq(buf[i], NULL, tty); + sysrq_pressed = 0; + continue; } +#endif /* CONFIG_MAGIC_SYSRQ */ + tty_insert_flip_char(tty, buf[i], 0); } + if (tty->flip.count) tty_schedule_flip(tty); - if (hp->do_wakeup) { - hp->do_wakeup = 0; - if ((tty->flags & (1 << TTY_DO_WRITE_WAKEUP)) - && tty->ldisc.write_wakeup) - (tty->ldisc.write_wakeup)(tty); - wake_up_interruptible(&tty->write_wait); + /* Account the total amount read in one loop, and if above 64 bytes, + * we do a quick schedule loop to let the tty grok the data and + * eventually throttle us + */ + read_total += n; + if (read_total >= 64) { + poll_mask |= HVC_POLL_QUICK; + break; } } - + throttled: + /* Wakeup write queue if necessary */ + if (hp->do_wakeup) { + hp->do_wakeup = 0; + if ((tty->flags & (1 << TTY_DO_WRITE_WAKEUP)) + && tty->ldisc.write_wakeup) + (tty->ldisc.write_wakeup)(tty); + wake_up_interruptible(&tty->write_wait); + } + bail: spin_unlock_irqrestore(&hp->lock, flags); + + return poll_mask; } #if defined(CONFIG_XMON) && defined(CONFIG_SMP) @@ -271,17 +402,37 @@ int khvcd(void *unused) { - int i; + int i, poll_mask; daemonize("khvcd"); for (;;) { + wait_queue_t wait = __WAITQUEUE_INITIALIZER(wait,current); + + poll_mask = 0; + hvc_kicked = 0; + wmb(); if (cpus_empty(cpus_in_xmon)) { for (i = 0; i < MAX_NR_HVC_CONSOLES; ++i) - hvc_poll(i); + poll_mask |= hvc_poll(i); + } else + poll_mask |= HVC_POLL_READ; + if (hvc_kicked) + continue; + if (poll_mask & HVC_POLL_QUICK) { + yield(); + continue; } + add_wait_queue(&hvc_wait_queue, &wait); set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(TIMEOUT); + if (!hvc_kicked) { + if (poll_mask == 0) + schedule(); + else + schedule_timeout(TIMEOUT); + } + set_current_state(TASK_RUNNING); + remove_wait_queue(&hvc_wait_queue, &wait); } } @@ -314,6 +465,7 @@ .close = hvc_close, .write = hvc_write, .hangup = hvc_hangup, + .unthrottle = hvc_unthrottle, .write_room = hvc_write_room, .chars_in_buffer = hvc_chars_in_buffer, .tiocmget = hvc_tiocmget, @@ -322,7 +474,9 @@ int __init hvc_init(void) { - hvc_driver = alloc_tty_driver(count); + init_waitqueue_head(&hvc_wait_queue); + + hvc_driver = alloc_tty_driver(hvc_count); if (!hvc_driver) return -ENOMEM; @@ -340,7 +494,7 @@ if (tty_register_driver(hvc_driver)) panic("Couldn't register hvc console driver\n"); - if (count > 0) + if (hvc_count > 0) kernel_thread(khvcd, NULL, CLONE_KERNEL); else printk(KERN_WARNING "no virtual consoles found\n"); @@ -391,7 +545,7 @@ static int __init hvc_console_setup(struct console *co, char *options) { if (co->index < 0 || co->index >= MAX_NR_HVC_CONSOLES - || co->index >= count) + || co->index >= hvc_count) return -1; return 0; } @@ -410,14 +564,14 @@ { struct hvc_struct *hvc; - if (count >= MAX_NR_HVC_CONSOLES) + if (hvc_count >= MAX_NR_HVC_CONSOLES) return -1; - hvc = &hvc_struct[count]; + hvc = &hvc_struct[hvc_count]; hvc->lock = SPIN_LOCK_UNLOCKED; - hvc->index = count; + hvc->index = hvc_count; - count++; + hvc_count++; return 0; } ===== include/asm-ppc64/hvconsole.h 1.7 vs edited ===== --- 1.7/include/asm-ppc64/hvconsole.h Sat Apr 10 08:11:48 2004 +++ edited/include/asm-ppc64/hvconsole.h Wed Apr 14 12:09:41 2004 @@ -57,6 +57,7 @@ extern int hvcs_get_partner_info(unsigned int unit_address, struct list_head *head); extern int hvcs_register_connection(unsigned int unit_address, unsigned int p_partition_ID, unsigned int p_unit_address); extern int hvcs_free_connection(unsigned int unit_address); +extern int hvc_interrupt(int index); #endif /* _PPC64_HVCONSOLE_H */ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Sat Apr 17 06:43:20 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Fri, 16 Apr 2004 15:43:20 -0500 Subject: [PATCH] fix crash in kdba bt command Message-ID: <20040416154320.M58706@forte.austin.ibm.com> Anton, Please apply attached patch to ameslab. Note, this is just the first, there will probably be some more patches coming in the next few days. This patch fixes a minor bug in th backtrace command; bt was failing to actually trace the stack at addr. --linas -------------- next part -------------- --- kdba_bt.c.orig 2004-04-16 14:45:44.000000000 -0500 +++ kdba_bt.c 2004-04-16 15:29:42.000000000 -0500 @@ -126,7 +126,7 @@ kdba_bt_stack_ppc(struct pt_regs *regs, if (!addr) addr = (kdb_machreg_t *)p->thread.ksp; - if (addr && !task_curr(p)) { + if (addr && (!p || !task_curr(p))) { eip = 0; esp = *addr; ebp = 0; @@ -183,7 +183,8 @@ kdba_bt_stack_ppc(struct pt_regs *regs, /* kdbnearsym(eip, &symtab); */ kdba_find_tb_table(eip, &tbtab); - /* sym = symtab.sym_name ? &symtab : &tbtab.symtab; *//* use fake symtab if necessary */ + /* sym = symtab.sym_name ? &symtab : &tbtab.symtab; */ + /* use fake symtab if necessary */ name = NULL; if (esp >= PAGE_OFFSET) { /*if ((sym) )*/ @@ -288,8 +289,8 @@ kdba_bt_stack(struct pt_regs *regs, kdb_ /* * kdba_bt_address * - * Do a backtrace starting at a specified stack address. Use this if the - * heuristics get the i386 stack decode wrong. + * Do a backtrace starting at a specified stack address. Handy + * if the stack is somwhere unexpected/unusual. * * Inputs: * addr Address provided to 'bt' command. @@ -300,9 +301,6 @@ kdba_bt_stack(struct pt_regs *regs, kdb_ * zero for success, a kdb diagnostic if error * Locking: * none. - * Remarks: - * mds %esp comes in handy when examining the stack to do a manual - * traceback. */ int From santil at us.ibm.com Sat Apr 17 07:49:13 2004 From: santil at us.ibm.com (Santiago Leon) Date: Fri, 16 Apr 2004 16:49:13 -0500 Subject: ibmveth gcc 3.5 issues In-Reply-To: <20040413105218.GP22471@krispykreme> References: <20040413105218.GP22471@krispykreme> Message-ID: <408054D9.5080809@us.ibm.com> Anton, Testing your patch I found that there was a mistake in the old code... I'm attaching a patch with your changes plus a small correction (the check for 0x2 should be only for the lower 2 bits of the MSB)... I have tested this patch, so merge it in if you want... Santi Anton Blanchard wrote: > Hi, > > gcc 3.5 doesnt like the mac_addr_p gymnastics and it has the potential > to explode if phyp feeds us a bogus mac address. The change was based on > the comment above it, can someone verify the new version will work as > expected? > > Anton -- Santiago A. Leon Power Linux Development IBM Linux Technology Center -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ibmveth_gcc35.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040416/55da0e3a/attachment.txt From brking at us.ibm.com Sat Apr 17 07:59:24 2004 From: brking at us.ibm.com (Brian King) Date: Fri, 16 Apr 2004 16:59:24 -0500 Subject: [PATCH] 2.4 ipr driver should use request_bufflen Message-ID: <4080573C.2070609@us.ibm.com> I recently came across a bug in the ipr driver that is in the ames 2.4 tree. Please apply. -Brian This patch fixes the 2.4 ipr driver to properly use request_bufflen instead of bufflen in the scsi_cmd struct when mapping DMA buffers. Usually these are the same value, but they are different for ERP ops issued by the eh thread. --- diff -puN drivers/scsi/ipr/iprdd.c~ipr-request-buffer drivers/scsi/ipr/iprdd.c --- bk-linux-2.4-ppc64/drivers/scsi/ipr/iprdd.c~ipr-request-buffer Fri Apr 16 10:42:22 2004 +++ bk-linux-2.4-ppc64-bjking1/drivers/scsi/ipr/iprdd.c Fri Apr 16 10:42:22 2004 @@ -1128,7 +1128,7 @@ static IPR_INL struct ipr_cmnd* ipr_buil p_sis_cmnd->p_scsi_cmd = p_scsi_cmd; p_sis_cmnd->ccb.buffer = p_scsi_cmd->buffer; p_sis_cmnd->ccb.request_buffer = p_scsi_cmd->request_buffer; - p_sis_cmnd->ccb.bufflen = p_scsi_cmd->bufflen; + p_sis_cmnd->ccb.bufflen = p_scsi_cmd->request_bufflen; p_sis_cmnd->ccb.cmd_len = p_scsi_cmd->cmd_len; p_sis_cmnd->ccb.p_resource = p_resource; p_sis_cmnd->ccb.underflow = p_scsi_cmd->underflow; diff -puN drivers/scsi/ipr/version.mk~ipr-request-buffer drivers/scsi/ipr/version.mk --- bk-linux-2.4-ppc64/drivers/scsi/ipr/version.mk~ipr-request-buffer Fri Apr 16 10:42:22 2004 +++ bk-linux-2.4-ppc64-bjking1/drivers/scsi/ipr/version.mk Fri Apr 16 10:42:22 2004 @@ -2,8 +2,8 @@ IPR_MAJOR_RELEASE=1 IPR_MINOR_RELEASE=0 -IPR_FIX_LEVEL=3 -IPR_FIX_DATE=(November 10, 2003) +IPR_FIX_LEVEL=4 +IPR_FIX_DATE=(April 15, 2004) IPR_VERSION_STR=Ver. $(IPR_MAJOR_RELEASE) Rev. $(IPR_MINOR_RELEASE).$(IPR_FIX_LEVEL) _ -- Brian King eServer Storage I/O IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Sat Apr 17 08:22:06 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Fri, 16 Apr 2004 17:22:06 -0500 Subject: [PATCH] stop debugger recursion when multiple resets caught. Message-ID: <20040416172206.N58706@forte.austin.ibm.com> Hi Anton, Please apply the following patch to Ameslab. It fixes one of the most serious KDB problems at this time: incorrect handling of recursive calls into the debugger from unexpected exceptions. For example, hitting the little yellow button repeatedly is currently causing all sorts of havoc in KDB, as are some other, more bizarre circumstances. This patch should fix these. --linas -------------- next part -------------- --- arch/ppc64/kdb/kdbasupport.c.orig 2004-04-16 16:15:17.000000000 -0500 +++ arch/ppc64/kdb/kdbasupport.c 2004-04-16 17:11:56.000000000 -0500 @@ -1789,7 +1789,7 @@ kdb_debugger(struct pt_regs *regs) { } else { /* regs invalid */ kdb(KDB_REASON_SILENT,0,regs); } - return 0; + return 1; } int --- arch/ppc64/kernel/traps.c.orig 2004-04-16 16:20:16.000000000 -0500 +++ arch/ppc64/kernel/traps.c 2004-04-16 16:26:09.000000000 -0500 @@ -171,13 +171,26 @@ SystemResetException(struct pt_regs *reg #endif if (!debugger(regs)) + { die("System Reset", regs, 0); + /* We should issue a shutdown or hard reset here. */ + } + /* Must die if the interrupt is not recoverable */ - if (!(regs->msr & MSR_RI)) + if (!(regs->msr & MSR_RI)) { panic("Unrecoverable System Reset"); - /* What should we do here? We could issue a shutdown or hard reset. */ + /* We should issue a shutdown or hard reset here. */ + } + + /* What should we do here? We might be tempted to issue a shutdown + * or hard reset, but that would be wrong. The reason we go here + * is because er hit the little yellow button a bunch of times, + * while already being in the debugger. The debugger just wants + * these events to go away, be ignored, and that is exactly what + * we should do. The user has other mechanisms for hard reboot, + * if that's what they really wanted to do. */ } #ifdef CONFIG_PPC_PSERIES From olh at suse.de Sun Apr 18 00:55:38 2004 From: olh at suse.de (Olaf Hering) Date: Sat, 17 Apr 2004 16:55:38 +0200 Subject: [PATCH] stop debugger recursion when multiple resets caught. In-Reply-To: <20040416172206.N58706@forte.austin.ibm.com> References: <20040416172206.N58706@forte.austin.ibm.com> Message-ID: <20040417145538.GB7103@suse.de> On Fri, Apr 16, linas at austin.ibm.com wrote: > > Hi Anton, > > Please apply the following patch to Ameslab. It fixes one of the > most serious KDB problems at this time: incorrect handling of > recursive calls into the debugger from unexpected exceptions. > > For example, hitting the little yellow button repeatedly is currently > causing all sorts of havoc in KDB, as are some other, more bizarre > circumstances. This patch should fix these. > > --linas > > --- arch/ppc64/kdb/kdbasupport.c.orig 2004-04-16 16:15:17.000000000 -0500 > +++ arch/ppc64/kdb/kdbasupport.c 2004-04-16 17:11:56.000000000 -0500 > @@ -1789,7 +1789,7 @@ kdb_debugger(struct pt_regs *regs) { > } else { /* regs invalid */ > kdb(KDB_REASON_SILENT,0,regs); > } > - return 0; > + return 1; > } Thanks Linas, I have added this part. -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Mon Apr 19 02:20:27 2004 From: anton at samba.org (Anton Blanchard) Date: Mon, 19 Apr 2004 02:20:27 +1000 Subject: [PATCH] fix crash in kdba bt command In-Reply-To: <20040416154320.M58706@forte.austin.ibm.com> References: <20040416154320.M58706@forte.austin.ibm.com> Message-ID: <20040418162027.GD26086@krispykreme> > Please apply attached patch to ameslab. Note, this is just the first, > there will probably be some more patches coming in the next few days. > > This patch fixes a minor bug in th backtrace command; bt > was failing to actually trace the stack at addr. Thanks Linas, applied. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Mon Apr 19 02:20:42 2004 From: anton at samba.org (Anton Blanchard) Date: Mon, 19 Apr 2004 02:20:42 +1000 Subject: [PATCH] stop debugger recursion when multiple resets caught. In-Reply-To: <20040416172206.N58706@forte.austin.ibm.com> References: <20040416172206.N58706@forte.austin.ibm.com> Message-ID: <20040418162042.GE26086@krispykreme> > Please apply the following patch to Ameslab. It fixes one of the > most serious KDB problems at this time: incorrect handling of > recursive calls into the debugger from unexpected exceptions. > > For example, hitting the little yellow button repeatedly is currently > causing all sorts of havoc in KDB, as are some other, more bizarre > circumstances. This patch should fix these. Applied. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Tue Apr 20 06:25:24 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 19 Apr 2004 15:25:24 -0500 Subject: [PATCH] hvcs.diff fixes build warnings Message-ID: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> greetings, Here is an hvcs patch against the latest Ameslab tree that fixes some build warnings in hvcs that were noticed by Olaf Hering. http://www-124.ibm.com/linux/patches/misc/hvcs-20040419.diff I'd like to check this into Ameslab soon so if I don't here a response in two days I will check it in. It has been thoroughly tested. These are minor changes. This patch also adds a change to arch/ppc64/kernel/hvconsole.c to support the conversion of H_LongBusyOrder* return codes into errno -EBUSY for hvcs to respond properly to a pending vterm device release hcall as required by the firmware specification. Ryan S. Arnold IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Tue Apr 20 06:30:50 2004 From: olh at suse.de (Olaf Hering) Date: Mon, 19 Apr 2004 22:30:50 +0200 Subject: [PATCH] hvcs.diff fixes build warnings In-Reply-To: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> References: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> Message-ID: <20040419203050.GA22141@suse.de> On Mon, Apr 19, Ryan Arnold wrote: > greetings, > > Here is an hvcs patch against the latest Ameslab tree that fixes some > build warnings in hvcs that were noticed by Olaf Hering. Thans Ryan, here is my (short) version to shut up gcc. --- linux-2.6.5/drivers/char/hvcs.c 2004-04-18 21:38:57.630055533 +0200 +++ linux-2.6.5/drivers/char/hvcs.c 2004-04-18 21:38:20.262107256 +0200 @@ -110,7 +110,7 @@ static struct termios hvcs_tty_termios = static int hvcs_parm_num_devs = -1; module_param(hvcs_parm_num_devs, int, 0); -static const char hvcs_driver_name[] = "hvcs"; +static char hvcs_driver_name[] = "hvcs"; static const char hvcs_device_node[] = "hvcs"; static const char hvcs_driver_string[] = "IBM hvcs (Hypervisor Virtual Console Server) Driver"; @@ -154,7 +154,7 @@ struct hvcs_struct { static struct list_head hvcs_structs = LIST_HEAD_INIT(hvcs_structs); -static void hvcs_read_task(unsigned long data); +static void hvcs_read_task(void *data); static void hvcs_unthrottle(struct tty_struct *tty); static void hvcs_throttle(struct tty_struct *tty); static irqreturn_t hvcs_handle_interrupt(int irq, void *dev_instance, struct pt_regs *regs); @@ -185,7 +185,7 @@ static void hvcs_create_driver_attrs(voi static void hvcs_remove_driver_attrs(void); static int __devinit hvcs_probe(struct vio_dev *dev, const struct vio_device_id *id); -static void __devexit hvcs_remove(struct vio_dev *dev); +static int __devexit hvcs_remove(struct vio_dev *dev); static int __init hvcs_module_init(void); static void __exit hvcs_module_exit(void); @@ -195,7 +195,7 @@ static void __exit hvcs_module_exit(void * throttle and we want to be able to reschedule ourselves to run AFTER a * push is scheduled so that we know when the tty is properly throttled. */ -static void hvcs_read_task(unsigned long data) +static void hvcs_read_task(void *data) { struct hvcs_struct *hvcsd = (struct hvcs_struct *)data; unsigned int unit_address = hvcsd->vdev->unit_address; @@ -295,7 +295,7 @@ static int __devinit hvcs_probe( if (!dev || !id) { printk(KERN_ERR "HVCS: driver probed with invalid parm.\n"); - return; + return -EPERM; } printk(KERN_INFO "HVCS: Added vty-server@%X.\n", dev->unit_address); @@ -319,7 +319,7 @@ static int __devinit hvcs_probe( hvcsd->index = ++hvcs_struct_count; - INIT_WORK(&hvcsd->read_work, hvcs_read_task, (unsigned long)hvcsd); + INIT_WORK(&hvcsd->read_work, hvcs_read_task, hvcsd); hvcsd->enabled = 0; @@ -345,12 +345,12 @@ static int __devinit hvcs_probe( return 0; } -static void __devexit hvcs_remove(struct vio_dev *dev) +static int __devexit hvcs_remove(struct vio_dev *dev) { struct hvcs_struct *hvcsd = (struct hvcs_struct *)dev->driver_data; if (!hvcsd) - return; + return -ENODEV; printk(KERN_INFO "HVCS: Removing vty-server@%X.\n", dev->unit_address); @@ -379,10 +379,11 @@ static void __devexit hvcs_remove(struct * which would probably be tty_hangup. */ kobject_put (&hvcsd->kobj); + return 0; }; static struct vio_driver hvcs_vio_driver = { - .name = &hvcs_driver_name, + .name = hvcs_driver_name, .id_table = hvcs_driver_table, .probe = hvcs_probe, .remove = __devexit_p(hvcs_remove), -- USB is for mice, FireWire is for men! sUse lINUX ag, n??RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jschopp at austin.ibm.com Tue Apr 20 06:52:51 2004 From: jschopp at austin.ibm.com (jschopp at austin.ibm.com) Date: Mon, 19 Apr 2004 15:52:51 -0500 (CDT) Subject: [PATCH] hvcs.diff fixes build warnings In-Reply-To: <20040419203050.GA22141@suse.de> Message-ID: > > This patch also adds a change to arch/ppc64/kernel/hvconsole.c to > > support the conversion of H_LongBusyOrder* return codes into errno > > -EBUSY for hvcs to respond properly to a pending vterm device release > > hcall as required by the firmware specification. > > here is my (short) version to shut up gcc. I can't comment on the first patch because I'm not really qualified, but I do like Olof's patch. I'm tired of seeing those messages and those changes look fine to me. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sleddog at us.ibm.com Tue Apr 20 06:54:31 2004 From: sleddog at us.ibm.com (Dave Boutcher) Date: Mon, 19 Apr 2004 15:54:31 -0500 Subject: [PATCH] hvcs.diff fixes build warnings In-Reply-To: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> References: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> Message-ID: On 19 Apr 2004 15:25:24 -0500, Ryan Arnold wrote: > Here is an hvcs patch against the latest Ameslab tree that fixes some > build warnings in hvcs that were noticed by Olaf Hering. > > http://www-124.ibm.com/linux/patches/misc/hvcs-20040419.diff > > I'd like to check this into Ameslab soon so if I don't here a response > in two days I will check it in. It has been thoroughly tested. These > are minor changes. > > This patch also adds a change to arch/ppc64/kernel/hvconsole.c to > support the conversion of H_LongBusyOrder* return codes into errno > -EBUSY for hvcs to respond properly to a pending vterm device release > hcall as required by the firmware specification. Ryan, I think this fixes way more than what you have described in the statements above. Can you (a) break out the long busy fix (b) break out the compiler changes from the functional changes...or redescribe the patch? Thanks, Dave B ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Tue Apr 20 07:21:06 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 19 Apr 2004 16:21:06 -0500 Subject: [PATCH] hvcs.diff fixes build warnings In-Reply-To: References: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> Message-ID: <1082409666.27507.486.camel@SigurRos.rchland.ibm.com> On Mon, 2004-04-19 at 15:54, Dave Boutcher wrote: > Ryan, I think this fixes way more than what you have described in the > statements above. Can you > (a) break out the long busy fix > (b) break out the compiler changes from the functional changes...or > redescribe the patch? Yes, I can break out the compiler changes from the functional changes. Really there are four small sets of changes. I thought it'd be silly to make them all their own patches, but here they are: 1.) Changes to fix the compiler warnings 2.) Changes to the formatting of the driver (including removing brackets, adding & removing comments, moving or removing printks). 3.) Addition of the H_LongBusyOrder* changes to the arch code. 4.) Changes to hvc_read_task() to remove unneeded interrupt controls and redundant code. Scheduling the read_task delayed out of the int handler rather than immediate. Ryan S. Arnold IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Tue Apr 20 07:24:14 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 19 Apr 2004 16:24:14 -0500 Subject: [PATCH] hvcs.diff fixes build warnings In-Reply-To: <20040419203050.GA22141@suse.de> References: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> <20040419203050.GA22141@suse.de> Message-ID: <1082409856.27507.490.camel@SigurRos.rchland.ibm.com> On Mon, 2004-04-19 at 15:30, Olaf Hering wrote: > > On Mon, Apr 19, Ryan Arnold wrote: > > > greetings, > > > > Here is an hvcs patch against the latest Ameslab tree that fixes some > > build warnings in hvcs that were noticed by Olaf Hering. Olaf, that looks good except that I don't think the __devexit_p portion of the following line is necessary, so I took it out in my patch. .remove = __devexit_p(hvcs_remove), Ryan S. Arnold IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at samba.org Tue Apr 20 14:20:20 2004 From: paulus at samba.org (Paul Mackerras) Date: Tue, 20 Apr 2004 14:20:20 +1000 Subject: xmon rewrite Message-ID: <16516.42244.591442.860815@cargo.ozlabs.ibm.com> I have rewritten the breakpoint handling and entry/exit code in xmon to make it much more usable on SMP systems. On entry, xmon will now send an IPI to all other processors to get them into xmon as well, and on exit they are all released. Breakpoint handling and single-stepping has also been improved. Xmon can now continue from a breakpoint, or do a single step at a location where a breakpoint is installed, without having to disable that breakpoint temporarily. (Instead it either emulates the instruction, or copies it to another place and executes it there.) Data address breakpoints are implemented but I don't yet have a good way for xmon to proceed from a data address breakpoint. If you do try to step, or to exit xmon, that cpu will just hit the breakpoint again straight away. You'll have to remove the data address breakpoint to continue. The obvious thing is to emulate the instruction but that will involve adding code to emulate all load and store instructions. The stack traces are also improved. Xmon should now detect exception frames in the stack trace fairly reliably, and it has some heuristics to work out whether the LR value and/or the first stack frame contain a valid return address that should be printed. Comments welcome. It would be good if people could try this out and let me know how it goes. If there are no problems I'll commit it to ameslab. (Anton has tested a slightly different version of this patch, but I haven't been able to test this one yet.) The patch is at http://ozlabs.org/~paulus/newxmon-nox.patch.gz. Sorry for the inconvenience, but the mailing list won't let me include the patch inline. Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Tue Apr 20 15:15:45 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 20 Apr 2004 15:15:45 +1000 Subject: [PATCH] hvcs.diff fixes build warnings In-Reply-To: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> References: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> Message-ID: <1082438145.1689.90.camel@gaston> On Tue, 2004-04-20 at 06:25, Ryan Arnold wrote: > greetings, > > Here is an hvcs patch against the latest Ameslab tree that fixes some > build warnings in hvcs that were noticed by Olaf Hering. > > http://www-124.ibm.com/linux/patches/misc/hvcs-20040419.diff > > I'd like to check this into Ameslab soon so if I don't here a response > in two days I will check it in. It has been thoroughly tested. These > are minor changes. > > This patch also adds a change to arch/ppc64/kernel/hvconsole.c to > support the conversion of H_LongBusyOrder* return codes into errno > -EBUSY for hvcs to respond properly to a pending vterm device release > hcall as required by the firmware specification. Did you ever take my hvc_console rework btw ? I got it working well here on both the power4 and the squadron, but was waiting for your tests before uploading Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Tue Apr 20 15:18:55 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 20 Apr 2004 15:18:55 +1000 Subject: [PATCH] hvcs.diff fixes build warnings In-Reply-To: <1082438145.1689.90.camel@gaston> References: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> <1082438145.1689.90.camel@gaston> Message-ID: <1082438334.23066.92.camel@gaston> > Did you ever take my hvc_console rework btw ? I got it working well > here on both the power4 and the squadron, but was waiting for your > tests before uploading To be more precise, I don't like at all the use of work queues, why not a kernel thread ? Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Wed Apr 21 23:05:50 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 21 Apr 2004 08:05:50 -0500 Subject: hvcs.diff fixes build warnings more about hvc_console though In-Reply-To: <1082438334.23066.92.camel@gaston> References: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> <1082438145.1689.90.camel@gaston> <1082438334.23066.92.camel@gaston> Message-ID: <1082552803.16102.1914.camel@SigurRos.rchland.ibm.com> On Tue, 2004-04-20 at 00:18, Benjamin Herrenschmidt wrote: > > > Did you ever take my hvc_console rework btw ? I got it working well > > here on both the power4 and the squadron, but was waiting for your > > tests before uploading > Ben, like I said last night in IRC and will say now for the public record, you were correct in surmising that I had a broken hvc_console patch earlier. It seems that your 3rd patch works just fine on my Power-5 hardware. Now, about me taking your patch, I'm not sure I'm the one to take it. I'd say if antonb doesn't have a problem with it or anyone else it should go into the Ameslab tree. > > > To be more precise, I don't like at all the use of work queues, > > why not a kernel thread ? > For the public record, do you still think it is fine to continue to use them while they work and then re-evaluate the usage when the hvcs driver is submitted to the LKML for addition? Ryan S. Arnold IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxiep at us.ibm.com Thu Apr 22 03:00:40 2004 From: lxiep at us.ibm.com (Linda Xie) Date: Wed, 21 Apr 2004 12:00:40 -0500 Subject: [PATH] symlink doesn't support kobj name > 20 charaters (KOBJ_NAME_LEN) Message-ID: <4086A8B8.2010004@us.ibm.com> Hi Greg, Since symlink.c uses "name" field of a kobj when it calculates the length, it gets a wrong value if the kobj's name has more than 20 charathers. A correct way to do that is to call kobject_name(kobj) instead of using kobj->name directly. Can you apply attached patch to you tree? Thanks, Linda -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: symlink.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040421/44d23e0a/attachment.txt From lxiep at us.ibm.com Thu Apr 22 06:38:39 2004 From: lxiep at us.ibm.com (Linda Xie) Date: Wed, 21 Apr 2004 15:38:39 -0500 Subject: [PATCH] -- set eeh option (enabled ) prior to any i/o to newly added IOA Message-ID: <4086DBCF.3020008@us.ibm.com> Hi Greg, Attached patch fix the problem I have found during DLPAR I/O slots testing on our new hardware. rpaphp needs to set eeh-option(eanbled) for newly added IOA prior to performing PCI config(pci_setup_device), otherwise the pci_dev of the IOA will have invalid base address information. Linas Vepstas impleted eeh changes. Please apply the patch to your tree. Thanks, Linda -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: eeh_rpaphp.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040421/824939d2/attachment.txt From benh at kernel.crashing.org Thu Apr 22 09:01:31 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 22 Apr 2004 09:01:31 +1000 Subject: hvcs.diff fixes build warnings more about hvc_console though In-Reply-To: <1082552803.16102.1914.camel@SigurRos.rchland.ibm.com> References: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> <1082438145.1689.90.camel@gaston> <1082438334.23066.92.camel@gaston> <1082552803.16102.1914.camel@SigurRos.rchland.ibm.com> Message-ID: <1082588491.2056.84.camel@gaston> On Wed, 2004-04-21 at 23:05, Ryan Arnold wrote: > On Tue, 2004-04-20 at 00:18, Benjamin Herrenschmidt wrote: > Ben, like I said last night in IRC and will say now for the public > record, you were correct in surmising that I had a broken hvc_console > patch earlier. It seems that your 3rd patch works just fine on my > Power-5 hardware. Now, about me taking your patch, I'm not sure I'm the > one to take it. I'd say if antonb doesn't have a problem with it or > anyone else it should go into the Ameslab tree. There's no problem with submitting upstream, I can do that and push to ameslab, I just wanted to make sure you tested it on relevant hardware. > For the public record, do you still think it is fine to continue to use > them while they work and then re-evaluate the usage when the hvcs driver > is submitted to the LKML for addition? Maybe a good approach. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sfr at canb.auug.org.au Thu Apr 22 17:36:32 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 22 Apr 2004 17:36:32 +1000 Subject: [PATCH] PPC64 iSeries add soem proc entries Message-ID: <20040422173632.2ac6a7e4.sfr@canb.auug.org.au> Hi Andrew, This patch just adds some proc entries for the virtual tape and cdrom drivers to allow mapping between linux devices and OS/400 ones. This is expected by existing users and there is no other way to do this translation. Please apply to your tree and send upstream. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- diff -ruN 2.6.6-rc2.viocd/drivers/cdrom/viocd.c 2.6.6-rc2.viocd.proc/drivers/cdrom/viocd.c --- 2.6.6-rc2.viocd/drivers/cdrom/viocd.c 2004-04-22 02:14:07.000000000 +1000 +++ 2.6.6-rc2.viocd.proc/drivers/cdrom/viocd.c 2004-04-22 17:31:15.000000000 +1000 @@ -39,6 +39,8 @@ #include #include #include +#include +#include #include @@ -152,6 +154,33 @@ #define MAX_CD_REQ 1 +/* procfs support */ +static int proc_viocd_show(struct seq_file *m, void *v) +{ + int i; + + for (i = 0; i < viocd_numdev; i++) { + seq_printf(m, "viocd device %d is iSeries resource %10.10s" + "type %4.4s, model %3.3s\n", + i, viocd_unitinfo[i].rsrcname, + viocd_unitinfo[i].type, + viocd_unitinfo[i].model); + } + return 0; +} + +static int proc_viocd_open(struct inode *inode, struct file *file) +{ + return single_open(file, proc_viocd_show, NULL); +} + +static struct file_operations proc_viocd_operations = { + .open = proc_viocd_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + static int viocd_blk_open(struct inode *inode, struct file *file) { struct disk_info *di = inode->i_bdev->bd_disk->private_data; @@ -541,6 +570,7 @@ struct gendisk *gendisk; int deviceno; int ret = 0; + struct proc_dir_entry *e; if (viopath_hostLp == HvLpIndexInvalid) { vio_set_hostlp(); @@ -629,6 +659,12 @@ add_disk(gendisk); } + e = create_proc_entry("iSeries/viocd", S_IFREG|S_IRUGO, NULL); + if (e) { + e->owner = THIS_MODULE; + e->proc_fops = &proc_viocd_operations; + } + return 0; out_undo_vio: @@ -643,6 +679,7 @@ { int deviceno; + remove_proc_entry("iSeries/viocd", NULL); for (deviceno = 0; deviceno < viocd_numdev; deviceno++) { struct disk_info *d = &viocd_diskinfo[deviceno]; if (unregister_cdrom(&d->viocd_info) != 0) diff -ruN 2.6.6-rc2.viocd/drivers/char/viotape.c 2.6.6-rc2.viocd.proc/drivers/char/viotape.c --- 2.6.6-rc2.viocd/drivers/char/viotape.c 2004-04-05 10:22:35.000000000 +1000 +++ 2.6.6-rc2.viocd.proc/drivers/char/viotape.c 2004-04-22 17:30:28.000000000 +1000 @@ -47,6 +47,8 @@ #include #include #include +#include +#include #include #include @@ -56,7 +58,7 @@ #include #include -#define VIOTAPE_VERSION "1.1" +#define VIOTAPE_VERSION "1.2" #define VIOTAPE_MAXREQ 1 #define VIOTAPE_KERN_WARN KERN_WARNING "viotape: " @@ -269,6 +271,34 @@ /* forward declaration to resolve interdependence */ static int chg_state(int index, unsigned char new_state, struct file *file); +/* procfs support */ +static int proc_viotape_show(struct seq_file *m, void *v) +{ + int i; + + seq_printf(m, "viotape driver version " VIOTAPE_VERSION "\n"); + for (i = 0; i < viotape_numdev; i++) { + seq_printf(m, "viotape device %d is iSeries resource %10.10s" + "type %4.4s, model %3.3s\n", + i, viotape_unitinfo[i].rsrcname, + viotape_unitinfo[i].type, + viotape_unitinfo[i].model); + } + return 0; +} + +static int proc_viotape_open(struct inode *inode, struct file *file) +{ + return single_open(file, proc_viotape_show, NULL); +} + +static struct file_operations proc_viotape_operations = { + .open = proc_viotape_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + /* Decode the device minor number into its parts */ void get_dev_info(struct inode *ino, struct viot_devinfo_struct *devi) { @@ -912,6 +942,7 @@ int ret; char tapename[32]; int i; + struct proc_dir_entry *e; op_struct_list = NULL; if ((ret = add_op_structs(VIOTAPE_MAXREQ)) < 0) { @@ -988,6 +1019,12 @@ viotape_unitinfo[i].model); } + e = create_proc_entry("iSeries/viotape", S_IFREG|S_IRUGO, NULL); + if (e) { + e->owner = THIS_MODULE; + e->proc_fops = &proc_viotape_operations; + } + return 0; unreg_class: @@ -1029,6 +1066,8 @@ { int i, ret; + remove_proc_entry("iSeries/viotape", NULL); + for (i = 0; i < viotape_numdev; ++i) { devfs_remove("iseries/nvt%d", i); devfs_remove("iseries/vt%d", i); From greg at kroah.com Fri Apr 23 02:21:04 2004 From: greg at kroah.com (Greg KH) Date: Thu, 22 Apr 2004 09:21:04 -0700 Subject: [PATCH] PPC64 iSeries add soem proc entries In-Reply-To: <20040422173632.2ac6a7e4.sfr@canb.auug.org.au> References: <20040422173632.2ac6a7e4.sfr@canb.auug.org.au> Message-ID: <20040422162104.GA13512@kroah.com> On Thu, Apr 22, 2004 at 05:36:32PM +1000, Stephen Rothwell wrote: > Hi Andrew, > > This patch just adds some proc entries for the virtual tape and cdrom > drivers to allow mapping between linux devices and OS/400 ones. This > is expected by existing users and there is no other way to do this > translation. Not in sysfs where stuff like this is supposed to be done? :) thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Fri Apr 23 08:35:02 2004 From: greg at kroah.com (Greg KH) Date: Thu, 22 Apr 2004 15:35:02 -0700 Subject: [PATH] symlink doesn't support kobj name > 20 charaters (KOBJ_NAME_LEN) In-Reply-To: <4086A8B8.2010004@us.ibm.com> References: <4086A8B8.2010004@us.ibm.com> Message-ID: <20040422223502.GA3126@kroah.com> On Wed, Apr 21, 2004 at 12:00:40PM -0500, Linda Xie wrote: > Hi Greg, > > Since symlink.c uses "name" field of a kobj when it calculates the > length, it gets a > wrong value if the kobj's name has more than 20 charathers. A correct > way to do > that is to call kobject_name(kobj) instead of using kobj->name directly. > > Can you apply attached patch to you tree? Applied, thanks. greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sfr at canb.auug.org.au Fri Apr 23 12:02:58 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Fri, 23 Apr 2004 12:02:58 +1000 Subject: [PATCH] PPC64 iSeries add soem proc entries In-Reply-To: <20040422162104.GA13512@kroah.com> References: <20040422173632.2ac6a7e4.sfr@canb.auug.org.au> <20040422162104.GA13512@kroah.com> Message-ID: <20040423120258.4382b189.sfr@canb.auug.org.au> On Thu, 22 Apr 2004 09:21:04 -0700 Greg KH wrote: > > On Thu, Apr 22, 2004 at 05:36:32PM +1000, Stephen Rothwell wrote: > > > > This patch just adds some proc entries for the virtual tape and > > cdrom drivers to allow mapping between linux devices and OS/400 > > ones. This is expected by existing users and there is no other way > > to do this translation. > > Not in sysfs where stuff like this is supposed to be done? No, this is unfortunately a case of least suprise and backwrd compatibility. Eventually, hopefully, this stuff will migrate to sysfs, but that requires that I do the code that makes the virtual drivers use the new driver infrastructure - and that is in train i.e. I am trying to understand the doco :-) > :) Smileys are so important in email :-) -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From nitin at in.ibm.com Sat Apr 24 00:16:22 2004 From: nitin at in.ibm.com (Nitin Vashisth) Date: 23 Apr 2004 19:46:22 +0530 Subject: [PATCH] Fix to update the OP panel on enterting/exiting kdb. Message-ID: <1082729782.3705.19.camel@kumbhkaran.in.ibm.com> Hello, This patch will update the OP panel with the KDB message every time kdb is entered and will put back the Linux kernel version string back on the panel while exiting KDB. Best Regards, Nitin. -- Nitin Vashisth Linux Technology Center IBM Software Lab Bangalore, INDIA Direct 91-80-2504 4611 Board 91-80-2526 2355 / 7117 Extension 3611. -------------- next part -------------- --- ameslab-org/kdb/kdbmain.c 2004-04-22 21:54:42.000000000 -0700 +++ ameslab/kdb/kdbmain.c 2004-04-23 17:14:57.352949016 -0700 @@ -62,6 +62,12 @@ #include #endif +#ifdef CONFIG_PPC64 +#include +#include +#include +#endif + #include /* @@ -3450,8 +3456,17 @@ kdb_cmd_init(void) static int kdb_panic(struct notifier_block *self, unsigned long command, void *ptr) { +#ifdef CONFIG_PPC64 + int cpu=smp_processor_id(); + ppc64_attention_msg(0x3200+cpu,"KDB Call "); +#endif KDB_FLAG_SET(CATASTROPHIC); /* kernel state is dubious now */ KDB_ENTER(); +#ifdef CONFIG_PPC64 + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); +#endif return(0); } --- ameslab-org/arch/ppc64/kdb/kdbasupport.c 2004-04-22 21:52:09.000000000 -0700 +++ ameslab/arch/ppc64/kdb/kdbasupport.c 2004-04-23 17:14:57.354948712 -0700 @@ -41,6 +41,10 @@ #include #include "../kernel/pci.h" // for traverse_all_pci_devices() +#include +#include + + extern const char *kdb_diemsg; unsigned long cpus_in_kdb=0; volatile unsigned long kdb_do_reboot=0; @@ -1757,6 +1761,8 @@ kdb_reset_debugger(struct pt_regs *regs) ppc64_attention_msg(0x3200+cpu,"KDB Call "); kdb(KDB_REASON_ENTER, regs->trap, (kdb_eframe_t) regs); ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); } else { kdb_on=1; kdb_do_reboot=1; @@ -1780,14 +1786,24 @@ kdb_reset_debugger(struct pt_regs *regs) int kdb_debugger(struct pt_regs *regs) { + + int cpu=smp_processor_id(); if (regs) { if (regs->trap==0x100) { kdb_reset_debugger(regs); } else { + ppc64_attention_msg(0x3200+cpu,"KDB Call "); kdb(KDB_REASON_ENTER,regs->trap,regs); /* ok */ + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); } } else { /* regs invalid */ + ppc64_attention_msg(0x3200+cpu,"KDB Call "); kdb(KDB_REASON_SILENT,0,regs); + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); } return 1; } @@ -1795,41 +1811,82 @@ kdb_debugger(struct pt_regs *regs) { int kdb_debugger_bpt(struct pt_regs *regs) { + int cpu=smp_processor_id(); + int ret = 0; + + ppc64_attention_msg(0x3200+cpu,"KDB Call "); if (regs) { if (regs->msr & MSR_SE) { regs->msr &= ~MSR_SE; - return kdb(KDB_REASON_DEBUG, regs->trap, regs); - } - return kdb(KDB_REASON_BREAK,regs->trap,regs); + ret = kdb(KDB_REASON_DEBUG, regs->trap, regs); + } else + ret = kdb(KDB_REASON_BREAK,regs->trap,regs); + } else /* regs invalid */ - return kdb(KDB_REASON_SILENT,0,regs); + ret = kdb(KDB_REASON_SILENT,0,regs); + + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); + + return ret; } int kdb_debugger_sstep(struct pt_regs *regs) { - if (regs) - return kdb(KDB_REASON_DEBUG,regs->trap,regs); /* ok */ + int cpu=smp_processor_id(); + int ret = 0; + + ppc64_attention_msg(0x3200+cpu,"KDB Call "); + if (regs) + ret = kdb(KDB_REASON_DEBUG,regs->trap,regs); /* ok */ else /* regs invalid */ - return kdb(KDB_REASON_SILENT,0,regs); + ret = kdb(KDB_REASON_SILENT,0,regs); + + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); + + return ret; + + } int kdb_debugger_iabr_match(struct pt_regs *regs) { + int cpu=smp_processor_id(); + int ret = 0; + + ppc64_attention_msg(0x3200+cpu,"KDB Call "); if (regs) - return kdb(KDB_REASON_BREAK,regs->trap,regs); + ret = kdb(KDB_REASON_BREAK,regs->trap,regs); else /* regs invalid */ - return kdb(KDB_REASON_SILENT,0,regs); + ret = kdb(KDB_REASON_SILENT,0,regs); + + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); + return ret; } int kdb_debugger_dabr_match(struct pt_regs *regs) { + int cpu=smp_processor_id(); + int ret = 0; + + ppc64_attention_msg(0x3200+cpu,"KDB Call "); if (regs) - return kdb(KDB_REASON_BREAK,regs->trap,regs); + ret = kdb(KDB_REASON_BREAK,regs->trap,regs); else /* regs invalid */ - return kdb(KDB_REASON_SILENT,0,regs); + ret = kdb(KDB_REASON_SILENT,0,regs); + + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); + return ret; } void --- ameslab-org/arch/ppc64/kdb/kdba_bp.c 2004-04-22 21:52:09.000000000 -0700 +++ ameslab/arch/ppc64/kdb/kdba_bp.c 2004-04-23 17:14:57.355948560 -0700 @@ -169,9 +169,9 @@ kdba_db_trap(kdb_eframe_t ef, int error_ KDB_STATE_CLEAR(DOING_SSB); KDB_STATE_CLEAR(DOING_SS); } else { - char *argv[] = {"ssb", NULL}; + const char *argv[] = {"ssb", NULL}; rv = KDB_DB_SSB; /* Indicate ssb - dismiss immediately */ - kdb_ss(0, (char **)argv, NULL, ef); + kdb_ss(0, argv, NULL, ef); } } else { /* --- ameslab-org/drivers/char/sn_serial.c 2004-04-22 21:52:35.000000000 -0700 +++ ameslab/drivers/char/sn_serial.c 2004-04-23 17:14:57.357948256 -0700 @@ -31,6 +31,9 @@ #ifdef CONFIG_KDB #include #include +#include +#include +#include /* * kdb_serial_line records the serial line number of the first serial console. * NOTE: The kernel ignores characters on the serial line unless a user space @@ -311,8 +314,14 @@ sn_receive_chars(struct pt_regs *regs, u if (!(*++kdb_serial_ptr)) { if (!regs) KDB_ENTER(); /* to get some registers */ - else + else { + int cpu=smp_processor_id(); + ppc64_attention_msg(0x3200+cpu,"KDB Call "); kdb(KDB_REASON_KEYBOARD, 0, regs); + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); + } kdb_serial_ptr = (char *)kdb_serial_str; break; } --- ameslab-org/drivers/char/keyboard.c 2004-04-22 21:52:35.000000000 -0700 +++ ameslab/drivers/char/keyboard.c 2004-04-23 17:14:57.358948104 -0700 @@ -42,6 +42,9 @@ #include #ifdef CONFIG_KDB #include +#include +#include +#include #endif /* CONFIG_KDB */ static void kbd_disconnect(struct input_handle *handle); @@ -1064,7 +1067,12 @@ void kbd_keycode(unsigned int keycode, i #ifdef CONFIG_KDB if (down && !rep && (keycode == KEY_PAUSE) && kdb_on) { + int cpu=smp_processor_id(); + ppc64_attention_msg(0x3200+cpu,"KDB Call "); kdb(KDB_REASON_KEYBOARD, 0, regs); + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); return; } #endif /* CONFIG_KDB */ --- ameslab-org/drivers/serial/8250.c 2004-04-22 21:53:17.000000000 -0700 +++ ameslab/drivers/serial/8250.c 2004-04-23 17:14:57.360947800 -0700 @@ -44,6 +44,9 @@ #include "8250.h" #ifdef CONFIG_KDB #include +#include +#include +#include /* * kdb_serial_line records the serial line number of the first serial console. * NOTE: The kernel ignores characters on the serial line unless a user space @@ -852,7 +855,12 @@ receive_chars(struct uart_8250_port *up, if ((up->port.line == kdb_serial_line) && kdb_on) { if (ch == *kdb_serial_ptr) { if (!(*++kdb_serial_ptr)) { + int cpu=smp_processor_id(); + ppc64_attention_msg(0x3200+cpu,"KDB Call "); kdb(KDB_REASON_KEYBOARD, 0, regs); + ppc64_attention_msg(0x3300+cpu,"KDB Done "); + ppc_md.progress("Linux ppc64\n", 0); + ppc_md.progress(UTS_RELEASE, 0); kdb_serial_ptr = kdb_serial_str; break; } From olof at austin.ibm.com Sat Apr 24 01:32:42 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Fri, 23 Apr 2004 10:32:42 -0500 Subject: [PATCH] Fix to update the OP panel on enterting/exiting kdb. In-Reply-To: <1082729782.3705.19.camel@kumbhkaran.in.ibm.com> References: <1082729782.3705.19.camel@kumbhkaran.in.ibm.com> Message-ID: <4089371A.50509@austin.ibm.com> Nitin Vashisth wrote: > Hello, > > This patch will update the OP panel with the KDB message every time kdb > is entered and will put back the Linux kernel version string back on the > panel while exiting KDB. I'm not so certain that I like this. Sure, it's great to be able to spot from just glancing at an HMC that a system has entered KDB, but every time you add more activity to KDB, the greater the risk is that it'll get stuck itself. For example, the code below will use the RTAS calls to update the information on the LED display. Anyway, see other comments below. > +#ifdef CONFIG_PPC64 > + ppc64_attention_msg(0x3300+cpu,"KDB Done "); > + ppc_md.progress("Linux ppc64\n", 0); > + ppc_md.progress(UTS_RELEASE, 0); > +#endif Why do you re-print the Linux/UTS_RELEASE string? There's nothing that really says it has to be there, chances are it's not even there when KDB is entered in the first place. :) Also, you have a lot of duplicated code, the same lines repeat over and over again. If you necessarily have to add this, why not add two small inline functions somewhere and call them instead? It'll keep the code much cleaner. -Olof -- Olof Johansson Office: 4F005/905 Linux on Power Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Sat Apr 24 02:48:49 2004 From: rsa at us.ibm.com (Ryan Scott Arnold) Date: Fri, 23 Apr 2004 11:48:49 -0500 Subject: [PATCCH] add converion of H_LongBusyOrder* to -EBUSY in arch/ppc64/kernel/hvconsole.c Message-ID: <408948F1.5000408@us.ibm.com> As requested, I'm moving the architecture specific changes out of my previously submitted hvcs.diff patch and submitting them as their own patch. This patch adds handling for H_LongBusyOrder* return codes and converts them to the -EBUSY errno for those drivers (only hvcs at this time) who prefer arch independent return codes. Pending review either I'll push this to Ameslab myself or ask someone else (antonb) to do it if that would be a preferred method. Thanks, Ryan S. Arnold -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: longbusy.diff Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040423/c6516b0b/attachment.txt From benh at kernel.crashing.org Sat Apr 24 11:26:19 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sat, 24 Apr 2004 11:26:19 +1000 Subject: [PATCH] Fix to update the OP panel on enterting/exiting kdb. In-Reply-To: <4089371A.50509@austin.ibm.com> References: <1082729782.3705.19.camel@kumbhkaran.in.ibm.com> <4089371A.50509@austin.ibm.com> Message-ID: <1082769978.6447.43.camel@gaston> On Sat, 2004-04-24 at 01:32, Olof Johansson wrote: > Nitin Vashisth wrote: > > Hello, > > > > This patch will update the OP panel with the KDB message every time kdb > > is entered and will put back the Linux kernel version string back on the > > panel while exiting KDB. > > I'm not so certain that I like this. Sure, it's great to be able to spot > from just glancing at an HMC that a system has entered KDB, but every > time you add more activity to KDB, the greater the risk is that it'll > get stuck itself. For example, the code below will use the RTAS calls to > update the information on the LED display. Agreed. For example, we just have had a hard time tracking some issues caused by RTAS, since the debugger would lockup on RTAS spinlock trying to disable surveillance. I'll fix that by providing a lock-free RTAS entry for the debugger, but this is to be used with great care and I think we should minimize such thing as much as possible. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sleddog at us.ibm.com Sun Apr 25 10:14:09 2004 From: sleddog at us.ibm.com (Dave Boutcher) Date: Sat, 24 Apr 2004 19:14:09 -0500 Subject: [PATCH] Make room fails without CONFIG_BLK_DEV_INITRD In-Reply-To: <1082438334.23066.92.camel@gaston> References: <1082406325.16102.476.camel@SigurRos.rchland.ibm.com> <1082438145.1689.90.camel@gaston> <1082438334.23066.92.camel@gaston> Message-ID: Hi Ben, Just FYI, with your make room patches the kernel won't build unless CONFIG_BLK_DEV_INITRD is specificed. I'm currently using the following patch, but I'm thinking there are probably some slightly more clever approaches.... --- 1.94/arch/ppc64/kernel/prom.c Sat Apr 24 00:42:58 2004 +++ edited/prom.c Sat Apr 24 19:04:48 2004 @@ -1544,13 +1544,14 @@ unsigned long needed, unsigned long align) { void *ret; - unsigned long offset = reloc_offset(); *mem_start = ALIGN(*mem_start, align); +#ifdef CONFIG_BLK_DEV_INITRD if (*mem_start + needed > *mem_end) { /* FIXME: Apple OF doesn't map unclaimed mem. If this * ever happened on G5, we'd need to fix. */ unsigned long initrd_len; + unsigned long offset = reloc_offset(); if (*mem_end != RELOC(initrd_start)) prom_panic(RELOC("No memory for copy_device_tree")); @@ -1564,6 +1565,7 @@ RELOC(initrd_start) = *mem_end; RELOC(initrd_end) = RELOC(initrd_start) + initrd_len; } +#endif ret = (void *)*mem_start; *mem_start += needed; @@ -1699,7 +1701,13 @@ phandle root; struct device_node **allnextp; unsigned long offset = reloc_offset(); - unsigned long mem_end = RELOC(initrd_start); + unsigned long mem_end = +#ifdef CONFIG_BLK_DEV_INITRD + RELOC(initrd_start); +#else + 0; +#endif + /* We pass mem_end-mem_start to OF: keep it well under 32-bit */ if (!mem_end) ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rusty at rustcorp.com.au Sun Apr 25 18:04:50 2004 From: rusty at rustcorp.com.au (Rusty Russell) Date: Sun, 25 Apr 2004 18:04:50 +1000 Subject: [Fwd: [PATCH] Make room fails without CONFIG_BLK_DEV_INITRD] In-Reply-To: <1082852448.1739.49.camel@gaston> References: <1082852448.1739.49.camel@gaston> Message-ID: <1082880289.3805.41.camel@bach> On Sun, 2004-04-25 at 10:20, Benjamin Herrenschmidt wrote: > -----Forwarded Message----- > From: Dave Boutcher > To: Benjamin Herrenschmidt > Cc: ppc64 Dev list > Subject: [PATCH] Make room fails without CONFIG_BLK_DEV_INITRD > Date: Sat, 24 Apr 2004 19:14:09 -0500 > > Hi Ben, > > Just FYI, with your make room patches the kernel won't build unless > CONFIG_BLK_DEV_INITRD is specificed. Oops. Prefer this fix: does it work for you? Thanks! Rusty. Name: Fix compile for CONFIG_BLK_DEV_INITRD=n Status: Trivial Depends: Misc/prom-move-initrd.patch.gz Doesn't compile with CONFIG_BLK_DEV_INITRD=n. Be more careful with the conditionals. diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .24128-linux-2.6.6-rc2-bk3/arch/ppc64/kernel/prom.c .24128-linux-2.6.6-rc2-bk3.updated/arch/ppc64/kernel/prom.c --- .24128-linux-2.6.6-rc2-bk3/arch/ppc64/kernel/prom.c 2004-04-25 17:49:51.000000000 +1000 +++ .24128-linux-2.6.6-rc2-bk3.updated/arch/ppc64/kernel/prom.c 2004-04-25 18:02:15.000000000 +1000 @@ -1548,6 +1548,7 @@ static void __init *__make_room(unsigned *mem_start = ALIGN(*mem_start, align); if (*mem_start + needed > *mem_end) { +#ifdef CONFIG_BLK_DEV_INITRD /* FIXME: Apple OF doesn't map unclaimed mem. If this * ever happened on G5, we'd need to fix. */ unsigned long initrd_len; @@ -1563,6 +1564,9 @@ static void __init *__make_room(unsigned initrd_len); RELOC(initrd_start) = *mem_end; RELOC(initrd_end) = RELOC(initrd_start) + initrd_len; +#else + prom_panic(RELOC("No memory for copy_device_tree")); +#endif } ret = (void *)*mem_start; @@ -1699,11 +1703,14 @@ copy_device_tree(unsigned long mem_start phandle root; struct device_node **allnextp; unsigned long offset = reloc_offset(); - unsigned long mem_end = RELOC(initrd_start); + unsigned long mem_end; /* We pass mem_end-mem_start to OF: keep it well under 32-bit */ - if (!mem_end) - mem_end = mem_start + 1024*1024*1024; + mem_end = mem_start + 1024*1024*1024; +#ifdef CONFIG_BLK_DEV_INITRD + if (RELOC(initrd_start) && RELOC(initrd_start) > mem_start) + mem_end = RELOC(initrd_start); +#endif /* CONFIG_BLK_DEV_INITRD */ root = call_prom(RELOC("peer"), 1, 1, (phandle)0); if (root == (phandle)0) { @@ -1964,12 +1971,14 @@ prom_init(unsigned long r3, unsigned lon prom_print(RELOC("after basic inits, mem=0x")); prom_print_hex(mem); prom_print_nl(); +#ifdef CONFIG_BLK_DEV_INITRD prom_print(RELOC("initrd_start=0x")); prom_print_hex(RELOC(initrd_start)); prom_print_nl(); prom_print(RELOC("initrd_end=0x")); prom_print_hex(RELOC(initrd_end)); prom_print_nl(); +#endif /* CONFIG_BLK_DEV_INITRD */ prom_print(RELOC("copying OF device tree...\n")); #endif /* DEBUG_PROM */ mem = copy_device_tree(mem); -- Anyone who quotes me in their signature is an idiot -- Rusty Russell ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Sun Apr 25 18:46:46 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sun, 25 Apr 2004 18:46:46 +1000 Subject: [Fwd: [PATCH] Make room fails without CONFIG_BLK_DEV_INITRD] In-Reply-To: <1082880289.3805.41.camel@bach> References: <1082852448.1739.49.camel@gaston> <1082880289.3805.41.camel@bach> Message-ID: <1082882806.1738.56.camel@gaston> On Sun, 2004-04-25 at 18:04, Rusty Russell wrote: > > Just FYI, with your make room patches the kernel won't build unless > > CONFIG_BLK_DEV_INITRD is specificed. > > Oops. Prefer this fix: does it work for you? Definitely looks better. I'll let you send to Andrew and I will push to ames. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From davis at skink.net Mon Apr 26 11:45:55 2004 From: davis at skink.net (davis) Date: Sun, 25 Apr 2004 21:45:55 -0400 Subject: Does altivec work on biarch compiler for gcc 3.3.3-hammer? Message-ID: <20040426014555.GA2122@skink.net> Hello Does altivec work with gcc 3.3.3 hammer? I'm building with -maltivec and -mabi=altivec but it does not seem to work for simple programs. For instance, printf("%vc",(vector unsigned char) {'h','e','l','l','o'}); Will print: %vc Here is how I am building: gcc -maltivec -mabi=altivec -mcpu=970 -mtune=970 testy.c -- Happy Trails John F. Davis ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Mon Apr 26 11:54:19 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 26 Apr 2004 11:54:19 +1000 Subject: Does altivec work on biarch compiler for gcc 3.3.3-hammer? In-Reply-To: <20040426014555.GA2122@skink.net> References: <20040426014555.GA2122@skink.net> Message-ID: <1082944458.1716.80.camel@gaston> On Mon, 2004-04-26 at 11:45, davis wrote: > Hello > > Does altivec work with gcc 3.3.3 hammer? > > I'm building with -maltivec and -mabi=altivec but it does not seem to work > for simple programs. For instance, > > printf("%vc",(vector unsigned char) {'h','e','l','l','o'}); It works, though I've been told 3.4 is more reliable at generating vector code. > Will print: > > %vc Which is a glibc issue, not gcc. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sleddog at us.ibm.com Mon Apr 26 12:55:17 2004 From: sleddog at us.ibm.com (Dave Boutcher) Date: Sun, 25 Apr 2004 21:55:17 -0500 Subject: [Fwd: [PATCH] Make room fails without CONFIG_BLK_DEV_INITRD] In-Reply-To: <1082880289.3805.41.camel@bach> References: <1082852448.1739.49.camel@gaston> <1082880289.3805.41.camel@bach> Message-ID: On Sun, 25 Apr 2004 18:04:50 +1000, Rusty Russell wrote: > Oops. Prefer this fix: does it work for you? Compiles and boots on my system. Much better than my hack :-) Dave B ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Mon Apr 26 17:16:00 2004 From: anton at samba.org (Anton Blanchard) Date: Mon, 26 Apr 2004 17:16:00 +1000 Subject: remove naca->slb_size Message-ID: <20040426071600.GG20714@krispykreme> Hi, The performance guys have pointed out how slow our userspace segment SLB replacement code is. At the moment naca->slb_size isnt very useful, we just hardcode it at boot. On top of that, do_slb_bolted doesnt even use it. So heres a patch to get rid of it. Looking at make_slbe before and after: @@ -628,10 +628,6 @@ bdnz .L102 b .L93 .size .flush_stab,.-.flush_stab - .section ".toc","aw" -.LC14: - .tc naca[TC],naca - .section ".text" .align 2 .section ".opd","aw" .align 3 @@ -641,21 +637,18 @@ .size make_slbe,24 .type .make_slbe, at function .make_slbe: - ld 11,.LC14 at toc(2) - ld 10,72(13) - ld 9,0(11) - ld 8,72(9) + ld 9,72(13) As you can see we reduce it by 3 instructions all of which were dependent loads. Anton --- ameslab-2.5-anton/arch/ppc64/kdb/kdba_bp.c | 4 ---- ameslab-2.5-anton/arch/ppc64/kernel/asm-offsets.c | 1 - ameslab-2.5-anton/arch/ppc64/kernel/eeh.c | 1 - ameslab-2.5-anton/arch/ppc64/kernel/head.S | 2 -- ameslab-2.5-anton/arch/ppc64/kernel/iSeries_pci.c | 1 - ameslab-2.5-anton/arch/ppc64/kernel/iSeries_proc.c | 1 - ameslab-2.5-anton/arch/ppc64/kernel/iSeries_setup.c | 5 ----- ameslab-2.5-anton/arch/ppc64/kernel/pci.c | 1 - ameslab-2.5-anton/arch/ppc64/kernel/pci_dn.c | 1 - ameslab-2.5-anton/arch/ppc64/kernel/prom.c | 7 ------- ameslab-2.5-anton/arch/ppc64/kernel/stab.c | 2 +- ameslab-2.5-anton/arch/ppc64/mm/init.c | 1 - ameslab-2.5-anton/include/asm-ppc64/naca.h | 2 +- ameslab-2.5-anton/include/asm-ppc64/processor.h | 6 ++++++ 14 files changed, 8 insertions(+), 27 deletions(-) diff -puN arch/ppc64/kdb/kdba_bp.c~naca_no_slbsize arch/ppc64/kdb/kdba_bp.c --- ameslab-2.5/arch/ppc64/kdb/kdba_bp.c~naca_no_slbsize 2004-04-25 18:18:19.741049712 +1000 +++ ameslab-2.5-anton/arch/ppc64/kdb/kdba_bp.c 2004-04-25 18:18:19.788049130 +1000 @@ -756,10 +756,6 @@ kdba_removebp(kdb_bp_t *bp) return 0; } -#if 0 -#define systemcfg naca -#endif - /* install data breakpoint */ void kdba_installdbreg(kdb_bp_t *bp) { diff -puN arch/ppc64/kernel/asm-offsets.c~naca_no_slbsize arch/ppc64/kernel/asm-offsets.c --- ameslab-2.5/arch/ppc64/kernel/asm-offsets.c~naca_no_slbsize 2004-04-25 18:18:19.744049675 +1000 +++ ameslab-2.5-anton/arch/ppc64/kernel/asm-offsets.c 2004-04-25 18:18:19.816048782 +1000 @@ -73,7 +73,6 @@ int main(void) DEFINE(ICACHEL1LINESIZE, offsetof(struct systemcfg, iCacheL1LineSize)); DEFINE(ICACHEL1LOGLINESIZE, offsetof(struct naca_struct, iCacheL1LogLineSize)); DEFINE(ICACHEL1LINESPERPAGE, offsetof(struct naca_struct, iCacheL1LinesPerPage)); - DEFINE(SLBSIZE, offsetof(struct naca_struct, slb_size)); DEFINE(PLATFORM, offsetof(struct systemcfg, platform)); /* paca */ diff -puN arch/ppc64/kernel/eeh.c~naca_no_slbsize arch/ppc64/kernel/eeh.c --- ameslab-2.5/arch/ppc64/kernel/eeh.c~naca_no_slbsize 2004-04-25 18:18:19.748049625 +1000 +++ ameslab-2.5-anton/arch/ppc64/kernel/eeh.c 2004-04-25 18:18:19.790049105 +1000 @@ -27,7 +27,6 @@ #include #include #include -#include #include #include #include diff -puN arch/ppc64/kernel/head.S~naca_no_slbsize arch/ppc64/kernel/head.S --- ameslab-2.5/arch/ppc64/kernel/head.S~naca_no_slbsize 2004-04-25 18:18:19.751049588 +1000 +++ ameslab-2.5-anton/arch/ppc64/kernel/head.S 2004-04-25 18:18:19.805048919 +1000 @@ -1120,8 +1120,6 @@ _GLOBAL(do_slb_bolted) */ /* r20 = paca */ - /* use a cpu feature mask if we ever change our slb size */ -SLB_NUM_ENTRIES = 64 1: ld r22,PACASTABRR(r20) addi r21,r22,1 cmpdi r21,SLB_NUM_ENTRIES diff -puN arch/ppc64/kernel/iSeries_pci.c~naca_no_slbsize arch/ppc64/kernel/iSeries_pci.c --- ameslab-2.5/arch/ppc64/kernel/iSeries_pci.c~naca_no_slbsize 2004-04-25 18:18:19.755049539 +1000 +++ ameslab-2.5-anton/arch/ppc64/kernel/iSeries_pci.c 2004-04-25 18:18:19.793049068 +1000 @@ -36,7 +36,6 @@ #include #include #include -#include #include #include diff -puN arch/ppc64/kernel/iSeries_proc.c~naca_no_slbsize arch/ppc64/kernel/iSeries_proc.c --- ameslab-2.5/arch/ppc64/kernel/iSeries_proc.c~naca_no_slbsize 2004-04-25 18:18:19.758049501 +1000 +++ ameslab-2.5-anton/arch/ppc64/kernel/iSeries_proc.c 2004-04-25 18:18:19.794049055 +1000 @@ -23,7 +23,6 @@ #include #include #include -#include #include #include #include diff -puN arch/ppc64/kernel/pci.c~naca_no_slbsize arch/ppc64/kernel/pci.c --- ameslab-2.5/arch/ppc64/kernel/pci.c~naca_no_slbsize 2004-04-25 18:18:19.761049464 +1000 +++ ameslab-2.5-anton/arch/ppc64/kernel/pci.c 2004-04-25 18:18:19.796049030 +1000 @@ -32,7 +32,6 @@ #include #include #include -#include #include #include diff -puN arch/ppc64/kernel/pci_dn.c~naca_no_slbsize arch/ppc64/kernel/pci_dn.c --- ameslab-2.5/arch/ppc64/kernel/pci_dn.c~naca_no_slbsize 2004-04-25 18:18:19.765049415 +1000 +++ ameslab-2.5-anton/arch/ppc64/kernel/pci_dn.c 2004-04-25 18:18:19.797049018 +1000 @@ -35,7 +35,6 @@ #include #include #include -#include #include #include "pci.h" diff -puN arch/ppc64/kernel/prom.c~naca_no_slbsize arch/ppc64/kernel/prom.c --- ameslab-2.5/arch/ppc64/kernel/prom.c~naca_no_slbsize 2004-04-25 18:18:19.769049365 +1000 +++ ameslab-2.5-anton/arch/ppc64/kernel/prom.c 2004-04-25 18:18:19.814048807 +1000 @@ -473,13 +473,6 @@ prom_initialize_naca(unsigned long mem) PROM_BUG(); } - /* - * Hardcode to GP size. I am not sure where to get this info - * in general, as there does not appear to be a slb-size OF - * entry. At least in Condor and earlier. DRENG - */ - _naca->slb_size = 64; - /* Add an eye catcher and the systemcfg layout version number */ strcpy(_systemcfg->eye_catcher, RELOC("SYSTEMCFG:PPC64")); _systemcfg->version.major = SYSTEMCFG_MAJOR; diff -puN arch/ppc64/kernel/stab.c~naca_no_slbsize arch/ppc64/kernel/stab.c --- ameslab-2.5/arch/ppc64/kernel/stab.c~naca_no_slbsize 2004-04-25 18:18:19.772049328 +1000 +++ ameslab-2.5-anton/arch/ppc64/kernel/stab.c 2004-04-25 18:18:19.807048894 +1000 @@ -335,7 +335,7 @@ static void make_slbe(unsigned long esid do { entry = castout_entry; castout_entry++; - if (castout_entry >= naca->slb_size) + if (castout_entry >= SLB_NUM_ENTRIES) castout_entry = 1; asm volatile("slbmfee %0,%1" : "=r" (esid_data) : "r" (entry)); } while (esid_data.data.v && diff -puN arch/ppc64/mm/init.c~naca_no_slbsize arch/ppc64/mm/init.c --- ameslab-2.5/arch/ppc64/mm/init.c~naca_no_slbsize 2004-04-25 18:18:19.776049278 +1000 +++ ameslab-2.5-anton/arch/ppc64/mm/init.c 2004-04-25 18:18:19.799048993 +1000 @@ -51,7 +51,6 @@ #include #include #include -#include #include #include #include diff -puN include/asm-ppc64/naca.h~naca_no_slbsize include/asm-ppc64/naca.h --- ameslab-2.5/include/asm-ppc64/naca.h~naca_no_slbsize 2004-04-25 18:18:19.779049241 +1000 +++ ameslab-2.5-anton/include/asm-ppc64/naca.h 2004-04-25 18:18:19.808048882 +1000 @@ -30,7 +30,7 @@ struct naca_struct { u64 log; /* Ptr to log buffer 0x30 */ u64 serialPortAddr; /* Phy addr of serial port 0x38 */ u64 interrupt_controller; /* Type of int controller 0x40 */ - u64 slb_size; /* SLB size in entries 0x48 */ + u64 unused1; /* was SLB size in entries 0x48 */ u64 pftSize; /* Log 2 of page table size 0x50 */ void *systemcfg; /* Pointer to systemcfg data 0x58 */ u32 dCacheL1LogLineSize; /* L1 d-cache line size Log2 0x60 */ diff -puN include/asm-ppc64/processor.h~naca_no_slbsize include/asm-ppc64/processor.h --- ameslab-2.5/include/asm-ppc64/processor.h~naca_no_slbsize 2004-04-25 18:18:19.782049204 +1000 +++ ameslab-2.5-anton/include/asm-ppc64/processor.h 2004-04-25 18:18:19.818048758 +1000 @@ -625,4 +625,10 @@ static inline void prefetchw(const void #endif /* ASSEMBLY */ +/* + * Number of entries in the SLB. If this ever changes we should handle + * it with a use a cpu feature fixup. + */ +#define SLB_NUM_ENTRIES 64 + #endif /* __ASM_PPC64_PROCESSOR_H */ diff -puN arch/ppc64/kernel/iSeries_setup.c~naca_no_slbsize arch/ppc64/kernel/iSeries_setup.c --- ameslab-2.5/arch/ppc64/kernel/iSeries_setup.c~naca_no_slbsize 2004-04-25 18:19:08.896440446 +1000 +++ ameslab-2.5-anton/arch/ppc64/kernel/iSeries_setup.c 2004-04-25 18:19:20.203300302 +1000 @@ -562,11 +562,6 @@ static void __init build_iSeries_Memory_ lmb_add(0, systemcfg->physicalMemorySize); lmb_analyze(); /* ?? */ lmb_reserve(0, __pa(klimit)); - - /* - * Hardcode to GP size. I am not sure where to get this info. DRENG - */ - naca->slb_size = 64; } /* _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From segher at kernel.crashing.org Mon Apr 26 17:39:17 2004 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 26 Apr 2004 09:39:17 +0200 Subject: Does altivec work on biarch compiler for gcc 3.3.3-hammer? In-Reply-To: <20040426014555.GA2122@skink.net> References: <20040426014555.GA2122@skink.net> Message-ID: > Does altivec work with gcc 3.3.3 hammer? Yes. > I'm building with -maltivec and -mabi=altivec but it does not seem to > work > for simple programs. For instance, > > printf("%vc",(vector unsigned char) {'h','e','l','l','o'}); Not valid code. A vector initializer has either one, or exactly the correct number of elements (i.e., for char, 16 elts). > Will print: > > %vc glibc doesn't support vector printf extensions. Political issue. > Here is how I am building: > > gcc -maltivec -mabi=altivec -mcpu=970 -mtune=970 testy.c -mtune is redundant; looks fine otherwise. Segher ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From davis at skink.net Mon Apr 26 23:44:20 2004 From: davis at skink.net (davis) Date: Mon, 26 Apr 2004 09:44:20 -0400 Subject: Does altivec work on biarch compiler for gcc 3.3.3-hammer? In-Reply-To: References: <20040426014555.GA2122@skink.net> Message-ID: <20040426134420.GA3537@skink.net> Hello Segher, On Mon, Apr 26, 2004 at 09:39:17AM +0200, Segher Boessenkool wrote: > >Does altivec work with gcc 3.3.3 hammer? > > Yes. > > >I'm building with -maltivec and -mabi=altivec but it does not seem to > >work > >for simple programs. For instance, > > > > printf("%vc",(vector unsigned char) {'h','e','l','l','o'}); > > Not valid code. A vector initializer has either one, or exactly > the correct number of elements (i.e., for char, 16 elts). Thanks that is good to know. However, I was a little sloppy with my rewrite. I actually did use all the slots in the vector as they do in the velocity engine tutorial. ie. hello world 1234. My main point was below. > > >Will print: > > > > %vc > > glibc doesn't support vector printf extensions. Political issue. That's good to know. I won't try to get that stuff working anymore. > > >Here is how I am building: > > > > gcc -maltivec -mabi=altivec -mcpu=970 -mtune=970 testy.c > > -mtune is redundant; looks fine otherwise. That is also good to know. Many thanks. > > > Segher > -- Happy Trails John F. Davis Durham, North Carolina Airhead BMW Club #6334 1992 R100GSPD http://www.skink.net ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From nathanl at austin.ibm.com Tue Apr 27 08:16:41 2004 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Mon, 26 Apr 2004 17:16:41 -0500 Subject: [PATCH] restore /proc/ppc64/rtas/error_log Message-ID: <408D8A49.4040608@austin.ibm.com> Hi- Somehow we've been placing the rtas error_log file at /proc/ppc64/error_log, which breaks at least one application I know of. It is supposed to be at /proc/ppc64/rtas/error_log (this is the 2.4 behavior). Nathan -------------- next part -------------- A non-text attachment was scrubbed... Name: put_rtas_error_log_in_the_right_place.patch Type: text/x-patch Size: 436 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040426/c1460375/attachment.bin From benh at kernel.crashing.org Tue Apr 27 08:28:00 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 27 Apr 2004 08:28:00 +1000 Subject: remove naca->slb_size In-Reply-To: <20040426071600.GG20714@krispykreme> References: <20040426071600.GG20714@krispykreme> Message-ID: <1083018480.1828.7.camel@gaston> On Mon, 2004-04-26 at 17:16, Anton Blanchard wrote: > Hi, > > The performance guys have pointed out how slow our userspace segment > SLB replacement code is. At the moment naca->slb_size isnt very useful, > we just hardcode it at boot. On top of that, do_slb_bolted doesnt even > use it. > > So heres a patch to get rid of it. Looking at make_slbe before and after: I think we should rewrite that critical code path in asm in fact... (and simulate it). Note that for things like the SLB size, if we ever have a different size, we can always use dynamic patching... Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at samba.org Tue Apr 27 15:45:42 2004 From: paulus at samba.org (Paul Mackerras) Date: Tue, 27 Apr 2004 15:45:42 +1000 Subject: [PATCCH] add converion of H_LongBusyOrder* to -EBUSY in arch/ppc64/kernel/hvconsole.c In-Reply-To: <408948F1.5000408@us.ibm.com> References: <408948F1.5000408@us.ibm.com> Message-ID: <16525.62342.125829.294264@cargo.ozlabs.ibm.com> Ryan Scott Arnold writes: > This patch adds handling for H_LongBusyOrder* return codes and converts > them to the -EBUSY errno for those drivers (only hvcs at this time) who > prefer arch independent return codes. > > Pending review either I'll push this to Ameslab myself or ask someone > else (antonb) to do it if that would be a preferred method. Patch looks fine. I'll check it in. Just looking at the surrounding code, I wonder why we return -EPERM for the default case? EINVAL would possibly be a better choice for a generic "something went wrong". How are we progressing towards having something that could be sent upstream (as far as the hvc stuff is concerned)? Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rsa at us.ibm.com Tue Apr 27 23:15:19 2004 From: rsa at us.ibm.com (Ryan Arnold) Date: 27 Apr 2004 08:15:19 -0500 Subject: [PATCCH] add converion of H_LongBusyOrder* to -EBUSY in arch/ppc64/kernel/hvconsole.c In-Reply-To: <16525.62342.125829.294264@cargo.ozlabs.ibm.com> References: <408948F1.5000408@us.ibm.com> <16525.62342.125829.294264@cargo.ozlabs.ibm.com> Message-ID: <1083071720.16102.1927.camel@SigurRos.rchland.ibm.com> On Tue, 2004-04-27 at 00:45, Paul Mackerras wrote: > Just looking at the surrounding code, I wonder why we return -EPERM > for the default case? EINVAL would possibly be a better choice for a > generic "something went wrong". > Paul, thanks for the check-in. We return -EPERM on the default _and_ on H_Function because H_Function indicates that a function or operation is not supported by the hypervisor. The default RPA return value for invalid parameters is H_Parameter, which does get converted to -EINVAL. Testing tended to indicate that as long as the function was supported H_Parameter was the return value when something known was wrong but H_Function is returned in a much more narrow case. My reasoning for wanting -EPERM returned as the default is that the hypervisor already returns H_Parameter for way too many ambiguous cases (not enough unique return codes for all the operations) and I'd like to know when something unique happens (outside the standard H_Parameter return case). > How are we progressing towards having something that could be sent > upstream (as far as the hvc stuff is concerned)? Well, I've got the code ready. I'm still going to resubmit the compile warning patch to Ameslab first. Mostly I'm waiting for Hollis's HVSI patch to get submitted/accepted on the mainline since we share a large amount of arch functionality that would be out of synch with the current mainline code if I were to submit my driver first. Ryan S. Arnold ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From torvalds at osdl.org Wed Apr 28 03:12:22 2004 From: torvalds at osdl.org (Linus Torvalds) Date: Tue, 27 Apr 2004 10:12:22 -0700 (PDT) Subject: "make allyesconfig"? Message-ID: One thing I've not done in a long time on my main machine is to try to make "allyesconfig" to get better coverage on stuff. And it just doesn't work on ppc64. Some of the stuff is pretty simple - I can make AGP compile (work? what's that?) by copying the ppc32 version of agp.h to include/asm-ppc64/ and fix a few other assumptions. And I've disabled a few drivers that won't build (the "pmac" IDE driver ends up missing "mediabay" defines, some ISDN drivers seem to be making nasty assumptions etc), but I was wondering if somebody has already done all the work - marking things broken on ppc64 in the Kconfig files so that "make allyesconfig" just does the right thing? Linus ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Wed Apr 28 04:48:40 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Tue, 27 Apr 2004 13:48:40 -0500 (CDT) Subject: [PATCH] ppc64: Set memory-only nodes online Message-ID: Hi, On pSeries LPARs we might end up with NUMA nodes that only have memory and no CPUs. Only the CPU configuration code actually set a node online, so memory-only nodes wouldn't show up in sysfs. Below patch adds the set_online call to the memory loop too. -Olof ===== arch/ppc64/mm/numa.c 1.24 vs edited ===== --- 1.24/arch/ppc64/mm/numa.c Mon Apr 12 12:54:46 2004 +++ edited/arch/ppc64/mm/numa.c Mon Apr 26 22:51:55 2004 @@ -184,6 +184,8 @@ if (numa_domain >= MAX_NUMNODES) BUG(); + node_set_online(numa_domain); + if (max_domain < numa_domain) max_domain = numa_domain; ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Wed Apr 28 08:54:35 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 28 Apr 2004 08:54:35 +1000 Subject: "make allyesconfig"? In-Reply-To: References: Message-ID: <1083106474.16544.29.camel@gaston> On Wed, 2004-04-28 at 03:12, Linus Torvalds wrote: > One thing I've not done in a long time on my main machine is to try to > make "allyesconfig" to get better coverage on stuff. And it just doesn't > work on ppc64. > > Some of the stuff is pretty simple - I can make AGP compile (work? what's > that?) by copying the ppc32 version of agp.h to include/asm-ppc64/ and fix > a few other assumptions. > > And I've disabled a few drivers that won't build (the "pmac" IDE driver > ends up missing "mediabay" defines, some ISDN drivers seem to be making > nasty assumptions etc), but I was wondering if somebody has already done > all the work - marking things broken on ppc64 in the Kconfig files so that > "make allyesconfig" just does the right thing? No, but I can do that, though it's weird that it tried to include the media bay stuff, that should be allowed to build on a ppc64 config. I'l have a look. Also, p and i series are mutually exclusive at this point, so we would in fact need a p-allyesconfig and an i-allyesconfig ;) But then, it's known that iseries won't built with various things. Finally, it's also expected that an allyesconfig kernel will not boot a pmac due to the legacy drivers trying to tap random IO ports for things that don't exist and crashing the box. I have no quick fix for that at the moment but ugly bits of #ifdef CONFIG_PPC if (_machine == _MACH_Pmac) return #endif In various places (this is what the distros are doing lately). I hope that in 2.7, we'll define a neat way to "describe" the legacy device setup from the arch code by creating struct device for them with some way to express "ranges" of IO ports that can be probed. The arch would then create that. It's one of the topic of the Kernel Summit this year. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sleddog at us.ibm.com Wed Apr 28 12:41:44 2004 From: sleddog at us.ibm.com (Dave Boitcjer) Date: Tue, 27 Apr 2004 21:41:44 -0500 Subject: [PATCH] mf_proc.c Message-ID: <408ED398.6501.77AA369@localhost> This patch was submitted by Olaf Hering to fix mf_proc.c where it does not return error values correctly. Paul/Anton, please apply and move upstream when you next bundle things up. Dave B ===== mf_proc.c 1.7 vs edited ===== --- 1.7/arch/ppc64/kernel/mf_proc.c Tue Mar 16 18:46:43 2004 +++ edited/mf_proc.c Tue Apr 27 12:37:03 2004 @@ -177,10 +177,14 @@ static int proc_mf_change_vmlinux(struct file *file, const char *buffer, unsigned long count, void *data) { + int rc; if (!capable(CAP_SYS_ADMIN)) return -EACCES; - mf_setVmlinuxChunk(buffer, count, file->f_pos, (u64)data); + rc = mf_setVmlinuxChunk(buffer, count, file->f_pos, (u64)data); + if (rc < 0) + return rc; + file->f_pos += count; return count; ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Wed Apr 28 15:05:28 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 28 Apr 2004 15:05:28 +1000 Subject: hvconsole.c : possible problem Message-ID: <1083128727.20089.57.camel@gaston> Hi ! I've been reviewing arch/ppc64/kernel/hvconsole.c from ameslab tree and I have a few comments: - The use of static variables names "write, read, ring" is a bit annoying for anybody trying to debug since they will appear "as-is" in System.map. Even for static variables, it's useful to have a prefix. - There is a potential buffer overflow, I think, in hvsi_load_chunk(), in this line : /* copy up to 16 bytes into the write buffer */ chunklen = hvsi_read(vtty, write->data.pkt + write->got, 16); The packet is defined to be 256 bytes. Now, if "got" is 254 bytes for example and we call that routine, I let you figure out what happens. It may not be possible for valid packets but I suppose an attacker can always forge something. Also, you load the ring buffer without limit, that means you can eventually overflow and reuse a buffer that is filled with data instead of breaking out. The whole function seems dodgy, it should rather ask for the exact amount it can fit in the packet, not more, and get rid of the overflow thing, don't you think ? A much simpler loop basically, asking only as much is needed to fill the header if that isn't filled, then as much is needed to fill the data (maxed out at 16) until the packet is filled. That would allow to always deal only with packet boundaries, let throttling work properly at HV level, and simplify the code significantly... - There is historical hunt for null characters in hvterm_get_chars(), that paulus added because xmon was getting confused. Where do those NULL chars come from ? I doubt HV itself is adding anything to the stream so I suppose it's whatever console program sits at the other hand ? I'm asking because hvsi_read() doesn't do that, and so we end up with 2 routines having the exact same prototype: hvsi_read() and hvc_hvterm_get_chars(), both calling the same HV routine, but not doing exactly the same thing and I was wondering if this inconsistency was still necessary. - The whole wait_for_packet() is completely synchronous (doesn't schedule), that doesn't sound very good. That's all for now ;) Cheers, BenH. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Thu Apr 29 00:37:04 2004 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Wed, 28 Apr 2004 09:37:04 -0500 Subject: hvconsole.c : possible problem In-Reply-To: <1083128727.20089.57.camel@gaston> References: <1083128727.20089.57.camel@gaston> Message-ID: <8457B337-9921-11D8-AFB9-000A95A0560C@us.ibm.com> On Apr 28, 2004, at 12:05 AM, Benjamin Herrenschmidt wrote: > > I've been reviewing arch/ppc64/kernel/hvconsole.c from ameslab tree > and I have a few comments: Thanks Ben, this is all my stuff. > - The use of static variables names "write, read, ring" is a bit > annoying for anybody trying to debug since they will appear "as-is" > in System.map. Even for static variables, it's useful to have a prefix. Ok. > - There is a potential buffer overflow, I think, in hvsi_load_chunk(), > in this line : > > /* copy up to 16 bytes into the write buffer */ > chunklen = hvsi_read(vtty, write->data.pkt + write->got, 16); > > The packet is defined to be 256 bytes. Now, if "got" is 254 bytes for > example and we call that routine, I let you figure out what happens. It > may not be possible for valid packets but I suppose an attacker can > always forge something. Ok. > Also, you load the ring buffer without limit, that means you can > eventually overflow and reuse a buffer that is filled with data > instead of breaking out. That's not true... oh, except that can happen in the overflow logic, yeah. > The whole function seems dodgy, it should > rather ask for the exact amount it can fit in the packet, not more, > and get rid of the overflow thing, don't you think ? Sorry, didn't follow that. The problem being solved is this: you do an hvsi_read() and store 15 bytes into 'buf' as follows: ff05000065 ff05000165 ff05000265 (that's "AAA" in three packets). We just put all three of those packets into a single ring buffer, so now we have to go back and copy two and three into subsequent buffers. Another possibility is having an intermediary 256-byte buffer that we read into, then copy from there into buffers. That would probably simplify the code a bit, at the expense of always requiring at least one memcpy (which is not the case now) even if we just get one packet. I'll try that. > A much simpler loop basically, asking only as much is needed to fill > the header if that isn't filled, then as much is needed to fill the > data (maxed out at 16) until the packet is filled. That would allow > to always deal only with packet boundaries, let throttling work > properly > at HV level, and simplify the code significantly... We don't get to ask for a specific number of bytes; we're told after we have them (up to 16). I'm noticing that the '16' parameter you're looking at is never used, and should be removed all the way back to drivers/char/hvc_console.c. > - There is historical hunt for null characters in hvterm_get_chars(), > that paulus added because xmon was getting confused. Where do those > NULL > chars come from ? I doubt HV itself is adding anything to the stream so > I suppose it's whatever console program sits at the other hand ? That must be the case, yeah. HVSI data passes through the HV in the same way as normal console data, but if any munging occured there we would be screwed. So it must be that java "vterm" on the HMC. > I'm > asking because hvsi_read() doesn't do that, and so we end up with 2 > routines having the exact same prototype: hvsi_read() and > hvc_hvterm_get_chars(), both calling the same HV routine, but not > doing exactly the same thing and I was wondering if this inconsistency > was still necessary. I've verified that those NULLs do still appear in the normal case, if that's what you mean. I have not seen any NULLs come through the HVSI code and they would be pretty noticeable. That is consistent with the vterm-did-it theory, and yes, that means we have different behavior. > - The whole wait_for_packet() is completely synchronous (doesn't > schedule), that doesn't sound very good. True, hmm... I must have meant to come back to that later. I guess I'll find out, but is there a limit on how early you can call schedule() during boot (like kmalloc)? wait_for_packet() is only used during initialization which happens pretty early. -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From cfriesen at nortelnetworks.com Thu Apr 29 06:41:26 2004 From: cfriesen at nortelnetworks.com (Chris Friesen) Date: Wed, 28 Apr 2004 16:41:26 -0400 Subject: problem building 64-bit gcc Message-ID: <409016F6.9000908@nortelnetworks.com> I built the 04/04/28 release of binutils for ppc64 using the recommended config options, installed it, and used the suggested script to create the symlinks. I then got the cvs hammer release of gcc as suggested on the 3.3 tree of the amodra ftp site. When I tried to build gcc (using the recommended config options), it died with the following error: make[2]: Entering directory `/ncgl/cfriesen/tools/gcc/gcc' for d in libgcc; do \ if [ -d $d ]; then true; else /bin/sh ./mkinstalldirs $d; fi; \ done if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi /ncgl/cfriesen/tools/gcc/gcc/xgcc -B/ncgl/cfriesen/tools/gcc/gcc/ -B/opt/ppc64/powerpc64-linux/bin/ -B/opt/ppc64/powerpc64-linux/lib/ -isystem /opt/ppc64/powerpc64-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -DNATIVE_CROSS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -mno-minimal-toc -fPIC -mlong-double-128 -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I. -I./. -I./config -I./../include -fPIC -mstrict-align -DL_muldi3 -c ./libgcc2.c -o libgcc/./_muldi3.o In file included from tconfig.h:23, from libgcc2.c:36: config/rs6000/linux64.h:588:20: signal.h: No such file or directory config/rs6000/linux64.h:590:26: sys/ucontext.h: No such file or directory make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/ncgl/cfriesen/tools/gcc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/ncgl/cfriesen/tools/gcc/gcc' make: *** [all-gcc] Error 2 I'm suspicious about the "-isystem /opt/ppc64/powerpc64-linux/include" part. That directory doesn't actually exist, so why is it trying to use it? Chris ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Thu Apr 29 08:24:12 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 29 Apr 2004 08:24:12 +1000 Subject: hvconsole.c : possible problem In-Reply-To: <8457B337-9921-11D8-AFB9-000A95A0560C@us.ibm.com> References: <1083128727.20089.57.camel@gaston> <8457B337-9921-11D8-AFB9-000A95A0560C@us.ibm.com> Message-ID: <1083191052.20092.79.camel@gaston> > Sorry, didn't follow that. The problem being solved is this: you do an > hvsi_read() and store 15 bytes into 'buf' as follows: > ff05000065 ff05000165 ff05000265 > (that's "AAA" in three packets). We just put all three of those packets > into a single ring buffer, so now we have to go back and copy two and > three into subsequent buffers. > > Another possibility is having an intermediary 256-byte buffer that we > read into, then copy from there into buffers. That would probably > simplify the code a bit, at the expense of always requiring at least > one memcpy (which is not the case now) even if we just get one packet. > I'll try that. Why ? You don't _have_ to read 16 bytes by 16 bytes, do you ? You can just read the right amount to fill the current packet header or data payload. Something like if (head_complete) size = remaining_data > 16 : 16 : remaining_data; else size = sizeof(header) - current_count; > > A much simpler loop basically, asking only as much is needed to fill > > the header if that isn't filled, then as much is needed to fill the > > data (maxed out at 16) until the packet is filled. That would allow > > to always deal only with packet boundaries, let throttling work > > properly > > at HV level, and simplify the code significantly... > > We don't get to ask for a specific number of bytes; we're told after we > have them (up to 16). I'm noticing that the '16' parameter you're > looking at is never used, and should be removed all the way back to > drivers/char/hvc_console.c. Ah, we always ask for 16 bytes... that I didn't get. Ok, then yes, use a static 16 bytes buffer, and then move data from there to packets and leave data in there if you have no packet available. The overflow logic is dodgy, you should be able to do a single nice loop. > > - There is historical hunt for null characters in hvterm_get_chars(), > > that paulus added because xmon was getting confused. Where do those > > NULL > > chars come from ? I doubt HV itself is adding anything to the stream so > > I suppose it's whatever console program sits at the other hand ? > > That must be the case, yeah. HVSI data passes through the HV in the > same way as normal console data, but if any munging occured there we > would be screwed. So it must be that java "vterm" on the HMC. > > > I'm > > asking because hvsi_read() doesn't do that, and so we end up with 2 > > routines having the exact same prototype: hvsi_read() and > > hvc_hvterm_get_chars(), both calling the same HV routine, but not > > doing exactly the same thing and I was wondering if this inconsistency > > was still necessary. > > I've verified that those NULLs do still appear in the normal case, if > that's what you mean. I have not seen any NULLs come through the HVSI > code and they would be pretty noticeable. That is consistent with the > vterm-did-it theory, and yes, that means we have different behavior. > > > - The whole wait_for_packet() is completely synchronous (doesn't > > schedule), that doesn't sound very good. > > True, hmm... I must have meant to come back to that later. > > I guess I'll find out, but is there a limit on how early you can call > schedule() during boot (like kmalloc)? wait_for_packet() is only used > during initialization which happens pretty early. If you are really concerned, then check system_state == SYSTEM_RUNNING Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From amodra at bigpond.net.au Thu Apr 29 11:06:24 2004 From: amodra at bigpond.net.au (Alan Modra) Date: Thu, 29 Apr 2004 10:36:24 +0930 Subject: problem building 64-bit gcc In-Reply-To: <409016F6.9000908@nortelnetworks.com> References: <409016F6.9000908@nortelnetworks.com> Message-ID: <20040429010624.GC31449@bubble.modra.org> On Wed, Apr 28, 2004 at 04:41:26PM -0400, Chris Friesen wrote: > config/rs6000/linux64.h:588:20: signal.h: No such file or directory > config/rs6000/linux64.h:590:26: sys/ucontext.h: No such file or directory There are various ways of overcoming the circular dependency between glibc and gcc. Probably the best one with current glibc sources is to configure glibc and run "make install-headers" before building gcc. Last time I checked, this didn't quite work, and I found I needed to create a dummy gnu/stubs.h. Bootstrapping tools from scratch is still a pain.. > I'm suspicious about the "-isystem /opt/ppc64/powerpc64-linux/include" > part. That directory doesn't > actually exist, so why is it trying to use it? It would exist if you had installed the required headers there. :) -- Alan Modra IBM OzLabs - Linux Technology Centre ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxiep at us.ibm.com Thu Apr 29 12:14:26 2004 From: lxiep at us.ibm.com (Linda Xie) Date: Wed, 28 Apr 2004 21:14:26 -0500 Subject: [PATH] rpaphp doesn't initialize slot's name Message-ID: <40906502.4070009@us.ibm.com> Hi Greg, This patch includes some changes that I missed when I cut php_phy_location.patch. It fixes the kernel crash when rpaphp is loaded because slot->name is not initialized. Please apply it to your tree. Thanks, Linda -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: php_phy_location_1.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040428/7fd86dd6/attachment.txt From dank at kegel.com Thu Apr 29 14:28:43 2004 From: dank at kegel.com (Dan Kegel) Date: Wed, 28 Apr 2004 21:28:43 -0700 Subject: problem building 64-bit gcc In-Reply-To: <20040429010624.GC31449@bubble.modra.org> References: <409016F6.9000908@nortelnetworks.com> <20040429010624.GC31449@bubble.modra.org> Message-ID: <4090847B.7060902@kegel.com> Alan Modra wrote: > On Wed, Apr 28, 2004 at 04:41:26PM -0400, Chris Friesen wrote: > >>config/rs6000/linux64.h:588:20: signal.h: No such file or directory >>config/rs6000/linux64.h:590:26: sys/ucontext.h: No such file or directory > > > There are various ways of overcoming the circular dependency between > glibc and gcc. Probably the best one with current glibc sources is > to configure glibc and run "make install-headers" before building > gcc. Last time I checked, this didn't quite work, and I found I needed > to create a dummy gnu/stubs.h. Bootstrapping tools from scratch is > still a pain.. Yup. That's why I wrote (and more or less maintain) crosstool. http://kegel.com/crosstool/crosstool-0.28-rc8.tar.gz seems to build gcc-3.4.0/glibc-2.3.2 powerpc64 ok finally. Say, could somebody here give it a try? Here's how: wget http://kegel.com/crosstool/crosstool-0.28-rc8.tar.gz tar -xzvf crosstool-0.28-rc8.tar.gz cd crosstool-0.28-rc8 lynx doc/crosstool-howto.html sudo mkdir /opt/crosstool sudo chown $USER /opt/crosstool sh demo-powerpc64.sh That should create a good toolchain (assuming the config file from linux-2.6.5's allnoconfig suffices; otherwise replace the sample config file linuxppc64.config). The path to the compiler would be /opt/crosstool/powerpc64-unknown-linux-gnu/gcc-3.4.0-glibc-2.3.2/bin/powerpc64-unknown-linux-gnu-gcc - Dan -- ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ananth at in.ibm.com Thu Apr 29 23:04:12 2004 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Thu, 29 Apr 2004 18:04:12 +0500 Subject: [PATCH] Compile kdb modules without error Message-ID: <20040429130412.GA2054@in.ibm.com> Hi Anton, Sometime during the linux-2.6.6-rc* series, both struct file and struct inode were changed. Some routines in kdb modules files depend on the structure elements that no longer exist. Inlined is a patch that circumvents this issue by disabling the routines that use the removed elements. Will need to sync with upstream once SGI releases a patch for the 2.6.6 series. (Will send another patch when one is available). This patch also contains updates to bring the "common" kdb code in ameslab up to date with the SGI released level (for 2.6.5). Please apply... Thanks, Ananth diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/arch/ppc64/kdb/kdba_bp.c ameslab/arch/ppc64/kdb/kdba_bp.c --- temp/ameslab/arch/ppc64/kdb/kdba_bp.c 2004-04-23 10:22:09.000000000 +0530 +++ ameslab/arch/ppc64/kdb/kdba_bp.c 2004-04-29 16:29:35.000000000 +0530 @@ -169,9 +169,9 @@ KDB_STATE_CLEAR(DOING_SSB); KDB_STATE_CLEAR(DOING_SS); } else { - char *argv[] = {"ssb", NULL}; + const char *argv[] = {"ssb", NULL}; rv = KDB_DB_SSB; /* Indicate ssb - dismiss immediately */ - kdb_ss(0, (char **)argv, NULL, ef); + kdb_ss(0, argv, NULL, ef); } } else { /* diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/drivers/char/sn_serial.c ameslab/drivers/char/sn_serial.c --- temp/ameslab/drivers/char/sn_serial.c 2004-04-23 10:22:35.000000000 +0530 +++ ameslab/drivers/char/sn_serial.c 2004-04-29 15:38:52.000000000 +0530 @@ -309,11 +309,13 @@ if (kdb_on) { if (ch == *kdb_serial_ptr) { if (!(*++kdb_serial_ptr)) { + spin_unlock_irqrestore(&sn_sal_lock, *flags); if (!regs) KDB_ENTER(); /* to get some registers */ else kdb(KDB_REASON_KEYBOARD, 0, regs); kdb_serial_ptr = (char *)kdb_serial_str; + spin_lock_irqsave(&sn_sal_lock, *flags); break; } } diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/include/linux/kdb.h ameslab/include/linux/kdb.h --- temp/ameslab/include/linux/kdb.h 2004-04-23 10:24:32.000000000 +0530 +++ ameslab/include/linux/kdb.h 2004-04-29 14:53:20.000000000 +0530 @@ -39,6 +39,7 @@ #include #include #include +#include #include #define KDB_MAJOR_VERSION 4 @@ -55,6 +56,7 @@ #else #define KDB_IS_RUNNING() (0) #endif /* CONFIG_KDB */ +extern atomic_t kdb_event; /* * kdb_on diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/kdb/ChangeLog ameslab/kdb/ChangeLog --- temp/ameslab/kdb/ChangeLog 2004-04-23 10:24:41.000000000 +0530 +++ ameslab/kdb/ChangeLog 2004-04-29 14:20:18.000000000 +0530 @@ -1,3 +1,33 @@ +2004-04-11 Keith Owens + + * Unlock sn_sal_lock before entering kdb from sn_serial. + * kdb v4.3-2.6.5-common-2. + +2004-04-05 Keith Owens + + * kdb v4.3-2.6.5-common-1. + +2004-03-22 Keith Owens + + * kdb v4.3-2.6.5-rc2-common-1. + +2004-03-12 Keith Owens + + * More work to avoid spurious messages from WARN_CONSOLE_UNLOCKED(). + * bh command bug fixes. Nathan Scott. + * kdb v4.3-2.6.4-common-1. + +2004-03-06 Keith Owens + + * Set KDB_IS_RUNNING() during kdb_init to avoid spurious messages from + WARN_CONSOLE_UNLOCKED(). + * Correct loss of symbol names in kdbnearsym. + * kdb v4.3-2.6.4-rc2-common-1. + +2004-02-29 Keith Owens + + * kdb v4.3-2.6.4-rc1-common-1. + 2004-02-21 Keith Owens * Correct build of kdb_cmds when using a separate object directory and @@ -841,562 +871,3 @@ * include/linux/kdbprivate.h: add kdb_initial_cpu. * include/linux/kdb.h: add kdb_on, bump version to kdb v1.4. -2002-11-02 Keith Owens - - * Upgrade to 2.5.45. - * Correct build without CONFIG_KDB. - * kdb v2.4-2.5.45-common-1. - -2002-11-01 Keith Owens - - * Sync with kdb v2.4-2.4.19-common-2. - * Add defcmd/endefcmd feature. - * Remove kdb_eframe_t. - * Clear bp data before using. - * Sanity check if we have pt_regs. - * Force LINES > 1. - * Remove special case for KDB_REASON_PANIC, use KDB_ENTER() instead. - * Remove kdba_getcurrentframe(). - * Coexist with O(1) scheduler. - * Add lines option to dmesg, speed up dmesg. - * Add selection critera to ps and bta commands. - * New man page, Documentation/kdb/kdb_sr.man. - * kdb v2.4-2.5.44-common-1. - -2002-10-25 Keith Owens - - * Move -fomit-frame-pointer after .config has been read. - * Upgrade to 2.5.44. - * kdb v2.3-2.5.44-common-1. - -2002-10-17 Keith Owens - - * Upgrade to 2.5.43. - * kdb v2.3-2.5.43-common-1. - -2002-10-14 Keith Owens - - * Upgrade to 2.5.42. - * kdb v2.3-2.5.42-common-1. - -2002-10-09 Keith Owens - - * Upgrade to 2.5.41. - * kdb v2.3-2.5.41-common-1. - -2002-10-04 Keith Owens - - * Minimize differences between patches for 2.4 and 2.5 kernels. - * Reduce stack usage. - * kdb v2.3-2.5.40-common-2. - -2002-10-03 Keith Owens - - * Upgrade to 2.5.40. - * kdb v2.3-2.5.40-common-1. - -2002-09-24 Keith Owens - - * Sync with kdb v2.3-2.4.19-common-2. - * Sync with 2.5.x-xfs (2.5.38). - * Replace kdb_port with kdb_serial to support memory mapped I/O. - David Mosberger. - * Remove individual SGI copyrights, the general SGI copyright applies. - * Handle md0. Reported by Hugh Dickins, different fix by Keith Owens. - * Use page_address() in kdbm_pg.c. Hugh Dickins. - * Remove debugging printk from kdbm_pg.c. Hugh Dickins. - * Move breakpoint address verification into arch dependent code. - * Dynamically resize kdb command table as required. - * Common code to support USB keyboard. Sebastien Lelarge. - Note: broken in 2.5 until somebody who understands USB can fix it. - * Add dmesg command. - * Clean up copyrights, Eric Sandeen. - * Syntax check mdWcN commands. - -2002-02-27 Keith Owens - - * Tom Duffy's kdb for 2.5.5. - * Sync with kdb v2.1-2.4.18-common-1. - * Correct kdbm_pg.c for non-highmem machines. - * kdb v2.1-2.5.5-common-1. - -2002-02-26 Keith Owens - - * Upgrade to 2.4.18. - * Add Paul Dorwin (IBM) magicpoint slides on using kdb as - Documentation/kdb/slides. - * kdb v2.1-2.4.18-common-1. - -2002-01-23 Keith Owens - - * Sync with XFS pagebuf changes. - * kdb v2.1-2.4.17-common-2. - -2002-01-18 Keith Owens - - * Ignore single stepping during panic. - * Remove kdba_getword, kdba_putword. Replace with kdb_getword, - kdb_putword that rely on copy_xx_user. The new functions return - an error code, like copy_xx_user. - * New functions kdb_getarea, kdb_putarea for copying areas of data - such as structures. These functions also return an error code. - * Change all common code to use the new functions. - * bp command checks that it can read and write the word at the - breakpoint before accepting the address. - * Break points are now set FIFO and cleared LIFO so overlapping - entries give sensible results. - * Verify address before disassembling code. - * Common changes for sparc64. Ethan Solomita, Tom Duffy. - * Remove ss , never supported. - * Remove kallsyms entries from arch vmlinux.lds files. - * Specify which commands auto repeat. - * kdb v2.1-2.4.17-common-1. - -2002-01-07 Keith Owens - - * Remove console semaphore code, not good in interrupt. - * Remove fragment of ia64 patch that had crept into kdb. - * Release as kdb v2.0-2.4.17-common-3. - -2002-01-04 Keith Owens - - * Sync xfs <-> kdb common code. - -2001-12-22 Keith Owens - - * Upgrade to 2.4.17. - * Clean up ifdef CONFIG_KDB. - * Add ifdef CONFIG_KDB around include kdb.h. - * Delete dummy kdb.h files for unsupported architectures. - * Delete arch i386 and ia64 specific files. This changelog now - applies to kdb common code only. - * Release as kdb v2.0-2.4.17-common-1. - -2001-12-03 Keith Owens - - * Upgrade to 2.4.16. - * Add include/asm-um/kdb.h stub to allow XFS to be tested under UML. - * Check if an interrupt frame on i386 came from user space. - * Out of scope bug fix in kdb_id.c. Ethan Solomita. - * Changes to common code to support sparc64. Ethan Solomita. - * Change GFP_KERNEL to GFP_ATOMIC in disasm. Ethan Solomita. - -2001-11-16 Keith Owens - - * Upgrade to 2.4.15-pre5. - * Wrap () around #define expressions with unary operators. - -2001-11-13 Keith Owens - - * Upgrade to 2.4.15-pre4. - * kbdm_pg.c patch from Hugh Dickins. - -2001-11-07 Keith Owens - - * Upgrade to 2.4.14-ia64-011105. - * Change name of l1 serial I/O routine, add ia64 init command. SGI. - * Sync kdbm_pg with XFS. - -2001-11-06 Keith Owens - - * Upgrade to kernel 2.4.14. - -2001-11-02 Keith Owens - - * Sync kdbm_pg.c with XFS. - -2001-10-24 Keith Owens - - * Upgrade to kernel 2.4.13. - -2001-10-14 Keith Owens - - * More use of TMPPREFIX in top level Makefile to speed up NFS compiles. - - * Correct repeat calculations in md/mds commands. - -2001-10-10 Keith Owens - - * Copy bfd.h and ansidecl.h to arch/$(ARCH)/kdb, remove dependecies on - user space includes. - - * Update kdb v1.9 to kernel 2.4.11. - -2001-10-01 Keith Owens - - * Update kdb v1.9 to kernel 2.4.11-pre1 and 2.4.10-ac1. - - * Correct loop in kdb_parse, reported by Tachino Nobuhiro. - -2001-09-25 Keith Owens - - * Update kdb v1.8 to kernel 2.4.10. - - * kdbm_pg patch from Hugh Dickens. - - * DProbes patch from Bharata B Rao. - - * mdWcn and mmW patch from Vamsi Krishna S. - - * i386 disasm layout patch from Jean-Marc Saffroy. - - * Work around for 64 bit binutils, Simon Munton. - - * kdb.mm doc correction by Chris Pascoe. - - * Enter repeats the last command, IA64 disasm only prints one - instruction. Don Dugger. - - * Allow kdb/modules to be linked into vmlinux. - - * Remove obsolete code from kdb/modules/kdbm_{pg,vm}.c. - - * Warn when commands are entered at more prompt. - - * Add MODULE_AUTHOR, DESCRIPTION, LICENSE. - - * Release as kdb v1.9. - -2001-02-27 Keith Owens - - * Update kdb v1.8 to kernel 2.4.2, sync kdb/modules with XFS. - - * Hook into panic() call. - -2000-12-18 Keith Owens - - * Update kdb v1.7 to kernel 2.4.0-test13-pre3, sync kdb/modules with - XFS. - -2000-11-18 Keith Owens - - * Update to kernel 2.4.0-test11-pre7, including forward port of - bug fixes from WIP 2.4.0-test9 tree. - - * Update to Cygnus CVS trees for disassembly code. - - * Bump to kdb v1.6. - -2000-10-19 Keith Owens - - * Update to kernel 2.4.0-test10-pre4. - -2000-10-15 Keith Owens - - * kdb/kdbmain.c (kdb_parse): Correctly handle blank input. - - * kdb/kdbmain.c (kdb_local, kdb): Reason SILENT can have NULL regs. - -2000-10-13 Keith Owens - - * kdb/kdbmain.c: Reduce CMD_LEN to avoid overflowing kdb_printf buffer. - -2000-10-11 Keith Owens - - * kdb/kdbmain.c (kdb): Test for userspace breakpoints before driving - other cpus into kdb. Speeds up gdb and avoids SMP race. - - * arch/i386/kdb/kdba_io.c (get_serial_char, get_kbd_char): Ignore - unprintable characters. - - * arch/i386/kdb/kdba_io.c (kdba_read): Better handling of buffer size. - -2000-10-04 Keith Owens - - * arch/i386/kdb/kdba_bt.c (kdba_bt_process): Verify that esp is inside - task_struct. Original patch by Mike Galbraith. - - * kdb/kdb_io.c (kdb_getstr): Reset output line counter, remove - unnecessary prompts. - - * arch/i386/kdb/kdbasupport.c (kdb_getregcontents): Change " cs" to - "xcs", ditto ss, ds, es. gdb2kdb does not like leading spaces. - - * include/asm-xxx/kdb.h: Add dummy kdb.h for all architectures except - ix86. This allows #include to appear in arch independent - code without causing compile errors. - - * kdb/modules/kdbm_pg: Sync with XFS. - -2000-10-03 Keith Owens - - * kdb/kdb_io.c (kdb_read): Ignore NMI while waiting for input. - - * kdb/kdb_io.c, kdb/Makefile: Export kdb_read. - -2000-10-02 Keith Owens - - * arch/i386/kernel/smpboot.c (do_boot_cpu): Set nmi_watchdog_source to 2 - to avoid premature NMI oops during cpu bring up. We have to assume that - a box with more than 1 cpu has a working IO-APIC. - - * Documentation/kdb/{kdb.mm,kdb_md.man}: Add mdr command. - - * kdb/kdbmain.c (kdb_md): Add mdr command. - - * Release as kdb v1.5 against 2.4.0-test9-pre8. - - * arch/i386/kdb/kdba_io.c, arch/i386/kdb/kdbasupport.c, kdb/kdbmain.c, - kdb/kdb_io.c, kdb/kdb_id.c: Remove zero initializers for static - variables. - -2000-09-28 Keith Owens - - * various: Add nmi_watchdog_source, 1 local APIC, 2 IO-APIC. - Test nmi_watchdog_source instead of nr_ioapics so UP works on SMP hardware. - - * arch/i386/kernel/io_apic.c: Rename setup_nmi to setup_nmi_io for clarity. - - * kdb/kdbmain.c (kdb_parse): Only set NO_WATCHDOG if it was already set. - - * kdb/kdbmain.c (kdb): Clear NO_WATCHDOG on all exit paths. - - * include/linux/kdb.h: Add KDB_REASON_SILENT. - - * kdb/kdbmain.c (kdb_local): Treat reason SILENT as immediate 'go'. - - * kdb/kdbmain.c (kdb_init): Invoke kdb with reason SILENT to instantiate - any breakpoints on boot cpu. - - * arch/i386/kernel/smpboot.c (smp_callin): Invoke kdb with reason SILENT - to instantiate any global breakpoints on this cpu. - - * kdb/kdb_cmds: Remove comment that said initial commands only worked on - boot cpu. - -2000-09-27 Keith Owens - - * arch/i386/kernel/msr.c: Move {rd,wr}msr_eio to include/asm-i386/apic.h. - - * include/asm-i386/apic.h: Define NMI interfaces. - - * kernel/sysctl.c (kern_table): - * kernel/sysctl.c (do_proc_set_nmi_watchdog): - Add /proc/sys/kernel/nmi_watchdog. - - * arch/i386/kernel/apic.c: New routines set_nmi_counter_local, - setup_apic_nmi_watchdog. - - * arch/i386/kernel/traps.c: New routine set_nmi_watchdog(). Call apic - routines to set/clear local apic timer. - -2000-09-26 Keith Owens - - * include/linux/sysctl.h (enum): Add NMI_WATCHDOG. - - * arch/i386/kernel/traps.c (nmi_watchdog_tick): Check nmi_watchdog is - still on. - - * arch/i386/config.in: Add CONFIG_UP_NMI_WATCHDOG. - - * Documentation/Configure.help: Add CONFIG_UP_NMI_WATCHDOG. - - * Documentation/nmi_watchdog.txt: Update for UP NMI watchdog. - -2000-09-25 Keith Owens - - * arch/i386/kernel/apic.c (init_apic_mappings): - * arch/i386/kernel/io_apic.c (IO_APIC_init_uniprocessor): - Merge Keir Fraser's local APIC for uniprocessors patch. - -2000-09-24 Keith Owens - - * Various: Declare initialization routines as __init. - - * Makefile: Define and export AWK. - - * kdb/Makefile: Generate gen-kdb_cmds.c from kdb/kdb_cmds. - - * kdb/kdbmain.c (kdb_init): Call new routine kdb_cmds_init to execute - whatever the user put in kdb/kdb_cmds. - - * arch/i386/kdb/kdba_bt.c (kdba_bt_stack): New parameter to - indicate if esp in regs is known to be valid or not. - - * kdb/kdb_bp.c, arch/i386/kdb/kdba_bp.c: More trace prints for - breakpoint handling. - - * arch/i386/kdb/kdba_bp.c (kdba_installbp): Finally found and fixed the - annoying breakpoint bug where breakpoints where not always installed - after 'go'. - - * Documentation/kdb: Update man pages kdb.mm, kdb_env.man, kdb_ss.man. - - * Released as kdb-v1.5-beta1-2.4.0-test8. - - * Sync to 2.4.0-test9-pre6 and release as kdb-v1.5-beta1-2.4.0-test9-pre6. - -2000-09-23 Keith Owens - - * arch/i386/kdb/kdbasupport.c (kdba_getregcontents): New pseudo - registers cesp and ceflags to help with debugging the debugger. - - * kdb/kdbmain.c (kdb_local, kdb): Add KDB_REASON_RECURSE. Add - environment variable RECURSE. Add code to cope with some types of - recursion. - - * kdb/kdbmain.c (kdb), arch/i386/kdba/kdba_bp.c: Add - kdba_clearsinglestep. - -2000-09-22 Keith Owens - - * drivers/video/vgacon.c (write_vga): No cli() if kdb is running, avoid - console deadlock. - - * arch/i386/kernel/irq.c (get_irqlock): Warn if kdb is running, may hang. - - * include/linux/kdb.h: Define KDB_IS_RUNNING as (0) if no CONFIG_KDB. - - * arch/i386/kdb/kdba_bt.c (kdba_bt_stack): Do not attempt a backtrace if - the code segment is not in the kernel. - - * kdb/modules: Change modules from MX_OBJS to M_OBJS. Remove EXPORT_NOSYMBOLS. - -2000-09-21 Keith Owens - - * arch/i386/kernel/i386_ksyms.c: Move EXPORT_SYMBOLS for kdb to kdb/kdbmain.c. - - * kdb/Makefile: Change kdb/kdbmain.o from O_OBJS to OX_OBJS. - - * arch/i386/kernel/smp.c: Remove some #ifdef CONFIG_KDB. Remove kdbprivate.h. - - * include/linux/kdb.h: Add kdb_print_state. Add KDB_STATE_WAIT_IPI. - - * kdb/kdbmain.c (kdb): Only mark cpu as leaving if it is in KDB state. Maintain - WAIT_IPI state so a cpu is only driven through NMI once. - - * arch/i386/kernel/smp.c (smp_kdb_stop): All state fiddling moved to kdb(). - -2000-09-20 Keith Owens - - * include/linux/kdb.h: #define kdb() as (0) if kdb is not configured. - - * arch/i386/kernel/traps.c: Remove some #ifdef CONFIG_KDB. - - * include/linux/kdbprivate.h: Move per cpu state to kdb.h. - - * include/linux/kdb.h: Add KDB_STATE_NO_WATCHDOG, KDB_STATE_PRINTF_LOCK. - Rename KDB_DEBUG_xxx to KDB_DEBUG_FLAG_xxx. Clean up debug flag - definitions. - - * arch/i386/kernel/traps.c (nmi_watchdog_tick): Check no watchdog. - - * kdb/kdbmain.c (kdb): Set no watchdog in normal kdb code. - - * kdb/kdbmain.c (kdb_parse): Allow watchdog in commands. - - * kdb/kdb_io.c (kdb_printf): No watchdog during printing. Clean up lock handling. - - * kdb/kdbmain.c (kdb_set): Clean up debug flag handling. - -2000-09-19 Juan J. Quintela - - * kdb/arch/i386/kdb/kdba_io.c: Allow kdb to compile without CONFIG_VT and/or - serial console. - -2000-09-19 Keith Owens - - * include/linux/kdb.h: Define KDB_DEBUG_STATE(). - - * kdb/kdbmain.c (kdb): Add kdb_print_state(), calls to KDB_DEBUG_STATE(). - -2000-09-16 Keith Owens - - * Move to finer grained control over individual processors in kdb with - per cpu kdb state. Needed to allow ss[b] to only release one processor, - previously ss[b] released all processors. Also need to recover from - errors inside kdb commands, e.g. oops in kdbm_pg code. - - * various: - Move global flags KDB_FLAG_SSB, KDB_FLAG_SUPRESS, KDB_FLAG_FAULT, - KDB_FLAG_SS, KDB_FLAG_SSBPT, kdb_active, to per cpu state and macros - KDB_STATE(xxx). - Replace kdb_flags & KDB_FLAG_xxx with KDB_FLAG(xxx). - Replace kdb_flags & KDB_DEBUG_xxx with KDB_DEBUG(xxx). - Replace specific tests with wrapper KDB_IS_RUNNING(). - - * various: Remove #ifdef CONFIG_SMP from kdb code wherever - possible. Simplifies the code and makes it much more readable. - - * arch/i386/kdb/kdbasupport.c (kdb_setjmp): Record if we have reliable - longjmp data instead of assuming it is always set. - - * various: Replace smp_kdb_wait with per cpu state, HOLD_CPU. - - * init/main.c : Replace #ifdef KDB_DEBUG with KDB_DEBUG(CALLBACK). - - * include/linux/kdbprivate.h: Separate command return codes from error - codes. Add more detailed command codes. - - * arch/i386/kernel/traps.c (die): Change spin_lock_irq to - spin_lock_irqsave. Why did I do this? - - * kdb/kdbmain.c (kdb_parse): Set per cpu flag CMD before executing kdb - command. More detailed return codes for commands that affect - processors. - - * kdb/kdbmain.c (kdb_previous_event): New, check if any processors are - still executing the previous kdb event. Removes a race window where a - second event could enter kdb before the first had completely ended. - - * kdb/kdbmain.c (kdb): Document all the concurrency conditions and how - kdb handles them. ss[b] now releases only the current cpu. Do not set - breakpoints when releasing for ss[b]. Recover from errors in kdb - commands. Check that we have reliable longjmp data before using it. - - * various: Update return code documentation. - - * kdb/kdb_bp.c (kdb_ss): Separate ss and ssb return codes. - - * kdb/kdbsupport.c (kdb_ipi): Finer grained algorithm for deciding - whether to call send a stop signal to a cpu. - - * arch/i386/kdb/kdba_bp.c (kdba_db_trap): Separate ss and ssb return - codes. Reinstall delayed software breakpoints per cpu instead of - globally. Changed algorithm for handling ss[b]. - - * arch/i386/kdb/kdba_bp.c (kdba_bp_trap): Match software breakpoints per - cpu instead of globally. - - * include/linux/kdb.h: Bump version to kdb v1.5. - -2000-09-16 Keith Owens - - * kernel/sysctl.c (kern_table): add /proc/sys/kernel/kdb. - - * init/main.c (parse_options): add boot flags kdb=on, kdb=off, - kdb=early. - - * include/linux/sysctl.h (enum): add KERN_KDB. - - * drivers/char/serial.c (receive_chars): check kdb_on. - - * drivers/char/keyboard.c (handle_scancode): check kdb_on. - - * arch/i386/kernel/traps.c (nmi_watchdog_tick): check kdb_on. - - * arch/i386/config.in: add CONFIG_KDB_OFF. - - * Documentation/Configure.help: add CONFIG_KDB_OFF. - - * kdb/kdbmain.c: add kdb_initial_cpu, kdb_on. - - * kdb/kdbmain.c (kdb): check kdb_on, set kdb_initial_cpu. - - * kdb/kdbmain.c (kdb_init): add Keith Owens to kdb banner. - - * kdb/kdb_io.c (kdb_printf): serialize kdb_printf output. - - * kdb/kdb_bt.c (kdb_bt): check environment variable BTAPROMPT. - - * kdb/kdbsupport.c (kdb_ipi): ignore NMI for kdb_initial_cpu. - - * kdb/modules/kdbm_pg.c (kdbm_page): merge updates from 2.4.0-test5-xfs. - - * kdb/kdb_bt.man: add btp, bta, BTAPROMPT. - - * kdb/kdb.mm: add CONFIG_KDB_OFF, boot flags, btp, bta. - - * include/linux/kdbprivate.h: add kdb_initial_cpu. - - * include/linux/kdb.h: add kdb_on, bump version to kdb v1.4. diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/kdb/gen-kdb_cmds.c ameslab/kdb/gen-kdb_cmds.c --- temp/ameslab/kdb/gen-kdb_cmds.c 2004-04-23 10:24:41.000000000 +0530 +++ ameslab/kdb/gen-kdb_cmds.c 1970-01-01 05:30:00.000000000 +0530 @@ -1,4 +0,0 @@ -#include -char __initdata *kdb_cmds[] = { - 0 -}; diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/kdb/kdb_cmds ameslab/kdb/kdb_cmds --- temp/ameslab/kdb/kdb_cmds 2004-04-23 10:24:41.000000000 +0530 +++ ameslab/kdb/kdb_cmds 2004-04-29 14:20:18.000000000 +0530 @@ -4,9 +4,3 @@ # registers) are not reliable this early. set and bp commands should # be safe. Global breakpoint commands affect each cpu as it is booted. -# Initial commands for kdb, alter to suit your needs. -# These commands are executed in kdb_init() context, no SMP, no -# processes. Commands that require process data (including stack or -# registers) are not reliable this early. set and bp commands should -# be safe. Global breakpoint commands affect each cpu as it is booted. - diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/kdb/kdb_io.c ameslab/kdb/kdb_io.c --- temp/ameslab/kdb/kdb_io.c 2004-04-23 10:24:41.000000000 +0530 +++ ameslab/kdb/kdb_io.c 2004-04-29 14:20:19.000000000 +0530 @@ -498,6 +498,7 @@ KDB_STATE_SET(PRINTF_LOCK); spin_lock(&kdb_printf_lock); got_printf_lock = 1; + atomic_inc(&kdb_event); } diag = kdbgetintenv("LINES", &linecount); @@ -597,6 +598,7 @@ got_printf_lock = 0; spin_unlock(&kdb_printf_lock); KDB_STATE_CLEAR(PRINTF_LOCK); + atomic_dec(&kdb_event); } if (do_longjmp) #ifdef KDB_HAVE_LONGJMP diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/kdb/kdbmain.c ameslab/kdb/kdbmain.c --- temp/ameslab/kdb/kdbmain.c 2004-04-23 10:24:42.000000000 +0530 +++ ameslab/kdb/kdbmain.c 2004-04-29 14:42:51.000000000 +0530 @@ -69,6 +69,7 @@ */ volatile int kdb_flags; volatile int kdb_enter_debugger; +atomic_t kdb_event; /* * kdb_lock protects updates to kdb_initial_cpu. Used to @@ -219,7 +220,7 @@ * with '\' in strings. CML2 would have been able to do it but we lost CML2. * KAO. */ -// const char kdb_serial_str[] = "\001"; +/* const char kdb_serial_str[] = "\001"; */ const char kdb_serial_str[] = "startKDB"; /* @@ -1678,9 +1679,10 @@ { kdb_intstate_t int_state; /* Interrupt state */ kdb_reason_t reason2 = reason; - int result = 1; /* Default is kdb handled it */ + int result = 0; /* Default is kdb did not handle it */ int ss_event; kdb_dbtrap_t db_result=KDB_DB_NOBPT; + atomic_inc(&kdb_event); switch(reason) { case KDB_REASON_OOPS: @@ -1699,7 +1701,7 @@ KDB_FLAG_SET(ONLY_DO_DUMP); } if (!kdb_on && !KDB_FLAG(ONLY_DO_DUMP)) - return 0; + goto out; KDB_DEBUG_STATE("kdb 1", reason); KDB_STATE_CLEAR(SUPPRESS); @@ -1730,7 +1732,7 @@ if ((reason == KDB_REASON_BREAK || reason == KDB_REASON_DEBUG) && db_result == KDB_DB_NOBPT) { KDB_DEBUG_STATE("kdb 2", reason); - return 0; /* Not one of mine */ + goto out; /* Not one of mine */ } /* Turn off single step if it was being used */ @@ -1807,12 +1809,12 @@ } if (!recover) { kdb_printf(" Cannot recover, allowing event to proceed\n"); - return(0); + goto out; } } } else if (!KDB_IS_RUNNING()) { kdb_printf("kdb: CPU switch without kdb running, I'm confused\n"); - return(0); + goto out; } /* @@ -1982,7 +1984,9 @@ KDB_STATE_CLEAR(RECURSE); KDB_STATE_CLEAR(LEAVING); /* No more kdb work after this */ KDB_DEBUG_STATE("kdb 17", reason); - return(result != 0); +out: + atomic_dec(&kdb_event); + return result != 0; } /* @@ -3475,6 +3479,7 @@ void __init kdb_init(void) { + kdb_initial_cpu = smp_processor_id(); /* * This must be called before any calls to kdb_printf. */ @@ -3501,7 +3506,8 @@ if (!kdbjmpbuf) printk(KERN_ERR "Cannot allocate kdbjmpbuf, no kdb recovery will be possible\n"); #endif /* KDB_HAVE_LONGJMP */ - + + kdb_initial_cpu = -1; } int kdb_getuserarea_size(void *to, unsigned long from, size_t size); diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/kdb/kdbsupport.c ameslab/kdb/kdbsupport.c --- temp/ameslab/kdb/kdbsupport.c 2004-04-23 10:24:42.000000000 +0530 +++ ameslab/kdb/kdbsupport.c 2004-04-29 14:20:19.000000000 +0530 @@ -162,7 +162,8 @@ unsigned long symbolsize; unsigned long offset; static char *knt[100]; /* kdb name table, arbitrary size */ - char *knt1 = kmalloc(128, GFP_ATOMIC); +#define knt1_size 128 /* must be >= kallsyms table size */ + char *knt1 = kmalloc(knt1_size, GFP_ATOMIC); if (!knt1) { kdb_printf("kdbnearsym: addr=0x%lx cannot kmalloc knt1\n", addr); @@ -176,10 +177,21 @@ symtab->sym_name = kallsyms_lookup(addr, &symbolsize , &offset, (char **)(&symtab->mod_name), knt1); symtab->sym_start = addr - offset; symtab->sym_end = symtab->sym_start + symbolsize; - ret = (symtab->sym_name != 0); + ret = symtab->sym_name != NULL && *(symtab->sym_name) != '\0'; - if (symtab->sym_name) { + if (ret) { int i; + /* Another 2.6 kallsyms "feature". Sometimes the sym_name is + * set but the buffer passed into kallsyms_lookup is not used, + * so it contains garbage. The caller has to work out which + * buffer needs to be saved. + * + * What was Rusty smoking when he wrote that code? + */ + if (symtab->sym_name != knt1) { + strncpy(knt1, symtab->sym_name, knt1_size); + knt1[knt1_size-1] = '\0'; + } for (i = 0; i < ARRAY_SIZE(knt); ++i) { if (knt[i] && strcmp(knt[i], knt1) == 0) break; @@ -191,6 +203,7 @@ kfree(knt1); knt1 = knt[i]; memcpy(knt+i, knt+i+1, sizeof(knt[0])*(ARRAY_SIZE(knt)-i-1)); + i = ARRAY_SIZE(knt) - 1; } knt[i] = knt1; symtab->sym_name = knt[i]; diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/kdb/modules/kdbm_pg.c ameslab/kdb/modules/kdbm_pg.c --- temp/ameslab/kdb/modules/kdbm_pg.c 2004-04-23 10:24:42.000000000 +0530 +++ ameslab/kdb/modules/kdbm_pg.c 2004-04-29 15:55:03.000000000 +0530 @@ -118,7 +118,7 @@ kdb_printf(" bno %llu size %d dev 0x%x\n", (unsigned long long)bh.b_blocknr, bh.b_size, - bh.b_bdev->bd_dev); + bh.b_bdev ? bh.b_bdev->bd_dev : 0); kdb_printf(" count %d state 0x%lx [%s]\n", bh.b_count.counter, bh.b_state, map_flags(bh.b_state, bh_state_vals)); @@ -181,9 +181,12 @@ return(diag); kdb_printf("struct page at 0x%lx\n", addr); - kdb_printf(" next 0x%p prev 0x%p addr space 0x%p index %lu (offset 0x%x)\n", +/* kdb_printf(" next 0x%p prev 0x%p addr space 0x%p index %lu (offset 0x%x)\n", page.list.next, page.list.prev, page.mapping, page.index, - (int)(page.index << PAGE_CACHE_SHIFT)); + (int)(page.index << PAGE_CACHE_SHIFT)); */ + kdb_printf(" addr space 0x%p index %lu (offset 0x%x)\n", + page.mapping, page.index, + (int)(page.index << PAGE_CACHE_SHIFT)); kdb_printf(" count %d flags %s\n", page.count.counter, page_flags(page.flags)); kdb_printf(" virtual 0x%p\n", page_address((struct page *)addr)); @@ -273,7 +276,7 @@ return 0; } - +/* routine not used currently.. sync with upstream later static void do_buffer(unsigned long addr) { @@ -286,7 +289,9 @@ (unsigned long long)bh.b_blocknr, map_flags(bh.b_state, bh_state_vals)); } +*/ +/* inode_struct changed in 2.6.6-rc series.. sync with upstream later static int kdbm_inode_pages(int argc, const char **argv, const char **envp, struct pt_regs *regs) @@ -386,6 +391,7 @@ kfree(ap); return diag; } +*/ static int kdbm_inode(int argc, const char **argv, const char **envp, @@ -566,7 +572,8 @@ kdb_register("inode", kdbm_inode, "", "Display inode", 0); kdb_register("sb", kdbm_sb, "", "Display super_block", 0); kdb_register("bh", kdbm_buffers, "", "Display buffer", 0); - kdb_register("inode_pages", kdbm_inode_pages, "", "Display pages in an inode", 0); +/* inode struct changed in 2.6.6-rc series.. sync with upstream later + kdb_register("inode_pages", kdbm_inode_pages, "", "Display pages in an inode", 0); */ kdb_register("req", kdbm_request, "", "dump request struct", 0); kdb_register("rqueue", kdbm_rqueue, "", "dump request queue", 0); #if defined(CONFIG_X86) | defined(CONFIG_PPC64) diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/kdb/modules/kdbm_task.c ameslab/kdb/modules/kdbm_task.c --- temp/ameslab/kdb/modules/kdbm_task.c 2004-04-23 10:24:42.000000000 +0530 +++ ameslab/kdb/modules/kdbm_task.c 2004-04-29 14:21:07.000000000 +0530 @@ -71,7 +71,7 @@ int nextarg; int e = 0; struct task_struct *tp = NULL; - + if (argc != 1) return KDB_ARGCOUNT; @@ -146,7 +146,7 @@ int e = 0; int i; char fmt[32]; - + if (argc != 1) return KDB_ARGCOUNT; @@ -186,7 +186,7 @@ { kdb_register("task", kdbm_task, "", "Display task_struct", 0); kdb_register("sigset", kdbm_sigset, "", "Display sigset_t", 0); - + return 0; } diff -Naur --exclude=BitKeeper --exclude=SCCS temp/ameslab/kernel/kallsyms.c ameslab/kernel/kallsyms.c --- temp/ameslab/kernel/kallsyms.c 2004-04-23 10:24:42.000000000 +0530 +++ ameslab/kernel/kallsyms.c 2004-04-29 15:36:13.000000000 +0530 @@ -39,7 +39,13 @@ static inline int is_kernel_text(unsigned long addr) { - if (addr >= (unsigned long)_stext && addr <= (unsigned long)_etext) + if (addr >= (unsigned long)_stext && addr <= +#ifdef CONFIG_KDB + (unsigned long)_end +#else + (unsigned long)_edata +#endif + ) return 1; return 0; } ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Fri Apr 30 00:35:06 2004 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Thu, 29 Apr 2004 09:35:06 -0500 Subject: problem building 64-bit gcc In-Reply-To: <4090847B.7060902@kegel.com> References: <409016F6.9000908@nortelnetworks.com> <20040429010624.GC31449@bubble.modra.org> <4090847B.7060902@kegel.com> Message-ID: <68E036EA-99EA-11D8-A88A-000A95A0560C@us.ibm.com> On Apr 28, 2004, at 11:28 PM, Dan Kegel wrote: > > Yup. That's why I wrote (and more or less maintain) crosstool. > http://kegel.com/crosstool/crosstool-0.28-rc8.tar.gz seems to build > gcc-3.4.0/glibc-2.3.2 powerpc64 ok finally. That's great news, I didn't know crosstool worked for ppc64. I know that Janis Johnson has been writing her own crosstool-based scripts for ppc64 at ftp://ftp.linuxppc64.org/pub/people/janis ... maybe you two should chat. :) > Say, could somebody here give it a try? Here's how: > > wget http://kegel.com/crosstool/crosstool-0.28-rc8.tar.gz > tar -xzvf crosstool-0.28-rc8.tar.gz > cd crosstool-0.28-rc8 > lynx doc/crosstool-howto.html > sudo mkdir /opt/crosstool > sudo chown $USER /opt/crosstool > sh demo-powerpc64.sh There is no demo-powerpc64.sh, but there is demo-ppc970.sh that seems to be 64-bit. Anyways I ran that and shortly afterwards I get this: + cat patch9585.log patching file gas/read.c + egrep -q '^No file to patch. Skipping patch.|^Hunk .* FAILED at' patch9585.log + rm -f patch9585.log + test -f /home/hollis/crosstool-0.28-rc8/patches/binutils-2.15.90.0.3/binutils- sh-relocs.patch + patch -g0 --fuzz=1 -p1 -f + cat patch9585.log patching file bfd/elf32-sh.c Hunk #1 FAILED at 6497. 1 out of 1 hunk FAILED -- saving rejects to file bfd/elf32-sh.c.rej + abort 'patch /home/hollis/crosstool-0.28-rc8/patches/binutils-2.15.90.0.3/binutils- sh-relocs.patch failed' -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From dank at kegel.com Fri Apr 30 01:09:02 2004 From: dank at kegel.com (Dan Kegel) Date: Thu, 29 Apr 2004 08:09:02 -0700 Subject: problem building 64-bit gcc In-Reply-To: <68E036EA-99EA-11D8-A88A-000A95A0560C@us.ibm.com> References: <409016F6.9000908@nortelnetworks.com> <20040429010624.GC31449@bubble.modra.org> <4090847B.7060902@kegel.com> <68E036EA-99EA-11D8-A88A-000A95A0560C@us.ibm.com> Message-ID: <40911A8E.6030304@kegel.com> Hollis Blanchard wrote: >> Say, could somebody here give it a try? Here's how: >> >> wget http://kegel.com/crosstool/crosstool-0.28-rc8.tar.gz >> tar -xzvf crosstool-0.28-rc8.tar.gz >> cd crosstool-0.28-rc8 >> lynx doc/crosstool-howto.html >> sudo mkdir /opt/crosstool >> sudo chown $USER /opt/crosstool >> sh demo-powerpc64.sh > > > There is no demo-powerpc64.sh, but there is demo-ppc970.sh that seems > to be 64-bit. d'oh, thanks, I'll fix that. > Anyways I ran that and shortly afterwards I get this: > > /home/hollis/crosstool-0.28-rc8/patches/binutils-2.15.90.0.3/binutils- > sh-relocs.patch failed' Silly error on my part. Download again, I fixed it just before reading your mail. Thanks, Dan -- ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From dank at kegel.com Fri Apr 30 01:13:15 2004 From: dank at kegel.com (Dan Kegel) Date: Thu, 29 Apr 2004 08:13:15 -0700 Subject: problem building 64-bit gcc In-Reply-To: <68E036EA-99EA-11D8-A88A-000A95A0560C@us.ibm.com> References: <409016F6.9000908@nortelnetworks.com> <20040429010624.GC31449@bubble.modra.org> <4090847B.7060902@kegel.com> <68E036EA-99EA-11D8-A88A-000A95A0560C@us.ibm.com> Message-ID: <40911B8B.50004@kegel.com> Hollis Blanchard wrote: > On Apr 28, 2004, at 11:28 PM, Dan Kegel wrote: > >> >> Yup. That's why I wrote (and more or less maintain) crosstool. >> http://kegel.com/crosstool/crosstool-0.28-rc8.tar.gz seems to build >> gcc-3.4.0/glibc-2.3.2 powerpc64 ok finally. > > > That's great news, I didn't know crosstool worked for ppc64. I know > that Janis Johnson has been writing her own crosstool-based scripts for > ppc64 at ftp://ftp.linuxppc64.org/pub/people/janis ... maybe you two > should chat. :) It looks like she's addressing the biarch question which I've been avoiding. Maybe I'll follow her lead on that. Thanks for the link! - Dan -- ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Fri Apr 30 02:50:52 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 29 Apr 2004 11:50:52 -0500 Subject: [PATH] rpaphp doesn't initialize slot's name In-Reply-To: <40906502.4070009@us.ibm.com>; from lxiep@us.ibm.com on Wed, Apr 28, 2004 at 09:14:26PM -0500 References: <40906502.4070009@us.ibm.com> Message-ID: <20040429115052.Y58706@forte.austin.ibm.com> Hi Linda, I don't know if your patch fixes this, but during a boot of mondays (26 april) ameslab kernel, I got the following in dmesg. Is this a know problem? perchance you patch fixes this? After boot, the system seemd to operate, well, almost normally (it crashed for an unrelated reason). --linas pci_hotplug: PCI Hot Plug PCI Core version: 0.5 rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 rpaphp: Slot [](bus_id=0002:00:02.0) registered kobject_register failed for (-17) Call Trace: [c0000000002383ac] .pci_hp_register+0x88/0x104 [c00000000023a9f0] .register_slot+0x3c/0x13c [c00000000023a39c] .register_pci_slot+0x80/0x8c [c0000000002391c8] .rpaphp_add_slot+0x180/0x230 [c0000000002392a4] .init_slots+0x2c/0x4c [c000000000239300] .init_rpa+0x3c/0x74 [c000000000571be4] .do_initcalls+0x60/0x124 [c00000000000c590] .init+0x9c/0x1f8 [c000000000019284] .kernel_thread+0x4c/0x68 pci_hotplug: Unable to register kobject<3>rpaphp: pci_hp_register failed with error -22 kobject_register failed for (-17) Call Trace: [c0000000002383ac] .pci_hp_register+0x88/0x104 [c00000000023a9f0] .register_slot+0x3c/0x13c [c00000000023a39c] .register_pci_slot+0x80/0x8c [c0000000002391c8] .rpaphp_add_slot+0x180/0x230 [c0000000002392a4] .init_slots+0x2c/0x4c [c000000000239300] .init_rpa+0x3c/0x74 [c000000000571be4] .do_initcalls+0x60/0x124 [c00000000000c590] .init+0x9c/0x1f8 [c000000000019284] .kernel_thread+0x4c/0x68 pci_hotplug: Unable to register kobject<3>rpaphp: pci_hp_register failed with error -22 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Fri Apr 30 06:52:59 2004 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Thu, 29 Apr 2004 15:52:59 -0500 Subject: problem building 64-bit gcc In-Reply-To: <40911A8E.6030304@kegel.com> References: <409016F6.9000908@nortelnetworks.com> <20040429010624.GC31449@bubble.modra.org> <4090847B.7060902@kegel.com> <68E036EA-99EA-11D8-A88A-000A95A0560C@us.ibm.com> <40911A8E.6030304@kegel.com> Message-ID: <331E3C4A-9A1F-11D8-A88A-000A95A0560C@us.ibm.com> On Apr 29, 2004, at 10:09 AM, Dan Kegel wrote: > > Silly error on my part. Download again, I fixed it just before reading > your mail. One more glitch: testhello.sh tried to exec the cross g++ even though I only built gcc. Aside from that, the build completed successfully and I'll have to try it out in a bit. :) -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From cfriesen at nortelnetworks.com Fri Apr 30 07:01:02 2004 From: cfriesen at nortelnetworks.com (Chris Friesen) Date: Thu, 29 Apr 2004 17:01:02 -0400 Subject: problem building 64-bit gcc In-Reply-To: <331E3C4A-9A1F-11D8-A88A-000A95A0560C@us.ibm.com> References: <409016F6.9000908@nortelnetworks.com> <20040429010624.GC31449@bubble.modra.org> <4090847B.7060902@kegel.com> <68E036EA-99EA-11D8-A88A-000A95A0560C@us.ibm.com> <40911A8E.6030304@kegel.com> <331E3C4A-9A1F-11D8-A88A-000A95A0560C@us.ibm.com> Message-ID: <40916D0E.5000009@nortelnetworks.com> Hollis Blanchard wrote: > On Apr 29, 2004, at 10:09 AM, Dan Kegel wrote: > >> >> Silly error on my part. Download again, I fixed it just before reading >> your mail. > > > One more glitch: testhello.sh tried to exec the cross g++ even though I > only built gcc. Aside from that, the build completed successfully and > I'll have to try it out in a bit. :) > I'm currently building. There are a bunch of busted dependencies (ie it is possible to use menuconfig to construct a .config that will not build). After weeding those out, I have something that compiles. Whether it will boot or not... Chris ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Fri Apr 30 07:05:05 2004 From: greg at kroah.com (Greg KH) Date: Thu, 29 Apr 2004 14:05:05 -0700 Subject: [PATCH] -- set eeh option (enabled ) prior to any i/o to newly added IOA In-Reply-To: <4086DBCF.3020008@us.ibm.com> References: <4086DBCF.3020008@us.ibm.com> Message-ID: <20040429210504.GA21243@kroah.com> On Wed, Apr 21, 2004 at 03:38:39PM -0500, Linda Xie wrote: > Hi Greg, > > Attached patch fix the problem I have found during DLPAR I/O slots > testing on our > new hardware. rpaphp needs to set eeh-option(eanbled) for newly added > IOA prior > to performing PCI config(pci_setup_device), otherwise the pci_dev of the > IOA will have invalid base address > information. > > Linas Vepstas impleted eeh changes. > > Please apply the patch to your tree. Thanks, I've only applied the pci hotplug driver changes, as I am not the one to commit changes to the main ppc64 portion of the kernel tree. You will have to send those changes to that maintainer. greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxiep at us.ibm.com Fri Apr 30 08:27:05 2004 From: lxiep at us.ibm.com (Linda Xie) Date: Thu, 29 Apr 2004 17:27:05 -0500 Subject: [PATCH] -- set eeh option (enabled ) prior to any i/o to newly added IOA Message-ID: <40918139.7090900@us.ibm.com> Hi Anton, Can you apply attached eeh.patch to ameslab tree? Thanks, Linda [ Greg KH writes: ] > > On Wed, Apr 21, 2004 at 03:38:39PM -0500, Linda Xie wrote: > > > > Attached patch fix the problem I have found during DLPAR I/O slots > > testing on our new hardware. rpaphp needs to set eeh-option(eanbled) > > for newly added IOA prior to performing PCI config(pci_setup_device), > > otherwise the pci_dev of the IOA will have invalid base address > > information. > > > > Linas Vepstas impleted eeh changes. > > > > Please apply the patch to your tree. > > Thanks, I've only applied the pci hotplug driver changes, as I am not > the one to commit changes to the main ppc64 portion of the kernel tree. > You will have to send those changes to that maintainer. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: eeh.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040429/8d97ee05/attachment.txt