Re: evading ulimits
[EMAIL PROTECTED] wrote:
> On Sat, 23 Dec 2006 19:42:10 EST, John Richard Moser said:
>>
>> Jan Engelhardt wrote:
I've set up some stuff on my box where /etc/security/limits.conf
contains the following:
@users softnproc 3072
@users hardnproc 4096
I'm in group users, and a simple fork bomb is easily quashed by this:
[EMAIL PROTECTED]:~$ :(){ :|:; };:
bash: fork: Resource temporarily unavailable
Terminated
Oddly enough, trying this again and again yields the same results; but,
I can kill the box (eventually; about 1 minute in I managed to `/exec
killall -9 bash` from x-chat, since I couldn't get a new shell open)
with the below:
>>> Note that trying to kill all shells is a race between killing them all firs
> t
>>> and them spawning new ones everytime. To stop fork bombs, use killall -STOP
>>> first, then kill them.
>>>
>> Yes I know; the point, though, is that they should die automatically
>> when the process count hits 4096. They do with the first fork bomb;
>> they keep growing with the second, well past what they should.
>
> This may be another timing issue - note that in the first case, you have :|:
> which forks off 2 processes with a pipe in between. If the head process
> fails,
> the second probably won't get started by the shell *either*. In the second
> case, you launch *3*, and it's possible that the head process will start and
> live long enough to re-fork before a later one in the pipe gets killed.
>
> Does the behavior change if you use 4095 or 4097 rather than 4096? I'm
> willing to bet that your system exhibits semi-predictable behavior regarding
> the order the processes get created, and *which* process gets killed makes
> a difference regarding how fast the process tree gets pruned.
>
I will test this later (sleeping now)
> Do you have any good evidence that the second version manages to create much
> more than 4096 processes, rather than just being more exuberant about doing
> so?
> I'm guessing that in fact, in both cases the number of processes ends up
> pseudorandomly oscillating in the 4090-4906 range, but the exact order of
> operations makes the rate and impact different in the two cases.
I haven't gathered evidence; I rather look for evidence that fork() is
failing, like bash complaints. I get those in abundance in the first
case; but see none in the second case.
Trying again, I can't reproduce the phenomena. It crashes out in 3
seconds. Either just weird that it ran for so long last time before I
had to manually kill it off; or a race. I don't have sufficient data to
decide.
--
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
Anti-Spam: https://bugzilla.mozilla.org/show_bug.cgi?id=229686
-
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: Changes to PM layer break userspace
On Friday 22 December 2006 1:09 pm, Pavel Machek wrote: > Actually, if we noticed power/state during PM framework review, it > would have been killed. It is just way too ugly. > > > > > In contrast, the /sys/devices/.../power/state API has never had many > > > > users beyond developers trying to test their drivers ... > > > > > > It's used on every Ubuntu and Suse system, > > > > Odd how the relevant Suse developers didn't mention any issues with > > those files going away, any of the times problems with them were > > discussed on the PM list. Also, I have a Suse system that doesn't > > use those files for anything ... maybe only newer release use it. > > Not on *every* suse system. power/state is known to oops kernels, so > it is only enabled when user explicitely asks for 'dangerous aggresive > experimental power saving' or something like that. So exactly what tool on Ubuntu uses this? Without any "dangerous! aggressive! experimental!" read-lights-siren-alarms-ringing alert level? Seems to me anyone really desperate to put PCI devices into a low power mode, without driver support at the "ifdown" level, would be able just "rmmod driver; setpci". Without risking software bugs. - 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/
cypress_m8 spews garbage on ppc64 but is ok on x86
anyone tried using the cypress_m8 usb serial cable on a G5 ? just tried it on a ppc64/2.6.19.1 kernel and all i get back is garbage when hooked up to serial console of a board running at 57600 baud plugged the same cable into my x86 machine and it works OK there Bus 001 Device 010: ID 04b4:5500 Cypress Semiconductor Corp. HID->COM RS232 Adapter plugged a pl2303 into the ppc64 and that worked fine too Bus 001 Device 011: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port $ uname -a Linux G5 2.6.19.1 #2 SMP Sun Dec 24 00:53:03 EST 2006 ppc PPC970MP, altivec supported PowerMac11,2 GNU/Linux $ stty -F /dev/ttyUSB0 speed 57600 baud; line = 0; flush = ^U; min = 1; time = 5; ignbrk -brkint -icrnl ixoff -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke find attached logs after doing `modprobe cypress_m8 debug=1` * setup of /dev/ttyUSB0 to proper serial settings * the board running `yes` and spewing "y" over the serial console to my machine -mike cypress-yes.log.bz2 Description: BZip2 compressed data cypress-setup.log.bz2 Description: BZip2 compressed data
Re: evading ulimits
On Sat, 23 Dec 2006 19:42:10 EST, John Richard Moser said:
>
>
> Jan Engelhardt wrote:
> >> I've set up some stuff on my box where /etc/security/limits.conf
> >> contains the following:
> >>
> >> @users softnproc 3072
> >> @users hardnproc 4096
> >>
> >> I'm in group users, and a simple fork bomb is easily quashed by this:
> >>
> >> [EMAIL PROTECTED]:~$ :(){ :|:; };:
> >> bash: fork: Resource temporarily unavailable
> >> Terminated
> >>
> >> Oddly enough, trying this again and again yields the same results; but,
> >> I can kill the box (eventually; about 1 minute in I managed to `/exec
> >> killall -9 bash` from x-chat, since I couldn't get a new shell open)
> >> with the below:
> >
> > Note that trying to kill all shells is a race between killing them all firs
t
> > and them spawning new ones everytime. To stop fork bombs, use killall -STOP
> > first, then kill them.
> >
>
> Yes I know; the point, though, is that they should die automatically
> when the process count hits 4096. They do with the first fork bomb;
> they keep growing with the second, well past what they should.
This may be another timing issue - note that in the first case, you have :|:
which forks off 2 processes with a pipe in between. If the head process fails,
the second probably won't get started by the shell *either*. In the second
case, you launch *3*, and it's possible that the head process will start and
live long enough to re-fork before a later one in the pipe gets killed.
Does the behavior change if you use 4095 or 4097 rather than 4096? I'm
willing to bet that your system exhibits semi-predictable behavior regarding
the order the processes get created, and *which* process gets killed makes
a difference regarding how fast the process tree gets pruned.
Do you have any good evidence that the second version manages to create much
more than 4096 processes, rather than just being more exuberant about doing so?
I'm guessing that in fact, in both cases the number of processes ends up
pseudorandomly oscillating in the 4090-4906 range, but the exact order of
operations makes the rate and impact different in the two cases.
pgpOsUgCQvDYw.pgp
Description: PGP signature
Re: Binary Drivers
On Fri, 22 Dec 2006 23:19:09 PST, David Schwartz said: > You can't sell something that doesn't exist. If you sell a car even though > you can't explain how anyone could drive it, that's fraud. Are they allowed to sell a car that incorporates a computer that uses a trade-secret algorithm for controlling the fuel injection to get 20 more horsepower and 5% better mileage? pgpCOLAI27S0I.pgp Description: PGP signature
Re: Open letter to Linux kernel developers (was Re: Binary Drivers)
On Fri, 22 Dec 2006 12:59:21 +0100, Erik Mouw said: > On Thu, Dec 21, 2006 at 01:16:15PM -0500, [EMAIL PROTECTED] wrote: > > At least nVidia *does* actually Get It, they just don't have a choice in > > implementing it, because all their current hardware includes patents that > > they licensed from other companies (I believe some of the OpenGL stuff that > > originated at SGI and got bought by Microsoft is involved, but I have no > > hard references for actual patent numbers). And then they have the big > > problem - do they keep using the patent in order to boost performance, > > or no? > > Wasn't the whole idea about patents that you publish your invention? (Argh - I was too busy coming down with the flu to carefully read what I wrote, and as a result I was a tad less that totally specific and accurate. Hopefully I get it closer to right this time. ;) Patent licenses are also a good place to hang all sorts of side agreements on - and I'm pretty sure that the *actual* intellectual property involved is a witches' brew of patents, copyrights, and trade secrets, all wrapped up with a nice "thou shalt not disclose *any* of it" wrapper. In any case, there isn't much that *any* company can do to open-source something when they've got any sort of legally binding NDA attached to 3rd-party intellectual property. At best, they can design an entirely new product that totally avoids the IP in question - but as I noted last time, the company *does* have to do a sanity check when 90% of the market doesn't care in the slightest. pgpOtR0H9mRIk.pgp Description: PGP signature
Re: [PATCH 1/5] Update Documentation/pci.txt
On Fri, Dec 22, 2006 at 11:46:58AM -0800, Randy Dunlap wrote: ... > > +pci_register_driver() call requires passing in a table of function > > +calls and thus dictates the high level structure of a driver. > > s/calls/pointers/ ? Yes. I was thinking "call table" or "jump table". But you are correct that the struct contains "function pointers". I've adopted all the other changes as well and just reposted a v7 of pci.txt. thanks! grant - 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] Update Documentation/pci.txt v7
[ dropped e1000-devel and linux-scsi from CC list] On Mon, Dec 18, 2006 at 12:11:33AM -0700, Grant Grundler wrote: > Full version of pci.txt (v6 is 677 lines): > http://www.parisc-linux.org/~grundler/Documentation/pci.txt-06 > > I've appended patch v6 (823 lines!) and commit log entry is below. "final" patch v7 and commit log entry appended below. :) Full pci.txt text is easier to review at: http://www.parisc-linux.org/~grundler/Documentation/ This incoporates all changes, grammer and spelling corrections suggested by Randy Dunlap (thank you again!). Also some additional spelling correction by Stephan Richter (also thank you!) and other misc changes (white space, section numbering for chap 3, replace "aka" with "a.k.a.", etc). thanks, grant Rewrite Documentation/pci.txt: o restructure document to match how API is used when writing init code. o update to reflect changes in struct pci_driver function pointers. o removed language on "new style vs old style" device discovery. "Old style" is now deprecated. Don't use it. Left description in to document existing driver behaviors. o add section "Legacy I/O Port free driver" by Kenji Kaneshige http://lkml.org/lkml/2006/11/22/25 o add "MMIO space and write posting" section to help avoid common pitfall when converting drivers from IO Port space to MMIO space. Orignally posted http://lkml.org/lkml/2006/2/27/24 o many typo/grammer/spelling corrections from Randy Dunlap o two more spelling corrections from Stephan Richter Signed-off-by: Grant Grundler <[EMAIL PROTECTED]> diff --git a/Documentation/pci.txt b/Documentation/pci.txt index 2b395e4..397e3fb 100644 --- a/Documentation/pci.txt +++ b/Documentation/pci.txt @@ -1,142 +1,231 @@ -How To Write Linux PCI Drivers - by Martin Mares <[EMAIL PROTECTED]> on 07-Feb-2000 + How To Write Linux PCI Drivers + + by Martin Mares <[EMAIL PROTECTED]> on 07-Feb-2000 + updated by Grant Grundler <[EMAIL PROTECTED]> on 23-Dec-2006 -The world of PCI is vast and it's full of (mostly unpleasant) surprises. -Different PCI devices have different requirements and different bugs -- -because of this, the PCI support layer in Linux kernel is not as trivial -as one would wish. This short pamphlet tries to help all potential driver -authors find their way through the deep forests of PCI handling. +The world of PCI is vast and full of (mostly unpleasant) surprises. +Since each CPU architecture implements different chip-sets and PCI devices +have different requirements (erm, "features"), the result is the PCI support +in the Linux kernel is not as trivial as one would wish. This short paper +tries to introduce all potential driver authors to Linux APIs for +PCI device drivers. + +A more complete resource is the third edition of "Linux Device Drivers" +by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. +LDD3 is available for free (under Creative Commons License) from: + + http://lwn.net/Kernel/LDD3/ + +However, keep in mind that all documents are subject to "bit rot". +Refer to the source code if things are not working as described here. + +Please send questions/comments/patches about Linux PCI API to the +"Linux PCI" <[EMAIL PROTECTED]> mailing list. + 0. Structure of PCI drivers ~~~ -There exist two kinds of PCI drivers: new-style ones (which leave most of -probing for devices to the PCI layer and support online insertion and removal -of devices [thus supporting PCI, hot-pluggable PCI and CardBus in a single -driver]) and old-style ones which just do all the probing themselves. Unless -you have a very good reason to do so, please don't use the old way of probing -in any new code. After the driver finds the devices it wishes to operate -on (either the old or the new way), it needs to perform the following steps: +PCI drivers "discover" PCI devices in a system via pci_register_driver(). +Actually, it's the other way around. When the PCI generic code discovers +a new device, the driver with a matching "description" will be notified. +Details on this below. + +pci_register_driver() leaves most of the probing for devices to +the PCI layer and supports online insertion/removal of devices [thus +supporting hot-pluggable PCI, CardBus, and Express-Card in a single driver]. +pci_register_driver() call requires passing in a table of function +pointers and thus dictates the high level structure of a driver. + +Once the driver knows about a PCI device and takes ownership, the +driver generally needs to perform the following initialization: Enable the device - Access device configuration space - Discover resources (addresses and IRQ numbers) provided by the device - Allocate these resources - Communicate with the device + Request MMIO/IOP resources + Set the DMA mask
Re: 2.6.19-rc1 build problem
On Sat, Dec 23, 2006 at 03:07:15PM -0800, Andrew Morton wrote: > On Sat, 23 Dec 2006 14:14:48 -0600 > Steve French <[EMAIL PROTECTED]> wrote: > > > Is this a know problem with very current 2.6.19-rc? > > > > Building modules, stage 2. > > MODPOST 443 modules > > WARNING: "bitrev32" [drivers/net/8139cp.ko] undefined! > > You'll need to set CONFIG_BITREVERSE. Somehow. This is going to cause > problems and I suspect we'll end up giving up in horror and just adding it > to lib-y. >... Not lib-y but obj-y. Adding it to lib-y would be a bug, and it would obviously not help with this problem. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
On Sat, 23 Dec 2006 12:06:43 -0800 (PST) Linus Torvalds wrote: > > > On Sat, 23 Dec 2006, Randy Dunlap wrote: > > > > BTW, reiserfs has similar build problems: it uses clear_page_dirty() > > so it won't build. > > Not any more. I fixed that one (very different issue, btw: it's not > actually doign writeout, it actually wanted to cancel IO on truncated > buffers. > > However, it's certainly possible that my fix hasn't mirrored out yet, I > pushed it just a couple of hours ago. So if you want to test it, here are > the two commits in question.. > > (The "cancel_dirty_page()" cleanup is needed not just to do reiserfs as a > module, it's also to make it more robust against reiserfs possibly feeding > that function with strange pages, and to match the other related functions > in the accounting functions). > > Len Brown tested the reiserfs changes, and claims that it was all good, > but if somebody wants to run fsx-linux or some other filesystem stress > testing tool that actually tests shared mmap (and truncate), that would be > really appreciated. I ran fsx-linux on it for one hour... with no problems reported. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 3/5] add interface for netconsole using sysfs
On Fri, 22 Dec 2006 21:14:36 +0900 Keiichi KII wrote:
> From: Keiichi KII <[EMAIL PROTECTED]>
>
> ---
> [changes]
> 1. expand macro code as far as possible.
> 2. follow kernel coding style.
> 3. print proper output messeage.
> 4. attach proper label for printk.
> 5. integrate netpoll_lock and netcon_target_list_lock into common spinlock.
> 6. return proper error value.
>
> --- linux-mm/drivers/net/netconsole.c 2006-12-22 20:54:54.431673500 +0900
> +++ enhanced-netconsole/drivers/net/netconsole.c.sysfs2006-12-22
> 16:12:47.925833000 +0900
> @@ -56,18 +58,234 @@ MODULE_PARM_DESC(netconsole, " netconsol
>
> struct netconsole_target {
> struct list_head list;
> + struct kobject obj;
> int id;
> struct netpoll np;
> };
>
> +#define MAX_PRINT_CHUNK 1000
> +#define CONFIG_SEPARATOR ":"
> +#define MAC_ADDR_DIGIT 6
Can you use ETH_ALEN from if_ether.h instead of MAC_ADDR_DIGIT ?
> +
> +struct target_attr {
> + struct attribute attr;
> + ssize_t (*show)(struct netconsole_target*, char*);
> + ssize_t (*store)(struct netconsole_target*, const char*,
> + size_t count);
> +};
> +
> static int add_target(char* target_config);
> +static void setup_target_sysfs(struct netconsole_target *nt);
> static void cleanup_netconsole(void);
> static void delete_target(struct netconsole_target *nt);
>
> +static int miscdev_configured = 0;
Don't init static data to 0 or NULL.
It's done for us.
> static LIST_HEAD(target_list);
>
> static DEFINE_SPINLOCK(target_list_lock);
>
> +static ssize_t show_local_ip(struct netconsole_target *nt, char *buf)
> +{
> + return sprintf(buf, "%d.%d.%d.%d\n", HIPQUAD(nt->np.local_ip));
I don't understand the use of HIPQUAD() here instead of
NIPQUAD(). Explain?
Also, NIPQUAD_FMT (in kernel.h) uses "%u.%u.%u.%u".
This should probably be the same.
Or just use:NIPQUAD_FMT "\n"
> +}
> +
> +static ssize_t show_remote_ip(struct netconsole_target *nt, char *buf)
> +{
> + return sprintf(buf, "%d.%d.%d.%d\n", HIPQUAD(nt->np.remote_ip));
> +}
> +
> +
> +static ssize_t store_remote_mac(struct netconsole_target *nt, const char
> *buf,
> +size_t count)
> +{
> + unsigned char input_mac[MAC_ADDR_DIGIT] =
> + {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
> + const char *cur = buf;
> + char *delim;
> + int i = 0;
> +
> + for(i=0; i < MAC_ADDR_DIGIT; i++) {
for (i = 0; i < MAC_ADDR_DIGIT; i++) {
> + input_mac[i] = simple_strtol(cur, NULL, 16);
> + if (i != MAC_ADDR_DIGIT - 1 &&
> + (delim = strchr(cur, ':')) == NULL) {
> + return -EINVAL;
No braces on one-line "blocks", please.
> + }
> + cur = delim + 1;
> + }
> + spin_lock(_list_lock);
> + memcpy(nt->np.remote_mac, input_mac, MAC_ADDR_DIGIT);
> + spin_unlock(_list_lock);
> +
> + return count;
> +}
> +
> +
---
~Randy
-
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/
Linux 2.6.20-rc2
Ok, it's a couple of days delayed, because we've been trying to figure out what is up with the rtorrent hash failures since 2.6.18.3. I don't think we've made any progress, but we've cleaned up a number of suspects in the meantime. It's a bit sad, if only because I was really hoping to make 2.6.20 an easy release, and held back on merging some stuff during the merge window for that reason. And now we're battling something that was introduced much earlier.. Now, practically speaking this isn't likely to affect a lot of people, but it's still a worrisome problem, and we've had "top people" looking at it. And they'll continue, but xmas is coming. In the meantime, we'll continue with the stabilization, and this mainly does some driver updates (usb, sound, dri, pci hotplug) and ACPI updates (much of the latter syntactic cleanups). And arm and powerpc updates. Shortlog appended. For developers: if you sent me a patch, and I didn't apply it, it was probably just missed because I concentrated on other issues. So pls re-send.. Unless I explicitly told you that I'm not going to pull it due to the merge window being over, of course ;) Linus --- Adrian Bunk (10): ACPI: make drivers/acpi/ec.c:ec_ecdt static ACPI: fix NULL check in drivers/acpi/osl.c [ALSA] sound/core/control.c: remove dead code PCI: don't export device IDs to userspace Driver core: proper prototype for drivers/base/init.c:driver_init() make kernel/printk.c:ignore_loglevel_setup() static fs/sysv/: proper prototypes for 2 functions [ATM]: Remove dead ATM_TNETA1570 option. [ATM] drivers/atm/fore200e.c: Cleanups. [SCTP]: make 2 functions static Akinobu Mita (9): drm: fix return value check ata: fix platform_device_register_simple() error check ACPI: fix single linked list manipulation ACPI: prevent processor module from loading on failures [ALSA] sound: initialize rawmidi substream list [ALSA] sound: fix PCM substream list audit: fix kstrdup() error check gss_spkm3: fix error handling in module init tlclk: delete unnecessary sysfs_remove_group Al Viro (4): m68k trivial build fixes more work_struct fixes: tas300x sound drivers fix leaks on pipe(2) failure exits [IPV6]: Dumb typo in generic csum_ipv6_magic() Alan Cox (5): Fix help text for CONFIG_ATA_PIIX pata_via: Cable detect error usb serial: Eliminate bogus ioctl code pci: Introduce pci_find_present PCI: Fix multiple problems with VIA hardware Alan Stern (1): UHCI: module parameter to ignore overcurrent changes Alexey Starikovskiy (15): ACPI: ec: Allow for write semantics in any command. ACPI: ec: Enable EC GPE at beginning of transaction ACPI: ec: Increase timeout from 50 to 500 ms to handle old slow machines. ACPI: ec: Read status register from check_status() function ACPI: ec: Remove expect_event and all races around it. ACPI: ec: Remove calls to clear_gpe() and enable_gpe(), as these are handled at ACPI: ec: Query only single query at a time. ACPI: ec: Change semaphore to mutex. ACPI: ec: Rename gpe_bit to gpe ACPI: ec: Drop udelay() from poll mode. Loop by reading status field instead. ACPI: ec: Acquire Global Lock under EC mutex. ACPI: ec: Style changes. ACPI: ec: Change #define to enums there possible. ACPI: ec: Lindent once again ACPI: ibm_acpi: allow clean removal Andreas Mohr (1): [ALSA] via82xx: add __devinitdata Andrew Morton (15): ACPI: uninline ACPI global locking functions ACPI: acpi-cpufreq: remove unused data when !CONFIG_SMP ACPI: Kconfig - depend on PM rather than selecting it [libata] pata_cs5530: suspend/resume support tweak [libata] pata_via: suspend/resume support fix USB: Nokia E70 is an unusual device USB: Nokia E70 is an unusual device truncate: clear page dirtiness before running try_to_free_buffers() truncate: dirty memory accounting fix rtc warning fix smc911 workqueue fixes schedule_timeout(): improve warning message relay: remove inlining increase CARDBUS_MEM_SIZE build compile.h earlier Andrew Victor (3): USB: ohci at91 warning fix USB: at91 udc, support at91sam926x addresses USB: at91_udc, misc fixes Aneesh Kumar K.V (1): kobject: kobject_uevent() returns manageable value Arnd Bergmann (4): [POWERPC] cell: update cell_defconfig [POWERPC] cell: add forward struct declarations to spu.h [POWERPC] spufs: fix assignment of node numbers [POWERPC] powerpc: add scanning of ebc bus to of_platform Avi Kivity (4): KVM: AMD SVM: handle MSR_STAR in 32-bit mode KVM: AMD SVM: Save and restore the floating point unit state KVM: Use more traditional error handling in kvm_mmu_init() KVM: API versioning Badari
[Patch][RfC] Update to Documentation/tty.txt on line disciplines
While trying to develop a line discipline I found a couple of things worth mentioning in Documentation/tty.txt which weren't, so I decided to add them. It would be nice if someone more knowledgeable than me in that area would look over them, in case I got something wrong. Thanks Tilman From: Tilman Schmidt <[EMAIL PROTECTED]> Update to Documentation/tty.txt on line disciplines. Signed-off-by: Tilman Schmidt <[EMAIL PROTECTED]> --- tty.txt | 115 +--- 1 files changed, 103 insertions(+), 12 deletions(-) --- linux-2.6.20-rc1-work/Documentation/tty.txt 2006-11-29 22:57:37.0 +0100 +++ local/Documentation/tty.txt 2006-12-23 21:11:17.0 +0100 @@ -39,28 +39,37 @@ TTY side interfaces: +open() - Called when the line discipline is attached to + the terminal. No other call into the line + discipline for this tty will occur until it + completes successfully. Can sleep. + close()- This is called on a terminal when the line discipline is being unplugged. At the point of execution no further users will enter the ldisc code for this tty. Can sleep. -open() - Called when the line discipline is attached to - the terminal. No other call into the line - discipline for this tty will occur until it - completes successfully. Can sleep. +hangup() - Called when the tty line is hung up. + The line discipline should cease I/O to the tty. + No further calls into the ldisc code will occur. + Can sleep. write()- A process is writing data through the line discipline. Multiple write calls are serialized by the tty layer for the ldisc. May sleep. -flush_buffer() - May be called at any point between open and close. - -chars_in_buffer() -Report the number of bytes in the buffer. - -set_termios() - Called on termios structure changes. The caller - passes the old termios data and the current data - is in the tty. Called under the termios semaphore so - allowed to sleep. Serialized against itself only. +flush_buffer() - (optional) May be called at any point between + open and close, and instructs the line discipline + to empty its input buffer. + +chars_in_buffer() -(optional) Report the number of bytes in the input + buffer. + +set_termios() - (optional) Called on termios structure changes. + The caller passes the old termios data and the + current data is in the tty. Called under the + termios semaphore so allowed to sleep. Serialized + against itself only. read() - Move data from the line discipline to the user. Multiple read calls may occur in parallel and the @@ -92,6 +101,88 @@ this function. In such a situation defer it. +Driver Access + +Line discipline methods can call the following methods of the underlying +hardware driver through the function pointers within the tty->driver +structure: + +write()Write a block of characters to the tty device. + Returns the number of characters accepted. + +put_char() Queues a character for writing to the tty device. + If there is no room in the queue, the character is + ignored. + +flush_chars() (Optional) If defined, must be called after + queueing characters with put_char() in order to + start transmission. + +write_room() Returns the numbers of characters the tty driver + will accept for queueing to be written. + +ioctl()Invoke device specific ioctl. + Expects data pointers to refer to userspace. + Returns ENOIOCTLCMD for unrecognized ioctl numbers. + +set_termios() Notify the tty driver that the device's termios + settings have changed. New settings are in + tty->termios. Previous settings should be passed in + the "old" argument. + +throttle() Notify the tty driver that input buffers for the + line discipline are close to full, and it should + somehow signal that no more characters should be + sent to the tty. + +unthrottle() Notify the tty driver that characters can now be
Re: ebtables problems on 2.6.19.1 *and* 2.6.16.36
Patrick McHardy wrote:
I'm trying to reproduce this (without success so far), please send your
kernel config and your ebtables script.
You could try if 2.6.19 works, there were some ebtables changes in
2.6.19.1 that touched this code.
We're hitting this too, on both 2.6.16.36 and 2.6.19.1.
BUG: unable to handle kernel paging request at virtual address f8cec008
printing eip:
c0462272
*pde =
Oops: [#1]
SMP
Modules linked in: e1000
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.19.1-1-bigmem #1)
EIP is at translate_table+0x2b3/0xddf
eax: f8ce2000 ebx: 0004 ecx: f6d53e90 edx: f8ce2000
esi: f8cebfa0 edi: 000e ebp: esp: f6d53e08
ds: 007b es: 007b ss: 0068
Process ebtables (pid: 4788, ti=f6d52000 task=f6d51550 task.ti=f6d52000)
Stack: f6d53e40 c0540440 0007 f6d53ebc 0001 0028
0004 0fa0 0fd0 f8d38000 f8ce2000 f6d53e90
8000
0004 0014 0014
0600
Call Trace:
[] do_replace+0x113/0x6da
[] get_page_from_freelist+0x8c/0xa8
[] do_ebt_set_ctl+0x2d/0x2e
[] nf_sockopt+0xfa/0xfc
[] nf_setsockopt+0x23/0x2b
[] ip_setsockopt+0x86/0x91
[] sock_common_setsockopt+0x23/0x2f
[] sys_setsockopt+0x61/0xac
[] sys_socketcall+0x1e9/0x249
[] do_page_fault+0x0/0x664
[] sysenter_past_esp+0x56/0x79
[] svc_recv+0x9c/0x3f5
===
Code: 30 3b 28 0f 83 5c 02 00 00 8b 54 24 30 8b 74 24 24 8b 4c 24 34 8b
5c 24 4c 03 72 24 8b 79 20 89 5c 24 20 c7 44 24 1c 00 00 00 00 <8b> 56
68 8b 46 6c 29 d0 31 d2 89 44 24 14 8b 06 85 c0 0f 84 f7
EIP: [] translate_table+0x2b3/0xddf SS:ESP 0068:f6d53e08
Unable to handle kernel paging request at virtual address f8a3b00c
printing eip:
c03cce45
*pde =
Oops: [#13]
SMP
Modules linked in: e1000
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.16.36-1-bigmem #1)
EIP is at translate_table+0x47b/0xfc2
eax: d8fbbc3c ebx: 0098 ecx: c049b780 edx:
esi: f8a3afa0 edi: 000e ebp: 0001 esp: d8fbbb7c
ds: 007b es: 007b ss: 0068
Process ebtables (pid: 7917, threadinfo=d8fba000 task=e7892550)
Stack: <0>c049b75c f8a3af78 c04468f8 d8fbbbcc c049b740 0007 d8fbbc68
d30f4260
00d2 d8fba000 d30f4240 d8fba000 0028 0004
0004
0fa0 0fd0 f8a8e000 f8a38000
Call Trace:
[] do_replace+0x16b/0x887
[] copy_everything_to_user+0x21a/0x35c
[] do_ebt_set_ctl+0x40/0x42
[] nf_sockopt+0x11f/0x121
[] nf_setsockopt+0x37/0x3b
[] ip_setsockopt+0x3f9/0xb0e
[] nf_sockopt+0xad/0x121
[] nf_getsockopt+0x37/0x3b
[] ip_getsockopt+0x5bd/0x62b
[] current_fs_time+0x5d/0x78
[] touch_atime+0x7d/0xcd
[] zap_pte_range+0xf1/0x316
[] unmap_page_range+0x103/0x174
[] prio_tree_remove+0x77/0xe7
[] buffered_rmqueue+0x155/0x209
[] buffered_rmqueue+0x155/0x209
[] get_page_from_freelist+0x8c/0xa6
[] get_page_from_freelist+0x8c/0xa6
[] __alloc_pages+0x56/0x309
[] page_add_file_rmap+0x2a/0x2c
[] do_anonymous_page+0x122/0x22a
[] __handle_mm_fault+0x138/0x326
[] sock_common_setsockopt+0x33/0x37
[] sys_setsockopt+0x6c/0xb2
[] sys_socketcall+0x1f4/0x254
[] do_page_fault+0x0/0x630
[] sysenter_past_esp+0x54/0x75
Code: 24 8b bc 24 8c 00 00 00 8b 84 24 88 00 00 00 8b 54 24 64 8b 74 24
44 03 77 24 8b 78 20 c7 44 24 38 00 00 00 00 89 54 24 3c 31 d2 <8b> 4e
6c 8b 5e 68 29 d9 89 4c 24 30 8b 06 85 c0 0f 84 14 02 00
It seems to happen when flushing a user-defined ebtable, or removing a
rule -- but not every time. It leaves the ebtable userspace process in D
state on 2.6.19.1 but not on 2.6.16.36 (?).
Considering I've never had these problems before, and that both stable
(2.6.16.36) and current (2.6.19.1) exhibit this issue, I'd venture to
guess that it's something that went into both of them very recently.
-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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
[EMAIL PROTECTED] wrote: > On Fri, 22 Dec 2006 02:34:54 +1100, Marek Wawrzyczny said: [...] > > Perhaps we just report on the individual devices then... forget the system > > rating. > OK, *that* I see as potentially useful - I frequently get handed older > boxen with strange gear == gear for which there is probably no documentation at all > in them, and need a way to figure out if I want to > install software, LiveCD of your choice... > or cannibalize it for parts. Also helpful if a buddy has > a Frankintel box they build, and they want to know if they can install > something other than Windows Same as above. > Bonus points if it sees a card that has a known out-of-tree driver and > tells you where to find it and what its license status is (I just went > down that road with an Intel 3945)... If in-tree driver is already a challange, out-of-tree is hopeless. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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] procfs: export context switch counts in /proc/*/stat
"Albert Cahalan" <[EMAIL PROTECTED]> writes: > The cumulative ones are still not justified though, and I fear they > may be 64-bit even on i386. All the context switch counts are unsigned long. > It turns out that an i386 procps spends > much of its time doing 64-bit division to parse the damn ASCII crap. > I suppose I could just skip those fields, but generating them isn't > too cheap and probably I'd get stuck parsing them for some other > reason -- having them separate is probably a good idea. I can't think of a compelling justification for the cumulative context switch counts. But I suggest that if the cost of exposing these values is low enough, they should be exposed anyway, just for the sake of uniformity (these would be the only two getrusage values not present in /proc/pid/stat). If the decimal representation of values in /proc/pid/stat has such unpleasant overheads, then I wonder if that is something worth fixing, whether the context switch counts are added or not? It occurs to me that it would be easy to add support for a hex version of /proc/pid/stat with very little additional code, by using an alternate sprintf format string in fs/proc/array.c:do_task_stat(). I assume that procps could be adapted quite easily to take advantage of this? David - 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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
On Sun, 24 Dec 2006 00:55:01 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote: > PM: Removing info for No Bus:usbdev3.15_ep81 > PM: Removing info for No Bus:usbdev3.15_ep82 > PM: Removing info for No Bus:usbdev3.15_ep02 > slab error in verify_redzone_free(): cache `size-512': memory outside object > was overwritten > [] cache_free_debugcheck+0x128/0x1d0 > [] hci_usb_close+0xf3/0x160 > [] kfree+0x50/0xa0 > [] hci_usb_close+0xf3/0x160 > [] hci_usb_disconnect+0x2e/0x90 > [] usb_disable_interface+0x53/0x70 > [] usb_unbind_interface+0x38/0x80 > [] __device_release_driver+0x68/0xb0 > [] device_release_driver+0x1e/0x40 > [] bus_remove_device+0x8b/0xa0 > [] device_del+0x159/0x1c0 > [] usb_disable_device+0x4d/0x100 > [] usb_disconnect+0x9a/0x110 > [] hub_thread+0x355/0xbd0 > [] schedule+0x2de/0x8f0 > [] autoremove_wake_function+0x0/0x50 > [] hub_thread+0x0/0xbd0 > [] kthread+0xec/0xf0 > [] kthread+0x0/0xf0 > [] kernel_thread_helper+0x7/0x10 > === yes, this one looks like memory scribblage in bluetooth. The buffer.c assertion failure should now be fixed, please verify. - 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: ext3-related crash in 2.6.20-rc1
On Sun, 24 Dec 2006 00:43:05 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > I got this nasty oops while playing with debugger. Not sure if that is > related; it also might be something with bluetooth; I already know it > corrupts memory during suspend, perhaps it corrupts memory in some > error path? > > > > Pavel > > > l2cap_recv_acldata: Unexpected continuation frame (len 0) > l2cap_recv_acldata: Unexpected continuation frame (len 0) > l2cap_recv_acldata: Unexpected continuation frame (len 0) > l2cap_recv_acldata: Unexpected continuation frame (len 0) > l2cap_recv_acldata: Unexpected continuation frame (len 0) > l2cap_recv_acldata: Unexpected continuation frame (len 0) > l2cap_recv_acldata: Unexpected continuation frame (len 0) > PM: Removing info for bluetooth:acl00803715A329 > e1000: eth0: e1000_watchdog: NIC Link is Down > e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex > e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO > e1000: eth0: e1000_watchdog: NIC Link is Down > e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex > e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO > [ cut here ] > kernel BUG at fs/buffer.c:1235! get thee to fs/buffer.c:1235. You'll see that someone somewhere forgot to reenable local interrupts. Were you using gdb at the time? A fix for something like that was merged into mainline yesterday. The slab errors which you're reporting in later emails will almost surely be unrelated to 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: ptrace() memory corruption?
Pavel Machek wrote: >> Is there something wrong with gdb? > > Yep. If I do gdb /bin/bash, run; I'll get similar oops. Am I alone > seeing this? Nope, I have this nasty thing here too and will post oopses in the afternoon, just before Jezisek comes :). regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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] add .mailmap for proper git-shortlog output
This list was built into the git-shortlog tool and has been removed in the latest version. It should be maintained separately so this is what this patch does. A couple more entries were added to the original list as well. Signed-off-by: Nicolas Pitre <[EMAIL PROTECTED]> --- diff --git a/.mailmap b/.mailmap new file mode 100644 index 000..016b861 --- /dev/null +++ b/.mailmap @@ -0,0 +1,96 @@ +# +# This list is used by git-shortlog to fix a few botched name translations +# in the git archive, either because the author's full name was messed up +# and/or not always written the same way, making contributions from the +# same person appearing not to be so or badly displayed. +# +# repo-abbrev: /pub/scm/linux/kernel/git/ +# + +Aaron Durbin <[EMAIL PROTECTED]> +Adam Oldham <[EMAIL PROTECTED]> +Adam Radford <[EMAIL PROTECTED]> +Adrian Bunk <[EMAIL PROTECTED]> +Alan Cox <[EMAIL PROTECTED]> +Alan Cox <[EMAIL PROTECTED]> +Aleksey Gorelov <[EMAIL PROTECTED]> +Al Viro <[EMAIL PROTECTED]> +Al Viro <[EMAIL PROTECTED]> +Andreas Herrmann <[EMAIL PROTECTED]> +Andrew Morton <[EMAIL PROTECTED]> +Andrew Vasquez <[EMAIL PROTECTED]> +Andy Adamson <[EMAIL PROTECTED]> +Arnaud Patard <[EMAIL PROTECTED]> +Arnd Bergmann <[EMAIL PROTECTED]> +Axel Dyks <[EMAIL PROTECTED]> +Ben Gardner <[EMAIL PROTECTED]> +Ben M Cahill <[EMAIL PROTECTED]> +Björn Steinbrink <[EMAIL PROTECTED]> +Brian Avery <[EMAIL PROTECTED]> +Brian King <[EMAIL PROTECTED]> +Christoph Hellwig <[EMAIL PROTECTED]> +Corey Minyard <[EMAIL PROTECTED]> +David Brownell <[EMAIL PROTECTED]> +David Woodhouse <[EMAIL PROTECTED]> +Domen Puncer <[EMAIL PROTECTED]> +Douglas Gilbert <[EMAIL PROTECTED]> +Ed L. Cashin <[EMAIL PROTECTED]> +Evgeniy Polyakov <[EMAIL PROTECTED]> +Felipe W Damasio <[EMAIL PROTECTED]> +Felix Kuhling <[EMAIL PROTECTED]> +Felix Moeller <[EMAIL PROTECTED]> +Filipe Lautert <[EMAIL PROTECTED]> +Franck Bui-Huu <[EMAIL PROTECTED]> +Frank Zago <[EMAIL PROTECTED]> +Greg Kroah-Hartman <[EMAIL PROTECTED](none)> +Greg Kroah-Hartman <[EMAIL PROTECTED]> +Greg Kroah-Hartman <[EMAIL PROTECTED]> +Henk Vergonet <[EMAIL PROTECTED]> +Henrik Kretzschmar <[EMAIL PROTECTED]> +Herbert Xu <[EMAIL PROTECTED]> +Jacob Shin <[EMAIL PROTECTED]> +James Bottomley <[EMAIL PROTECTED](none)> +James Bottomley <[EMAIL PROTECTED]> +James E Wilson <[EMAIL PROTECTED]> +James Ketrenos <[EMAIL PROTECTED](none)> +Jean Tourrilhes <[EMAIL PROTECTED]> +Jeff Garzik <[EMAIL PROTECTED]> +Jens Axboe <[EMAIL PROTECTED]> +Jens Osterkamp <[EMAIL PROTECTED]> +John Stultz <[EMAIL PROTECTED]> +Juha Yrjola +Juha Yrjola <[EMAIL PROTECTED]> +Juha Yrjola <[EMAIL PROTECTED]> +Kay Sievers <[EMAIL PROTECTED]> +Kenneth W Chen <[EMAIL PROTECTED]> +Koushik <[EMAIL PROTECTED]> +Leonid I Ananiev <[EMAIL PROTECTED]> +Linas Vepstas <[EMAIL PROTECTED]> +Matthieu CASTET <[EMAIL PROTECTED]> +Michel Dänzer <[EMAIL PROTECTED]> +Mitesh shah <[EMAIL PROTECTED]> +Morten Welinder <[EMAIL PROTECTED]> +Morten Welinder <[EMAIL PROTECTED]> +Morten Welinder <[EMAIL PROTECTED]> +Morten Welinder <[EMAIL PROTECTED]> +Nguyen Anh Quynh <[EMAIL PROTECTED]> +Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> +Patrick Mochel <[EMAIL PROTECTED]> +Peter A Jonsson <[EMAIL PROTECTED]> +Praveen BP <[EMAIL PROTECTED]> +Rajesh Shah <[EMAIL PROTECTED]> +Ralf Baechle <[EMAIL PROTECTED]> +Ralf Wildenhues <[EMAIL PROTECTED]> +Rémi Denis-Courmont <[EMAIL PROTECTED]> +Rudolf Marek <[EMAIL PROTECTED]> +Rui Saraiva <[EMAIL PROTECTED]> +Sachin P Sant <[EMAIL PROTECTED]> +Sam Ravnborg <[EMAIL PROTECTED]> +Simon Kelley <[EMAIL PROTECTED]> +Stéphane Witzmann <[EMAIL PROTECTED]> +Stephen Hemminger <[EMAIL PROTECTED]> +Tejun Heo <[EMAIL PROTECTED]> +Thomas Graf <[EMAIL PROTECTED]> +Tony Luck <[EMAIL PROTECTED]> +Tsuneo Yoshioka <[EMAIL PROTECTED]> +Valdis Kletnieks <[EMAIL PROTECTED]>
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sat, Dec 23, 2006 at 10:36:02PM +0100, Pavel Machek wrote: > On Sat 2006-12-23 12:24:29, Adrian Bunk wrote: > > On Thu, Dec 21, 2006 at 03:38:29PM +, Pavel Machek wrote: > > > On Thu 14-12-06 20:51:36, Adrian Bunk wrote: > > > > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote: > > > > > On Thu, Dec 14, 2006 at 04:33:47PM +, Alan wrote: > > > > > > > The trick is to let a lawyer send cease and desist letters to > > > > > > > people > > > > > > > distributing the infringing software for 1 Euro at Ebay. > > > > > > > > > > > > Doesn't that sound even more like the music industry ? Pick on > > > > > > Grandma, > > > > > > and people who've no clue about the issue. It's not the way to > > > > > > solve such > > > > > > problems. The world does not need "The war on binary modules". > > > > > > Educate > > > > > > people instead, and talk to vendors. > > > > > > > > > > or like Microsoft, who is threatening to make war on end-users > > > > > instead of settling things with vendors. (One of the reasons why I > > > > > personally find the Microsoft promise not to sue _Novell_'s end users > > > > > so nasty. Microsoft shouldn't be threatening anyone's users; if they > > > > > have a problem, they should be taking it up with the relevant vendor, > > > > > not sueing innocent and relatively shallow-pocketed end-users and > > > > > distributors.) > > > > > > > > > > One of the things that I find so interesting about how rabid people > > > > > get about enforcing GPL-only modules is how they start acting more and > > > > > more like the RIAA, MPAA, and Microsoft every day > > > > > > > > Please don't think or imply I'd plan to do this, I'm only saying that > > > > there's a risk for users in such grey areas. > > > > > > > > It could be that someone who wants to harm Linux starts suing people > > > > distributing Linux. If your goal is to harm Linux, suing users can > > > > simply be much more effective than suing vendors... > > > > > > > > It could even be that people distributing Linux could receive cease and > > > > desist letters from people without any real interest in the issue > > > > itself - "cease and desist letter"s are so frequent in Germany because > > > > the people who have to sign them have to pay the lawyers' costs that > > > > are > > > > usually > 1000 Euro, and that's a good business for the lawyers. > > > > > > Something is very wrong with German legal system, I'm afraid. > > > > The point that you can take legal actions against anyone distributing > > something that violates your rights should be present in more or less > > all legal systems. > > > > What might be special in Germany is only that you can demand your costs > > after successfully taking legal actions. > > What is special in Germany is fact that any random lawyer can demand > $1000 (not his cost, his profit) if you distribute code that is not > his... This is a misunderstanding. You can demand the costs for your lawyer. The costs for your lawyer depend on the amount in controversy. The one who tells his lawyer to take legal actions might be a copyright owner, but it's also possible based on competition law. > Pavel cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
linux 2.6.20-rc1: kernel BUG at fs/buffer.c:1235!
this is on a thinkpad t40, not sure if it means anything, but here it goes: kernel: kernel BUG at fs/buffer.c:1235! kernel: invalid opcode: [#1] kernel: PREEMPT kernel: Modules linked in: radeon drm binfmt_misc nfs sd_mod scsi_mod nfsd exportfs lockd sunrpc autofs4 pcmcia firmware_class joydev irtty_sir sir_dev nsc_ircc irda crc_ccitt parport_pc parport ehci_hcd uhci_hcd usbcore aes_i586 airo nls_iso8859_1 ntfs yenta_socket rsrc_nonstatic pcmcia_core kernel: CPU:0 kernel: EIP:0060:[]Not tainted VLI kernel: EFLAGS: 00010046 (2.6.20-rc1 #215) kernel: EIP is at __find_get_block+0x14/0x15e kernel: eax: 0082 ebx: c661fcf0 ecx: 1000 edx: 004d7f7a kernel: esi: 1000 edi: 004d7f7a ebp: c146d740 esp: c661fb80 kernel: ds: 007b es: 007b ss: 0068 kernel: Process vdrift (pid: 27994, ti=c661e000 task=ddc9da70 task.ti=c661e000) kernel: Stack: 1000 000b0059 cf76d9f8 c016ae46 cf76d9f8 cf76dd38 d7da8684 kernel:c661fcf0 004d7f7a 1000 c016ae66 c661fd1c 000b0059 004d7f7a kernel:c146d740 c661fcf0 004d7f7a c661fcf8 c019889a c661fc0c kernel: Call Trace: kernel: [] __find_get_block+0x154/0x15e kernel: [] __getblk+0x16/0x1d6 kernel: [] search_by_key+0x6b/0xc77 kernel: [] try_to_wake_up+0x13c/0x147 kernel: [] __group_send_sig_info+0x5e/0x69 kernel: [] group_send_sig_info+0x5d/0x65 kernel: [] hrtimer_run_queues+0x136/0x14c kernel: [] run_timer_softirq+0x17c/0x184 kernel: [] make_cpu_key+0x3f/0x46 kernel: [] reiserfs_update_sd_size+0x7e/0x284 kernel: [] profile_tick+0x42/0x5d kernel: [] journal_begin+0x99/0xd0 kernel: [] reiserfs_dirty_inode+0x61/0x7e kernel: [] __mark_inode_dirty+0x2a/0x18d kernel: [] __d_lookup+0x120/0x13d kernel: [] inode_setattr+0x15f/0x169 kernel: [] reiserfs_setattr+0x152/0x185 kernel: [] current_fs_time+0x45/0x51 kernel: [] notify_change+0x101/0x219 kernel: [] do_truncate+0x52/0x68 kernel: [] get_unused_fd+0xa9/0xc5 kernel: [] may_open+0x17c/0x193 kernel: [] open_namei+0x25a/0x56e kernel: [] do_filp_open+0x25/0x39 kernel: [] get_unused_fd+0xa9/0xc5 kernel: [] do_sys_open+0x42/0xc3 kernel: [] sys_open+0x1c/0x1e kernel: [] syscall_call+0x7/0xb kernel: [] unix_create1+0x4a/0xee kernel: === kernel: Code: 89 e0 25 00 e0 ff ff 8b 40 08 a8 08 74 05 e8 cd 93 19 00 5b 5e 5f c3 55 89 c5 57 89 d7 56 89 ce 53 83 ec 20 9c 58 f6 c4 02 75 04 <0f> 0b eb fe b8 01 00 00 00 e8 ae 94 fa ff 31 c9 8b 1c 8d 20 23 kernel: EIP: [] __find_get_block+0x14/0x15e SS:ESP 0068:c661fb80 kernel: WARNING at kernel/exit.c:853 do_exit() kernel: [] do_exit+0x42/0x72f kernel: [] printk+0x1b/0x1f kernel: [] die+0x1d9/0x1e1 kernel: [] do_invalid_op+0x0/0xab kernel: [] do_invalid_op+0xa2/0xab kernel: [] __find_get_block+0x14/0x15e kernel: [] __getblk+0x16/0x1d6 kernel: [] clocksource_get_next+0x3b/0x55 kernel: [] do_timer+0x500/0x711 kernel: [] reiserfs_read_bitmap_block+0x5c/0xc1 kernel: [] hrtimer_run_queues+0x123/0x14c kernel: [] error_code+0x74/0x7c kernel: [] shrink_icache_memory+0x17b/0x1ce kernel: [] __find_get_block+0x14/0x15e kernel: [] __find_get_block+0x154/0x15e kernel: [] __getblk+0x16/0x1d6 kernel: [] search_by_key+0x6b/0xc77 kernel: [] try_to_wake_up+0x13c/0x147 kernel: [] __group_send_sig_info+0x5e/0x69 kernel: [] group_send_sig_info+0x5d/0x65 kernel: [] hrtimer_run_queues+0x136/0x14c kernel: [] run_timer_softirq+0x17c/0x184 kernel: [] make_cpu_key+0x3f/0x46 kernel: [] reiserfs_update_sd_size+0x7e/0x284 kernel: [] profile_tick+0x42/0x5d kernel: [] journal_begin+0x99/0xd0 kernel: [] reiserfs_dirty_inode+0x61/0x7e kernel: [] __mark_inode_dirty+0x2a/0x18d kernel: [] __d_lookup+0x120/0x13d kernel: [] inode_setattr+0x15f/0x169 kernel: [] reiserfs_setattr+0x152/0x185 kernel: [] current_fs_time+0x45/0x51 kernel: [] notify_change+0x101/0x219 kernel: [] do_truncate+0x52/0x68 kernel: [] get_unused_fd+0xa9/0xc5 kernel: [] may_open+0x17c/0x193 kernel: [] open_namei+0x25a/0x56e kernel: [] do_filp_open+0x25/0x39 kernel: [] get_unused_fd+0xa9/0xc5 kernel: [] do_sys_open+0x42/0xc3 kernel: [] sys_open+0x1c/0x1e kernel: [] syscall_call+0x7/0xb kernel: [] unix_create1+0x4a/0xee kernel: === --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | - 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: evading ulimits
Jan Engelhardt wrote:
>> I've set up some stuff on my box where /etc/security/limits.conf
>> contains the following:
>>
>> @users softnproc 3072
>> @users hardnproc 4096
>>
>> I'm in group users, and a simple fork bomb is easily quashed by this:
>>
>> [EMAIL PROTECTED]:~$ :(){ :|:; };:
>> bash: fork: Resource temporarily unavailable
>> Terminated
>>
>> Oddly enough, trying this again and again yields the same results; but,
>> I can kill the box (eventually; about 1 minute in I managed to `/exec
>> killall -9 bash` from x-chat, since I couldn't get a new shell open)
>> with the below:
>
> Note that trying to kill all shells is a race between killing them all first
> and them spawning new ones everytime. To stop fork bombs, use killall -STOP
> first, then kill them.
>
Yes I know; the point, though, is that they should die automatically
when the process count hits 4096. They do with the first fork bomb;
they keep growing with the second, well past what they should.
>
> -`J'
--
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
Anti-Spam: https://bugzilla.mozilla.org/show_bug.cgi?id=229686
-
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: evading ulimits
>I've set up some stuff on my box where /etc/security/limits.conf
>contains the following:
>
>@users softnproc 3072
>@users hardnproc 4096
>
>I'm in group users, and a simple fork bomb is easily quashed by this:
>
>[EMAIL PROTECTED]:~$ :(){ :|:; };:
>bash: fork: Resource temporarily unavailable
>Terminated
>
>Oddly enough, trying this again and again yields the same results; but,
>I can kill the box (eventually; about 1 minute in I managed to `/exec
>killall -9 bash` from x-chat, since I couldn't get a new shell open)
>with the below:
Note that trying to kill all shells is a race between killing them all first
and them spawning new ones everytime. To stop fork bombs, use killall -STOP
first, then kill them.
-`J'
--
-
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/
ptrace() memory corruption?
On Sun 2006-12-24 01:06:05, Pavel Machek wrote: > On Sun 2006-12-24 01:01:50, Pavel Machek wrote: > > Hi! > > > > > > I got this nasty oops while playing with debugger. Not sure if that is > > > > related; it also might be something with bluetooth; I already know it > > > > corrupts memory during suspend, perhaps it corrupts memory in some > > > > error path? > > > > > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > > > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > > > cycles... so it is probably unrelated to the previous crash. > > > > > > I was getting pretty regular crashes with bluetooth & gdb, but I was > > > not using bluetooth at the time of ext3-related crash. > > > > And for completeness, here's bluetooth + gdb oops. Ok, I'm not _sure_ > > it is bluetooth related. I'll try it without bluetooth in a while. > > Ok, so this one is not bluetooth related. My little "phone" > application provokes nasty oops, even when talking to > /dev/null. Strange, that code does _nothing_ > strange. (www.sf.net/projects/tui). > > Is there something wrong with gdb? Yep. If I do gdb /bin/bash, run; I'll get similar oops. Am I alone seeing this? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
not-only-bluetooth memory corruption
On Sun 2006-12-24 01:01:50, Pavel Machek wrote: > Hi! > > > > I got this nasty oops while playing with debugger. Not sure if that is > > > related; it also might be something with bluetooth; I already know it > > > corrupts memory during suspend, perhaps it corrupts memory in some > > > error path? > > > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > > cycles... so it is probably unrelated to the previous crash. > > > > I was getting pretty regular crashes with bluetooth & gdb, but I was > > not using bluetooth at the time of ext3-related crash. > > And for completeness, here's bluetooth + gdb oops. Ok, I'm not _sure_ > it is bluetooth related. I'll try it without bluetooth in a while. Ok, so this one is not bluetooth related. My little "phone" application provokes nasty oops, even when talking to /dev/null. Strange, that code does _nothing_ strange. (www.sf.net/projects/tui). Is there something wrong with gdb? Pavel pcmcia: Detected deprecated PCMCIA ioctl usage from process: cardmgr. pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools. pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details. cs: IO port probe 0x310-0x380: clean. cs: IO port probe 0xa00-0xaff: clean. PM: Adding info for No Bus:vcs10 PM: Adding info for No Bus:vcsa10 PM: Removing info for No Bus:vcs10 PM: Removing info for No Bus:vcsa10 PM: Adding info for No Bus:vcs10 PM: Adding info for No Bus:vcsa10 PM: Removing info for No Bus:vcs10 PM: Removing info for No Bus:vcsa10 e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO PM: Adding info for No Bus:vcs11 PM: Adding info for No Bus:vcsa11 PM: Adding info for No Bus:vcs2 PM: Adding info for No Bus:vcs3 PM: Adding info for No Bus:vcs4 PM: Adding info for No Bus:vcsa2 PM: Adding info for No Bus:vcs5 PM: Adding info for No Bus:vcs6 PM: Adding info for No Bus:vcs7 PM: Adding info for No Bus:vcs8 PM: Adding info for No Bus:vcsa3 PM: Adding info for No Bus:vcsa4 PM: Adding info for No Bus:vcsa5 PM: Adding info for No Bus:vcsa6 PM: Adding info for No Bus:vcsa7 PM: Adding info for No Bus:vcsa8 coda_read_super: Bad mount data coda_read_super: device index: 0 coda_read_super: No pseudo device PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 kjournald starting. Commit interval 5 seconds EXT3 FS on sda2, internal journal EXT3-fs: mounted filesystem with ordered data mode. [ cut here ] kernel BUG at fs/buffer.c:1235! invalid opcode: [#1] SMP Modules linked in: CPU:1 EIP:0060:[]Not tainted VLI EFLAGS: 00010046 (2.6.20-rc1 #383) EIP is at __find_get_block+0x1b2/0x1c0 eax: 0086 ebx: 1000 ecx: edx: 006780b2 esi: 0033d60d edi: 1000 ebp: 00cf esp: f6de1c90 ds: 007b es: 007b ss: 0068 Process phone (pid: 1847, ti=f6de task=c2329550 task.ti=f6de) Stack: 006780b2 c20eb5f8 0003 05950595 c236d8d2 c0629908 f88da000 0012 0002 0003 05800580 c236d878 c016a284 1000 0033d60d 1000 00cf c01912df 1000 5a0df380 007f f77b9c0c Call Trace: [] check_poison_obj+0x24/0x1a0 [] __getblk+0x1f/0x290 [] lock_timer_base+0x20/0x50 [] __mod_timer+0x90/0xa0 [] __ext3_get_inode_loc+0x120/0x3a0 [] dbg_redzone1+0xe/0x20 [] cache_alloc_debugcheck_after+0x3e/0x150 [] journal_start+0x83/0xe0 [] ext3_reserve_inode_write+0x27/0x80 [] ext3_mark_inode_dirty+0x1a/0x40 [] ext3_dirty_inode+0x79/0xb0 [] __mark_inode_dirty+0x34/0x1c0 [] file_update_time+0x39/0xa0 [] __generic_file_aio_write_nolock+0x244/0x590 [] __mutex_lock_slowpath+0xef/0x230 [] generic_file_aio_write+0x59/0xd0 [] apic_timer_interrupt+0x28/0x30 [] ext3_file_write+0x30/0xc0 [] do_sync_write+0xc7/0x130 [] autoremove_wake_function+0x0/0x50 [] remove_vma+0x39/0x50 [] vfs_write+0xa6/0x160 [] do_sync_write+0x0/0x130 [] sys_write+0x41/0x70 [] syscall_call+0x7/0xb === Code: 00 8b 7c 24 18 f3 a5 fb 8b 44 24 10 85 c0 0f 84 2c ff ff ff 8b 44 24 10 e8 5c ca ff ff e9 1e ff ff ff 89 d8 e8 50 ca ff ff eb 8d <0f> 0b eb fe 0f 0b eb fe 0f 0b eb fe 89 f6 55 57 56 53 83 ec 48 EIP: [] __find_get_block+0x1b2/0x1c0 SS:ESP 0068:f6de1c90 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html oops4.bz2 Description: Binary data
Re: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi! > > I got this nasty oops while playing with debugger. Not sure if that is > > related; it also might be something with bluetooth; I already know it > > corrupts memory during suspend, perhaps it corrupts memory in some > > error path? > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > cycles... so it is probably unrelated to the previous crash. > > I was getting pretty regular crashes with bluetooth & gdb, but I was > not using bluetooth at the time of ext3-related crash. And for completeness, here's bluetooth + gdb oops. Ok, I'm not _sure_ it is bluetooth related. I'll try it without bluetooth in a while. Pavel PM: Adding info for No Bus:vcsa8 coda_read_super: Bad mount data coda_read_super: device index: 0 coda_read_super: rootfid is (01234567..080519b0.) PM: Removing info for No Bus:vcs10 PM: Removing info for No Bus:vcsa10 coda_upcall: Venus dead on (op,un) (7.2) flags 10 Failure of coda_cnode_make for root: error -19 hci_cmd_task: hci0 command tx timeout PM: Adding info for No Bus:rfcomm1 PM: Adding info for bluetooth:acl00803715A329 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata:
bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi! > I got this nasty oops while playing with debugger. Not sure if that is > related; it also might be something with bluetooth; I already know it > corrupts memory during suspend, perhaps it corrupts memory in some > error path? Okay, I spoke too soon. bluetooth & suspend memory corruption was _way_ harder to reproduce than expected. Took me 5-or-so-suspend cycles... so it is probably unrelated to the previous crash. I was getting pretty regular crashes with bluetooth & gdb, but I was not using bluetooth at the time of ext3-related crash. Pavel acpi acpi: resuming __tx_submit: hci0 tx submit failed urb c20efb08 type 2 err -113 agpgart-intel :00:00.0: resuming pci :00:02.0: resuming pci :00:02.1: resuming PM: Writing back config space on device :00:02.1 at offset 1 (was 90, writing 93) HDA Intel :00:1b.0: resuming PM: Writing back config space on device :00:1b.0 at offset 1 (was 100106, writing 100102) PCI: Setting latency timer of device :00:1b.0 to 64 pci :00:1c.0: resuming PCI: Setting latency timer of device :00:1c.0 to 64 pci :00:1c.1: resuming PCI: Setting latency timer of device :00:1c.1 to 64 pci :00:1c.2: resuming PCI: Setting latency timer of device :00:1c.2 to 64 pci :00:1c.3: resuming PM: Writing back config space on device :00:1c.3 at offset f (was 40400, writing 4040b) PM: Writing back config space on device :00:1c.3 at offset 9 (was 10001, writing e421e421) PM: Writing back config space on device :00:1c.3 at offset 8 (was 0, writing ebf0ea00) PM: Writing back config space on device :00:1c.3 at offset 7 (was 2000, writing 8070) PM: Writing back config space on device :00:1c.3 at offset 3 (was 81, writing 810010) PM: Writing back config space on device :00:1c.3 at offset 1 (was 10, writing 100107) PCI: Setting latency timer of device :00:1c.3 to 64 uhci_hcd :00:1d.0: resuming PCI: Setting latency timer of device :00:1d.0 to 64 usb usb4: root hub lost power or was reset uhci_hcd :00:1d.1: resuming PCI: Setting latency timer of device :00:1d.1 to 64 usb usb2: root hub lost power or was reset uhci_hcd :00:1d.2: resuming PCI: Setting latency timer of device :00:1d.2 to 64 usb usb5: root hub lost power or was reset uhci_hcd :00:1d.3: resuming PCI: Setting latency timer of device :00:1d.3 to 64 usb usb3: root hub lost power or was reset ehci_hcd :00:1d.7: resuming PCI: Setting latency timer of device :00:1d.7 to 64 pci :00:1e.0: resuming PM: Writing back config space on device :00:1e.0 at offset 1 (was 15, writing 17) PCI: Setting latency timer of device :00:1e.0 to 64 pci :00:1f.0: resuming PIIX_IDE :00:1f.1: resuming ahci :00:1f.2: resuming PCI: Setting latency timer of device :00:1f.2 to 64 pci :00:1f.3: resuming pci :02:00.0: resuming PM: Writing back config space on device :02:00.0 at offset 1 (was 100107, writing 100103) pci :03:00.0: resuming yenta_cardbus :15:00.0: resuming ohci1394 :15:00.1: resuming PM: Writing back config space on device :15:00.1 at offset 4 (was 0, writing e4301000) PM: Writing back config space on device :15:00.1 at offset 3 (was 80, writing 804000) PM: Writing back config space on device :15:00.1 at offset 1 (was 210, writing 216) ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[21] MMIO=[e4301000-e43017ff] Max Packet=[2048] IR/IT contexts=[4/4] sdhci :15:00.2: resuming PM: Writing back config space on device :15:00.2 at offset 4 (was 0, writing e4301800) PM: Writing back config space on device :15:00.2 at offset 3 (was 80, writing 804000) PM: Writing back config space on device :15:00.2 at offset 1 (was 210, writing 216) system 00:00: resuming pnp 00:01: resuming system 00:02: resuming pnp 00:03: resuming pnp 00:04: resuming pnp 00:05: resuming pnp 00:06: resuming pnp 00:07: resuming i8042 kbd 00:08: resuming pnp: Device 00:08 does not support activation. i8042 aux 00:09: resuming pnp: Device 00:09 does not support activation. pnp 00:0a: resuming pnp 00:0b: resuming platform bluetooth: resuming pcspkr pcspkr: resuming vesafb vesafb.0: resuming serial8250 serial8250: resuming usb usb1: resuming hub 1-0:1.0: resuming usb usb2: resuming hub 2-0:1.0: resuming usb usb4: resuming ata2: SATA link down (SStatus 0 SControl 0) ata3: SATA link down (SStatus 0 SControl 0) ata4: SATA link down (SStatus 0 SControl 0) usb usb5: resuming hub 4-0:1.0: resuming hub 5-0:1.0: resuming usb usb3: resuming hub 3-0:1.0: resuming i8042 i8042: resuming atkbd serio0: resuming psmouse serio1: resuming mmcblk mmc0:cc53: resuming sd 0:0:0:0: resuming usb 3-2: resuming usbdev3.14_ep00: PM: resume from 0, parent 3-2 still 2 usb 3-2:1.0: PM: resume from 2, parent 3-2 still 2 usb 3-2:1.0: resuming usbdev3.14_ep81: PM: resume from 0, parent 3-2:1.0 still 2
Re: [patch] suspend: fix suspend on single-CPU systems
> Subject: [patch] suspend: fix suspend on single-CPU systems > From: Ingo Molnar <[EMAIL PROTECTED]> > > Clark Williams reported that suspend doesnt work on his laptop on > 2.6.20-rc1-rt kernels. The bug was introduced by the following cleanup > commit: > > commit 112cecb2cc0e7341db92281ba04b26c41bb8146d > Author: Siddha, Suresh B <[EMAIL PROTECTED]> > Date: Wed Dec 6 20:34:31 2006 -0800 > > [PATCH] suspend: don't change cpus_allowed for task initiating the suspend > > because with this change 'error' is not initialized to 0 anymore, if > there are no other online CPUs. (i.e. if the system is single-CPU). > > the fix is the initialize it to 0. The really weird thing is that my > version of gcc does not warn about this non-initialized variable > situation ... > > (also fix the kernel printk in the error branch, it was missing a > newline) > > Reported-by: Clark Williams <[EMAIL PROTECTED]> > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Looks okay to me. -- Thanks, Sharp! - 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/
ext3-related crash in 2.6.20-rc1
Hi! I got this nasty oops while playing with debugger. Not sure if that is related; it also might be something with bluetooth; I already know it corrupts memory during suspend, perhaps it corrupts memory in some error path? Pavel l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) PM: Removing info for bluetooth:acl00803715A329 e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO [ cut here ] kernel BUG at fs/buffer.c:1235! invalid opcode: [#1] SMP Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010046 (2.6.20-rc1 #379) EIP is at __find_get_block+0x1b2/0x1c0 eax: 0086 ebx: 1000 ecx: edx: 006780b2 esi: 0033d60d edi: 1000 ebp: 00cf esp: c9135c90 ds: 007b es: 007b ss: 0068 Process phone (pid: 1161, ti=c9134000 task=f7949030 task.ti=c9134000) Stack: 006780b2 f7ec2820 0003 ad40ad40 f7d8f5ba c0652a48 f88da000 0012 000f f65c9000 f65c9230 c016c9df c016c3c4 1000 0033d60d 1000 00cf c01933ef 1000 5a0ff380 007f f65c9234 Call Trace: [] __getblk+0x1f/0x290 [] __ext3_get_inode_loc+0x120/0x3a0 [] ext3_reserve_inode_write+0x27/0x80 [] ext3_mark_inode_dirty+0x1a/0x40 [] ext3_dirty_inode+0x79/0xb0 [] __mark_inode_dirty+0x34/0x1c0 [] __generic_file_aio_write_nolock+0x244/0x590 [] generic_file_aio_write+0x59/0xd0 [] ext3_file_write+0x30/0xc0 [] do_sync_write+0xc7/0x130 [] vfs_write+0xa6/0x160 [] sys_write+0x41/0x70 [] syscall_call+0x7/0xb [] 0xb7f18d2e === Code: 00 8b 7c 24 18 f3 a5 fb 8b 44 24 10 85 c0 0f 84 2c ff ff ff 8b 44 24 10 e8 5c ca ff ff e9 1e ff ff ff 89 d8 e8 50 ca ff ff eb 8d <0f> 0b eb fe 0f 0b eb fe 0f 0b eb fe 89 f6 55 57 56 53 83 ec 48 EIP: [] __find_get_block+0x1b2/0x1c0 SS:ESP 0068:c9135c90 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ext4-block-reservation.patch
Hi,
> Andrew Morton (AM) writes:
AM> Should be cacheline_aligned_in_smp.
AM> That's assuming it needs to be cacheline aligned at all. It can consume a
AM> lot of space.
the idea is to make block reservation cheap because it's called
for every page.
AM>
AM> oh, this should be allocated with alloc_percpu(), in which case the
AM> open-coded alignment can perhaps go away.
got it.
>> +
>> +int ext4_reserve_local(struct super_block *sb, int blocks)
>> +{
>> + struct ext4_sb_info *sbi = EXT4_SB(sb);
>> + struct ext4_reservation_slot *rs;
>> + int rc = -ENOSPC;
>> +
>> + preempt_disable();
>> + rs = sbi->s_reservation_slots + smp_processor_id();
AM> use get_cpu() here.
ok.
>> +void ext4_rebalance_reservation(struct ext4_reservation_slot *rs, __u64
>> free)
>> +{
>> + int i, used_slots = 0;
>> + __u64 chunk;
>> +
>> + /* let's know what slots have been used */
>> + for (i = 0; i < NR_CPUS; i++)
>> + if (rs[i].rs_reserved || i == smp_processor_id())
>> + used_slots++;
>> +
>> + /* chunk is a number of block every used
>> +* slot will get. make sure it isn't 0 */
>> + chunk = free + used_slots - 1;
>> + do_div(chunk, used_slots);
>> +
>> + for (i = 0; i < NR_CPUS; i++) {
AM> all these NR_CPUS loops need to go away. Use either
AM> for_each_possible_cpu() or, preferably, for_each_online_cpu() and a hotplug
AM> notifier.
hmm, i see.
AM> Why is this code using per-cpu data at all, btw? These optimisations tend
AM> to be marginal in filesystems. What is the perfomance impact of making
AM> this data be single-superblock-wide-instance?
well, even on 2way box a single-lock reservation was in top10.
thanks, Alex
-
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.19-rc1 build problem
On Sat, 23 Dec 2006 14:14:48 -0600 Steve French <[EMAIL PROTECTED]> wrote: > Is this a know problem with very current 2.6.19-rc? > > Building modules, stage 2. > MODPOST 443 modules > WARNING: "bitrev32" [drivers/net/8139cp.ko] undefined! You'll need to set CONFIG_BITREVERSE. Somehow. This is going to cause problems and I suspect we'll end up giving up in horror and just adding it to lib-y. > WARNING: "serio_register_driver" [drivers/input/touchscreen/mtouch.ko] > undefined! serio_register_driver is exported, so we're missing a Kconfig dependency somewhere. MTOUCH selects SERIO, which seems right, so something weird is happening. Please send .config. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
David Schwartz <[EMAIL PROTECTED]> wrote: > > Two of the specific arguments I've heard are (a) that the board (and > > its hardware interfaces that the documentation would describe) involve > > IP licensed from a third party, which the board manufacturer does not > > have a legal right to disclose, > If they can't disclose it, they can't sell it. If they can't sell it, it's > fraud to tell someone that they can buy it. If a contract with a third party > limits your ability to sell something to someone, you have to *tell* *them* > that they do not get all of the rights of ownership because you don't own > some of them and hence can't transfer them. They aren't /selling/ you the rights to the driver, just charging you for its /use/. [...] > > or (b) that there is, in fact, no > > suitable documentation, because the boards are developed somewhat > > fluidly and the driver is developed directly from low-level knowledge > > that simply isn't written down in a form suitable for passing on. > You can't sell something that doesn't exist. If you sell a car even though > you can't explain how anyone could drive it, that's fraud. Nonsense. [...] > > If you're building products with no expectation of supporting outside > > driver developers, both of those are quite possible. > And they're both quite fraudulent. You cannot both sell something and keep > its construction a secret. It is quite regularly done, so this argument won't fly. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ext4-delayed-allocation.patch
On Fri, 22 Dec 2006 23:28:32 +0300 Alex Tomas <[EMAIL PROTECTED]> wrote: > +/* > + * With EXT4_WB_SKIP_SMALL defined the patch will try to avoid > + * small I/Os ignoring ->writepages() if mapping hasn't enough > + * contig. dirty pages > + */ > +#define EXT4_WB_SKIP_SMALL__ > + > +#define WB_ASSERT(__x__) if (!(__x__)) BUG(); This is unused. Please kill. > +#define WB_DEBUG__ > +#ifdef WB_DEBUG > +#define wb_debug(fmt,a...) printk(fmt, ##a); > +#else > +#define wb_debug(fmt,a...) > +#endif It's tiresome for each piece of kernel code to implement private debug macros. Why not use pr_debug()? In general, this patch adds a mountain of code which I suspect just shouldn't be in a filesystem. It should be library code in mm/ or fs/. It'll take some thought and refactoring and definition of new address_space_operations entries, etc. But burying all this inside a single filesystem is just The Wrong Thing To Do. I am not inclined to review the code in detail because the lack of suitable code comments would make that task much larger and significantly less useful than it should be. Please spend a day or so commenting the code in a similar manner to other parts of ext4 and jbd2. When doing so, put yourself in the position of an experienced kernel developer who seeks to understand what the code is doing and why it is doing it. Skilful commenting is essential if the code is to be maintainable and it has an immediate impact upon the code's quality. Every non-trivial function should have an introductory comment which tells the reader why this function exists, what it does and, if not obvious, how it does it. Don't bother with kernel-doc comments - for some reason they tend to be useless for code conprehension. I shouldn't need to sit here scratching my head and wondering why the heck a writepages function is running __set_page_dirty_nobuffers(). Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc1 build problem
On Sat, 23 Dec 2006 14:14:48 -0600 Steve French wrote: > Is this a know problem with very current 2.6.19-rc? Do you mean 2.6.20-rc1? > Building modules, stage 2. > MODPOST 443 modules > WARNING: "bitrev32" [drivers/net/8139cp.ko] undefined! > WARNING: "serio_register_driver" [drivers/input/touchscreen/mtouch.ko] > undefined! > (repeated many times) I haven't seen it. Got .config? --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ext4-block-reservation.patch
On Fri, 22 Dec 2006 23:25:16 +0300
Alex Tomas <[EMAIL PROTECTED]> wrote:
Once this code is settled in we should consider removal of the existing
reservations code from ext4.
> +
> +struct ext4_reservation_slot {
> + __u64 rs_reserved;
> + spinlock_t rs_lock;
> +} cacheline_aligned;
Should be cacheline_aligned_in_smp.
That's assuming it needs to be cacheline aligned at all. It can consume a
lot of space.
oh, this should be allocated with alloc_percpu(), in which case the
open-coded alignment can perhaps go away.
> +
> +int ext4_reserve_local(struct super_block *sb, int blocks)
> +{
> + struct ext4_sb_info *sbi = EXT4_SB(sb);
> + struct ext4_reservation_slot *rs;
> + int rc = -ENOSPC;
> +
> + preempt_disable();
> + rs = sbi->s_reservation_slots + smp_processor_id();
use get_cpu() here.
> +void ext4_rebalance_reservation(struct ext4_reservation_slot *rs, __u64 free)
> +{
> + int i, used_slots = 0;
> + __u64 chunk;
> +
> + /* let's know what slots have been used */
> + for (i = 0; i < NR_CPUS; i++)
> + if (rs[i].rs_reserved || i == smp_processor_id())
> + used_slots++;
> +
> + /* chunk is a number of block every used
> + * slot will get. make sure it isn't 0 */
> + chunk = free + used_slots - 1;
> + do_div(chunk, used_slots);
> +
> + for (i = 0; i < NR_CPUS; i++) {
all these NR_CPUS loops need to go away. Use either
for_each_possible_cpu() or, preferably, for_each_online_cpu() and a hotplug
notifier.
Why is this code using per-cpu data at all, btw? These optimisations tend
to be marginal in filesystems. What is the perfomance impact of making
this data be single-superblock-wide-instance?
> +int ext4_reserve_init(struct super_block *sb)
> +{
> + struct ext4_sb_info *sbi = EXT4_SB(sb);
> + struct ext4_reservation_slot *rs;
> + int i;
> +
> + rs = kmalloc(sizeof(struct ext4_reservation_slot) * NR_CPUS,
> GFP_KERNEL);
alloc_percpu()
-
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/
Linux 2.4.34 released
Hi ! I finally managed to update my release scripts to safely produce a final release, so I have released a 2.4.34 identical to -rc4, which added just a security fix to -rc3. Complete changelog appended. I've also released 2.4.33.7 with the same fix for those still tracking 2.4.33.x. Depending on the load on the servers here, it might take some time before 2.4.34 shows up on www.kernel.org. Also, _please_ only use www2.kernel.org, which is less loaded than www1. For those who did not track the pre-releases, 2.4.34 brings the usual bunch of security fixes, bugfixes, and adds support for gcc 4 to x86, x86-64 and sparc64, thanks to Mikael Pettersson's work. What I did not expect first is that it seems to ease the maintenance job for some subsystem maintainers who mostly work on 2.6 right now. One user reported regular panics with aacraid since 2.4.32, so there's no regression here. I will seek for some help to get this fixed in 2.4.35. I also get reports of people getting trapped by NIC vendors who suddenly change their ethernet chips with no big warning notice. The i82546GB chip which replaced the i82546EB in e1000 cards come to mind. It is not supported by the driver in 2.4.34 but I will try to solve this in 2.4.35 (right now, you have to download the vendor's drivers when you replace a NIC). Another driver should get some lifting : skge. I have got a few reports of problems with the vendor's sk98lin driver and I noticed the same problems at work (UDP becoming silent on NFS server). I already have adapted Stephen Hemminger's backport for a merge, and it seems to work correctly on my personal kernels. Stephen kindly offered to help me get this driver in sync with 2.6, which will fix problems for people who previously had problems with the vendor's driver, and it will ease further maintenance. I also received a request to merge the gcc 4 fixes for mips, but the patch came as a big chunk. I might consider reviewing it later when I have time. I should also merge most of the typo fixes that Mariusz Kozlowski sent me. Concerning the 2.4.X.Y tree, as Greg recommended to me, I will create a different git repository for 2.4.34.Y, and will probably do a little cleanup in the existing branches. It will be easier to release stable kernels that way. I don't think I will still provide 2.4.33.Y trees, unless it does not take me more time and there is real and justified demand. Last but not least, a really big thanks to Grant Coady who saves me some CPU (and human) time by building and testing all the pre-releases on several machines, and who then puts the results online. Best regards, Willy complete 2.4.33 - 2.4.34 changelog --- final: - v2.4.34-rc4 was released as 2.4.34 with no changes. Summary of changes from v2.4.34-rc3 to v2.4.34-rc4 Marcel Holtmann (1): Call init_timer() for ISDN PPP CCP reset state timer (CVE-2006-5749) Willy Tarreau (1): Change VERSION to 2.4.34-rc4 Summary of changes from v2.4.34-rc2 to v2.4.34-rc3 Hugh Dickins (1): zeromap may find a pte Linus Torvalds (1): Fix incorrect user space access locking in mincore() (CVE-2006-4814) Willy Tarreau (1): Change VERSION to 2.4.34-rc3 Summary of changes from v2.4.34-rc1 to v2.4.34-rc2 Marcel Holtmann (1): [Bluetooth] Add packet size checks for CAPI messages (CVE-2006-6106) Willy Tarreau (1): Change VERSION to 2.4.34-rc2 Summary of changes from v2.4.34-pre6 to v2.4.34-rc1 dann frazier (1): smbfs : don't ignore uid/gid/mode mount opts w/ unix extensions Jean Delvare (6): i2c cleanup : typos and whitespace i2c cleanup : dead code removal i2c cleanup : c99 struct init i2c cleanup : simplify code i2c cleanup : resync algo ids i2c cleanup : warning fix Oliver Neukum (2): fix for transient error in usb printer driver task stte leak in pegasus usb driver Ralf Baechle (1): Masking bug in 6pack driver Shaohua Li (1): x86 microcode: dont check the size Willy Tarreau (8): rio: typo in bitwise AND expression. flashpoint: use '!' instead of '~' with EE_SYNC_MASK jfs: incorrect use of "&&" instead of "&" arm: incorrect use of "&&" instead of "&" e100: incorrect use of "&&" instead of "&" ps2esdi: typo may cause premature timeout fbcon: incorrect use of "&&" instead of "&" Change VERSION to 2.4.34-rc1 Summary of changes from v2.4.34-pre5 to v2.4.34-pre6 Jean Delvare (5): [PATCH][I2C] update web site address and contacts [PATCH][I2C] do not ignore error when returning from i2c_add_adapter() [PATCH][I2C] i2c-matroxfb: Struct init conversion [PATCH][I2C] Fix copy-n-paste error in i2c Config.in. [PATCH][I2C] remove non-existing functions
Re: xt_request_find_match
On Dec 20 2006 10:17, Patrick McHardy wrote: >Jan Engelhardt wrote: >>>Make sure the user specifies the match on the command line before >>>your match. Look at the TCPMSS or REJECT targets for examples for >>>this. >> >> That would mean I'd have to >> >> -p tcp -m multiport --dport 1,2,3,4 -m time --time sundays -m >> lotsofothers -j TARGET >> -p udp -m multiport --dport 1,2,3,4 -m time --time sundays -m >> lotsofothers -j TARGET > >I don't see any match that would depend on an other match in >your example. How about your start explaining what you would >like to do, ideally with some code. Yup, on the spot! http://jengelh.hopto.org/f/chaostables/chaostables-0.1.tar.bz2 (Contains a target, but still something that could use xt_request_find_module.) -`J' -- - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sat 2006-12-23 12:24:29, Adrian Bunk wrote: > On Thu, Dec 21, 2006 at 03:38:29PM +, Pavel Machek wrote: > > On Thu 14-12-06 20:51:36, Adrian Bunk wrote: > > > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote: > > > > On Thu, Dec 14, 2006 at 04:33:47PM +, Alan wrote: > > > > > > The trick is to let a lawyer send cease and desist letters to > > > > > > people > > > > > > distributing the infringing software for 1 Euro at Ebay. > > > > > > > > > > Doesn't that sound even more like the music industry ? Pick on > > > > > Grandma, > > > > > and people who've no clue about the issue. It's not the way to solve > > > > > such > > > > > problems. The world does not need "The war on binary modules". Educate > > > > > people instead, and talk to vendors. > > > > > > > > or like Microsoft, who is threatening to make war on end-users > > > > instead of settling things with vendors. (One of the reasons why I > > > > personally find the Microsoft promise not to sue _Novell_'s end users > > > > so nasty. Microsoft shouldn't be threatening anyone's users; if they > > > > have a problem, they should be taking it up with the relevant vendor, > > > > not sueing innocent and relatively shallow-pocketed end-users and > > > > distributors.) > > > > > > > > One of the things that I find so interesting about how rabid people > > > > get about enforcing GPL-only modules is how they start acting more and > > > > more like the RIAA, MPAA, and Microsoft every day > > > > > > Please don't think or imply I'd plan to do this, I'm only saying that > > > there's a risk for users in such grey areas. > > > > > > It could be that someone who wants to harm Linux starts suing people > > > distributing Linux. If your goal is to harm Linux, suing users can > > > simply be much more effective than suing vendors... > > > > > > It could even be that people distributing Linux could receive cease and > > > desist letters from people without any real interest in the issue > > > itself - "cease and desist letter"s are so frequent in Germany because > > > the people who have to sign them have to pay the lawyers' costs that are > > > usually > 1000 Euro, and that's a good business for the lawyers. > > > > Something is very wrong with German legal system, I'm afraid. > > The point that you can take legal actions against anyone distributing > something that violates your rights should be present in more or less > all legal systems. > > What might be special in Germany is only that you can demand your costs > after successfully taking legal actions. What is special in Germany is fact that any random lawyer can demand $1000 (not his cost, his profit) if you distribute code that is not his... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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.20-rc1 5/6] SA1100 GPIO wrappers
On Saturday 23 December 2006 3:37 am, Russell King wrote: > Why do we need to convert between IRQ and PGIO numbers? (I take it that's the only real issue you had with this patch, other than maybe excessive #includes?) I suppose we could do with a one way mapping: GPIO-to-IRQ, then require drivers map the other way themselves when they need to. As they must do with DMA addresses. Having that GPIO-to-IRQ mapping is quite routine; and necessary. On the other hand, since it's a (small) one-to-one mapping, I don't see any real issue with defining how to access it in both directions. I can tell one direction (IRQ-to-GPIO) bothers you ... but not why. > When the interrupt system is asked to claim a IRQ corresponding to a > GPIO, it should deal with all the stuff necessary to ensure that the > GPIO is in the required state. IRQ framework can't do "all" the needed stuff on platforms (like OMAP1) where knowing the GPIO (presumably from a private IRQ-to-GPIO mapping??) doesn't tell you what pin to set up, or how. Such setup needs to be in place *before* request_irq() is called. The genirq irqchip.startup() call could potentially sanity check whether a GPIO is configured as an input, but couldn't handle pin muxing or pullup/pulldown config; and I'd argue it shouldn't try to change anyt of that, since it's an API for managing IRQs not for pin configuration. > are we expecting to add GPIO > support to all Linux drivers which could possibly be used on ARM, just > because their interrupt pin might possibly be connected to a GPIO? I'd expect board-specific setup code to pass gpio_to_irq(gpio_num) to drivers when the _only_ thing that matters is its IRQ-ness. And to have previousy set up the relevant pin as a GPIO input ... so that most drivers would just see an IRQ, much like any other irq. That's what most of them do now, I didn't propose changing any part of that except defining a standard way to write the GPIO-to-IRQ mapping. The overall goal is basically to let drivers which know they've got a GPIO have a standard way to use it ... in the previous situation, the lack of such a portable API means those drivers must be (needlessly) platform-specific. > This is NOT > something that drivers should even care about - it's something that the > interrupt subsystem should know when being asked to claim an GPIO-based > IRQ. It's admittedly uncommon that drivers care about IRQ-to-GPIO, but it's not a "never" thing. Drivers often need to care more about the exact state of the signal than "IRQ triggered a while back"; and that means some kind of IRQ-to-GPIO mapping. Examples: systems that only have "both edges" triggering, where the hardware signal is level triggered; or the supported triggering modes are otherwise not a good match for an external chip. State when the driver starts up may need to check signal level directly, when the IRQ must use edge triggering. Also, disabling an IRQ at the source (vs. unsharably masking it in the local IRQ controller) can sometimes take much of a millisecond because of I2C or similar delays, making it likely that signal state changed since the irq triggered. Oh, and the reverse mapping could also be useful for diagnostics. > Get real - if you're dealing with IRQs use _only_ IRQ numbers. Don't > even think that drivers should be able to convert between IRQ and GPIO > numbers. I was being real, and I gave some examples above where drivers need to be able to detect the actual signal level. On the other hand it'd also be practical to force drivers to do that mapping from IRQ (they probably only handle a few!) to GPIO, when they need to do that, if they're given a GPIO number directly. Then they'd just use the GPIO-to-IRQ mapping to request the IRQ (already a common idiom) and directly access the gpio state. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] containers: BeanCounters over generic process containers
On Fri, Dec 22, 2006 at 06:14:48AM -0800, Paul Menage wrote:
> This patch implements the BeanCounter resource control abstraction
> over generic process containers. It contains the beancounter core
> code, plus the numfiles resource counter. It doesn't currently contain
> any of the memory tracking code or the code for switching beancounter
> context in interrupts.
I don't like it, it looks bloated and probably
adds plenty of overhead (similar to the OVZ
implementation where this seems to be taken from)
here are some comments/questions:
> Currently all the beancounters resource counters are lumped into a
> single hierarchy; ideally it would be possible for each resource
> counter to be a separate container subsystem, allowing them to be
> connected to different hierarchies.
>
> +static inline void bc_uncharge(struct beancounter *bc, int res_id,
> + unsigned long val)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(>bc_lock, flags);
> + bc_uncharge_locked(bc, res_id, val);
> + spin_unlock_irqrestore(>bc_lock, flags);
why use a spinlock, when we could use atomic
counters?
> +int bc_charge_locked(struct beancounter *bc, int res, unsigned long val,
> + int strict, unsigned long flags)
> +{
> + struct bc_resource_parm *parm;
> + unsigned long new_held;
> +
> + BUG_ON(val > BC_MAXVALUE);
> +
> + parm = >bc_parms[res];
> + new_held = parm->held + val;
> +
> + switch (strict) {
> + case BC_LIMIT:
> + if (new_held > parm->limit)
> + break;
> + /* fallthrough */
> + case BC_BARRIER:
> + if (new_held > parm->barrier) {
> + if (strict == BC_BARRIER)
> + break;
> + if (parm->held < parm->barrier &&
> + bc_resources[res]->bcr_barrier_hit)
> + bc_resources[res]->bcr_barrier_hit(bc);
> + }
why do barrier checks with every accounting?
there are probably a few cases where the
checks could be independant from the accounting
> + /* fallthrough */
> + case BC_FORCE:
> + parm->held = new_held;
> + bc_adjust_maxheld(parm);
in what cases do we want to cross the barrier?
> + return 0;
> + default:
> + BUG();
> + }
> +
> + if (bc_resources[res]->bcr_limit_hit)
> + return bc_resources[res]->bcr_limit_hit(bc, val, flags);
> +
> + parm->failcnt++;
> + return -ENOMEM;
> +int bc_file_charge(struct file *file)
> +{
> + int sev;
> + struct beancounter *bc;
> +
> + task_lock(current);
why do we lock current? it won't go away that
easily, and for switching the bc, it might be
better to use RCU or a separate lock, no?
> + bc = task_bc(current);
> + css_get_current(>css);
> + task_unlock(current);
> +
> + sev = (capable(CAP_SYS_ADMIN) ? BC_LIMIT : BC_BARRIER);
> +
> + if (bc_charge(bc, BC_NUMFILES, 1, sev)) {
> + css_put(>css);
> + return -EMFILE;
> + }
> +
> + file->f_bc = bc;
> + return 0;
> +}
also note that certain limits are much more
complicated than the (very simple) file limits
and the code will be called at higher frequency
how to handle requests like:
try to get as 64 files or as many as available
whatever is smaller
happy xmas,
Herbert
-
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.19-rc1 build problem
Is this a know problem with very current 2.6.19-rc? Building modules, stage 2. MODPOST 443 modules WARNING: "bitrev32" [drivers/net/8139cp.ko] undefined! WARNING: "serio_register_driver" [drivers/input/touchscreen/mtouch.ko] undefined! (repeated many times) - 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: WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
On Sat, 23 Dec 2006, Randy Dunlap wrote:
>
> BTW, reiserfs has similar build problems: it uses clear_page_dirty()
> so it won't build.
Not any more. I fixed that one (very different issue, btw: it's not
actually doign writeout, it actually wanted to cancel IO on truncated
buffers.
However, it's certainly possible that my fix hasn't mirrored out yet, I
pushed it just a couple of hours ago. So if you want to test it, here are
the two commits in question..
(The "cancel_dirty_page()" cleanup is needed not just to do reiserfs as a
module, it's also to make it more robust against reiserfs possibly feeding
that function with strange pages, and to match the other related functions
in the accounting functions).
Len Brown tested the reiserfs changes, and claims that it was all good,
but if somebody wants to run fsx-linux or some other filesystem stress
testing tool that actually tests shared mmap (and truncate), that would be
really appreciated.
Linus
--
commit 8368e328dfe1c534957051333a87b3210a12743b
Author: Linus Torvalds <[EMAIL PROTECTED]>
Date: Sat Dec 23 09:25:04 2006 -0800
Clean up and export cancel_dirty_page() to modules
Make cancel_dirty_page() act more like all the other dirty and writeback
accounting functions: test for "mapping" being NULL, and do the
NR_FILE_DIRY accounting purely based on mapping_cap_account_dirty()).
Also, add it to the exports, so that modular filesystems can use it.
Acked-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
mm/truncate.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/mm/truncate.c b/mm/truncate.c
index 4a38dd1..ecdfdcc 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -60,12 +60,16 @@ void cancel_dirty_page(struct page *page, unsigned int
account_size)
WARN_ON(++warncount < 5);
}
- if (TestClearPageDirty(page) && account_size &&
- mapping_cap_account_dirty(page->mapping)) {
- dec_zone_page_state(page, NR_FILE_DIRTY);
- task_io_account_cancelled_write(account_size);
+ if (TestClearPageDirty(page)) {
+ struct address_space *mapping = page->mapping;
+ if (mapping && mapping_cap_account_dirty(mapping)) {
+ dec_zone_page_state(page, NR_FILE_DIRTY);
+ if (account_size)
+ task_io_account_cancelled_write(account_size);
+ }
}
}
+EXPORT_SYMBOL(cancel_dirty_page);
/*
* If truncate cannot remove the fs-private metadata from the page, the page
commit ffaa82008f1aad52a6d3979f49d2a76c2928b60f
Author: Linus Torvalds <[EMAIL PROTECTED]>
Date: Sat Dec 23 09:32:45 2006 -0800
Fix reiserfs after "test_clear_page_dirty()" removal
Thanks to Len Brown for testing this fix, since while they have in the
past, none of my machines run reiserfs at the moment.
Cc: Vladimir V. Saveliev <[EMAIL PROTECTED]>
Acked-by: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
fs/reiserfs/stree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c
index 47e7027..afb21ea 100644
--- a/fs/reiserfs/stree.c
+++ b/fs/reiserfs/stree.c
@@ -1459,7 +1459,7 @@ static void unmap_buffers(struct page *page, loff_t pos)
bh = next;
} while (bh != head);
if (PAGE_SIZE == bh->b_size) {
- clear_page_dirty(page);
+ cancel_dirty_page(page, PAGE_CACHE_SIZE);
}
}
}
-
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: omap compilation fixes
Hi, * Pavel Machek <[EMAIL PROTECTED]> [061222 13:49]: > Hi! > > > > This is not yet complete set. set_map() is missing in latest kernels. > > > > > > Fix DECLARE_WORK()-change-related compilation problems. Please apply, > > > > > > --- a/drivers/mmc/omap.c > > > +++ b/drivers/mmc/omap.c > > > @@ -2,7 +2,7 @@ > > > * linux/drivers/media/mmc/omap.c > > > * > > > * Copyright (C) 2004 Nokia Corporation > > > - * Written by Tuukka Tikkanen and Juha Yrjölä<[EMAIL PROTECTED]> > > > + * Written by Tuukka Tikkanen and Juha Yrjölä <[EMAIL PROTECTED]> > > > * Misc hacks here and there by Tony Lindgren <[EMAIL PROTECTED]> > > > * Other hacks (DMA, SD, etc) by David Brownell > > > * > > > > I already applied similar fixes to linux-omap for the workqueue changes, > > so I only applied the MMC typo fix above. > > I thought I got pretty recent -git: > > omap git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git > > ...should I use another tree? > > Aha, I did another pull now and it seems to be better... no, it is > not: > > Recovering from a previously interrupted fetch... > Fetching pack (head and objects)... > Fetching tags... > Missing tag v2.6.20-rc1... > Generating pack... > Done counting 1 objects. > Deltifying 1 objects. > 100% (1/1) done > Total 1, written 1 (delta 0), reused 1 (delta 0) > Unpacking 1 objects > 100% (1/1) done > Up to date. > > Applying changes... > Branch already fully merged. > > Plus it still does not compile: > > LD vmlinux > arch/arm/plat-omap/built-in.o(.text+0xd470): In function > `exmap_set_armmmu': > : undefined reference to `set_pte' > arch/arm/plat-omap/built-in.o(.text+0xd56c): In function > `exmap_set_armmmu': > : undefined reference to `set_pte' > make: *** [vmlinux] Error 1 Is this still a problem? Sounds like the latest tree was not yet mirrored from master.kernel.org when you pulled. Regards, Tony - 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/1] Char: isicom, eliminate spinlock recursion
isicom, eliminate spinlock recursion
Many spinlock recursion was in the isicom driver. Eliminate it.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 59988b8c2d1ce45e5ccb715ac7ece78dfb73545a
tree d6060769defd71c77ffa340d579f95e24b783ebf
parent fe13ee556f3b973a3b27f154db9852766634d0d6
author Jiri Slaby <[EMAIL PROTECTED]> Sat, 23 Dec 2006 20:43:42 +0059
committer Jiri Slaby <[EMAIL PROTECTED]> Sat, 23 Dec 2006 20:43:42 +0059
drivers/char/isicom.c | 103 -
1 files changed, 51 insertions(+), 52 deletions(-)
diff --git a/drivers/char/isicom.c b/drivers/char/isicom.c
index 0362740..26d3f78 100644
--- a/drivers/char/isicom.c
+++ b/drivers/char/isicom.c
@@ -228,6 +228,20 @@ static struct isi_port isi_ports[PORT_COUNT];
* it wants to talk.
*/
+static inline int WaitTillCardIsFree(u16 base)
+{
+ unsigned int count = 0;
+ unsigned int a = in_atomic(); /* do we run under spinlock? */
+
+ while (!(inw(base + 0xe) & 0x1) && count++ < 100)
+ if (a)
+ mdelay(1);
+ else
+ msleep(1);
+
+ return !(inw(base + 0xe) & 0x1);
+}
+
static int lock_card(struct isi_board *card)
{
charretries;
@@ -274,69 +288,71 @@ static void unlock_card(struct isi_board *card)
* ISI Card specific ops ...
*/
+/* card->lock HAS to be held */
static void raise_dtr(struct isi_port *port)
{
struct isi_board *card = port->card;
unsigned long base = card->base;
u16 channel = port->channel;
- if (!lock_card(card))
+ if (WaitTillCardIsFree(base))
return;
outw(0x8000 | (channel << card->shift_count) | 0x02, base);
outw(0x0504, base);
InterruptTheCard(base);
port->status |= ISI_DTR;
- unlock_card(card);
}
+/* card->lock HAS to be held */
static inline void drop_dtr(struct isi_port *port)
{
struct isi_board *card = port->card;
unsigned long base = card->base;
u16 channel = port->channel;
- if (!lock_card(card))
+ if (WaitTillCardIsFree(base))
return;
outw(0x8000 | (channel << card->shift_count) | 0x02, base);
outw(0x0404, base);
InterruptTheCard(base);
port->status &= ~ISI_DTR;
- unlock_card(card);
}
+/* card->lock HAS to be held */
static inline void raise_rts(struct isi_port *port)
{
struct isi_board *card = port->card;
unsigned long base = card->base;
u16 channel = port->channel;
- if (!lock_card(card))
+ if (WaitTillCardIsFree(base))
return;
outw(0x8000 | (channel << card->shift_count) | 0x02, base);
outw(0x0a04, base);
InterruptTheCard(base);
port->status |= ISI_RTS;
- unlock_card(card);
}
+
+/* card->lock HAS to be held */
static inline void drop_rts(struct isi_port *port)
{
struct isi_board *card = port->card;
unsigned long base = card->base;
u16 channel = port->channel;
- if (!lock_card(card))
+ if (WaitTillCardIsFree(base))
return;
outw(0x8000 | (channel << card->shift_count) | 0x02, base);
outw(0x0804, base);
InterruptTheCard(base);
port->status &= ~ISI_RTS;
- unlock_card(card);
}
+/* card->lock MUST NOT be held */
static inline void raise_dtr_rts(struct isi_port *port)
{
struct isi_board *card = port->card;
@@ -353,35 +369,20 @@ static inline void raise_dtr_rts(struct isi_port *port)
unlock_card(card);
}
+/* card->lock HAS to be held */
static void drop_dtr_rts(struct isi_port *port)
{
struct isi_board *card = port->card;
unsigned long base = card->base;
u16 channel = port->channel;
- if (!lock_card(card))
+ if (WaitTillCardIsFree(base))
return;
outw(0x8000 | (channel << card->shift_count) | 0x02, base);
outw(0x0c04, base);
InterruptTheCard(base);
port->status &= ~(ISI_RTS | ISI_DTR);
- unlock_card(card);
-}
-
-static inline void kill_queue(struct isi_port *port, short queue)
-{
- struct isi_board *card = port->card;
- unsigned long base = card->base;
- u16 channel = port->channel;
-
- if (!lock_card(card))
- return;
-
- outw(0x8000 | (channel << card->shift_count) | 0x02, base);
- outw((queue << 8) | 0x06, base);
- InterruptTheCard(base);
- unlock_card(card);
}
/*
@@ -727,7 +728,7 @@ static void isicom_config_port(struct isi_port *port)
else
raise_dtr(port);
- if (lock_card(card)) {
+ if (WaitTillCardIsFree(base) == 0) {
outw(0x8000 | (channel << shift_count) |0x03, base);
outw(linuxb_to_isib[baud] << 8 | 0x03, base);
channel_setup = 0;
@@ -755,7 +756,6 @@ static void isicom_config_port(struct
Re: WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
On Sat, 23 Dec 2006 10:30:40 -0800 (PST) Linus Torvalds wrote: > > [ Andrew - I'm cc'ing you, because you caused the requirement that people > use "set_page_writeback()" in their writepage() routine that CIFS seems > to have been ignoring all these years. That was introduced more than > two years ago, back in April 11, 2004: > > [PATCH] fdatasync integrity fix > > fdatasync can fail to wait on some pages due to a race. > ... > > and as far as I can see, ever since then, any filesystem that didn't do > a "set_page_writeback()" to sync up the TAG_DIRTY bit would have this > CPU usage problem. Please double-check whether I'm right or barking up > the wrong tree. > > Afaik, the lack of doing the page writeback bit handling properly would > seem to not cause any actual visible _semantic_ problems, it would just > cause fdatasync to not necessarily be entirely reliable (which I guess > is semantic, but very hard to see) and just wasted CPU cycles when we > look up pages that are marked dirty in the radix tree, but aren't > actually really dirty. > > Correct? Who else is implicated in all of this? ] > > On Fri, 22 Dec 2006, Linus Torvalds wrote: > > > > CIFS _should_ be using "clear_page_dirty_for_io()" in that place, and that > > will fix the build. However, the reason I didn't just do that myself is > > that I can't test the end result, and for the life of me, I can't see > > where CIFS does the "end_page_writeback()" that it needs to do at IO > > completion time. > > Ok, I spent some more time looking at this. > > The reason cifs didn't do an "end_page_writeback()" was that it didn't > even do the "set_page_writeback()" to mark the page under writeback in the > first place. > > Now, you might think that since it didn't do a set_page_writeback(), it > doesn't need to do the matching end_page_writeback() at all, and instead > just continue to use the old (_really_ old) way of just unlocking the page > when it is done. > > However, you'd be wrong. The thing is, a "writepage()" function will be > called with the dirty bit cleared in the "struct page *", but the mapping > radix trees will still have the dirty bit set, exactly because the VM > _requires_ the filesystem to tell it what the h*ll it is doing with the > page. So a low-level filesystem must always do one of two things in it's > "writepage()" function. Either: > > - "set_page_writeback()" (and then an "end_page_writeback()" when >finished, of course) > > OR > > - "redirty_page_for_writepage()" to tell the VM to move the page to the >back of the LRU queues because it can't be cleaned (eg, some temporary >problem with write ordering or similar, or something fundamental like >"I'm ramfs, and I don't _have_ any backing store"). > > and if the low-level filesystem doesn't do either of those, then the > status bits in the radix tree that contains the mapping information will > never be updated, so the page that got cleaned will continue to be marked > "dirty" in the radix tree (which admittedly will generally be invisible, > except for "sync()" and friends spending inordinate amounts of time > looking at pages that aren't even dirty any more - since they look things > up by the radix tree tags). > > So I think the old code happened to work, but it was definitely incorrect, > and would leave the dirty tags in the radix tree very confused indeed (it > so happened that "cifs_writepages()" - with an "s" at the end - because it > used "test_clear_page_dirty()" - would also clear the dirty tag, but any > page that went through the generic VM routines and the single-page > "cifs_writepage()" - without an "s" at the end - would then be forever > marked dirty in the radix tree even though it was clean. > > Somebody should check me, though. > > This fairly mindless patch adds the proper "set_page_writeback()" calls > (and the "clear_page_writeback()" ones I had already added before I looked > more closely at this). > > I added a comment in "cifs_writepage()" (the single-page case) for why > this all is the case, BTW, reiserfs has similar build problems: it uses clear_page_dirty() so it won't build. fs/built-in.o: In function `reiserfs_cut_from_item': (.text.reiserfs_cut_from_item+0x868): undefined reference to `clear_page_dirty' --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] delayed allocation for ext4
> Christoph Hellwig (CH) writes: CH> Note that recording delayed alloc state at a page granularity in addition CH> to just the buffer heads has a lot of advantages aswell and would help CH> xfs, too. But I think it makes a lot more sense to record it as a radix CH> tree tag to speed up the gang lookups for delalloc conversion. please, exaplein about radix tree tag. in ext4-delalloc I use this bit the only way - to avoid multiple reservation space for same page. I guess you need to find non-allocated pages. probably to flush them and update number of reserved blocks in case of -ENOSPC? thanks, Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] delayed allocation for ext4
Good day, > David Chinner (DC) writes: DC> So that mean's we'll have 2 separate mechanisms for marking DC> pages as delalloc. XFS uses the BH_delay flag to indicate DC> that a buffer (block) attached to the page is using delalloc. well, for blocksize=pagesize we can save 56 bytes on every page. DC> FWIW, how does this mechanism deal with block size < page size? DC> Don't you have to track delalloc on a block basis rather than DC> a page basis? I'm still thinking how better to deal with that w/o much code duplication. DC> Ah, that's why you can get away with a page flag - you've ignored DC> the partial page delay state problem. Any plans to use the DC> existing method in the future so we will be able to use ext4 delalloc DC> on machines with a page size larger than 4k? what do you mean by "exsiting"? BH_delay? thanks, Alex - 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: WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
[ Andrew - I'm cc'ing you, because you caused the requirement that people use "set_page_writeback()" in their writepage() routine that CIFS seems to have been ignoring all these years. That was introduced more than two years ago, back in April 11, 2004: [PATCH] fdatasync integrity fix fdatasync can fail to wait on some pages due to a race. ... and as far as I can see, ever since then, any filesystem that didn't do a "set_page_writeback()" to sync up the TAG_DIRTY bit would have this CPU usage problem. Please double-check whether I'm right or barking up the wrong tree. Afaik, the lack of doing the page writeback bit handling properly would seem to not cause any actual visible _semantic_ problems, it would just cause fdatasync to not necessarily be entirely reliable (which I guess is semantic, but very hard to see) and just wasted CPU cycles when we look up pages that are marked dirty in the radix tree, but aren't actually really dirty. Correct? Who else is implicated in all of this? ] On Fri, 22 Dec 2006, Linus Torvalds wrote: > > CIFS _should_ be using "clear_page_dirty_for_io()" in that place, and that > will fix the build. However, the reason I didn't just do that myself is > that I can't test the end result, and for the life of me, I can't see > where CIFS does the "end_page_writeback()" that it needs to do at IO > completion time. Ok, I spent some more time looking at this. The reason cifs didn't do an "end_page_writeback()" was that it didn't even do the "set_page_writeback()" to mark the page under writeback in the first place. Now, you might think that since it didn't do a set_page_writeback(), it doesn't need to do the matching end_page_writeback() at all, and instead just continue to use the old (_really_ old) way of just unlocking the page when it is done. However, you'd be wrong. The thing is, a "writepage()" function will be called with the dirty bit cleared in the "struct page *", but the mapping radix trees will still have the dirty bit set, exactly because the VM _requires_ the filesystem to tell it what the h*ll it is doing with the page. So a low-level filesystem must always do one of two things in it's "writepage()" function. Either: - "set_page_writeback()" (and then an "end_page_writeback()" when finished, of course) OR - "redirty_page_for_writepage()" to tell the VM to move the page to the back of the LRU queues because it can't be cleaned (eg, some temporary problem with write ordering or similar, or something fundamental like "I'm ramfs, and I don't _have_ any backing store"). and if the low-level filesystem doesn't do either of those, then the status bits in the radix tree that contains the mapping information will never be updated, so the page that got cleaned will continue to be marked "dirty" in the radix tree (which admittedly will generally be invisible, except for "sync()" and friends spending inordinate amounts of time looking at pages that aren't even dirty any more - since they look things up by the radix tree tags). So I think the old code happened to work, but it was definitely incorrect, and would leave the dirty tags in the radix tree very confused indeed (it so happened that "cifs_writepages()" - with an "s" at the end - because it used "test_clear_page_dirty()" - would also clear the dirty tag, but any page that went through the generic VM routines and the single-page "cifs_writepage()" - without an "s" at the end - would then be forever marked dirty in the radix tree even though it was clean. Somebody should check me, though. This fairly mindless patch adds the proper "set_page_writeback()" calls (and the "clear_page_writeback()" ones I had already added before I looked more closely at this). I added a comment in "cifs_writepage()" (the single-page case) for why this all is the case, Linus PS. To clarify: the old "test_clear_page_dirty()" would actually clear the dirty bit in the radix tree too, so in that sense it was the RIGHT thing to do for CIFS, since CIFS was mostly unaware of the need to clear the radix tree dirty bit (even if cifs_writepages() actually used that bit to look up pages). HOWEVER, since CIFS is called from the generic routines (which _are_ radix-tree-aware and need the bit to be cleared explicitly), even the old code was actually totally broken. It would clear - largely by mistake - the radix tree dirty bit only for one case, not for _all_ the cases. A filesystem really does need to know about these things now, although a lot of filesystems can ignore them, since if they use all the generic routines, they generic routines will handle it all for them. --- diff --git a/fs/cifs/file.c b/fs/cifs/file.c index 0f05cab..8a49b2e 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -1245,14 +1245,21 @@ retry: wait_on_page_writeback(page);
Re: Binary Drivers
David Schwartz <[EMAIL PROTECTED]> wrote: [...] > Honestly, I think it *is* wrong to sell someone a physical product and then > not tell them how to make it work. Right. And the driver *is* the "information to make it work", in a convenient package. [...] > How would you feel if you bought a car and then discovered that the > manufacturer had welded the hood shut? How many people still do their own > oil changes anyway? If people don't do this, what sense does it make to tell them how to do it anyway? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: [take29 0/8] kevent: Generic event handling mechanism.
On Sat, Dec 23, 2006 at 07:51:40PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: > > Generic event handling mechanism. > > Kevent is a generic subsytem which allows to handle event notifications. > It supports both level and edge triggered events. It is similar to > poll/epoll in some cases, but it is more scalable, it is faster and > allows to work with essentially eny kind of events. > > Events are provided into kernel through control syscall and can be read > back through ring buffer or using usual syscalls. > Kevent update (i.e. readiness switching) happens directly from internals > of the appropriate state machine of the underlying subsytem (like > network, filesystem, timer or any other). > > Homepage: > http://tservice.net.ru/~s0mbre/old/?section=projects=kevent > > Documentation page: > http://linux-net.osdl.org/index.php/Kevent > > Consider for inclusion. > > New benchmark, which can be a hoax though, can be found at > http://tservice.net.ru/~s0mbre/blog/2006/11/30#2006_11_30 > where kevent on amd64 with 1gb of ram can handle more than 7200 events per > second with 8000 requests concurrency with 'ab' benchmark and lighttpd. > Although I tought it should not be published due to possible errors, > I decided to send it for review. > > With this release I start 3 days resending timeout - i.e. each third day I > will send either new version (if something new was requested and agreed to > be implemented) or resending with back counter started from three. > When back counter hits zero after three resending I consider there is no > interest in subsystem and I will stop further sending. > First one will be sent about Jan 10. > > Thanks for understanding and your time. > > Changes from 'take28' patchset: > * optimized af_unix to use socket notifications > * changed ALWAYS_QUEUE behaviour with poll/select notifications - previously > kevent was not queued into poll wait queue when ALWAYS_QUEUE flag > is set > * added KEVENT_POLL_POLLRDHUP definition into ukevent.h header > * libevent-1.2 patch (Jamal, your request is completed, so I'm waiting two > weeks > before starting final countdown :) > All regression tests passed successfully except test_evbuffer(), which > crashes on my amd64 linux 2.6 test machine for all types of > notifications, > probably it is fixed in libevent-1.2a version, I did not check. > Patch and README can be found at project homepage. P.S. all kernel kevent options must be turned on (namely kevent_poll, kevent_socket and kevent_pipe). I did not hack 'configure' to check for supported notification types. -- Evgeniy Polyakov - 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/
[take29 0/8] kevent: Generic event handling mechanism.
Generic event handling mechanism. Kevent is a generic subsytem which allows to handle event notifications. It supports both level and edge triggered events. It is similar to poll/epoll in some cases, but it is more scalable, it is faster and allows to work with essentially eny kind of events. Events are provided into kernel through control syscall and can be read back through ring buffer or using usual syscalls. Kevent update (i.e. readiness switching) happens directly from internals of the appropriate state machine of the underlying subsytem (like network, filesystem, timer or any other). Homepage: http://tservice.net.ru/~s0mbre/old/?section=projects=kevent Documentation page: http://linux-net.osdl.org/index.php/Kevent Consider for inclusion. New benchmark, which can be a hoax though, can be found at http://tservice.net.ru/~s0mbre/blog/2006/11/30#2006_11_30 where kevent on amd64 with 1gb of ram can handle more than 7200 events per second with 8000 requests concurrency with 'ab' benchmark and lighttpd. Although I tought it should not be published due to possible errors, I decided to send it for review. With this release I start 3 days resending timeout - i.e. each third day I will send either new version (if something new was requested and agreed to be implemented) or resending with back counter started from three. When back counter hits zero after three resending I consider there is no interest in subsystem and I will stop further sending. First one will be sent about Jan 10. Thanks for understanding and your time. Changes from 'take28' patchset: * optimized af_unix to use socket notifications * changed ALWAYS_QUEUE behaviour with poll/select notifications - previously kevent was not queued into poll wait queue when ALWAYS_QUEUE flag is set * added KEVENT_POLL_POLLRDHUP definition into ukevent.h header * libevent-1.2 patch (Jamal, your request is completed, so I'm waiting two weeks before starting final countdown :) All regression tests passed successfully except test_evbuffer(), which crashes on my amd64 linux 2.6 test machine for all types of notifications, probably it is fixed in libevent-1.2a version, I did not check. Patch and README can be found at project homepage. Changes from 'take27' patchset: * made kevent default yes in non embedded case. * added falgs to callback structures - currently used to check if kevent can be requested from kernelspace only (posix timers) or userspace (all others) Changes from 'take26' patchset: * made kevent visible in config only in case of embedded setup. * added comment about KEVENT_MAX number. * spell fix. Changes from 'take25' patchset: * use timespec as timeout parameter. * added high-resolution timer to handle absolute timeouts. * added flags to waiting and initialization syscalls. * kevent_commit() has new_uidx parameter. * kevent_wait() has old_uidx parameter, which, if not equal to u->uidx, results in immediate wakeup (usefull for the case when entries are added asynchronously from kernel (not supported for now)). * added interface to mark any event as ready. * event POSIX timers support. * return -ENOSYS if there is no registered event type. * provided file descriptor must be checked for fifo type (spotted by Eric Dumazet). * signal notifications. * documentation update. * lighttpd patch updated (the latest benchmarks with lighttpd patch can be found in blog). Changes from 'take24' patchset: * new (old (new)) ring buffer implementation with kernel and user indexes. * added initialization syscall instead of opening /dev/kevent * kevent_commit() syscall to commit ring buffer entries * changed KEVENT_REQ_WAKEUP_ONE flag to KEVENT_REQ_WAKEUP_ALL, kevent wakes only first thread always if that flag is not set * KEVENT_REQ_ALWAYS_QUEUE flag. If set, kevent will be queued into ready queue instead of copying back to userspace when kevent is ready immediately when it is added. * lighttpd patch (Hail! Although nothing really outstanding compared to epoll) Changes from 'take23' patchset: * kevent PIPE notifications * KEVENT_REQ_LAST_CHECK flag, which allows to perform last check at dequeueing time * fixed poll/select notifications (were broken due to tree manipulations) * made Documentation/kevent.txt look nice in 80-col terminal * fix for copy_to_user() failure report for the first kevent (Andrew Morton) * minor function renames Changes from 'take22' patchset: * new ring buffer implementation in process' memory * wakeup-one-thread flag * edge-triggered behaviour Changes from 'take21' patchset: * minor cleanups (different return values, removed unneded variables, whitespaces and so on) * fixed bug in kevent removal in case when kevent being removed is the same as overflow_kevent (spotted by Eric Dumazet) Changes from 'take20' patchset: * new ring buffer implementation * removed artificial limit on
[take29 1/8] kevent: Description.
Description.
diff --git a/Documentation/kevent.txt b/Documentation/kevent.txt
new file mode 100644
index 000..2e03a3f
--- /dev/null
+++ b/Documentation/kevent.txt
@@ -0,0 +1,240 @@
+Description.
+
+int kevent_init(struct kevent_ring *ring, unsigned int ring_size,
+ unsigned int flags);
+
+num - size of the ring buffer in events
+ring - pointer to allocated ring buffer
+flags - various flags, see KEVENT_FLAGS_* definitions.
+
+Return value: kevent control file descriptor or negative error value.
+
+ struct kevent_ring
+ {
+ unsigned int ring_kidx, ring_over;
+ struct ukevent event[0];
+ }
+
+ring_kidx - index in the ring buffer where kernel will put new events
+ when kevent_wait() or kevent_get_events() is called
+ring_over - number of overflows of ring_uidx happend from the start.
+ Overflow counter is used to prevent situation when two threads
+ are going to free the same events, but one of them was scheduled
+ away for too long, so ring indexes were wrapped, so when that
+ thread will be awakened, it will free not those events, which
+ it suppose to free.
+
+Example userspace code (ring_buffer.c) can be found on project's homepage.
+
+Each kevent syscall can be so called cancellation point in glibc, i.e. when
+thread has been cancelled in kevent syscall, thread can be safely removed
+and no events will be lost, since each syscall (kevent_wait() or
+kevent_get_events()) will copy event into special ring buffer, accessible
+from other threads or even processes (if shared memory is used).
+
+When kevent is removed (not dequeued when it is ready, but just removed),
+even if it was ready, it is not copied into ring buffer, since if it is
+removed, no one cares about it (otherwise user would wait until it becomes
+ready and got it through usual way using kevent_get_events() or kevent_wait())
+and thus no need to copy it to the ring buffer.
+
+---
+
+
+int kevent_ctl(int fd, unsigned int cmd, unsigned int num, struct ukevent
*arg);
+
+fd - is the file descriptor referring to the kevent queue to manipulate.
+It is created by opening "/dev/kevent" char device, which is created with
+dynamic minor number and major number assigned for misc devices.
+
+cmd - is the requested operation. It can be one of the following:
+KEVENT_CTL_ADD - add event notification
+KEVENT_CTL_REMOVE - remove event notification
+KEVENT_CTL_MODIFY - modify existing notification
+KEVENT_CTL_READY - mark existing events as ready, if number of events is
zero,
+ it just wakes up parked in syscall thread
+
+num - number of struct ukevent in the array pointed to by arg
+arg - array of struct ukevent
+
+Return value:
+ number of events processed or negative error value.
+
+When called, kevent_ctl will carry out the operation specified in the
+cmd parameter.
+---
+
+ int kevent_get_events(int ctl_fd, unsigned int min_nr, unsigned int max_nr,
+ struct timespec timeout, struct ukevent *buf, unsigned flags);
+
+ctl_fd - file descriptor referring to the kevent queue
+min_nr - minimum number of completed events that kevent_get_events will block
+waiting for
+max_nr - number of struct ukevent in buf
+timeout - time to wait before returning less than min_nr
+ events. If this is -1, then wait forever.
+buf - pointer to an array of struct ukevent.
+flags - various flags, see KEVENT_FLAGS_* definitions.
+
+Return value:
+ number of events copied or negative error value.
+
+kevent_get_events will wait timeout milliseconds for at least min_nr completed
+events, copying completed struct ukevents to buf and deleting any
+KEVENT_REQ_ONESHOT event requests. In nonblocking mode it returns as many
+events as possible, but not more than max_nr. In blocking mode it waits until
+timeout or if at least min_nr events are ready.
+
+This function copies event into ring buffer if it was initialized, if ring
buffer
+is full, KEVENT_RET_COPY_FAILED flag is set in ret_flags field.
+---
+
+ int kevent_wait(int ctl_fd, unsigned int num, unsigned int old_uidx,
+ struct timespec timeout, unsigned int flags);
+
+ctl_fd - file descriptor referring to the kevent queue
+num - number of processed kevents
+old_uidx - the last index user is aware of
+timeout - time to wait until there is free space in kevent queue
+flags - various flags, see KEVENT_FLAGS_* definitions.
+
+Return value:
+ number of events copied into ring buffer or negative error value.
+
+This syscall waits until either timeout expires or at least one event becomes
+ready. It also copies events into special ring buffer. If ring buffer is full,
+it waits until there are ready events and then return.
+If kevent is one-shot kevent it is
[take29 4/8] kevent: Socket notifications.
Socket notifications.
This patch includes socket send/recv/accept notifications.
Using trivial web server based on kevent and this features
instead of epoll it's performance increased more than noticebly.
More details about various benchmarks and server itself
(evserver_kevent.c) can be found on project's homepage.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/fs/inode.c b/fs/inode.c
index ada7643..2740617 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
/*
@@ -164,12 +165,18 @@ static struct inode *alloc_inode(struct super_block *sb)
}
inode->i_private = 0;
inode->i_mapping = mapping;
+#if defined CONFIG_KEVENT_SOCKET || defined CONFIG_KEVENT_PIPE
+ kevent_storage_init(inode, >st);
+#endif
}
return inode;
}
void destroy_inode(struct inode *inode)
{
+#if defined CONFIG_KEVENT_SOCKET || defined CONFIG_KEVENT_PIPE
+ kevent_storage_fini(>st);
+#endif
BUG_ON(inode_has_buffers(inode));
security_inode_free(inode);
if (inode->i_sb->s_op->destroy_inode)
diff --git a/include/net/sock.h b/include/net/sock.h
index edd4d73..d48ded8 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -48,6 +48,7 @@
#include
#include /* struct sk_buff */
#include
+#include
#include
@@ -450,6 +451,21 @@ static inline int sk_stream_memory_free(struct sock *sk)
extern void sk_stream_rfree(struct sk_buff *skb);
+struct socket_alloc {
+ struct socket socket;
+ struct inode vfs_inode;
+};
+
+static inline struct socket *SOCKET_I(struct inode *inode)
+{
+ return _of(inode, struct socket_alloc, vfs_inode)->socket;
+}
+
+static inline struct inode *SOCK_INODE(struct socket *socket)
+{
+ return _of(socket, struct socket_alloc, socket)->vfs_inode;
+}
+
static inline void sk_stream_set_owner_r(struct sk_buff *skb, struct sock *sk)
{
skb->sk = sk;
@@ -477,6 +493,7 @@ static inline void sk_add_backlog(struct sock *sk, struct
sk_buff *skb)
sk->sk_backlog.tail = skb;
}
skb->next = NULL;
+ kevent_socket_notify(sk, KEVENT_SOCKET_RECV);
}
#define sk_wait_event(__sk, __timeo, __condition) \
@@ -679,21 +696,6 @@ static inline struct kiocb *siocb_to_kiocb(struct
sock_iocb *si)
return si->kiocb;
}
-struct socket_alloc {
- struct socket socket;
- struct inode vfs_inode;
-};
-
-static inline struct socket *SOCKET_I(struct inode *inode)
-{
- return _of(inode, struct socket_alloc, vfs_inode)->socket;
-}
-
-static inline struct inode *SOCK_INODE(struct socket *socket)
-{
- return _of(socket, struct socket_alloc, socket)->vfs_inode;
-}
-
extern void __sk_stream_mem_reclaim(struct sock *sk);
extern int sk_stream_mem_schedule(struct sock *sk, int size, int kind);
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 7a093d0..69f4ad2 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -857,6 +857,7 @@ static inline int tcp_prequeue(struct sock *sk, struct
sk_buff *skb)
tp->ucopy.memory = 0;
} else if (skb_queue_len(>ucopy.prequeue) == 1) {
wake_up_interruptible(sk->sk_sleep);
+ kevent_socket_notify(sk,
KEVENT_SOCKET_RECV|KEVENT_SOCKET_SEND);
if (!inet_csk_ack_scheduled(sk))
inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
(3 * TCP_RTO_MIN) / 4,
diff --git a/kernel/kevent/kevent_socket.c b/kernel/kevent/kevent_socket.c
new file mode 100644
index 000..d1a2701
--- /dev/null
+++ b/kernel/kevent/kevent_socket.c
@@ -0,0 +1,144 @@
+/*
+ * kevent_socket.c
+ *
+ * 2006 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static int kevent_socket_callback(struct kevent *k)
+{
+ struct inode *inode = k->st->origin;
+ unsigned int events = SOCKET_I(inode)->ops->poll(SOCKET_I(inode)->file,
SOCKET_I(inode), NULL);
[take29 3/8] kevent: poll/select() notifications.
poll/select() notifications.
This patch includes generic poll/select notifications.
kevent_poll works simialr to epoll and has the same issues (callback
is invoked not from internal state machine of the caller, but through
process awake, a lot of allocations and so on).
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/fs/file_table.c b/fs/file_table.c
index bc35a40..0805547 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -119,6 +120,7 @@ struct file *get_empty_filp(void)
f->f_uid = tsk->fsuid;
f->f_gid = tsk->fsgid;
eventpoll_init_file(f);
+ kevent_init_file(f);
/* f->f_version: 0 */
return f;
@@ -164,6 +166,7 @@ void fastcall __fput(struct file *file)
* in the file cleanup chain.
*/
eventpoll_release(file);
+ kevent_cleanup_file(file);
locks_remove_flock(file);
if (file->f_op && file->f_op->release)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 5baf3a1..8bbf3a5 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -276,6 +276,7 @@ extern int dir_notify_enable;
#include
#include
#include
+#include
#include
#include
@@ -586,6 +587,10 @@ struct inode {
struct mutexinotify_mutex; /* protects the watches list */
#endif
+#if defined CONFIG_KEVENT_SOCKET || defined CONFIG_KEVENT_PIPE
+ struct kevent_storage st;
+#endif
+
unsigned long i_state;
unsigned long dirtied_when; /* jiffies of first dirtying */
@@ -739,6 +744,9 @@ struct file {
struct list_headf_ep_links;
spinlock_t f_ep_lock;
#endif /* #ifdef CONFIG_EPOLL */
+#ifdef CONFIG_KEVENT_POLL
+ struct kevent_storage st;
+#endif
struct address_space*f_mapping;
};
extern spinlock_t files_lock;
diff --git a/kernel/kevent/kevent_poll.c b/kernel/kevent/kevent_poll.c
new file mode 100644
index 000..14094d5
--- /dev/null
+++ b/kernel/kevent/kevent_poll.c
@@ -0,0 +1,234 @@
+/*
+ * 2006 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static kmem_cache_t *kevent_poll_container_cache;
+static kmem_cache_t *kevent_poll_priv_cache;
+
+struct kevent_poll_ctl
+{
+ struct poll_table_structpt;
+ struct kevent *k;
+};
+
+struct kevent_poll_wait_container
+{
+ struct list_headcontainer_entry;
+ wait_queue_head_t *whead;
+ wait_queue_twait;
+ struct kevent *k;
+};
+
+struct kevent_poll_private
+{
+ struct list_headcontainer_list;
+ spinlock_t container_lock;
+};
+
+static int kevent_poll_enqueue(struct kevent *k);
+static int kevent_poll_dequeue(struct kevent *k);
+static int kevent_poll_callback(struct kevent *k);
+
+static int kevent_poll_wait_callback(wait_queue_t *wait,
+ unsigned mode, int sync, void *key)
+{
+ struct kevent_poll_wait_container *cont =
+ container_of(wait, struct kevent_poll_wait_container, wait);
+ struct kevent *k = cont->k;
+
+ kevent_storage_ready(k->st, NULL, KEVENT_MASK_ALL);
+ return 0;
+}
+
+static void kevent_poll_qproc(struct file *file, wait_queue_head_t *whead,
+ struct poll_table_struct *poll_table)
+{
+ struct kevent *k =
+ container_of(poll_table, struct kevent_poll_ctl, pt)->k;
+ struct kevent_poll_private *priv = k->priv;
+ struct kevent_poll_wait_container *cont;
+ unsigned long flags;
+
+ cont = kmem_cache_alloc(kevent_poll_container_cache, GFP_KERNEL);
+ if (!cont) {
+ kevent_break(k);
+ return;
+ }
+
+ cont->k = k;
+ init_waitqueue_func_entry(>wait, kevent_poll_wait_callback);
+ cont->whead = whead;
+
+ spin_lock_irqsave(>container_lock, flags);
+ list_add_tail(>container_entry, >container_list);
+ spin_unlock_irqrestore(>container_lock, flags);
+
+ add_wait_queue(whead, >wait);
+}
+
+static int kevent_poll_enqueue(struct kevent *k)
+{
+ struct file *file;
+ int err;
+ unsigned int revents;
+ unsigned long flags;
+ struct
[take29 8/8] kevent: Kevent posix timer notifications.
Kevent posix timer notifications.
Simple extensions to POSIX timers which allows
to deliver notification of the timer expiration
through kevent queue.
Example application posix_timer.c can be found
in archive on project homepage.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/include/asm-generic/siginfo.h b/include/asm-generic/siginfo.h
index 8786e01..3768746 100644
--- a/include/asm-generic/siginfo.h
+++ b/include/asm-generic/siginfo.h
@@ -235,6 +235,7 @@ typedef struct siginfo {
#define SIGEV_NONE 1 /* other notification: meaningless */
#define SIGEV_THREAD 2 /* deliver via thread creation */
#define SIGEV_THREAD_ID 4 /* deliver to thread */
+#define SIGEV_KEVENT 8 /* deliver through kevent queue */
/*
* This works because the alignment is ok on all current architectures
@@ -260,6 +261,8 @@ typedef struct sigevent {
void (*_function)(sigval_t);
void *_attribute; /* really pthread_attr_t */
} _sigev_thread;
+
+ int kevent_fd;
} _sigev_un;
} sigevent_t;
diff --git a/include/linux/posix-timers.h b/include/linux/posix-timers.h
index a7dd38f..4b9deb4 100644
--- a/include/linux/posix-timers.h
+++ b/include/linux/posix-timers.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
union cpu_time_count {
cputime_t cpu;
@@ -49,6 +50,9 @@ struct k_itimer {
sigval_t it_sigev_value;/* value word of sigevent struct */
struct task_struct *it_process; /* process to send signal to */
struct sigqueue *sigq; /* signal queue entry. */
+#ifdef CONFIG_KEVENT_TIMER
+ struct kevent_storage st;
+#endif
union {
struct {
struct hrtimer timer;
diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
index e5ebcc1..74270f8 100644
--- a/kernel/posix-timers.c
+++ b/kernel/posix-timers.c
@@ -48,6 +48,8 @@
#include
#include
#include
+#include
+#include
/*
* Management arrays for POSIX timers. Timers are kept in slab memory
@@ -224,6 +226,100 @@ static int posix_ktime_get_ts(clockid_t which_clock,
struct timespec *tp)
return 0;
}
+#ifdef CONFIG_KEVENT_TIMER
+static int posix_kevent_enqueue(struct kevent *k)
+{
+ /*
+* It is not ugly - there is no pointer in the id field union,
+* but its size is 64bits, which is ok for any known pointer size.
+*/
+ struct k_itimer *tmr = (struct k_itimer *)(unsigned
long)k->event.id.raw_u64;
+ return kevent_storage_enqueue(>st, k);
+}
+static int posix_kevent_dequeue(struct kevent *k)
+{
+ struct k_itimer *tmr = (struct k_itimer *)(unsigned
long)k->event.id.raw_u64;
+ kevent_storage_dequeue(>st, k);
+ return 0;
+}
+static int posix_kevent_callback(struct kevent *k)
+{
+ return 1;
+}
+static int posix_kevent_init(void)
+{
+ struct kevent_callbacks tc = {
+ .callback = _kevent_callback,
+ .enqueue = _kevent_enqueue,
+ .dequeue = _kevent_dequeue,
+ .flags = KEVENT_CALLBACKS_KERNELONLY};
+
+ return kevent_add_callbacks(, KEVENT_POSIX_TIMER);
+}
+
+extern struct file_operations kevent_user_fops;
+
+static int posix_kevent_init_timer(struct k_itimer *tmr, int fd)
+{
+ struct ukevent uk;
+ struct file *file;
+ struct kevent_user *u;
+ int err;
+
+ file = fget(fd);
+ if (!file) {
+ err = -EBADF;
+ goto err_out;
+ }
+
+ if (file->f_op != _user_fops) {
+ err = -EINVAL;
+ goto err_out_fput;
+ }
+
+ u = file->private_data;
+
+ memset(, 0, sizeof(struct ukevent));
+
+ uk.event = KEVENT_MASK_ALL;
+ uk.type = KEVENT_POSIX_TIMER;
+ uk.id.raw_u64 = (unsigned long)(tmr); /* Just cast to something unique
*/
+ uk.req_flags = KEVENT_REQ_ONESHOT | KEVENT_REQ_ALWAYS_QUEUE;
+ uk.ptr = tmr->it_sigev_value.sival_ptr;
+
+ err = kevent_user_add_ukevent(, u);
+ if (err)
+ goto err_out_fput;
+
+ fput(file);
+
+ return 0;
+
+err_out_fput:
+ fput(file);
+err_out:
+ return err;
+}
+
+static void posix_kevent_fini_timer(struct k_itimer *tmr)
+{
+ kevent_storage_fini(>st);
+}
+#else
+static int posix_kevent_init_timer(struct k_itimer *tmr, int fd)
+{
+ return -ENOSYS;
+}
+static int posix_kevent_init(void)
+{
+ return 0;
+}
+static void posix_kevent_fini_timer(struct k_itimer *tmr)
+{
+}
+#endif
+
+
/*
* Initialize everything, well, just everything in Posix clocks/timers ;)
*/
@@ -241,6 +337,11 @@ static __init int init_posix_timers(void)
register_posix_clock(CLOCK_REALTIME, _realtime);
register_posix_clock(CLOCK_MONOTONIC, _monotonic);
+ if (posix_kevent_init()) {
+ printk(KERN_ERR "Failed to initialize kevent posix timers.\n");
+
[take29 7/8] kevent: Signal notifications.
Signal notifications.
This type of notifications allows to deliver signals through kevent queue.
One can find example application signal.c on project homepage.
If KEVENT_SIGNAL_NOMASK bit is set in raw_u64 id then signal will be
delivered only through queue, otherwise both delivery types are used - old
through update of mask of pending signals and through queue.
If signal is delivered only through kevent queue mask of pending signals
is not updated at all, which is equal to putting signal into blocked mask,
but with delivery of that signal through kevent queue.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/include/linux/sched.h b/include/linux/sched.h
index fc4a987..ef38a3c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -80,6 +80,7 @@ struct sched_param {
#include
#include
#include
+#include
#include
@@ -1013,6 +1014,10 @@ struct task_struct {
#ifdef CONFIG_TASK_DELAY_ACCT
struct task_delay_info *delays;
#endif
+#ifdef CONFIG_KEVENT_SIGNAL
+ struct kevent_storage st;
+ u32 kevent_signals;
+#endif
};
static inline pid_t process_group(struct task_struct *tsk)
diff --git a/kernel/fork.c b/kernel/fork.c
index 1c999f3..e5b5b14 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
#include
@@ -115,6 +116,9 @@ void __put_task_struct(struct task_struct *tsk)
WARN_ON(atomic_read(>usage));
WARN_ON(tsk == current);
+#ifdef CONFIG_KEVENT_SIGNAL
+ kevent_storage_fini(>st);
+#endif
security_task_free(tsk);
free_uid(tsk->user);
put_group_info(tsk->group_info);
@@ -1121,6 +1125,10 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
if (retval)
goto bad_fork_cleanup_namespace;
+#ifdef CONFIG_KEVENT_SIGNAL
+ kevent_storage_init(p, >st);
+#endif
+
p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr :
NULL;
/*
* Clear TID on mm_release()?
diff --git a/kernel/kevent/kevent_signal.c b/kernel/kevent/kevent_signal.c
new file mode 100644
index 000..abe3972
--- /dev/null
+++ b/kernel/kevent/kevent_signal.c
@@ -0,0 +1,94 @@
+/*
+ * kevent_signal.c
+ *
+ * 2006 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int kevent_signal_callback(struct kevent *k)
+{
+ struct task_struct *tsk = k->st->origin;
+ int sig = k->event.id.raw[0];
+ int ret = 0;
+
+ if (sig == tsk->kevent_signals)
+ ret = 1;
+
+ if (ret && (k->event.id.raw_u64 & KEVENT_SIGNAL_NOMASK))
+ tsk->kevent_signals |= 0x8000;
+
+ return ret;
+}
+
+int kevent_signal_enqueue(struct kevent *k)
+{
+ int err;
+
+ err = kevent_storage_enqueue(>st, k);
+ if (err)
+ goto err_out_exit;
+
+ if (k->event.req_flags & KEVENT_REQ_ALWAYS_QUEUE) {
+ kevent_requeue(k);
+ err = 0;
+ } else {
+ err = k->callbacks.callback(k);
+ if (err)
+ goto err_out_dequeue;
+ }
+
+ return err;
+
+err_out_dequeue:
+ kevent_storage_dequeue(k->st, k);
+err_out_exit:
+ return err;
+}
+
+int kevent_signal_dequeue(struct kevent *k)
+{
+ kevent_storage_dequeue(k->st, k);
+ return 0;
+}
+
+int kevent_signal_notify(struct task_struct *tsk, int sig)
+{
+ tsk->kevent_signals = sig;
+ kevent_storage_ready(>st, NULL, KEVENT_SIGNAL_DELIVERY);
+ return (tsk->kevent_signals & 0x8000);
+}
+
+static int __init kevent_init_signal(void)
+{
+ struct kevent_callbacks sc = {
+ .callback = _signal_callback,
+ .enqueue = _signal_enqueue,
+ .dequeue = _signal_dequeue,
+ .flags = 0,
+ };
+
+ return kevent_add_callbacks(, KEVENT_SIGNAL);
+}
+module_init(kevent_init_signal);
diff --git a/kernel/signal.c b/kernel/signal.c
index fb5da6d..d3d3594 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
[take29 5/8] kevent: Timer notifications.
Timer notifications.
Timer notifications can be used for fine grained per-process time
management, since interval timers are very inconvenient to use,
and they are limited.
This subsystem uses high-resolution timers.
id.raw[0] is used as number of seconds
id.raw[1] is used as number of nanoseconds
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/kernel/kevent/kevent_timer.c b/kernel/kevent/kevent_timer.c
new file mode 100644
index 000..c21a155
--- /dev/null
+++ b/kernel/kevent/kevent_timer.c
@@ -0,0 +1,114 @@
+/*
+ * 2006 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct kevent_timer
+{
+ struct hrtimer ktimer;
+ struct kevent_storage ktimer_storage;
+ struct kevent *ktimer_event;
+};
+
+static int kevent_timer_func(struct hrtimer *timer)
+{
+ struct kevent_timer *t = container_of(timer, struct kevent_timer,
ktimer);
+ struct kevent *k = t->ktimer_event;
+
+ kevent_storage_ready(>ktimer_storage, NULL, KEVENT_MASK_ALL);
+ hrtimer_forward(timer, timer->base->softirq_time,
+ ktime_set(k->event.id.raw[0], k->event.id.raw[1]));
+ return HRTIMER_RESTART;
+}
+
+static struct lock_class_key kevent_timer_key;
+
+static int kevent_timer_enqueue(struct kevent *k)
+{
+ int err;
+ struct kevent_timer *t;
+
+ t = kmalloc(sizeof(struct kevent_timer), GFP_KERNEL);
+ if (!t)
+ return -ENOMEM;
+
+ hrtimer_init(>ktimer, CLOCK_MONOTONIC, HRTIMER_REL);
+ t->ktimer.expires = ktime_set(k->event.id.raw[0], k->event.id.raw[1]);
+ t->ktimer.function = kevent_timer_func;
+ t->ktimer_event = k;
+
+ err = kevent_storage_init(>ktimer, >ktimer_storage);
+ if (err)
+ goto err_out_free;
+ lockdep_set_class(>ktimer_storage.lock, _timer_key);
+
+ err = kevent_storage_enqueue(>ktimer_storage, k);
+ if (err)
+ goto err_out_st_fini;
+
+ hrtimer_start(>ktimer, t->ktimer.expires, HRTIMER_REL);
+
+ return 0;
+
+err_out_st_fini:
+ kevent_storage_fini(>ktimer_storage);
+err_out_free:
+ kfree(t);
+
+ return err;
+}
+
+static int kevent_timer_dequeue(struct kevent *k)
+{
+ struct kevent_storage *st = k->st;
+ struct kevent_timer *t = container_of(st, struct kevent_timer,
ktimer_storage);
+
+ hrtimer_cancel(>ktimer);
+ kevent_storage_dequeue(st, k);
+ kfree(t);
+
+ return 0;
+}
+
+static int kevent_timer_callback(struct kevent *k)
+{
+ k->event.ret_data[0] = jiffies_to_msecs(jiffies);
+ return 1;
+}
+
+static int __init kevent_init_timer(void)
+{
+ struct kevent_callbacks tc = {
+ .callback = _timer_callback,
+ .enqueue = _timer_enqueue,
+ .dequeue = _timer_dequeue,
+ .flags = 0,
+ };
+
+ return kevent_add_callbacks(, KEVENT_TIMER);
+}
+module_init(kevent_init_timer);
+
-
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/
[take29 6/8] kevent: Pipe notifications.
Pipe notifications.
diff --git a/fs/pipe.c b/fs/pipe.c
index f3b6f71..aeaee9c 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -312,6 +313,7 @@ redo:
break;
}
if (do_wakeup) {
+ kevent_pipe_notify(inode, KEVENT_SOCKET_SEND);
wake_up_interruptible_sync(>wait);
kill_fasync(>fasync_writers, SIGIO, POLL_OUT);
}
@@ -321,6 +323,7 @@ redo:
/* Signal writers asynchronously that there is more room. */
if (do_wakeup) {
+ kevent_pipe_notify(inode, KEVENT_SOCKET_SEND);
wake_up_interruptible(>wait);
kill_fasync(>fasync_writers, SIGIO, POLL_OUT);
}
@@ -490,6 +493,7 @@ redo2:
break;
}
if (do_wakeup) {
+ kevent_pipe_notify(inode, KEVENT_SOCKET_RECV);
wake_up_interruptible_sync(>wait);
kill_fasync(>fasync_readers, SIGIO, POLL_IN);
do_wakeup = 0;
@@ -501,6 +505,7 @@ redo2:
out:
mutex_unlock(>i_mutex);
if (do_wakeup) {
+ kevent_pipe_notify(inode, KEVENT_SOCKET_RECV);
wake_up_interruptible(>wait);
kill_fasync(>fasync_readers, SIGIO, POLL_IN);
}
@@ -605,6 +610,7 @@ pipe_release(struct inode *inode, int decr, int decw)
free_pipe_info(inode);
} else {
wake_up_interruptible(>wait);
+ kevent_pipe_notify(inode,
KEVENT_SOCKET_SEND|KEVENT_SOCKET_RECV);
kill_fasync(>fasync_readers, SIGIO, POLL_IN);
kill_fasync(>fasync_writers, SIGIO, POLL_OUT);
}
diff --git a/kernel/kevent/kevent_pipe.c b/kernel/kevent/kevent_pipe.c
new file mode 100644
index 000..91dc1eb
--- /dev/null
+++ b/kernel/kevent/kevent_pipe.c
@@ -0,0 +1,123 @@
+/*
+ * kevent_pipe.c
+ *
+ * 2006 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int kevent_pipe_callback(struct kevent *k)
+{
+ struct inode *inode = k->st->origin;
+ struct pipe_inode_info *pipe = inode->i_pipe;
+ int nrbufs = pipe->nrbufs;
+
+ if (k->event.event & KEVENT_SOCKET_RECV && nrbufs > 0) {
+ if (!pipe->writers)
+ return -1;
+ return 1;
+ }
+
+ if (k->event.event & KEVENT_SOCKET_SEND && nrbufs < PIPE_BUFFERS) {
+ if (!pipe->readers)
+ return -1;
+ return 1;
+ }
+
+ return 0;
+}
+
+int kevent_pipe_enqueue(struct kevent *k)
+{
+ struct file *pipe;
+ int err = -EBADF;
+ struct inode *inode;
+
+ pipe = fget(k->event.id.raw[0]);
+ if (!pipe)
+ goto err_out_exit;
+
+ inode = igrab(pipe->f_dentry->d_inode);
+ if (!inode)
+ goto err_out_fput;
+
+ err = -EINVAL;
+ if (!S_ISFIFO(inode->i_mode))
+ goto err_out_iput;
+
+ err = kevent_storage_enqueue(>st, k);
+ if (err)
+ goto err_out_iput;
+
+ if (k->event.req_flags & KEVENT_REQ_ALWAYS_QUEUE) {
+ kevent_requeue(k);
+ err = 0;
+ } else {
+ err = k->callbacks.callback(k);
+ if (err)
+ goto err_out_dequeue;
+ }
+
+ fput(pipe);
+
+ return err;
+
+err_out_dequeue:
+ kevent_storage_dequeue(k->st, k);
+err_out_iput:
+ iput(inode);
+err_out_fput:
+ fput(pipe);
+err_out_exit:
+ return err;
+}
+
+int kevent_pipe_dequeue(struct kevent *k)
+{
+ struct inode *inode = k->st->origin;
+
+ kevent_storage_dequeue(k->st, k);
+ iput(inode);
+
+ return 0;
+}
+
+void kevent_pipe_notify(struct inode *inode, u32 event)
+{
+ kevent_storage_ready(>st, NULL, event);
+}
+
+static int __init kevent_init_pipe(void)
+{
+ struct kevent_callbacks sc = {
+ .callback = _pipe_callback,
+
[patch] suspend: fix suspend on single-CPU systems
Subject: [patch] suspend: fix suspend on single-CPU systems
From: Ingo Molnar <[EMAIL PROTECTED]>
Clark Williams reported that suspend doesnt work on his laptop on
2.6.20-rc1-rt kernels. The bug was introduced by the following cleanup
commit:
commit 112cecb2cc0e7341db92281ba04b26c41bb8146d
Author: Siddha, Suresh B <[EMAIL PROTECTED]>
Date: Wed Dec 6 20:34:31 2006 -0800
[PATCH] suspend: don't change cpus_allowed for task initiating the suspend
because with this change 'error' is not initialized to 0 anymore, if
there are no other online CPUs. (i.e. if the system is single-CPU).
the fix is the initialize it to 0. The really weird thing is that my
version of gcc does not warn about this non-initialized variable
situation ...
(also fix the kernel printk in the error branch, it was missing a
newline)
Reported-by: Clark Williams <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
kernel/cpu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/kernel/cpu.c
===
--- linux.orig/kernel/cpu.c
+++ linux/kernel/cpu.c
@@ -258,7 +258,7 @@ static cpumask_t frozen_cpus;
int disable_nonboot_cpus(void)
{
- int cpu, first_cpu, error;
+ int cpu, first_cpu, error = 0;
mutex_lock(_add_remove_lock);
first_cpu = first_cpu(cpu_present_map);
@@ -294,7 +294,7 @@ int disable_nonboot_cpus(void)
/* Make sure the CPUs won't be enabled by someone else */
cpu_hotplug_disabled = 1;
} else {
- printk(KERN_ERR "Non-boot CPUs are not disabled");
+ printk(KERN_ERR "Non-boot CPUs are not disabled\n");
}
out:
mutex_unlock(_add_remove_lock);
-
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: sched_clock() on i386
On Fri, 2006-12-22 at 02:43 -0800, Stephane Eranian wrote: > Hello, > > > The perfmon subsystems needs to compute per-CPU duration. It is using > sched_clock() to provide this information. However, it seems they are > big variations in the way sched_clock() is implemented for each architectures, > especially in the accuracy of the returned value (going from TSC to jiffies). > The vast majority of architectures return a scaled jiffies value for sched_clock(). MIPS, and ARM for instance are two, and i386 does sometimes. The function isn't very predictable in terms or what you'll get as output. The most reliable way to get timing is to use gettimeofday() which in turn uses a lowlevel clock. I'm not sure exactly what your application is, but sometimes gettimeofday() can be a little complicated to use. Which is why I create the following clocksource changes, ftp://source.mvista.com/pub/dwalker/clocksource/ the purpose of which is to allow generic access to suitable lowlevel clocks. It just extends the mechanism already used by gettimeofday(). Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.6.19.1
On Wednesday 20 December 2006 14:21, Alistair John Strachan wrote:
> Hi,
>
> Any ideas?
Pretty much like clockwork, it happened again. I think it's time to take this
seriously as a software bug, and not some hardware problem. I've ran kernels
since 2.6.0 on this machine without such crashes, and now two of the same in
2.6.19.1? Pretty unlikely!
BUG: unable to handle kernel NULL pointer dereference at virtual address
0009
printing eip:
c0156f60
*pde =
Oops: 0002 [#1]
Modules linked in: ipt_recent ipt_REJECT xt_tcpudp ipt_MASQUERADE iptable_nat
xt_sta
te iptable_filter ip_tables x_tables prism54 yenta_socket rsrc_nonstatic
pcmcia_core snd_via82xx snd_ac97_codec snd_ac97_bus
snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd soundcore
usblp ehci_hcd eth1394 uhci_hcd usbcore ohci1394 i
eee1394 via_agp agpgart vt1211 hwmon_vid hwmon ip_nat_ftp ip_nat
ip_conntrack_ftp ip_conntrack
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.19.1 #1)
EIP is at pipe_poll+0xa0/0xb0
eax: 0008 ebx: ecx: 0008 edx:
esi: ee1b9e9c edi: f4d80a00 ebp: ee1b9c1c esp: ee1b9c0c
ds: 007b es: 007b ss: 0068
Process java (pid: 5374, ti=ee1b8000 task=f7117560 task.ti=ee1b8000)
Stack: ee1b9e9c f6c17160 ee1b9fa4 c015d7f3 ee1b9c54 ee1b9fac
082dff90 0010 082dffa0 ee1b9e94 ee1b9e94 0002 ee1b9eac
ee1b9e94 c015e580 0002 f6c17160
Call Trace:
[] do_sys_poll+0x253/0x480
[] sys_poll+0x33/0x50
[] syscall_call+0x7/0xb
[] 0xb7f26402
===
Code: 58 01 00 00 0f 4f c2 09 c1 89 c8 83 c8 08 85 db 0f 44 c8 8b 5d f4 89 c8
8b 75
f8 8b 7d fc 89 ec 5d c3 89 ca 8b 46 6c 83 ca 10 3b <87> 68 01 00 00 0f 45 ca
eb b6 8d b6 00 00 00 00 55 b8 01 00 00
EIP: [] pipe_poll+0xa0/0xb0 SS:ESP 0068:ee1b9c0c
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
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] usblp.c - add Kyocera Mita FS 820 to list of "quirky" printers
So after reading about usbmon, here are some logs. Printer is inserted and on. Starting cups usb backend to get information gives: df827bc0 1861979946 S Bi:002:02 -115 8192 < ddba34e0 1861979979 S Ci:002:00 s a1 00 03ff 1023 < ddba34e0 1866979395 C Ci:002:00 -104 0 df827bc0 1866980389 C Bi:002:02 -2 0 Plugging the printer in with usbmon logging gives: dfaede40 1932904692 S Ii:001:01 -115 2 < ddba3460 1932904708 S Ci:001:00 s a3 00 0001 0004 4 < ddba3460 1932904711 C Ci:001:00 0 4 = 0001 ddba3460 1932904712 S Ci:001:00 s a3 00 0002 0004 4 < ddba3460 1932904717 C Ci:001:00 0 4 = 01010100 ddba3460 1932904718 S Co:001:00 s 23 01 0010 0002 0 ddba3460 1932904719 C Co:001:00 0 0 ddba3460 1932904722 S Ci:001:00 s a3 00 0002 0004 4 < ddba3460 1932904723 C Ci:001:00 0 4 = 0101 ddba3460 1932936690 S Ci:001:00 s a3 00 0002 0004 4 < ddba3460 1932936692 C Ci:001:00 0 4 = 0101 ddba3460 1932968689 S Ci:001:00 s a3 00 0002 0004 4 < ddba3460 1932968698 C Ci:001:00 0 4 = 0101 ddba3460 1933000687 S Ci:001:00 s a3 00 0002 0004 4 < ddba3460 1933000689 C Ci:001:00 0 4 = 0101 ddba3460 1933032693 S Ci:001:00 s a3 00 0002 0004 4 < ddba3460 1933032694 C Ci:001:00 0 4 = 0101 ddba3460 1933032703 S Co:001:00 s 23 03 0004 0002 0 ddba3460 1933048686 C Co:001:00 0 0 ddba3460 1933104684 S Ci:001:00 s a3 00 0002 0004 4 < ddba3460 1933104690 C Ci:001:00 0 4 = 03011000 dfaede40 1933156684 C Ii:001:01 0 1 = 04 dfaede40 1933156686 S Ii:001:01 -115 2 < ddba3460 1933160683 S Co:001:00 s 23 01 0014 0002 0 ddba3460 1933160684 C Co:001:00 0 0 ddba3460 1933171377 S Ci:000:00 s 80 06 0100 0040 64 < ddba3460 1933172589 C Ci:000:00 0 8 = 12010101 0008 ddba3460 1933172597 S Co:001:00 s 23 03 0004 0002 0 ddba3460 1933184681 C Co:001:00 0 0 ddba3460 1933240680 S Ci:001:00 s a3 00 0002 0004 4 < ddba3460 1933240686 C Ci:001:00 0 4 = 03011000 ddba3460 1933296678 S Co:001:00 s 23 01 0014 0002 0 ddba3460 1933296679 C Co:001:00 0 0 ddba3460 1933296681 S Co:000:00 s 00 05 0003 0 ddba3460 1933298535 C Co:000:00 0 0 ddba3460 1933316680 S Ci:003:00 s 80 06 0100 0012 18 < ddba3460 1933318528 C Ci:003:00 0 18 = 12010101 0008 82041000 0102 0301 ddba3460 1933318537 S Ci:003:00 s 80 06 0200 0009 9 < ddba3460 1933321527 C Ci:003:00 0 9 = 09022000 010100c0 32 ddba3460 1933321532 S Ci:003:00 s 80 06 0200 0020 32 < ddba3460 1933324525 C Ci:003:00 0 32 = 09022000 010100c0 32090400 00020701 02000705 01024000 00070582 0240 ddba34e0 1933324536 S Ci:003:00 s 80 06 0300 00ff 255 < ddba34e0 1933327524 C Ci:003:00 0 4 = 04030904 ddba34e0 1933327531 S Ci:003:00 s 80 06 0302 0409 00ff 255 < ddba34e0 190523 C Ci:003:00 0 42 = 2a034b00 79006f00 63006500 72006100 20004d00 69007400 61002000 46005300 ddba34e0 190530 S Ci:003:00 s 80 06 0301 0409 00ff 255 < ddba34e0 193522 C Ci:003:00 0 26 = 1a034b00 79006f00 63006500 72006100 20004d00 69007400 6100 ddba34e0 193527 S Ci:003:00 s 80 06 0303 0409 00ff 255 < ddba34e0 196520 C Ci:003:00 0 22 = 16035800 4c004600 34005900 30003700 37003900 3100 ddba34e0 1933378426 S Co:003:00 s 00 09 0001 0 ddba34e0 1933379513 C Co:003:00 0 0 cf590ea0 1933379625 S Co:003:00 s 01 0b 0 cf590ea0 1933382511 C Co:003:00 0 0 cf590ea0 1933382539 S Ci:003:00 s a1 00 03ff 1023 < cf590ea0 1933385510 C Ci:003:00 0 91 = 005b4944 3a46532d 3832303b 4d46473a 4b796f63 6572613b 434d443a 50434c58 cf590ea0 1933396519 S Ci:001:00 s a3 00 0003 0004 4 < cf590ea0 1933396524 C Ci:001:00 0 4 = 0001 cf590ea0 1933396531 S Ci:001:00 s a3 00 0002 0004 4 < cf590ea0 1933396533 C Ci:001:00 0 4 = 0301 de8fbac0 1935981340 S Bi:003:02 -115 8192 < de8fb1c0 1935981363 S Ci:003:00 s a1 00 03ff 1023 < de8fbac0 1935982496 C Bi:003:02 0 0 de8fb1c0 1935982501 C Ci:003:00 0 91 = 005b4944 3a46532d 3832303b 4d46473a 4b796f63 6572613b 434d443a 50434c58 starting the cups usb backend some seconds after plugging the printer in gives de8fbac0 2123539163 S Bi:003:02 -115 8192 < ddba3860 2123539196 S Ci:003:00 s a1 00 03ff 1023 < ddba3860 2128538251 C Ci:003:00 -104 0 de8fbac0 2128539243 C Bi:003:02 -2 0 just as before. - 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: Changes to sysfs PM layer break userspace
On Fri, Dec 22, 2006 at 08:44:01PM +, Pavel Machek wrote: > Hi! > > > > which userspace is using this btw? > > > > Ubuntu uses it to disable wireless hardware under certain circumstances. > > I believe that Suse's powernowd uses it to power down wired ethernet > > hardware when it's not in use. Powersaved had implemented this, but it was always declared an experimental feature and AFAIK is gone since quite some time. > I flamed seife for this. It was always broken for 20%-or-so of > hardware. It is _not_ simple to fix. It was an experimental feature in the words sense: For experimentation. I never accepted any bugreports for that but told the reporters to go away :-) -- Stefan Seyfried QA / R Team Mobile Devices| "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." - 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/4] Add MMC Password Protection (lock/unlock) support V8: mmc_sysfs.diff
Anderson Briglia wrote: > Ok. I will fix the code and send another version of this patch on the V9 > series e-mail thread. > Have you found the time to fix this? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - 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: Finding hardlinks
If user (or script) doesn't specify that flag, it doesn't help. I think the best solution for these filesystems would be either to add new syscall int is_hardlink(char *filename1, char *filename2) (but I know adding syscall bloat may be objectionable) it's also the wrong api; the filenames may have been changed under you just as you return from this call, so it really is a "was_hardlink_at_some_point()" as you specify it. If you make it work on fd's.. it has a chance at least. Yes, but it doesn't matter --- if the tree changes under "cp -a" command, no one guarantees you what you get. int fis_hardlink(int handle1, int handle 2); Is another possibility but it can't detect hardlinked symlinks. Mikulas - 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: bcm43xx from 2.6.20-rc1-mm1 on HPC nx6325 (x86_64)
Hi, On Friday, 22 December 2006 18:30, Larry Finger wrote: > I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on > an HPC nx6325, with no luck, so far, although I'm using a firmware that has > been reported to work with these boxes > (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29). > > The driver loads and seems to operate the hardware to some extent, but there > seems to be a problem with interrupts. Namely, the chip doesn't seem to > generate any. > Raphael J. Wysocki wrote: > > > Right after a fresh 'modprobe bcm43xx' I get the following messages in > dmesg: > > > bcm43xx driver > > ACPI: PCI Interrupt :30:00.0[A] -> GSI 18 (level, low) -> IRQ 18 > > PCI: Setting latency timer of device :30:00.0 to 64 > > bcm43xx: Chip ID 0x4311, rev 0x1 > > bcm43xx: Number of cores: 4 > > bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243 > > bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243 > > bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243 > > bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243 > > bcm43xx: PHY connected > > bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8 > > bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) > > bcm43xx: Radio turned off > > bcm43xx: Radio turned off > > PM: Adding info for No Bus:eth1 > > printk: 3 messages suppressed. > > SoftMAC: ASSERTION FAILED (0) at: > > net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate() > > > > but, strangely enough, eth1 does not appear, but eth2 appears instead: > > > > Usually the problem generates an oops, but I think your problem is due to the > changes in the work > struct in 2.6.20-rc1. There is a fix in the pipeline, but it has not > propagated through the system. > > You should apply the work_struct2 patch attached. If your computer has a > switch to kill the RF, you > may also wish to apply the radio_hwenable patch, which should cause the radio > LED to be turned on. > > The selection of eth2 rather than eth1 is probably due to the rules in > /etc/udev/rules.d/30-net_persistent_names.rules. Ah, I'll check that, thanks. It used to be eth1, though, and I haven't changed the udev configuration myself. > When I boot a softmac version, my bcm43xx device is > wlan0, but when I boot the d80211 version, it is eth1. I have a second > bcm43xx card, which becomes > eth2 under softmac. Thanks for the patch. In the meantime I've browsed the bcm43xx-dev archives and found some other interesting patches for me to try. ;-) Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - 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] change WARN_ON back to "BUG: at ..."
On Sat, 23 Dec 2006, Ingo Molnar wrote: > > i can whip up a patch for any of these conversions, but i dont think we > need this flux right now. > I agree, it's not needed right now. But making BUG_ON panic seems to be a good idea, but if you do make that change (and even if you don't), could you please add the dump_stack into panic (like you have in -rt)? Thanks! -- Steve - 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] MMCONFIG: Fix x86_64 ioremap base_address
Hi, Arjan van de Ven <[EMAIL PROTECTED]> writes: > On Sat, 2006-12-23 at 10:02 +0900, OGAWA Hirofumi wrote: >> Current -mm's mmconfig has some problems of remapped range. >> >> a) In the case of broken MCFG tables on Asus etc., we need to remap >> 256M range, but currently only remap 1M. > > I respectfully disagree. If the MCFG table is broken, we should not use > it AT ALL. It's either a correct table, and we can use it, or it's so > broken that we know it never has been tested etc etc, we're just better > of to not trust it in that case. Hm.. I see. Sounds sane to me. Well, my patch didn't add the new workaround of broken table, it just fixes the oops of existence workaround. Current workaround is the following (both of linus and -mm), if (pci_mmcfg_config_num == 1 && cfg->pci_segment_group_number == 0 && (cfg->start_bus_number | cfg->end_bus_number) == 0) /* Assume it can access 256M range */ But, if the system has bus number 0 only, it's a correct table. We may need to detect the broken system. blacklist? -- OGAWA Hirofumi <[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 2.6.20-rc1 6/6] S3C2410 GPIO wrappers
On Thu, Dec 21, 2006 at 11:33:11AM +0100, Arnaud Patard wrote: > > +#include > > imho, this is not needed. The user who will use irq will add it in his > code anyway. > > > +#include This is a pet peave. _NO_ drivers should include either of these two headers directly. Use asm/irq.h and asm/hardware.h instead. Audit your code to ensure that you're including the right headers please. I can see that I've got to do another sweep of the entire kernel code to fix all these again. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add i386 idle notifier (take 3)
On Fri, Dec 22, 2006 at 02:07:00AM -0800, Stephane Eranian wrote: > Andrian, > > On Fri, Dec 22, 2006 at 02:06:41AM +0100, Adrian Bunk wrote: > > > changelog: > > > - add a notifier mechanism to the low level idle loop. You can > > > register a callback function which gets invoked on entry and exit > > > from the low level idle loop. The low level idle loop is defined as > > > the polling loop, low-power call, or the mwait instruction. Interrupts > > > processed by the idle thread are not considered part of the low level > > > loop. The notifier can be used to measure precisely how much is spent > > > in useless execution (or low power mode). The perfmon subsystem uses > > > it > > > to turn on/off monitoring. > > > > > > Why is this patch not submitted as part of the perfmon patch that also > > adds a user of this code? > > If you look at the perfmon-new-base patch, you'll see a base.diff patch which > includes this one. I am slowly getting rid of this requirement by pushing > those "infrastructure patches" to mainline so that the perfmon patch gets > smaller over time. Submitting smaller patches makes it easier for maintainers > to integrate. No, the preferred way is to start with getting both the infrastructure and the users into -mm. Adding infrastructure without users doesn't fit into the kernel development model. The unused x86-64 idle notifiers are now bloating the kernel since nearly one year. > > And why does it bloat the kernel with EXPORT_SYMBOL's although even your > > perfmon-new-base-061204 doesn't seem to add any modular user? > > I have tried to stay as close as possible from the x86-64 implementation > of this mechanism. The registration entry points are exported to modules, > just like they are for x86-64. Also note that the x86-64 idle notifier does > not have a user at this point, yet it is in the kernel. Perfmon will become > the first user of this mechanism. Where does the perfmon code use the EXPORT_SYMBOL's? And having added bloat on one architecture is not an excuse for adding bloat on other architectures. > -Stephane cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.20-rc1 5/6] SA1100 GPIO wrappers
On Wed, Dec 20, 2006 at 01:13:21PM -0800, David Brownell wrote:
> Arch-neutral GPIO calls for SA-1100.
>
> From: Philipp Zabel <[EMAIL PROTECTED]>
>
> +static inline unsigned gpio_to_irq(unsigned gpio)
> +{
> + if (gpio < 11)
> + return IRQ_GPIO0 + gpio;
> + else
> + return IRQ_GPIO11 - 11 + gpio;
> +}
> +
> +static inline unsigned irq_to_gpio(unsigned irq)
> +{
> + if (irq < IRQ_GPIO11_27)
> + return irq - IRQ_GPIO0;
> + else
> + return irq - IRQ_GPIO11 + 11;
> +}
Why do we need to convert between IRQ and PGIO numbers? This is NOT
something that drivers should even care about - it's something that the
interrupt subsystem should know when being asked to claim an GPIO-based
IRQ.
That's something I worked hard to eliminate from the SA1100 drivers,
please don't reintroduce this silly idea again.
When the interrupt system is asked to claim a IRQ corresponding to a
GPIO, it should deal with all the stuff necessary to ensure that the
GPIO is in the required state. Drivers should not be considering
converting IRQ numbers to GPIOs or vice versa.
Doing otherwise is just plain silly - are we expecting to add GPIO
support to all Linux drivers which could possibly be used on ARM, just
because their interrupt pin might possibly be connected to a GPIO?
Get real - if you're dealing with IRQs use _only_ IRQ numbers. Don't
even think that drivers should be able to convert between IRQ and GPIO
numbers.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 21, 2006 at 03:38:29PM +, Pavel Machek wrote: > On Thu 14-12-06 20:51:36, Adrian Bunk wrote: > > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote: > > > On Thu, Dec 14, 2006 at 04:33:47PM +, Alan wrote: > > > > > The trick is to let a lawyer send cease and desist letters to people > > > > > distributing the infringing software for 1 Euro at Ebay. > > > > > > > > Doesn't that sound even more like the music industry ? Pick on Grandma, > > > > and people who've no clue about the issue. It's not the way to solve > > > > such > > > > problems. The world does not need "The war on binary modules". Educate > > > > people instead, and talk to vendors. > > > > > > or like Microsoft, who is threatening to make war on end-users > > > instead of settling things with vendors. (One of the reasons why I > > > personally find the Microsoft promise not to sue _Novell_'s end users > > > so nasty. Microsoft shouldn't be threatening anyone's users; if they > > > have a problem, they should be taking it up with the relevant vendor, > > > not sueing innocent and relatively shallow-pocketed end-users and > > > distributors.) > > > > > > One of the things that I find so interesting about how rabid people > > > get about enforcing GPL-only modules is how they start acting more and > > > more like the RIAA, MPAA, and Microsoft every day > > > > Please don't think or imply I'd plan to do this, I'm only saying that > > there's a risk for users in such grey areas. > > > > It could be that someone who wants to harm Linux starts suing people > > distributing Linux. If your goal is to harm Linux, suing users can > > simply be much more effective than suing vendors... > > > > It could even be that people distributing Linux could receive cease and > > desist letters from people without any real interest in the issue > > itself - "cease and desist letter"s are so frequent in Germany because > > the people who have to sign them have to pay the lawyers' costs that are > > usually > 1000 Euro, and that's a good business for the lawyers. > > Something is very wrong with German legal system, I'm afraid. The point that you can take legal actions against anyone distributing something that violates your rights should be present in more or less all legal systems. What might be special in Germany is only that you can demand your costs after successfully taking legal actions. > Pavel cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: io_submit delay problems revisited
On Fri, 2006-12-22 at 22:16 -0500, Patrick Reynolds wrote: > I believe that io_submit() blocks when it shouldn't. I have read the two > recent LKML threads on the subject. > Any ideas? > AIO to files isn't actually asynchronous (with the possible exception of O_DIRECT opened files). > --Patrick -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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] change WARN_ON back to "BUG: at ..."
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > WARN_ON is still a BUG, but we know enough about it that we can just > cripple the system so that it doesn't break anything. [...] well - a WARN_ON() can be /anything/. It is the same as BUG_ON(), but it doesnt crash the box immediately and on purpose. In that sense all existing BUG_ON()s should be converted to WARN_ON()s or to panic()s (whichever fits best for that particular BUG_ON()). [ or all WARN_ON()s should be converted to BUG_ON()s and the behavior of BUG_ON() should be changed to /not/ crash the system on purpose - and for those cases where we really do not want to continue, panic() should be used. That way the user can set panic policy himself. ] i can whip up a patch for any of these conversions, but i dont think we need this flux right now. 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.19-rt14 slowdown compared to 2.6.19
* Chen, Tim C <[EMAIL PROTECTED]> wrote: > Ingo, > > We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19 > kernel and noticed several slowdowns. The test machine is a 2 socket > woodcrest machine with your default configuration. cool - thanks for the feedback! Running the 64-bit kernel, right? > Netperf TCP Streaming was slower by 40% ( 1 server and 1 client each > bound to separate cpu cores on different socket, network loopback mode > was used). > > Volanomark was slower by 80% (Server and Clients communicate with > network loopback mode. Idle time goes from 1% to 60%) > > Re-Aim7 was slower by 40% (idle time goes from 0% to 20%) > > Wonder if you have any suggestions on what could cause the slowdown. > We've tried disabling CONFIG_NO_HZ and it didn't help much. while some slowdown is to be expected, did in each case idle time increase significantly? If yes then this is the effect of lock contention. Lock contention effects are 'magnified' by PREEMPT_RT. For example if you run 128 threads workload that all use the same lock then the -rt kernel can act as if it were a 128-way box (!). This way by running -rt you'll see scalability problems alot sooner than on real hardware. In other words: PREEMPT_RT in essence simulates the scalability behavior of up to an infinite amount of CPUs. (with the exception of cachemiss emulation ;) [the effect is not this precise, but that's the rough trend] the good news: any fix for such problems in -rt is useful for the upstream kernel too, because it improves scalability on real hardware as well. The bad news: this work hasnt been finished yet ;-) We've fixed a couple of contention points discovered by -rt this way, in particular Peter's excellent scalability patches at: http://programming.kicks-ass.net/kernel-patches/ were done based on lock-contention profiling feedback. I've included the lockless pagecache and the s_files scalability patches which were very useful already. The lru_cache_add one is the next one for me to try, plus on i686 -rt kernels highmem locking hurts, hence the highmem_rewrite.patch (not in -rt yet either). Plus there's the really exciting concurrent-pagecache patch-queue from Peter, which will be interesting to try too. If you'd like to profile this yourself then the lowest-cost way of profiling lock contention on -rt is to use the yum kernel and run the attached trace-it-lock-prof.c code on the box while your workload is in 'steady state' (and is showing those extended idle times): ./trace-it-lock-prof > trace.txt this captures up to 1 second worth of system activity, on the current CPU. Then you can construct the histogram via: grep -A 1 ' __schedule()<-' trace.txt | cut -d: -f2- | sort | uniq -c | sort -n > prof.txt i just did this for "hackbench 20", and it gave me: 38 kfree()<-skb_release_data()<-kfree_skbmem()<-(-1)() 40 kmem_cache_free()<-kfree_skbmem()<-__kfree_skb()<-(-1)() 47 __schedule()<-preempt_schedule_irq()<-retint_kernel()<-__spin_unlock_irqrestore() 173 rt_read_lock()<-sock_def_readable()<-unix_stream_sendmsg()<-(-1)() 173 __schedule()<-schedule()<-rt_spin_lock_slowlock()<-__lock_text_start() 274 __schedule()<-schedule()<-posix_cpu_timers_thread()<-kthread() 277 __schedule()<-schedule()<-ksoftirqd()<-kthread() 365 kmem_cache_alloc_node()<-__alloc_skb()<-sock_alloc_send_skb()<-(-1)() 366 kmem_cache_alloc_node()<-__kmalloc_node()<-__alloc_skb()<-(-1)() 814 __schedule()<-schedule()<-rt_spin_lock_slowlock()<-rt_spin_lock() 1819 __schedule()<-schedule()<-int_careful()<-() 2346 __schedule()<-schedule()<-schedule_timeout()<-unix_stream_recvmsg() 2346 sock_aio_read()<-do_sync_read()<-vfs_read()<-(-1)() (note the output mixes the two lines of symbolic stack backtrace entries that are generated by the tracer, so the last two lines for example are for the same contention/preemption point.) this means that the biggest contention points (or natural rescheduling points) in this workload are sock_aio_read()->unix_stream_recvmsg() - not unexpected. But there's also ~10% of contention in the kmalloc code, meaning that for this workload the per-CPU slabs are probably set a bit too low. There's also ~5% of contention from sock_def_readable()'s use of an rwlock. with more CPUs and more tasks you'll see these effects in a more drastic way. Ingo /* * Copyright (C) 2005, Ingo Molnar <[EMAIL PROTECTED]> * * user-triggered tracing. * * The -rt kernel has a built-in kernel tracer, which will trace * all kernel function calls (and a couple of special events as well), * by using a build-time gcc feature that instruments all kernel * functions. * * The tracer is highly automated for a number of latency tracing purposes, * but it can also be switched into 'user-triggered' mode, which is a * half-automatic tracing mode where userspace apps start and stop the *
[PATCH] usbhid quirks for macbook(pro) updated to 2.6.20-rc1
On Fri, 2006-12-15 at 09:56 -0800, Greg KH wrote:
> On Fri, Dec 15, 2006 at 09:36:04AM +0100, Soeren Sonnenburg wrote:
> > On Sat, 2006-12-09 at 21:08 -0500, Joseph Fannin wrote:
> > > On Fri, 2006-12-08 at 18:19 +0100, Soeren Sonnenburg wrote:
[...]
> > Greg,
> >
> > I've noticed that this patch is not in 2.6.20-rc1. Could you please
> > comment on what is wrong with it / whether it will ever have a chance to
> > be accepted in the way it is done ?
>
> It's in my queue right now, sorry. I'll catch up on it in a few hours.
Please find attached a updated version of this patch (for kernel
2.6.20-rc1)
Soeren
--
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
Signed-off-by: Soeren Sonnenburg <[EMAIL PROTECTED]>
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
diff -ur linux-2.6.20-rc1-orig/drivers/usb/input/hid-core.c linux-2.6.20-rc1/drivers/usb/input/hid-core.c
--- linux-2.6.20-rc1-orig/drivers/usb/input/hid-core.c 2006-12-14 02:14:23.0 +0100
+++ linux-2.6.20-rc1/drivers/usb/input/hid-core.c 2006-12-23 10:21:49.0 +0100
@@ -772,6 +772,7 @@
#define USB_DEVICE_ID_APPLE_GEYSER4_JIS 0x021c
#define USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY 0x030a
#define USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY 0x030b
+#define USB_DEVICE_ID_APPLE_IR 0x8240
#define USB_VENDOR_ID_CHERRY 0x046a
#define USB_DEVICE_ID_CHERRY_CYMOTION 0x0023
@@ -942,19 +943,19 @@
{ USB_VENDOR_ID_CHERRY, USB_DEVICE_ID_CHERRY_CYMOTION, HID_QUIRK_CYMOTION },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_POWERBOOK_ISO_KEYBOARD},
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_POWERBOOK_ISO_KEYBOARD},
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_POWERBOOK_ISO_KEYBOARD},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_POWERBOOK_ISO_KEYBOARD},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_POWERBOOK_ISO_KEYBOARD},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
{ USB_VENDOR_ID_PANJIT, 0x0001, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_PANJIT, 0x0002, HID_QUIRK_IGNORE },
@@ -1060,6 +1061,11 @@
if (quirks & HID_QUIRK_IGNORE)
return NULL;
+ if ((quirks & HID_QUIRK_IGNORE_MOUSE) &&
+ (interface->desc.bInterfaceProtocol == USB_INTERFACE_PROTOCOL_MOUSE))
+ return NULL;
+
+
if (usb_get_extra_descriptor(interface, HID_DT_HID, ) &&
(!interface->desc.bNumEndpoints ||
usb_get_extra_descriptor(>endpoint[0], HID_DT_HID, ))) {
diff -ur linux-2.6.20-rc1-orig/include/linux/hid.h linux-2.6.20-rc1/include/linux/hid.h
--- linux-2.6.20-rc1-orig/include/linux/hid.h 2006-12-14 02:14:23.0
[PATCH] make fn_keys work again on power/macbooks on linux-2.6.20-rc1
Dear all, The apple fn keys don't work anymore with 2.6.20-rc1. The reason is that USB_HID_POWERBOOK appears in several files although USB_HIDINPUT_POWERBOOK is the thing to be used. the attached trivial patch fixes this. Please apply. Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. Signed-off-by: Soeren Sonnenburg <[EMAIL PROTECTED]> diff -ur linux-2.6.20-rc1-orig/arch/i386/defconfig linux-2.6.20-rc1/arch/i386/defconfig --- linux-2.6.20-rc1-orig/arch/i386/defconfig 2006-12-14 02:14:23.0 +0100 +++ linux-2.6.20-rc1/arch/i386/defconfig 2006-12-23 11:13:07.0 +0100 @@ -1167,7 +1167,7 @@ # USB Input Devices # CONFIG_USB_HID=y -# CONFIG_USB_HID_POWERBOOK is not set +# CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # CONFIG_USB_AIPTEK is not set diff -ur linux-2.6.20-rc1-orig/arch/sparc64/defconfig linux-2.6.20-rc1/arch/sparc64/defconfig --- linux-2.6.20-rc1-orig/arch/sparc64/defconfig 2006-12-14 02:14:23.0 +0100 +++ linux-2.6.20-rc1/arch/sparc64/defconfig 2006-12-23 11:13:07.0 +0100 @@ -1103,7 +1103,7 @@ # USB Input Devices # CONFIG_USB_HID=y -# CONFIG_USB_HID_POWERBOOK is not set +# CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # CONFIG_USB_AIPTEK is not set diff -ur linux-2.6.20-rc1-orig/arch/x86_64/defconfig linux-2.6.20-rc1/arch/x86_64/defconfig --- linux-2.6.20-rc1-orig/arch/x86_64/defconfig 2006-12-14 02:14:23.0 +0100 +++ linux-2.6.20-rc1/arch/x86_64/defconfig 2006-12-23 11:13:07.0 +0100 @@ -1191,7 +1191,7 @@ # USB Input Devices # CONFIG_USB_HID=y -# CONFIG_USB_HID_POWERBOOK is not set +# CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # CONFIG_USB_AIPTEK is not set diff -ur linux-2.6.20-rc1-orig/drivers/usb/input/Kconfig linux-2.6.20-rc1/drivers/usb/input/Kconfig --- linux-2.6.20-rc1-orig/drivers/usb/input/Kconfig 2006-12-14 02:14:23.0 +0100 +++ linux-2.6.20-rc1/drivers/usb/input/Kconfig 2006-12-23 11:08:28.0 +0100 @@ -28,7 +28,7 @@ comment "Input core support is needed for USB HID input layer or HIDBP support" depends on USB_HID && INPUT=n -config USB_HID_POWERBOOK +config USB_HIDINPUT_POWERBOOK bool "Enable support for iBook/PowerBook special keys" default n depends on USB_HID
Re: [patch] sched: improve sched_clock() on i686
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> it's purely historic - the i686 sched_clock() implementation predates
> the scheduler's ability to deal with non-synchronous per-CPU clocks. I
> tried to fix that (a year ago) and it didnt work out - but i've
> reviewed my old patch and now realize what the mistake was - the patch
> below should work better.
that patch needs the small fix below as well.
Ingo
Index: linux/include/asm-i386/bugs.h
===
--- linux.orig/include/asm-i386/bugs.h
+++ linux/include/asm-i386/bugs.h
@@ -160,7 +160,7 @@ static void __init check_config(void)
* If we configured ourselves for a TSC, we'd better have one!
*/
#ifdef CONFIG_X86_TSC
- if (!cpu_has_tsc)
+ if (!cpu_has_tsc && !tsc_disable)
panic("Kernel compiled for Pentium+, requires TSC feature!");
#endif
-
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] MMCONFIG: Fix x86_64 ioremap base_address
On Sat, 2006-12-23 at 10:02 +0900, OGAWA Hirofumi wrote: > Current -mm's mmconfig has some problems of remapped range. > > a) In the case of broken MCFG tables on Asus etc., we need to remap > 256M range, but currently only remap 1M. Hi, I respectfully disagree. If the MCFG table is broken, we should not use it AT ALL. It's either a correct table, and we can use it, or it's so broken that we know it never has been tested etc etc, we're just better of to not trust it in that case. Greetings, Arjan van de Ven - 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: Finding hardlinks
> > If user (or script) doesn't specify that flag, it doesn't help. I think > the best solution for these filesystems would be either to add new syscall > int is_hardlink(char *filename1, char *filename2) > (but I know adding syscall bloat may be objectionable) it's also the wrong api; the filenames may have been changed under you just as you return from this call, so it really is a "was_hardlink_at_some_point()" as you specify it. If you make it work on fd's.. it has a chance at least. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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] usblp.c - add Kyocera Mita FS 820 to list of "quirky" printers
Am Freitag, 22. Dezember 2006 14:10 schrieben Sie:
> Your mailer has mangled tabs into whitespace. Also, your patch needs to
> be applicable with -p1 from the root kernel dir.
I think, it was more the copy and paste from the shell; should have included
the file instead.
> Given the description of the problem it is probably more worthwhile to
> provide logs with USB debugging enabled, and usbmon logs, so that the
> real problem can be found.
I´ll gladly do that best I can, but might need some help what to do. In the
following is what I found so far.
Two straces of the usb backend. First one that worked ok (some seconds after
pluuging the printer in):
[...]
rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
open("/dev/usblp0", O_RDWR|O_EXCL|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open("/dev/usb/lp0", O_RDWR|O_EXCL|O_LARGEFILE) = 3
ioctl(0x3, 0x84005001, 0xbfd67cd1) = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fd4000
write(1, "direct usb://Kyocera/FS-820 \"Kyo"..., 161direct
usb://Kyocera/FS-820 "Kyocera FS-820" "Kyocera FS-820 USB
#1"
"ID:FS-820;MFG:Kyocera;CMD:PCLXL,PCL5E,PJL;MDL:FS-820;CLS:PRINTER;DES:Kyocera
Mita FS-820;"
) = 161
close(3)= 0
open("/dev/usblp1", O_RDWR|O_EXCL|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
[...]
the ususal case (does not work):
[...]
rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
open("/dev/usblp0", O_RDWR|O_EXCL|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open("/dev/usb/lp0", O_RDWR|O_EXCL|O_LARGEFILE) = 3
ioctl(0x3, 0x84005001, 0xbfc397b1) = -1 (errno 5)
close(3)= 0
open("/dev/usblp1", O_RDWR|O_EXCL|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
[...]
Here a piece of the kernel messages with CONFIG_USB_DEBUG=y (started the usb
backend two times, reading printer ID does not work):
[...]
Dec 21 18:48:17 heinrich usb 3-5.4: usb timed out on ep0in len=0/1023
Dec 21 18:48:37 heinrich usb 3-5.4: usb timed out on ep0in len=0/1023
[...]
yes, that´s all with CONFIG_USB_DEBUG.
Then, there are syslog messages with "#define DEBUG" in usblp.c:
After plugging in the printer:
[...]
Dec 21 19:56:12 heinrich usb 1-5.4: new full speed USB device using ehci_hcd
and address 6
Dec 21 19:56:12 heinrich usb 1-5.4: configuration #1 chosen from 1 choice
Dec 21 19:56:12 heinrich drivers/usb/class/usblp.c: usblp0 set protocol 2
Dec 21 19:56:12 heinrich drivers/usb/class/usblp.c: usblp_control_msg: rq:
0x00 dir: 1 recip: 1 value: 0 idx:
0 len: 0x3ff result: 91
Dec 21 19:56:12 heinrich drivers/usb/class/usblp.c: usblp0 Device ID string
[len=91]="ID:FS-820;MFG:Kyocera;C
MD:PCLXL,PCL5E,PJL;MDL:FS-820;CLS:PRINTER;DES:Kyocera Mita FS-820;"
Dec 21 19:56:12 heinrich drivers/usb/class/usblp.c: usblp_control_msg: rq:
0x01 dir: 1 recip: 1 value: 0 idx:
0 len: 0x1 result: 1
Dec 21 19:56:12 heinrich drivers/usb/class/usblp.c: usblp0: USB Bidirectional
printer dev 6 if 0 alt 0 proto
2 vid 0x0482 pid 0x0010
Dec 21 19:56:15 heinrich drivers/usb/class/usblp.c: usblp_ioctl:
cmd=0x84005001 (P nr=1 len=1024 dir=2)
Dec 21 19:56:15 heinrich drivers/usb/class/usblp.c: usblp_control_msg: rq:
0x00 dir: 1 recip: 1 value: 0 idx:
0 len: 0x3ff result: 91
Dec 21 19:56:15 heinrich drivers/usb/class/usblp.c: usblp0 Device ID string
[len=91]="ID:FS-820;MFG:Kyocera;C
MD:PCLXL,PCL5E,PJL;MDL:FS-820;CLS:PRINTER;DES:Kyocera Mita FS-820;"
[So far, so good. I then call the usb backend to read the printer ID]:
Dec 21 19:56:18 heinrich drivers/usb/class/usblp.c: usblp_ioctl:
cmd=0x84005001 (P nr=1 len=1024 dir=2)
Dec 21 19:56:23 heinrich drivers/usb/class/usblp.c: usblp_control_msg: rq:
0x00 dir: 1 recip: 1 value: 0 idx:
0 len: 0x3ff result: -110
Dec 21 19:56:23 heinrich drivers/usb/class/usblp.c: usblp0: error = -110
reading IEEE-1284 Device ID string
[...]
This is what I know until know. What can I do next? Learning about usbmon?
Thanks for hints.
Martin
-
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: Changes to PM layer break userspace
Hi! > > That's a workable approach to resolving the underlying problem in the > > long term. In the short term, notice the system still works correctly > > if you don't try writing those files. > > Well, except I'm now burning an extra couple of watts of power. I > consider that pretty broken. Couple of watts is not that bad, considering usb still eats 4W more than it should. > > I'd not be keen on reverting Linus' patch [1] myself, even though few > > drivers have started to use that mechanism yet; that would be a step > > backwards, and would perpetuate users of that broken sysfs file. > > I'm sorry, which bit of "Don't break userspace API without adequate > prior warning and with a workable replacement" is difficult to > understand? It should not break any userspace... but you do not get the power savings any more. Sorry. This kind of powersaving is not available on recent kernels. Right fix is to extend wifi stack... and have ifconfig wlan0 powerdown, or something like that. Pavel -- Thanks for all the (sleeping) penguins. - 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: Changes to PM layer break userspace
Hi! > > The existence of the power/state interface wasn't a bug - it was a > > deliberate decision to add it. It's the only reason the > > dpm_runtime_suspend() interface exists. Actually, if we noticed power/state during PM framework review, it would have been killed. It is just way too ugly. > > > In contrast, the /sys/devices/.../power/state API has never had many > > > users beyond developers trying to test their drivers (without taking > > > the whole system into a low power state, which probably didn't work > > > in any case), and has *always* been problematic. And the change you > > > object to doesn't "break" anything fundamental, either. Everything > > > still works. > > > > It's used on every Ubuntu and Suse system, > > Odd how the relevant Suse developers didn't mention any issues with > those files going away, any of the times problems with them were > discussed on the PM list. Also, I have a Suse system that doesn't > use those files for anything ... maybe only newer release use it. Not on *every* suse system. power/state is known to oops kernels, so it is only enabled when user explicitely asks for 'dangerous aggresive experimental power saving' or something like that. -- Thanks for all the (sleeping) penguins. - 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/10] local_t : adding and standardising atomic primitives
Hi! > These patches extend and standardise local_t operations on each architectures, > allowing a rich set of atomic operations to be done on per-cpu data with > minimal performance impact. On some architectures, there seems to be no > difference between the SMP and UP operation (same memory barriers, same > LOCking), local.h simply includes asm-generic/local.h, which removes > duplicated > code. Could you provide some Documentation/? Knowing when local_t can be used is kind-of important. Pavel -- Thanks for all the (sleeping) penguins. - 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: Network drivers that don't suspend on interface down
Hi! > > about your driver list; > > do you have an idea of what the top 5 relevant ones would be? > > I'd be surprised if the top 5 together had less than 95% market share, > > so if we fix those we'd be mostly done already. > > In terms of what I've seen on vaguely modern hardware, I'd guess at > e1000 and sky2 as the top ones. b44 is still common in cheaper hardware, e1000 already powersaves when cable is not plugged in. Difference is ~0.5W, IIRC. Pavel -- Thanks for all the (sleeping) penguins. - 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: Changes to sysfs PM layer break userspace
Hi! > > which userspace is using this btw? > > Ubuntu uses it to disable wireless hardware under certain circumstances. > I believe that Suse's powernowd uses it to power down wired ethernet > hardware when it's not in use. I flamed seife for this. It was always broken for 20%-or-so of hardware. It is _not_ simple to fix. Pavel -- Thanks for all the (sleeping) penguins. - 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/
suspend to disk (was Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means))
Hi! > >Stop spreading fud. Take powersave + suspend from > >suse10.2, and see > >if you can break it. > > > >sata_nv seems to have problem, that's it. and it > >triggered problem in > >reiserfs. Use ext3 if you care about your data, and yes > >your drivers > >need to support suspend/resume. > > > My Compaq laptop, a Presario 2200, has video lockups > using suspend to disk and a dead system everytime I use > it. I don't Try with vga=1 (no framebuffer) and minimum number of modules. > think its fud. I also conceed its not Linux's fault most > of the time. These vendors put Windows specific hardware suspend to ram is usually video bios problem; suspend to disk tends to be linux problem. Pavel -- Thanks for all the (sleeping) penguins. - 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: moxa serial driver testing
Jiri,
Jiri Slaby <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> Hi Jiri,
>>
>> I've figured out that both old and new mxser drivers have two similar
>> problems:
>>
>> 1. When there are data coming to a port, sometimes opening of the port
>>entirely locks the box. This is quite reproducible. Any idea what's
>>wrong and how can I help to debug it?
>
> Could you test the patch below, if something changes?
Thanks for looking into it. I'll be able to get to the box with moxa
installed on Monday and will try the patch.
As for SysRq, I'm afraid it didn't work though I'm not 100% sure. I'll
check that as well.
-- Sergei.
> ---
>
> drivers/char/mxser_new.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/mxser_new.c b/drivers/char/mxser_new.c
> index a2bca5d..c0af201 100644
> --- a/drivers/char/mxser_new.c
> +++ b/drivers/char/mxser_new.c
> @@ -2268,6 +2268,8 @@ static irqreturn_t mxser_interrupt(int irq, void
> *dev_id)
> if (bits & irqbits)
> continue;
> port = >ports[i];
> + if (!(port->flags & ASYNC_INITIALIZED))
> + continue;
>
> int_cnt = 0;
> do {
> @@ -2320,9 +2322,9 @@ static irqreturn_t mxser_interrupt(int irq, void
> *dev_id)
> if (status & UART_LSR_THRE)
> mxser_transmit_chars(port);
> }
> - } while (int_cnt++ < MXSER_ISR_PASS_LIMIT);
> + } while (int_cnt++ < 256);
> }
> - if (pass_counter++ > MXSER_ISR_PASS_LIMIT)
> + if (pass_counter++ > 64)
> break; /* Prevent infinite loops */
> }
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] delayed allocation for ext4
On Sat, Dec 23, 2006 at 02:31:23PM +1100, David Chinner wrote: > > - ext4-delayed-allocation.patch > >delayed allocation itself, enabled by "delalloc" mount option. > >extents support is also required. currently it works only > >with blocksize=pagesize. > > Ah, that's why you can get away with a page flag - you've ignored > the partial page delay state problem. Any plans to use the > existing method in the future so we will be able to use ext4 delalloc > on machines with a page size larger than 4k? I think fixing this up for blocksize < pagesize is an absolute requirement to get things merged. We don't need more filesystems that are crippled on half of our platforms. Note that recording delayed alloc state at a page granularity in addition to just the buffer heads has a lot of advantages aswell and would help xfs, too. But I think it makes a lot more sense to record it as a radix tree tag to speed up the gang lookups for delalloc conversion. - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Fri, 2006-12-22 at 13:32 +0100, Martin Michlmayr wrote: > * Andrei Popa <[EMAIL PROTECTED]> [2006-12-22 14:24]: > > With all three patches I have corruption > > I've completed one installation with Linus' patch plus the two from > Andrew successfully, but I'm currently trying again... but I really > need a better testcase since an installation takes about an hour. > Andrei, which torrent do you download as a testcase? It would be good > if someone could suggest a torrent which is legal and not too large. It's a 1.4GB file torrent split in 84 rar files and there are many seeders. I download with ~ 5MB/sec. The torrent is private. - 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/
NFS root mount problem
Hi, I'm tying to run 2.6.18 kernel on ARM AT91RM9200DK board with NFS mount root filesystem. The printout from the boot is : Loading: # # # # done Bytes transferred = 1000118 (f42b6 hex) ## Booting image at 2100 ... Image Name: Image Type: ARM Linux Kernel Image (gzip compressed) Data Size:154 Bytes = 976.6 kB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... Linux version 2.6.18 ([EMAIL PROTECTED]) () #1 Fri Dec 22 14:45:47 CST 2006 CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177 Machine: Atmel AT91RM9200 Memory policy: ECC disabled, Data cache writeback Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Built 1 zonelists. Total pages: 8192 Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.10:/home_own/rootfs ip=192.168.0.12 console=ttyS0,115200 mem=32M AT91: 128 gpio irqs in 4 banks PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory: 32MB = 32MB total Memory: 30292KB available (1824K code, 209K data, 88K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 usbcore: registered new driver usbfs usbcore: registered new driver hub NET: Registered protocol family 2 IP route cache hash table entries: 256 (order: -2, 1024 bytes) TCP established hash table entries: 1024 (order: 0, 4096 bytes) TCP bind hash table entries: 512 (order: -1, 2048 bytes) TCP: Hash tables configured (established 1024 bind 512) TCP reno registered NetWinder Floating Point Emulator V0.97 (double precision) io scheduler noop registered io scheduler anticipatory registered (default) AT91 Watchdog Timer enabled (5 seconds, nowayout) at91_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL at91_usart.1: ttyS1 at MMIO 0xfffc4000 (irq = 7) is a AT91_SERIAL nbd: registered device at major 43 eth0: Link now 100-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (12:34:56:78:99:aa) eth0: Davicom 9161 PHY (Copper) physmap platform flash device: 0020 at 1000 Found: Atmel AT49BV16X physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank number of JEDEC chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. at91_cf: irqs det #64, io #0 usbmon: debugfs is not available at91_ohci at91_ohci: AT91 OHCI at91_ohci at91_ohci: new USB bus registered, assigned bus number 1 at91_ohci at91_ohci: irq 23, io mem 0x0030 usb usb1: Product: AT91 OHCI usb usb1: Manufacturer: Linux 2.6.18 ohci_hcd usb usb1: SerialNumber: at91 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected udc: at91_udc version 3 May 2006 mice: PS/2 mouse device common for all mice i2c /dev entries driver MMC: 4 wire bus mode not supported by this driver - using 1 wire TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 eth0: Link now 100-FullDuplex IP-Config: Guessing netmask 255.255.255.0 IP-Config: Complete: device=eth0, addr=192.168.0.12, mask=255.255.255.0, gw=255.255.255.255, host=192.168.0.12, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=192.168.0.10, rootpath= Root-NFS: Mounting /home_own/rootfs on server 192.168.0.10 as root Root-NFS: rsize = 4096, wsize = 4096, timeo = 0, retrans = 0 Root-NFS: acreg (min,max) = (3,60), acdir (min,max) = (30,60) Root-NFS: nfsd port = -1, mountd port = 0, flags = 0200 Looking up port of RPC 13/2 on 192.168.0.10 Root-NFS: Portmapper on server returned 2049 as nfsd port Looking up port of RPC 15/1 on 192.168.0.10 Root-NFS: mountd port is 792 NFS: nfs_mount(c0a8000a:/home_own/rootfs) VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or unknown-block(2,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) As you can see the network and the NFS mount come successful. It fails when to mount the root. I try to track the problem and it seems fails when to do_mount the path doesn't exist. The root path is fixed as "/root" if I change that to "/" it goes further but it fails on console. The console problem I think it's still related to the root mount being wrong even it passed with the change I did. Can anyone help or point out where to look for clues . - To unsubscribe from this list: send the line "unsubscribe
NFS root mount problem
Hi, I'm tying to run 2.6.18 kernel on ARM AT91RM9200DK board with NFS mount root filesystem. The printout from the boot is : Loading: # # # # done Bytes transferred = 1000118 (f42b6 hex) ## Booting image at 2100 ... Image Name: Image Type: ARM Linux Kernel Image (gzip compressed) Data Size:154 Bytes = 976.6 kB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... Linux version 2.6.18 ([EMAIL PROTECTED]) () #1 Fri Dec 22 14:45:47 CST 2006 CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177 Machine: Atmel AT91RM9200 Memory policy: ECC disabled, Data cache writeback Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Built 1 zonelists. Total pages: 8192 Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.10:/home_own/rootfs ip=192.168.0.12 console=ttyS0,115200 mem=32M AT91: 128 gpio irqs in 4 banks PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory: 32MB = 32MB total Memory: 30292KB available (1824K code, 209K data, 88K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 usbcore: registered new driver usbfs usbcore: registered new driver hub NET: Registered protocol family 2 IP route cache hash table entries: 256 (order: -2, 1024 bytes) TCP established hash table entries: 1024 (order: 0, 4096 bytes) TCP bind hash table entries: 512 (order: -1, 2048 bytes) TCP: Hash tables configured (established 1024 bind 512) TCP reno registered NetWinder Floating Point Emulator V0.97 (double precision) io scheduler noop registered io scheduler anticipatory registered (default) AT91 Watchdog Timer enabled (5 seconds, nowayout) at91_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL at91_usart.1: ttyS1 at MMIO 0xfffc4000 (irq = 7) is a AT91_SERIAL nbd: registered device at major 43 eth0: Link now 100-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (12:34:56:78:99:aa) eth0: Davicom 9161 PHY (Copper) physmap platform flash device: 0020 at 1000 Found: Atmel AT49BV16X physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank number of JEDEC chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. at91_cf: irqs det #64, io #0 usbmon: debugfs is not available at91_ohci at91_ohci: AT91 OHCI at91_ohci at91_ohci: new USB bus registered, assigned bus number 1 at91_ohci at91_ohci: irq 23, io mem 0x0030 usb usb1: Product: AT91 OHCI usb usb1: Manufacturer: Linux 2.6.18 ohci_hcd usb usb1: SerialNumber: at91 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected udc: at91_udc version 3 May 2006 mice: PS/2 mouse device common for all mice i2c /dev entries driver MMC: 4 wire bus mode not supported by this driver - using 1 wire TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 eth0: Link now 100-FullDuplex IP-Config: Guessing netmask 255.255.255.0 IP-Config: Complete: device=eth0, addr=192.168.0.12, mask=255.255.255.0, gw=255.255.255.255, host=192.168.0.12, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=192.168.0.10, rootpath= Root-NFS: Mounting /home_own/rootfs on server 192.168.0.10 as root Root-NFS: rsize = 4096, wsize = 4096, timeo = 0, retrans = 0 Root-NFS: acreg (min,max) = (3,60), acdir (min,max) = (30,60) Root-NFS: nfsd port = -1, mountd port = 0, flags = 0200 Looking up port of RPC 13/2 on 192.168.0.10 Root-NFS: Portmapper on server returned 2049 as nfsd port Looking up port of RPC 15/1 on 192.168.0.10 Root-NFS: mountd port is 792 NFS: nfs_mount(c0a8000a:/home_own/rootfs) VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device nfs or unknown-block(2,0) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) As you can see the network and the NFS mount come successful. It fails when to mount the root. I try to track the problem and it seems fails when to do_mount the path doesn't exist. The root path is fixed as /root if I change that to / it goes further but it fails on console. The console problem I think it's still related to the root mount being wrong even it passed with the change I did. Can anyone help or point out where to look for clues . - To unsubscribe from this list: send the line unsubscribe
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Fri, 2006-12-22 at 13:32 +0100, Martin Michlmayr wrote: * Andrei Popa [EMAIL PROTECTED] [2006-12-22 14:24]: With all three patches I have corruption I've completed one installation with Linus' patch plus the two from Andrew successfully, but I'm currently trying again... but I really need a better testcase since an installation takes about an hour. Andrei, which torrent do you download as a testcase? It would be good if someone could suggest a torrent which is legal and not too large. It's a 1.4GB file torrent split in 84 rar files and there are many seeders. I download with ~ 5MB/sec. The torrent is private. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] delayed allocation for ext4
On Sat, Dec 23, 2006 at 02:31:23PM +1100, David Chinner wrote: - ext4-delayed-allocation.patch delayed allocation itself, enabled by delalloc mount option. extents support is also required. currently it works only with blocksize=pagesize. Ah, that's why you can get away with a page flag - you've ignored the partial page delay state problem. Any plans to use the existing method in the future so we will be able to use ext4 delalloc on machines with a page size larger than 4k? I think fixing this up for blocksize pagesize is an absolute requirement to get things merged. We don't need more filesystems that are crippled on half of our platforms. Note that recording delayed alloc state at a page granularity in addition to just the buffer heads has a lot of advantages aswell and would help xfs, too. But I think it makes a lot more sense to record it as a radix tree tag to speed up the gang lookups for delalloc conversion. - 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: moxa serial driver testing
Jiri,
Jiri Slaby [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Hi Jiri,
I've figured out that both old and new mxser drivers have two similar
problems:
1. When there are data coming to a port, sometimes opening of the port
entirely locks the box. This is quite reproducible. Any idea what's
wrong and how can I help to debug it?
Could you test the patch below, if something changes?
Thanks for looking into it. I'll be able to get to the box with moxa
installed on Monday and will try the patch.
As for SysRq, I'm afraid it didn't work though I'm not 100% sure. I'll
check that as well.
-- Sergei.
---
drivers/char/mxser_new.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/char/mxser_new.c b/drivers/char/mxser_new.c
index a2bca5d..c0af201 100644
--- a/drivers/char/mxser_new.c
+++ b/drivers/char/mxser_new.c
@@ -2268,6 +2268,8 @@ static irqreturn_t mxser_interrupt(int irq, void
*dev_id)
if (bits irqbits)
continue;
port = brd-ports[i];
+ if (!(port-flags ASYNC_INITIALIZED))
+ continue;
int_cnt = 0;
do {
@@ -2320,9 +2322,9 @@ static irqreturn_t mxser_interrupt(int irq, void
*dev_id)
if (status UART_LSR_THRE)
mxser_transmit_chars(port);
}
- } while (int_cnt++ MXSER_ISR_PASS_LIMIT);
+ } while (int_cnt++ 256);
}
- if (pass_counter++ MXSER_ISR_PASS_LIMIT)
+ if (pass_counter++ 64)
break; /* Prevent infinite loops */
}
-
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: Changes to sysfs PM layer break userspace
Hi! which userspace is using this btw? Ubuntu uses it to disable wireless hardware under certain circumstances. I believe that Suse's powernowd uses it to power down wired ethernet hardware when it's not in use. I flamed seife for this. It was always broken for 20%-or-so of hardware. It is _not_ simple to fix. Pavel -- Thanks for all the (sleeping) penguins. - 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/
suspend to disk (was Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means))
Hi! Stop spreading fud. Take powersave + suspend from suse10.2, and see if you can break it. sata_nv seems to have problem, that's it. and it triggered problem in reiserfs. Use ext3 if you care about your data, and yes your drivers need to support suspend/resume. My Compaq laptop, a Presario 2200, has video lockups using suspend to disk and a dead system everytime I use it. I don't Try with vga=1 (no framebuffer) and minimum number of modules. think its fud. I also conceed its not Linux's fault most of the time. These vendors put Windows specific hardware suspend to ram is usually video bios problem; suspend to disk tends to be linux problem. Pavel -- Thanks for all the (sleeping) penguins. - 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/10] local_t : adding and standardising atomic primitives
Hi! These patches extend and standardise local_t operations on each architectures, allowing a rich set of atomic operations to be done on per-cpu data with minimal performance impact. On some architectures, there seems to be no difference between the SMP and UP operation (same memory barriers, same LOCking), local.h simply includes asm-generic/local.h, which removes duplicated code. Could you provide some Documentation/? Knowing when local_t can be used is kind-of important. Pavel -- Thanks for all the (sleeping) penguins. - 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: Changes to PM layer break userspace
Hi! The existence of the power/state interface wasn't a bug - it was a deliberate decision to add it. It's the only reason the dpm_runtime_suspend() interface exists. Actually, if we noticed power/state during PM framework review, it would have been killed. It is just way too ugly. In contrast, the /sys/devices/.../power/state API has never had many users beyond developers trying to test their drivers (without taking the whole system into a low power state, which probably didn't work in any case), and has *always* been problematic. And the change you object to doesn't break anything fundamental, either. Everything still works. It's used on every Ubuntu and Suse system, Odd how the relevant Suse developers didn't mention any issues with those files going away, any of the times problems with them were discussed on the PM list. Also, I have a Suse system that doesn't use those files for anything ... maybe only newer release use it. Not on *every* suse system. power/state is known to oops kernels, so it is only enabled when user explicitely asks for 'dangerous aggresive experimental power saving' or something like that. -- Thanks for all the (sleeping) penguins. - 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/
