Re: [patch] CFS scheduler, -v18
On 7/2/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: ok. Does the xterm slowdown get any better if you do: echo 46 > /proc/sys/kernel/sched_features ? The default on v18 is: echo 14 > /proc/sys/kernel/sched_features No. The Ctrl-C still hangs between 1 and 3 seconds, again seemingly depending on how long the program runs before I terminate it. Vegard - 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: [linux-usb-devel] [PATCH 3/4] usb: allocated usb releated dma buffer with?kmalloc_node
On Tue, Jul 03, 2007 at 08:23:07AM +0200, Oliver Neukum wrote: > Am Dienstag, 3. Juli 2007 schrieb Greg KH: > > On Mon, Jul 02, 2007 at 10:33:12PM -0700, Yinghai Lu wrote: > > > On 7/2/07, Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Mon, Jul 02, 2007 at 03:36:37PM -0700, Yinghai Lu wrote: > > > > > [PATCH 3/4] usb: allocated usb releated dma buffer with kmalloc_node > > > > > > > > > > For amd64 based two way system. USB always on node0. but dma buffer > > > > > for > > > > urb > > > > > allocated via kmalloc always get ram on node1. So change to > > > > > kmalloc_node > > > > to > > > > > get dma_buffer on corresponding node > > > > > > > > Are all of these changes really necessary? You are doing this for some > > > > allocations that take a _long_ time when sending to the device due to > > > > the speed of the device. > > > > > > > > I could possibly see this making a difference on some drivers, but for > > > > the core, and for the basic USB structures, I can't imagine it is really > > > > worth it. > > > > > > > > Or do you have numbers showing the differences here? > > > > > > > > Patch included fully below for the benifit of the usb list, which you > > > > should have cc:ed... > > > > > > dma buffer could be allocated via alloc_pages_coherent. or > > > kmalloc/dma_map_single. > > > alloc_pages_coherent get the dma_buffer on corresponding node. > > > but kmalloc/dma_map_single always get dma_buffer on last node. or say > > > device is on HT chain node0, it will get dma buffer on node 7 of 8 > > > socket system. > > > also on two way system with 4G+4G RAM conf. device on node 0 will get > > > dma_buffer above 4G, and if the dma_mask is less 32bit, will need > > > extra iommu mapping. > > > In my mcp55+io55 system, it show dma_map_single is keepping called by > > > usb input: keyboard/mouse (8/0x40 bytes), and forcedeth. (0x670bytes) > > > > Ok, so two drivers might need this, but not the whole usb core, right? > > If those two drivers need the extended allocator, why not use it where > it is beneficial, even if the benefit is small? What is the benefit? Speed isn't an issue here, so what is? 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 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
My $0.02 on thinkpad_acpi & HID's... 1. moving to DMI binding from PNP-id binding sounds like a step in the wrong direction. Are there thinkpads that you need to support that don't export IBM0068? There is a long tradition of DMI information being copy/pasted and being invalid. While the thinkpad BIOS guys are probably above average here, they're probably not immune from this issue. At the end of the day, I'd be astonished if somebody told me that the Windows thinkpad platform driver binds via DMI strings instead of binding to IBM0068 -- which was likely invented for this sole purpose. 2. IBM_PCI_HID = ACPI_PCI_HOST_HID = PCI_ROOT_HID_STRING = "PNP0A03" There is nothing IBM specific about a PCI root bridge. If you need to use this one, please call it PCI_ROOT_HID_STRING. thanks, -Len - 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] CFS scheduler, -v18
On Mon, 2007-07-02 at 18:40 +0200, Vegard Nossum wrote:
> On 7/2/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > thx. As an initial matter, could you double-check whether your v18
> > kernel source has the patch below applied already?
> >
> > Ingo
> >
> > Index: linux/kernel/sched_fair.c
> > ===
> > --- linux.orig/kernel/sched_fair.c
> > +++ linux/kernel/sched_fair.c
> > @@ -342,8 +342,9 @@ update_stats_enqueue(struct cfs_rq *cfs_
> > s64 tmp;
> >
> > if (se->wait_runtime < 0) {
> > - tmp = (0 - se->wait_runtime) << NICE_0_SHIFT;
> > - key += (tmp * se->load.inv_weight) >> WMULT_SHIFT;
> > + tmp = -se->wait_runtime;
> > + key += (tmp * se->load.inv_weight) >>
> > + (WMULT_SHIFT - NICE_0_SHIFT);
> > } else {
> > tmp = se->wait_runtime * se->load.weight;
> > key -= tmp >> NICE_0_SHIFT;
> >
> >
>
> It does.
Hi,
This doesn't appear to be a CFS problem. I can reproduce the problem
easily in virgin 2.6.22-rc7 by starting xterm-spam at nice -1 or better.
As soon as xterm-spam can get enough CPU to keep the xterm fully busy,
it's game over, the xterm freezes. The more accurate fairness of CFS to
sleepers just tips the balance quicker. In mainline, the xterm has an
unfair advantage and maintains it indefinitely... until you tip the
scales just a wee bit, at which time it inverts.
-Mike
-
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: [linux-usb-devel] [PATCH 3/4] usb: allocated usb releated dma buffer with?kmalloc_node
Am Dienstag, 3. Juli 2007 schrieb Greg KH: > > > Ok, so two drivers might need this, but not the whole usb core, right? > > > > If those two drivers need the extended allocator, why not use it where > > it is beneficial, even if the benefit is small? > > What is the benefit? Speed isn't an issue here, so what is? Speed is always an issue. Every cycle used in the kernel is lost to user space. Regards Oliver - 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: blink driver power saving
* Pavel Machek <[EMAIL PROTECTED]> [2007-07-03 01:08]: > On Mon 2007-07-02 14:39:27, Andi Kleen wrote: > > > > > > Perhaps one of you geniuses who all hate it can find a better way to > > > > solve the "video output dead after kexec; but need visual feedback to > > > > the user > > > > while crash dumping" problem. I'm waiting for your patches. > > > > > > > > > > I don't don't like it ;) Unfortunately too many people end up enabling > > > > Yes that's pretty weird. I admit I hadn't expected > > that problem. blink is equivalent to "annoy me" and it > > is a mystery why so many people should willingly ask their computer to > > annoy them. > > tristate "Keyboard blink driver" > > ...drivers are not expected to act on their own. I was expecting to > get nice /sys/class/led* interface to my keyboard leds. What's the benefit of such an interface? If you're able to trigger keyboard LEDs via that interface, you're also able to use the ioctl() on /dev/console. I think the intention of the blink driver was to have a *early* blink, i.e. before initrd (and on systems without intrd, before the first init script runs). Thanks, Bernhard - 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] CFS scheduler, -v18
* Vegard Nossum <[EMAIL PROTECTED]> wrote: > I'd also like to point out that [EMAIL PROTECTED] seems to draw more CPU > than it should. Or, at least, in top, it shows up as using 50% CPU > even though other processes are demanding as much as they can get. The > FAH program should be running with idle priority. I expect it to fall > to near 0% when other programs are running at full speed, but it keeps > trotting along. And I am pretty sure that this is not due to SMP/HT (I > made sure to utilize both CPUs). your FAH processes are running with nice +19 - that should be enough to throttle them. With v18 you can also mark it SCHED_IDLE: schedtool -D $$ # mark the shell idle SCHED_IDLE gets inherited by child tasks so if you mark the shell that starts up FEH as SCHED_IDLE, all FEH threads should be SCHED_IDLE too. (or you can start it up via schedtool -D -e ... ) does it still get more CPU time than you'd expect it to get? A reniced or SCHED_IDLE task will 'fill in' any idle time that it senses, so in itself it's not an anomaly if a task gets 50% and FEH fills in the remaining 50%. Does it still get CPU time if you start two CPU hogs: for (( N=0; N < 2; N++ )); do ( while :; do :; done ) & done ? If yes, that would be an anomaly. > Otherwise, I am satisfied with the performance of CFS. Especially the > desktop is noticably smoother. Thanks! great! :-) Ingo - 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 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
> BTW: I also saw a laptop (IIRC it was a sony) with asus and sony ACPI
> device.
> When both drivers got loaded things broke.
> A solution was to only let the asus driver get active if the device is
> known. Currently, not sure whether still (I sent a patch a while ago),
> the Asus driver falls back to a default ("M6N"?) configuration. IMO this
> is a bit too dangerous and instead a message like "unsupported ASUS
> model found, please send acpidump to [EMAIL PROTECTED]".
This is pretty scary.
Can you drop the acpidump output into a bugzilla?
thanks,
-Len
-
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] Remove process freezer from suspend to RAM pathway
On Tue, 2007-07-03 at 16:08 +1000, Nigel Cunningham wrote: > > > So I think Matthew is totally right. In fact, the presence of the > > freezer is the main reason why Paulus so far NACKed Johannes attempts at > > merging the PPC PM code with the generic code in kernel/power.c > > > > We've been doing fine without it so far and intend to continue to do so. > > Fuse depends on !PPC? No, that's not what I'm saying. I'm saying we've been doing STR without the freezer and that's the way to go imho. > > As for suspend-to-disk, I refer you to the discussions we had in the > > past with Linus, where he explains I think quite clearly how wrong the > > current implementation of STR is :-) > > I assume you mean STD. Oops, yeah, sorry. > The problem there is that Linus doesn't care about STD. > If he did, I dare say he'd think through the issues more thoroughly than he > apparently has. Heh, that might be the case :-) > > Thing is, if you're going to do snapshots, you should probably not sync > > after you have "frozen" anyway. > > Fully agree. But how do you stop things syncing while you're writing the > image > if you don't have a freezer or equivalent? (scheduler based, kexec.. they're > all workarounds for this issue). Well, I was saying that in the context of the -current- snapshotting mechanism which is based on the freezer, then you should not sys_sync(). Some random user or kernel thread doing a sync is not a problem. It will stop in the middle of sync and resume on wakeup. The problem is currently because STD -itself- attempts to sync after it has frozen things. I think that should be changed. If you want to sync for whatever reason, (mostly save RAM ?) do it before the freeze. That means you may get new dirty data in memory that isn't written out by the sync before you freeze, but that's allright, that data will be in the suspend image anyway. If you fail to wakeup, that's akin to a normal crash, the user will only lose the last data written at the time of the suspend and journaling fs'es should take care of fs metadata integrity. So to summarize, the plan that makes things work with fuse is: - For STR, don't do the freezer thing. - For STD, don't sys_sync() after you froze There might be -other- issues, but that should get you through some of them at least. Of course, you'll be in trouble if you try to do things like STD-to-a-file which sits on a fuse FS but there's a limit to insanity :-) Cheers, 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] CFS scheduler, -v18
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> This doesn't appear to be a CFS problem. I can reproduce the problem
> easily in virgin 2.6.22-rc7 by starting xterm-spam at nice -1 or
> better. As soon as xterm-spam can get enough CPU to keep the xterm
> fully busy, it's game over, the xterm freezes. The more accurate
> fairness of CFS to sleepers just tips the balance quicker. In
> mainline, the xterm has an unfair advantage and maintains it
> indefinitely... until you tip the scales just a wee bit, at which time
> it inverts.
ah. That indeed makes sense. It seems like the xterm doesnt process the
Ctrl-C/Z keypresses _at all_ when it is 'spammed' with output. Normally,
output 'spam' is throttled by the scroll buffer's overhead. But in
Vegard's case, the printout involves a \r carriage return:
printf("%ld\r", 1000 * clock() / CLOCKS_PER_SEC);
which allows xterm-spam (attached) to easily flood the xterm (without
any scrolling that would act as a throttle) and the xterm to flood Xorg.
I suspect we need the help of an xterm/Xorg expert? (maybe Keith can
give us further pointers? I can reproduce the problem on a T60 with i940
and Core2Duo running Fedora 7 + Xorg 7.1.)
Ingo
#include
main ()
{
while(1)
printf("%ld\r", 1000 * clock() / CLOCKS_PER_SEC);
}
Re: [patch 3/5] remove ptep_test_and_clear_dirty and ptep_clear_flush_dirty.
On Mon, 2007-07-02 at 18:29 -0700, Zachary Amsden wrote:
> > -static inline int
> > -ptep_test_and_clear_dirty (struct vm_area_struct *vma, unsigned long addr,
> > pte_t *ptep)
> > -{
> > -#ifdef CONFIG_SMP
> > - if (!pte_dirty(*ptep))
> > - return 0;
> > - return test_and_clear_bit(_PAGE_D_BIT, ptep);
> > -#else
> > - pte_t pte = *ptep;
> > - if (!pte_dirty(pte))
> > - return 0;
> > - set_pte_at(vma->vm_mm, addr, ptep, pte_mkclean(pte));
> > - return 1;
> > -#endif
> > -}
>
> I've not followed all the changes lately - what is the current protocol
> for clearing dirty bit? Is it simply pte_clear followed by set or is it
> not done at all? At least for i386 and virtualization, we had several
> optimizations to the test_and_clear path that are not possible with a
> pte_clear / set_pte approach.
Imho with a sequence of ptep_get_and_clear, pte_wrprotect, set_pte_at.
One of the reasons why ptep_test_and_clear_dirty doesn't make sense
anymore is the shared dirty page tracking. You never just test and clear
the dirty bit, the latest code always sets the write protect bit as
well.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
-
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: Error in syslog on 2.6.20
William Thompson wrote: > I'm not on either list, keep me in CC. > > I noticed the following error on a cdrom device: > ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata2.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 > res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout) > ata2: soft resetting port > ata2.00: configured for MWDMA2 > ata2: EH complete > > This is the device when it was found: > libata version 2.00 loaded. > ata_piix :00:1f.1: version 2.00ac7 > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14 > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 > scsi0 : ata_piix > ata1.00: ATA-4, max UDMA/66, 16514064 sectors: LBA > ata1.00: ata1: dev 0 multi count 8 > ata1.00: configured for UDMA/66 > scsi1 : ata_piix > ata2.00: ATAPI, max MWDMA2 > ata2.00: configured for MWDMA2 > scsi 0:0:0:0: Direct-Access ATA WDC WD84AA 05.0 PQ: 0 ANSI: 5 > scsi 1:0:0:0: CD-ROMLITEON CD-ROM LTN486S YQSM PQ: 0 ANSI: 5 > > I have a program that does a scsi TEST UNIT READY on many devices once every > .1 second. The problem occured when I ejected the cdrom and closed the tray > again with valid media in the drive. My program noticed media removed and > inserted, then said the device was dead/unpollable. This is when I saw this > error. Your cd rom failed to complete the TUR command your program issued in the specified timeout. ODDs sometimes take quite long to finish TUR or any other command when media is changed. Did you use sg command or cdrom ioctl? Anyways, after timing out, libata EH kicked the cdrom in the ass and world peace is restored. -- tejun - 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/
platform_driver_register() ??
Hi All, I have an MMC driver for my kit (i.MX21 based cogent board CSB535FS), which is supplied by Cogent (Kernel version 2.6.16). The original driver (linux/drivers/mmc/mmc_block.c) uses mmc_register_driver() method to register the driver but the one supplied by Cogent uses platform_driver_register() method. What is the difference between the two? Thanks, Midhun. - 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 0/3] ACPI autoloading
> A) Cannot pass acpi_device_id through ops.add (probe equivalent func)
> -
>
> int acpi_match_device_ids(..)
> should be:
> const acpi_device_id *acpi_match_device_ids
> and the matching device id should get passed to the acpi driver's .add
> function.
> This would ease up the code in the ACPI driver a lot (e.g. see button.c,
> it is compared again which device (HID) has been found. Theoretically
> the drivers also needs to check CIDs...).
>
> The problem is that in scan.c ACPI driver is abstracted to use .match
> and .probe "struct bus_type" functions and I have no idea how the
> matching acpi_device_id should get passed or stored from
> acpi_match_device_ids (.match) to ops.add (invoked in .probe).
> Currently:
> kernel_ulong_t driver_data;
> of acpi_device_id got added, but is not used at all atm.
>
> B) Thermal module always gets loaded
>
>
> This is because _TZ_ (scope?!?) always gets added, but is declared as a
> device or at least pops up as a thermal device.
> This is in drivers/acpi/utilities/utglobal.c:
>
> /*
> * Predefined ACPI Names (Built-in to the Interpreter)
> *
> * NOTES:
> * 1) _SB_ is defined to be a device to allow \_SB_._INI to be run
> *during the initialization sequence.
> * 2) _TZ_ is defined to be a thermal zone in order to allow ASL code to
> *perform a Notify() operation on it.
> */
>
> Any idea how to get rid of that is very welcome.
> Is this to be able to process buggy ASL code of this kind?:
> "Notify ("_TZ_", 0x80)"
> While _TZ_ is not a real device, but a scope operator and gets
> statically declared as a device here to solve such things?
ThermalZone objects hang under _TZ, whether TZ it be global, or under _SB
I would think that if there are no ThermalZone objects,
then we'd not need to bind the thermal driver.
However, this would be a custom binding method (like acpi video.c)
rather than a HID based one.
I'm really not sure about the _TZ_ syntax -- we'll have to ask Bob
where that came from when he returns -- but I don't think it matters
for the issue at hand.
> C) Renaming/Unifying of HID strings
> ---
>
> This shouldn't be a problem. Consequence is that the new ACPI sysfs
> structure will show other names, but as it got introduced recently this
> shouldn't hurt anyone?
I agree that it is still new and that it is unlikely that a re-name
now would be a significant compatibility issue.
> For better readability we could map all HIDs to a device name through a
> HID <-> Device Name - enum and table. And then export "battery" again
> through /sys instead of "PNP0C0A".
> This was a bit mixed up. If, this should get implemented soon as the
> sysfs structure should not get altered that often...
> If wanted, I can send an on top patch later...
We've had this discussion before.
I'm inclined to keep the kernel as simple as possible, and let
some user-space thingie look up standard strings in some user-space table.
I don't want to get into the game of trying to make sysfs
so user-friendly, that a kernel re-build is necessary to add/translate
a new string...
that said, if we have to _invent_ a new string, it might as well
be something meaningful to a human.
> D) Why renaming struct acpi_device_id to struct __acpi_device_id
>
> Not a problem, just for understanding why I have done this:
> struct acpi_device_id already exists in ACPICA. The module aliasing
> interface requires that struct "SUBSYSTEM"_device_id is used as name.
> This is not that obvious (include/linux/module.h):
> #define MODULE_GENERIC_TABLE(gtype,name) and
> #define MODULE_DEVICE_TABLE(type,name)
it is really irritating to end up with two nearly identical definitions.
it is also irritating to diverge from ACPICA for syntax reasons.
I don't really have a better idea -- though I'd be inclined to call it
acpica_device_id instead of __acpi_device_id if we're stuck with that route.
-Len
-
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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > So to summarize, the plan that makes things work with fuse is: > > - For STR, don't do the freezer thing. > > - For STD, don't sys_sync() after you froze > > There might be -other- issues, but that should get you through some of At the risk of repeating myself. Character device drivers are written with the assumption that normal io and suspend/resume do not race with each other due to the freezer. What do you intend to do about that? Regards Oliver - 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 1/3] ACPI autoloading - ACPICA adjustance
On Sunday 17 June 2007 16:24, Thomas Renninger wrote: > Define standardized HIDs ... > Index: linux-2.6.22-rc4/include/acpi/acpi_drivers.h > === > --- linux-2.6.22-rc4.orig/include/acpi/acpi_drivers.h > +++ linux-2.6.22-rc4/include/acpi/acpi_drivers.h > @@ -34,16 +34,33 @@ > #define ACPI_BUS_COMPONENT 0x0001 > #define ACPI_SYSTEM_COMPONENT0x0200 > > -/* _HID definitions */ > +/* > + _HID definitions > + HIDs starting with 'X' are self defined here and are used for devices where > + a HID does not exist in spec. > + HIDs must conform to (ACPI spec - 6.1.4): > > -#define ACPI_POWER_HID "power_resource" > + Numeric 32-bit compressed EISA type ID are not supported (never seen one as > + an ACPI HID?) > + > + A valid PNP ID must be of the form AAA where A is an uppercase letter > + and # is a hex digit. > + A valid ACPI ID must be of the form ACPI where # is a hex digit. > + > + and our self-defined: XAAA where A is an uppercase letter and # is a > hex > + digit. What was the criteria for inventing the XAAA format? It doesn't comply with the PNP standard format above, since it starts with four letters instead of three. I don't think that "XVID0001" will be more meaningful than "video" when seen in sysfs... > +*/ > + > +#define ACPI_POWER_HID "XPWR0001" > #define ACPI_PROCESSOR_HID "ACPI0007" > -#define ACPI_SYSTEM_HID "acpi_system" > -#define ACPI_THERMAL_HID "thermal" > -#define ACPI_BUTTON_HID_POWERF "button_power" > -#define ACPI_BUTTON_HID_SLEEPF "button_sleep" > -#define ACPI_VIDEO_HID "video" > -#define ACPI_BAY_HID "bay" > +#define ACPI_SYSTEM_HID "XSYS0001" > +#define ACPI_THERMAL_HID "XTHM0001" > +#define ACPI_BUTTON_HID_POWERF "XPBT0001" > +#define ACPI_BUTTON_HID_SLEEPF "XSBT0001" > +#define ACPI_VIDEO_HID "XVID0001" > +#define ACPI_BAY_HID "XBAY0001" > + If the criteria is to stay within an 8 character id length, I'd rather spell a word with capital letters, and stick in 0's where we don't need more letters: POWER000 SYSTEM00 THERMAL0 PWRBTN00 SLEEPBTN VIDEO000 DRIVEBAY Or when we discussed this before, we though about not conflicting with a standard (or vendor standard) name by becoming the Linux vendor -- say using the "LNX" prefix, and trying to spell something useful in the remaining 5 characters. eg. LNXPOWER LNXSYSTM LNXTHERM LNXSLPBN LNXPWRBN LNXVIDEO LNXIOBAY -Len - 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/
Fusion MPT regression, fixed or not?
Hello World, I re-stumbled on this installing Gentoo on VMware today; http://lkml.org/lkml/2007/3/23/312 It doesn't seem to be fixed in 2.6.22-rc7, but I might be mistaken somehow. Has anyone done any work on this or looked at the problem in more detail? The trail seems to die at that thread. It is affecting VMware for me mainly but a lot of heavy server hardware seems to use the chip, in fact some I am looking at right now to recommend purchasing on.. I'd really like to use the latest kernel because virtualisation is the key (dynamic ticks and tickless hz and the latest virtualisation options would help eke out more value ;) -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations - 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] CFS scheduler, -v18
On Tue, 2007-07-03 at 09:22 +0200, Ingo Molnar wrote: > which allows xterm-spam (attached) to easily flood the xterm (without > any scrolling that would act as a throttle) and the xterm to flood Xorg. It's just an Xterm bug. Xterm will look for X input if it ever manages to fill the input buffer past 32768 bytes. If it manages to get more than 4096 bytes in one read, it will invoke sched_yield. and then check for input. Gotta love that sched_yield call. As it always processes all of the incoming data before trying to read again, there doesn't appear to be any way it can ever have more than 32768 characters in the buffer. And, as the kernel will not buffer more than 4095 bytes from a pty, there isn't any way it will ever read 4096 bytes. So, it sits there carefully reading every byte from the pty and painting them on the screen. You can 'fix' xterm with: $ xterm -xrm '*minBufSize: 4095' I hesitate to even suggest a patch to xterm that would solve this problem correctly. Note that xterm has kludges in several of the output processing steps which explicitly look for input (most vertical cursor motion, it seems), which is why any application which scrolls doesn't cause this problem. Do you need more reasons to switch to another terminal emulator? gnome-terminal has finally gotten reasonable; I expect rxvt or konsole would work just as well. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tue, 2007-07-03 at 05:29 +0100, Matthew Garrett wrote: > or alternatively we could do what we do for suspend to RAM on other > platforms (PPC and APM) and just not use the freezer. As a data point, I am running with this patch on top of 2.6.21.2 the last 3+ weeks, with an average of 5/6 STR cycles a day, and had no problems at all. (Sony vaio pcg-fx701). Just normal work, I didn't try to stress the thing, but I have quite a few times suspended/resumed over a big compile without a glitch. What are the risks of this patch supposed to be? Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - 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] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Romano Giannetti: > On Tue, 2007-07-03 at 05:29 +0100, Matthew Garrett wrote: > > or alternatively we could do what we do for suspend to RAM on other > > platforms (PPC and APM) and just not use the freezer. > > As a data point, I am running with this patch on top of 2.6.21.2 the > last 3+ weeks, with an average of 5/6 STR cycles a day, and had no > problems at all. (Sony vaio pcg-fx701). Just normal work, I didn't try > to stress the thing, but I have quite a few times suspended/resumed over > a big compile without a glitch. > > What are the risks of this patch supposed to be? You did this test only while stressing normal block devices. Try provoking races in character devices. Regards Oliver - 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: Some NCQ numbers...
Michael Tokarev wrote: > [Offtopic notice: For the first time I demonstrated some > speed testing results on linux-ide mailinglist, as a > demonstration how [NT]CQ can help. But later, someone > becomes curious and posted that email to lkml, asking > for more details. Since that, I become more curious > as well, and decided to look at it more closely. > Here it goes...] > > A test drive is Seagate Barracuda ST3250620AS "desktop" drive, > 250Gb, cache size is 16Mb, 7200RPM. And which elevator? -- tejun - 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: PROBLEM: SATA AHCI driver significant throughput loss in 2.6.22-rc5-g75154f40-dirty
Michal Piotrowski wrote: > Hi, > > [adding linux-ide to cc] > > On 27/06/07, Dan <[EMAIL PROTECTED]> wrote: >> Something changed with the AHCI SATA driver in the latest git version. >> With 2.6.21 I get ~49MB/sec according to hdparm. Using the latest git >> version I only get ~8MB/sec. I've attached my .config and have >> included some info about my system below. Please let me know if you >> need more information or if I can help test anything. Please post boot dmesgs of before and after. -- tejun - 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] CFS scheduler, -v18
* Keith Packard <[EMAIL PROTECTED]> wrote: > On Tue, 2007-07-03 at 09:22 +0200, Ingo Molnar wrote: > > > which allows xterm-spam (attached) to easily flood the xterm > > (without any scrolling that would act as a throttle) and the xterm > > to flood Xorg. > > It's just an Xterm bug. > > Xterm will look for X input if it ever manages to fill the input > buffer past 32768 bytes. If it manages to get more than 4096 bytes in > one read, it will invoke sched_yield. and then check for input. Gotta > love that sched_yield call. > > As it always processes all of the incoming data before trying to read > again, there doesn't appear to be any way it can ever have more than > 32768 characters in the buffer. > > And, as the kernel will not buffer more than 4095 bytes from a pty, > there isn't any way it will ever read 4096 bytes. > > So, it sits there carefully reading every byte from the pty and > painting them on the screen. ah. Thanks for the explanation! > You can 'fix' xterm with: > > $ xterm -xrm '*minBufSize: 4095' indeed, that solves the xterm-spam Ctrl-C/Ctrl-Z problem here! > I hesitate to even suggest a patch to xterm that would solve this > problem correctly. Note that xterm has kludges in several of the > output processing steps which explicitly look for input (most vertical > cursor motion, it seems), which is why any application which scrolls > doesn't cause this problem. > > Do you need more reasons to switch to another terminal emulator? > gnome-terminal has finally gotten reasonable; I expect rxvt or konsole > would work just as well. yeah, i use gnome-terminal exclusively. But testers looking for CFS regressions do run every shell on the planet :-) gnome-terminal is also faster all around (at least on my box): $ (echo '#!/bin/bash' ; echo 'for ((i=0; i<10; i++)); do echo $i; done') > 1.sh; chmod +x 1.sh; time xterm $HOME/1.sh; time gnome-terminal -x ./1.sh real0m3.193s user0m2.840s sys 0m0.460s real0m2.495s user0m2.430s sys 0m1.520s Ingo - 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.22-rc2-mm1
On Fri, 1 Jun 2007 05:38:48 -0700, Greg KH <[EMAIL PROTECTED]> wrote: [Sorry for taking so long to respond, I've been offline for a month] > Can you resend me the new patch, I seem to have lost it in this thread > :( Andrew has the fixup patch in his -mm lineup as driver-core-check-return-code-of-sysfs_create_link-fix.patch. Do you need anything else? Cornelia - 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/
How to handle patches that cross maintainers?
Andrew, I was hoping to get your input on how to handle patches that cross maintainers. I've got a patch that is pretty PPC specific, but happens to touch some drivers as well. Here's the diffstat to get a rough idea: arch/powerpc/kernel/io.c| 12 ++-- arch/powerpc/mm/hash_native_64.c|2 +- arch/powerpc/mm/stab.c |4 ++-- drivers/ide/pci/scc_pata.c |4 ++-- drivers/media/dvb/bt8xx/bt878.h |5 ++--- drivers/serial/cpm_uart/cpm_uart_core.c |2 +- include/asm-powerpc/system.h|2 +- 7 files changed, 15 insertions(+), 16 deletions(-) Now, I've had this issue before w/o any good sense on how to handle it. Suggestions? - k - 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: Fwd: Mounting MMC card
Hi All, This is referring to my problem - not able to mount MMC card. I have some output from dmesg when I remove and put the card back (I have changes the kernel config to include i.MX SPI and disabled the generic SPI). DOes this give any clue as to why the MMC card is not appaering in /proc/partions and /sysfs/block ?? Any help will of great use. The output of dmesg is as follows. I have removed and inserted the card twice. <6>imx-mmc imx-mmc.0: card removed <7>imx-mmc imx-mmc.0: clock 0 power 1 vdd 20 width 1 <7>imx-mmc imx-mmc.0: clock 15 power 2 vdd 20 width 1 <7>imx-mmc imx-mmc.0: PERCLK2 265977856 MHz -> prescaler 5 <7>imx-mmc imx-mmc.0: MMC_CLK_RATE: 0x0057 <7>imx-mmc imx-mmc.0: clock 15 power 2 vdd 20 width 1 <7>imx-mmc imx-mmc.0: PERCLK2 265977856 MHz -> prescaler 5 <7>imx-mmc imx-mmc.0: MMC_CLK_RATE: 0x0057 <7>MMC: starting cmd 00 arg flags 0040 <7>imx-mmc imx-mmc.0: CMD00 (0x00) mask set to 0x003b <7>imx-mmc imx-mmc.0: CMD TIMEOUT <7>imx-mmc imx-mmc.0: RESP 0x, 0x, 0x, 0x, error 1 <7>MMC: req done (00): 1: <7>imx-mmc imx-mmc.0: clock 15 power 2 vdd 20 width 1 <7>imx-mmc imx-mmc.0: PERCLK2 265977856 MHz -> prescaler 5 <7>imx-mmc imx-mmc.0: MMC_CLK_RATE: 0x0057 <7>MMC: starting cmd 37 arg flags 0015 <7>imx-mmc imx-mmc.0: CMD55 (0x37) mask set to 0x003b <7>imx-mmc imx-mmc.0: CMD TIMEOUT <7>imx-mmc imx-mmc.0: RESP 0x, 0x, 0x, 0x, error 1 <7>MMC: req done (37): 1: <7>MMC: starting cmd 37 arg flags 0015 <7>imx-mmc imx-mmc.0: CMD55 (0x37) mask set to 0x003b <7>imx-mmc imx-mmc.0: CMD TIMEOUT <7>imx-mmc imx-mmc.0: RESP 0x, 0x, 0x, 0x, error 1 <7>MMC: req done (37): 1: <7>MMC: starting cmd 37 arg flags 0015 <7>imx-mmc imx-mmc.0: CMD55 (0x37) mask set to 0x003b <7>imx-mmc imx-mmc.0: CMD TIMEOUT <7>imx-mmc imx-mmc.0: RESP 0x8000, 0x, 0x, 0x, error 1 <7>MMC: req done (37): 1: 8000 <7>MMC: starting cmd 37 arg flags 0015 <7>imx-mmc imx-mmc.0: CMD55 (0x37) mask set to 0x003b <7>imx-mmc imx-mmc.0: CMD TIMEOUT <7>imx-mmc imx-mmc.0: RESP 0x, 0x, 0x, 0x, error 1 <7>MMC: req done (37): 1: <7>MMC: starting cmd 01 arg flags 0061 <7>imx-mmc imx-mmc.0: CMD01 (0x01) mask set to 0x003b <7>imx-mmc imx-mmc.0: CMD TIMEOUT <7>imx-mmc imx-mmc.0: RESP 0x, 0x, 0x, 0x, error 1 <7>MMC: req done (01): 1: <7>imx-mmc imx-mmc.0: clock 0 power 0 vdd 0 width 1 <6>imx-mmc imx-mmc.0: card inserted <7>imx-mmc imx-mmc.0: clock 0 power 1 vdd 20 width 1 <7>imx-mmc imx-mmc.0: clock 15 power 2 vdd 20 width 1 <7>imx-mmc imx-mmc.0: PERCLK2 265977856 MHz -> prescaler 5 <7>imx-mmc imx-mmc.0: MMC_CLK_RATE: 0x0057 <7>imx-mmc imx-mmc.0: clock 15 power 2 vdd 20 width 1 <7>imx-mmc imx-mmc.0: PERCLK2 265977856 MHz -> prescaler 5 <7>imx-mmc imx-mmc.0: MMC_CLK_RATE: 0x0057 <7>MMC: starting cmd 00 arg flags 0040 <7>imx-mmc imx-mmc.0: CMD00 (0x00) mask set to 0x003b <7>imx-mmc imx-mmc.0: RESP 0x, 0x, 0x, 0x, error 0 <7>MMC: req done (00): 0: <7>imx-mmc imx-mmc.0: clock 15 power 2 vdd 20 width 1 <7>imx-mmc imx-mmc.0: PERCLK2 265977856 MHz -> prescaler 5 <7>imx-mmc imx-mmc.0: MMC_CLK_RATE: 0x0057 <7>MMC: starting cmd 37 arg flags 0015 <7>imx-mmc imx-mmc.0: CMD55 (0x37) mask set to 0x003b <7>imx-mmc imx-mmc.0: CMD TIMEOUT <7>imx-mmc imx-mmc.0: RESP 0x, 0x, 0x, 0x, error 1 <7>MMC: req done (37): 1: <7>MMC: starting cmd 37 arg flags 0015 <7>imx-mmc imx-mmc.0: CMD55 (0x37) mask set to 0x003b <7>imx-mmc imx-mmc.0: CMD TIMEOUT <7>imx-mmc imx-mmc.0: RESP 0x, 0x, 0x, 0x, error 1 <7>MMC: req done (37): 1: <7>MMC: starting cmd 37 arg flags 0015 <7>imx-mmc imx-mmc.0: CMD55 (0x37) mask set to 0x003b <7>imx-mmc imx-mmc.0: CMD TIMEOUT <7>imx-mmc imx-mmc.0: RESP 0x8000, 0x, 0x, 0x, error 1 <7>MMC: req done (37): 1: 8000 <7>MMC: starting cmd 37 arg flags 0015 <7>imx-mmc imx-mmc.0: CMD55 (0x37) mask set to 0x003b <7>imx-mmc imx-mmc.0: CMD TIMEOUT <7>imx-mmc imx-mmc.0: RESP 0x, 0x, 0x, 0x, error 1 <7>MMC: req done (37): 1: <7>MMC: starting cmd 01 arg flags 0061 <7>imx-mmc imx-mmc.0: CMD01 (0x01) mask set to 0x003b <7>imx-mmc imx-mmc.0: RESP 0x, 0x, 0x, 0x, error 0 <7>MMC: req done (01): 0: 00
Re: [patch] CFS scheduler, -v18
On 7/3/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: does it still get more CPU time than you'd expect it to get? A reniced or SCHED_IDLE task will 'fill in' any idle time that it senses, so in itself it's not an anomaly if a task gets 50% and FEH fills in the remaining 50%. Does it still get CPU time if you start two CPU hogs: for (( N=0; N < 2; N++ )); do ( while :; do :; done ) & done ? If yes, that would be an anomaly. No, with this test, it gets the expected amount of CPU. Thanks for clearing it up! Vegard - 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] driver core: multithreaded probing - more parallelismcontrol
On Mon, 25 Jun 2007 01:16:24 -0700, Greg KH <[EMAIL PROTECTED]> wrote: [I'm a bit late to the party, but...] > On Sun, Jun 24, 2007 at 11:04:13PM +0800, Huang, Ying wrote: > > There does exist multithreaded device probing in current driver core > > implementation, supposing two devices are hot-plugged at the same time. > > No, that is a bus-specific thing, and no bus that I know of supports > that at this time. The s390 channel subsystem busses should be fine with any parallelism, especially as the css bus kicks off tons of probes (device recognition) at the same time. Any ccw driver must be able to be handle to be called for many devices in parallel as well (like, when someone attaches their shiny new storage subsystem to the LPAR and some thousands of dasds become available). > > > But, many device drivers are written without this taken into account. > > That's why no bus does this :) It is possible for busses for a small set of device drivers (like the s390 busses; maybe there are others). It looks like a bad idea to try this for PCI :) > > > I think it may be better to make default device probing process more > > single-threaded in the driver core. The single-thread workqueue or some > > customized version of workqueue like that implemented by my patch can be > > used for this. The parallel control mechanism can be used to implement > > multithreaded device probing in needed subsystems too. > > But remember, the individual busses already do this all in a single > thread anyway, nothing is needed in the driver core to do this. I think I could make good use of some more parallelism control (for throttling or so). Not sure if it should really sit at the driver core level, but that would avoid reinventing the wheel. [Goes reading the original patch] Cornelia - 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: How to handle patches that cross maintainers?
On Tue, 3 Jul 2007 04:01:20 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote: > Andrew, > > I was hoping to get your input on how to handle patches that cross > maintainers. I've got a patch that is pretty PPC specific, but > happens to touch some drivers as well. > > Here's the diffstat to get a rough idea: > > arch/powerpc/kernel/io.c| 12 ++-- > arch/powerpc/mm/hash_native_64.c|2 +- > arch/powerpc/mm/stab.c |4 ++-- > drivers/ide/pci/scc_pata.c |4 ++-- > drivers/media/dvb/bt8xx/bt878.h |5 ++--- > drivers/serial/cpm_uart/cpm_uart_core.c |2 +- > include/asm-powerpc/system.h|2 +- > 7 files changed, 15 insertions(+), 16 deletions(-) > > Now, I've had this issue before w/o any good sense on how to handle it. > > Suggestions? > Well, assuming that all the changes are interdependent and cannot be split up: send it to the relevant maintainers, gather the acks and merge it up yourself. - 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] LinuxPPS (with new syscalls API) - new version
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
>
> Seems reasonable enough in principle -- but whatever you do, don't use
> "long" for it. That would definitely need different behaviour for 32-bit
> vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t.
Here the patch to convert LinuxPPS data structs into fixed ones.
Please, take a look at it and report possible modifications.
Thanks for your time,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
diff --git a/Documentation/pps/timepps.h b/Documentation/pps/timepps.h
index d690aa6..fe8f467 100644
--- a/Documentation/pps/timepps.h
+++ b/Documentation/pps/timepps.h
@@ -28,6 +28,32 @@
/* --- 3.2 New data structures - */
+struct ntp_fp {
+ unsigned int integral;
+ unsigned int fractional;
+};
+
+union pps_timeu {
+ struct timespec tspec;
+ struct ntp_fp ntpfp;
+ unsigned long longpad[3];
+};
+
+struct pps_info {
+ unsigned long assert_sequence; /* seq. num. of assert event */
+ unsigned long clear_sequence; /* seq. num. of clear event */
+ union pps_timeu assert_tu; /* time of assert event */
+ union pps_timeu clear_tu; /* time of clear event */
+ int current_mode; /* current mode bits */
+};
+
+struct pps_params {
+ int api_version;/* API version # */
+ int mode; /* mode bits */
+ union pps_timeu assert_off_tu; /* offset compensation for assert */
+ union pps_timeu clear_off_tu; /* offset compensation for clear */
+};
+
typedef int pps_handle_t; /* represents a PPS source */
typedef unsigned long pps_seq_t; /* sequence number */
typedef struct ntp_fp ntp_fp_t;/* NTP-compatible time stamp */
@@ -86,7 +112,6 @@ void time_pps_readlink(char *link, int linklen, char *path,
int pathlen)
/* Return the file name where "link" points to */
path[i] = '\0';
- return;
}
#define PPS_HAVE_FINDPATH 1
@@ -108,8 +133,10 @@ int time_pps_findpath(char *path, int pathlen, char
*idstring, int idlen)
int time_pps_create(int source, pps_handle_t *handle)
{
- if (!handle)
- return -EINVAL;
+ if (!handle) {
+ errno = -EINVAL;
+ return -1;
+ }
/* In LinuxPPS there are no differences between a PPS source and
* a PPS handle so we return the same value. */
@@ -128,12 +155,33 @@ int time_pps_destroy(pps_handle_t handle)
int time_pps_getparams(pps_handle_t handle,
pps_params_t *ppsparams)
{
- return syscall(__NR_time_pps_getparams, handle, ppsparams);
+ int ret;
+ struct pps_kparams __ppsparams;
+
+ ret = syscall(__NR_time_pps_getparams, handle, &__ppsparams);
+
+ ppsparams->api_version = __ppsparams.api_version;
+ ppsparams->mode = __ppsparams.mode;
+ ppsparams->assert_off_tu.tspec.tv_sec = __ppsparams.assert_off_tu.sec;
+ ppsparams->assert_off_tu.tspec.tv_nsec = __ppsparams.assert_off_tu.nsec;
+ ppsparams->clear_off_tu.tspec.tv_sec = __ppsparams.clear_off_tu.sec;
+ ppsparams->clear_off_tu.tspec.tv_nsec = __ppsparams.clear_off_tu.nsec;
+
+ return ret;
}
int time_pps_setparams(pps_handle_t handle,
const pps_params_t *ppsparams)
{
+ struct pps_kparams __ppsparams;
+
+ __ppsparams.api_version = ppsparams->api_version;
+ __ppsparams.mode = ppsparams->mode;
+ __ppsparams.assert_off_tu.sec = ppsparams->assert_off_tu.tspec.tv_sec;
+ __ppsparams.assert_off_tu.nsec = ppsparams->assert_off_tu.tspec.tv_nsec;
+ __ppsparams.clear_off_tu.sec = ppsparams->clear_off_tu.tspec.tv_sec;
+ __ppsparams.clear_off_tu.nsec = ppsparams->clear_off_tu.tspec.tv_nsec;
+
return syscall(__NR_time_pps_getparams, handle, ppsparams);
}
@@ -147,15 +195,41 @@ int time_pps_fetch(pps_handle_t handle, const int
tsformat,
pps_info_t *ppsinfobuf,
const struct timespec *timeout)
{
- return syscall(__NR_time_pps_fetch, handle,
- tsformat, ppsinfobuf, timeout);
+ struct pps_kinfo __ppsinfobuf;
+ struct pps_ktime __timeout;
+ int ret;
+
+ /* Sanity checks */
+ if (tsformat != PPS_TSFMT_TSPEC) {
+ errno = -EINVAL;
+ return -1;
+ }
+
+ if (timeout) {
+ __timeout.sec = timeout->tv_sec;
+ __timeout.nsec = timeout->tv_nsec;
+ }
+
+ ret = syscall(__NR_time_pps_fetch, handle, &__ppsinfobuf,
+ timeout ? &__timeout : N
Re: [PATCH/RFC] oops and panic message logging to MTD
On Tue, Jun 19, 2007 at 11:00:54AM +0100, Richard Purdie wrote: > Its not a case of formatting the whole partition. The whole point of > this code is the following use case: > > 1. Device crashes > 2. Device reboots > 3. mtdoops partition has a log of why it crashed The oops logger uses oops_in_progress variable to detect the begin and the end of an oops. The end is detected when the first non-oops line comes and oops_in_progress is false. This works if the kernel is still running after the oops and gemerates some non-oops messages. But if there is no non-oops line following an oops, no flushing will occur and there won't be a log on flash. Jarkko Lavinen - 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/7][TAKE5] support new modes in fallocate
On Sat, Jun 30, 2007 at 12:52:46PM -0400, Andreas Dilger wrote:
> The @mode flags that are currently under consideration are (AFAIK):
>
> FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default allocate)
> */
> FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (default change
> size) */
> FA_FL_DEL_DATA0x04 /* delete existing data in alloc range (default
> keep) */
We now have two sets of flags -
1) the above three with which I think no one has any issues with, and
2) the ones below, for which we need some discussions before finalizing
on them.
I will prefer fallocate going in mainline with the above three modes, and
rest of the modes can be debated upon and discussed parallely. And, each
new mode/flag can be pushed as a separate patch. This will not hold
fallocate feature indefinitely...
Please confirm if you find this approach ok. Otherwise, please object.
Thanks!
> FA_FL_ERR_FREE0x08 /* free preallocation on error (default keep
> prealloc) */
> FA_FL_NO_MTIME0x10 /* keep same mtime (default change on size, data
> change) */
> FA_FL_NO_CTIME0x20 /* keep same ctime (default change on size, data
> change) */
--
Regards,
Amit Arora
-
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/7][TAKE5] support new modes in fallocate
On Tue, Jul 03, 2007 at 03:38:48PM +0530, Amit K. Arora wrote:
> > FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default
> > allocate) */
> > FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (default change
> > size) */
> > FA_FL_DEL_DATA 0x04 /* delete existing data in alloc range (default
> > keep) */
>
> We now have two sets of flags -
> 1) the above three with which I think no one has any issues with, and
Yes, I do. FA_FL_DEL_DATA is plain stupid, a preallocation call should
never delete data. FA_FL_DEALLOC should probably be a separate syscall
because it's very different functionality.
While we're at it I also dislike the FA_ prefix becuase it doesn't say
anything and is far too generic. FALLOC_ is much better.
> > FA_FL_ERR_FREE 0x08 /* free preallocation on error (default keep
> > prealloc) */
NACK on this one. We should have just one behaviour, and from the thread
that not freeing the allocation on error.
> > FA_FL_NO_MTIME 0x10 /* keep same mtime (default change on size, data
> > change) */
> > FA_FL_NO_CTIME 0x20 /* keep same ctime (default change on size, data
> > change) */
NACK to these aswell. If i_size changes c/mtime need updates, if the size
doesn't chamge they don't. No need to add more flags for this.
-
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: PKTCDVD related bugzilla bugs
On Mon, 2 Jul 2007, Tejun Heo wrote: Hello, it's me again. We have another bug which reportedly is related to pktcdvd. Please respond. http://bugzilla.kernel.org/show_bug.cgi?id=7547 http://bugzilla.kernel.org/show_bug.cgi?id=7805 The problem is that when you run pktsetup, the driver will open the cdrom device and keep it open. A very long time ago, the driver didn't do that, but that caused other problems, see for example: http://herbie.ucs.indiana.edu/hypermail/linux/kernel/0407.0/0761.html I don't know how to fix these problems in the kernel, but I know that an old idea from Jens Axboe was to merge pktsetup and mount in user space so that pktsetup only needs to run when you are actually going to use packet writing. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - 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/
shouldn't LVM support be selected by default?
just built a new kernel and didn't notice that support for LVM wasn't selected by default for x86. given what i thought was fairly widespread use of LVM2, wouldn't it make sense to have this option as part of the default config? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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: [EXT4 set 3][PATCH 1/1] ext4 nanosecond timestamp
On Sun, 2007-07-01 at 03:36 -0400, Mingming Cao wrote:
> +
> +#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode)
>\
> +do {\
> + (inode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime); \
> + if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra)) \
> + ext4_decode_extra_time(&(inode)->xtime,\
> +raw_inode->xtime ## _extra);\
> +} while (0)
> +
> +#define EXT4_EINODE_GET_XTIME(xtime, einode, raw_inode)
>\
> +do {\
> + if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime)) \
> + (einode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime); \
> + if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime ## _extra))\
> + ext4_decode_extra_time(&(einode)->xtime, \
> +raw_inode->xtime ## _extra);\
> +} while (0)
> +
This nanosecond patch seems to be missing the fix below which is required for
http://bugzilla.kernel.org/show_bug.cgi?id=5079
If the timestamp is set to before epoch i.e. a negative timestamp then the file
may have its date set into the future on 64-bit systems. So when the timestamp
is read it must be cast as signed.
Index: linux-2.6.21/include/linux/ext4_fs.h
===
--- linux-2.6.21.orig/include/linux/ext4_fs.h
+++ linux-2.6.21/include/linux/ext4_fs.h
@@ -390,7 +390,7 @@ do {
\
#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode) \
do { \
- (inode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime); \
+ (inode)->xtime.tv_sec = (signed)le32_to_cpu((raw_inode)->xtime); \
if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra)) \
ext4_decode_extra_time(&(inode)->xtime,\
raw_inode->xtime ## _extra);\
@@ -399,7 +399,8 @@ do {
\
#define EXT4_EINODE_GET_XTIME(xtime, einode, raw_inode)
\
do { \
if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime)) \
- (einode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime); \
+ (einode)->xtime.tv_sec = \
+ (signed)le32_to_cpu((raw_inode)->xtime); \
if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime ## _extra))\
ext4_decode_extra_time(&(einode)->xtime, \
raw_inode->xtime ## _extra);\
Thanks,
Kalpak.
-
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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
> > So to summarize, the plan that makes things work with fuse is: > > > > - For STR, don't do the freezer thing. > > > > - For STD, don't sys_sync() after you froze > > > > There might be -other- issues, but that should get you through some of > > At the risk of repeating myself. Character device drivers are written > with the assumption that normal io and suspend/resume do not race > with each other due to the freezer. > What do you intend to do about that? Oliver, can you please explain your worries in a bit more detail? I don't claim to know anything about how STR or hibernate works, but neither seem to have any problem with I/O on the fuse device "racing" with them. And conceptually I can't see anything that would cause trouble either. The fuse kernel module just provides a specialized IPC mechanism, where one userspace process communicates with another using file operations and a char dev. Miklos - 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: [EXT4 set 3][PATCH 1/1] ext4 nanosecond timestamp
On Sun, 2007-07-01 at 03:36 -0400, Mingming Cao wrote:
> +
> +#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode)
>\
> +do {\
> + (inode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime); \
> + if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra)) \
> + ext4_decode_extra_time(&(inode)->xtime,\
> +raw_inode->xtime ## _extra);\
> +} while (0)
> +
> +#define EXT4_EINODE_GET_XTIME(xtime, einode, raw_inode)
>\
> +do {\
> + if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime)) \
> + (einode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime); \
> + if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime ## _extra))\
> + ext4_decode_extra_time(&(einode)->xtime, \
> +raw_inode->xtime ## _extra);\
> +} while (0)
> +
This nanosecond patch seems to be missing the fix below which is required for
http://bugzilla.kernel.org/show_bug.cgi?id=5079
If the timestamp is set to before epoch i.e. a negative timestamp then the file
may have its date set into the future on 64-bit systems. So when the timestamp
is read it must be cast as signed.
Index: linux-2.6.21/include/linux/ext4_fs.h
===
--- linux-2.6.21.orig/include/linux/ext4_fs.h
+++ linux-2.6.21/include/linux/ext4_fs.h
@@ -390,7 +390,7 @@ do {
\
#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode) \
do { \
- (inode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime); \
+ (inode)->xtime.tv_sec = (signed)le32_to_cpu((raw_inode)->xtime); \
if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra)) \
ext4_decode_extra_time(&(inode)->xtime,\
raw_inode->xtime ## _extra);\
@@ -399,7 +399,8 @@ do {
\
#define EXT4_EINODE_GET_XTIME(xtime, einode, raw_inode)
\
do { \
if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime)) \
- (einode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime); \
+ (einode)->xtime.tv_sec = \
+ (signed)le32_to_cpu((raw_inode)->xtime); \
if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime ## _extra))\
ext4_decode_extra_time(&(einode)->xtime, \
raw_inode->xtime ## _extra);\
Thanks,
Kalpak.
-
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/
MTRR Patch still applies to 2.6.22-rc7.
Incase anyone is interested: p34:/usr/src/linux-2.6.22-rc7# patch -p1 < ../mtrr-v3.patch patching file Documentation/kernel-parameters.txt Hunk #1 succeeded at 548 (offset -5 lines). patching file arch/i386/kernel/cpu/mtrr/generic.c Hunk #2 succeeded at 85 (offset 1 line). patching file arch/i386/kernel/cpu/mtrr/if.c patching file arch/i386/kernel/cpu/mtrr/main.c patching file arch/i386/kernel/cpu/mtrr/mtrr.h patching file arch/x86_64/kernel/bugs.c patching file arch/x86_64/kernel/setup.c patching file include/asm-x86_64/mtrr.h p34:/usr/src/linux-2.6.22-rc7# - 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
> > > > So to summarize, the plan that makes things work with fuse is: > > > > > > > > - For STR, don't do the freezer thing. > > > > > > > > - For STD, don't sys_sync() after you froze > > > > > > > > There might be -other- issues, but that should get you through some of > > > > > > At the risk of repeating myself. Character device drivers are written > > > with the assumption that normal io and suspend/resume do not race > > > with each other due to the freezer. > > > What do you intend to do about that? > > > > Oliver, can you please explain your worries in a bit more detail? > > > > I don't claim to know anything about how STR or hibernate works, but > > neither seem to have any problem with I/O on the fuse device "racing" > > with them. > > The problem is not with fuse. The problem is generic in nature. > > If you remove the freezer, user space remains active until the last CPU > goes into suspend. It can do syscalls. Or do you know a clean way to exempt > only the tasks fuse might use? You are talking about hibernate, right? Suspending (to ram) is instantaneous, in that _after_ suspend no CPU is active obviously. > Now device drivers have a guaranteed temporal sequence: > > last io -> suspend() -> resume() [or disconnect()] -> new io > > This is because suspend() is called after the freezer goes into action. If > you remove the freezer, you need to deal with > > 1. io to suspended devices > 2. resume() assuming that the device is in the state suspend() left it > 3. io changing a device's state while suspend is saving it > > and you need to fix this for all device drivers, not just those fuse is > involved with. Removing the freezer means doing a more or less full > audit of every driver and additional locking in many drivers. OK, this has _nothing_ at all to do with fuse then, and everything to do with disk I/O. Just because fuse is a filesystem, it doesn't have to do anything with block devices, just like procfs doesn't either. So removing the freezer from the hibernate path would be problematic, but as I understand this is not what has been proposed, only removing the freezer from the STR path, which should be OK. Miklos - 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Oliver Neukum writes: > At the risk of repeating myself. Character device drivers are written > with the assumption that normal io and suspend/resume do not race > with each other due to the freezer. > What do you intend to do about that? Going back to the old powerbook sleep code, we had a two-phase suspend: drivers got notified once when userspace is still running, with interrupts enabled, in process context; and then a second time with interrupts disabled and with only one CPU up, so the process that is initiating the suspend is the only process running (since interrupts are disabled and nothing it does can sleep, no other process can get to run). I still believe that is the right way to go, although we currently only have a single-phase suspend. Most drivers suspended their hardware in the second call. If they are in the middle of a conversation with their device that *has* to be completed, they can do that by polling. If it's a character device, a better approach would be to set a flag or whatever in the first suspend call to make sure that no new conversations get started with the device, sleeping if necessary. I'm actually having a hard time thinking of how to test your assertion since there are so few things on a typical computer that are plain character devices driving real hardware. A serial port would be about the only one; keyboards and mice (and serial ports :) are USB these days, or ADB on older powerbooks. Or did you mean to include drivers for pseudo-devices (e.g. ptys)? I don't see why they would have a suspend method at all. 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Miklos Szeredi: > > > > > So to summarize, the plan that makes things work with fuse is: > > > > > > > > > > - For STR, don't do the freezer thing. > > > > > > > > > > - For STD, don't sys_sync() after you froze > > > > > > > > > > There might be -other- issues, but that should get you through some of > > > > > > > > At the risk of repeating myself. Character device drivers are written > > > > with the assumption that normal io and suspend/resume do not race > > > > with each other due to the freezer. > > > > What do you intend to do about that? > > > > > > Oliver, can you please explain your worries in a bit more detail? > > > > > > I don't claim to know anything about how STR or hibernate works, but > > > neither seem to have any problem with I/O on the fuse device "racing" > > > with them. > > > > The problem is not with fuse. The problem is generic in nature. > > > > If you remove the freezer, user space remains active until the last CPU > > goes into suspend. It can do syscalls. Or do you know a clean way to exempt > > only the tasks fuse might use? > > You are talking about hibernate, right? Suspending (to ram) is > instantaneous, in that _after_ suspend no CPU is active obviously. If that is so, why do you care? If it is really atomic, fuse has no chance to call out to its component in user space either. Removing the freezer cannot make a difference. Something is fishy here. Regards Oliver - 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Miklos Szeredi: > > > So to summarize, the plan that makes things work with fuse is: > > > > > > - For STR, don't do the freezer thing. > > > > > > - For STD, don't sys_sync() after you froze > > > > > > There might be -other- issues, but that should get you through some of > > > > At the risk of repeating myself. Character device drivers are written > > with the assumption that normal io and suspend/resume do not race > > with each other due to the freezer. > > What do you intend to do about that? > > Oliver, can you please explain your worries in a bit more detail? > > I don't claim to know anything about how STR or hibernate works, but > neither seem to have any problem with I/O on the fuse device "racing" > with them. The problem is not with fuse. The problem is generic in nature. If you remove the freezer, user space remains active until the last CPU goes into suspend. It can do syscalls. Or do you know a clean way to exempt only the tasks fuse might use? Now device drivers have a guaranteed temporal sequence: last io -> suspend() -> resume() [or disconnect()] -> new io This is because suspend() is called after the freezer goes into action. If you remove the freezer, you need to deal with 1. io to suspended devices 2. resume() assuming that the device is in the state suspend() left it 3. io changing a device's state while suspend is saving it and you need to fix this for all device drivers, not just those fuse is involved with. Removing the freezer means doing a more or less full audit of every driver and additional locking in many drivers. Regards Oliver - 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: Error in syslog on 2.6.20
On Tue, Jul 03, 2007 at 04:26:31PM +0900, Tejun Heo wrote: > William Thompson wrote: > > I'm not on either list, keep me in CC. > > > > I noticed the following error on a cdrom device: > > ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > > ata2.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 > > res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout) > > ata2: soft resetting port > > ata2.00: configured for MWDMA2 > > ata2: EH complete > > > > This is the device when it was found: > > libata version 2.00 loaded. > > ata_piix :00:1f.1: version 2.00ac7 > > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14 > > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 > > scsi0 : ata_piix > > ata1.00: ATA-4, max UDMA/66, 16514064 sectors: LBA > > ata1.00: ata1: dev 0 multi count 8 > > ata1.00: configured for UDMA/66 > > scsi1 : ata_piix > > ata2.00: ATAPI, max MWDMA2 > > ata2.00: configured for MWDMA2 > > scsi 0:0:0:0: Direct-Access ATA WDC WD84AA 05.0 PQ: 0 ANSI: 5 > > scsi 1:0:0:0: CD-ROMLITEON CD-ROM LTN486S YQSM PQ: 0 ANSI: 5 > > > > I have a program that does a scsi TEST UNIT READY on many devices once every > > .1 second. The problem occured when I ejected the cdrom and closed the tray > > again with valid media in the drive. My program noticed media removed and > > inserted, then said the device was dead/unpollable. This is when I saw this > > error. > > Your cd rom failed to complete the TUR command your program issued in > the specified timeout. ODDs sometimes take quite long to finish TUR or > any other command when media is changed. Did you use sg command or > cdrom ioctl? I'm using SG_IO. I also tested sg3-utils' sg_tur which gave me the same thing. Is it just a crappy cdrom? > Anyways, after timing out, libata EH kicked the cdrom in the ass and > world peace is restored. Ah, that's good. - 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/
Problem with size after growing a device
Hi, I don't know really which subsystem this, so I'm sending this to the linux-kernel list. Please direct me to a more appropriate place if this is not correct. I'm using a 3ware 9500 with Linux 2.6.18.1. I've grown the HW raid5-array and here is where the problem begins. After the card had expanded the array, I used "blockdev --rereadpt /dev/sdk" to get the kernel to recognize the now larger device. The last step was to do a "pvresize /dev/sdk". The problem is that pvresize still thought that the device was at the original size. From the lvm mailinglist I found out that pvresize used the same mechanism as "blockdev --getsz" to get the size of the disks, so I tested this and found that blockdev also reported the device to have the wrong size. So, if I do: # cat /sys/block/sdk/size 4882708480 and # blockdev --getsz /dev/sdk 3906166784 Apparently /sys/block/sdk/size is updated with the new size, but whatever "blockdev --getsz" and "pvresize" is querying is not. If I reboot, everything works correctly. Best Regards, /LM Ps. please keep me as Cc: on this; since I'm not subscibed to the linux-kernel list.. - 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Paul Mackerras: > I'm actually having a hard time thinking of how to test your assertion > since there are so few things on a typical computer that are plain > character devices driving real hardware. A serial port would be about > the only one; keyboards and mice (and serial ports :) are USB these > days, or ADB on older powerbooks. USB devices certainly have suspend methods. Regards Oliver - 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tue, 2007-07-03 at 09:44 +0200, Oliver Neukum wrote: > Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > So to summarize, the plan that makes things work with fuse is: > > > > - For STR, don't do the freezer thing. > > > > - For STD, don't sys_sync() after you froze > > > > There might be -other- issues, but that should get you through some of > > At the risk of repeating myself. Character device drivers are written > with the assumption that normal io and suspend/resume do not race > with each other due to the freezer. > What do you intend to do about that? Ugh ... "character devices" ... that's a pretty wide statement... there's lots of those and very different one from the other... Any sane device-driver will have to cope with being suspended in a "live" system. I've demonstrated multiple times in the past why this is necessary anyway, for things like dynamic power management, among others. The whole freezer thing is a hack job to avoid fixing drivers that need fixing. Unfortunately, I believe in that area, it's simply not sustainable. Besides, getting drivers to behave properly isn't very hard in most 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tue, 2007-07-03 at 13:27 +0200, Oliver Neukum wrote: > > You are talking about hibernate, right? Suspending (to ram) is > > instantaneous, in that _after_ suspend no CPU is active obviously. > > If that is so, why do you care? If it is really atomic, fuse has no > chance > to call out to its component in user space either. Removing the > freezer > cannot make a difference. It's not atomic. You will get called after suspend() in drivers. The thing is ... you just have to deal 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: [PATCH 4/7][TAKE5] support new modes in fallocate
On Tue, Jul 03, 2007 at 11:31:07AM +0100, Christoph Hellwig wrote:
> On Tue, Jul 03, 2007 at 03:38:48PM +0530, Amit K. Arora wrote:
> > > FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default
> > > allocate) */
> > > FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (default change
> > > size) */
> > > FA_FL_DEL_DATA0x04 /* delete existing data in alloc range (default
> > > keep) */
> >
> > We now have two sets of flags -
> > 1) the above three with which I think no one has any issues with, and
>
> Yes, I do. FA_FL_DEL_DATA is plain stupid, a preallocation call should
> never delete data. FA_FL_DEALLOC should probably be a separate syscall
> because it's very different functionality.
Well, if you see the modes proposed using above flags :
#define FA_ALLOCATE 0
#define FA_DEALLOCATE FA_FL_DEALLOC
#define FA_RESV_SPACE FA_FL_KEEP_SIZE
#define FA_UNRESV_SPACE (FA_FL_DEALLOC | FA_FL_KEEP_SIZE | FA_FL_DEL_DATA)
FA_FL_DEL_DATA is _not_ being used for preallocation. We have two modes
for preallocation FA_ALLOCATE and FA_RESV_SPACE, which do not use this
flag. Hence prealloction will never delete data.
This mode is required only for FA_UNRESV_SPACE, which is a deallocation
mode, to support any existing XFS aware applications/usage-scenarios.
And, regarding FA_FL_DEALLOC being a separate syscall - I think then the
very purpose of @mode argument is not justified. We have this mode so
that we can provide more features like this. That said, I don't say that
we should make things very complicated; but, atleast we should provide
some basic features which we expect most of the applications wanting
preallocation to use. To start with, we need to cater to already
existing applications/user base who use XFS preallocation feature.
And further advanced features, like goal based preallocation, can be
implemented as a separate syscall.
> While we're at it I also dislike the FA_ prefix becuase it doesn't say
> anything and is far too generic. FALLOC_ is much better.
Ok. This can be changed in the next take.
> > > FA_FL_ERR_FREE0x08 /* free preallocation on error (default keep
> > > prealloc) */
>
> NACK on this one. We should have just one behaviour, and from the thread
> that not freeing the allocation on error.
I agree on this one.
> > > FA_FL_NO_MTIME0x10 /* keep same mtime (default change on size, data
> > > change) */
> > > FA_FL_NO_CTIME0x20 /* keep same ctime (default change on size, data
> > > change) */
>
> NACK to these aswell. If i_size changes c/mtime need updates, if the size
> doesn't chamge they don't. No need to add more flags for this.
This requirement was from the point of view of HSM applications. Hope
you saw Andreas previous post and are keeping that in mind.
--
Regards,
Amit Arora
-
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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > On Tue, 2007-07-03 at 09:44 +0200, Oliver Neukum wrote: > > Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > > So to summarize, the plan that makes things work with fuse is: > > > > > > - For STR, don't do the freezer thing. > > > > > > - For STD, don't sys_sync() after you froze > > > > > > There might be -other- issues, but that should get you through some of > > > > At the risk of repeating myself. Character device drivers are written > > with the assumption that normal io and suspend/resume do not race > > with each other due to the freezer. > > What do you intend to do about that? > > Ugh ... "character devices" ... that's a pretty wide statement... > there's lots of those and very different one from the other... That is a good summary of the problem ;-( > Any sane device-driver will have to cope with being suspended in a > "live" system. I've demonstrated multiple times in the past why this is > necessary anyway, for things like dynamic power management, among > others. That is an interesting notion. I'd rather see device drivers reporting their devices idle and requsting to be suspended. But in any case it doesn't solve the problem. Regards Oliver - 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
> The problem is not with fuse. The problem is generic in nature. > > If you remove the freezer, user space remains active until the last CPU > goes into suspend. It can do syscalls. Or do you know a clean way to exempt > only the tasks fuse might use? > > Now device drivers have a guaranteed temporal sequence: > > last io -> suspend() -> resume() [or disconnect()] -> new io No, that's always been bullshit. You can have IOs emitted by kernel threads (think knfsd, and that's just one among many others). Beside, relying on having userland frozen means that your driver will be unable to be "live" suspended/resumed for more ambitious dynamic power management schemes. So it's always been wrong, imho, to rely on that. I've had powermac STR work fine without the freezer for years, and few drivers have been a problem, and we just fixed them. The freezer thingy, at best, hides problems, causing them not to be fixed. > This is because suspend() is called after the freezer goes into action. If > you remove the freezer, you need to deal with > > 1. io to suspended devices > 2. resume() assuming that the device is in the state suspend() left it > 3. io changing a device's state while suspend is saving it > > and you need to fix this for all device drivers, not just those fuse is > involved with. Removing the freezer means doing a more or less full > audit of every driver and additional locking in many drivers. Yes, more or less. The good news is that a whole lot of drivers don't really care much, and in some cases, things can be done trivially with a bit of help from the upper layers. But yeah, as I've been explaining over and over again, the lazy approach here doesn't work. 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > On Tue, 2007-07-03 at 13:27 +0200, Oliver Neukum wrote: > > > You are talking about hibernate, right? Suspending (to ram) is > > > instantaneous, in that _after_ suspend no CPU is active obviously. > > > > If that is so, why do you care? If it is really atomic, fuse has no > > chance > > to call out to its component in user space either. Removing the > > freezer > > cannot make a difference. > > It's not atomic. You will get called after suspend() in drivers. The > thing is ... you just have to deal with it :-) So you are volunteering to go through all drivers >:-> ? Regards Oliver - 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 0/3] ACPI autoloading
On Tue, 2007-07-03 at 03:40 -0400, Len Brown wrote:
> > A) Cannot pass acpi_device_id through ops.add (probe equivalent func)
> > -
> >
> > int acpi_match_device_ids(..)
> > should be:
> > const acpi_device_id *acpi_match_device_ids
> > and the matching device id should get passed to the acpi driver's .add
> > function.
> > This would ease up the code in the ACPI driver a lot (e.g. see button.c,
> > it is compared again which device (HID) has been found. Theoretically
> > the drivers also needs to check CIDs...).
> >
> > The problem is that in scan.c ACPI driver is abstracted to use .match
> > and .probe "struct bus_type" functions and I have no idea how the
> > matching acpi_device_id should get passed or stored from
> > acpi_match_device_ids (.match) to ops.add (invoked in .probe).
> > Currently:
> > kernel_ulong_t driver_data;
> > of acpi_device_id got added, but is not used at all atm.
> >
> > B) Thermal module always gets loaded
> >
> >
> > This is because _TZ_ (scope?!?) always gets added, but is declared as a
> > device or at least pops up as a thermal device.
> > This is in drivers/acpi/utilities/utglobal.c:
> >
> > /*
> > * Predefined ACPI Names (Built-in to the Interpreter)
> > *
> > * NOTES:
> > * 1) _SB_ is defined to be a device to allow \_SB_._INI to be run
> > *during the initialization sequence.
> > * 2) _TZ_ is defined to be a thermal zone in order to allow ASL code to
> > *perform a Notify() operation on it.
> > */
> >
> > Any idea how to get rid of that is very welcome.
> > Is this to be able to process buggy ASL code of this kind?:
> > "Notify ("_TZ_", 0x80)"
> > While _TZ_ is not a real device, but a scope operator and gets
> > statically declared as a device here to solve such things?
>
> ThermalZone objects hang under _TZ, whether TZ it be global, or under _SB
> I would think that if there are no ThermalZone objects,
> then we'd not need to bind the thermal driver.
>
> However, this would be a custom binding method (like acpi video.c)
> rather than a HID based one.
>
> I'm really not sure about the _TZ_ syntax -- we'll have to ask Bob
> where that came from when he returns -- but I don't think it matters
> for the issue at hand.
Yeah. It's the same behavior as before then, as everybody would try to
load the thermal module on all i386/x86_64 machines anyway.
Would be great if Bob could give a short comment, maybe I start digging
a bit deeper if I find the time to find out why this is and how this can
get workarounded (in another way, already looks like a workaround).
>
> > C) Renaming/Unifying of HID strings
> > ---
> >
> > This shouldn't be a problem. Consequence is that the new ACPI sysfs
> > structure will show other names, but as it got introduced recently this
> > shouldn't hurt anyone?
>
> I agree that it is still new and that it is unlikely that a re-name
> now would be a significant compatibility issue.
>
> > For better readability we could map all HIDs to a device name through a
> > HID <-> Device Name - enum and table. And then export "battery" again
> > through /sys instead of "PNP0C0A".
> > This was a bit mixed up. If, this should get implemented soon as the
> > sysfs structure should not get altered that often...
> > If wanted, I can send an on top patch later...
>
> We've had this discussion before.
>
> I'm inclined to keep the kernel as simple as possible, and let
> some user-space thingie look up standard strings in some user-space table.
> I don't want to get into the game of trying to make sysfs
> so user-friendly, that a kernel re-build is necessary to add/translate
> a new string...
>
> that said, if we have to _invent_ a new string, it might as well
> be something meaningful to a human.
I don't know. Maybe Kay could give a comment whether it's useful/common
to have the PNPwxyz:00 path in /sys/../acpi/... to be evaluated to e.g.
a battery:00 or ac_adapter:00 path name.
IMO it is useful. Any user who knows about linux, but has no idea about
ACPI will find battery info by simply "find /sys |grep battery".
Disadvantage would be the size of the strings mapping to the PNP ids, I
think it's not that bad.
OTH you stick to the spec name of the device.
No idea what is better/nicer, but we should decide before 2.6.23...
For the latter we could add another documentation file,
acpi_hids_mapping.txt listing all supported Hids?
Userspace (HAL) would need to know about the ids then..., maybe these
guys have any preferences?
>
> > D) Why renaming struct acpi_device_id to struct __acpi_device_id
> >
> > Not a problem, just for understanding why I have done this:
> > struct acpi_device_id already exists in ACPICA. The module aliasing
> > interface requires that struct "SUBSYSTEM"_device_id is used as name.
> > This is not that obvious (include/linux/module.h):
> > #define MODULE_GENERIC_TABLE(gtype,name) a
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > Now device drivers have a guaranteed temporal sequence: > > > > last io -> suspend() -> resume() [or disconnect()] -> new io > > No, that's always been bullshit. You can have IOs emitted by kernel > threads (think knfsd, and that's just one among many others). Beside, That's why we have the problem of freezing the kernel threads or not. Short of knfsd very few kernel threads really operate on their own and those can use the new notifier chain. > relying on having userland frozen means that your driver will be unable > to be "live" suspended/resumed for more ambitious dynamic power > management schemes. Only if they work without cooperation and idle detection in the drivers. > So it's always been wrong, imho, to rely on that. I've had powermac STR > work fine without the freezer for years, and few drivers have been a > problem, and we just fixed them. Powermacs are somewhat limited in hardware used with them (OK, powerbook have PCMCIA, but how often is that used?) You want to have all that pain for fuse? Regards Oliver - 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: Error in syslog on 2.6.20
William Thompson wrote: >> Your cd rom failed to complete the TUR command your program issued in >> the specified timeout. ODDs sometimes take quite long to finish TUR or >> any other command when media is changed. Did you use sg command or >> cdrom ioctl? > > I'm using SG_IO. I also tested sg3-utils' sg_tur which gave me the same > thing. Is it just a crappy cdrom? Not necessarily. It could be just that you're specifying too short timeout. Give a shot at longer timeout. -- tejun - 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> > So to summarize, the plan that makes things work with fuse is: >> > >> > - For STR, don't do the freezer thing. >> > >> > - For STD, don't sys_sync() after you froze >> > >> > There might be -other- issues, but that should get you through some of >> >> At the risk of repeating myself. Character device drivers are written >> with the assumption that normal io and suspend/resume do not race >> with each other due to the freezer. >> What do you intend to do about that? > > Oliver, can you please explain your worries in a bit more detail? Try suspending while printing. -- What's worse than a Male Chauvinist Pig? A woman that won't do what she's told. Friß, Spammer: [EMAIL PROTECTED] - 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 0/5] some mm improvements + s390 tlb flush.
I have updated my mm patch set. The diff: - The tlb gather restart patch has been changed as discussed with Hugh. - The ptep_establish patch now really removes all traces of the call. - The mm_struct / vm_area_struct move to mm_types.h has been test compiled on a number of architectures. - The page_mkclean_one patch has been dropped because it doesn't seem to have any effect. - There is a new patch to fix a theoretical architectural problem on s390. The patch is required for the 1K/2K page tables for KVM as well. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. - 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 1/5] avoid tlb gather restarts.
From: Martin Schwidefsky <[EMAIL PROTECTED]>
If need_resched() is false in the inner loop of unmap_vmas it is
unnecessary to do a full blown tlb_finish_mmu / tlb_gather_mmu for
each ZAP_BLOCK_SIZE ptes. Do a tlb_flush_mmu() instead. That gives
architectures with a non-generic tlb flush implementation room for
optimization. The tlb_flush_mmu primitive is a available with the
generic tlb flush code, the ia64_tlb_flush_mm needs to be renamed
and a dummy function is added to arm and arm26.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
include/asm-arm/tlb.h |5 +
include/asm-arm26/tlb.h |5 +
include/asm-ia64/tlb.h |6 +++---
mm/memory.c | 16 ++--
4 files changed, 19 insertions(+), 13 deletions(-)
diff -urpN linux-2.6/include/asm-arm/tlb.h
linux-2.6-patched/include/asm-arm/tlb.h
--- linux-2.6/include/asm-arm/tlb.h 2006-11-08 10:45:43.0 +0100
+++ linux-2.6-patched/include/asm-arm/tlb.h 2007-07-03 12:56:46.0
+0200
@@ -52,6 +52,11 @@ tlb_gather_mmu(struct mm_struct *mm, uns
}
static inline void
+tlb_flush_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+{
+}
+
+static inline void
tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
{
if (tlb->fullmm)
diff -urpN linux-2.6/include/asm-arm26/tlb.h
linux-2.6-patched/include/asm-arm26/tlb.h
--- linux-2.6/include/asm-arm26/tlb.h 2006-11-08 10:45:43.0 +0100
+++ linux-2.6-patched/include/asm-arm26/tlb.h 2007-07-03 12:56:46.0
+0200
@@ -29,6 +29,11 @@ tlb_gather_mmu(struct mm_struct *mm, uns
}
static inline void
+tlb_flush_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+{
+}
+
+static inline void
tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
{
if (tlb->need_flush)
diff -urpN linux-2.6/include/asm-ia64/tlb.h
linux-2.6-patched/include/asm-ia64/tlb.h
--- linux-2.6/include/asm-ia64/tlb.h2006-11-08 10:45:45.0 +0100
+++ linux-2.6-patched/include/asm-ia64/tlb.h2007-07-03 12:56:46.0
+0200
@@ -72,7 +72,7 @@ DECLARE_PER_CPU(struct mmu_gather, mmu_g
* freed pages that where gathered up to this point.
*/
static inline void
-ia64_tlb_flush_mmu (struct mmu_gather *tlb, unsigned long start, unsigned long
end)
+tlb_flush_mmu (struct mmu_gather *tlb, unsigned long start, unsigned long end)
{
unsigned int nr;
@@ -160,7 +160,7 @@ tlb_finish_mmu (struct mmu_gather *tlb,
* Note: tlb->nr may be 0 at this point, so we can't rely on
tlb->start_addr and
* tlb->end_addr.
*/
- ia64_tlb_flush_mmu(tlb, start, end);
+ tlb_flush_mmu(tlb, start, end);
/* keep the page table cache within bounds */
check_pgt_cache();
@@ -184,7 +184,7 @@ tlb_remove_page (struct mmu_gather *tlb,
}
tlb->pages[tlb->nr++] = page;
if (tlb->nr >= FREE_PTE_NR)
- ia64_tlb_flush_mmu(tlb, tlb->start_addr, tlb->end_addr);
+ tlb_flush_mmu(tlb, tlb->start_addr, tlb->end_addr);
}
/*
diff -urpN linux-2.6/mm/memory.c linux-2.6-patched/mm/memory.c
--- linux-2.6/mm/memory.c 2007-06-18 09:43:22.0 +0200
+++ linux-2.6-patched/mm/memory.c 2007-07-03 12:56:46.0 +0200
@@ -853,18 +853,15 @@ unsigned long unmap_vmas(struct mmu_gath
break;
}
- tlb_finish_mmu(*tlbp, tlb_start, start);
-
if (need_resched() ||
(i_mmap_lock && need_lockbreak(i_mmap_lock))) {
- if (i_mmap_lock) {
- *tlbp = NULL;
+ if (i_mmap_lock)
goto out;
- }
+ tlb_finish_mmu(*tlbp, tlb_start, start);
cond_resched();
- }
-
- *tlbp = tlb_gather_mmu(vma->vm_mm, fullmm);
+ *tlbp = tlb_gather_mmu(vma->vm_mm, fullmm);
+ } else
+ tlb_flush_mmu(*tlbp, tlb_start, start);
tlb_start_valid = 0;
zap_work = ZAP_BLOCK_SIZE;
}
@@ -892,8 +889,7 @@ unsigned long zap_page_range(struct vm_a
tlb = tlb_gather_mmu(mm, 0);
update_hiwater_rss(mm);
end = unmap_vmas(&tlb, vma, address, end, &nr_accounted, details);
- if (tlb)
- tlb_finish_mmu(tlb, address, end);
+ tlb_finish_mmu(tlb, address, end);
return end;
}
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
-
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
[patch 2/5] remove ptep_establish.
From: Martin Schwidefsky <[EMAIL PROTECTED]>
The last user of ptep_establish in mm/ is long gone. Remove the
architecture primitive as well.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
include/asm-arm/pgtable.h |6 ++---
include/asm-generic/pgtable.h | 19 --
include/asm-i386/pgtable.h| 11 --
include/asm-ia64/pgtable.h|6 +++--
include/asm-s390/pgtable.h| 43 ++
5 files changed, 26 insertions(+), 59 deletions(-)
diff -urpN linux-2.6/include/asm-arm/pgtable.h
linux-2.6-patched/include/asm-arm/pgtable.h
--- linux-2.6/include/asm-arm/pgtable.h 2007-05-09 09:58:15.0 +0200
+++ linux-2.6-patched/include/asm-arm/pgtable.h 2007-07-03 12:56:47.0
+0200
@@ -83,14 +83,14 @@
* means that a write to a clean page will cause a permission fault, and
* the Linux MM layer will mark the page dirty via handle_pte_fault().
* For the hardware to notice the permission change, the TLB entry must
- * be flushed, and ptep_establish() does that for us.
+ * be flushed, and ptep_set_access_flags() does that for us.
*
* The "accessed" or "young" bit is emulated by a similar method; we only
* allow accesses to the page if the "young" bit is set. Accesses to the
* page will cause a fault, and handle_pte_fault() will set the young bit
* for us as long as the page is marked present in the corresponding Linux
- * PTE entry. Again, ptep_establish() will ensure that the TLB is up to
- * date.
+ * PTE entry. Again, ptep_set_access_flags() will ensure that the TLB is
+ * up to date.
*
* However, when the "young" bit is cleared, we deny access to the page
* by clearing the hardware PTE. Currently Linux does not flush the TLB
diff -urpN linux-2.6/include/asm-generic/pgtable.h
linux-2.6-patched/include/asm-generic/pgtable.h
--- linux-2.6/include/asm-generic/pgtable.h 2007-06-18 09:43:22.0
+0200
+++ linux-2.6-patched/include/asm-generic/pgtable.h 2007-07-03
12:56:47.0 +0200
@@ -3,25 +3,6 @@
#ifndef __ASSEMBLY__
-#ifndef __HAVE_ARCH_PTEP_ESTABLISH
-/*
- * Establish a new mapping:
- * - flush the old one
- * - update the page tables
- * - inform the TLB about the new one
- *
- * We hold the mm semaphore for reading, and the pte lock.
- *
- * Note: the old pte is known to not be writable, so we don't need to
- * worry about dirty bits etc getting lost.
- */
-#define ptep_establish(__vma, __address, __ptep, __entry) \
-do { \
- set_pte_at((__vma)->vm_mm, (__address), __ptep, __entry); \
- flush_tlb_page(__vma, __address); \
-} while (0)
-#endif
-
#ifndef __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
/*
* Largely same as above, but only sets the access flags (dirty,
diff -urpN linux-2.6/include/asm-i386/pgtable.h
linux-2.6-patched/include/asm-i386/pgtable.h
--- linux-2.6/include/asm-i386/pgtable.h2007-06-18 09:43:22.0
+0200
+++ linux-2.6-patched/include/asm-i386/pgtable.h2007-07-03
12:56:47.0 +0200
@@ -317,17 +317,6 @@ static inline pte_t native_local_ptep_ge
__ret; \
})
-/*
- * Rules for using ptep_establish: the pte MUST be a user pte, and
- * must be a present->present transition.
- */
-#define __HAVE_ARCH_PTEP_ESTABLISH
-#define ptep_establish(vma, address, ptep, pteval) \
-do { \
- set_pte_present((vma)->vm_mm, address, ptep, pteval); \
- flush_tlb_page(vma, address); \
-} while (0)
-
#define __HAVE_ARCH_PTEP_CLEAR_DIRTY_FLUSH
#define ptep_clear_flush_dirty(vma, address, ptep) \
({ \
diff -urpN linux-2.6/include/asm-ia64/pgtable.h
linux-2.6-patched/include/asm-ia64/pgtable.h
--- linux-2.6/include/asm-ia64/pgtable.h2007-06-18 09:43:22.0
+0200
+++ linux-2.6-patched/include/asm-ia64/pgtable.h2007-07-03
12:56:47.0 +0200
@@ -546,8 +546,10 @@ extern void lazy_mmu_prot_update (pte_t
# define ptep_set_access_flags(__vma, __addr, __ptep, __entry,
__safely_writable) \
({ \
int __changed = !pte_same(*(__ptep), __entry); \
- if (__changed) \
- ptep_establish(__vma, __addr, __ptep, __entry); \
+ if (__changed) {\
+ set_pte_at((__vma)->vm_mm, (__addr), __ptep, __entry); \
+ flush_tlb_page(__vma, __addr); \
+ } \
__changed;
[patch 4/5] move mm_struct and vm_area_struct.
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Move the definitions of struct mm_struct and struct vma_area_struct
to include/mm_types.h. This allows to define more function in
asm/pgtable.h and friends with inline assemblies instead of macros.
Compile tested on i386, ia64, powerpc, powerpc64, s390-32, s390-64
and x86_64.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
include/linux/mm.h | 63
include/linux/mm_types.h | 143 +++
include/linux/sched.h| 74
3 files changed, 144 insertions(+), 136 deletions(-)
diff -urpN linux-2.6/include/linux/mm.h linux-2.6-patched/include/linux/mm.h
--- linux-2.6/include/linux/mm.h2007-06-22 14:11:55.0 +0200
+++ linux-2.6-patched/include/linux/mm.h2007-07-03 12:56:50.0
+0200
@@ -51,69 +51,6 @@ extern int sysctl_legacy_va_layout;
* mmap() functions).
*/
-/*
- * This struct defines a memory VMM memory area. There is one of these
- * per VM-area/task. A VM area is any part of the process virtual memory
- * space that has a special rule for the page-fault handlers (ie a shared
- * library, the executable area etc).
- */
-struct vm_area_struct {
- struct mm_struct * vm_mm; /* The address space we belong to. */
- unsigned long vm_start; /* Our start address within vm_mm. */
- unsigned long vm_end; /* The first byte after our end address
- within vm_mm. */
-
- /* linked list of VM areas per task, sorted by address */
- struct vm_area_struct *vm_next;
-
- pgprot_t vm_page_prot; /* Access permissions of this VMA. */
- unsigned long vm_flags; /* Flags, listed below. */
-
- struct rb_node vm_rb;
-
- /*
-* For areas with an address space and backing store,
-* linkage into the address_space->i_mmap prio tree, or
-* linkage to the list of like vmas hanging off its node, or
-* linkage of vma in the address_space->i_mmap_nonlinear list.
-*/
- union {
- struct {
- struct list_head list;
- void *parent; /* aligns with prio_tree_node parent */
- struct vm_area_struct *head;
- } vm_set;
-
- struct raw_prio_tree_node prio_tree_node;
- } shared;
-
- /*
-* A file's MAP_PRIVATE vma can be in both i_mmap tree and anon_vma
-* list, after a COW of one of the file pages. A MAP_SHARED vma
-* can only be in the i_mmap tree. An anonymous MAP_PRIVATE, stack
-* or brk vma (with NULL file) can only be in an anon_vma list.
-*/
- struct list_head anon_vma_node; /* Serialized by anon_vma->lock */
- struct anon_vma *anon_vma; /* Serialized by page_table_lock */
-
- /* Function pointers to deal with this struct. */
- struct vm_operations_struct * vm_ops;
-
- /* Information about our backing store: */
- unsigned long vm_pgoff; /* Offset (within vm_file) in PAGE_SIZE
- units, *not* PAGE_CACHE_SIZE */
- struct file * vm_file; /* File we map to (can be NULL). */
- void * vm_private_data; /* was vm_pte (shared mem) */
- unsigned long vm_truncate_count;/* truncate_count or restart_addr */
-
-#ifndef CONFIG_MMU
- atomic_t vm_usage; /* refcount (VMAs shared if !MMU) */
-#endif
-#ifdef CONFIG_NUMA
- struct mempolicy *vm_policy;/* NUMA policy for the VMA */
-#endif
-};
-
extern struct kmem_cache *vm_area_cachep;
/*
diff -urpN linux-2.6/include/linux/mm_types.h
linux-2.6-patched/include/linux/mm_types.h
--- linux-2.6/include/linux/mm_types.h 2007-05-11 09:19:04.0 +0200
+++ linux-2.6-patched/include/linux/mm_types.h 2007-07-03 12:56:50.0
+0200
@@ -1,13 +1,25 @@
#ifndef _LINUX_MM_TYPES_H
#define _LINUX_MM_TYPES_H
+#include /* For AT_VECTOR_SIZE */
#include
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
struct address_space;
+#if NR_CPUS >= CONFIG_SPLIT_PTLOCK_CPUS
+typedef atomic_long_t mm_counter_t;
+#else /* NR_CPUS < CONFIG_SPLIT_PTLOCK_CPUS */
+typedef unsigned long mm_counter_t;
+#endif /* NR_CPUS < CONFIG_SPLIT_PTLOCK_CPUS */
+
/*
* Each physical page in the system has a struct page associated with
* it to keep track of whatever it is we are using the page for at the
@@ -80,4 +92,135 @@ struct page {
#endif /* WANT_PAGE_VIRTUAL */
};
+/*
+ * This struct defines a memory VMM memory area. There is one of these
+ * per VM-area/task. A VM area is any part of the process virtual memory
+ * space that has a special rule for the page-fault handlers (ie a shared
+ * library, the executable area etc).
+ */
+struct vm_area_struct {
+ struct mm_struct * vm_mm; /* The address space
[patch 3/5] remove ptep_test_and_clear_dirty and ptep_clear_flush_dirty.
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Nobody is using ptep_test_and_clear_dirty and ptep_clear_flush_dirty.
Remove the functions from all architectures.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
include/asm-frv/pgtable.h |8
include/asm-generic/pgtable.h | 25 -
include/asm-i386/pgtable.h | 21 -
include/asm-ia64/pgtable.h | 17 -
include/asm-m32r/pgtable.h |6 --
include/asm-parisc/pgtable.h| 16
include/asm-powerpc/pgtable-ppc32.h |7 ---
include/asm-powerpc/pgtable-ppc64.h | 31 ---
include/asm-ppc/pgtable.h |7 ---
include/asm-s390/pgtable.h | 15 ---
include/asm-x86_64/pgtable.h|8
include/asm-xtensa/pgtable.h| 12
12 files changed, 173 deletions(-)
diff -urpN linux-2.6/include/asm-frv/pgtable.h
linux-2.6-patched/include/asm-frv/pgtable.h
--- linux-2.6/include/asm-frv/pgtable.h 2007-07-02 08:45:46.0 +0200
+++ linux-2.6-patched/include/asm-frv/pgtable.h 2007-07-03 12:56:49.0
+0200
@@ -394,13 +394,6 @@ static inline pte_t pte_mkdirty(pte_t pt
static inline pte_t pte_mkyoung(pte_t pte) { (pte).pte |= _PAGE_ACCESSED;
return pte; }
static inline pte_t pte_mkwrite(pte_t pte) { (pte).pte &= ~_PAGE_WP;
return pte; }
-static inline int ptep_test_and_clear_dirty(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
-{
- int i = test_and_clear_bit(_PAGE_BIT_DIRTY, ptep);
- asm volatile("dcf %M0" :: "U"(*ptep));
- return i;
-}
-
static inline int ptep_test_and_clear_young(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
{
int i = test_and_clear_bit(_PAGE_BIT_ACCESSED, ptep);
@@ -510,7 +503,6 @@ static inline int pte_file(pte_t pte)
remap_pfn_range(vma, vaddr, pfn, size, prot)
#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
-#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_DIRTY
#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
#define __HAVE_ARCH_PTEP_SET_WRPROTECT
#define __HAVE_ARCH_PTE_SAME
diff -urpN linux-2.6/include/asm-generic/pgtable.h
linux-2.6-patched/include/asm-generic/pgtable.h
--- linux-2.6/include/asm-generic/pgtable.h 2007-07-03 12:56:49.0
+0200
+++ linux-2.6-patched/include/asm-generic/pgtable.h 2007-07-03
12:56:49.0 +0200
@@ -49,31 +49,6 @@
})
#endif
-#ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_DIRTY
-#define ptep_test_and_clear_dirty(__vma, __address, __ptep)\
-({ \
- pte_t __pte = *__ptep; \
- int r = 1; \
- if (!pte_dirty(__pte)) \
- r = 0; \
- else\
- set_pte_at((__vma)->vm_mm, (__address), (__ptep), \
- pte_mkclean(__pte)); \
- r; \
-})
-#endif
-
-#ifndef __HAVE_ARCH_PTEP_CLEAR_DIRTY_FLUSH
-#define ptep_clear_flush_dirty(__vma, __address, __ptep) \
-({ \
- int __dirty;\
- __dirty = ptep_test_and_clear_dirty(__vma, __address, __ptep); \
- if (__dirty)\
- flush_tlb_page(__vma, __address); \
- __dirty;\
-})
-#endif
-
#ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR
#define ptep_get_and_clear(__mm, __address, __ptep)\
({ \
diff -urpN linux-2.6/include/asm-i386/pgtable.h
linux-2.6-patched/include/asm-i386/pgtable.h
--- linux-2.6/include/asm-i386/pgtable.h2007-07-03 12:56:49.0
+0200
+++ linux-2.6-patched/include/asm-i386/pgtable.h2007-07-03
12:56:49.0 +0200
@@ -295,17 +295,6 @@ static inline pte_t native_local_ptep_ge
__changed; \
})
-#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_DIRTY
-#define ptep_test_and_clear_dirty(vma, addr, ptep) ({ \
- int __ret = 0; \
- if (pte_dirty(*(ptep))) \
- __ret = test_and_clear_bit(_PAGE_BIT_DIRTY, \
- &(ptep)->pte_low); \
- if (__ret) \
-
[patch 5/5] s390 tlb flush fix.
From: Martin Schwidefsky <[EMAIL PROTECTED]>
The current tlb flushing code for page table entries violates the
s390 architecture in a small detail. The relevant section from the
principles of operation (SA22-7832-02 page 3-47):
"A valid table entry must not be changed while it is attached
to any CPU and may be used for translation by that CPU except to
(1) invalidate the entry by using INVALIDATE PAGE TABLE ENTRY or
INVALIDATE DAT TABLE ENTRY, (2) alter bits 56-63 of a page-table
entry, or (3) make a change by means of a COMPARE AND SWAP AND
PURGE instruction that purges the TLB."
That means if one thread of a multithreaded applciation uses a vma
while another thread does an unmap on it, the page table entries of
that vma needs to get removed with IPTE, IDTE or CSP. In some strange
and rare situations a cpu could check-stop (die) because a entry has
been pushed out of the TLB that is still needed to complete a
(milli-coded) instruction. I've never seen it happen with the current
code on any of the supported machines, so right now this is a
theoretical problem. But I want to fix it nevertheless, to avoid
headaches in the futures.
To get this implemented correctly without changing common code the
primitives ptep_get_and_clear, ptep_get_and_clear_full and
ptep_set_wrprotect need to use the IPTE instruction to invalidate the
pte before the new pte value gets stored. If IPTE is always used for
the three primitives three important operations will have a performace
hit: fork, mprotect and exit_mmap. Time for some workarounds:
* 1: ptep_get_and_clear_full is used in unmap_vmas to remove page
tables entries in a batched tlb gather operation. If the mmu_gather
context passed to unmap_vmas has been started with full_mm_flush==1
or if only one cpu is online or if the mm_struct doesn't has more
than one user the fullmm indication in the mmu_gather context is
set to one. All TLBs for mm_struct are flushed by the tlb_gather_mmu
call. No new TLBs can be created while the unmap is in progress. In
this case ptep_get_and_clear_full clears the ptes with a simple store.
* 2: ptep_get_and_clear is used in change_protection to clear the
ptes from the page tables before they are reentered with the new
access flags. At the end of the update flush_tlb_range clears the
remaining TLBs. In general the ptep_get_and_clear has to issue IPTE
for each pte and flush_tlb_range is a nop. But if there is only one
user of the mm_struct then ptep_get_and_clear uses simple stores
to do the update and flush_tlb_range will flush the TLBs.
* 3: Similar to 2, ptep_set_wrprotect is used in copy_page_range
for a fork to make all ptes of a cow mapping read-only. At the end of
of copy_page_range dup_mmap will flush the TLBs with a call to
flush_tlb_mm. Check for mm->mm_users and if there is only one user
avoid using IPTE in ptep_set_wrprotect and let flush_tlb_mm clear the
TLBs.
Overall for single threaded programs the tlb flush code now performs
better, for multi threaded programs it is slightly worse. In particular
exit_mmap() now does a single IDTE for the mm and then just frees every
page cache reference and every page table page directly without a delay
over the mmu_gather structure.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
arch/s390/kernel/smp.c |2
include/asm-s390/pgalloc.h | 17
include/asm-s390/pgtable.h | 90 +++-
include/asm-s390/tlb.h | 127 ---
include/asm-s390/tlbflush.h | 159 +++-
5 files changed, 245 insertions(+), 150 deletions(-)
diff -urpN linux-2.6/arch/s390/kernel/smp.c
linux-2.6-patched/arch/s390/kernel/smp.c
--- linux-2.6/arch/s390/kernel/smp.c2007-06-01 10:06:01.0 +0200
+++ linux-2.6-patched/arch/s390/kernel/smp.c2007-07-03 12:56:51.0
+0200
@@ -328,7 +328,7 @@ static void smp_ext_bitcall(int cpu, ec_
*/
void smp_ptlb_callback(void *info)
{
- local_flush_tlb();
+ __tlb_flush_local();
}
void smp_ptlb_all(void)
diff -urpN linux-2.6/include/asm-s390/pgalloc.h
linux-2.6-patched/include/asm-s390/pgalloc.h
--- linux-2.6/include/asm-s390/pgalloc.h2007-02-07 15:42:46.0
+0100
+++ linux-2.6-patched/include/asm-s390/pgalloc.h2007-07-03
12:56:51.0 +0200
@@ -84,7 +84,6 @@ static inline void pgd_free(pgd_t *pgd)
*/
#define pmd_alloc_one(mm,address) ({ BUG(); ((pmd_t *)2); })
#define pmd_free(x) do { } while (0)
-#define __pmd_free_tlb(tlb,x) do { } while (0)
#define pgd_populate(mm, pmd, pte) BUG()
#define pgd_populate_kernel(mm, pmd, pte) BUG()
#else /* __s390x__ */
@@ -120,12 +119,6 @@ static inline void pmd_free (pmd_t *pmd)
free_pages((unsigned long) pmd, PMD_ALLOC_ORDER);
}
-#define __pmd_free_tlb(tlb,pmd)\
- do {\
- tlb_flush_mmu(tlb, 0, 0); \
-
Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tue, Jul 03, 2007 at 08:13:53AM +0200, Oliver Neukum wrote: > Only if you want to audit all character devices' read() and write() > methods for races against suspend(). > / on fuse is a bad idea. Any driver that assumes that userspace will be frozen during suspend has been broken forever. That behaviour has never been guaranteed. -- Matthew Garrett | [EMAIL PROTECTED] - 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 1/1] file caps: update selinux xattr hooks
On Mon, 2007-07-02 at 17:06 -0500, Serge E. Hallyn wrote:
> Thanks Stephen, does the following version appear correct? It just
> checks for a different cap for security.capability, then if granted
> goes on to check FILE__GETATTR before granting setxattr or removexattr
> on any security.* xattr.
>
> thanks,
> -serge
>
> >From 5ec50bc22d3320565002658433829f7dc5bc0aa5 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Mon, 2 Jul 2007 14:07:51 -0400
> Subject: [PATCH 1/1] file caps: update selinux xattr hooks (v2)
>
> SELinux does not call out to it's secondary module for setxattr
> or removexattr mediation, as the secondary module would
> incorrectly prevent writing of selinux xattrs. This means
> that when selinux and capability are both loaded, admins will
> be able to write file capabilities with CAP_SYS_ADMIN as before,
> not with CAP_SETFCAP.
>
> Update the selinux hooks to hardcode logic for the special
> consideration for file caps.
>
> Note that the setxattr and removexattr logic for non selinux
> attrs appears to be identical. So I do have another patch
> where selinux_inode_setotherxattr takes an extra argument
> u32 av (in case removexattr ever gets its own av permission)
> so removexattr can shrink and just use that. But first I
> thought I'd see if this version is even close correct :)
Yes, looks sane, and feel free to have both hooks use a common helper
for non-selinux attributes. I don't think you even need to bother with
the u32 av argument; if we later split the check, we can change it then
(it isn't as though these functions need to have a stable interface).
>
> Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
> ---
> security/selinux/hooks.c | 48 -
> 1 files changed, 30 insertions(+), 18 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index af42820..336525c 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2289,6 +2289,25 @@ static int selinux_inode_getattr(struct vfsmount *mnt,
> struct dentry *dentry)
> return dentry_has_perm(current, mnt, dentry, FILE__GETATTR);
> }
>
> +static int selinux_inode_setotherxattr(struct dentry *dentry, char *name)
> +{
> + if (!strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof XATTR_SECURITY_PREFIX - 1)) {
> + if (!strcmp(name, XATTR_NAME_CAPS)) {
> + if (!capable(CAP_SETFCAP))
> + return -EPERM;
> + } else if (!capable(CAP_SYS_ADMIN)) {
> + /* A different attribute in the security namespace.
> +Restrict to administrator. */
> + return -EPERM;
> + }
> + }
> +
> + /* Not an attribute we recognize, so just check the
> +ordinary setattr permission. */
> + return dentry_has_perm(current, NULL, dentry, FILE__SETATTR);
> +}
> +
> static int selinux_inode_setxattr(struct dentry *dentry, char *name, void
> *value, size_t size, int flags)
> {
> struct task_security_struct *tsec = current->security;
> @@ -2299,19 +2318,8 @@ static int selinux_inode_setxattr(struct dentry
> *dentry, char *name, void *value
> u32 newsid;
> int rc = 0;
>
> - if (strcmp(name, XATTR_NAME_SELINUX)) {
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof XATTR_SECURITY_PREFIX - 1) &&
> - !capable(CAP_SYS_ADMIN)) {
> - /* A different attribute in the security namespace.
> -Restrict to administrator. */
> - return -EPERM;
> - }
> -
> - /* Not an attribute we recognize, so just check the
> -ordinary setattr permission. */
> - return dentry_has_perm(current, NULL, dentry, FILE__SETATTR);
> - }
> + if (strcmp(name, XATTR_NAME_SELINUX))
> + return selinux_inode_setotherxattr(dentry, name);
>
> sbsec = inode->i_sb->s_security;
> if (sbsec->behavior == SECURITY_FS_USE_MNTPOINT)
> @@ -2387,11 +2395,15 @@ static int selinux_inode_removexattr (struct dentry
> *dentry, char *name)
> {
> if (strcmp(name, XATTR_NAME_SELINUX)) {
> if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof XATTR_SECURITY_PREFIX - 1) &&
> - !capable(CAP_SYS_ADMIN)) {
> - /* A different attribute in the security namespace.
> -Restrict to administrator. */
> - return -EPERM;
> + sizeof XATTR_SECURITY_PREFIX - 1)) {
> + if (!strcmp(name, XATTR_NAME_CAPS)) {
> + if (!capable(CAP_SETFCAP))
> + return -EPERM;
> + } else if (!capable(CAP_SYS_ADMIN)) {
> + /* A different attribute in
recognizing memory sticks in tifm
Hi Alex, hi all, I have an Acer TM3012 with 0a:09.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD) but only when I plug in an SD card I get a device created, while plugging in a Memory Stick I do not get any reaction of the kernel. This is with kernel 2.6.22-rc6. Is this feature missing or could it be a configuration error (.config if you need it). Inserting a sd card gives: tifm_core: MMC/SD card detected in socket 0:1 mmcblk0: mmc0:bffc SD02G 1985024KiB mmcblk0: p1 >From the "MMC/SD card detected" I assumed that MS should work, too. Thanks for any clarification. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- MAENTWROG (n. Welsh) The height by which the top of a wave exceeds the heigh to which you have rolled up your trousers. --- Douglas Adams, The Meaning of Liff - 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 1/3] ACPI autoloading - ACPICA adjustance
On Tue, 2007-07-03 at 03:58 -0400, Len Brown wrote: > On Sunday 17 June 2007 16:24, Thomas Renninger wrote: > > Define standardized HIDs ... > > > Index: linux-2.6.22-rc4/include/acpi/acpi_drivers.h > > === > > --- linux-2.6.22-rc4.orig/include/acpi/acpi_drivers.h > > +++ linux-2.6.22-rc4/include/acpi/acpi_drivers.h > > @@ -34,16 +34,33 @@ > > #define ACPI_BUS_COMPONENT 0x0001 > > #define ACPI_SYSTEM_COMPONENT 0x0200 > > > > -/* _HID definitions */ > > +/* > > + _HID definitions > > + HIDs starting with 'X' are self defined here and are used for devices > > where > > + a HID does not exist in spec. > > + HIDs must conform to (ACPI spec - 6.1.4): > > > > -#define ACPI_POWER_HID "power_resource" > > + Numeric 32-bit compressed EISA type ID are not supported (never seen one > > as > > + an ACPI HID?) > > + > > + A valid PNP ID must be of the form AAA where A is an uppercase letter > > + and # is a hex digit. > > + A valid ACPI ID must be of the form ACPI where # is a hex digit. > > + > > + and our self-defined: XAAA where A is an uppercase letter and # is a > > hex > > + digit. > > What was the criteria for inventing the XAAA format? > It doesn't comply with the PNP standard format above, since > it starts with four letters instead of three. Yes, it still violates the standard, intend was to not do so. And to stick to the 8/9 bytes. The X has the same meaning as your suggestion below, starting with LNX, it should be visible that it is an out of spec, linux only hid. > > I don't think that "XVID0001" will be more meaningful than "video" > when seen in sysfs... > > > +*/ > > + > > +#define ACPI_POWER_HID "XPWR0001" > > #define ACPI_PROCESSOR_HID "ACPI0007" > > -#define ACPI_SYSTEM_HID"acpi_system" > > -#define ACPI_THERMAL_HID "thermal" > > -#define ACPI_BUTTON_HID_POWERF "button_power" > > -#define ACPI_BUTTON_HID_SLEEPF "button_sleep" > > -#define ACPI_VIDEO_HID "video" > > -#define ACPI_BAY_HID "bay" > > +#define ACPI_SYSTEM_HID"XSYS0001" > > +#define ACPI_THERMAL_HID "XTHM0001" > > +#define ACPI_BUTTON_HID_POWERF "XPBT0001" > > +#define ACPI_BUTTON_HID_SLEEPF "XSBT0001" > > +#define ACPI_VIDEO_HID "XVID0001" > > +#define ACPI_BAY_HID "XBAY0001" > > + > > If the criteria is to stay within an 8 character id length, > I'd rather spell a word with capital letters, and stick > in 0's where we don't need more letters: > > POWER000 > SYSTEM00 > THERMAL0 > PWRBTN00 > SLEEPBTN > VIDEO000 > DRIVEBAY > > Or when we discussed this before, we though about not conflicting > with a standard (or vendor standard) name by becoming the Linux vendor -- > say using the "LNX" prefix, and trying to spell something useful > in the remaining 5 characters. eg. > > LNXPOWER > LNXSYSTM > LNXTHERM > LNXSLPBN > LNXPWRBN > LNXVIDEO > LNXIOBAY Don't know what is better, the first solution looks nicer... Just tell me the final suggestion and I redo the patch. Thomas PS: What is your general impression of the patches, will you add the next series to acpi-test? Shall I wait for some other patch(es) and then rebase, this one touches nearly every file in /drivers/acpi/*.c and could end up in some merge work for me or others. - 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.21.5 june 30th to july 1st date hang?
Hi all,
All my servers and workstations running a 2.6.21.5 kernel hanged exactly
when the date shift from june 30th to july 1st.
On my monitoring system every single station running a 2.6.21.5 kernel
stoped responding exactly after midnight on the date shift from June
30th to July 1st. Although, stations still running 2.6.18 to 2.6.20.11
worked flawlessly.
I first tought there had been an electricity outage but two of my
servers (dell PE 2950 dual-quad core) on UPS in our server room also
hanged:
Jun 30 23:55:01 urpdev1 /USR/SBIN/CRON[31298]: (root) CMD ([ -x
/usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT" ; [
"$ENABLED" = "true" ] && exec /usr/lib/sysstat/sa1; })
Jul 3 11:54:03 urpdev1 syslogd 1.4.1#17: restart.
I could not get anything on any of the 20+ consoles... All the systems
hanged at around the exact same time... When the date shifted from June
30th to July 1st in UTC ...?
Any clue any one?
- vin
-
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] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 06:29, Matthew Garrett wrote: > Suspend to RAM on a machine with / on a fuse filesystem turns out to be > a screaming nightmare - either the suspend fails because syslog (for > instance) can't be frozen, or the machine deadlocks for some other > reason I haven't tracked down. We could "fix" fuse, or alternatively we > could do what we do for suspend to RAM on other platforms (PPC and APM) > and just not use the freezer. > > Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> Could you please rediff against the current -mm tree? There are some patches in there that this will clash with. I still think that this is a mistake, BTW. Please see the Alan's post at https://lists.linux-foundation.org/pipermail/linux-pm/2007-June/012847.html Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 09:19, Benjamin Herrenschmidt wrote: > On Tue, 2007-07-03 at 16:08 +1000, Nigel Cunningham wrote: > > > > > So I think Matthew is totally right. In fact, the presence of the > > > freezer is the main reason why Paulus so far NACKed Johannes attempts at > > > merging the PPC PM code with the generic code in kernel/power.c > > > > > > We've been doing fine without it so far and intend to continue to do so. > > > > Fuse depends on !PPC? > > No, that's not what I'm saying. I'm saying we've been doing STR without > the freezer and that's the way to go imho. > > > > As for suspend-to-disk, I refer you to the discussions we had in the > > > past with Linus, where he explains I think quite clearly how wrong the > > > current implementation of STR is :-) > > > > I assume you mean STD. > > Oops, yeah, sorry. > > > The problem there is that Linus doesn't care about STD. > > If he did, I dare say he'd think through the issues more thoroughly than he > > apparently has. > > Heh, that might be the case :-) > > > > Thing is, if you're going to do snapshots, you should probably not sync > > > after you have "frozen" anyway. > > > > Fully agree. But how do you stop things syncing while you're writing the > > image > > if you don't have a freezer or equivalent? (scheduler based, kexec.. > > they're > > all workarounds for this issue). > > Well, I was saying that in the context of the -current- snapshotting > mechanism which is based on the freezer, then you should not > sys_sync(). > > Some random user or kernel thread doing a sync is not a problem. It will > stop in the middle of sync and resume on wakeup. > > The problem is currently because STD -itself- attempts to sync after it > has frozen things. To be precise, it tries to sync after it has frozen the user land. > I think that should be changed. If you want to sync for whatever reason, > (mostly save RAM ?) do it before the freeze. That means you may get new > dirty data in memory that isn't written out by the sync before you > freeze, but that's allright, that data will be in the suspend image > anyway. If you fail to wakeup, that's akin to a normal crash, the user > will only lose the last data written at the time of the suspend and > journaling fs'es should take care of fs metadata integrity. > > So to summarize, the plan that makes things work with fuse is: > > - For STR, don't do the freezer thing. In the long run, I agree. Still, can you please read this post from Alan Stern: https://lists.linux-foundation.org/pipermail/linux-pm/2007-June/012847.html ? I don't think I'm able to repeat the arguments given in there in a convincing way. > - For STD, don't sys_sync() after you froze Yeah, I think we can move the syncing before the freezing, so to speak. And it need not be called from within the freezer, BTW. > There might be -other- issues, but that should get you through some of > them at least. Of course, you'll be in trouble if you try to do things > like STD-to-a-file which sits on a fuse FS but there's a limit to > insanity :-) Yes. :-) Ggreetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 13:07, Oliver Neukum wrote: > Am Dienstag, 3. Juli 2007 schrieb Miklos Szeredi: > > > > So to summarize, the plan that makes things work with fuse is: > > > > > > > > - For STR, don't do the freezer thing. > > > > > > > > - For STD, don't sys_sync() after you froze > > > > > > > > There might be -other- issues, but that should get you through some of > > > > > > At the risk of repeating myself. Character device drivers are written > > > with the assumption that normal io and suspend/resume do not race > > > with each other due to the freezer. > > > What do you intend to do about that? > > > > Oliver, can you please explain your worries in a bit more detail? > > > > I don't claim to know anything about how STR or hibernate works, but > > neither seem to have any problem with I/O on the fuse device "racing" > > with them. > > The problem is not with fuse. The problem is generic in nature. > > If you remove the freezer, user space remains active until the last CPU > goes into suspend. It can do syscalls. Or do you know a clean way to exempt > only the tasks fuse might use? > > Now device drivers have a guaranteed temporal sequence: > > last io -> suspend() -> resume() [or disconnect()] -> new io > > This is because suspend() is called after the freezer goes into action. If > you remove the freezer, you need to deal with > > 1. io to suspended devices > 2. resume() assuming that the device is in the state suspend() left it > 3. io changing a device's state while suspend is saving it > > and you need to fix this for all device drivers, not just those fuse is > involved with. Removing the freezer means doing a more or less full > audit of every driver and additional locking in many drivers. Agreed. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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: shouldn't LVM support be selected by default?
Robert P. J. Day <[EMAIL PROTECTED]> wrote: > just built a new kernel and didn't notice that support for LVM > wasn't selected by default for x86. given what i thought was fairly > widespread use of LVM2, wouldn't it make sense to have this option as > part of the default config? If you don't know about LVM, you don't need it. Do you? -- It's redundant! It's redundant! Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - 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.21.5 june 30th to july 1st date hang?
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] De la part de
> Fortier,Vincent [Montreal]
> Envoyé : 3 juillet 2007 08:44
>
> Hi all,
>
> All my servers and workstations running a 2.6.21.5 kernel
> hanged exactly when the date shift from june 30th to july 1st.
>
> On my monitoring system every single station running a
> 2.6.21.5 kernel stoped responding exactly after midnight on
> the date shift from June 30th to July 1st. Although,
> stations still running 2.6.18 to 2.6.20.11 worked flawlessly.
>
> I first tought there had been an electricity outage but two
> of my servers (dell PE 2950 dual-quad core) on UPS in our
> server room also
> hanged:
> Jun 30 23:55:01 urpdev1 /USR/SBIN/CRON[31298]: (root) CMD ([ -x
> /usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT"
> ; [ "$ENABLED" = "true" ] && exec /usr/lib/sysstat/sa1; })
> Jul 3 11:54:03 urpdev1 syslogd 1.4.1#17: restart.
>
> I could not get anything on any of the 20+ consoles... All
> the systems hanged at around the exact same time... When the
> date shifted from June 30th to July 1st in UTC ...?
>
> Any clue any one?
Forgot to mention:
- All stations that failed where running a 2.6.21 kernel + CFS v18 (I don't
have any stations running a plain 2.6.21 kernel so can't tell)
- Config file can be found at:
http://linux-dev.qc.ec.gc.ca/kernel/debian/CONFIG-i686-2.6.21-005
- kernels can be found at:
http://linux-dev.qc.ec.gc.ca/kernel/debian/sarge/i686/2.6.21/
>
> - vin
>
-
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: platform_driver_register() ??
Hi Midhun, I think mmc driver is layered modules, only top block driver registers driver under "mmc_bus_type" bus, see drivers/mmc/mmc_sysfs.c and mmc_block.c. I think they are creating a tree of devices of same characteristics under that bus. I think your driver is linux/drivers/mmc/imxmmc.c where it registers a driver for device of type "platform_bus_type". This module will come under above mentioned block driver. Corresponding platform device is registered in linux/arch/arm/mach-imx/generic.c see platform_device imx_mmc_device. Nobin Mathew On 7/3/07, Midhun Agnihotram <[EMAIL PROTECTED]> wrote: Hi All, I have an MMC driver for my kit (i.MX21 based cogent board CSB535FS), which is supplied by Cogent (Kernel version 2.6.16). The original driver (linux/drivers/mmc/mmc_block.c) uses mmc_register_driver() method to register the driver but the one supplied by Cogent uses platform_driver_register() method. What is the difference between the two? Thanks, Midhun. - 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/ - 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: Add INPUT support to toshiba_acpi
Rolf Eike Beer wrote: Renato S. Yamane wrote: Rolf Eike Beer wrote: Richard Hughes wrote: Yes, although this is out of my area or expertise, sorry. I've looked a bit but can't find any driver interaction of those programs. Any further ideas welcome. Do you try omnibook driver? svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try this module above and now I can change brightness writing in /proc/omnibook/lcd and kpowersave can change brightness too. Oh wow! Even my Multimedia keys get recognized. Thanks very much for your pointer. I think that is a good idea more support to Toshiba Laptops, so omnibook+toshiba_acpi is a perfect couple, because some functions works with toshiba_acpi and others works with omnibook. Jaime (in cc too) do a very useful module that work in some laptop models that not work on toshiba_acpi and omnibook driver. So, I think that is a very good idea all work together to do a more powerful (and compatible) module in next kernel releases. Regards, Renato S. Yamane - 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 13:46, Oliver Neukum wrote: > Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > On Tue, 2007-07-03 at 09:44 +0200, Oliver Neukum wrote: > > > Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > > > So to summarize, the plan that makes things work with fuse is: > > > > > > > > - For STR, don't do the freezer thing. > > > > > > > > - For STD, don't sys_sync() after you froze > > > > > > > > There might be -other- issues, but that should get you through some of > > > > > > At the risk of repeating myself. Character device drivers are written > > > with the assumption that normal io and suspend/resume do not race > > > with each other due to the freezer. > > > What do you intend to do about that? > > > > Ugh ... "character devices" ... that's a pretty wide statement... > > there's lots of those and very different one from the other... > > That is a good summary of the problem ;-( > > > Any sane device-driver will have to cope with being suspended in a > > "live" system. I've demonstrated multiple times in the past why this is > > necessary anyway, for things like dynamic power management, among > > others. > > That is an interesting notion. I'd rather see device drivers reporting > their devices idle and requsting to be suspended. > But in any case it doesn't solve the problem. Agreed. What I think will solve the problem in the long run is to: 1) Separate the hibernation code from the suspend code (ie. hibernation-related callbacks should generally be different from suspend-related callback for each driver). 2) Remove the freezing of kernel threads from each of them (in the hibernation case, if possible) an fix the things that get broken. 3) Remove the freezing of user space from the suspend code path and fix the things that get broken. Going to step 3) before doing 1) and 2) doesn't seem to be the right thing to me. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 07:49, Benjamin Herrenschmidt wrote: > On Tue, 2007-07-03 at 05:29 +0100, Matthew Garrett wrote: > > Suspend to RAM on a machine with / on a fuse filesystem turns out to be > > a screaming nightmare - either the suspend fails because syslog (for > > instance) can't be frozen, or the machine deadlocks for some other > > reason I haven't tracked down. We could "fix" fuse, or alternatively we > > could do what we do for suspend to RAM on other platforms (PPC and APM) > > and just not use the freezer. > > > > Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> > > Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > > (And with much pleasure :-) Clashes with some code already in -mm. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 07:51, Benjamin Herrenschmidt wrote: > On Tue, 2007-07-03 at 05:29 +0100, Matthew Garrett wrote: > > Suspend to RAM on a machine with / on a fuse filesystem turns out to be > > a screaming nightmare - either the suspend fails because syslog (for > > instance) can't be frozen, or the machine deadlocks for some other > > reason I haven't tracked down. We could "fix" fuse, or alternatively we > > could do what we do for suspend to RAM on other platforms (PPC and APM) > > and just not use the freezer. > > The main reason for deadlocks is because we do a sys_sync() after the > freeze, which we shouldn't do. So why don't we remove the sys_sync() from freeze_processes() instead? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 14:13, Matthew Garrett wrote: > On Tue, Jul 03, 2007 at 08:13:53AM +0200, Oliver Neukum wrote: > > > Only if you want to audit all character devices' read() and write() > > methods for races against suspend(). > > / on fuse is a bad idea. > > Any driver that assumes that userspace will be frozen during suspend has > been broken forever. That behaviour has never been guaranteed. Can we please fix those drivers _first_, then? Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 09:37, Romano Giannetti wrote: > On Tue, 2007-07-03 at 05:29 +0100, Matthew Garrett wrote: > > or alternatively we could do what we do for suspend to RAM on other > > platforms (PPC and APM) and just not use the freezer. > > As a data point, I am running with this patch on top of 2.6.21.2 the > last 3+ weeks, with an average of 5/6 STR cycles a day, and had no > problems at all. (Sony vaio pcg-fx701). Just normal work, I didn't try > to stress the thing, but I have quite a few times suspended/resumed over > a big compile without a glitch. > > What are the risks of this patch supposed to be? See https://lists.linux-foundation.org/pipermail/linux-pm/2007-June/012847.html Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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.21.5 june 30th to july 1st date hang?
Hi, Vincent!
Fortier,Vincent [Montreal] schrieb:
Hi all,
All my servers and workstations running a 2.6.21.5 kernel hanged exactly
when the date shift from june 30th to july 1st.
On my monitoring system every single station running a 2.6.21.5 kernel
stoped responding exactly after midnight on the date shift from June
30th to July 1st. Although, stations still running 2.6.18 to 2.6.20.11
worked flawlessly.
I first tought there had been an electricity outage but two of my
servers (dell PE 2950 dual-quad core) on UPS in our server room also
hanged:
Jun 30 23:55:01 urpdev1 /USR/SBIN/CRON[31298]: (root) CMD ([ -x
/usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT" ; [
"$ENABLED" = "true" ] && exec /usr/lib/sysstat/sa1; })
Jul 3 11:54:03 urpdev1 syslogd 1.4.1#17: restart.
I could not get anything on any of the 20+ consoles... All the systems
hanged at around the exact same time... When the date shifted from June
30th to July 1st in UTC ...?
Any clue any one?
No problems over here with plain 2.6.21.5 on x686
You could just reset the date back on one of these machines and
check the transition again... and see if it was really the kernel
who crashed and check your cron configuration.
Regards,
--
Clemens Koller
__
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.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: [PATCH] LinuxPPS (with new syscalls API) - new version
On Tue, 2007-07-03 at 11:48 +0200, Rodolfo Giometti wrote: > On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote: > > > > Seems reasonable enough in principle -- but whatever you do, don't use > > "long" for it. That would definitely need different behaviour for 32-bit > > vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t. > > Here the patch to convert LinuxPPS data structs into fixed ones. > > Please, take a look at it and report possible modifications. Looks relatively sane at first glance; busy this week so haven't looked very hard yet. Two thing though... you're mixing proper C types (uint32_t) and the Linux-specific legacy crap types (__u32). Pick one. I won't recommend _which_ one, because if I do I'll make Andrew unhappy. But pick one; don't use both at the same time. Also read Documentation/volatile-considered-harmful.txt and ponder deeply your use of 'volatile' on certain members of struct pps_s. -- dwmw2 - 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: how do versioning filesystems take snapshot of opened files?
On Tue, 3 Jul 2007 01:28:57 -0400 "Xin Zhao" <[EMAIL PROTECTED]> wrote: > Hi, > > > If a file is already opened when snapshot command is issued, the file > itself could be in an inconsistent state already. Before the file is > closed, maybe part of the file contains old data, the rest contains > new data. > How does a versioning filesystem guarantee that the file snapshot is > in a consistent state in this case? > > I googled it but didn't find any answer. Can someone explain it a > little bit? It's the same answer as in most filesystem related questions...it depends ;) Consistent state means many different things. It may mean that the metadata accurately reflects the space on disk allocated to the file and that all data for the file is properly on disk (ie from an fsync). But, even this is less than useful because very few files on the filesystem stand alone. Applications spread their state across a number of files and so consistent means something different to every application. Getting a snapshot that is useful with respect to application data requires help from the application. The app needs to be shutdown or paused prior to the snapshot and then started up again after the snapshot is taken. -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: [PATCH -mm] PM: Prevent frozen user mode helpers from failing the freezing of tasks (rev. 2)
On Tuesday, 3 July 2007 07:30, Benjamin Herrenschmidt wrote: > On Tue, 2007-06-26 at 00:27 +0200, Rafael J. Wysocki wrote: > > > > case PM_HIBERNATION_PREPARE: > > > > case PM_SUSPEND_PREPARE: > > > > usermodehelper_disabled = 1; > > > > - return NOTIFY_OK; > > > > + smp_mb(); > > > > > > usermodehelper_disabled should be atomic variable, too, so we don't > > > have to play these ugly tricks by hand? This should not be > > > performance-critical, right? > > > > Well, I think we'd need to add the barriers anyway. > > > > The problem, as far as I understand it, is that the instructions can > > get > > reordered if there are no barriers in there. > > That seems dodgy either way to me :-) > > Just use a spinlock. Around wait_for_completion()? I don't think that's a good idea. :-) Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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: vm/fs meetup in september?
On Mon, 2 July 2007 17:46:40 -0700, Jared Hulbert wrote: > > Right, the solution to swap problem is identical to the rw XIP > filesystem problem.Jörn, that's why you're the self-appointed > subject matter expert! All right. I'll try to make an important face whenever the subject comes up. Nick, do you have a problem if LogFS occupies two brainslots at the meeting? Jörn -- Eighty percent of success is showing up. -- Woody Allen - 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: shouldn't LVM support be selected by default?
On Tue, 3 Jul 2007, Bodo Eggert wrote: > Robert P. J. Day <[EMAIL PROTECTED]> wrote: > > > just built a new kernel and didn't notice that support for LVM > > wasn't selected by default for x86. given what i thought was fairly > > widespread use of LVM2, wouldn't it make sense to have this option as > > part of the default config? > > If you don't know about LVM, you don't need it. Do you? well, ok, i can go with that. thanks. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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] LinuxPPS (with new syscalls API) - new version
On Tue, Jul 03, 2007 at 09:09:50AM -0400, David Woodhouse wrote: > On Tue, 2007-07-03 at 11:48 +0200, Rodolfo Giometti wrote: > > On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote: > > > > > > Seems reasonable enough in principle -- but whatever you do, don't use > > > "long" for it. That would definitely need different behaviour for 32-bit > > > vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t. > > > > Here the patch to convert LinuxPPS data structs into fixed ones. > > > > Please, take a look at it and report possible modifications. > > Looks relatively sane at first glance; busy this week so haven't looked > very hard yet. Two thing though... you're mixing proper C types > (uint32_t) and the Linux-specific legacy crap types (__u32). Pick one. I > won't recommend _which_ one, because if I do I'll make Andrew unhappy. > But pick one; don't use both at the same time. > > Also read Documentation/volatile-considered-harmful.txt and ponder > deeply your use of 'volatile' on certain members of struct pps_s. I will! Thanks a lot. Rodolfo -- GNU/Linux Solutions e-mail:[EMAIL PROTECTED] Linux Device Driver [EMAIL PROTECTED] Embedded Systems[EMAIL PROTECTED] UNIX programming phone: +39 349 2432127 - 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: Suspend2 is getting a new name.
Hi, On Tuesday, 3 July 2007 00:08, Nigel Cunningham wrote: > Hi. > > On Tuesday 03 July 2007 05:18:39 Bill Davidsen wrote: > > Nigel Cunningham wrote: > > > Hi all. > > > > > > Suspend2's name is changing to "TuxOnIce". > > > > > > This is for a couple of reasons: > > > > > > In recent discussions on LKML, the point was made that the word "Suspend" > is > > > confusing. It is used to refer to both suspending to disk and suspending > to > > > ram. Life will be simpler if we more clearly differentiate the two. > > > > > > The name Suspend2 came about a couple of years ago when we made the 2.0 > > > release and started self-hosting. If we ever get to a 3.0 release, the > name > > > could become even more confusing! (And there are already problems with > people > > > confusing the name with swsusp and talking about uswsusp as version 3!). > > > > > > http://www.suspend2.net is still working at the moment, but we'll shift > > > to > > > http://www.tuxonice.net over the next while. The wiki and bugzilla are > > > already done; email will remain on suspend2.net for a little while and > > > git > > > trees will be renamed at the time of the next stable release. > > > > > I guess this is "good news, bad news" time. The good news is that the > > "suspend with working resume" project is still active, the bad news is > > that making provisions for long term out of mainline operation sounds as > > if you have no hope of getting this code into the mainline kernel. :-( > > Let's not turn this into a flamewar, please. This is just a name change, > nothing more. > > As far as I know, the desire on Rafael's part and mine is still to get at > least some of the functionality merged. The only reason this isn't happening > yet is that we're both busy with other aspects of the work. Rafael is > focussing on infrastructure issues, I'm focussing on minimising the diff and > finishing off cleaning up and adding comments to functions. That's correct, thanks for saying this! My first target is to introduce a framework allowing drivers to have different callbacks for hibernation and suspend. Unfortunately, that turned out to require quite a lot of work - and time - to do. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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 -mm] PM: Prevent frozen user mode helpers from failing the freezing of tasks (rev. 2)
On Tuesday, 3 July 2007 15:19, Rafael J. Wysocki wrote: > On Tuesday, 3 July 2007 07:30, Benjamin Herrenschmidt wrote: > > On Tue, 2007-06-26 at 00:27 +0200, Rafael J. Wysocki wrote: > > > > > case PM_HIBERNATION_PREPARE: > > > > > case PM_SUSPEND_PREPARE: > > > > > usermodehelper_disabled = 1; > > > > > - return NOTIFY_OK; > > > > > + smp_mb(); > > > > > > > > usermodehelper_disabled should be atomic variable, too, so we don't > > > > have to play these ugly tricks by hand? This should not be > > > > performance-critical, right? > > > > > > Well, I think we'd need to add the barriers anyway. > > > > > > The problem, as far as I understand it, is that the instructions can > > > get > > > reordered if there are no barriers in there. > > > > That seems dodgy either way to me :-) > > > > Just use a spinlock. > > Around wait_for_completion()? I don't think that's a good idea. :-) Sorry, I mistunderstood you (I think). Yes, I could use a spinlock for protecting usermodehelper_disabled, but why would that be better than the current code? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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 1/1] file caps: update selinux xattr hooks
Quoting Stephen Smalley ([EMAIL PROTECTED]):
> On Mon, 2007-07-02 at 17:06 -0500, Serge E. Hallyn wrote:
> > Thanks Stephen, does the following version appear correct? It just
> > checks for a different cap for security.capability, then if granted
> > goes on to check FILE__GETATTR before granting setxattr or removexattr
> > on any security.* xattr.
> >
> > thanks,
> > -serge
> >
> > >From 5ec50bc22d3320565002658433829f7dc5bc0aa5 Mon Sep 17 00:00:00 2001
> > From: Serge E. Hallyn <[EMAIL PROTECTED]>
> > Date: Mon, 2 Jul 2007 14:07:51 -0400
> > Subject: [PATCH 1/1] file caps: update selinux xattr hooks (v2)
> >
> > SELinux does not call out to it's secondary module for setxattr
> > or removexattr mediation, as the secondary module would
> > incorrectly prevent writing of selinux xattrs. This means
> > that when selinux and capability are both loaded, admins will
> > be able to write file capabilities with CAP_SYS_ADMIN as before,
> > not with CAP_SETFCAP.
> >
> > Update the selinux hooks to hardcode logic for the special
> > consideration for file caps.
> >
> > Note that the setxattr and removexattr logic for non selinux
> > attrs appears to be identical. So I do have another patch
> > where selinux_inode_setotherxattr takes an extra argument
> > u32 av (in case removexattr ever gets its own av permission)
> > so removexattr can shrink and just use that. But first I
> > thought I'd see if this version is even close correct :)
>
> Yes, looks sane, and feel free to have both hooks use a common helper
> for non-selinux attributes. I don't think you even need to bother with
> the u32 av argument; if we later split the check, we can change it then
> (it isn't as though these functions need to have a stable interface).
Great, here is the new patch then.
thanks,
-serge
>From 3aaf0621dd6903ef7b73cc17df4d72140ad1e922 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Date: Mon, 2 Jul 2007 14:14:40 -0400
Subject: [PATCH 1/1] file caps: update selinux xattr hooks (v4)
SELinux does not call out to its secondary module for setxattr
or removexattr mediation, as the secondary module would
incorrectly prevent writing of selinux xattrs. This means
that when selinux and capability are both loaded, admins will
be able to write file capabilities with CAP_SYS_ADMIN as before,
not with CAP_SETFCAP.
Update the selinux hooks to hardcode logic for the special
consideration for file caps. Also consolidate the handling
of non-selinux xattrs in removexattr and setxattr.
Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
---
security/selinux/hooks.c | 50 +
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index af42820..54e8a47 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2289,6 +2289,25 @@ static int selinux_inode_getattr(struct vfsmount *mnt,
struct dentry *dentry)
return dentry_has_perm(current, mnt, dentry, FILE__GETATTR);
}
+static int selinux_inode_setotherxattr(struct dentry *dentry, char *name)
+{
+ if (!strncmp(name, XATTR_SECURITY_PREFIX,
+sizeof XATTR_SECURITY_PREFIX - 1)) {
+ if (!strcmp(name, XATTR_NAME_CAPS)) {
+ if (!capable(CAP_SETFCAP))
+ return -EPERM;
+ } else if (!capable(CAP_SYS_ADMIN)) {
+ /* A different attribute in the security namespace.
+ Restrict to administrator. */
+ return -EPERM;
+ }
+ }
+
+ /* Not an attribute we recognize, so just check the
+ ordinary setattr permission. */
+ return dentry_has_perm(current, NULL, dentry, FILE__SETATTR);
+}
+
static int selinux_inode_setxattr(struct dentry *dentry, char *name, void
*value, size_t size, int flags)
{
struct task_security_struct *tsec = current->security;
@@ -2299,19 +2318,8 @@ static int selinux_inode_setxattr(struct dentry *dentry,
char *name, void *value
u32 newsid;
int rc = 0;
- if (strcmp(name, XATTR_NAME_SELINUX)) {
- if (!strncmp(name, XATTR_SECURITY_PREFIX,
-sizeof XATTR_SECURITY_PREFIX - 1) &&
- !capable(CAP_SYS_ADMIN)) {
- /* A different attribute in the security namespace.
- Restrict to administrator. */
- return -EPERM;
- }
-
- /* Not an attribute we recognize, so just check the
- ordinary setattr permission. */
- return dentry_has_perm(current, NULL, dentry, FILE__SETATTR);
- }
+ if (strcmp(name, XATTR_NAME_SELINUX))
+ return selinux_inode_setotherxattr(dentry, name);
sbsec = inode->i_sb->s_security;
if (sbsec->behavior == SECURITY_FS_USE_MNTPOINT)
@@ -2385,20 +2393,8 @@ static int
Re: [AppArmor 32/44] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames
On Thu, 2007-06-28 at 20:15 +0200, Andreas Gruenbacher wrote: > On Thursday 28 June 2007 18:12, James Morris wrote: > > Are you trying to cater for the case where you're holding an open fd for a > > file which has been deleted, and thus has no pathname? > > Yes, see the AA_CHECK_FD flag in security/apparmor/main.c:aa_perm_dentry(). > We > want to distinguish between the following two cases: > > - process performs an operation on an open file descriptor, > > - process performs an operation on a pathname, and between the dentry >lookup and the LSM permission check, the file gets deleted. > > In the former case, we obviously want to continue giving the process access > to > his fd (the classical pattern: open temporary file; delete it so that it will > self-recycle, continue using the open file descriptor). > > In the latter case, The file still existed at the time of the lookup but not > anymore at the time of the permission check. The file obviously doesn't have > a filename anymore, so we cannot check permissions. If we granted access in > that case, processes could bypass their profile permissions in that race > window. We close the race by returning -ENOENT in that case, the same result > as if the file had already been deleted before the lookup. So you don't actually need/use the struct file pointer; you just need a flag indicating whether or not access was by open file descriptor or by pathname? And what does this mean for a process that has "changed hats"? Which might not be authorized to access the file anymore, even via an already opened descriptor. -- Stephen Smalley National Security Agency - 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: recognizing memory sticks in tifm
Not really. Current svn has read-only support for legacy MS (not mspro yet). I'm still working on it. The major difference: mmc/sd has an open spec, sony ms has none. --- Norbert Preining <[EMAIL PROTECTED]> wrote: > Hi Alex, hi all, > > I have an Acer TM3012 with > 0a:09.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card > Reader (SD/MMC/MS/MS > PRO/xD) > > but only when I plug in an SD card I get a device created, while > plugging in a Memory Stick I do not get any reaction of the kernel. > > This is with kernel 2.6.22-rc6. > > Is this feature missing or could it be a configuration error (.config if > you need it). > > Inserting a sd card gives: > tifm_core: MMC/SD card detected in socket 0:1 > mmcblk0: mmc0:bffc SD02G 1985024KiB > mmcblk0: p1 > > From the "MMC/SD card detected" I assumed that MS should work, too. > > Thanks for any clarification. > > Best wishes > > Norbert > > --- > Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of > Technology > Debian Developer <[EMAIL PROTECTED]> Debian TeX Group > gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 > B094 > --- > MAENTWROG (n. Welsh) > The height by which the top of a wave exceeds the heigh to which you > have rolled up your trousers. > --- Douglas Adams, The Meaning of Liff > Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ - 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.21.5 june 30th to july 1st date hang?
On Tuesday, 3. July 2007, Fortier,Vincent [Montreal] wrote: > Hi all, > > All my servers and workstations running a 2.6.21.5 kernel hanged exactly > when the date shift from june 30th to july 1st. > Same thing here on two machines with plain vanilla 2.6.21.(3/4), on debian testing & debian unstable. regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - 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.21.5 june 30th to july 1st date hang?
On Tue, Jul 03, 2007 at 08:44:00AM -0400, Fortier,Vincent [Montreal] wrote:
> Hi all,
>
> All my servers and workstations running a 2.6.21.5 kernel hanged exactly
> when the date shift from june 30th to july 1st.
>
> On my monitoring system every single station running a 2.6.21.5 kernel
> stoped responding exactly after midnight on the date shift from June
> 30th to July 1st. Although, stations still running 2.6.18 to 2.6.20.11
> worked flawlessly.
>
> I first tought there had been an electricity outage but two of my
> servers (dell PE 2950 dual-quad core) on UPS in our server room also
> hanged:
> Jun 30 23:55:01 urpdev1 /USR/SBIN/CRON[31298]: (root) CMD ([ -x
> /usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT" ; [
> "$ENABLED" = "true" ] && exec /usr/lib/sysstat/sa1; })
> Jul 3 11:54:03 urpdev1 syslogd 1.4.1#17: restart.
>
> I could not get anything on any of the 20+ consoles... All the systems
> hanged at around the exact same time... When the date shifted from June
> 30th to July 1st in UTC ...?
>
> Any clue any one?
>
> - vin
> -
> 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/
>
there was one 'special' event at that date:
syslog.2.gz:Jul 1 01:59:59 master kernel: Clock: inserting leap second
23:59:60 UTC
-
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.22-rc6-mm1 bad_page events.
X86 32bit with lots of debug turned on I get this: Freeing unused kernel memory: 156k freed Write protecting the kernel text: 1668k Write protecting the kernel read-only data: 719k Bad page state in process 'swapper' page:c1c0 flags:0x0400 mapping: mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: [] bad_page+0x6c/0x100 [] free_hot_cold_page+0x5d/0x140 [] global_flush_tlb+0x112/0x130 [] init_post+0xd/0xe0 [] kernel_init+0x216/0x220 [] schedule_tail+0x0/0xe0 [] kernel_init+0x0/0x220 [] kernel_init+0x0/0x220 [] kernel_thread_helper+0x7/0x10 === Hexdump: 000: 00 06 00 00 01 00 00 00 ff ff ff ff 0f 00 00 00 010: 00 00 00 00 00 00 00 00 78 00 00 c1 b8 00 00 c1 020: 00 06 00 00 01 00 00 00 ff ff ff ff a7 03 00 00 030: 00 00 00 00 00 00 00 00 98 00 00 c1 d8 00 00 c1 040: 00 04 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 050: 00 00 00 00 00 00 00 00 b8 00 00 c1 f8 00 00 c1 060: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00 070: 00 00 00 00 00 00 00 00 d8 00 00 c1 18 01 00 c1 080: 00 06 00 00 01 00 00 00 ff ff ff ff 9c 03 00 00 090: 00 00 00 00 00 00 00 00 f8 00 00 c1 38 01 00 c1 0a0: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00 0b0: 00 00 00 00 00 00 00 00 18 01 00 c1 58 01 00 c1 - 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]: Check the right register for the DMA enabled flags
Mirrors change in IT821X
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.22-rc6-mm1/drivers/ata/ata_generic.c
linux-2.6.22-rc6-mm1/drivers/ata/ata_generic.c
--- linux.vanilla-2.6.22-rc6-mm1/drivers/ata/ata_generic.c 2007-07-02
20:50:11.0 +0100
+++ linux-2.6.22-rc6-mm1/drivers/ata/ata_generic.c 2007-07-02
21:02:10.0 +0100
@@ -50,7 +50,7 @@
/* Bits 5 and 6 indicate if DMA is active on master/slave */
if (ap->ioaddr.bmdma_addr)
- dma_enabled = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
+ dma_enabled = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_STATUS);
for (i = 0; i < ATA_MAX_DEVICES; i++) {
struct ata_device *dev = &ap->device[i];
-
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 2.6.22-rc6] sata_mv: PCI-ID for Adaptec 1430SA SATA Controller
Florian Attenberger wrote:
Signed-off-by: Florian Attenberger <[EMAIL PROTECTED]>
--- 2.6.22-rc6/drivers/ata/sata_mv.c2007-06-30 16:21:47.462020256 +0200
+++ 2.6.22-rc6.mine/drivers/ata/sata_mv.c 2007-06-30 16:25:25.999165444
+0200
@@ -582,6 +582,9 @@ static const struct pci_device_id mv_pci
{ PCI_VDEVICE(ADAPTEC2, 0x0241), chip_604x },
+ /* Adaptec 1430SA */
+ { PCI_VDEVICE(ADAPTEC2, 0x0243), chip_7042 },
+
applied
-
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] pata_pcmcia: Switch to ata_sff_port_start
PCMCIA doesn't use DMA and as this driver is used on many platforms we don't want it to fail on those that define the DMA alloc API as a NULL return Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --exclude-from /usr/src/exclude --recursive linux.vanilla-2.6.22-rc6-mm1/drivers/ata/pata_pcmcia.c linux-2.6.22-rc6-mm1/drivers/ata/pata_pcmcia.c --- linux.vanilla-2.6.22-rc6-mm1/drivers/ata/pata_pcmcia.c 2007-07-02 20:48:49.0 +0100 +++ linux-2.6.22-rc6-mm1/drivers/ata/pata_pcmcia.c 2007-07-02 21:04:38.0 +0100 @@ -129,7 +129,7 @@ .irq_on = ata_irq_on, .irq_ack= ata_irq_ack, - .port_start = ata_port_start, + .port_start = ata_sff_port_start, }; #define CS_CHECK(fn, ret) \ - 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] pata_pdc202xx_old: Correct cable detect logic
We got it backwards and now the other detects are fixed it shows up Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --exclude-from /usr/src/exclude --recursive linux.vanilla-2.6.22-rc6-mm1/drivers/ata/pata_pdc202xx_old.c linux-2.6.22-rc6-mm1/drivers/ata/pata_pdc202xx_old.c --- linux.vanilla-2.6.22-rc6-mm1/drivers/ata/pata_pdc202xx_old.c 2007-07-02 20:50:11.0 +0100 +++ linux-2.6.22-rc6-mm1/drivers/ata/pata_pdc202xx_old.c2007-07-02 21:04:38.0 +0100 @@ -31,8 +31,8 @@ pci_read_config_word(pdev, 0x50, &cis); if (cis & (1 << (10 + ap->port_no))) - return ATA_CBL_PATA80; - return ATA_CBL_PATA40; + return ATA_CBL_PATA40; + return ATA_CBL_PATA80; } /** - 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]: Check the right register for the DMA enabled flags
Alan Cox wrote: Mirrors change in IT821X Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --exclude-from /usr/src/exclude --recursive linux.vanilla-2.6.22-rc6-mm1/drivers/ata/ata_generic.c linux-2.6.22-rc6-mm1/drivers/ata/ata_generic.c --- linux.vanilla-2.6.22-rc6-mm1/drivers/ata/ata_generic.c 2007-07-02 20:50:11.0 +0100 +++ linux-2.6.22-rc6-mm1/drivers/ata/ata_generic.c 2007-07-02 21:02:10.0 +0100 @@ -50,7 +50,7 @@ /* Bits 5 and 6 indicate if DMA is active on master/slave */ if (ap->ioaddr.bmdma_addr) - dma_enabled = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD); + dma_enabled = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_STATUS); applied Please put driver or subsystem name in subject, to disambiguate. Email subject goes straight into kernel changelog verbatim, and is in essence a global namespace. - 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] amiserial: Remove incorrect 'no termios change' check
Lots of serial drivers check and optimise for setting the termios values
to the ones they were before. This is pointless and the check is wrong
anyway. Remove the checks on the serial drivers. If we ever do need such
a check put it back in the tty layer instead _once_!
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.22-rc6-mm1/drivers/char/amiserial.c
linux-2.6.22-rc6-mm1/drivers/char/amiserial.c
--- linux.vanilla-2.6.22-rc6-mm1/drivers/char/amiserial.c 2007-07-02
20:48:49.0 +0100
+++ linux-2.6.22-rc6-mm1/drivers/char/amiserial.c 2007-07-02
21:05:53.0 +0100
@@ -738,6 +738,7 @@
}
/* If the quotient is zero refuse the change */
if (!quot && old_termios) {
+ /* FIXME: Will need updating for new tty in the end */
info->tty->termios->c_cflag &= ~CBAUD;
info->tty->termios->c_cflag |= (old_termios->c_cflag & CBAUD);
baud = tty_get_baud_rate(info->tty);
@@ -783,7 +784,6 @@
/*
* Set up parity check flag
*/
-#define RELEVANT_IFLAG(iflag) (iflag & (IGNBRK|BRKINT|IGNPAR|PARMRK|INPCK))
info->read_status_mask = UART_LSR_OE | UART_LSR_DR;
if (I_INPCK(info->tty))
@@ -1367,11 +1367,6 @@
unsigned long flags;
unsigned int cflag = tty->termios->c_cflag;
- if ( (cflag == old_termios->c_cflag)
- && ( RELEVANT_IFLAG(tty->termios->c_iflag)
- == RELEVANT_IFLAG(old_termios->c_iflag)))
- return;
-
change_speed(info, old_termios);
/* Handle transition to B0 status */
-
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/
