Re: [01/11] fix amd64 2.6.11 oops on modprobe (saa7110)
On Thu, Mar 10, 2005 at 07:37:40PM -0600, Josh Boyer wrote: > On Thu, 2005-03-10 at 15:07 -0800, Greg KH wrote: > > -stable review patch. If anyone has any objections, please let us know. > > > > -- > > > > This is a rewrite of the saa7110_write_block function, which was plain > > broken in the case where the underlying adapter supports I2C_FUNC_I2C. > > It also includes related fixes which ensure that different parts of the > > driver agree on the number of registers the chip has. > > > > Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> > > Signed-off-by: Chris Wright <[EMAIL PROTECTED]> > > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > > > --- linux-2.6.11-bk3/drivers/media/video/saa7110.c.orig Tue Mar 8 > > 10:27:15 2005 > > +++ linux-2.6.11-bk3/drivers/media/video/saa7110.c Tue Mar 8 12:02:45 2005 > > @@ -58,10 +58,12 @@ > > #define SAA7110_MAX_INPUT 9 /* 6 CVBS, 3 SVHS */ > > #define SAA7110_MAX_OUTPUT 0 /* its a decoder only */ > > > > -#defineI2C_SAA7110 0x9C/* or 0x9E */ > > +#define I2C_SAA71100x9C/* or 0x9E */ > > Not that I really care, but isn't there a rule that a patch "... can not > contain any "trivial" fixes in it (spelling changes, whitespace > cleanups, etc.)"? Good point. Jean, care to respin the patch? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oom with 2.6.11
On Fri, Mar 11, 2005 at 02:14:14AM +0100, Christian Kujau wrote: > Andrew Morton wrote: > > Christian Kujau <[EMAIL PROTECTED]> wrote: > > > >>i was going to compile 2.6.11-rc5-bk4, to sort out the "bad" kernel. > >>compiling went fine. ok, finished some email, ok, suddenly my swap was > >>used up again, and no memory left - uh oh! OOM again, with 2.6.11-rc5-bk2! > > > > > > Well if you ran out of swap then yes, the oom-killer will visit you. > > > > Why did you run out of swapspace? > > hm, if i only knew. i don't know how long it took the other night to go > from "normal" to "OOM". but today, with 2.6.11-rc5-bk2 (well, yesterday > actually) i was working normally, and all of a sudden swap goes from 170MB > used swap (normal) to OOM. i think it took a minute or so, but i just > can't tell which application went nuts. today the first process that got > killed was "ssh-agent", the other day it was mysqld. but even after this, > it should've released some memory, right? but the oom-killer goes on and > on and kills the next task. > > i'll monitor memory usage tonight and see what it gives. these "pppd" > messages are suspicious though. > I've also seen this 3 times now.. I'm running Xen 2.0 and the 2.6.10-xen0 kernel (with -as5 patch) goes OOM after a couple of days operation.. and then the box reboots. The "virtual machines" are OK, it's only the dom0 kernel that goes OOM.. And I'm not running anything special on dom0, only xen control stuff (which is written in python..), ntp, nfs server, ssh, lvm2 and software raid. Now I'm running a script which logs the cpu/memory/swap usage every 1 minutes.. trying to see if I can find the cause for the OOM. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Last night Linus bk - netfilter busted?
Hi, My box gets stuck while booting (actually starting ntpd) whith tonight pull from Linus. It looks like it is spinning in ipt_do_table when I do SysRq-P. No call trace though. Anyone else seeing it? Any ideas? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: User mode drivers: part 2: PCI device handling (patch 1/2 for 2.6.11)
On Fri, Mar 11, 2005 at 02:37:17PM +1100, Peter Chubb wrote: > +/* > + * The PCI subsystem is implemented as yet-another pseudo filesystem, > + * albeit one that is never mounted. > + * This is its magic number. > + */ > +#define USR_PCI_MAGIC (0x12345678) If you make it a real, mountable filesystem, then you don't need to have any of your new syscalls, right? Why not just do that instead? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc64: Add IDE-pmac support for new "Shasta" chipset
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > The iMac G5 and new single CPU PowerMac G5 come with a new revision of > the K2 ASIC called Shasta. The PATA cell in there now does 133Mhz. This > patch adds support for it. It also adds some power management bits to > the old 100MHz cell that was in Intrepid based ppc32 machines. Compile fix: --- 25/drivers/ide/ppc/pmac.c~ppc64-add-ide-pmac-support-for-new-shasta-chipset-fix 2005-03-11 07:12:01.0 -0700 +++ 25-akpm/drivers/ide/ppc/pmac.c 2005-03-11 07:12:20.0 -0700 @@ -1301,7 +1301,7 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p */ if (device_is_compatible(np, "K2-UATA") || device_is_compatible(np, "shasta-ata")) - pmid->cable_80 = 1; + pmif->cable_80 = 1; /* On Kauai-type controllers, we make sure the FCR is correct */ if (pmif->kauai_fcr) _ (Wonders how well tested this was). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microstate Accounting for 2.6.11
Andrew Morton <[EMAIL PROTECTED]> writes: > Why does the kernel need this feature? > > Have you any numbers on the overhead? It does RDTSC and lots of complicated stuff twice for each system call. On P4 this will be extremly slow (> 1000cycles combined) It is pretty unlikely that whatever it does justifies this extreme overhead in a critical fast path. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] -stable, how it's going to work.
Chris Friesen <[EMAIL PROTECTED]> writes: > Neil Brown wrote: > >> If a data corruption bug has been there for 10 weeks without being >> noticed, then the real risk is not that great. We are calling it >> "-release", not "-hardened". > > I disagree. If there's a simple, obvious, small fix that passes all > the other criteria, it should go into -stable ASAP after passing > review. Then the -stable maintainers will push the fix to > Andrew/Linux, and it will go into the next 2.6.x. No way, it needs to go into mainline first and then maybe later into stable. Doing stable first would lead to code drift because a lot of people would only care about stable and we would be back in the bad old days when older kernels had more fixes than newer ones. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
On Thu, 2005-03-10 at 11:27 +0100, Lars Marowsky-Bree wrote: > On 2005-03-09T18:36:37, Alex Aizman <[EMAIL PROTECTED]> wrote: > > >That works well in our current development series, and if you want to > > >share code, you can either rip it off (Open Source, we love ya ;) or we > > >can spin off these parts into a sub-package for you to depend on... > > If it's not a big deal :-) let's do the "sub-package" option. > > I've brought this up on the linux-ha-dev list. When do you need this? For open-iscsi, I think it would make sense to link open-iscs daemon code against klibc. The same way dm-multipath do. This will allow as to build iSCSI remote boot using early user-space. Not sure it will be possible to use your package without modifications. Let me know. Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ppc64: Add basic support for the SMU chip in iMac G5
Hi !
The iMac G5 and latest single-cpu PowerMac G5 have seen the venerable
PMU (Power Management Unit) chip been sent to well deserved retirement.
It has been replaced by a newcomer, the SMU (System Management Unit ?)
which is of course totally undocumented and has no open source darwin
driver... The SMU chip is responsible of initializing the chipset & CPU
(boot process), power supply control, real time clock, fan control,
provides some i2c busses, etc... etc... etc...
This is a very basic driver based on the Open Firmware methods for
accessing this chip. It provides synchronous functions only, and does
restart, shutdown, and real time clock access. There is still no fan
control, at least not until we have figured out how to access the fans
via the SMU.
The initial code was written by J. Mayer <[EMAIL PROTECTED]>, I mostly
rewrote it to better adhere to our coding style standards ;)
The patch also updates the g5_defconfig to include the SMU support by
default.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/arch/ppc64/Kconfig
===
--- linux-work.orig/arch/ppc64/Kconfig 2005-03-07 10:10:13.0 +1100
+++ linux-work/arch/ppc64/Kconfig 2005-03-10 16:56:16.0 +1100
@@ -81,7 +81,6 @@
depends on PPC_MULTIPLATFORM
bool " Apple G5 based machines"
default y
- select ADB_PMU
select U3_DART
config PPC_MAPLE
Index: linux-work/arch/ppc64/kernel/misc.S
===
--- linux-work.orig/arch/ppc64/kernel/misc.S2005-03-07 14:00:11.0
+1100
+++ linux-work/arch/ppc64/kernel/misc.S 2005-03-10 17:39:22.0 +1100
@@ -292,6 +292,26 @@
isync
blr
+_GLOBAL(flush_inval_dcache_range)
+ ld r10,[EMAIL PROTECTED](r2)
+ lwz r7,DCACHEL1LINESIZE(r10)/* Get dcache line size */
+ addir5,r7,-1
+ andcr6,r3,r5/* round low to line bdy */
+ subfr8,r6,r4/* compute length */
+ add r8,r8,r5/* ensure we get enough */
+ lwz r9,DCACHEL1LOGLINESIZE(r10)/* Get log-2 of dcache line size */
+ srw.r8,r8,r9/* compute line count */
+ beqlr /* nothing to do? */
+ sync
+ isync
+ mtctr r8
+0: dcbf0,r6
+ add r6,r6,r7
+ bdnz0b
+ sync
+ isync
+ blr
+
/*
* Flush a particular page from the data cache to RAM.
Index: linux-work/arch/ppc64/kernel/pmac_setup.c
===
--- linux-work.orig/arch/ppc64/kernel/pmac_setup.c 2005-03-10
13:43:01.0 +1100
+++ linux-work/arch/ppc64/kernel/pmac_setup.c 2005-03-10 16:56:16.0
+1100
@@ -70,6 +70,7 @@
#include
#include
#include
+#include
#include "pmac.h"
#include "mpic.h"
@@ -80,13 +81,20 @@
#define DBG(fmt...)
#endif
-
static int current_root_goodness = -1;
#define DEFAULT_ROOT_DEVICE Root_SDA1 /* sda1 - slightly silly choice */
extern int powersave_nap;
int sccdbg;
+sys_ctrler_t sys_ctrler;
+EXPORT_SYMBOL(sys_ctrler);
+
+#ifdef CONFIG_PMAC_SMU
+unsigned long smu_cmdbuf_abs;
+EXPORT_SYMBOL(smu_cmdbuf_abs);
+#endif
+
extern void udbg_init_scc(struct device_node *np);
void __pmac pmac_show_cpuinfo(struct seq_file *m)
@@ -155,8 +163,14 @@
/* We can NAP */
powersave_nap = 1;
- /* Initialize the PMU */
+#ifdef CONFIG_ADB_PMU
+ /* Initialize the PMU if any */
find_via_pmu();
+#endif
+#ifdef CONFIG_PMAC_SMU
+ /* Initialize the SMU if any */
+ smu_init();
+#endif
/* Init NVRAM access */
pmac_nvram_init();
@@ -216,12 +230,39 @@
void __pmac pmac_restart(char *cmd)
{
- pmu_restart();
+ switch(sys_ctrler) {
+#ifdef CONFIG_ADB_PMU
+ case SYS_CTRLER_PMU:
+ pmu_restart();
+ break;
+#endif
+
+#ifdef CONFIG_PMAC_SMU
+ case SYS_CTRLER_SMU:
+ smu_restart();
+ break;
+#endif
+ default:
+ ;
+ }
}
void __pmac pmac_power_off(void)
{
- pmu_shutdown();
+ switch(sys_ctrler) {
+#ifdef CONFIG_ADB_PMU
+ case SYS_CTRLER_PMU:
+ pmu_shutdown();
+ break;
+#endif
+#ifdef CONFIG_PMAC_SMU
+ case SYS_CTRLER_SMU:
+ smu_shutdown();
+ break;
+#endif
+ default:
+ ;
+ }
}
void __pmac pmac_halt(void)
@@ -426,7 +467,6 @@
{
if (platform != PLATFORM_POWERMAC)
return 0;
-
/*
* On U3, the DART (iommu) must be allocated now since it
* has an impact on htab_initialize (due to the large page it
@@ -435,6 +475,15 @@
*/
alloc_u3_dart_table();
+#ifdef CONFIG_PMAC_SMU
+ /*
+* SMU based G5s need some
[PATCH] ppc64: Fix some PCI interrupt routing issues on iMac G5
Hi !
The iMac G5 has some issues with Apple chips not having a valid
PCI_INTERRUPT_PIN. This patch fixes IRQ routing on PowerMac
platforms so that it only relies on the Open Firmware informations
which are correct.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: J. Mayer <[EMAIL PROTECTED]>
Index: linux-work/arch/ppc64/kernel/pmac_pci.c
===
--- linux-work.orig/arch/ppc64/kernel/pmac_pci.c2005-01-31
14:18:14.0 +1100
+++ linux-work/arch/ppc64/kernel/pmac_pci.c 2005-03-10 14:57:03.0
+1100
@@ -656,13 +656,32 @@
return 0;
}
+/*
+ * We use our own read_irq_line here because PCI_INTERRUPT_PIN is
+ * crap on some of Apple ASICs. We unconditionally use the Open Firmware
+ * interrupt number as this is always right.
+ */
+static int pmac_pci_read_irq_line(struct pci_dev *pci_dev)
+{
+ struct device_node *node;
+
+ node = pci_device_to_OF_node(pci_dev);
+ if (node == NULL)
+ return -1;
+ if (node->n_intrs == 0)
+ return -1;
+ pci_dev->irq = node->intrs[0].line;
+ pci_write_config_byte(pci_dev, PCI_INTERRUPT_LINE, pci_dev->irq);
+
+ return 0;
+}
void __init pmac_pcibios_fixup(void)
{
struct pci_dev *dev = NULL;
for_each_pci_dev(dev)
- pci_read_irq_line(dev);
+ pmac_pci_read_irq_line(dev);
}
static void __init pmac_fixup_phb_resources(void)
@@ -771,3 +790,4 @@
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SERVERWORKS, 0x0240, fixup_k2_sata);
+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ppc64: Add IDE-pmac support for new "Shasta" chipset
Hi !
The iMac G5 and new single CPU PowerMac G5 come with a new revision of
the K2 ASIC called Shasta. The PATA cell in there now does 133Mhz. This
patch adds support for it. It also adds some power management bits to
the old 100MHz cell that was in Intrepid based ppc32 machines.
The original iMac G5 bits are from J. Mayer <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/drivers/ide/ppc/pmac.c
===
--- linux-work.orig/drivers/ide/ppc/pmac.c 2005-01-31 14:18:21.0
+1100
+++ linux-work/drivers/ide/ppc/pmac.c 2005-03-10 14:58:19.0 +1100
@@ -68,6 +68,7 @@
struct device_node* node;
struct macio_dev*mdev;
u32 timings[4];
+ volatile u32 __iomem * *kauai_fcr;
#ifdef CONFIG_BLK_DEV_IDEDMA_PMAC
/* Those fields are duplicating what is in hwif. We currently
* can't use the hwif ones because of some assumptions that are
@@ -89,7 +90,8 @@
controller_kl_ata3, /* KeyLargo ATA-3 */
controller_kl_ata4, /* KeyLargo ATA-4 */
controller_un_ata6, /* UniNorth2 ATA-6 */
- controller_k2_ata6 /* K2 ATA-6 */
+ controller_k2_ata6, /* K2 ATA-6 */
+ controller_sh_ata6, /* Shasta ATA-6 */
};
static const char* model_name[] = {
@@ -99,6 +101,7 @@
"KeyLargo ATA-4", /* KeyLargo ATA-4 (UDMA/66) */
"UniNorth ATA-6", /* UniNorth2 ATA-6 (UDMA/100) */
"K2 ATA-6", /* K2 ATA-6 (UDMA/100) */
+ "Shasta ATA-6", /* Shasta ATA-6 (UDMA/133) */
};
/*
@@ -122,6 +125,15 @@
#define IDE_SYSCLK_NS 30 /* 33Mhz cell */
#define IDE_SYSCLK_66_NS 15 /* 66Mhz cell */
+/* 133Mhz cell, found in shasta.
+ * See comments about 100 Mhz Uninorth 2...
+ * Note that PIO_MASK and MDMA_MASK seem to overlap
+ */
+#define TR_133_PIOREG_PIO_MASK 0xff000fff
+#define TR_133_PIOREG_MDMA_MASK0x00fff800
+#define TR_133_UDMAREG_UDMA_MASK 0x0003
+#define TR_133_UDMAREG_UDMA_EN 0x0001
+
/* 100Mhz cell, found in Uninorth 2. I don't have much infos about
* this one yet, it appears as a pci device (106b/0033) on uninorth
* internal PCI bus and it's clock is controlled like gem or fw. It
@@ -209,6 +221,13 @@
#define IDE_INTR_DMA 0x8000
#define IDE_INTR_DEVICE0x4000
+/*
+ * FCR Register on Kauai. Not sure what bit 0x4 is ...
+ */
+#define KAUAI_FCR_UATA_MAGIC 0x0004
+#define KAUAI_FCR_UATA_RESET_N 0x0002
+#define KAUAI_FCR_UATA_ENABLE 0x0001
+
#ifdef CONFIG_BLK_DEV_IDEDMA_PMAC
/* Rounded Multiword DMA timings
@@ -322,6 +341,48 @@
{ 0 , 0 },
};
+static struct kauai_timing shasta_pio_timings[] __pmacdata =
+{
+ { 930 , 0x08000fff },
+ { 600 , 0x0A000c97 },
+ { 383 , 0x07000712 },
+ { 360 , 0x040003cd },
+ { 330 , 0x040003cd },
+ { 300 , 0x040003cd },
+ { 270 , 0x040003cd },
+ { 240 , 0x040003cd },
+ { 239 , 0x040003cd },
+ { 180 , 0x0400028b },
+ { 120 , 0x0400010a }
+};
+
+static struct kauai_timing shasta_mdma_timings[] __pmacdata =
+{
+ { 1260 , 0x00fff000 },
+ { 480 , 0x00820800 },
+ { 360 , 0x00820800 },
+ { 270 , 0x00820800 },
+ { 240 , 0x00820800 },
+ { 210 , 0x00820800 },
+ { 180 , 0x00820800 },
+ { 150 , 0x0028b000 },
+ { 120 , 0x001ca000 },
+ { 0 , 0 },
+};
+
+static struct kauai_timing shasta_udma133_timings[] __pmacdata =
+{
+ { 120 , 0x00035901, },
+ { 90, 0x000348b1, },
+ { 60, 0x00033881, },
+ { 45, 0x00033861, },
+ { 30, 0x00033841, },
+ { 20, 0x00033031, },
+ { 15, 0x00033021, },
+ { 0 , 0 },
+};
+
+
static inline u32
kauai_lookup_timing(struct kauai_timing* table, int cycle_time)
{
@@ -547,7 +608,9 @@
if (pmif == NULL)
return;
- if (pmif->kind == controller_un_ata6 || pmif->kind ==
controller_k2_ata6)
+ if (pmif->kind == controller_sh_ata6 ||
+ pmif->kind == controller_un_ata6 ||
+ pmif->kind == controller_k2_ata6)
pmac_ide_kauai_selectproc(drive);
else
pmac_ide_selectproc(drive);
@@ -665,6 +728,14 @@
pio = ide_get_best_pio_mode(drive, pio, 4, );
switch (pmif->kind) {
+ case controller_sh_ata6: {
+ /* 133Mhz cell */
+ u32 tr = kauai_lookup_timing(shasta_pio_timings, d.cycle_time);
+ if (tr == 0)
+ return;
+ *timings = ((*timings) & ~TR_133_PIOREG_PIO_MASK) | tr;
+ break;
+ }
case controller_un_ata6:
case
Re: [PATCH] ide: hdio.txt update
Greetings Bartlomiej,
I've updated the following
* in_flags modification when out_flags != 0 && in_flags == 0
* more than one -> one or more than one
* tf_{in|out}_flags -> {in|out}_flags as tf_* are in-kernel names
I'll update the taskfile patch series after receiving your comments
about the patches. Also, if you have a big picture for the IDE
driver, do you care to spill? What I have in mind now are
1. Completion-based taskfile (no direct ending/error handling of
requests), so that we can use it for specials/rw_disk/eh/etc...
2. Make specials (set_geometry, set_multmode...) more regular.
3. Do error-handling/resetting in a exception handler thread.
Maybe this and #2 should happen together.
So, please let me know what you think. Updated patch for hdio.txt
follows.
This patch updates Documentation/ioctl/hdio.txt to include more
detailed descriptions about HDIO_DRIVE_{CMD|TASK|TASKFILE} ioctls.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-taskfile-ng/Documentation/ioctl/hdio.txt
===
--- linux-taskfile-ng.orig/Documentation/ioctl/hdio.txt 2005-03-11
15:10:59.068016786 +0900
+++ linux-taskfile-ng/Documentation/ioctl/hdio.txt 2005-03-11
15:27:32.718915939 +0900
@@ -573,26 +573,43 @@ HDIO_DRIVE_TASKFILE execute raw taskfil
EFAULTreq_cmd == TASKFILE_IN_OUT (not implemented as of 2.6.8)
EPERM req_cmd == TASKFILE_MULTI_OUT and drive
multi-count not yet set.
-
+ EIO Drive failed the command.
notes:
- [1] Currently (2.6.8), both the input and output buffers are
- copied from the user and written back to the user, even when
- not used. This may be a bug.
-
- [2] The out_flags and in_flags are returned to the user after
- the ioctl completes. Currently (2.6.8) these are the same
- as the input values, unchanged. In the future, they may have
- more significance.
-
- Extreme caution should be used with using this ioctl. A
- mistake can easily corrupt data or hang the system.
-
- The argument to the ioctl is a pointer to a region of memory
- containing a ide_task_request_t structure, followed by an
- optional buffer of data to be transmitted to the drive,
- followed by an optional buffer to receive data from the drive.
+ [1] READ THE FOLLOWING NOTES *CAREFULLY*. THIS IOCTL IS
+ FULL OF GOTCHAS. Extreme caution should be used with using
+ this ioctl. A mistake can easily corrupt data or hang the
+ system.
+
+ [2] Both the input and output buffers are copied from the
+ user and written back to the user, even when not used.
+
+ [3] If one or more bits are set in out_flags and in_flags is
+ zero, the following values are used for in_flags.all and
+ written back into in_flags on completion.
+
+ * IDE_TASKFILE_STD_IN_FLAGS | (IDE_HOB_STD_IN_FLAGS << 8)
+if LBA48 addressing is enabled for the drive
+ * IDE_TASKFILE_STD_IN_FLAGS
+if CHS/LBA28
+
+ The association between in_flags.all and each enable
+ bitfield flips depending on endianess; fortunately, TASKFILE
+ only uses inflags.b.data bit and ignores all other bits.
+ The end result is that, on any endian machines, it has no
+ effect other than modifying in_flags on completion.
+
+ [4] The default value of SELECT is (0xa0|DEV_bit|LBA_bit)
+ except for four drives per port chipsets. For four drives
+ per port chipsets, it's (0xa0|DEV_bit|LBA_bit) for the first
+ pair and (0x80|DEV_bit|LBA_bit) for the second pair.
+
+ [5] The argument to the ioctl is a pointer to a region of
+ memory containing a ide_task_request_t structure, followed
+ by an optional buffer of data to be transmitted to the
+ drive, followed by an optional buffer to receive data from
+ the drive.
Command is passed to the disk drive via the ide_task_request_t
structure, which contains these fields:
@@ -611,11 +628,66 @@ HDIO_DRIVE_TASKFILE execute raw taskfil
out_sizeoutput (user->drive) buffer size, bytes
in_size input (drive->user) buffer size, bytes
- This ioctl does not necessarily respect all flags in the
- out_flags and in_flags values -- some taskfile registers
- may be written or read even if not requested in the flags.
- Unused fields of io_ports[] and hob_ports[] should be set
- to zero.
+ When out_flags is zero, the following registers are loaded.
+
+ HOB_FEATURE If the drive supports LBA48
+ HOB_NSECTOR If the drive supports LBA48
+ HOB_SECTOR If the drive supports
Re: inappropriate use of in_atomic()
Hi Andrew,
On Thu, 10 Mar 2005 20:40:06 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> in_atomic() is not a reliable indication of whether it is currently safe
> to call schedule().
>
> arch/ppc64/kernel/viopath.c
in_atomic() in viopath.c was just used to determine if we had initialised
enough to be able to wait in a semaphore (i.e. schedule). Thus it can be
replaced now with checking system_state for SYSTEM_RUNNING.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
Test booted on iSeries (which is the only place it is used).
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
diff -ruNp linus/arch/ppc64/kernel/viopath.c
linus-in_atomic/arch/ppc64/kernel/viopath.c
--- linus/arch/ppc64/kernel/viopath.c 2005-01-22 06:09:01.0 +1100
+++ linus-in_atomic/arch/ppc64/kernel/viopath.c 2005-03-11 17:19:45.0
+1100
@@ -79,7 +79,7 @@ static void handleMonitorEvent(struct Hv
/*
* We use this structure to handle asynchronous responses. The caller
* blocks on the semaphore and the handler posts the semaphore. However,
- * if in_atomic() is true in the caller, then wait_atomic is used ...
+ * if system_state is not SYSTEM_RUNNING, then wait_atomic is used ...
*/
struct doneAllocParms_t {
struct semaphore *sem;
@@ -465,7 +465,7 @@ static int allocateEvents(HvLpIndex remo
DECLARE_MUTEX_LOCKED(Semaphore);
atomic_t wait_atomic;
- if (in_atomic()) {
+ if (system_state != SYSTEM_RUNNING) {
parms.used_wait_atomic = 1;
atomic_set(_atomic, 1);
parms.wait_atomic = _atomic;
@@ -475,7 +475,7 @@ static int allocateEvents(HvLpIndex remo
}
mf_allocate_lp_events(remoteLp, HvLpEvent_Type_VirtualIo, 250, /* It
would be nice to put a real number here! */
numEvents, _donealloc, );
- if (in_atomic()) {
+ if (system_state != SYSTEM_RUNNING) {
while (atomic_read(_atomic))
mb();
} else
pgp8HryQkIgDo.pgp
Description: PGP signature
[PATCH] ppc64: Export proper version from vDSO
Hi ! The ppc64 vDSO is still exporting LINUX_2.6.11 (from -mm) for symbol versioning. The glibc folks asked me to export the first kernel version that will contain it, so this patch fixes it to LINUX_2.6.12 Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Index: linux-work/include/asm-ppc64/vdso.h === --- linux-work.orig/include/asm-ppc64/vdso.h2005-03-08 11:21:44.0 +1100 +++ linux-work/include/asm-ppc64/vdso.h 2005-03-11 17:16:21.0 +1100 @@ -11,7 +11,7 @@ #define VDSO32_MBASE 0x10 #define VDSO64_MBASE 0x10 -#define VDSO_VERSION_STRINGLINUX_2.6.11 +#define VDSO_VERSION_STRINGLINUX_2.6.12 /* Define if 64 bits VDSO has procedure descriptors */ #undef VDS64_HAS_DESCRIPTORS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4 fix for write throttling on x86 >1G
Hello Marcelo,
I've got a fix for you on 2.4. I got reports of stalls with heavy writes
on 2.4. There was a mistake in nr_free_buffer_pages. That function is
definitely meant _not_ to take highmem into account (dirty cache cannot
spread over highmem in 2.4 [even when on top of fs]). For unknown
reasons it was actually taking highmem into account. The code was
obviously meant to not take inot account see the GFP_USER and zonelist,
except it wasn't using the zonelist. That is a severe problem because
there will be no write throttling at all, and no bdflush wakeup either.
This should fix it, though my compiler fails to compile 2.4, so it's not
immediate to verify it. If any problem showup I'll post a followup.
This is a noop for all systems <800M (1G shouldn't be noticeable
either). This is why most people can't notice.
Thanks.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
--- 2.4.23aa3/mm/page_alloc.c.~1~ 2004-07-04 02:09:42.0 +0200
+++ 2.4.23aa3/mm/page_alloc.c 2005-03-11 07:00:23.0 +0100
@@ -656,7 +656,7 @@ unsigned int nr_free_buffer_pages (void)
class_idx = zone_idx(zone);
sum += zone->nr_cache_pages;
- for (zone = pgdat->node_zones; zone < pgdat->node_zones +
MAX_NR_ZONES; zone++) {
+ for (; zone; zone = *zonep++) {
int free = zone->free_pages -
zone->watermarks[class_idx].high;
if (free <= 0)
continue;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC 1/3] Add sem_getcount() to arches that lack it
Jody McIntyre <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 10, 2005 at 08:55:03PM -0800, Andrew Morton wrote: > > Jody McIntyre <[EMAIL PROTECTED]> wrote: > > > > > > parisc and frv define sem_getcount() in semaphore.h, which returns the > > > current semaphore value. This is cleaner than doing > > > atomic_read(), currently done in > > > drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work > > > on all architectures if sem_getcount() is added. > > > > That's a fairly bizarre thing to want to do. Would it be hard to modify > > xfs and 1394 to stop wanting to read a semaphore's up() count? > > The count is the number of free transaction labels (1394 async is > transaction-based) and is initialized to 64. When a new transaction label > is needed, the requestor does a down(), then locks the tlabel variables > and allocates a new one. When a transaction label is freed, an up() > occurs. The semaphore's up() count is therefore the number of free > tlabels, and the number of outstanding transactions is (64 - count). I > can imagine situations in which this would be a useful statistic, but > I'm not sure any of them actually exist. That's a nice application of semaphores. I can see that there's also a need to be able to read the value back for reporting purposes. Dang. But I guess it's a bit hard to justify adding more infrastructure to support a single callsite which has a simple alternative. So if you could please add the separate counter? > ... > > If this patch isn't accepted, we should get rid of the xfs and 1394 > hacks and delete sem_getcount (parisc, frv) and sema_count (arm) as they > are unused. True. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() doesn't respect SO_RCVLOWAT ?
On Thu, Mar 10, 2005 at 04:58:51PM -0500, Felix Matathias wrote: > > I am running a 2.4.21-9.0.3.ELsmp #1 kernel and I can setsockopt and > getsockopt correctly the SO_RCVLOWAT option, but select() seems to mark a > socket readable even if a single byte is ready to be read. Then, a read() > blocks until the specified number of bytes in SO_RCVLOWAT makes it to the > socket buffer. as discussed in a previous thread, if you use select(), you should also use non-blocking sockets. There are cases where select() can wake you up without anything to read, eg if there is a packet waiting with a wrong checksum. > This is the exact opposite behaviour of what I yould have > expected/desired. Our application receives data at many Khz rate and we > want to avoid reading the socket until a predetermined amount of data is > sent, to avoid partial reads. SO_RCVLOWAT seemed to be a nice way to > implement that. I too came across this problem a long time ago and concluded that LOWAT was not really usable on Linux. But in the end, this is not really a big deal, because as long as your application doesn't eat all CPU, it does not change anything performance-wise, and when it becomes to eat a lot of CPU, the latency will increase, letting more data come in when you do one read. > An earlier message by Alan Cox was a bit cryptic: > > "But is the cost of all those special case checks and all the handling > for it such as select computing if enough tcp packets together accumulated > worth the cost on every app not using LOWAT for the microscopic gain given > that essentially nobody uses it." > > Does this mean that select() in Linux will wake up no matter what > SO_RCVLOWAT is set to ? Yes. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] radeonfb: Implement proper workarounds for PLL accesses
Hi !
After discussion with ATIs, it seems that the workarounds they initially
gave me were not completely correct.
This patch implements the proper ones, which includes sleeping in PLL
accesses, and thus requires the previous patch to make sure we do not
call unblank at interrupt time (unless oops_in_progress is set, in which
case I use an mdelay).
It also removes obsolete code that used to disable some power management
features in the accel init code.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/drivers/video/aty/radeonfb.h
===
--- linux-work.orig/drivers/video/aty/radeonfb.h2005-03-11
15:05:34.0 +1100
+++ linux-work/drivers/video/aty/radeonfb.h 2005-03-11 15:42:19.0
+1100
@@ -77,6 +77,15 @@
CHIP_HAS_CRTC2 = 0x0004UL,
};
+/*
+ * Errata workarounds
+ */
+enum radeon_errata {
+ CHIP_ERRATA_R300_CG = 0x0001,
+ CHIP_ERRATA_PLL_DUMMYREADS = 0x0002,
+ CHIP_ERRATA_PLL_DELAY = 0x0004,
+};
+
/*
* Monitor types
@@ -295,6 +304,7 @@
int chipset;
u8 family;
u8 rev;
+ unsigned interrata;
unsigned long video_ram;
unsigned long mapped_vram;
int vram_width;
@@ -305,7 +315,6 @@
int has_CRTC2;
int is_mobility;
int is_IGP;
- int R300_cg_workaround;
int reversed_DAC;
int reversed_TMDS;
struct panel_info panel_info;
@@ -369,6 +378,21 @@
* IO macros
*/
+/* Note about this function: we have some rare cases where we must not
schedule,
+ * this typically happen with our special "wake up early" hook which allows us
to
+ * wake up the graphic chip (and thus get the console back) before everything
else
+ * on some machines that support that mecanism. At this point, interrupts are
off
+ * and scheduling is not permitted
+ */
+static inline void _radeon_msleep(struct radeonfb_info *rinfo, unsigned long
ms)
+{
+ if (rinfo->no_schedule || oops_in_progress)
+ mdelay(ms);
+ else
+ msleep(ms);
+}
+
+
#define INREG8(addr) readb((rinfo->mmio_base)+addr)
#define OUTREG8(addr,val) writeb(val, (rinfo->mmio_base)+addr)
#define INREG(addr)readl((rinfo->mmio_base)+addr)
@@ -390,107 +414,85 @@
#define OUTREGP(addr,val,mask) _OUTREGP(rinfo, addr, val,mask)
-/* This function is required to workaround a hardware bug in some (all?)
- * revisions of the R300. This workaround should be called after every
- * CLOCK_CNTL_INDEX register access. If not, register reads afterward
- * may not be correct.
- */
-static inline void R300_cg_workardound(struct radeonfb_info *rinfo)
-{
- u32 save, tmp;
- save = INREG(CLOCK_CNTL_INDEX);
- tmp = save & ~(0x3f | PLL_WR_EN);
- OUTREG(CLOCK_CNTL_INDEX, tmp);
- tmp = INREG(CLOCK_CNTL_DATA);
- OUTREG(CLOCK_CNTL_INDEX, save);
-}
-
/*
- * PLL accesses suffer from various HW issues on the different chip
- * families. Some R300's need the above workaround, rv200 & friends
- * need a couple of dummy reads after any write of CLOCK_CNTL_INDEX,
- * and some RS100/200 need a dummy read before writing to
- * CLOCK_CNTL_INDEX as well. Instead of testing every chip revision,
- * we just unconditionally do the workarounds at once since PLL
- * accesses are far from beeing performance critical. Except for R300
- * one which stays separate for now
+ * Note about PLL register accesses:
+ *
+ * I have removed the spinlock on them on purpose. The driver now
+ * expects that it will only manipulate the PLL registers in normal
+ * task environment, where radeon_msleep() will be called, protected
+ * by a semaphore (currently the console semaphore) so that no conflict
+ * will happen on the PLL register index.
+ *
+ * With the latest changes to the VT layer, this is guaranteed for all
+ * calls except the actual drawing/blits which aren't supposed to use
+ * the PLL registers anyway
+ *
+ * This is very important for the workarounds to work properly. The only
+ * possible exception to this rule is the call to unblank(), which may
+ * be done at irq time if an oops is in progress.
*/
-
-static inline void radeon_pll_workaround_before(struct radeonfb_info *rinfo)
+static inline void radeon_pll_errata_after_index(struct radeonfb_info *rinfo)
{
+ if (!(rinfo->errata & CHIP_ERRATA_PLL_DUMMYREADS))
+ return;
+
+ (void)INREG(CLOCK_CNTL_DATA);
(void)INREG(CRTC_GEN_CNTL);
}
-static inline void radeon_pll_workaround_after(struct radeonfb_info *rinfo)
+static inline void radeon_pll_errata_after_data(struct radeonfb_info *rinfo)
{
-
Re: [BK PATCHES] kbuild updates
> If this is the same version as in 2.6.11-mm2 (you didn't offer a GNU > patch so that I could check it), the following is still present: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0502.2/1507.html Thanks Adrian, I forgot about that one. It is now fixed and pushed to bk://linux-sam.bkbits.net/kbuild Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ppc32: move powermac backlight stuff to a workqueue
Hi !
The powermac has a kernel-based driver for controlling the backlight
from the keyboard that used to call into some fbdev's from interrupt
contexts. This patch moves it to a workqueue (and additionally makes
sure the console semaphore is taken and held).
I hope I'll replace this by the new backlight framework in a future
kernel version, but for now, this will fix the immediate issues with
radeon.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/arch/ppc/platforms/pmac_backlight.c
===
--- linux-work.orig/arch/ppc/platforms/pmac_backlight.c 2005-01-24
17:09:23.0 +1100
+++ linux-work/arch/ppc/platforms/pmac_backlight.c 2005-03-11
15:18:54.0 +1100
@@ -25,14 +25,19 @@
#include
#include
-static struct backlight_controller *backlighter = NULL;
-static void* backlighter_data = NULL;
-static int backlight_autosave = 0;
+static struct backlight_controller *backlighter;
+static void* backlighter_data;
+static int backlight_autosave;
static int backlight_level = BACKLIGHT_MAX;
static int backlight_enabled = 1;
+static int backlight_req_level = -1;
+static int backlight_req_enable = -1;
-void __pmac
-register_backlight_controller(struct backlight_controller *ctrler, void *data,
char *type)
+static void backlight_callback(void *);
+static DECLARE_WORK(backlight_work, backlight_callback, NULL);
+
+void __pmac register_backlight_controller(struct backlight_controller *ctrler,
+ void *data, char *type)
{
struct device_node* bk_node;
char *prop;
@@ -83,16 +88,18 @@
backlight_level = req.reply[0] >> 4;
}
#endif
+ acquire_console_sem();
if (!backlighter->set_enable(1, backlight_level, data))
backlight_enabled = 1;
+ release_console_sem();
- printk(KERN_INFO "Registered \"%s\" backlight controller, level:
%d/15\n",
- type, backlight_level);
+ printk(KERN_INFO "Registered \"%s\" backlight controller,"
+ "level: %d/15\n", type, backlight_level);
}
EXPORT_SYMBOL(register_backlight_controller);
-void __pmac
-unregister_backlight_controller(struct backlight_controller *ctrler, void
*data)
+void __pmac unregister_backlight_controller(struct backlight_controller
+ *ctrler, void *data)
{
/* We keep the current backlight level (for now) */
if (ctrler == backlighter && data == backlighter_data)
@@ -100,22 +107,29 @@
}
EXPORT_SYMBOL(unregister_backlight_controller);
-int __pmac
-set_backlight_enable(int enable)
+static int __pmac __set_backlight_enable(int enable)
{
int rc;
if (!backlighter)
return -ENODEV;
- rc = backlighter->set_enable(enable, backlight_level, backlighter_data);
+ acquire_console_sem();
+ rc = backlighter->set_enable(enable, backlight_level,
+backlighter_data);
if (!rc)
backlight_enabled = enable;
+ release_console_sem();
return rc;
}
+int __pmac set_backlight_enable(int enable)
+{
+ backlight_req_enable = enable;
+ schedule_work(_work);
+}
+
EXPORT_SYMBOL(set_backlight_enable);
-int __pmac
-get_backlight_enable(void)
+int __pmac get_backlight_enable(void)
{
if (!backlighter)
return -ENODEV;
@@ -123,8 +137,7 @@
}
EXPORT_SYMBOL(get_backlight_enable);
-int __pmac
-set_backlight_level(int level)
+static int __pmac __set_backlight_level(int level)
{
int rc = 0;
@@ -134,10 +147,12 @@
level = BACKLIGHT_OFF;
if (level > BACKLIGHT_MAX)
level = BACKLIGHT_MAX;
+ acquire_console_sem();
if (backlight_enabled)
rc = backlighter->set_level(level, backlighter_data);
if (!rc)
backlight_level = level;
+ release_console_sem();
if (!rc && !backlight_autosave) {
level <<=1;
if (level & 0x10)
@@ -146,13 +161,35 @@
}
return rc;
}
+int __pmac set_backlight_level(int level)
+{
+ backlight_req_level = level;
+ schedule_work(_work);
+}
+
EXPORT_SYMBOL(set_backlight_level);
-int __pmac
-get_backlight_level(void)
+int __pmac get_backlight_level(void)
{
if (!backlighter)
return -ENODEV;
return backlight_level;
}
EXPORT_SYMBOL(get_backlight_level);
+
+static void backlight_callback(void *dummy)
+{
+ int level, enable;
+
+ do {
+ level = backlight_req_level;
+ enable = backlight_req_enable;
+ mb();
+
+ if (level >= 0)
+ __set_backlight_level(level);
+ if (enable >= 0)
+ __set_backlight_enable(enable);
+ } while(cmpxchg(_req_level, level, -1) != level ||
+
Re: [PATCH 2.6.11] fix: drivers/base/class.c
> > fix: drivers/base/class.c
>
> "fix" how? What are you fixing?
I'm sorry. Previous subject was "[PATCH 2.6.11] fix call kobject_get_path()
with zero kobject argument in drivers/base/class.c"
> > diff -uNrp linux/drivers/base/class.orig.c linux/drivers/base/class.c
> > --- linux/drivers/base/class.orig.c 2005-03-10 12:19:00.0 +0300
> > +++ linux/drivers/base/class.c 2005-03-10 13:59:27.0 +0300
> > @@ -307,12 +307,14 @@ static int class_hotplug(struct kset *ks
> > if (class_dev->dev) {
> >/* add physical device, backing this device */
> >struct device *dev = class_dev->dev;
>
> Your email client ate all of the tabs, this patch can't be applied :(
oops :(
I send patch as attachment.
>
> Let me guess, you are using an out-of-tree driver that incorrectly sets
> up the kobject
I use standard cdc_acm driver from 2.6.11 for Motorola C350 mobile phone
build-in GPRS modem (USB).
In the function (see devices/usb/class/cdc-acm.c):
static void acm_tty_close(struct tty_struct *tty, struct file *filp)
{
struct acm *acm = tty->driver_data;
if (!acm || !acm->used)
return;
down(_sem);
if (!--acm->used) {
if (acm->dev) {
acm_set_control(acm, acm->ctrlout = 0);
usb_kill_urb(acm->ctrlurb);
usb_kill_urb(acm->writeurb);
usb_kill_urb(acm->readurb);
} else {
->
Problem, take place here:
tty_unregister_device(acm_tty_driver, acm->minor);
-->
acm_table[acm->minor] = NULL;
usb_free_urb(acm->ctrlurb);
usb_free_urb(acm->readurb);
usb_free_urb(acm->writeurb);
kfree(acm);
}
}
up(_sem);
}
> and the hotplug userspace code doesn't like the in
> the strings?
When I unplug my mobile phone (or my phone lost GPRS network) , I have OOPS:
Mar 6 00:55:52 toshiba kernel: <6>usb 2-1: USB disconnect, address 4
Mar 6 00:55:53 toshiba kernel: <1>Unable to handle kernel NULL pointer
dereference at virtual address
Mar 6 00:55:53 toshiba kernel: printing eip:
Mar 6 00:55:53 toshiba kernel: c0255299
Mar 6 00:55:53 toshiba kernel: *pde =
Mar 6 00:55:53 toshiba kernel: Oops: [#1]
Mar 6 00:55:53 toshiba kernel: PREEMPT
Mar 6 00:55:53 toshiba kernel: Modules linked in: ppp_deflate zlib_deflate
bsd_comp ppp_async crc_ccitt ppp_generic slhc i
pt_REJECT ipt_LOG iptable_filter ipt_MASQUERADE iptable_nat ip_conntrack
ip_tables pktcdvd snd_pcm_oss snd_mixer_oss rtc pcs
pkr usbhid intel_agp intelfb uhci_hcd ehci_hcd i8xx_tco 8250_pci 8250
serial_core snd_intel8x0m eepro100 mii evdev pcmcia ye
nta_socket rsrc_nonstatic pcmcia_core nls_koi8_r ntfs cdc_acm usb_storage
usbkbd usbmouse usbcore msr cpuid sg sd_mod scsi_m
od dummy ide_cd cdrom snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd
soundcore snd_page_alloc agpgart
Mar 6 00:55:53 toshiba kernel: CPU:0
Mar 6 00:55:53 toshiba kernel: EIP:0060:[]Not tainted VLI
Mar 6 00:55:53 toshiba kernel: EFLAGS: 00010246 (2.6.11)
Mar 6 00:55:53 toshiba kernel: EIP is at get_kobj_path_length+0x29/0x50
Mar 6 00:55:53 toshiba kernel: eax: ebx: ecx:
edx:
Mar 6 00:55:53 toshiba kernel: esi: 0001 edi: ebp: d4397d9c
esp: d4397d8c
Mar 6 00:55:53 toshiba kernel: ds: 007b es: 007b ss: 0068
Mar 6 00:55:53 toshiba kernel: Process pppd (pid: 6057, threadinfo=d4396000
task=d432da20)
Mar 6 00:55:53 toshiba kernel: Stack: dedf5bb8 00d0 dedf5b94 d6dfa298
d4397db8 c0255339 d4397dc4 dedf5bb8
Mar 6 00:55:53 toshiba kernel:c041f708 dedf5b94 d6dfa298 d4397dfc
c02bc68f 0286 fffd
Mar 6 00:55:53 toshiba kernel: 21ac27d7 de53d829 c039d8ab
c041f720 d6dfa90c
Mar 6 00:55:53 toshiba kernel: Call Trace:
Mar 6 00:55:53 toshiba kernel: [] show_stack+0x7a/0x90
Mar 6 00:55:53 toshiba kernel: [] show_registers+0x149/0x1b0
Mar 6 00:55:53 toshiba kernel: [] die+0xdd/0x170
Mar 6 00:55:53 toshiba kernel: [] do_page_fault+0x30a/0x65a
Mar 6 00:55:53 toshiba kernel: [] error_code+0x2b/0x30
Mar 6 00:55:53 toshiba kernel: [] kobject_get_path+0x19/0x60
Mar 6 00:55:53 toshiba kernel: [] class_hotplug+0x6f/0x160
Mar 6 00:55:53 toshiba kernel: [] kobject_hotplug+0x1b4/0x2c0
Mar 6 00:55:53 toshiba kernel: [] kobject_del+0x10/0x20
Mar 6 00:55:53 toshiba kernel: [] class_device_del+0x92/0xc0
Mar 6 00:55:53 toshiba kernel: [] class_device_unregister+0xb/0x20
Mar 6 00:55:53 toshiba kernel: [] acm_tty_close+0x14c/0x160
[cdc_acm]
Mar 6 00:55:53 toshiba kernel: [] release_dev+0x7f2/0x810
Mar 6 00:55:53 toshiba kernel: [] tty_release+0x12/0x20
Mar 6 00:55:53 toshiba kernel: [] __fput+0x12b/0x140
Mar 6 00:55:53 toshiba kernel: [] filp_close+0x4f/0x80
Mar 6 00:55:53 toshiba kernel: [] syscall_call+0x7/0xb
Mar 6 00:55:53 toshiba kernel: Code: 00 00 55 ba ff ff ff ff 89 e5 57 56 be 01
00 00 00 53 83 ec 04 31 db 89 45 f0 90 8d b
4 26 00 00 00 00 8b 45 f0 89 d1 8b 38 89 d8 ae f7 d1 49 8b 45 f0 8d 74 31
01 8b 40 24 89 45 f0 85 c0 75
> Fix the driver,
[PATCH] sealevel 8 port RS-232/RS-422/RS-485 board
Vendor Sealevel suggested these changes for its new board. Tried them,
they work with the card. Please apply the patch below, which was made
from 2.6.10 but can be applied to 2.6.11.2 without errors.
Dick
--- linux/drivers/serial/8250_pci.orig 2005-03-10 13:09:39.0 -0600
+++ linux/drivers/serial/8250_pci.c 2005-03-10 15:03:39.0 -0600
@@ -1867,6 +1867,9 @@
{ PCI_VENDOR_ID_SEALEVEL, PCI_DEVICE_ID_SEALEVEL_COMM8,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b2_8_115200 },
+ { PCI_VENDOR_ID_SEALEVEL, PCI_DEVICE_ID_SEALEVEL_UCOMM8,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_b2_8_115200 },
{ PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_GTEK_SERIAL2,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
--- linux/drivers/pci/pci.ids.orig 2005-03-10 13:10:10.0 -0600
+++ linux/drivers/pci/pci.ids 2005-03-10 15:21:43.0 -0600
@@ -5714,6 +5714,7 @@
7401 Four Port RS-232 Interface
7402 Four Port RS-422/485 Interface
7801 Eight Port RS-232 Interface
+ 7804 Eight Port RS-232/422/485 Interface
8001 8001 Digital I/O Adapter
135f I-Data International A-S
1360 Meinberg Funkuhren
--- linux/include/linux/pci_ids.h.orig 2005-03-10 13:11:25.0 -0600
+++ linux/include/linux/pci_ids.h 2005-03-10 15:06:07.0 -0600
@@ -1780,6 +1780,7 @@
#define PCI_DEVICE_ID_SEALEVEL_UCOMM2320x7202
#define PCI_DEVICE_ID_SEALEVEL_COMM4 0x7401
#define PCI_DEVICE_ID_SEALEVEL_COMM8 0x7801
+#define PCI_DEVICE_ID_SEALEVEL_UCOMM8 0x7804
#define PCI_VENDOR_ID_HYPERCOPE0x1365
#define PCI_DEVICE_ID_HYPERCOPE_PLX0x9050
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] don't call unblank at irq time
Hi !
This patch removes the call to unblank() from printk, and avoids calling
unblank at irq() time _unless_ oops_in_progress is 1. I also export
oops_in_progress() so drivers who care like radeonfb can test it and
know what to do. I audited call sites of unblank_screen(),
console_unblank(), etc... and I _hope_ I got them all, the patch
includes a small patch to the s390 bust_spinlocks code that sets
oops_in_progress back to 0 _after_ unblanking for example.
I added a few might_sleep() to help us catch possible remaining callers.
I'll soon write a document explaining fbdev locking. The current
situation after this patch is that:
- All callbacks have console_semaphore held (fbdev's are fully
serialised).
- Everything is called in schedule'able context, except the cfb_*
rendering operations and cursor operations, with the special case of
unblank who can be called at any time when "oops_in_progress" is true. A
driver that needs to sleep in it's unblank implementation is welcome to
test that variable and use a fallback path (or just do nothing if it's
not simple).
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/kernel/printk.c
===
--- linux-work.orig/kernel/printk.c 2005-03-10 11:37:34.0 +1100
+++ linux-work/kernel/printk.c 2005-03-11 14:51:42.0 +1100
@@ -54,7 +54,12 @@
EXPORT_SYMBOL(console_printk);
+/*
+ * Low lever drivers may need that to know if they can schedule in
+ * their unblank() callback or not. So let's export it.
+ */
int oops_in_progress;
+EXPORT_SYMBOL(oops_in_progress);
/*
* console_sem protects the console_drivers list, and also
@@ -744,12 +749,15 @@
struct console *c;
/*
-* Try to get the console semaphore. If someone else owns it
-* we have to return without unblanking because console_unblank
-* may be called in interrupt context.
+* console_unblank can no longer be called in interrupt context unless
+* oops_in_progress is set to 1..
*/
- if (down_trylock(_sem) != 0)
- return;
+ if (oops_in_progress) {
+ if (down_trylock(_sem) != 0)
+ return;
+ } else
+ acquire_console_sem();
+
console_locked = 1;
console_may_schedule = 0;
for (c = console_drivers; c != NULL; c = c->next)
Index: linux-work/arch/s390/mm/fault.c
===
--- linux-work.orig/arch/s390/mm/fault.c2005-01-24 17:09:26.0
+1100
+++ linux-work/arch/s390/mm/fault.c 2005-03-11 14:46:21.0 +1100
@@ -62,8 +62,8 @@
oops_in_progress = 1;
} else {
int loglevel_save = console_loglevel;
- oops_in_progress = 0;
console_unblank();
+ oops_in_progress = 0;
/*
* OK, the message is on the console. Now we call printk()
* without oops_in_progress set so that printk will give klogd
Index: linux-work/drivers/char/vt.c
===
--- linux-work.orig/drivers/char/vt.c 2005-03-10 11:37:24.0 +1100
+++ linux-work/drivers/char/vt.c2005-03-11 14:54:05.0 +1100
@@ -2220,9 +2220,6 @@
}
set_cursor(vc);
- if (!oops_in_progress)
- poke_blanked_console();
-
quit:
clear_bit(0, );
}
@@ -2823,6 +2820,13 @@
{
struct vc_data *vc;
+ /* This should now always be called from a "sane" (read: can schedule)
+* context for the sake of the low level drivers, except in the special
+* case of oops_in_progress
+*/
+ if (!oops_in_progress)
+ might_sleep();
+
WARN_CONSOLE_UNLOCKED();
ignore_poke = 0;
@@ -2879,6 +2883,14 @@
{
WARN_CONSOLE_UNLOCKED();
+ /* Add this so we quickly catch whoever might call us in a non
+* safe context. Nowadays, unblank_screen() isn't to be called in
+* atomic contexts and is allowed to schedule (with the special case
+* of oops_in_progress, but that isn't of any concern for this
+* function. --BenH.
+*/
+ might_sleep();
+
/* This isn't perfectly race free, but a race here would be mostly
harmless,
* at worse, we'll do a spurrious blank and it's unlikely
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC 1/3] Add sem_getcount() to arches that lack it
On Thu, Mar 10, 2005 at 08:55:03PM -0800, Andrew Morton wrote: > Jody McIntyre <[EMAIL PROTECTED]> wrote: > > > > parisc and frv define sem_getcount() in semaphore.h, which returns the > > current semaphore value. This is cleaner than doing > > atomic_read(), currently done in > > drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work > > on all architectures if sem_getcount() is added. > > That's a fairly bizarre thing to want to do. Would it be hard to modify > xfs and 1394 to stop wanting to read a semaphore's up() count? The count is the number of free transaction labels (1394 async is transaction-based) and is initialized to 64. When a new transaction label is needed, the requestor does a down(), then locks the tlabel variables and allocates a new one. When a transaction label is freed, an up() occurs. The semaphore's up() count is therefore the number of free tlabels, and the number of outstanding transactions is (64 - count). I can imagine situations in which this would be a useful statistic, but I'm not sure any of them actually exist. I haven't investigated xfs, but modifying 1394 would be fairly easy. I could add a second variable that tracks the up() count, or just drop the sysfs attribute that reports the number. The first option seems a bit wasteful, but only slightly. I thought this patch was worthwhile based on xfs wanting to do this and 3 arches already having (unused) implementations of sem_getcount/sema_count. If this patch isn't accepted, we should get rid of the xfs and 1394 hacks and delete sem_getcount (parisc, frv) and sema_count (arm) as they are unused. Jody > > (Why do they want to do this anyway?) -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: User mode drivers: part 2: PCI device handling (patch 1/2 for 2.6.11)
Peter Chubb writes: > There are three new system calls: > > long usr_pci_open(int bus, int slot, int function, __u64 dma_mask); > Returns a filedescriptor for the PCI device described > by bus,slot,function. It also enables the device, and sets it > up as a bus-mastering DMA device, with the specified dma mask. You forgot the PCI domain (a.k.a. hose, phb...) number. Also, you might encode bus,slot,function according to the PCI spec. So that gives: long usr_pci_open(unsigned pcidomain, unsigned devspec, __u64 dmamask); (with the user library returning an int instead of long) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI Express Advanced Error Reporting Driver
On Thu, Mar 10, 2005 at 03:04:18PM -0800, long wrote: > PCI Express error signaling can occur on the PCI Express link itself > or on behalf of transactions initiated on the link. PCI Express > defines the Advanced Error Reporting capability, which is implemented > with a PCI Express advanced error reporting extended capability > structure, to provide more robust error reporting. With the Advanced > Error Reporting capability a PCI Express component, which detects an > error, can send an error message to the Root Port associated with > its hierarchy. This patch was too big for lkml, and should also be sent to the linux-pci list. Care to split it up and resend it? Also, how does this tie into the recent discussion about pci error recovery? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.10-as7
Hi, 2.6.10-as is now in purely maintenance mode; that is, I'll only include security fixes or quick things that people send me (that don't require much effort on my part :). This includes the security fix from 2.6.11.2. I'll have 2.6.11-as1 soon, after I sync up w/ Debian stuff and go through about 800 more changesets. We'll see where 2.6.x.y goes from there; if feeding patches is easy, then there won't be much need for -as; otherwise, I'll continue doing it as a vendor base (at least one person who does vendor kernels has expressed the opinion that they'd prefer 2.6.x.y to be a bit more liberal than it currently is). Also, note the email address; I'm trying to phase out usage of my voxel.net address, as I no longer work there. The -as tree is intended to include only security and bugfixes, from various sources. I do not include hardware driver updates (specifically, anything that changes how the hardware registers themselves are probed/poked), large subsystem updates, cleanups, and so on; only fixes that will not contain regressions. The hope is that vendors/distributors can use this tree as a base for their kernels. It is also what I'd want a 2.6.x.y tree to have. The kernel patches can be grabbed from here: http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as7/ 86f79bd2e50963829da3c0456804df0f ChangeLog e852090bafa5ea4ff7c6b922d33ec1e7 linux-2.6.10-as7.tar.gz 8ca1ac89c1eac2111f146cc21d6193c2 patch-2.6.10-as7.gz Changes from 2.6.10-as6: 2005-03-10 21:51:49 GMT Andres Salomon <[EMAIL PROTECTED]> patch-155 Summary: tag 2.6.10-as7 Revision: linux--dilinger--0--patch-155 modified files: 000-extraversion.patch 2005-03-10 21:50:21 GMT Andres Salomon <[EMAIL PROTECTED]> patch-154 Summary: 144-sys_epoll_wait_int_overflow.patch Revision: linux--dilinger--0--patch-154 [SECURITY] sys_epoll_wait contains an integer overflow; see http://seclists.org/lists/fulldisclosure/2005/Mar/0293.html for additional details. new files: .arch-ids/144-sys_epoll_wait_int_overflow.patch.id 144-sys_epoll_wait_int_overflow.patch 2005-03-10 21:46:21 GMT Andres Salomon <[EMAIL PROTECTED]> patch-153 Summary: 143-sysfs_write_file_signedness_problem.patch Revision: linux--dilinger--0--patch-153 [SYSFS] sysfs_write_file assigns the result of fill_write_buffer (which is signed and returns negative upon error) to an unsigned int. Clearly, bad and wrong.. new files: .arch-ids/143-sysfs_write_file_signedness_problem.patch.id 143-sysfs_write_file_signedness_problem.patch -- Andres Salomon <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [PATCH, RFC 1/3] Add sem_getcount() to arches that lack it
On Thu, Mar 10, 2005 at 09:10:42PM -0800, Roland Dreier wrote: > Andrew> (Why do they want to do this anyway?) > > Neither use seems really fundamental. The XFS use is explicitly > inside #ifdef DEBUG and seems to be used only for assertions. Right, our peeking at that value is debug-only (so usually its not even compiled in). I wouldn't go out of your way to add a more permanent interface just for this, we can live without it. cheers. -- Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binary drivers and development
Lennart Sorensen writes: > You forgot the very important: >- Only works on architecture it was compiled for. So anyone not > using i386 (and maybe later x86-64) is simply out of luck. What do > nvidia users that want accelerated nvidia drivers for X DRI do > right now if they have a powerpc or a sparc or an alpha? How about > porting Linux to a new architecture. With binary drivers you now > start out with no drivers on the new architecture except for the > ones you have source for. Not very productive. Rik van Riel writes: > No, it wouldn't. I can use a source code driver on x86, > x86-64 and PPC64 systems, but a binary driver is only > usable on the architecture it was compiled for. > > Source code is way more portable than binary anything. The kernel already has an AML interpreter for ACPI. **duck** As for portability, AML would do the job. It beats typical vendor source code IMHO, because endianness and integer size are well-defined. (like the Java VM and .net) For the x86 and ia64 users, the AML interpreter is probably already compiled into the kernel. Most people need it to set up SMP or power management. So, no added bloat even. AML code is fairly well controlled and isolated. There is of course the backdoor via DMA for the truly determined evil author, but such paranoia is rather extreme. AML is really designed for this sort of task. As with any interpreter, there are ways (JIT) to make the AML interpreter go faster if need be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC 1/3] Add sem_getcount() to arches that lack it
Andrew> (Why do they want to do this anyway?) Neither use seems really fundamental. The XFS use is explicitly inside #ifdef DEBUG and seems to be used only for assertions. ieee1394 is just sticking the value in a read-only sysfs attribute. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IA32 (2.6.11 - 2005-03-10.16.00) - 1 New warnings
drivers/video/intelfb/intelfbdrv.h:31: warning: 'intelfb_setup' declared `static' but never defined - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microstate Accounting for 2.6.11
> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes: Andrew> Peter Chubb <[EMAIL PROTECTED]> wrote: >> Timing data on threads at present is pretty crude: when the timer >> interrupt occurs, a tick is added to either system time or user >> time for the currently running thread. Thus in an unpacthed kernel >> one can distinguish three timed states: On-cpu in userspace, on-cpu >> in system space, and not running. >> >> The actual number of states is much larger. A thread can be on a >> runqueue or the expired queue (i.e., ready to run but not running), >> sleeping on a semaphore or on a futex, having its time stolen to >> service an interrupt, etc., etc. >> >> This patch adds timers per-state to each struct task_struct, so >> that time in all these states can be tracked. This patch contains >> the core code do the timing, and to initialise the timers. >> Subsequent patches enable the code (by adding Kconfig options) and >> add hooks to track state changes. Andrew> Why does the kernel need this feature? I find that it's useful when trying to work out why a thread is going more slowly than it needs to. Userspace tools in the CVS repository at gelato.unsw.edu.au let you graph in real time the time spent in each state, so you get graphs like this: http://gelato.unsw.edu.au/patches/snapshot.png which shows mplay skipping because of a slow disk/filesystem. Andrew> Have you any numbers on the overhead? Around 5% on LMbench context switch numbers for uniprocessor, negligeable on SMP (but SMP context switch results are horrible at the moment according to LMbench2 -- almost 16usec); select on 10 fd goes from 1.665 usec to 1.701; Andrew> The preempt_disable() in sys_msa() seems odd. Yes I only added that yesterday. It's to prevent migration while updating the current timer. All the other places where the current timer are updated are naturally protected this. It should probably be a local_irq_disable() instead. Peter C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] -stable, how it's going to work.
Neil Brown wrote: If a data corruption bug has been there for 10 weeks without being noticed, then the real risk is not that great. We are calling it "-release", not "-hardened". I disagree. If there's a simple, obvious, small fix that passes all the other criteria, it should go into -stable ASAP after passing review. Then the -stable maintainers will push the fix to Andrew/Linux, and it will go into the next 2.6.x. Let's keep -stable as good as possible, while still abiding by all the other rules. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops / 2.6.11 / run_timer_softirq (mountvirtfs)
jerome lacoste <[EMAIL PROTECTED]> wrote: > > On an VIA EPIA board, I got this single oops at boot. Wasn't stored on > file so I had to take a screenshot with a digital camera. Basicallly > goes along those lines: > > Process: S36mountvirtfs > > Call trace: > run_timer_softirq+0x16f/0x200 > __do_softirq > do_softirq > irq_exit > do_IRQ > common_interrupt > > Process is found here on my system: > > lrwxr-xr-x 1 root root 21 Mar 1 00:29 /etc/rcS.d/S36mountvirtfs -> > ../init.d/mountvirtfs > > The exact screenshot (500k) can be found here: > > http://coffeebreaks.dyndns.org/~jerome/static/images/linux/oops_2.6.11_run_timer_softirq_boot.jpg > An oops in cascade() is tricky. Normally it means that some piece of code has done something bad with a kernel timer. Later, a clock tick happens and the kernel falls over. We're left with no hints as to which part of the kernel misbehaved. Please try enabling CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC and see if that reveals any additional info. Apart from that, you have a lot of modules configured there. Please try disabling them all, see if the oops goes away. If it does then try re-enabling them, see if you can narrow it down to the one which is causing the timer list corruption. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Average power consumption in S3?
On Thu, 2005-03-10 at 22:46 -0500, Theodore Ts'o wrote: > On Thu, Mar 10, 2005 at 07:08:26PM +0100, Moritz Muehlenhoff wrote: > > I've got the e100 and with WOL disabled and Matthew's hacked radeontool > > power consumption decreases to 970 mWh. > > I have a T40p, and with the following patches (versus 2.6.11) and the > following sleep script, I have power consuption down to 580 mWh. > > The 05-radeonfb-Thinkpad-Power.patch will have to patched with your > specific Thinkpad model number, or booted with the force_sleep option. > See the Linux thinkpad mailing list ([EMAIL PROTECTED]) > archives for more information. > > Warning: The 05-radeonfb-Thinkpad-Power.patch is not quite ready for > merging, but compared to completely pathetic battery life when using > ACPI's suspend-to-memory without them, it's definitely worth it. Hi Ted ! Hopefully, somebody is gathering those patches. I intend to merge them all at one point, though I can't promise it will happen before 2.6.12. It would be good to "ping" me regulary though ;) I've sort-of been waiting for ATI to tell me how to retreive the proper memory register setting from the BIOS, since the code in there currently is quite powerbook specific, and might not write the exact correct value on all models. I suppose it works fine on yours so far, but I'd rather have a way to know the right value ... unfortunately, they didn't reply on this request. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC 1/3] Add sem_getcount() to arches that lack it
Jody McIntyre <[EMAIL PROTECTED]> wrote: > > parisc and frv define sem_getcount() in semaphore.h, which returns the > current semaphore value. This is cleaner than doing > atomic_read(), currently done in > drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work > on all architectures if sem_getcount() is added. That's a fairly bizarre thing to want to do. Would it be hard to modify xfs and 1394 to stop wanting to read a semaphore's up() count? (Why do they want to do this anyway?) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inappropriate use of in_atomic()
> Consequently the use of in_atomic() in the below files is probably > deadlocky if CONFIG_PREEMPT=n: ... > drivers/infiniband/core/mad.c Thanks for pointing this out. I'll get you a patch in the next day or two. As you can probably tell, the code is just trying to decide whether to use GFP_ATOMIC or GFP_KERNEL to allocate a couple of things, depending on what context we're being called from. So at worst we can just change to GFP_ATOMIC unconditionally. I'll check into whether we can do something cleverer, but just going the GFP_ATOMIC route won't be horrible. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
inappropriate use of in_atomic()
in_atomic() is not a reliable indication of whether it is currently safe to call schedule(). This is because the lockdepth beancounting which in_atomic() uses is only accumulated if CONFIG_PREEMPT=y. in_atomic() will return false inside spinlocks if CONFIG_PREEMPT=n. Consequently the use of in_atomic() in the below files is probably deadlocky if CONFIG_PREEMPT=n: arch/ppc64/kernel/viopath.c drivers/net/irda/sir_kthread.c drivers/net/wireless/airo.c drivers/video/amba-clcd.c drivers/acpi/osl.c drivers/ieee1394/ieee1394_transactions.c drivers/infiniband/core/mad.c Note that the same beancounting is used for the "scheduling while atomic" warning, so if the code calls schedule with locks held, we won't get a warning. Both are tied to CONFIG_PREEMPT=y. The kernel provides no reliable runtime way of detecting whether or not it is safe to call schedule(). Can we please find ways to change the above code to not use in_atomic()? Then we can whack #ifndef MODULE around its definition to reduce reoccurrences. Will probably rename it to something more scary as well. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Microstate accounting, IA64 support
Microstate Accounting:
Add suppoort for IA64.
linux-2.6-ustate/arch/ia64/Kconfig | 25 +++
linux-2.6-ustate/arch/ia64/kernel/entry.S| 44 +++
linux-2.6-ustate/arch/ia64/kernel/irq_ia64.c | 21 +++-
linux-2.6-ustate/arch/ia64/kernel/ivt.S |8 +++-
linux-2.6-ustate/include/asm-ia64/msa.h | 33
linux-2.6-ustate/include/asm-ia64/unistd.h |1
7 files changed, 129 insertions(+), 5 deletions(-)
Index: linux-2.6-ustate/arch/ia64/Kconfig
===
--- linux-2.6-ustate.orig/arch/ia64/Kconfig 2005-03-10 09:13:01.780632777
+1100
+++ linux-2.6-ustate/arch/ia64/Kconfig 2005-03-10 09:16:14.593655619 +1100
@@ -302,6 +302,31 @@
little bigger and slows down execution a bit, but it is generally
a good idea to turn this on. If you're unsure, say Y.
+config MICROSTATE
+ bool "Microstate accounting"
+ help
+ This option causes the kernel to keep very accurate track of
+ how long your threads spend on the runqueues, running, or asleep or
+ stopped. It will slow down your kernel.
+ Times are reported in /proc/pid/msa and through a new msa()
+ system call.
+choice
+ depends on MICROSTATE
+ prompt "Microstate timing source"
+ default MICROSTATE_ITC
+ help
+ On IA64 one can use two timeing sources for the microstate
+ accounting; the on-chip interval counter, or Linux's
+ time-of-day clock. The first is very cheap; the other is
+ more accurate on SMP systems.
+
+config MICROSTATE_ITC
+ bool "Use on-chip ITC for microstate timing"
+
+config MICROSTATE_TOD
+ bool "Use time-of-day clock for microstate timings"
+endchoice
+
config IA64_PALINFO
tristate "/proc/pal support"
help
Index: linux-2.6-ustate/include/asm-ia64/msa.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-ustate/include/asm-ia64/msa.h 2005-03-10 09:16:14.594632174
+1100
@@ -0,0 +1,33 @@
+/
+ * asm-ia64/msa.h
+ *
+ * Provide an architecture-specific clock.
+ */
+
+#ifndef _ASM_IA64_MSA_H
+#define _ASM_IA64_MSA_H
+
+#include
+#include
+#include
+
+
+# if defined(CONFIG_MICROSTATE_ITC)
+# define MSA_NOW(now) do { now = (clk_t)get_cycles(); } while (0)
+
+# define MSA_TO_NSEC(clk) ((10*clk) /
cpu_data(smp_processor_id())->itc_freq)
+
+# elif defined(CONFIG_MICROSTATE_TOD)
+static inline void msa_now(clk_t *nsp) {
+ struct timeval tv;
+ do_gettimeofday();
+ *nsp = tv.tv_sec * 100 + tv.tv_usec;
+}
+# define MSA_NOW(x) msa_now()
+# define MSA_TO_NSEC(clk) ((clk) * 1000)
+
+# else
+# include
+# endif
+
+#endif /* _ASM_IA64_MSA_H */
Microstate Accounting: Track time in system calls for IA64
arch/ia64/kernel/entry.S | 44
arch/ia64/kernel/ivt.S |8 ++--
2 files changed, 50 insertions(+), 2 deletions(-)
Index: linux-2.6-ustate/arch/ia64/kernel/entry.S
===
--- linux-2.6-ustate.orig/arch/ia64/kernel/entry.S 2005-03-10
09:13:01.149778160 +1100
+++ linux-2.6-ustate/arch/ia64/kernel/entry.S 2005-03-10 09:16:15.157128068
+1100
@@ -589,6 +589,46 @@
.ret4: br.cond.sptk ia64_leave_kernel
END(ia64_strace_leave_kernel)
+#ifdef CONFIG_MICROSTATE
+/*
+ * preserve input registers,
+ * and r8
+ */
+GLOBAL_ENTRY(invoke_msa_end_syscall)
+ .prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(8)
+ alloc loc1=ar.pfs,8,4,0,0
+ mov loc0=rp
+ .body
+ ;;
+ mov loc2=ret0
+ mov loc3=ret2
+ br.call.sptk.many rp=msa_end_syscall
+1: mov rp=loc0
+ mov ret0=loc2
+ mov ret2=loc3
+ mov ar.pfs=loc1
+ br.ret.sptk.many rp
+END(invoke_msa_end_syscall)
+/*
+ * Preserves in0-7, and all callee-save registers.
+ */
+GLOBAL_ENTRY(invoke_msa_start_syscall)
+ .prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(8)
+ alloc loc1=ar.pfs,8,4,0,0
+ mov loc0=rp
+ .body
+ mov loc2=r3
+ mov loc3=r15
+ ;;
+ br.call.sptk.many rp=msa_start_syscall
+1: mov r15=loc3
+ mov r3=loc2
+ mov ar.pfs=loc1
+ mov rp=loc0
+ br.ret.sptk.many rp
+END(invoke_msa_start_syscall)
+#endif /* CONFIG_MICROSTATE */
+
GLOBAL_ENTRY(ia64_ret_from_clone)
PT_REGS_UNWIND_INFO(0)
{ /*
@@ -671,6 +711,10 @@
*/
ENTRY(ia64_leave_syscall)
PT_REGS_UNWIND_INFO(0)
+#ifdef CONFIG_MICROSTATE
+ br.call.sptk.many rp=invoke_msa_end_syscall
+1:
+#endif
/*
* work.need_resched etc. mustn't get changed by this CPU before it
returns to
* user- or fsys-mode, hence we
Re: AGP bogosities
On Thu, 2005-03-10 at 20:02 -0800, Jesse Barnes wrote: > On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote: > > That one is even worse... from what I see in your lspci output, you have > > no bridge with AGP capability at all, and the various AGP devices are > > all siblings... > > Both of the video cards are sitting on agp busses in agp slots hooked up to > host to agp bridges. > > > Are you sure there is any real AGP slot in there ? > > Yes :) Well, according to your lspci, none of the bridges exposes a device with AGP capabilities... It looks like you aren't exposing the host "self" device on the bus. Do you have an AGP driver ? If yes, it certainly can't use any of the generic code anyway ... I still think that the matching between a bridge and a card should be a bridge callback (with eventually a generic one that works for whatever x86 are around) so that the bridge driver can deal with funky layouts. I have no time to toy with this at the moment though ;) Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AGP support for powermac G5
Hi. On Fri, 2005-03-11 at 15:02, Paul Mackerras wrote: > Nigel Cunningham writes: > > > No power management support? :> > > The suspend/resume methods are in the pci_driver struct, not the > agp_bridge_driver struct. Not that we have suspend/resume on the G5 > yet. Ah. Thought I'd seen some in others. Humble apologies. Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://suspend2.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AGP support for powermac G5
> > No power management support? :> Heh, not yet :) We can't really put a G5 to sleep yet. I haven't figured out the magic incantations for the PMU chip on those. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microstate Accounting for 2.6.11
Peter Chubb <[EMAIL PROTECTED]> wrote: > > Timing data on threads at present is pretty crude: when the timer > interrupt occurs, a tick is added to either system time or user time > for the currently running thread. Thus in an unpacthed kernel one can > distinguish three timed states: On-cpu in userspace, on-cpu in system > space, and not running. > > The actual number of states is much larger. A thread can be on a > runqueue or the expired queue (i.e., ready to run but not running), > sleeping on a semaphore or on a futex, having its time stolen to > service an interrupt, etc., etc. > > This patch adds timers per-state to each struct task_struct, so that > time in all these states can be tracked. This patch contains the core > code do the timing, and to initialise the timers. Subsequent patches > enable the code (by adding Kconfig options) and add hooks to track > state changes. Why does the kernel need this feature? Have you any numbers on the overhead? The preempt_disable() in sys_msa() seems odd. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Microstate Accounting for 2.6.11, patch 4/6
Microstate accounting: Account for time in interrupt handlers for I386.
arch/i386/kernel/irq.c | 13 -
1 files changed, 12 insertions(+), 1 deletion(-)
Index: linux-2.6-ustate/arch/i386/kernel/irq.c
===
--- linux-2.6-ustate.orig/arch/i386/kernel/irq.c2005-03-10
09:13:00.115606274 +1100
+++ linux-2.6-ustate/arch/i386/kernel/irq.c 2005-03-10 09:16:16.032121680
+1100
@@ -55,6 +55,8 @@
#endif
irq_enter();
+ msa_start_irq(irq);
+
#ifdef CONFIG_DEBUG_STACKOVERFLOW
/* Debugging check for stack overflow: is there less than 1KB free? */
{
@@ -101,6 +103,7 @@
#endif
__do_IRQ(irq, regs);
+ msa_finish_irq(irq);
irq_exit();
return 1;
@@ -221,10 +224,18 @@
seq_printf(p, "%3d: ",i);
#ifndef CONFIG_SMP
seq_printf(p, "%10u ", kstat_irqs(i));
+#ifdef CONFIG_MICROSTATE
+ seq_printf(p, "%10llu", msa_irq_time(0, i));
+#endif
#else
for (j = 0; j < NR_CPUS; j++)
- if (cpu_online(j))
+ if (cpu_online(j)) {
seq_printf(p, "%10u ", kstat_cpu(j).irqs[i]);
+#ifdef CONFIG_MICROSTATE
+ seq_printf(p, "%10llu", msa_irq_time(j, i));
+#endif
+ }
+
#endif
seq_printf(p, " %14s", irq_desc[i].handler->typename);
seq_printf(p, " %s", action->name);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AGP support for powermac G5
Nigel Cunningham writes: > No power management support? :> The suspend/resume methods are in the pci_driver struct, not the agp_bridge_driver struct. Not that we have suspend/resume on the G5 yet. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote: > That one is even worse... from what I see in your lspci output, you have > no bridge with AGP capability at all, and the various AGP devices are > all siblings... Both of the video cards are sitting on agp busses in agp slots hooked up to host to agp bridges. > Are you sure there is any real AGP slot in there ? Yes :) Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Microstate Accounting for 2.6.11, patch 6/6
Microstate accounting: Track time spent asleep while paging, in poll() or select(), or on a futex separately from other sleeps. fs/select.c |2 ++ kernel/futex.c |2 ++ mm/memory.c |6 +- Index: linux-2.6-ustate/mm/memory.c === --- linux-2.6-ustate.orig/mm/memory.c 2005-03-10 09:12:59.492564100 +1100 +++ linux-2.6-ustate/mm/memory.c2005-03-10 09:16:16.583875465 +1100 @@ -2079,6 +2079,7 @@ if (is_vm_hugetlb_page(vma)) return VM_FAULT_SIGBUS; /* mapping truncation does this. */ + msa_next_state(current, PAGING_SLEEP); /* * We need the page table lock to synchronize with kswapd * and the SMP-safe atomic PTE updates. @@ -2098,10 +2099,13 @@ if (!pte) goto oom; - return handle_pte_fault(mm, vma, address, write_access, pte, pmd); + int ret = handle_pte_fault(mm, vma, address, write_access, pte, pmd); + msa_next_state(current, MSA_UNKNOWN); + return ret; oom: spin_unlock(>page_table_lock); + msa_next_state(current, MSA_UNKNOWN); return VM_FAULT_OOM; } Index: linux-2.6-ustate/kernel/futex.c === --- linux-2.6-ustate.orig/kernel/futex.c2005-03-10 09:12:58.843154938 +1100 +++ linux-2.6-ustate/kernel/futex.c 2005-03-10 09:16:17.109262256 +1100 @@ -39,6 +39,7 @@ #include #include #include +#include #define FUTEX_HASHBITS (CONFIG_BASE_SMALL ? 4 : 8) @@ -571,6 +572,7 @@ * wakes us up. */ + msa_next_state(current, FUTEX_SLEEP); /* add_wait_queue is the barrier after __set_current_state. */ __set_current_state(TASK_INTERRUPTIBLE); add_wait_queue(, ); Index: linux-2.6-ustate/fs/select.c === --- linux-2.6-ustate.orig/fs/select.c 2005-03-10 09:12:59.182996124 +1100 +++ linux-2.6-ustate/fs/select.c2005-03-10 09:16:16.843639194 +1100 @@ -256,6 +256,7 @@ retval = table.error; break; } + msa_next_state(current, POLL_SLEEP); __timeout = schedule_timeout(__timeout); } __set_current_state(TASK_RUNNING); @@ -447,6 +448,7 @@ count = wait->error; if (count) break; + msa_next_state(current, POLL_SLEEP); timeout = schedule_timeout(timeout); } __set_current_state(TASK_RUNNING); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Microstate Accounting for 2.6.11, patch 5/6
Microstate accounting: Add the I386 system call. arch/i386/kernel/entry.S |2 +- include/asm-i386/unistd.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6-ustate/arch/i386/kernel/entry.S === --- linux-2.6-ustate.orig/arch/i386/kernel/entry.S 2005-03-10 09:16:14.888575341 +1100 +++ linux-2.6-ustate/arch/i386/kernel/entry.S 2005-03-10 09:16:15.446188457 +1100 @@ -876,7 +876,7 @@ .long sys_mq_getsetattr .long sys_ni_syscall/* reserved for kexec */ .long sys_waitid - .long sys_ni_syscall/* 285 */ /* available */ + .long sys_msa /* 285 */ /* available */ .long sys_add_key .long sys_request_key .long sys_keyctl Index: linux-2.6-ustate/include/asm-i386/unistd.h === --- linux-2.6-ustate.orig/include/asm-i386/unistd.h 2005-03-10 09:13:00.813843194 +1100 +++ linux-2.6-ustate/include/asm-i386/unistd.h 2005-03-10 09:16:15.448141568 +1100 @@ -290,7 +290,7 @@ #define __NR_mq_getsetattr (__NR_mq_open+5) #define __NR_sys_kexec_load283 #define __NR_waitid284 -/* #define __NR_sys_setaltroot 285 */ +#define __NR_sys_msa 285 #define __NR_add_key 286 #define __NR_request_key 287 #define __NR_keyctl288 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Make primary boot video device detection more robust
When detecting the boot video device, allow for the case of multiple
cards on the same bus. Check each candidate to make sure that the card
is active.
Signed off by: Jon Smirl <[EMAIL PROTECTED]>
--
Jon Smirl
[EMAIL PROTECTED]
= arch/i386/pci/fixup.c 1.24 vs edited =
--- 1.24/arch/i386/pci/fixup.c 2005-01-11 19:42:41 -05:00
+++ edited/arch/i386/pci/fixup.c2005-03-10 22:50:30 -05:00
@@ -343,7 +343,7 @@
/*
* Fixup to mark boot BIOS video selected by BIOS before it changes
*
- * From information provided by "Jon Smirl" <[EMAIL PROTECTED]>
+ * From information provided by "Jon Smirl" <[EMAIL PROTECTED]>
*
* The standard boot ROM sequence for an x86 machine uses the BIOS
* to select an initial video card for boot display. This boot video
@@ -355,11 +355,12 @@
* is marked here since the boot video device will be the only enabled
* video device at this point.
*
- */static void __devinit pci_fixup_video(struct pci_dev *pdev)
+ */
+static void __devinit pci_fixup_video(struct pci_dev *pdev)
{
struct pci_dev *bridge;
struct pci_bus *bus;
- u16 l;
+ u16 config;
if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
return;
@@ -369,12 +370,16 @@
while (bus) {
bridge = bus->self;
if (bridge) {
- pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, );
- if (!(l & PCI_BRIDGE_CTL_VGA))
+ pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
);
+ if (!(config & PCI_BRIDGE_CTL_VGA))
return;
}
bus = bus->parent;
}
- pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+ pci_read_config_word(pdev, PCI_COMMAND, );
+ if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
+ pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+ printk(KERN_DEBUG "Boot video device is %s\n", pci_name(pdev));
+ }
}
DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Microstate Accounting for 2.6.11, patch 3/6
Microstate accounting:
Provide I386-dependent MSA clocks, and Kconfig options.
arch/i386/Kconfig | 39 ++-
include/asm-i386/msa.h | 49 +
2 files changed, 87 insertions(+), 1 deletion(-)
Signed-off-by: Peter Chubb <[EMAIL PROTECTED]>
Index: linux-2.6-ustate/arch/i386/Kconfig
===
--- linux-2.6-ustate.orig/arch/i386/Kconfig 2005-03-11 09:59:38.773632446
+1100
+++ linux-2.6-ustate/arch/i386/Kconfig 2005-03-11 09:59:38.777538666 +1100
@@ -923,8 +923,45 @@
If unsure, say Y. Only embedded should say N here.
-endmenu
+config MICROSTATE
+ bool "Microstate accounting"
+ help
+ This option causes the kernel to keep very accurate track of
+how long your threads spend on the runqueues, running, or asleep or
+stopped. It will slow down your kernel.
+Times are reported in /proc/pid/msa and through a new msa()
+system call.
+
+choice
+ depends on MICROSTATE
+ prompt "Microstate timing source"
+ default MICROSTATE_TSC
+
+config MICROSTATE_PM
+ bool "Use Power-Management timer for microstate timings"
+ depends on X86_PM_TIMER
+ help
+If your machine is ACPI enabled and uses power-management, then the
+TSC runs at a variable rate, which will distort the
+microstate measurements. This timer, although having
+slightly more overhead, and a lower resolution (279
+nanoseconds or so) will always run at a constant rate.
+
+config MICROSTATE_TSC
+ bool "Use on-chip TSC for microstate timings"
+ depends on X86_TSC
+ help
+ If your machine's clock runs at constant rate, then this timer
+gives you cycle precision in measureing times spent in microstates.
+
+config MICROSTATE_TOD
+ bool "Use time-of-day clock for microstate timings"
+ help
+ If none of the other timers are any good for you, this timer
+will give you micro-second precision.
+endchoice
+endmenu
menu "Power management options (ACPI, APM)"
depends on !X86_VOYAGER
Index: linux-2.6-ustate/include/asm-i386/msa.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-ustate/include/asm-i386/msa.h 2005-03-11 09:59:38.779491777
+1100
@@ -0,0 +1,49 @@
+/
+ * asm-i386/msa.h
+ *
+ * Provide an architecture-specific clock.
+ */
+
+#ifndef _ASM_I386_MSA_H
+# define _ASM_I386_MSA_H
+
+# include
+
+
+# if defined(CONFIG_MICROSTATE_TSC)
+/*
+ * Use the processor's time-stamp counter as a timesource
+ */
+# include
+# include
+
+# define MSA_NOW(now) rdtscll(now)
+
+extern unsigned long cpu_khz;
+# define MSA_TO_NSEC(clk) ({ clk_t _x = ((clk) * 100ULL); do_div(_x,
cpu_khz); _x; })
+
+# elif defined(CONFIG_MICROSTATE_PM)
+/*
+ * Use the system's monotonic clock as a timesource.
+ * This will only be enabled if the Power Management Timer is enabled.
+ */
+unsigned long long monotonic_clock(void);
+# define MSA_NOW(now) do { now = monotonic_clock(); } while (0)
+# define MSA_TO_NSEC(clk) (clk)
+
+# elif defined(CONFIG_MICROSTATE_TOD)
+/*
+ * Fall back to gettimeofday.
+ * This one is incompatible with interrupt-time measurement on some processors.
+ */
+static inline void msa_now(clk_t *nsp) {
+ struct timeval tv;
+ do_gettimeofday();
+ *nsp = tv.tv_sec * 100 + tv.tv_usec;
+}
+# define MSA_NOW(x) msa_now()
+# define MSA_TO_NSEC(clk) ((clk) * 1000)
+# endif
+
+
+#endif /* _ASM_I386_MSA_H */
I386
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AGP support for powermac G5
Hi.
On Fri, 2005-03-11 at 14:02, Paul Mackerras wrote:
> +struct agp_bridge_driver u3_agp_driver = {
> + .owner = THIS_MODULE,
> + .aperture_sizes = (void *)u3_sizes,
> + .size_type = U32_APER_SIZE,
> + .num_aperture_sizes = 8,
> + .configure = uninorth_configure,
> + .fetch_size = uninorth_fetch_size,
> + .cleanup= uninorth_cleanup,
> + .tlb_flush = uninorth_tlbflush,
> + .mask_memory= agp_generic_mask_memory,
> + .masks = NULL,
> + .cache_flush= null_cache_flush,
> + .agp_enable = uninorth_agp_enable,
> + .create_gatt_table = uninorth_create_gatt_table,
> + .free_gatt_table= uninorth_free_gatt_table,
> + .insert_memory = u3_insert_memory,
> + .remove_memory = u3_remove_memory,
> + .alloc_by_type = agp_generic_alloc_by_type,
> + .free_by_type = agp_generic_free_by_type,
> + .agp_alloc_page = agp_generic_alloc_page,
> + .agp_destroy_page = agp_generic_destroy_page,
> + .cant_use_aperture = 1,
> + .needs_scratch_page = 1,
> +};
> +
No power management support? :>
Regards,
Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574
Maintainer of Suspend2 Kernel Patches http://suspend2.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Microstate Accounting for 2.6.11, patch 2/6
Microstate Accounting:
Add hooks into the scheduler to track state changes.
Arrange for parent process's child times to be updated at process exit.
kernel/sched.c |8
kernel/exit.c |3 +++
Index: linux-2.6-ustate/kernel/sched.c
===
--- linux-2.6-ustate.orig/kernel/sched.c2005-03-11 09:59:31.109628035
+1100
+++ linux-2.6-ustate/kernel/sched.c 2005-03-11 09:59:31.116463921 +1100
@@ -635,6 +635,7 @@
*/
static inline void __activate_task(task_t *p, runqueue_t *rq)
{
+ msa_set_timer(p, ONACTIVEQUEUE);
enqueue_task(p, rq->active);
rq->nr_running++;
}
@@ -1238,6 +1239,7 @@
if (unlikely(!current->array))
__activate_task(p, rq);
else {
+ msa_set_timer(p, ONACTIVEQUEUE);
p->prio = current->prio;
list_add_tail(>run_list, >run_list);
p->array = current->array;
@@ -2422,6 +2424,7 @@
if (!rq->expired_timestamp)
rq->expired_timestamp = jiffies;
if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq)) {
+ msa_next_state(p, ONEXPIREDQUEUE);
enqueue_task(p, rq->expired);
if (p->static_prio < rq->best_expired_prio)
rq->best_expired_prio = p->static_prio;
@@ -2733,6 +2736,7 @@
array = rq->active;
rq->expired_timestamp = 0;
rq->best_expired_prio = MAX_PRIO;
+ msa_flip_expired(prev);
} else
schedstat_inc(rq, sched_noswitch);
@@ -2773,6 +2777,8 @@
rq->curr = next;
++*switch_count;
+ msa_switch(prev, next);
+
prepare_arch_switch(rq, next);
prev = context_switch(rq, prev, next);
barrier();
@@ -3693,6 +3699,8 @@
*/
if (rt_task(current))
target = rq->active;
+ else
+ msa_next_state(current, ONEXPIREDQUEUE);
if (current->array->nr_active == 1) {
schedstat_inc(rq, yld_act_empty);
Index: linux-2.6-ustate/kernel/exit.c
===
--- linux-2.6-ustate.orig/kernel/exit.c 2005-03-11 09:59:36.360564796 +1100
+++ linux-2.6-ustate/kernel/exit.c 2005-03-11 09:59:36.364471017 +1100
@@ -93,6 +93,9 @@
}
sched_exit(p);
+
+ msa_update_parent(p->parent, p);
+
write_unlock_irq(_lock);
spin_unlock(>proc_lock);
proc_pid_flush(proc_dentry);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Microstate Accounting for 2.6.11, patch 3/
Microstate Accounting: Track time in system calls and interrupts, i386 code.
Signed-off-by; Peter Chubb <[EMAIL PROTECTED]>
arch/i386/kernel/entry.S | 16
arch/i386/kernel/irq.c | 13 -
Index: linux-2.6-ustate/arch/i386/kernel/entry.S
===
--- linux-2.6-ustate.orig/arch/i386/kernel/entry.S 2005-03-10
09:13:01.448604031 +1100
+++ linux-2.6-ustate/arch/i386/kernel/entry.S 2005-03-10 09:16:14.888575341
+1100
@@ -222,10 +222,18 @@
/* Note, _TIF_SECCOMP is bit number 8, and so it needs testw and not
testb */
testw
$(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP),TI_flags(%ebp)
jnz syscall_trace_entry
+#ifdef CONFIG_MICROSTATE
+ pushl %eax
+ call msa_start_syscall
+ popl%eax
+#endif
cmpl $(nr_syscalls), %eax
jae syscall_badsys
call *sys_call_table(,%eax,4)
movl %eax,EAX(%esp)
+#ifdef CONFIG_MICROSTATE
+ call msa_end_syscall
+#endif
cli
movl TI_flags(%ebp), %ecx
testw $_TIF_ALLWORK_MASK, %cx
@@ -250,9 +258,17 @@
cmpl $(nr_syscalls), %eax
jae syscall_badsys
syscall_call:
+#ifdef CONFIG_MICROSTATE
+ pushl %eax
+ call msa_start_syscall
+ popl%eax
+#endif
call *sys_call_table(,%eax,4)
movl %eax,EAX(%esp) # store the return value
syscall_exit:
+#ifdef CONFIG_MICROSTATE
+ call msa_end_syscall
+#endif
cli # make sure we don't miss an interrupt
# setting need_resched or sigpending
# between sampling and the iret
Index: linux-2.6-ustate/arch/i386/kernel/irq.c
===
--- linux-2.6-ustate.orig/arch/i386/kernel/irq.c2005-03-10
09:13:00.115606274 +1100
+++ linux-2.6-ustate/arch/i386/kernel/irq.c 2005-03-10 09:16:16.032121680
+1100
@@ -55,6 +55,8 @@
#endif
irq_enter();
+ msa_start_irq(irq);
+
#ifdef CONFIG_DEBUG_STACKOVERFLOW
/* Debugging check for stack overflow: is there less than 1KB free? */
{
@@ -101,6 +103,7 @@
#endif
__do_IRQ(irq, regs);
+ msa_finish_irq(irq);
irq_exit();
return 1;
@@ -221,10 +224,18 @@
seq_printf(p, "%3d: ",i);
#ifndef CONFIG_SMP
seq_printf(p, "%10u ", kstat_irqs(i));
+#ifdef CONFIG_MICROSTATE
+ seq_printf(p, "%10llu", msa_irq_time(0, i));
+#endif
#else
for (j = 0; j < NR_CPUS; j++)
- if (cpu_online(j))
+ if (cpu_online(j)) {
seq_printf(p, "%10u ", kstat_cpu(j).irqs[i]);
+#ifdef CONFIG_MICROSTATE
+ seq_printf(p, "%10llu", msa_irq_time(j, i));
+#endif
+ }
+
#endif
seq_printf(p, " %14s", irq_desc[i].handler->typename);
seq_printf(p, " %s", action->name);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Average power consumption in S3?
On Thu, Mar 10, 2005 at 07:08:26PM +0100, Moritz Muehlenhoff wrote:
> I've got the e100 and with WOL disabled and Matthew's hacked radeontool
> power consumption decreases to 970 mWh.
I have a T40p, and with the following patches (versus 2.6.11) and the
following sleep script, I have power consuption down to 580 mWh.
The 05-radeonfb-Thinkpad-Power.patch will have to patched with your
specific Thinkpad model number, or booted with the force_sleep option.
See the Linux thinkpad mailing list ([EMAIL PROTECTED])
archives for more information.
Warning: The 05-radeonfb-Thinkpad-Power.patch is not quite ready for
merging, but compared to completely pathetic battery life when using
ACPI's suspend-to-memory without them, it's definitely worth it.
- Ted
From: Christian Borntraeger <[EMAIL PROTECTED]>
During the wakeup from suspend-to-ram I get several warnings.
Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/acpi/osl.c |4 ++--
25-akpm/drivers/acpi/pci_link.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff -puN drivers/acpi/osl.c~acpi-sleep-while-atomic-during-s3-resume-from-ram
drivers/acpi/osl.c
--- 25/drivers/acpi/osl.c~acpi-sleep-while-atomic-during-s3-resume-from-ram
2005-01-16 00:45:23.784364208 -0800
+++ 25-akpm/drivers/acpi/osl.c 2005-01-16 00:45:23.789363448 -0800
@@ -145,7 +145,7 @@ acpi_os_vprintf(const char *fmt, va_list
void *
acpi_os_allocate(acpi_size size)
{
- return kmalloc(size, GFP_KERNEL);
+ return kmalloc(size, GFP_ATOMIC);
}
void
@@ -905,7 +905,7 @@ acpi_os_wait_semaphore(
ACPI_DEBUG_PRINT ((ACPI_DB_MUTEX, "Waiting for semaphore[%p|%d|%d]\n",
handle, units, timeout));
- if (in_atomic())
+ if (in_atomic() || irqs_disabled())
timeout = 0;
switch (timeout)
diff -puN
drivers/acpi/pci_link.c~acpi-sleep-while-atomic-during-s3-resume-from-ram
drivers/acpi/pci_link.c
---
25/drivers/acpi/pci_link.c~acpi-sleep-while-atomic-during-s3-resume-from-ram
2005-01-16 00:45:23.785364056 -0800
+++ 25-akpm/drivers/acpi/pci_link.c 2005-01-16 00:45:23.790363296 -0800
@@ -315,7 +315,7 @@ acpi_pci_link_set (
if (!link || !irq)
return_VALUE(-EINVAL);
- resource = kmalloc( sizeof(*resource)+1, GFP_KERNEL);
+ resource = kmalloc( sizeof(*resource)+1, GFP_ATOMIC);
if(!resource)
return_VALUE(-ENOMEM);
_
This is needed to remove another sleeping function called from invalid
context error message when resuming from sleep.
Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]>
Index: src/drivers/acpi/utils.c
===
--- src.orig/drivers/acpi/utils.c 2005-03-03 13:08:44.0 -0500
+++ src/drivers/acpi/utils.c2005-03-03 13:10:04.0 -0500
@@ -252,7 +252,7 @@
if (!data)
return_ACPI_STATUS(AE_BAD_PARAMETER);
- element = kmalloc(sizeof(union acpi_object), GFP_KERNEL);
+ element = kmalloc(sizeof(union acpi_object), GFP_ATOMIC);
if(!element)
return_ACPI_STATUS(AE_NO_MEMORY);
= drivers/video/aty/radeon_base.c 1.40 vs edited =
--- 1.40/drivers/video/aty/radeon_base.c2005-02-15 21:25:30 -05:00
+++ edited/drivers/video/aty/radeon_base.c 2005-02-17 20:30:48 -05:00
@@ -273,6 +273,9 @@
#ifdef CONFIG_MTRR
static int nomtrr = 0;
#endif
+#if defined(CONFIG_PM) && defined(CONFIG_X86)
+int radeon_force_sleep = 0;
+#endif
/*
* prototypes
@@ -2535,6 +2538,10 @@
force_measure_pll = 1;
} else if (!strncmp(this_opt, "ignore_edid", 11)) {
ignore_edid = 1;
+#if defined(CONFIG_PM) && defined(CONFIG_X86)
+ } else if (!strncmp(this_opt, "force_sleep", 11)) {
+ radeon_force_sleep = 1;
+#endif
} else
mode_option = this_opt;
}
@@ -2574,3 +2581,5 @@
MODULE_PARM_DESC(panel_yres, "int: set panel yres");
module_param(mode_option, charp, 0);
MODULE_PARM_DESC(mode_option, "Specify resolution as
\"x[-][@]\" ");
+module_param(radeon_force_sleep, int, 0);
+MODULE_PARM_DESC(radeon_force_sleep, "bool: force ACPI sleep mode on untested
machines");
= drivers/video/aty/radeon_pm.c 1.10 vs edited =
--- 1.10/drivers/video/aty/radeon_pm.c 2005-02-12 23:01:11 -05:00
+++ edited/drivers/video/aty/radeon_pm.c2005-02-17 20:23:57 -05:00
@@ -25,8 +25,97 @@
#include
#endif
+/* For detecting supported PC laptops */
+#ifdef CONFIG_X86
+#include
+#endif
+
#include "ati_ids.h"
+#ifdef CONFIG_X86
+/* This array holds a list of supported PC laptops.
+ * Currently only few IBM models are tested.
+ * If you want to experiment, use dmidecode to find out
+ * vendor and product codes for Your laptop.
+ */
+static struct dmi_system_id
Microstate Accounting for 2.6.11
Microstate Accounting
-
Timing data on threads at present is pretty crude: when the timer
interrupt occurs, a tick is added to either system time or user time
for the currently running thread. Thus in an unpacthed kernel one can
distinguish three timed states: On-cpu in userspace, on-cpu in system
space, and not running.
The actual number of states is much larger. A thread can be on a
runqueue or the expired queue (i.e., ready to run but not running),
sleeping on a semaphore or on a futex, having its time stolen to
service an interrupt, etc., etc.
This patch adds timers per-state to each struct task_struct, so that
time in all these states can be tracked. This patch contains the core
code do the timing, and to initialise the timers. Subsequent patches
enable the code (by adding Kconfig options) and add hooks to track
state changes.
Signed-off-by: Peter Chubb <[EMAIL PROTECTED]>
include/asm-generic/msa.h | 21 ++
include/linux/msa-kernel.h | 99 +
include/linux/msa.h| 46
include/linux/sched.h |4
kernel/Makefile|2
kernel/fork.c |2
kernel/msa.c | 472 +
7 files changed, 645 insertions(+), 1 deletion(-)
Index: linux-2.6-ustate/kernel/msa.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-ustate/kernel/msa.c 2005-03-11 09:58:20.574030768 +1100
@@ -0,0 +1,472 @@
+/*
+ * Microstate accounting.
+ * Try to account for various states much more accurately than
+ * the normal code does.
+ *
+ * Copyright (c) Peter Chubb 2005
+ * UNSW and National ICT Australia
+ * This code is released under the Gnu Public Licence, version 2.
+ */
+
+
+#include
+#include
+#include
+#include
+#ifdef CONFIG_MICROSTATE
+#include
+#include
+#include
+#include
+
+#include
+
+/*
+ * Track time spend in interrupt handlers.
+ */
+struct msa_irq {
+ clk_t times;
+ clk_t last_entered;
+};
+
+/*
+ * When the scheduler last swapped active and expired queues
+ */
+static DEFINE_PER_CPU(clk_t, queueflip_time);
+
+/*
+ * Time spent in interrupt handlers
+ */
+static DEFINE_PER_CPU(struct msa_irq[NR_IRQS+1], msa_irq);
+
+
+/**
+ * msa_switch: Update microstate timers when switching from one task to
another.
+ * @prev, @next: The prev task is coming off the processor;
+ *the new task is about to run on the processor.
+ *
+ * Update the times in both prev and next. It may be necessary to infer the
+ * next state for each task.
+ *
+ */
+void
+msa_switch(struct task_struct *prev, struct task_struct *next)
+{
+ struct microstates *msprev = >microstates;
+ struct microstates *msnext = >microstates;
+ clk_t now;
+ enum thread_state next_state;
+ int interrupted = msprev->cur_state == INTERRUPTED;
+
+ preempt_disable();
+
+ MSA_NOW(now);
+
+ if (msprev->flags & QUEUE_FLIPPED) {
+ __get_cpu_var(queueflip_time) = now;
+ msprev->flags &= ~QUEUE_FLIPPED;
+ }
+
+ /*
+* If the queues have been flipped,
+* update the state as of the last flip time.
+*/
+ if (msnext->cur_state == ONEXPIREDQUEUE) {
+ clk_t qfp = per_cpu(queueflip_time, msnext->lastqueued);
+ msnext->cur_state = ONACTIVEQUEUE;
+ msnext->timers[ONEXPIREDQUEUE] += qfp - msnext->last_change;
+ msnext->last_change = qfp;
+ }
+
+ msprev->timers[msprev->cur_state] += now - msprev->last_change;
+ msnext->timers[msnext->cur_state] += now - msnext->last_change;
+
+ /* Update states */
+ switch (msprev->next_state) {
+ case MSA_UNKNOWN:
+ /*
+* Infer from actual state
+*/
+ switch (prev->state) {
+ case TASK_INTERRUPTIBLE:
+ next_state = INTERRUPTIBLE_SLEEP;
+ break;
+
+ case TASK_UNINTERRUPTIBLE:
+ next_state = UNINTERRUPTIBLE_SLEEP;
+ break;
+
+ case TASK_STOPPED:
+ next_state = STOPPED;
+ break;
+
+ case EXIT_DEAD:
+ case EXIT_ZOMBIE:
+ next_state = ZOMBIE;
+ break;
+
+ case TASK_RUNNING:
+ next_state = ONACTIVEQUEUE;
+ break;
+
+ default:
+ next_state = MSA_UNKNOWN;
+ break;
+
+ }
+ break;
+
+ case PAGING_SLEEP: /*
+ * Sleep states are PAGING_SLEEP;
+ * others inferred from task state
+ */
+
Re: pci_fixup_video() bogosity
On Thu, 2005-03-10 at 22:39 -0500, Jon Smirl wrote: > Patch to make detection of boot video device more robust. Should I > leave the printk in? Hrm... yes, but make it KERN_DEBUG. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pci_fixup_video() bogosity
Patch to make detection of boot video device more robust. Should I
leave the printk in?
--
Jon Smirl
[EMAIL PROTECTED]
= arch/i386/pci/fixup.c 1.24 vs edited =
--- 1.24/arch/i386/pci/fixup.c 2005-01-11 19:42:41 -05:00
+++ edited/arch/i386/pci/fixup.c2005-03-10 22:32:35 -05:00
@@ -355,11 +355,12 @@
* is marked here since the boot video device will be the only enabled
* video device at this point.
*
- */static void __devinit pci_fixup_video(struct pci_dev *pdev)
+ */
+static void __devinit pci_fixup_video(struct pci_dev *pdev)
{
struct pci_dev *bridge;
struct pci_bus *bus;
- u16 l;
+ u16 config;
if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
return;
@@ -369,12 +370,16 @@
while (bus) {
bridge = bus->self;
if (bridge) {
- pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, );
- if (!(l & PCI_BRIDGE_CTL_VGA))
+ pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
);
+ if (!(config & PCI_BRIDGE_CTL_VGA))
return;
}
bus = bus->parent;
}
- pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+ pci_read_config_word(pdev, PCI_COMMAND, );
+ if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
+ pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+ printk(KERN_INFO "Boot video device is %s\n", pci_name(pdev));
+ }
}
DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
FEB_comms statement - Best so far
To contact us, please do_not_replyto. See the bottom of this email to contact us by telephone or email. It's absolutely right. You are going to get emails like this very soon Quickly, send me an email or call me and you will get real com.miss.ion emails with this subject line and big, big comm_ission pa.yments from all the bus_inesses you pro_mote. To pro.ve it, for a limit_ed per_iod I will give.you 10 sign_ups (that will p.a.y. to j.o.i.n. your bus.in.ess) and I will not ask you for a sin.gle cent/penny to get you star-ted. Use these to gen_erate an in.stant in.com_e. Then sitback & watch the_sign_ups join_you inst_antly in their droves and without you having to do much_at all. At the end of March you will get comm_ission state_ments showing that you have ear.ned tens_of thou_s_ands of doll_ars from your existing bus..iness.oppo.rtun.it.ies. Miss. this and def_in.it.ely miss.out on the ea-sie.st and fas.test mo.ney that you will ever ma.ke from your bu.sin_ess opp.or-tuni.ty You can call me on 00 44 791-365-8094 or +44 791-365-8094 or from USA 001 44 791-365-8094 or email me on [EMAIL PROTECTED] Please ring my number if you can't get through via email. My number is a normal rate UK mobile telephone. Thank you Jane Yale If you want to stop getting my emails please send me an email to [EMAIL PROTECTED] with "US" in the subject. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
User mode drivers: part 2: PCI device handling (patch 2/2 for 2.6.11)
User-level drivers: Add system calls for I386 and IA64. Signed-Off-By: Peter Chubb <[EMAIL PROTECTED]> # # arch/i386/kernel/entry.S |4 # arch/ia64/kernel/entry.S |8 # include/asm-i386/unistd.h |6 +- # include/asm-ia64/unistd.h |4 # 4 files changed, 17 insertions(+), 5 deletions(-) # Index: linux-2.6.11-usrdrivers/arch/ia64/kernel/entry.S === --- linux-2.6.11-usrdrivers.orig/arch/ia64/kernel/entry.S 2005-03-11 13:59:28.940744950 +1100 +++ linux-2.6.11-usrdrivers/arch/ia64/kernel/entry.S2005-03-11 13:59:41.236542676 +1100 @@ -1577,10 +1577,10 @@ data8 sys_add_key data8 sys_request_key data8 sys_keyctl - data8 sys_ni_syscall - data8 sys_ni_syscall// 1275 - data8 sys_ni_syscall - data8 sys_ni_syscall + data8 sys_usr_pci_open + data8 sys_usr_pci_mmap // 1275 + data8 sys_usr_pci_munmap + data8 sys_usr_pci_get_consistent data8 sys_ni_syscall data8 sys_ni_syscall Index: linux-2.6.11-usrdrivers/include/asm-i386/unistd.h === --- linux-2.6.11-usrdrivers.orig/include/asm-i386/unistd.h 2005-03-11 13:59:28.942698059 +1100 +++ linux-2.6.11-usrdrivers/include/asm-i386/unistd.h 2005-03-11 13:59:41.245331667 +1100 @@ -294,8 +294,12 @@ #define __NR_add_key 286 #define __NR_request_key 287 #define __NR_keyctl288 +#define __NR_usr_pci_open 289 +#define __NR_usr_pci_mmap (__NR_usr_pci_open+1) +#define __NR_usr_pci_munmap(__NR_usr_pci_open+2) +#define __NR_usr_pci_get_consistent(__NR_usr_pci_open+3) -#define NR_syscalls 289 +#define NR_syscalls 293 /* * user-visible error numbers are in the range -1 - -128: see Index: linux-2.6.11-usrdrivers/include/asm-ia64/unistd.h === --- linux-2.6.11-usrdrivers.orig/include/asm-ia64/unistd.h 2005-03-11 13:59:28.942698059 +1100 +++ linux-2.6.11-usrdrivers/include/asm-ia64/unistd.h 2005-03-11 13:59:41.247284776 +1100 @@ -263,6 +263,10 @@ #define __NR_add_key 1271 #define __NR_request_key 1272 #define __NR_keyctl1273 +#define __NR_usr_pci_open 1274 +#define __NR_usr_pci_mmap 1275 +#define __NR_usr_pci_unmap 1276 +#define __NR_usr_pci_get_consistent 1277 #ifdef __KERNEL__ Index: linux-2.6.11-usrdrivers/arch/i386/kernel/entry.S === --- linux-2.6.11-usrdrivers.orig/arch/i386/kernel/entry.S 2005-03-11 13:59:28.941721505 +1100 +++ linux-2.6.11-usrdrivers/arch/i386/kernel/entry.S2005-03-11 13:59:41.248261330 +1100 @@ -864,5 +864,9 @@ .long sys_add_key .long sys_request_key .long sys_keyctl + .long sys_usr_pci_open + .long sys_usr_pci_mmap /* 290 */ + .long sys_usr_pci_munmap + .long sys_usr_pci_get_consistent syscall_table_size=(.-sys_call_table) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
User mode drivers: part 2: PCI device handling (patch 1/2 for 2.6.11)
USER LEVEL DRIVERS: enable PCI device drivers at user space. This patch adds the capability for suitably privileged user-level processes to enable a PCI device, and set up DMA for it. A subsequent patch hooks up the actual system calls. There are three new system calls: long usr_pci_open(int bus, int slot, int function, __u64 dma_mask); Returns a filedescriptor for the PCI device described by bus,slot,function. It also enables the device, and sets it up as a bus-mastering DMA device, with the specified dma mask. Error codes are: ENOMEM: insufficient kernel memory to fulfil your request ENOENT: the specified device doesn't exist, or is otherwise invisible to Linux. EBUSY: Another driver has claimed the device EIO: The specified dma mask is invalid for this device. ENFILE: too many open files long usr_pci_get_consistent(int fd, size_t size, void **vaddrp, unsigned long *dmaaddrp) Call pci_alloc_consistent() to get size worth of pci consistent memory (currently an error if size != PAGESIZE); map the allocated memory into the user's address space; return the virtual user address in *vaddrp, and the bus address in *dmaaddrp ERRORS: EINVAL: the filedescriptor was not one obtained from usr_pci_open(), or size != PAGESIZE ENOMEM: insufficient appropriate memory or insufficient free virtual address space in the user program. EFAULT: vaddrp or dmaaddrp didn't point to writeable memory. The mapping obtained can be cleaned up with munmap(). long usr_pci_mmap(int fd, struct mapping_info *mp) -- map some memory for DMA to/from the device represented by fd, which was obtained from usr_pci_open(). struct mapping_info contains: void *virtaddr -- the virtual address to dma to int size -- how many bytes to set up struct usr_pci_sglist *sglist -- a pointer to a scatterlist int nents -- how many entries in the scatterlist enum dma_data_direction direction --- which way the dma is going to happen. The scatterlist should be sized at least size/PAGESIZE + 2. usr_pci_mmap() will call pci_map_sg() on the virtual region, then copy the resulting scatterlist into *sglist. The nents field will be updated with the actual number of scatterlist entries filled in. Failure codes are: EINVAL: the fd wasn't obtained from usr_pci_open, or direction wasn't one of DMA_TO_DEVICE, DMA_FROM_DEVICE or DMA_BIDIRECTIONAL, or the size of the scatterlist is insufficient to map the region. EFAULT: mp was a bad pointer, or the region of memory spanned by (virtaddr, virtaddr + size) was not all mapped. ENOMEM: insufficient appropriate memory long usr_pci_munmap(int fd, struct mapping_info *mp) Unmap a dma region mapped by usr_pci_map(). Struct mapping info is the same one used in usr_pci_mmap(). Error codes are: EINVAL: : the fd wasn't obtained from usr_pci_open, or the struct mapping_info was never mapped for this device Signed-off-by: Peter Chubb <[EMAIL PROTECTED]> # # drivers/Makefile |3 # drivers/pci/Kconfig|6 # drivers/usr/Makefile |2 # drivers/usr/sys.c | 952 + # include/linux/usrdrv.h | 63 +++ # 5 files changed, 1026 insertions(+) # Index: linux-2.6.11-usrdrivers/drivers/Makefile === --- linux-2.6.11-usrdrivers.orig/drivers/Makefile 2005-03-11 12:25:29.169139978 +1100 +++ linux-2.6.11-usrdrivers/drivers/Makefile2005-03-11 12:25:41.159270471 +1100 @@ -13,6 +13,9 @@ # was used and do nothing if so obj-$(CONFIG_PNP) += pnp/ +# User level device drivers +obj-$(CONFIG_USRDEV) += usr/ + # char/ comes before serial/ etc so that the VT console is the boot-time # default. obj-y += char/ Index: linux-2.6.11-usrdrivers/drivers/usr/Makefile === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.11-usrdrivers/drivers/usr/Makefile2005-03-11 12:25:41.160247026 +1100 @@ -0,0 +1,2 @@ +obj-y += sys.o +obj-$(CONFIG_USRBLKDEV) += blkdev.o Index: linux-2.6.11-usrdrivers/drivers/usr/sys.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.11-usrdrivers/drivers/usr/sys.c 2005-03-11 14:15:59.897394833 +1100 @@ -0,0 +1,952 @@ +/* + * Expose PCI-DMA interface to user mode. + * + * Copyright 2005 Peter Chubb + * National ICT
User mode drivers: part 1, interrupt handling (patch for 2.6.11)
As many of you will be aware, we've been working on infrastructure for
user-mode PCI and other drivers. The first step is to be able to
handle interrupts from user space. Subsequent patches add
infrastructure for setting up DMA for PCI devices.
The user-level interrupt code doesn't depend on the other patches, and
is probably the most mature of this patchset.
This patch adds a new file to /proc/irq// called irq. Suitably
privileged processes can open this file. Reading the file returns the
number of interrupts (if any) that have occurred since the last read.
If the file is opened in blocking mode, reading it blocks until
an interrupt occurs. poll(2) and select(2) work as one would expect, to
allow interrupts to be one of many events to wait for.
(If you didn't like the file, one could have a special system call to
return the file descriptor).
Interrupts are usually masked; while a thread is in poll(2) or read(2) on the
file they are unmasked.
All architectures that use CONFIG_GENERIC_HARDIRQ are supported by
this patch.
A low latency user level interrupt handler would do something like
this, on a CONFIG_PREEMPT kernel:
int irqfd;
int n_ints;
struct sched_param sched_param;
irqfd = open("/proc/irq/513/irq", O_RDONLY);
mlockall()
sched_param.sched_priority = sched_get_priority_max(SCHED_FIFO) - 10;
sched_setscheduler(0, SCHED_FIFO, _param);
while(read(irqfd, n_ints, sizeof n_ints) == sizeof nints) {
... talk to device to handle interrupt
}
If you don't care about latency, then forget about the mlockall() and
setting the priority, and you don't need CONFIG_PREEMPT.
Signed-off-by: Peter Chubb <[EMAIL PROTECTED]>
kernel/irq/proc.c | 163 ++
1 files changed, 153 insertions(+), 10 deletions(-)
Index: linux-2.6.11-usrdrivers/kernel/irq/proc.c
===
--- linux-2.6.11-usrdrivers.orig/kernel/irq/proc.c 2005-03-11
10:30:57.875619102 +1100
+++ linux-2.6.11-usrdrivers/kernel/irq/proc.c 2005-03-11 10:45:07.146928168
+1100
@@ -9,6 +9,8 @@
#include
#include
#include
+#include
+#include "internals.h"
static struct proc_dir_entry *root_irq_dir, *irq_dir[NR_IRQS];
@@ -90,27 +92,168 @@
action->dir = proc_mkdir(name, irq_dir[irq]);
}
+struct irq_proc {
+ unsigned long irq;
+ wait_queue_head_t q;
+ atomic_t count;
+ char devname[TASK_COMM_LEN];
+};
+
+static irqreturn_t irq_proc_irq_handler(int irq, void *vidp, struct pt_regs
*regs)
+{
+ struct irq_proc *idp = (struct irq_proc *)vidp;
+
+ BUG_ON(idp->irq != irq);
+ disable_irq_nosync(irq);
+ atomic_inc(>count);
+ wake_up(>q);
+ return IRQ_HANDLED;
+}
+
+
+/*
+ * Signal to userspace an interrupt has occured.
+ */
+static ssize_t irq_proc_read(struct file *filp, char __user *bufp, size_t
len, loff_t *ppos)
+{
+ struct irq_proc *ip = (struct irq_proc *)filp->private_data;
+ irq_desc_t *idp = irq_desc + ip->irq;
+ int pending;
+
+ DEFINE_WAIT(wait);
+
+ if (len < sizeof(int))
+ return -EINVAL;
+
+ pending = atomic_read(>count);
+ if (pending == 0) {
+ if (idp->status & IRQ_DISABLED)
+ enable_irq(ip->irq);
+ if (filp->f_flags & O_NONBLOCK)
+ return -EWOULDBLOCK;
+ }
+
+ while (pending == 0) {
+ prepare_to_wait(>q, , TASK_INTERRUPTIBLE);
+ pending = atomic_read(>count);
+ if (pending == 0)
+ schedule();
+ finish_wait(>q, );
+ if (signal_pending(current))
+ return -ERESTARTSYS;
+ }
+
+ if (copy_to_user(bufp, , sizeof pending))
+ return -EFAULT;
+
+ *ppos += sizeof pending;
+
+ atomic_sub(pending, >count);
+ return sizeof pending;
+}
+
+
+static int irq_proc_open(struct inode *inop, struct file *filp)
+{
+ struct irq_proc *ip;
+ struct proc_dir_entry *ent = PDE(inop);
+ int error;
+
+ ip = kmalloc(sizeof *ip, GFP_KERNEL);
+ if (ip == NULL)
+ return -ENOMEM;
+
+ memset(ip, 0, sizeof(*ip));
+ strcpy(ip->devname, current->comm);
+ init_waitqueue_head(>q);
+ atomic_set(>count, 0);
+ ip->irq = (unsigned long)ent->data;
+
+ error = request_irq(ip->irq,
+ irq_proc_irq_handler,
+ SA_INTERRUPT,
+ ip->devname,
+ ip);
+ if (error < 0) {
+ kfree(ip);
+ return error;
+ }
+ filp->private_data = (void *)ip;
+
+ return 0;
+}
+
+static int irq_proc_release(struct inode *inop, struct file *filp)
+{
+ struct irq_proc *ip = (struct irq_proc *)filp->private_data;
Re: current linus bk, error mounting root
On Thu, 10 Mar 2005 19:11:37 -0800, Matt Mackall <[EMAIL PROTECTED]> wrote: > On Thu, Mar 10, 2005 at 01:52:59PM -0500, Jon Smirl wrote: > > Here's a big clue, if I build ata_piix in I can boot. If it is a > > module I can't. The console output definitely shows that the module is > > being loaded. > > Can you post your config? The attached config works. If you change CONFIG_SCSI_ATA_PIIX to a module (make sure it is on initrd) it will fail. I have been running with CONFIG_SCSI_ATA_PIIX as a module since 2.5.30 or so. -- Jon Smirl [EMAIL PROTECTED] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11 # Thu Mar 10 17:53:22 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_CPUSETS is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODE is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=m # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set # CONFIG_ACPI_CONTAINER is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD
Re: [uml-devel] [PATCH 3/9] UML - "Hardware" random number generator
On Wednesday 09 March 2005 09:15 pm, Jeff Dike wrote: > This implements a hardware random number generator for UML which attaches > itself to the host's /dev/random. Direct use of /dev/random always makes me nervous. I've had a recurring problem with /dev/random blocking, and generally configure as much as possible to use /dev/urandom instead. It's really easy for a normal user to drain the /dev/random entropy pool on a server (at least one that doesn't have a sound card you can tell it to read white noise from). cat /dev/random > /dev/null I like /dev/urandom because it'll feed you as much entropy as it's got, but won't block, and will presumably round-robin insert real entropy in the streams that multiple users get from /dev/urandom. (I realize this may not be the best place to get gpg keys from.) I'm just thinking about those UML hosting farms, with several UML instances per machine, on machines which haven't got a keyboard attached constantly feeding entropy into the pool. If just ONE of them is serving ssl connections from its own /dev/urandom, that would drain the /dev/random entropy pool on the host machine almost immediately... Admittedly if UML used /dev/urandom instead of /dev/random, it wouldn't know how much "real" randomness it was getting and how much synthetic randomness, but this makes predicting the numbers it's producing easier how? Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: current linus bk, error mounting root
On Thu, Mar 10, 2005 at 01:52:59PM -0500, Jon Smirl wrote: > Here's a big clue, if I build ata_piix in I can boot. If it is a > module I can't. The console output definitely shows that the module is > being loaded. Can you post your config? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri, Mar 11, 2005 at 01:40:24PM +1100, Benjamin Herrenschmidt wrote: > > > After it does that pci_dev_put on the from, it does another pci_dev_get > > on 'dev', which is what my put was releasing. > > > > Or am I terribly confused ? > > Well, pci_get_class() put's the passed-in device and get's() the > returned one. So if you run it in a loop, you should never have to > either get or put. When you exit the loop with a valid pci_dev, though, > you should definitely put() it after you're done with it, but this is > something that should be done only for that specific instance and after > you are finished with it... Yeah. Makes perfect sense now I've had it spelled out for me :-) I think Linus is right though that some extra bullet-proofing in kref_put to BUG() if it goes negative would've caught this. I wonder if anyone else has fallen into this trap. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Thu, 2005-03-10 at 18:18 -0800, Jesse Barnes wrote: > On Thursday, March 10, 2005 6:11 pm, Paul Mackerras wrote: > > What is the relationship in the PCI device tree between the video > > cards and their bridges? Is there for instance only one AGP bridge > > per host bridge? > > I *think* a TIO (numalink<->agp & numalink<->pci) has two AGP busses coming > off of it... > > > Interesting, could you post the output from lspci -v on that system? > > flatearth:~ # lspci -v .../... That one is even worse... from what I see in your lspci output, you have no bridge with AGP capability at all, and the various AGP devices are all siblings... Are you sure there is any real AGP slot in there ? I'm afraid we may have to do the card <-> bridge machine as a bridge specific function. At least the bridge driver can "know" how the HW for that specific bridge lays out the PCI view of the AGP slot. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] AGP support for powermac G5
This patch adds AGP support for the U3 northbridge used in Apple G5
machines to drivers/char/agp/uninorth-agp.c. This patch is based on
earlier work by Jerome Glisse. With this patch, the driver works in
both ppc32 and ppc64 kernels.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/drivers/char/agp/Kconfig g5/drivers/char/agp/Kconfig
--- linux-2.5/drivers/char/agp/Kconfig 2005-03-07 14:01:44.0 +1100
+++ g5/drivers/char/agp/Kconfig 2005-03-11 13:53:47.0 +1100
@@ -1,6 +1,6 @@
config AGP
tristate "/dev/agpgart (AGP Support)" if !GART_IOMMU
- depends on ALPHA || IA64 || PPC32 || X86
+ depends on ALPHA || IA64 || PPC || X86
default y if GART_IOMMU
---help---
AGP (Accelerated Graphics Port) is a bus system mainly used to
@@ -146,11 +146,11 @@
default AGP
config AGP_UNINORTH
- tristate "Apple UniNorth AGP support"
+ tristate "Apple UniNorth & U3 AGP support"
depends on AGP && PPC_PMAC
help
This option gives you AGP support for Apple machines with a
- UniNorth bridge.
+ UniNorth or U3 (Apple G5) bridge.
config AGP_EFFICEON
tristate "Transmeta Efficeon support"
diff -urN linux-2.5/drivers/char/agp/uninorth-agp.c
g5/drivers/char/agp/uninorth-agp.c
--- linux-2.5/drivers/char/agp/uninorth-agp.c 2005-03-11 11:47:37.0
+1100
+++ g5/drivers/char/agp/uninorth-agp.c 2005-03-11 11:54:54.0 +1100
@@ -9,8 +9,23 @@
#include
#include
#include
+#include
#include "agp.h"
+/*
+ * NOTES for uninorth3 (G5 AGP) supports :
+ *
+ * There maybe also possibility to have bigger cache line size for
+ * agp (see pmac_pci.c and look for cache line). Need to be investigated
+ * by someone.
+ *
+ * PAGE size are hardcoded but this may change, see asm/page.h.
+ *
+ * Jerome Glisse <[EMAIL PROTECTED]>
+ */
+static int uninorth_rev;
+static int is_u3;
+
static int uninorth_fetch_size(void)
{
int i;
@@ -40,14 +55,20 @@
static void uninorth_tlbflush(struct agp_memory *mem)
{
+ u32 ctrl = UNI_N_CFG_GART_ENABLE;
+
+ if (is_u3)
+ ctrl |= U3_N_CFG_GART_PERFRD;
pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_INVAL);
- pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_ENABLE);
- pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_2xRESET);
- pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_ENABLE);
+ ctrl | UNI_N_CFG_GART_INVAL);
+ pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, ctrl);
+
+ if (uninorth_rev <= 0x30) {
+ pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
+ ctrl | UNI_N_CFG_GART_2xRESET);
+ pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
+ ctrl);
+ }
}
static void uninorth_cleanup(void)
@@ -57,14 +78,16 @@
pci_read_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, );
if (!(tmp & UNI_N_CFG_GART_ENABLE))
return;
- pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_INVAL);
- pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
- 0);
- pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_2xRESET);
- pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
- 0);
+ tmp |= UNI_N_CFG_GART_INVAL;
+ pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, tmp);
+ pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, 0);
+
+ if (uninorth_rev <= 0x30) {
+ pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
+ UNI_N_CFG_GART_2xRESET);
+ pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
+ 0);
+ }
}
static int uninorth_configure(void)
@@ -87,8 +110,21 @@
* the AGP aperture isn't mapped at bus physical address 0
*/
agp_bridge->gart_bus_addr = 0;
+#ifdef CONFIG_PPC64
+ /* Assume U3 or later on PPC64 systems */
+ /* high 4 bits of GART physical address go in UNI_N_CFG_AGP_BASE */
+ pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_AGP_BASE,
+ (agp_bridge->gatt_bus_addr >> 32) & 0xf);
+#else
pci_write_config_dword(agp_bridge->dev,
UNI_N_CFG_AGP_BASE, agp_bridge->gart_bus_addr);
+#endif
+
+ if (is_u3) {
+ pci_write_config_dword(agp_bridge->dev,
+
Re: AGP bogosities
On Fri, Mar 11, 2005 at 01:35:40PM +1100, Benjamin Herrenschmidt wrote: > > > > > This part I'm not so sure about. > > The pci_get_class() call a few lines above will get a refcount that > > we will now never release. > > We will ... on the next loop iteration when we call pci_get_class again. Ohhh, duh. Yes. now I follow. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] -stable, how it's going to work.
On Fri, Mar 11, 2005 at 11:10:37AM +1100, Neil Brown wrote: > I didn't mean "If it fixes a regression, it should be accepted." > I meant "If it does not fix a regression, it should not be accepted." ... Presumably with the obvious exception for security fixes.--b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
> After it does that pci_dev_put on the from, it does another pci_dev_get > on 'dev', which is what my put was releasing. > > Or am I terribly confused ? Well, pci_get_class() put's the passed-in device and get's() the returned one. So if you run it in a loop, you should never have to either get or put. When you exit the loop with a valid pci_dev, though, you should definitely put() it after you're done with it, but this is something that should be done only for that specific instance and after you are finished with it... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
> > This part I'm not so sure about. > The pci_get_class() call a few lines above will get a refcount that > we will now never release. We will ... on the next loop iteration when we call pci_get_class again. > Thanks for taking a look at this. The absense of hardware to test > on means I pretty much rely on feedback from inclusion in -mm > to hear about problems like this before it hits mainline. > Unfortunatly, no-one with ppc64 tested it there it seems :-( And ppc32, and probably others... I have seen AGP layed out differently in quite a few cases Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Thu, 10 Mar 2005, Dave Jones wrote:
>
> >/* ARQSZ - Set the value to the maximum one.
> > @@ -642,11 +638,6 @@
> >return 0;
> >}
> >cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
> > - if (!cap_ptr) {
> > - pci_dev_put(device);
> > - continue;
> > - }
> > - cap_ptr = 0;
> >}
>
> This part I'm not so sure about.
> The pci_get_class() call a few lines above will get a refcount that
> we will now never release.
That's the part I rewrote in my version, I think that one is good.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri, 11 Mar 2005, Paul Mackerras wrote: > > The point is that pci_get_class does a pci_dev_put() on the "from" > parameter, so your code ended up doing a double put. Ahh, I missed that too. Hmm.. We seem to not have any tests for the counts becoming negative, and this would seem to be an easy mistake to make considering that both I and Dave did it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PPC64] Allow emulation of mfpvr on ppc64 kernel
Ingo Oeser writes: > Why not putting the required information into the AUX table > when executing your ELF programs? I loved this feature in the > ix86 arch. We do put an AT_HWCAP entry in the aux table, which is a bitmap of features supported by the cpu. But for some applications, such as programming the performance monitor hardware, you need to know the specific CPU model and version, and this is a way to provide that information. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11 on AMD64 traps
On Wed, 09 Mar 2005 20:45:35 +0100 Patrick McHardy <[EMAIL PROTECTED]> wrote: > > Michal Vanco wrote: > >> > >> I see this problem running 2.6.11 on dual AMD64: > >> > >> Running quagga routing daemon (ospf+bgp) and issuing "netstat -rn |wc > >> -l" command > >> while quagga tries to load more than 154000 routes from its bgp > >> neighbours causes this trap: > > This patch should fix it. The crash is caused by stale pointers, > the pointers in fib_iter_state are not reloaded after seq->stop() > followed by seq->start(pos > 0). Applied, thanks Patrick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can I get 200M contiguous physical memory?
Chris Wedgwood wrote: it's driver in windows can do it. windows can get 200MB of memory on a running system relaibly? does it swap like mad when you do this? I'm guessing that driver isn't too likely to pass WHQL testing on Windows either, whatever it's doing.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
Dave Jones writes:
> >cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
> > - if (!cap_ptr) {
> > - pci_dev_put(device);
> > - continue;
> > - }
> > - cap_ptr = 0;
> >}
>
> This part I'm not so sure about.
> The pci_get_class() call a few lines above will get a refcount that
> we will now never release.
The point is that pci_get_class does a pci_dev_put() on the "from"
parameter, so your code ended up doing a double put.
> Unfortunatly, no-one with ppc64 tested it there it seems :-(
I have only recently got AGP and DRI working on my G5. I'll post a
patch for AGP support on the G5 shortly.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Thursday, March 10, 2005 6:11 pm, Paul Mackerras wrote: > What is the relationship in the PCI device tree between the video > cards and their bridges? Is there for instance only one AGP bridge > per host bridge? I *think* a TIO (numalink<->agp & numalink<->pci) has two AGP busses coming off of it... > Interesting, could you post the output from lspci -v on that system? flatearth:~ # lspci -v :01:01.0 Co-processor: Silicon Graphics, Inc. IOC4 I/O controller (rev 4f) Flags: bus master, 66Mhz, medium devsel, latency 255, IRQ 60 Memory at c0080f20 (32-bit, non-prefetchable) :01:03.0 Class 0106: Vitesse Semiconductor VSC7174 PCI/PCI-X Serial ATA Host Bus Controller (rev 01) Subsystem: Vitesse Semiconductor VSC7174 PCI/PCI-X Serial ATA Host Bus Controller Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 61 Memory at c0080f30 (64-bit, non-prefetchable) Capabilities: [e0] PCI-X non-bridge device. Capabilities: [e8] Power Management version 2 Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/2 Enable- :01:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15) Subsystem: Silicon Graphics, Inc. SGI IO9/IO10 Gigabit Ethernet (Copper) Flags: bus master, 66Mhz, medium devsel, latency 48, IRQ 62 Memory at c0080f31 (64-bit, non-prefetchable) Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- :02:01.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE/SG (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Xpert 128 Flags: bus master, stepping, medium devsel, latency 64, IRQ 63 Memory at c008a400 (32-bit, prefetchable) [size=c0080fe2] I/O ports at c0080fa0 [size=256] Memory at c0080fe0 (32-bit, non-prefetchable) [size=16K] Expansion ROM at 0002 [disabled] Capabilities: [5c] Power Management version 1 :02:02.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Orange Micro Root Hub Flags: bus master, medium devsel, latency 8, IRQ 64 Memory at c0080fe04000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 :02:02.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Orange Micro Root Hub Flags: bus master, medium devsel, latency 8, IRQ 65 Memory at c0080fe05000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 :02:02.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI]) Subsystem: Orange Micro Root hub Flags: bus master, medium devsel, latency 68, IRQ 65 Memory at c0080fe06000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 :17:00.0 VGA compatible controller: ATI Technologies Inc R350 NK [Fire GL X2] (rev 80) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0152 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0, IRQ 67 Memory at c041c800 (32-bit, prefetchable) [size=c041c012] I/O ports at c04023001000 [size=256] Memory at c041c010 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 0002 [disabled] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 :17:00.1 Display controller: ATI Technologies Inc: Unknown device 4e6b (rev80) Subsystem: ATI Technologies Inc: Unknown device 0153 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0 Memory at c041d000 (32-bit, prefetchable) [size=c041c000] Memory at c041c011 (32-bit, non-prefetchable) [size=64K] Expansion ROM at Capabilities: [50] Power Management version 2 :1b:00.0 VGA compatible controller: ATI Technologies Inc R350 NK [Fire GL X2] (rev 80) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0152 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0, IRQ 66 Memory at c0c1c800 (32-bit, prefetchable) [size=c0c1c012] I/O ports at c0c023001000 [size=256] Memory at c0c1c010 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 0002 [disabled] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 :1b:00.1 Display controller: ATI Technologies Inc: Unknown device 4e6b (rev80) Subsystem: ATI Technologies Inc: Unknown device 0153 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0 Memory at
Re: AGP bogosities
On Fri, Mar 11, 2005 at 01:18:36PM +1100, Paul Mackerras wrote:
> Dave Jones writes:
>
> > > cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
> > > - if (!cap_ptr) {
> > > - pci_dev_put(device);
> > > - continue;
> > > - }
> > > - cap_ptr = 0;
> > > }
> >
> > This part I'm not so sure about.
> > The pci_get_class() call a few lines above will get a refcount that
> > we will now never release.
>
> The point is that pci_get_class does a pci_dev_put() on the "from"
> parameter, so your code ended up doing a double put.
After it does that pci_dev_put on the from, it does another pci_dev_get
on 'dev', which is what my put was releasing.
Or am I terribly confused ?
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri, Mar 11, 2005 at 12:24:54PM +1100, Paul Mackerras wrote:
> In fact there are other bogosities in drivers/char/agp/generic.c. I
> can't believe Dave ever tested that code with an AGP 3.0 device.
Hrmm, I'm fairly sure I did. It's also been sat in -mm without complaint
for a few weeks, which is odd.
> you pass in a mode that has the AGP 3.0 bit set, agp_v3_parse_one()
> will first clear that bit (and print a message), and then complain
> because you haven't got that bit set in the mode, with a message that
> the caller is broken. Furthermore, if the mode passed in has both the
> 4x and 8x bits set, the new code will give you 4x where the old code
> would give you 8x (which is what the caller wanted).
>
> The patch below fixes these problems. It will work in the 99.99% of
> cases where we have one AGP bridge and one AGP video card. We should
> eventually cope with multiple AGP bridges, but doing the matching of
> bridges to video cards is a hard problem because the video card is not
> necessarily a child or sibling of the PCI device that we use for
> controlling the AGP bridge. I think we need to see an actual example
> of a system with multiple AGP bridges first.
>
> Oh, and by the way, I have 3D working relatively well on my G5 with a
> 64-bit kernel (and 32-bit X server and clients), which is why I care
> about AGP 3.0 support. :)
>
> Paul.
>
> diff -urN linux-2.5/drivers/char/agp/agp.h g5-bad/drivers/char/agp/agp.h
> --- linux-2.5/drivers/char/agp/agp.h 2005-03-07 14:01:44.0 +1100
> +++ g5/drivers/char/agp/agp.h2005-03-11 11:54:54.0 +1100
> @@ -322,7 +322,7 @@
> #define AGPCTRL_GTLBEN (1<<7)
>
> #define AGP2_RESERVED_MASK 0x00fffcc8
> -#define AGP3_RESERVED_MASK 0x00ff00cc
> +#define AGP3_RESERVED_MASK 0x00ff00c4
>
> #define AGP_ERRATA_FASTWRITES 1<<0
> #define AGP_ERRATA_SBA 1<<1
> diff -urN linux-2.5/drivers/char/agp/generic.c
> g5-bad/drivers/char/agp/generic.c
> --- linux-2.5/drivers/char/agp/generic.c 2005-03-11 11:47:37.0
> +1100
> +++ g5/drivers/char/agp/generic.c2005-03-11 12:08:29.0 +1100
> @@ -515,13 +515,9 @@
> printk (KERN_INFO PFX "%s tried to set rate=x0. Setting to AGP3
> x4 mode.\n", current->comm);
> *requested_mode |= AGPSTAT3_4X;
> }
> -if (tmp == 3) {
> -printk (KERN_INFO PFX "%s tried to set rate=x3. Setting to AGP3
> x4 mode.\n", current->comm);
> -*requested_mode |= AGPSTAT3_4X;
> -}
> -if (tmp >3) {
> -printk (KERN_INFO PFX "%s tried to set rate=x%d. Setting to
> AGP3 x8 mode.\n", current->comm, tmp);
> -*requested_mode |= AGPSTAT3_8X;
> +if (tmp >= 3) {
> +printk (KERN_INFO PFX "%s tried to set rate=x%d. Setting to
> AGP3 x8 mode.\n", current->comm, tmp * 4);
> +*requested_mode = (*requested_mode & ~7) | AGPSTAT3_8X;
> }
This seems to make sense.
> /* ARQSZ - Set the value to the maximum one.
> @@ -642,11 +638,6 @@
> return 0;
> }
> cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
> -if (!cap_ptr) {
> -pci_dev_put(device);
> -continue;
> -}
> -cap_ptr = 0;
> }
This part I'm not so sure about.
The pci_get_class() call a few lines above will get a refcount that
we will now never release.
Thanks for taking a look at this. The absense of hardware to test
on means I pretty much rely on feedback from inclusion in -mm
to hear about problems like this before it hits mainline.
Unfortunatly, no-one with ppc64 tested it there it seems :-(
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
Jesse Barnes writes: > I have a system in my office with several gfx pipes on different AGP busses, > and I'd like that to work well too! :) Interesting, could you post the output from lspci -v on that system? What is the relationship in the PCI device tree between the video cards and their bridges? Is there for instance only one AGP bridge per host bridge? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Thursday, March 10, 2005 5:24 pm, Paul Mackerras wrote: > The patch below fixes these problems. It will work in the 99.99% of > cases where we have one AGP bridge and one AGP video card. We should > eventually cope with multiple AGP bridges, but doing the matching of > bridges to video cards is a hard problem because the video card is not > necessarily a child or sibling of the PCI device that we use for > controlling the AGP bridge. I think we need to see an actual example > of a system with multiple AGP bridges first. We have real systems with multiple AGP bridges out there already, so we'd like to see this fixed properly. I think this is Mike's code, Mike? > Oh, and by the way, I have 3D working relatively well on my G5 with a > 64-bit kernel (and 32-bit X server and clients), which is why I care > about AGP 3.0 support. :) I have a system in my office with several gfx pipes on different AGP busses, and I'd like that to work well too! :) Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: re-inline sched functions
Andrew Morton wrote: "Chen, Kenneth W" <[EMAIL PROTECTED]> wrote: This could be part of the unknown 2% performance regression with db transaction processing benchmark. The four functions in the following patch use to be inline. They are un-inlined since 2.6.7. We measured that by re-inline them back on 2.6.9, it improves performance for db transaction processing benchmark, +0.2% (on real hardware :-) Can you also inline requeue_task? No performance gain expected, but it is just a simple wrapper around a list function. The cost is certainly larger kernel size, cost 928 bytes on x86, and 2728 bytes on ia64. But certainly worth the money for enterprise customer since they improve performance on enterprise workload. Less that 1k on x86 versus >2k on ia64. No wonder those things have such big caches ;) ... Possible we can introduce them back? OK by me. What happens if you leave task_timeslice out of line? It isn't exactly huge, but it is called from a handful of places. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri, 11 Mar 2005, Paul Mackerras wrote: > > Oh, and by the way, I have 3D working relatively well on my G5 with a > 64-bit kernel (and 32-bit X server and clients), which is why I care > about AGP 3.0 support. :) Ok, I can't even compile it on my G5, so you're obviously withholding some patches you shouldn't ;) Anyway, I fixed up the AGP discovery differently from your patch, so you should check that my version works for you. DaveJ, please give it a once-over too, since my G5 doesn't do the AGP thing yet. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11 low latency audio test results
On Thursday 10 March 2005 16:52, Lee Revell wrote: >On Wed, 2005-03-09 at 08:27 -0600, K.R. Foley wrote: >> Lee Revell wrote: >> > Of course all of the above settings provide flawless xrun-free >> > performance with 2.6.11-rc4 + PREEMPT_RT. >> >> The above mentioned patch will apply (and build and run) just fine >> to 2.6.11 if you fix the EXTRAVERSION portion of the patch to not >> expect -rc4. > >Right, it sure does. No rejects except the Makefile. > >Looks like the release candidate process is getting tighter. > >Lee > Maybe Lee, maybe. It kills tvtime, I built that into 2.6.11.2 yesterday to test. So I'm back in 2.6.11.2 with only the bk-ieee1394.patch applied over the .1 and .2 patches. >- >To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inode cache, dentry cache, buffer heads usage
Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > So, why is these slab cache are not getting purged/shrinked even > under memory pressure ? (I have seen lowmem as low as 6MB). What > can I do to keep the machine healthy ? Tried increasing /proc/sys/vm/vfs_cache_pressure? (That might not be in 2.6.8 though). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] -stable, how it's going to work.
On Thursday March 10, [EMAIL PROTECTED] wrote: > On Thu, 2005-03-10 at 21:00 +1100, Neil Brown wrote: > > One rule that I thought would make sense, but that I don't see listed > > is: > > > > - must fix a regression > > > > If some problem was in 2.6.X and is still there in 2.6.X+1, then there > > is no great rush to fix it for 2.6.(X+1).1, it can wait for 2.6.(X+2). > > this is tricky. I mean, what if it's a datacorruption thing? Sure older > kernels may have it too... yet at the same time it'd be nice to get it > fixed. And once you go down this slipperly slope you end up with the > original ruleset again, eg it must be "somehow relatively important". > My position is that - there are lots of things that "it'd be nice to get it fixed", and that is what 2.6.X is for - It is a very slippery slope - No one expect Linux to be perfect. But people do expect it to get better without getting worse. It is precisely to fix this expectation that (I understand) 2.6.x.y was created. If a data corruption bug has been there for 10 weeks without being noticed, then the real risk is not that great. We are calling it "-release", not "-hardened". Just my shilling-and-six worth. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Support for GEODE CPUs
So.. did we end up deciding that the Geode patch should be reverted wholesale? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [01/11] fix amd64 2.6.11 oops on modprobe (saa7110)
On Thu, 2005-03-10 at 15:07 -0800, Greg KH wrote: > -stable review patch. If anyone has any objections, please let us know. > > -- > > This is a rewrite of the saa7110_write_block function, which was plain > broken in the case where the underlying adapter supports I2C_FUNC_I2C. > It also includes related fixes which ensure that different parts of the > driver agree on the number of registers the chip has. > > Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> > Signed-off-by: Chris Wright <[EMAIL PROTECTED]> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > --- linux-2.6.11-bk3/drivers/media/video/saa7110.c.orig Tue Mar 8 > 10:27:15 2005 > +++ linux-2.6.11-bk3/drivers/media/video/saa7110.cTue Mar 8 12:02:45 2005 > @@ -58,10 +58,12 @@ > #define SAA7110_MAX_INPUT9 /* 6 CVBS, 3 SVHS */ > #define SAA7110_MAX_OUTPUT 0 /* its a decoder only */ > > -#define I2C_SAA7110 0x9C/* or 0x9E */ > +#define I2C_SAA7110 0x9C/* or 0x9E */ Not that I really care, but isn't there a rule that a patch "... can not contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc.)"? josh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AGP bogosities
Linus,
I see that you did a cset -x on a changeset from Dave Jones that added
a bogus test for which AGP bridge a device is under. That has left us
with code in agp_collect_device_status that will never find any device
(just take a look and you'll see).
In fact there are other bogosities in drivers/char/agp/generic.c. I
can't believe Dave ever tested that code with an AGP 3.0 device. If
you pass in a mode that has the AGP 3.0 bit set, agp_v3_parse_one()
will first clear that bit (and print a message), and then complain
because you haven't got that bit set in the mode, with a message that
the caller is broken. Furthermore, if the mode passed in has both the
4x and 8x bits set, the new code will give you 4x where the old code
would give you 8x (which is what the caller wanted).
The patch below fixes these problems. It will work in the 99.99% of
cases where we have one AGP bridge and one AGP video card. We should
eventually cope with multiple AGP bridges, but doing the matching of
bridges to video cards is a hard problem because the video card is not
necessarily a child or sibling of the PCI device that we use for
controlling the AGP bridge. I think we need to see an actual example
of a system with multiple AGP bridges first.
Oh, and by the way, I have 3D working relatively well on my G5 with a
64-bit kernel (and 32-bit X server and clients), which is why I care
about AGP 3.0 support. :)
Paul.
diff -urN linux-2.5/drivers/char/agp/agp.h g5-bad/drivers/char/agp/agp.h
--- linux-2.5/drivers/char/agp/agp.h2005-03-07 14:01:44.0 +1100
+++ g5/drivers/char/agp/agp.h 2005-03-11 11:54:54.0 +1100
@@ -322,7 +322,7 @@
#define AGPCTRL_GTLBEN (1<<7)
#define AGP2_RESERVED_MASK 0x00fffcc8
-#define AGP3_RESERVED_MASK 0x00ff00cc
+#define AGP3_RESERVED_MASK 0x00ff00c4
#define AGP_ERRATA_FASTWRITES 1<<0
#define AGP_ERRATA_SBA 1<<1
diff -urN linux-2.5/drivers/char/agp/generic.c g5-bad/drivers/char/agp/generic.c
--- linux-2.5/drivers/char/agp/generic.c2005-03-11 11:47:37.0
+1100
+++ g5/drivers/char/agp/generic.c 2005-03-11 12:08:29.0 +1100
@@ -515,13 +515,9 @@
printk (KERN_INFO PFX "%s tried to set rate=x0. Setting to AGP3
x4 mode.\n", current->comm);
*requested_mode |= AGPSTAT3_4X;
}
- if (tmp == 3) {
- printk (KERN_INFO PFX "%s tried to set rate=x3. Setting to AGP3
x4 mode.\n", current->comm);
- *requested_mode |= AGPSTAT3_4X;
- }
- if (tmp >3) {
- printk (KERN_INFO PFX "%s tried to set rate=x%d. Setting to
AGP3 x8 mode.\n", current->comm, tmp);
- *requested_mode |= AGPSTAT3_8X;
+ if (tmp >= 3) {
+ printk (KERN_INFO PFX "%s tried to set rate=x%d. Setting to
AGP3 x8 mode.\n", current->comm, tmp * 4);
+ *requested_mode = (*requested_mode & ~7) | AGPSTAT3_8X;
}
/* ARQSZ - Set the value to the maximum one.
@@ -642,11 +638,6 @@
return 0;
}
cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
- if (!cap_ptr) {
- pci_dev_put(device);
- continue;
- }
- cap_ptr = 0;
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: oom with 2.6.11
Andrew Morton wrote: > Christian Kujau <[EMAIL PROTECTED]> wrote: > >>i was going to compile 2.6.11-rc5-bk4, to sort out the "bad" kernel. >>compiling went fine. ok, finished some email, ok, suddenly my swap was >>used up again, and no memory left - uh oh! OOM again, with 2.6.11-rc5-bk2! > > > Well if you ran out of swap then yes, the oom-killer will visit you. > > Why did you run out of swapspace? hm, if i only knew. i don't know how long it took the other night to go from "normal" to "OOM". but today, with 2.6.11-rc5-bk2 (well, yesterday actually) i was working normally, and all of a sudden swap goes from 170MB used swap (normal) to OOM. i think it took a minute or so, but i just can't tell which application went nuts. today the first process that got killed was "ssh-agent", the other day it was mysqld. but even after this, it should've released some memory, right? but the oom-killer goes on and on and kills the next task. i'll monitor memory usage tonight and see what it gives. these "pppd" messages are suspicious though. thank you, Christian. -- BOFH excuse #135: You put the disk in upside down. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm2 + Radeon crash
> > When I try to start X, my machine reboots. The screen goes dark as > usual when setting the video mode, but then I get a beep and I'm > greeted with the BIOS boot messages. This happened 4/5 times i've > tried, and once the video mode was actually set (at least I saw the > usual X b/w pattern with some random framebuffer garbage), the machine > didn't reboot but after that nothing happened. My keyboard was still > responsive (ie NumLock LED would still go on/off), but i could neither > kill X with CTRL-ALT-BACKSPACE nor could i switch back to console, so > I ended up pressing reset. > > After the crashes I booted with a rescue CD to examine the logs, but I > could not find any obvious errors. > > Everything works nicely on 2.6.10 and earlier kernels. I'm in the > process of building 2.6.11.2 to see if the crash occurs there. > > Here is some info on my system: > > I've got an Athlon 1000C on a VIA KT133 chipset and a Radeon 7200 (the > original Radeon with 32MB SDR RAM). I'm running Debian/sid. > A copy of /var/log/XFree86.0.log and a copy of dmesg and copy of your .config if you could .. main things of interest whether you have fb drivers and drm drivers.. Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Someting's busted with serial in 2.6.11 latest
On Thursday 10 March 2005 03:59 pm, Russell King wrote: > On Thu, Mar 10, 2005 at 03:40:11PM -0700, Steven Cole wrote: > > I'll test current bk tonight, but I don't see any recent fix to > > drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6. > > Ok, so Stephen's bug is already fixed. After testing the latest bk, if > you find your bug isn't resolved, please try to isolate the change by > applying this patch. If this doesn't resolve it, then your change of > behaviour hasn't been caused by changes to 8250.c, but must be down to > some other part of the kernel. OK, latest 2.6.11-bk works just fine. Although I thought I had a failure with a fairly recent snapshot, I must have had a version before the fix. Sorry for any confusion. FWIW, the failing kernels reported: ttyS0 at I/O 0x3f8 (irq = 4) is a XScale But now, all is fine. Thanks. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add a clear_pages function to clear pages of higher order
Changelog:
- use Kconfig and CONFIG_CLEAR_PAGES
The zeroing of a page of a arbitrary order in page_alloc.c and in hugetlb.c may
benefit from a
clear_page that is capable of zeroing multiple pages at once. The following
patch adds
a function "clear_pages" that is capable of clearing multiple continuous pages
at once.
Patch against 2.6.11-bk6
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.11/mm/page_alloc.c
===
--- linux-2.6.11.orig/mm/page_alloc.c 2005-03-10 14:42:43.0 -0800
+++ linux-2.6.11/mm/page_alloc.c2005-03-10 15:01:53.0 -0800
@@ -628,11 +628,19 @@ void fastcall free_cold_page(struct page
free_hot_cold_page(page, 1);
}
-static inline void prep_zero_page(struct page *page, int order, int gfp_flags)
+void prep_zero_page(struct page *page, unsigned int order, unsigned int
gfp_flags)
{
int i;
BUG_ON((gfp_flags & (__GFP_WAIT | __GFP_HIGHMEM)) == __GFP_HIGHMEM);
+
+#ifdef CONFIG_CLEAR_PAGES
+ if (!PageHighMem(page)) {
+ clear_pages(page_address(page), order);
+ return;
+ }
+#endif
+
for(i = 0; i < (1 << order); i++)
clear_highpage(page + i);
}
Index: linux-2.6.11/mm/hugetlb.c
===
--- linux-2.6.11.orig/mm/hugetlb.c 2005-03-01 23:38:12.0 -0800
+++ linux-2.6.11/mm/hugetlb.c 2005-03-10 15:01:53.0 -0800
@@ -78,7 +78,6 @@ void free_huge_page(struct page *page)
struct page *alloc_huge_page(void)
{
struct page *page;
- int i;
spin_lock(_lock);
page = dequeue_huge_page();
@@ -89,8 +88,7 @@ struct page *alloc_huge_page(void)
spin_unlock(_lock);
set_page_count(page, 1);
page[1].mapping = (void *)free_huge_page;
- for (i = 0; i < (HPAGE_SIZE/PAGE_SIZE); ++i)
- clear_highpage([i]);
+ prep_zero_page(page, HUGETLB_PAGE_ORDER, GFP_HIGHUSER);
return page;
}
Index: linux-2.6.11/include/asm-ia64/page.h
===
--- linux-2.6.11.orig/include/asm-ia64/page.h 2005-03-01 23:37:48.0
-0800
+++ linux-2.6.11/include/asm-ia64/page.h2005-03-10 15:02:47.0
-0800
@@ -56,8 +56,9 @@
# ifdef __KERNEL__
# define STRICT_MM_TYPECHECKS
-extern void clear_page (void *page);
+extern void clear_pages (void *page, int order);
extern void copy_page (void *to, void *from);
+#define clear_page(__page) clear_pages(__page, 0)
/*
* clear_user_page() and copy_user_page() can't be inline functions because
Index: linux-2.6.11/arch/ia64/kernel/ia64_ksyms.c
===
--- linux-2.6.11.orig/arch/ia64/kernel/ia64_ksyms.c 2005-03-01
23:38:08.0 -0800
+++ linux-2.6.11/arch/ia64/kernel/ia64_ksyms.c 2005-03-10 15:01:53.0
-0800
@@ -38,7 +38,7 @@ EXPORT_SYMBOL(__down_trylock);
EXPORT_SYMBOL(__up);
#include
-EXPORT_SYMBOL(clear_page);
+EXPORT_SYMBOL(clear_pages);
#ifdef CONFIG_VIRTUAL_MEM_MAP
#include
Index: linux-2.6.11/arch/ia64/lib/clear_page.S
===
--- linux-2.6.11.orig/arch/ia64/lib/clear_page.S2005-03-01
23:37:47.0 -0800
+++ linux-2.6.11/arch/ia64/lib/clear_page.S 2005-03-10 15:01:53.0
-0800
@@ -7,6 +7,7 @@
* 1/06/01 davidm Tuned for Itanium.
* 2/12/02 kchen Tuned for both Itanium and McKinley
* 3/08/02 davidm Some more tweaking
+ * 12/10/04 clameter Make it work on pages of order size
*/
#include
@@ -29,27 +30,33 @@
#define dst4 r11
#define dst_last r31
+#define totsizer14
-GLOBAL_ENTRY(clear_page)
+GLOBAL_ENTRY(clear_pages)
.prologue
- .regstk 1,0,0,0
- mov r16 = PAGE_SIZE/L3_LINE_SIZE-1 // main loop count,
-1=repeat/until
+ .regstk 2,0,0,0
+ mov r16 = PAGE_SIZE/L3_LINE_SIZE// main loop count
+ mov totsize = PAGE_SIZE
.save ar.lc, saved_lc
mov saved_lc = ar.lc
-
+ ;;
.body
+ adds dst1 = 16, in0
mov ar.lc = (PREFETCH_LINES - 1)
mov dst_fetch = in0
- adds dst1 = 16, in0
adds dst2 = 32, in0
+ shl r16 = r16, in1
+ shl totsize = totsize, in1
;;
.fetch:stf.spill.nta [dst_fetch] = f0, L3_LINE_SIZE
adds dst3 = 48, in0 // executing this multiple times is
harmless
br.cloop.sptk.few .fetch
+ add r16 = -1,r16
+ add dst_last = totsize, dst_fetch
+ adds dst4 = 64, in0
;;
- addl dst_last = (PAGE_SIZE - PREFETCH_LINES*L3_LINE_SIZE), dst_fetch
mov ar.lc = r16 // one L3 line per iteration
- adds dst4 = 64, in0
+ adds dst_last = -PREFETCH_LINES*L3_LINE_SIZE, dst_last
;;
#ifdef CONFIG_ITANIUM
//
Re: [AGPGART] Map the graphic card to the bridge its connected to.
On Fri, 2005-03-11 at 10:02 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2005-02-23 at 02:25 +, Linux Kernel Mailing List wrote: > > ChangeSet 1.1982.82.19, 2005/02/22 21:25:33-05:00, [EMAIL PROTECTED] > > > > [AGPGART] Map the graphic card to the bridge its connected to. > > > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> Note that the effect of reverting the patch gets a broken result too (btw... the code had a spurrious pci_dev_put() too ...) Anyway, paulus is working on a solution that should be good enough for both cases where the AGP bridge is a sibling of the device, and where the bridge is a parent of the device. Patch soon... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/5] audit mips fix
Hi Ralf,
On Thu, 10 Mar 2005 17:14:29 +
Ralf Baechle <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 04, 2005 at 01:16:57PM -0800, [EMAIL PROTECTED] wrote:
>
> > Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
>
> > @@ -307,7 +308,7 @@ asmlinkage void do_syscall_trace(struct
> > {
> > if (unlikely(current->audit_context)) {
> > if (!entryexit)
> > - audit_syscall_entry(current, regs->orig_eax,
> > + audit_syscall_entry(current, regs->regs[2],
>
> Wrong. regs[2] can will contain the syscall return value and can be
> modified by ptrace also.
Thank you for your comment,
I consider a good way based on your comment.
Do you already have a good idea?
Yoichi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PPC64] Allow emulation of mfpvr on ppc64 kernel
On Thu, Mar 10, 2005 at 11:17:03PM +0100, Ingo Oeser wrote: > David Gibson wrote: > > Andrew, please apply. > > > > Allow userspace programs on ppc64 to use the (privileged) mfpvr > > instruction to determine the processor type. At the moment it > > emulates the instruction to provide the real PVR value, though it > > could be made to lie in future if for some reason we wish to restrict > > what CPU features userspace uses. > > Why not putting the required information into the AUX table > when executing your ELF programs? I loved this feature in the > ix86 arch. Because this is easy and is the way we already do it on ppc32..? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: re-inline sched functions
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote: > > This could be part of the unknown 2% performance regression with > db transaction processing benchmark. > > The four functions in the following patch use to be inline. They > are un-inlined since 2.6.7. > > We measured that by re-inline them back on 2.6.9, it improves performance > for db transaction processing benchmark, +0.2% (on real hardware :-) > > The cost is certainly larger kernel size, cost 928 bytes on x86, and > 2728 bytes on ia64. But certainly worth the money for enterprise > customer since they improve performance on enterprise workload. Less that 1k on x86 versus >2k on ia64. No wonder those things have such big caches ;) > ... > Possible we can introduce them back? OK by me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oom with 2.6.11
Christian Kujau <[EMAIL PROTECTED]> wrote: > > i was going to compile 2.6.11-rc5-bk4, to sort out the "bad" kernel. > compiling went fine. ok, finished some email, ok, suddenly my swap was > used up again, and no memory left - uh oh! OOM again, with 2.6.11-rc5-bk2! Well if you ran out of swap then yes, the oom-killer will visit you. Why did you run out of swapspace? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re-inline sched functions
This could be part of the unknown 2% performance regression with
db transaction processing benchmark.
The four functions in the following patch use to be inline. They
are un-inlined since 2.6.7.
We measured that by re-inline them back on 2.6.9, it improves performance
for db transaction processing benchmark, +0.2% (on real hardware :-)
The cost is certainly larger kernel size, cost 928 bytes on x86, and
2728 bytes on ia64. But certainly worth the money for enterprise
customer since they improve performance on enterprise workload.
# size vmlinux.*
textdata bss dec hex filename
3261844 717184 262020 4241048 40b698 vmlinux.x86.orig
3262772 717488 262020 4242280 40bb68 vmlinux.x86.inline
textdata bss dec hex filename
5836933 903828 201940 6942701 69efed vmlinux.ia64.orig
5839661 903460 201940 6945061 69f925 vmlinux.ia64.inline
Possible we can introduce them back?
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
--- linux-2.6.11/kernel/sched.c.orig2005-03-10 15:31:10.0 -0800
+++ linux-2.6.11/kernel/sched.c 2005-03-10 15:36:32.0 -0800
@@ -164,7 +164,7 @@
#define SCALE_PRIO(x, prio) \
max(x * (MAX_PRIO - prio) / (MAX_USER_PRIO/2), MIN_TIMESLICE)
-static unsigned int task_timeslice(task_t *p)
+static inline unsigned int task_timeslice(task_t *p)
{
if (p->static_prio < NICE_TO_PRIO(0))
return SCALE_PRIO(DEF_TIMESLICE*4, p->static_prio);
@@ -302,7 +302,7 @@ static DEFINE_PER_CPU(struct runqueue, r
* interrupts. Note the ordering: we can safely lookup the task_rq without
* explicitly disabling preemption.
*/
-static runqueue_t *task_rq_lock(task_t *p, unsigned long *flags)
+static inline runqueue_t *task_rq_lock(task_t *p, unsigned long *flags)
__acquires(rq->lock)
{
struct runqueue *rq;
@@ -426,7 +426,7 @@ struct file_operations proc_schedstat_op
/*
* rq_lock - lock a given runqueue and disable interrupts.
*/
-static runqueue_t *this_rq_lock(void)
+static inline runqueue_t *this_rq_lock(void)
__acquires(rq->lock)
{
runqueue_t *rq;
@@ -1323,7 +1323,7 @@ void fastcall sched_exit(task_t * p)
* with the lock held can cause deadlocks; see schedule() for
* details.)
*/
-static void finish_task_switch(task_t *prev)
+static inline void finish_task_switch(task_t *prev)
__releases(rq->lock)
{
runqueue_t *rq = this_rq();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
