Re: [patch] x86: fix ESP corruption CPU bug
Andi Kleen wrote: Stas Sergeev <[EMAIL PROTECTED]> writes: Another way of saying the same thing: I absolutely hate seeing patches that fix some theoretical issue that no Linux apps will ever care about. No, it is not theoretical, but it is mainly about a DOS games and an MS linker, as for me. The things I'd like to get working, but the ones you may not care too much about:) The particular game I want to get working, is "Master of Orion 2" for DOS. How about you just run it in dosbox instead of dosemu ? Yes, that's a solution of course, but it is a bit like saying why not use Open Office instead of MS Word. A long term goal of wine is to support DOS apps to. Of course it's not a priority, but it's there. regards, Jakob - 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/3] openfirmware: adds sysfs nodes for openfirmware devices
I choose the spec. If an implementation is not conformant to the spec, it doesn't "work". Not to say that Linux doesn't have to work around bugs in actual implementations, of course. And there's a lot of those. Too bad ;-) Yah, well.. ok, let's say we have a spec... and an implementation that represents about 90% of the machines concerned. Those 90% have the "bug"... what do you chose ? :) What do you mean? I already said we have to work around this bug -- but it IS a bug. That's all. The separator in "compatible", afaik, is \0, not space btw. Please re-read my original message? Yes the "separator" is 0x00; of course it isn't space, as space isn't allowed at all. On possibiliy would be to have the kernel replace spaces with underscores for the sake of matching. That would make life easier for everybody. Yes, that'll probably work just fine. Or use 0xb1, showing that this is "plus-minus" correct :-) Segher - 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/3] openfirmware: adds sysfs nodes for openfirmware devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin Herrenschmidt wrote: >>>Well, we have an unmaintained spec on one side that can't even be >>>ordered from IEEE anymore and actual imlementations that work today, >>>what do you chose ? ;) >> >>I choose the spec. If an implementation is not conformant to the spec, >>it doesn't "work". >> >>Not to say that Linux doesn't have to work around bugs in actual >>implementations, of course. And there's a lot of those. Too bad ;-) > > > Yah, well.. ok, let's say we have a spec... and an implementation that > represents about 90% of the machines concerned. Those 90% have the > "bug"... what do you chose ? :) > > The separator in "compatible", afaik, is \0, not space btw. > > On possibiliy would be to have the kernel replace spaces with > underscores for the sake of matching. That would make life easier for > everybody. I had suggested this a few days ago, but got no response. Can we agree that this would be an acceptable solution? - -Jeff - -- Jeff Mahoney SuSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCNauDLPWxlyuTD7IRAt+IAJ9mJRrrYT5trhv03qbGGPrwIwosqwCgpLS6 K/xQZE+dB4BPZc+R/FW74Nw= =9Pgi -END PGP SIGNATURE- - 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.11-mm3: SIS5513 DMA problem (set_drive_speed_status)
Hi,
just tried the 2.6.11-mm3 and at boot-time my start scripts try to
enable DMA on my disk (hdparm -m16 -c1 -u1 -X69 /dev/hda).
But while running hdparm, the kernel waits many seconds and gives me
some DMA warnings/errors:
[dmesg output]
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller at PCI slot :00:02.5
SIS5513: chipset revision 0
SIS5513: not 100% native mode: will probe irqs later
SIS5513: SiS 962/963 MuTIOL IDE UDMA133 controller
ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: WDC WD1600JB-00GVA0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: IDE DVD-ROM 16X, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
Probing IDE interface ide3...
Probing IDE interface ide4...
Probing IDE interface ide5...
hda: max request size: 1024KiB
hda: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(100)
hda: cache flushes supported
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 >
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
hda: set_drive_speed_status: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: dma_timer_expiry: dma status == 0x41
hda: DMA timeout error
hda: dma timeout error: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: DMA disabled
ide0: reset: success
hda: CHECK for good STATUS
hdc: Speed warnings UDMA 3/4/5 is not functional.
[/dmesg output]
That happened also with 2.6.11-rc3 since I thought I should switch away
from my 2.6.8-rc2-mm1 (the best kernel ever ;)).
In kernel config I enabled:
CONFIG_EDD=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_ACPI=y
My machine:
Pentium 4 - 2,4Ghz
cat /proc/interrupts:
14: 26411 XT-PIC ide0
15: 24 XT-PIC ide1
lspci -vvxxx:
:00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
(prog-if 80 [Master])
Subsystem: Silicon Integrated Systems [SiS] SiS5513 EIDE Controller
(A,B step)
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR-
Research & Development
TechnoTrend AG
pgpK2fapNoWAB.pgp
Description: PGP signature
Re: [PATCH 2/3] openfirmware: adds sysfs nodes for openfirmware devices
> > Well, we have an unmaintained spec on one side that can't even be > > ordered from IEEE anymore and actual imlementations that work today, > > what do you chose ? ;) > > I choose the spec. If an implementation is not conformant to the spec, > it doesn't "work". > > Not to say that Linux doesn't have to work around bugs in actual > implementations, of course. And there's a lot of those. Too bad ;-) Yah, well.. ok, let's say we have a spec... and an implementation that represents about 90% of the machines concerned. Those 90% have the "bug"... what do you chose ? :) The separator in "compatible", afaik, is \0, not space btw. On possibiliy would be to have the kernel replace spaces with underscores for the sake of matching. That would make life easier for everybody. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][-mm][1/2] cifs: whitespace cleanups for file.c
OK - the first of them is merged in to the cifs bk tree. The second one looks like an improvement on structuring of the cifs open logic but needs review. I may have a chance to test it later in the week. 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: bug in kernel
On Mon, 2005-03-14 at 15:51 +0100, Arjan van de Ven wrote:
> On Mon, 2005-03-14 at 17:48 +0300, Evgeniy wrote:
> > Here is a simple program.
> >
> > #include
> > #include
> > main(){
> > int err;
> > err=read(0,NULL,6);
> > printf("%d %d\n",err,errno);
> > }
> >
> > I think that it should be an error : Null pointer assignment, like in
> > windows.
> > But in practise it is not so.
> > Mandrake Linux kernel 2.4.21-0.13mdk
> > I am a programmer too and i am very interested to solve this problem.
> > Please,
> > send me fragment of sourse code of kernel with this bug.
>
> well what is the value of errno ?
> -EFAULT by chance ?
note that you need to include for the proper read() prototype
btw
-
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: bug in kernel
On Mon, 2005-03-14 at 17:48 +0300, Evgeniy wrote:
> Here is a simple program.
>
> #include
> #include
> main(){
> int err;
> err=read(0,NULL,6);
> printf("%d %d\n",err,errno);
> }
>
> I think that it should be an error : Null pointer assignment, like in windows.
> But in practise it is not so.
> Mandrake Linux kernel 2.4.21-0.13mdk
> I am a programmer too and i am very interested to solve this problem. Please,
> send me fragment of sourse code of kernel with this bug.
well what is the value of errno ?
-EFAULT by chance ?
-
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/
bug in kernel
Here is a simple program.
#include
#include
main(){
int err;
err=read(0,NULL,6);
printf("%d %d\n",err,errno);
}
I think that it should be an error : Null pointer assignment, like in windows.
But in practise it is not so.
Mandrake Linux kernel 2.4.21-0.13mdk
I am a programmer too and i am very interested to solve this problem. Please,
send me fragment of sourse code of kernel with this bug.
Thanks.
Sorry for my English
-
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: Call for help: list of machines with working S3
On Monday 14 March 2005 09:00, Pavel Machek wrote: > Hi! > > > * MySQL (hinders the actual suspension process and kicks the pc back to > > where it was) > > Try this patch... Works nicely. Thanks. Jan -- Most people don't need a great deal of love nearly so much as they need a steady supply. - 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: mouse with 2.6.10+
On Mon, Mar 14, 2005 at 02:52:00PM +0300, Michael Tokarev wrote: > After plugging in USB keyboard and loading uhci-hcd and > usbhid, the keyboard un-freeze, but mouse still didn't > work. So I tried re-loading psmouse module, and > surprizingly, mouse started working again, but now dmesg > says: > > input: PS2++ Logitech Wheel Mouse on isa0060/serio1 > > (normally it's > input: ImPS/2 Generic Wheel Mouse on isa0060/serio1 > ) > > and the mouse is moving very fast now. Previously > I either didn't able to make it work at all after such > freeze, or it worked automatically after loading usbhid. > > BTW, it's 2.6.10, I can't made it work with 2.6.11 at all. Can you try 'usb-handoff' on the kernel command line? -- Vojtech Pavlik SuSE Labs, SuSE CR - 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/3] openfirmware: adds sysfs nodes for openfirmware devices
Is whitespace (in any form) allowed in the compatible value? No. Only printable characters are allowed, that is, byte values 0x21..0x7e and 0xa1..0xfe; each text string is terminated by a 0x00; there can be several text strings concatenated in one "compatible" property. Yes, whitespace is used at least in the toplevel compatible file, like 'Power Macintosh' in some Pismo models. So those OF implementations violate the OF specification. Well, we have an unmaintained spec on one side that can't even be ordered from IEEE anymore and actual imlementations that work today, what do you chose ? ;) I choose the spec. If an implementation is not conformant to the spec, it doesn't "work". Not to say that Linux doesn't have to work around bugs in actual implementations, of course. And there's a lot of those. Too bad ;-) Segher - 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: [TTY] overrun notify issue during 5 minutes after booting
--- Andrew Morton <[EMAIL PROTECTED]> wrote: > moreau francis <[EMAIL PROTECTED]> wrote: > > How does this look? > It works well though I haven't tested the second correction. But it looks good... By the way, is it safe in "n_tty_receive_overrun" to call "printk" ? because the former can be called from IT context... Francis Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 0/2 Buddy allocator with placement policy (Version 9) + prezeroing (Version 4)
On Thu, 10 Mar 2005, Dave Hansen wrote:
> On Thu, 2005-03-10 at 09:22 -0800, Paul Jackson wrote:
> > In particular, I am working on preparing a patch proposal for a policy
> > that would kill a task rather than invoke the swapper. In
> > mm/page_alloc.c __alloc_pages(), if one gets down to the point of being
> > about to kick the swapper, if this policy is enabled (and you're not
> > in_interrupt() and don't have flag PF_MEMALLOC set), then ask
> > oom_kill_task() to shoot us instead. For some big HPC jobs that are
> > carefully sized to fit on the allowed memory nodes, swapping is a fate
> > worse than death.
> >
> > The natural place (for me, anyway) to hang such policies is off the
> > cpuset.
> >
I have not read up on cpuset before so I am assuming you are talking about
http://www.bullopensource.org/cpuset/ so correct me if I am wrong.
> > I am hopeful that cpusets will soon hit Linus's tree.
> >
> > Would it make sense to specify these buddy allocator fallback policies
> > per cpuset as well?
>
> That seems reasonable, but I don't think there necessarily be enough
> cpuset users to make this reasonable as the only interface.
>
> Seems like something VMA-based along the lines of madvise() or the NUMA
> binding API would be more appropriate. Perhaps default policies
> inherited from a cpuset, but overridden by other APIs would be a good
> compromise.
>
I would think that VMA is too fine-grained and there is not a really clean
way of specifying what fallback policy to use with madvise() unless we
hard-code a fixed number of policies. I agree that if cpuset is not
widely used, it should not be the only way of setting policy. However, the
NUMA binding API deals with memory ranges, not PIDs. Implementing the
fallbacks for memory ranges would be at the node or zone level, not PID
which could be a conflict with cpuset (for example, which takes priority
when both cpuset and node policies are set?). So, I don't think the numa
binding as it is today is exactly the way to go either.
First though, we have to define how a fallback policy would be implemented
and applied. Right now, there is one hard-coded policy (assuming that the
placement policy gets merged at some point in the future) that is
implemented in __rmqueue() and is applied at the zone level. It is
implemented as a while loop and the information it uses is;
Input: int[] Integer array of fallback allocation types
struct zone * zone is the zone being allocated from
int order being the required order
Output: struct free_area *area is the area we are going to allocate from
int current_order is the order of the free pages in area
So, a very rough fallback policy setup might look something like;
/*
* Fallback function fills this struct telling the allocator where to get
* free pages from
*/
struct fallback {
struct free_area*area;
unsigned long current_order;
};
/* struct that describes a fallback policy */
struct fallback_policy {
void (*fallback)(int *fallback_list, struct zone* zone, int order);
char name[10];
int id; /* set on register */
}
/* List of all available fallback policies */
struct list_head *fallback_policies;
/* Default policy to use */
struct fallback_policy default_policy = {
.fallback = fallback_lowfrag,
.name = "default",
.id = 0
};
/*
* Register a new fallback policy. Throws a wobbly if the name is already
* registered
*/
void register_fallback(struct fallback_policy *policy);
/* Unregister a fallback, calls BUG if policy == default_policy */
void unregister_fallback(struct fallback_policy *policy);
the fallback_lowfrag() function would just implement the current fallback
approach. Other users like hotplug or cpuset would create their own
fallback policy, populate a fallback_policy and register it. I think this
is similar to how IO schedulers are registered.
Next... How do we apply it.
I think the sensible level to have a fallback policy as at the mm_struct
level. If the mm does not have a pointer to a fallback_policy, it uses
the default. This would be inherited from either a cpuset or explicitly
set via a specific API (should it inherit across exec()? Initially, I
would think no)
Case 1: The cpuset case
cpuset has a pseudo filesystem called cfs that looks very like /sys
mounted on /dev/cpuset. Each directory under /dev/cpuset is a cpuset and
there are a number of files there. For fallbacks, a new file would be
there called fallback. Catting it would print something like
[default] hotplug noswapper
where the name between [] is what is currently set. To set a new fallback
policy, echo the new string name to fallback like
echo noswapper > fallback
Any process created with pexec() or is otherwise part of a cpuset will get
it's policy from here.
Case 2: Specific API
The NUMA binding API has a method that looks like this;
#include
int set_mempolicy(int policy, unsigned long *nodemask, unsigned long
Re: [PATCH 2/3] openfirmware: adds sysfs nodes for openfirmware devices
On Tue, Mar 15, Benjamin Herrenschmidt wrote: > what do you chose ? ;) I'm sure Rusty will prefer the non-whitespace version for depmod and module.alias - 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/3] openfirmware: adds sysfs nodes for openfirmware devices
On Sun, 2005-03-13 at 16:17 +0100, Segher Boessenkool wrote: > Sorry to follow up this late... > > >>> Is whitespace (in any form) allowed in the compatible value? > > No. Only printable characters are allowed, that is, byte values > 0x21..0x7e and 0xa1..0xfe; each text string is terminated by a > 0x00; there can be several text strings concatenated in one > "compatible" property. > > >> Yes, whitespace is used at least in the toplevel compatible file, like > >> 'Power Macintosh' in some Pismo models. > > So those OF implementations violate the OF specification. Well, we have an unmaintained spec on one side that can't even be ordered from IEEE anymore and actual imlementations that work today, what do you chose ? ;) Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange memory leak in 2.6.x
> > > See http://download.hennerich.de/kallsyms_20050312_1630.gz > > > > Great, just so that there is no confusion, I still need a new run > > of /proc/page_owner, the shorter time before the lockup the better. > > The machine locked up this morning again. See > > http://download.hennerich.de/page_owner_sorted_20050314_0740.bz2 > > for one of the last results of /proc/page_owner. It seems to be > obvious that the memory-leak seems to be the first entry: > > $ less page_owner_sorted_20050314_0740.bz2 > 881397 times: > Page allocated via order 0 > [0xc013962b] find_or_create_page+91 > [0xf8aa9955] reiserfs_prepare_file_region_for_write+613 > [0xf8aaa606] reiserfs_file_write+1366 > [0xc015765c] vfs_write+172 > [0xc015776c] sys_write+60 > [0xc0103879] sysenter_past_esp+82 [resolved addresses => names] > 13358 times: > Page allocated via order 0 > [0xc014817a] do_wp_page+282 > [0xc014914e] handle_mm_fault+302 > [0xc0113625] do_page_fault+501 > [0xc0104a7b] error_code+43 > > The sorted table of /proc/kallsyms looks like this: > > ... > f8aa90e0 t reiserfs_commit_page [reiserfs] > f8aa92e0 t reiserfs_submit_file_region_for_write[reiserfs] > f8aa9550 t reiserfs_check_for_tail_and_convert [reiserfs] > f8aa96f0 t reiserfs_prepare_file_region_for_write [reiserfs] > f8aaa0b0 t reiserfs_file_write [reiserfs] > f8aaa770 t reiserfs_aio_write [reiserfs] > f8aaa779 t .text.lock.file [reiserfs] > f8aaa7c0 t reiserfs_dir_fsync [reiserfs] > f8aaa7f0 t reiserfs_readdir [reiserfs] > f8aaad70 t make_empty_dir_item_v1 [reiserfs] > f8aaae50 t make_empty_dir_item [reiserfs] > f8aaafc0 t create_virtual_node [reiserfs] > f8aab520 t check_left [reiserfs] > f8aab670 t check_right [reiserfs] > f8aab7c0 t get_num_ver [reiserfs] > ... > > So I guess that we have a problem with the reiser filesystem?? > We are using reiserfs 3.6... > > Perhaps it's important to notice that the operating system > > - is no fresh installation of SuSE 9.2, but was updated from SuSE 8.2 > - is installed on that special hardware via a restore with the software > Mondo-Rescue v2.03 > > Unfortunately we were not able up to now to reproduce the bug with > identical hardware and simulated disk-io. Only the production environment > triggers the bug. > > > 0xf8aa9955 - 613 = 0xf8aa96f0: reiserfs_prepare_file_region_for_write > 0xf8aaa606 - 1366 = 0xf8aaa0b0: reiserfs_file_write > > Wild guessing: Is "reiserfs_prepare_file_region_for_write" used > to append new output to existent files only - and do we have a memory > leak inside of this function? The production machine is used as loghost > and syslog is writing several 100MB logfiles each day - which would be > a difference to the test hardware. [added Vladimir Saveliev to CC] The only thing that stands out is big page cache. However, looking at the previous OOM output it shows that it is zone normal that is completely out of memory and that highmem zone has lots of free memory. Let's see if the big sharks know what is going on... - 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/3] openfirmware: adds sysfs nodes for openfirmware devices
Sorry to follow up this late... Is whitespace (in any form) allowed in the compatible value? No. Only printable characters are allowed, that is, byte values 0x21..0x7e and 0xa1..0xfe; each text string is terminated by a 0x00; there can be several text strings concatenated in one "compatible" property. Yes, whitespace is used at least in the toplevel compatible file, like 'Power Macintosh' in some Pismo models. So those OF implementations violate the OF specification. Oh well, it was wishful thinking anyway. ;) I see two potential solutions: * Ideally, I'd like to find a character (pipe?) that isn't used in the Apple OF compatible property. I've been unable to find any documentation that specifies to this level of detail. (Well, without paying for the IEEE-1275 reference, and it may not even be there.) See 2.3.75 and 3.2.2.1.2 in the OF spec. Segher - 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.11] IBM TrackPoint support
On Mon, 14 Mar 2005 13:19:56 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote: > How much does it interpret the stream in non-transparent mode? Are > commands also passed through in soft transparent mode? > > I'm asking because we might want to implement a passthrough port > similarly to what the Synaptics driver does and allow extended protocol > mice to be connected to the external mouse port. I originally thought that I could implement something similar to the Synaptics driver. Unfortunately, while in transparent mode bytes are relayed unmodified with the TrackPoint controller disabled. In other words, no simultaneous usage. That doesn't mean extended protocol mice couldn't be supported in transparent mode however. I didn't find it particularly useful given the TrackPoint itself would be disabled. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: User mode drivers: part 2: PCI device handling (patch 1/2 for 2.6.11)
On Gwe, 2005-03-11 at 21:04, Albert Cahalan wrote: > > Still insufficient because the device might be hotplugged on you. You > > need a file handle that has the expected revocation effects on unplug > > and refcounts > > I was under the impression that a file handle would be returned. Then lets use that popular "open" system call - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: User mode drivers: part 1, interrupt handling (patch for 2.6.11)
On Llu, 2005-03-14 at 00:02, Peter Chubb wrote: > I can see there'd be problems if the code allowed shared interrupts, > but it doesn't. If you don't allow shared IRQ's its useless, if you do allow shared IRQ's it deadlocks. Take your pick 8) As to your comment about needing to do a few more I/O operations I agree. However if your need is for speed then you might want to just write a small IRQ helper module for the kernel or extend the syntax I proposed a little (its conveniently trivial to generate native code from this). There isn't much you can do about the status read without MWI on most chip designs (some get it right by posting status to system memory but not many) Alan - 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: inconsistent kallsyms data [2.6.11-mm2]
Sam Ravnborg wrote: On Thu, Mar 10, 2005 at 12:12:22PM +, Paulo Marques wrote: Paulo Marques wrote: [...] A simple and robust way is to do the sampling on a list of symbols sorted by symbol name. This way, even if the symbol positions that are given to scripts/kallsyms change, the symbols sampled will be the same. I'll do the patch to do this and send it ASAP. Ok, here it is. Dominik can you try the attached patch and see if it solves the problem? Hi Paulo. Hi Sam :) Alexander Stohr had similar problems with down and __sched_text_start. I figured out that what was causing the troubles was the fact that the linker generated symbol __sched_text_start changed value from pass 1 to pass 2. The reason for this was the alingment used within that section. Damn, you're right. Looking more carefully at Dominik's files I can see that on the first pass we have: T __sched_text_startPTR 0xc0420482 t __downPTR 0xc0420484 and on the second pass: t __downPTR 0xc0420484 T __sched_text_startPTR 0xc0420484 I only looked at the addresses on the second pass and noticed they were aliased symbols and that the symbol order changed from the first pass :P I never came around submitting this since I do not know what the correct number for function alignment is on different paltforms. If this will just align the beginning of a section, I don't think it will be a problem to always align at 8 bytes even on platforms that need only a 4 byte alignment. So I think that your patch should definitely go in, as it solves a real problem. As for my patch it could potentially solve problems that we don't currently have(*), so it is probably better to wait for them to appear before trying to solve an non-existent problem :) -- Paulo Marques - www.grupopie.com All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) (*) order of aliased symbols changing, or 'nm' returning non sorted addresses. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() doesn't respect SO_RCVLOWAT ?
In article <[EMAIL PROTECTED]> (at Mon, 14 Mar 2005 13:24:24 +), Alan Cox <[EMAIL PROTECTED]> says: > 1003.1g both agree with your expectations. The right list is probably > netdev@oss.sgi.com however. I've just forwarded this thread to netdev. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() doesn't respect SO_RCVLOWAT ?
On Gwe, 2005-03-11 at 20:26, Felix Matathias wrote: > Dear Alan, > > I am positive. I can setsockopt, and then, getsockopt returns the value > that I requested. Ok I misremembered - its SNDLOWAT that is locked to one in Linux. > Stevens very clearly states that SO_RCVLOWAT has a direct impact on > select() and I assumed that this would be the case for Linux. > What is the rationale for not complying with that ? Is it the micromanagement > of select() that you dislike ? Isn't a significant reduction in the > amount of read operations a real gain in high speed networking ? I believe since we implement SO_SNDLOWAT that its a bug. Stevens and 1003.1g both agree with your expectations. The right list is probably netdev@oss.sgi.com however. Alan - 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: about interrupt latency
On Sat, 12 Mar 2005 10:01:43 -0700 (MST), Zwane Mwaikambo <[EMAIL PROTECTED]> wrote: > On Wed, 9 Mar 2005, Francesco Oppedisano wrote: > > > On Tue, 8 Mar 2005 12:09:58 -0700 (MST), Zwane Mwaikambo > > <[EMAIL PROTECTED]> wrote: > > > > > At some cpu frequency point on i386 the main cause of your interrupt > > > service latency will be in the interrupt controller and how long from irq > > > assertion to the signal being recognised, resultant vector being > > > dispatched to the processor and the necessary interrupt controller > > > acknowledge steps required. This is also helped by the fact that the > > > Linux/i386 interrupt vector stubs are very small and fast, so there isn't > > > all that much code to execute to reach the ISR from the vector table. I'm > > > not sure if you've tested this, but you may notice that timer interrupt > > > via Local APIC will have lower dispatch latency than timer interrupt via > > > i8259 only. But that's all at the lower end of the latency graph, you will > > > most likely run into other sources on a busy system. > > > > > > Zwane > > > > > Very interesting zwanei haven't tested the local APICdo you > > think this dispatch time can vary with the system I/O load (many > > pending interrupts in the PIC)? > > The PIC/i386 setup cannot really pend interrupts so i would say no i don't > think the dispatch time would be affected. > > > I think the interrupt latency is influenced even by the code inside > > the kernel: if a lot of code is running with interrupts disabled then > > the interrupt latency will grow. Am i right? > > Yes that's correct, in fact this will be your major/main cause of > interrupt latency. > > > So probably we can state that the factors influencing the interrupt latency > > are: > > 1)Dispatching time in the PIC > > 2)Waiting time on the PIC (if there are pending interrupt of lower vector) > > With APIC/i386 this is more possible, if you're really interested you > should try and calculate the dispatch time using the same system (must > have an IOAPIC) and testing with the following combinations; > > PIC only (noapic, nolapic) > PIC + LAPIC (noapic) > IOAPIC + LAPIC > > You will probably find that the IOAPIC + LAPIC has the lowest dispatch > time. Also worth noting that the LAPIC can queue upto 2 vectors (on P4), > this allows for more interrupts to be ready for dispatch. > > > 3)fetching ISR from main memory > > 4)wait time when CPU is running with disabled interrupt > > > > Do U agree? > > A bit more on (4) > > 4a) wait time when CPU is running firmware (e.g. SMI/SMM, VGA BIOSes etc) > > Otherwise, yes i agree, good luck with your research. > > Zwane > - > 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/ > I am just a user, not sure if it is related. But with CONFIG_X86_UP_APIC and/or CONFIG_X86_UP_IOAPIC set my mouse behaviour is totally different, when playing games everything feels more "laggy". And it gives me what gamers call "negative acceleration". - 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/
hold task lock question
Hello, Should we hold some lock (like task_lock(tsk)) when test tsk->mm == _mm or any things else like tsk->mm ==0 ? Suppose it's the final test. Thanks -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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/
Resending ethernet packets to direct neighbours
Hi, i have a pc with five ethernet devices onto and want to resend ethernet packets coming in from one device to four direct neighbours (distance 1). Therefore i have installed a packet handler receiving skbs. Now i have the following questions: 1) is it enough to change the skb->dev to the output device, rebuild the ethernet header and call dev_queue_xmit()? 2) how to i get the destination ethernet address of the physically direct neighbour within the packet handler? I believe, that i have to use the neighour caches but have not idea how... Any help would be appreciated! Bye Matthias - 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: cpufreq on-demand governor up_treshold?
On Monday 14 March 2005 08:57, Eric Piel wrote: > Jan De Luyck a écrit : > > Hello lists, > > > > (please cc me from cpufreq list) > > > > I've since yesterday started using the ondemand governor. Seems to work > > fine, tho I can't seem to find a reason why it keeps scaling my processor > > speed upwards tho the processor use never exceeds 30% (been watching top > > -d 1). > > > > > > Any hints? > > You can try the three attached patches in the order : > ondemand-cleanup-factorise-idle-measurement-2.6.11.patch > ondemand-save-idle-up-for-all-cpu-2.6.11.patch > ondemand-automatic-downscaling-2.6.11-accepted.patch > > They are available on the cpufreq list but as it's difficult to access > it I'm sending them again, all together. These are the last things that > Venki and I have been working on. It should solve your problem > (actually, only the last patch, but it depends on the two previous > patches). Please, let me know if it works. Okay, now the behaviour of the ondemand governor looks more 'sane'. Thanks, it looks like a huge improvement :) Jan -- Snow and adolescence are the only problems that disappear if you ignore them long enough. - 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: Strange memory leak in 2.6.x
Hello, my brother got ill this weekend, so I'll continue this task: > > See http://download.hennerich.de/kallsyms_20050312_1630.gz > > Great, just so that there is no confusion, I still need a new run > of /proc/page_owner, the shorter time before the lockup the better. The machine locked up this morning again. See http://download.hennerich.de/page_owner_sorted_20050314_0740.bz2 for one of the last results of /proc/page_owner. It seems to be obvious that the memory-leak seems to be the first entry: $ less page_owner_sorted_20050314_0740.bz2 881397 times: Page allocated via order 0 [0xc013962b] find_or_create_page+91 [0xf8aa9955] +613 [0xf8aaa606] +1366 [0xc015765c] vfs_write+172 [0xc015776c] sys_write+60 [0xc0103879] sysenter_past_esp+82 13358 times: Page allocated via order 0 [0xc014817a] do_wp_page+282 [0xc014914e] handle_mm_fault+302 [0xc0113625] do_page_fault+501 [0xc0104a7b] error_code+43 The sorted table of /proc/kallsyms looks like this: ... f8aa90e0 t reiserfs_commit_page [reiserfs] f8aa92e0 t reiserfs_submit_file_region_for_write[reiserfs] f8aa9550 t reiserfs_check_for_tail_and_convert [reiserfs] f8aa96f0 t reiserfs_prepare_file_region_for_write [reiserfs] f8aaa0b0 t reiserfs_file_write [reiserfs] f8aaa770 t reiserfs_aio_write [reiserfs] f8aaa779 t .text.lock.file [reiserfs] f8aaa7c0 t reiserfs_dir_fsync [reiserfs] f8aaa7f0 t reiserfs_readdir [reiserfs] f8aaad70 t make_empty_dir_item_v1 [reiserfs] f8aaae50 t make_empty_dir_item [reiserfs] f8aaafc0 t create_virtual_node [reiserfs] f8aab520 t check_left [reiserfs] f8aab670 t check_right [reiserfs] f8aab7c0 t get_num_ver [reiserfs] ... So I guess that we have a problem with the reiser filesystem?? We are using reiserfs 3.6... Perhaps it's important to notice that the operating system - is no fresh installation of SuSE 9.2, but was updated from SuSE 8.2 - is installed on that special hardware via a restore with the software Mondo-Rescue v2.03 Unfortunately we were not able up to now to reproduce the bug with identical hardware and simulated disk-io. Only the production environment triggers the bug. 0xf8aa9955 - 613 = 0xf8aa96f0: reiserfs_prepare_file_region_for_write 0xf8aaa606 - 1366 = 0xf8aaa0b0: reiserfs_file_write Wild guessing: Is "reiserfs_prepare_file_region_for_write" used to append new output to existent files only - and do we have a memory leak inside of this function? The production machine is used as loghost and syslog is writing several 100MB logfiles each day - which would be a difference to the test hardware. Best regards Timo -- T+T Hennerich GmbH --- Zettachring 12a --- 70567 Stuttgart Fon:+49(711)720714-0 Fax:+49(711)720714-44 Vanity:+49(700)HENNERICH UNIX - Linux - Java - C Entwicklung/Beratung/Betreuung/Schulung http://www.hennerich.de/ - 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.11] IBM TrackPoint support
On Mon, Mar 14, 2005 at 07:01:23AM -0500, Stephen Evanchik wrote: > On Mon, 14 Mar 2005 09:19:49 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote: > > > +/* > > > + * Mode manipulation > > > + */ > > > +#define TP_SET_SOFT_TRANS (0x4E) /* Set mode */ > > > +#define TP_CANCEL_SOFT_TRANS (0xB9) /* Cancel mode */ > > > +#define TP_SET_HARD_TRANS (0x45) /* Mode can only be set */ > > > > What exactly is transparent mode? > > Transparency mode, when enabled, turns off the TrackPoint controller's > interpretation of the byte stream going to and coming from the > external PS/2 port if present. > > Soft transparency mode can be cancelled, while hard transparency mode > requires a reset of the device and possibly the machine. How much does it interpret the stream in non-transparent mode? Are commands also passed through in soft transparent mode? I'm asking because we might want to implement a passthrough port similarly to what the Synaptics driver does and allow extended protocol mice to be connected to the external mouse port. -- Vojtech Pavlik SuSE Labs, SuSE CR - 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.11] IBM TrackPoint support
On Mon, 14 Mar 2005 09:19:49 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote: > > +/* > > + * Mode manipulation > > + */ > > +#define TP_SET_SOFT_TRANS (0x4E) /* Set mode */ > > +#define TP_CANCEL_SOFT_TRANS (0xB9) /* Cancel mode */ > > +#define TP_SET_HARD_TRANS (0x45) /* Mode can only be set */ > > What exactly is transparent mode? Transparency mode, when enabled, turns off the TrackPoint controller's interpretation of the byte stream going to and coming from the external PS/2 port if present. Soft transparency mode can be cancelled, while hard transparency mode requires a reset of the device and possibly the machine. Stephen - 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] uml-export-getgid-for-hostfs
> EXPORT_SYMBOL_PROTO(getuid); > +EXPORT_SYMBOL_PROTO(getgid); please don't. as mentioned in the discussion about ROOT_DEV the whole code using it is bogus. - 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: mouse with 2.6.10+
Michael Tokarev wrote: [] 2.6.10 almost works, but sometimes, the whole input subsystem just "hungs", ie, both keyboard and mouse just stops working. Plugging in USB keyboard and loading usbhid module solves the problem - both keyboards and the mouse works after that, and I didn't yet notice the problem repeats after usbhid and usb keyboard is loaded. I wasn't able to determine when the problem occurs, for me it seems it hangs at some "random" point - sometimes after 5 minutes after boot, sometimes after a hour or so. Got another such "hung" and tried to debug it somehow. Did a task dump (echo t > /proc/sysrq-trigger when logged from network) -- nothing interesting; kseriod trace looks a bit weird but it is as weird in normal mode too: kseriod S 0 196 1 361 122 (L-TLB) c11f9f94 0046 c11f9000 c11f9000 c77d09e0 24de 6b1f3a71 0004 c11f06bc c11f9fc0 c11f9000 c11f9fd4 f000 c01c4d4e c11f9000 c11f0560 c0127c20 c11f9fcc c11f9fcc c11f0560 c77c7f60 Call Trace: [] serio_thread+0xbe/0x110 [] autoremove_wake_function+0x0/0x30 [] ret_from_fork+0x6/0x20 [] autoremove_wake_function+0x0/0x30 [] serio_thread+0x0/0x110 [] kernel_thread_helper+0x5/0x10 Everything on the system is sleeping. After plugging in USB keyboard and loading uhci-hcd and usbhid, the keyboard un-freeze, but mouse still didn't work. So I tried re-loading psmouse module, and surprizingly, mouse started working again, but now dmesg says: input: PS2++ Logitech Wheel Mouse on isa0060/serio1 (normally it's input: ImPS/2 Generic Wheel Mouse on isa0060/serio1 ) and the mouse is moving very fast now. Previously I either didn't able to make it work at all after such freeze, or it worked automatically after loading usbhid. BTW, it's 2.6.10, I can't made it work with 2.6.11 at all. /mjt - 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/2] uml: export getgid for hostfs
Export this symbol which is now needed for a typo fix (getuid() -> getgid()). Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> --- linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c |1 + 1 files changed, 1 insertion(+) diff -puN arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs arch/um/os-Linux/user_syms.c --- linux-2.6.11/arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs 2005-03-11 20:16:17.061368376 +0100 +++ linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c 2005-03-11 20:16:17.065367768 +0100 @@ -82,6 +82,7 @@ EXPORT_SYMBOL_PROTO(statfs); EXPORT_SYMBOL_PROTO(statfs64); EXPORT_SYMBOL_PROTO(getuid); +EXPORT_SYMBOL_PROTO(getgid); /* * Overrides for Emacs so that we follow Linus's tabbing style. _ - 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: A new 10GB Ethernet Driver by Chelsio Communications
Hi,
Few more coding style comments.
On Fri, 11 Mar 2005 11:21:32 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> diff -puN /dev/null drivers/net/chelsio/cxgb2.c
> --- /dev/null 2003-09-15 06:40:47.0 -0700
> +++ 25-akpm/drivers/net/chelsio/cxgb2.c 2005-03-11 11:13:06.0
> -0800
> @@ -0,0 +1,1284 @@
> +#ifndef HAVE_FREE_NETDEV
> +#define free_netdev(dev) kfree(dev)
> +#endif
Please drop this wrapper.
> + printk(KERN_INFO "%s: %s (rev %d), %s %dMHz/%d-bit\n", adapter->name,
> +bi->desc, adapter->params.chip_revision,
> +adapter->params.pci.is_pcix ? "PCIX" : "PCI",
> +adapter->params.pci.speed, adapter->params.pci.width);
> + return 0;
> +
> + out_release_adapter_res:
> + t1_free_sw_modules(adapter);
> + out_free_dev:
> + if (adapter) {
> + if (adapter->tdev)
> + kfree(adapter->tdev);
kfree() handles null pointers so please drop the redundant check.
> diff -puN /dev/null drivers/net/chelsio/gmac.h
> --- /dev/null 2003-09-15 06:40:47.0 -0700
> +++ 25-akpm/drivers/net/chelsio/gmac.h2005-03-11 11:13:06.0
> -0800
> @@ -0,0 +1,126 @@
> +
> +typedef struct _cmac_instance cmac_instance;
Please drop the typedef.
> diff -puN /dev/null drivers/net/chelsio/osdep.h
> --- /dev/null 2003-09-15 06:40:47.0 -0700
> +++ 25-akpm/drivers/net/chelsio/osdep.h 2005-03-11 11:13:06.0
> -0800
> @@ -0,0 +1,222 @@
> +#define DRV_NAME "cxgb"
> +#define PFX DRV_NAME ": "
> +
> +#define CH_ERR(fmt, ...) printk(KERN_ERR PFX fmt, ## __VA_ARGS__)
> +#define CH_WARN(fmt, ...) printk(KERN_WARNING PFX fmt, ## __VA_ARGS__)
> +#define CH_ALERT(fmt, ...) printk(KERN_ALERT PFX fmt, ## __VA_ARGS__)
> +
> +/*
> + * More powerful macro that selectively prints messages based on msg_enable.
> + * For info and debugging messages.
> + */
> +#define CH_MSG(adapter, level, category, fmt, ...) do { \
> + if ((adapter)->msg_enable & NETIF_MSG_##category) \
> + printk(KERN_##level PFX "%s: " fmt, (adapter)->name, \
> +## __VA_ARGS__); \
> +} while (0)
> +
> +#ifdef DEBUG
> +# define CH_DBG(adapter, category, fmt, ...) \
> +CH_MSG(adapter, DEBUG, category, fmt, ## __VA_ARGS__)
> +#else
> +# define CH_DBG(fmt, ...)
> +#endif
Please consider using dev_* helpers from instead.
> +
> +/* Additional NETIF_MSG_* categories */
> +#define NETIF_MSG_MMIO 0x800
> +
> +#define CH_DEVICE(devid, ssid, idx) \
> + { PCI_VENDOR_ID_CHELSIO, devid, PCI_ANY_ID, ssid, 0, 0, idx }
> +
> +#define SUPPORTED_PAUSE (1 << 13)
> +#define SUPPORTED_LOOPBACK(1 << 15)
> +
> +#define ADVERTISED_PAUSE (1 << 13)
> +#define ADVERTISED_ASYM_PAUSE (1 << 14)
> +
> +/*
> + * Now that we have included the driver's main data structure,
> + * we typedef it to something the rest of the system understands.
> + */
> +typedef struct adapter adapter_t;
Please drop the typedef.
> +
> +#define DELAY_US(x) udelay(x)
> +
> +#define TPI_LOCK(adapter) spin_lock(&(adapter)->tpi_lock)
> +#define TPI_UNLOCK(adapter) spin_unlock(&(adapter)->tpi_lock)
Please drop the obfuscating wrappers.
> +void t1_elmer0_ext_intr(adapter_t *adapter);
> +void t1_link_changed(adapter_t *adapter, int port_id, int link_status,
> + int speed, int duplex, int fc);
> +
> +static inline void DELAY_MS(unsigned long ms)
> +{
> + unsigned long ticks = (ms * HZ + 999) / 1000 + 1;
> +
> + while (ticks) {
> + set_current_state(TASK_UNINTERRUPTIBLE);
> + ticks = schedule_timeout(ticks);
> + }
> +}
Use msleep here.
> diff -puN /dev/null drivers/net/chelsio/subr.c
> --- /dev/null 2003-09-15 06:40:47.0 -0700
> +++ 25-akpm/drivers/net/chelsio/subr.c2005-03-11 11:13:06.0
> -0800
> +typedef struct {
> + u32 format_version;
> + u8 serial_number[16];
> + u8 mac_base_address[6];
> + u8 pad[2]; /* make multiple-of-4 size requirement explicit */
> +} chelsio_vpd_t;
Please drop the typedef.
Pekka
-
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 2/2] uml: cope with uml_net security fix
Pass the interface to close as an fd besides that by name... passing it by
name does not work with newer uml_net because that allows to ifconfig down
arbitrary interfaces, while if you have an open fd to the SLIP interface it
means you have full access to it (and thus can close it). Passing only by fd
does not work with older utilities, so we do both things (which does not
hurt).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.11-paolo/arch/um/drivers/slip_user.c |6 +-
1 files changed, 5 insertions(+), 1 deletion(-)
diff -puN arch/um/drivers/slip_user.c~uml-uml_net-security-fix
arch/um/drivers/slip_user.c
--- linux-2.6.11/arch/um/drivers/slip_user.c~uml-uml_net-security-fix
2005-03-11 20:33:21.367650152 +0100
+++ linux-2.6.11-paolo/arch/um/drivers/slip_user.c 2005-03-11
20:33:21.370649696 +0100
@@ -108,6 +108,9 @@ static int slip_tramp(char **argv, int f
err = -EINVAL;
}
}
+
+ os_close_file(fds[0]);
+
return(err);
}
@@ -128,6 +131,7 @@ static int slip_open(void *data)
sfd = os_open_file(ptsname(mfd), of_rdwr(OPENFLAGS()), 0);
if(sfd < 0){
printk("Couldn't open tty for slip line, err = %d\n", -sfd);
+ os_close_file(mfd);
return(sfd);
}
if(set_up_tty(sfd)) return(-1);
@@ -175,7 +179,7 @@ static void slip_close(int fd, void *dat
sprintf(version_buf, "%d", UML_NET_VERSION);
- err = slip_tramp(argv, -1);
+ err = slip_tramp(argv, pri->slave);
if(err != 0)
printk("slip_tramp failed - errno = %d\n", -err);
_
-
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/2] uml: export getgid for hostfs
Export this symbol which is now needed for a typo fix (getuid() -> getgid()). Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> --- linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c |1 + 1 files changed, 1 insertion(+) diff -puN arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs arch/um/os-Linux/user_syms.c --- linux-2.6.11/arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs 2005-03-11 20:16:17.061368376 +0100 +++ linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c 2005-03-11 20:16:17.065367768 +0100 @@ -82,6 +82,7 @@ EXPORT_SYMBOL_PROTO(statfs); EXPORT_SYMBOL_PROTO(statfs64); EXPORT_SYMBOL_PROTO(getuid); +EXPORT_SYMBOL_PROTO(getgid); /* * Overrides for Emacs so that we follow Linus's tabbing style. _ - 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 2/2] (undescribed patch)
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.11-paolo/arch/um/drivers/slip_user.c |6 +-
1 files changed, 5 insertions(+), 1 deletion(-)
diff -puN arch/um/drivers/slip_user.c~uml-uml_net-security-fix
arch/um/drivers/slip_user.c
--- linux-2.6.11/arch/um/drivers/slip_user.c~uml-uml_net-security-fix
2005-03-09 12:44:10.0 +0100
+++ linux-2.6.11-paolo/arch/um/drivers/slip_user.c 2005-03-09
12:44:10.0 +0100
@@ -108,6 +108,9 @@ static int slip_tramp(char **argv, int f
err = -EINVAL;
}
}
+
+ os_close_file(fds[0]);
+
return(err);
}
@@ -128,6 +131,7 @@ static int slip_open(void *data)
sfd = os_open_file(ptsname(mfd), of_rdwr(OPENFLAGS()), 0);
if(sfd < 0){
printk("Couldn't open tty for slip line, err = %d\n", -sfd);
+ os_close_file(mfd);
return(sfd);
}
if(set_up_tty(sfd)) return(-1);
@@ -175,7 +179,7 @@ static void slip_close(int fd, void *dat
sprintf(version_buf, "%d", UML_NET_VERSION);
- err = slip_tramp(argv, -1);
+ err = slip_tramp(argv, pri->slave);
if(err != 0)
printk("slip_tramp failed - errno = %d\n", -err);
_
-
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] uml-export-getgid-for-hostfs
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> --- linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c |1 + 1 files changed, 1 insertion(+) diff -puN arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs arch/um/os-Linux/user_syms.c --- linux-2.6.11/arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs 2005-03-11 20:15:37.347405816 +0100 +++ linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c 2005-03-11 20:15:43.868414472 +0100 @@ -82,6 +82,7 @@ EXPORT_SYMBOL_PROTO(statfs); EXPORT_SYMBOL_PROTO(statfs64); EXPORT_SYMBOL_PROTO(getuid); +EXPORT_SYMBOL_PROTO(getgid); /* * Overrides for Emacs so that we follow Linus's tabbing style. _ - 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: cpufreq on-demand governor up_treshold?
On Mon, Mar 14, 2005 at 08:57:52AM +0100, Eric Piel wrote: > BTW, DaveJ, Dominik, I couldn't find them in the daily-snapshot > available at codemonkey.org.uk. Should I worry, or is it just due to > some latency between your private trees and the public one? > This happens those days only when I upgrade the LINUX_2_4 branch (and only because its easier for me to diff between HEAD and LINUX_2_4). -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. - 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][1/2] cifs: whitespace cleanups for file.c
On Mon, 14 Mar 2005, Steven French wrote: > > > Here's the first of two patches with cleanups for fs/cifs/file.c > The patch looks safe enough but I can not get the patch to apply (pattch > always claims it is malformed) - whichever email clients I received it > from probably because of wrap at 80 columns or some conversion that > occurred in the email text of the patch, although evolution email client > also had problems with it being to big to cut and paste (but even trying > it in smaller chunks I could not get it to apply). If you could resend > it as a file that would be helpful. > I just send it to you as an attachment in private email. I'd rather not resend that big a file to the lists if not needed. I've also put the patches online here : http://www.linuxtux.org/~juhl/fs_cifs_file-whitespace-cleanups-part-1.patch http://www.linuxtux.org/~juhl/fs_cifs_file-whitespace-cleanups-part-2-and_cifs_open-rework.patch They won't live forever at that location, but I can leave them there for a few weeks at least. -- Jesper Juhl - 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: A new 10GB Ethernet Driver by Chelsio Communications
Some of my usual coding style comments...
On Fri, 11 Mar 2005 11:21:32 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> diff -puN /dev/null drivers/net/chelsio/osdep.h
> --- /dev/null 2003-09-15 06:40:47.0 -0700
> +++ 25-akpm/drivers/net/chelsio/osdep.h 2005-03-11 11:13:06.0
> -0800
> +static inline void *t1_malloc(size_t len)
> +{
> + void *m = kmalloc(len, GFP_KERNEL);
> + if (m)
> + memset(m, 0, len);
> + return m;
> +}
> +
> +static inline void t1_free(void *v, size_t len)
> +{
> + kfree(v);
> +}
Please do not introduce subsystem specific wrappers to kmalloc and kfree.
> +/*
> + * Allocates basic RX resources, consisting of memory mapped freelist Qs and
> a
> + * response Q.
> + */
> +static int alloc_rx_resources(struct sge *sge, struct sge_params *p)
> +{
> + struct pci_dev *pdev = sge->adapter->pdev;
> + unsigned int size, i;
> +
> + for (i = 0; i < SGE_FREELQ_N; i++) {
> + struct freelQ *Q = >freelQ[i];
> +
> + Q->genbit = 1;
> + Q->entries_n = p->freelQ_size[i];
> + Q->dma_offset = SGE_RX_OFFSET - sge->rx_pkt_pad;
> + size = sizeof(struct freelQ_e) * Q->entries_n;
> + Q->entries = (struct freelQ_e *)
> + pci_alloc_consistent(pdev, size, >dma_addr);
> + if (!Q->entries)
> + goto err_no_mem;
> + memset(Q->entries, 0, size);
> + size = sizeof(struct freelQ_ce) * Q->entries_n;
> + Q->centries = (struct freelQ_ce *) kmalloc(size, GFP_KERNEL);
> + if (!Q->centries)
> + goto err_no_mem;
> + memset(Q->centries, 0, size);
Please drop the redundant casts and use kcalloc() here and in various
other places as
well.
Also, the patch has some whitespace damage (spaces instead of tabs).
Pekka
-
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] x86: fix ESP corruption CPU bug
Stas Sergeev <[EMAIL PROTECTED]> writes: Another way of saying the same thing: I absolutely hate seeing patches that fix some theoretical issue that no Linux apps will ever care about. No, it is not theoretical, but it is mainly about a DOS games and an MS linker, as for me. The things I'd like to get working, but the ones you may not care too much about:) The particular game I want to get working, is "Master of Orion 2" for DOS. How about you just run it in dosbox instead of dosemu ? -Andi Nah, don't insult a DOSemu developer. ;-) Stas is one of them... Best regards, Zoltán Böszörményi - 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] break_lock forever broken
Ingo Molnar wrote: * Arjan van de Ven <[EMAIL PROTECTED]> wrote: as I said, since the cacheline just got dirtied, the write is just half a cycle which is so much in the noise that it really doesn't matter. ok - the patch below is a small modification of Hugh's so that we clear ->break_lock unconditionally. Since this code is not inlined it ought to have minimal icache impact too. Fine by me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] PCI Express Advanced Error Reporting Driver
long wrote: > This patch includes PCIEAER-HOWTO.txt, which describes how the PCI > Express Advanced Error Reporting Root driver works. > --- linux-2.6.11-rc5/Documentation/PCIEAER-HOWTO.txt Could this be placed in a sub-system subdirectory (creating one if necessary, e.g., pci/)? The root of Documentation/ is rather full of random files as is. David Vrabel - 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] drivers/media Sparse fixes
Removes some sparse warnings on one-bit bitfields.
Signed-off-by: Peter Hagervall <[EMAIL PROTECTED]>
--
dvb/dvb-core/dvb_ca_en50221.c |6 +++---
video/cx88/cx88.h |4 ++--
video/msp3400.c |4 ++--
video/videocodec.h| 16
4 files changed, 15 insertions(+), 15 deletions(-)
= drivers/media/dvb/dvb-core/dvb_ca_en50221.c 1.10 vs edited =
--- 1.10/drivers/media/dvb/dvb-core/dvb_ca_en50221.c2005-03-14 00:29:37
+01:00
+++ edited/drivers/media/dvb/dvb-core/dvb_ca_en50221.c 2005-03-14 11:40:56
+01:00
@@ -148,13 +148,13 @@
wait_queue_head_t thread_queue;
/* Flag indicating when thread should exit */
- int exit:1;
+ unsigned int exit:1;
/* Flag indicating if the CA device is open */
- int open:1;
+ unsigned int open:1;
/* Flag indicating the thread should wake up now */
- int wakeup:1;
+ unsigned int wakeup:1;
/* Delay the main thread should use */
unsigned long delay;
= drivers/media/video/msp3400.c 1.34 vs edited =
--- 1.34/drivers/media/video/msp3400.c 2005-01-25 22:50:27 +01:00
+++ edited/drivers/media/video/msp3400.c2005-03-14 11:38:24 +01:00
@@ -97,8 +97,8 @@
/* thread */
struct task_struct *kthread;
wait_queue_head_twq;
- int restart:1;
- int watch_stereo:1;
+ unsigned int restart:1;
+ unsigned int watch_stereo:1;
};
#define HAVE_NICAM(msp) (((msp->rev2>>8) & 0xff) != 00)
= drivers/media/video/videocodec.h 1.3 vs edited =
--- 1.3/drivers/media/video/videocodec.h2005-01-05 03:48:33 +01:00
+++ edited/drivers/media/video/videocodec.h 2005-03-14 11:37:28 +01:00
@@ -222,14 +222,14 @@
/* = */
struct vfe_polarity {
- int vsync_pol:1;
- int hsync_pol:1;
- int field_pol:1;
- int blank_pol:1;
- int subimg_pol:1;
- int poe_pol:1;
- int pvalid_pol:1;
- int vclk_pol:1;
+ unsigned int vsync_pol:1;
+ unsigned int hsync_pol:1;
+ unsigned int field_pol:1;
+ unsigned int blank_pol:1;
+ unsigned int subimg_pol:1;
+ unsigned int poe_pol:1;
+ unsigned int pvalid_pol:1;
+ unsigned int vclk_pol:1;
};
struct vfe_settings {
= drivers/media/video/cx88/cx88.h 1.8 vs edited =
--- 1.8/drivers/media/video/cx88/cx88.h 2005-03-11 21:32:23 +01:00
+++ edited/drivers/media/video/cx88/cx88.h 2005-03-14 11:39:36 +01:00
@@ -188,8 +188,8 @@
int tda9887_conf;
struct cx88_input input[8];
struct cx88_input radio;
- int blackbird:1;
- int dvb:1;
+ unsigned intblackbird:1;
+ unsigned intdvb:1;
};
struct cx88_subid {
-
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] break_lock forever broken
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> as I said, since the cacheline just got dirtied, the write is just
> half a cycle which is so much in the noise that it really doesn't
> matter.
ok - the patch below is a small modification of Hugh's so that we clear
->break_lock unconditionally. Since this code is not inlined it ought to
have minimal icache impact too.
Ingo
--
lock->break_lock is set when a lock is contended, but cleared only in
cond_resched_lock. Users of need_lockbreak (journal_commit_transaction,
copy_pte_range, unmap_vmas) don't necessarily use cond_resched_lock on it.
So, if the lock has been contended at some time in the past, break_lock
remains set thereafter, and the fastpath keeps dropping lock unnecessarily.
Hanging the system if you make a change like I did, forever restarting a
loop before making any progress. And even users of cond_resched_lock may
well suffer an initial unnecessary lockbreak.
There seems to be no point at which break_lock can be cleared when
unlocking, any point being either too early or too late; but that's okay,
it's only of interest while the lock is held. So clear it whenever the
lock is acquired - and any waiting contenders will quickly set it again.
Additional locking overhead? well, this is only when CONFIG_PREEMPT is on.
Since cond_resched_lock's spin_lock clears break_lock, no need to clear it
itself; and use need_lockbreak there too, preferring optimizer to #ifdefs.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
--- 2.6.11-bk8/kernel/sched.c 2005-03-11 13:33:09.0 +
+++ linux/kernel/sched.c2005-03-11 17:46:50.0 +
@@ -3753,14 +3753,11 @@ EXPORT_SYMBOL(cond_resched);
*/
int cond_resched_lock(spinlock_t * lock)
{
-#if defined(CONFIG_SMP) && defined(CONFIG_PREEMPT)
- if (lock->break_lock) {
- lock->break_lock = 0;
+ if (need_lockbreak(lock)) {
spin_unlock(lock);
cpu_relax();
spin_lock(lock);
}
-#endif
if (need_resched()) {
_raw_spin_unlock(lock);
preempt_enable_no_resched();
--- 2.6.11-bk8/kernel/spinlock.c2005-03-02 07:38:52.0 +
+++ linux/kernel/spinlock.c 2005-03-12 22:52:41.0 +
@@ -187,6 +187,7 @@ void __lockfunc _##op##_lock(locktype##_
cpu_relax();\
preempt_disable(); \
} \
+ (lock)->break_lock = 0; \
} \
\
EXPORT_SYMBOL(_##op##_lock); \
@@ -209,6 +211,7 @@ unsigned long __lockfunc _##op##_lock_ir
cpu_relax();\
preempt_disable(); \
} \
+ (lock)->break_lock = 0; \
return flags; \
} \
\
-
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/
[BUG?] x86_64 : Can not read /dev/kmem ?
Hi Andi
I tried to read /dev/kmem on x86_64 (linux-2.6.11) and got no success.
read() or pread() returns EINVAL
I tried mmap() too : mmap() calls succeed, but as soon the user process
dereference memory, we get :
tinfo: Corrupted page table at address 2aabf800
PGD 8a983067 PUD c7e5a067 PMD 91588067 PTE 8048a025
Bad pagetable: 000d [1] SMP
CPU 0
Modules linked in: ipt_REJECT
Pid: 10892, comm: tinfo Not tainted 2.6.11
RIP: 0033:[<00100562>] [<00100562>]
RSP: 002b:7790 EFLAGS: 00010217
RAX: 2aabf000 RBX: 2abbe000 RCX: 2ac8fc0c
RDX: 0001 RSI: 1000 RDI:
RBP: 77f8 R08: 0003 R09: 8048a000
R10: 0001 R11: 0206 R12: 001005b0
R13: 0001 R14: 2adfdfe8 R15: 00100530
FS: 2abcb970() GS:804866c0() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 2aabf800 CR3: 90368000 CR4: 06e0
Process tinfo (pid: 10892, threadinfo 8100901b, task
8100c7d976c0)
RIP [<00100562>] RSP <7790>
Thank you
Eric Dumazet
# cat tinfo.c
#define _XOPEN_SOURCE 500
#include
#include
#include
struct tcp_hashinfo {
struct tcp_ehash_bucket *__tcp_ehash;
struct tcp_bind_hashbucket *__tcp_bhash;
int __tcp_bhash_size;
int __tcp_ehash_size;
} tcp_hashinfo;
#define TCPINFO_ADDR 0x8048a000 /* tcp_hashinfo */
int main()
{
int fd = open("/dev/kmem", O_RDONLY) ;
if (pread(fd, _hashinfo, sizeof(tcp_hashinfo), TCPINFO_ADDR) == -1) {
lseek(fd, TCPINFO_ADDR, 0) ;
if (read(fd, _hashinfo, sizeof(tcp_hashinfo)) == -1) {
perror("Can not read /dev/kmem ?") ;
return 1 ;
}
}
printf("ehash=%p esize=%d bhash=%p bsize=%d\n",
tcp_hashinfo.__tcp_ehash,
tcp_hashinfo.__tcp_ehash_size,
tcp_hashinfo.__tcp_bhash,
tcp_hashinfo.__tcp_bhash_size) ;
return 0 ;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
mouse with 2.6.10+
I noticied a weird problem with input subsystem (mostly mouse) which happens on my boxes with 2.6.10 and 2.6.11+ kernels (up to current 2.6.11.3), which didn't happen with earlier kernels. First issue is that psmouse module takes about 10 sec to load (to detect the mouse), which was done instantly with older kernels. Not a very big problem ofcourse, but looks like it is indicating some more deep problem. 2.6.10 almost works, but sometimes, the whole input subsystem just "hungs", ie, both keyboard and mouse just stops working. Plugging in USB keyboard and loading usbhid module solves the problem - both keyboards and the mouse works after that, and I didn't yet notice the problem repeats after usbhid and usb keyboard is loaded. I wasn't able to determine when the problem occurs, for me it seems it hangs at some "random" point - sometimes after 5 minutes after boot, sometimes after a hour or so. And 2.6.11 is almost screwed up. I managed to get mouse working with it only 2 or 3 times (all after cold reboot). It also takes about 10 sec to load psmouse module (2.6.10 is a >< bit faster), but the mouse does just not work. Sometimes, it detects my mouse as "Generic ps/2 mouse" (it is "Generic Wheel mouse" usually). More, quite often, after re-loading psmouse module the keyboard stops working as well. I played with i8042.noacpi parameter but it has no visible effect (incl. the dmesg output). The machine is some Gygabyte mobo based on VT8601 chipset with VIA C3 CPU in it (I love those fanless system for their quiet operations). Mouse and keyboard (PS/2 interface) are pretty standard ones, mouse has wheel. All the stuff reported by the kernel looks ok too, here's the dmesg output: Linux version 2.6.10-i486-1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-5)) #1 Mon Feb 7 15:57:55 MSK 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 077f (usable) BIOS-e820: 077f - 077f3000 (ACPI NVS) BIOS-e820: 077f3000 - 0780 (ACPI data) BIOS-e820: 0780 - 0800 (reserved) BIOS-e820: fec0 - 0001 (reserved) 119MB LOWMEM available. On node 0 totalpages: 30704 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 26608 pages, LIFO batch:6 HighMem zone: 0 pages, LIFO batch:1 DMI not present. ACPI: RSDP (v000 GBT ) @ 0x000f7340 ACPI: RSDT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x) @ 0x077f3000 ACPI: FADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x) @ 0x077f3040 ACPI: DSDT (v001 GBTAWRDACPI 0x1000 MSFT 0x010c) @ 0x Built 1 zonelists Kernel command line: initrd=boot/initrd-2.6.10-i486-1 root=/dev/ram0 BOOT_IMAGE=boot/vmlinuz-2.6.10-i486-1 ip=192.168.1.165:192.168.1.1:192.168.1.5:255.255.255.0 No local APIC present or hardware disabled mapped APIC to d000 (010f2000) Initializing CPU#0 CPU 0 irqstacks, hard=c0318000 soft=c0317000 PID hash table entries: 512 (order: 9, 8192 bytes) Detected 910.013 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 118144k/122816k available (1235k kernel code, 4116k reserved, 653k data, 224k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1815.34 BogoMIPS (lpj=9076736) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 00803035 80803035 CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 64K (32 bytes/line) CPU: After all inits, caps:00803135 80803035 CPU: Centaur VIA Ezra stepping 08 Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0200 (from 8e20) checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 610k freed NET: Registered protocol family 16 EISA bus registered PCI: PCI BIOS revision 2.10 entry at 0xfaa80, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20041105 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Via IRQ fixup ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 11 12 14 *15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 11 devices PnPBIOS: Disabled by ACPI PCI: Using ACPI for IRQ routing **
Re: [2.6 patch] unexport kmap_{pte,port} on !ppc
On Fri, Mar 11, 2005 at 07:16:45PM +0100, Adrian Bunk wrote:
> I haven't found any modular usage of kmap_{pte,port} on !ppc in the
> kernel.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> This patch was already sent on:
> - 21 Jan 2005
>
> arch/i386/mm/init.c |3 ---
> arch/mips/mm/init.c |3 ---
Looks good.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/5] audit mips fix
On Fri, Mar 11, 2005 at 09:58:39AM +0900, Yoichi Yuasa wrote:
> > > Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> >
> > > @@ -307,7 +308,7 @@ asmlinkage void do_syscall_trace(struct
> > > {
> > > if (unlikely(current->audit_context)) {
> > > if (!entryexit)
> > > - audit_syscall_entry(current, regs->orig_eax,
> > > + audit_syscall_entry(current, regs->regs[2],
> >
> > Wrong. regs[2] can will contain the syscall return value and can be
> > modified by ptrace also.
>
> Thank you for your comment,
> I consider a good way based on your comment.
>
> Do you already have a good idea?
Basically do what x86 did, keep a copy of the the original regs[2] around.
The only potencial problem with this approach is debuggers might be
affected so I want to look into that first.
Ralf
-
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: [MC] [CHECKER] Need help on mmap on FUSE (linux user-land file system)
> > Forget to mention, we are checking linux 2.6. It appears to us > > that mmap doesnt' work for FUSE in linux 2.6. > > IIRC, the reason mmap doesn't work on FUSE is because when it > dirties pages they cannot be flushed reliably, because writing them > out involves calling a userspace process which may allocate RAM, > etc. Yes. To be precise this only affects writable shared mmap(), which is not used by the great majority of applications. Any other kind of memory mapping should work OK. Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serious problems with HFS+
Hi, On Sun, 13 Mar 2005, Matt Mackall wrote: > I've noticed a few problems with HFS+ support in recent kernels on > another user's machine running Ubuntu (Warty) running > 2.6.8.1-3-powerpc. I'm not in a position to extensively test or fix > either of these problem because of the fs tools situation so I'm just > passing this on. > > First, it reports inappropriate blocks to stat(2). It uses 4096 byte > blocks rather than 512 byte blocks which stat callers are expecting. > This seriously confuses du(1) (and me, for a bit). Looks like it may > be forgetting to set s_blocksize_bits. This should be fixed since 2.6.10. > Second, if an HFS+ filesystem mounted via Firewire or USB becomes > detached, the filesystem appears to continue working just fine. I can > find on the entire tree, despite memory pressure. I can even create > new files that continue to appear in directory listings! Writes to > such files succeed (they're async, of course) and the typical app is > none the wiser. It's only when apps attempt to read later that they > encounter problems. It turns out that various apps including scp > ignore IO errors on read and silently copy zero-filled files to the > destination. So I got this report as "why aren't the pictures I took > off my camera visible on my website?" HFS+ metadata is also in the page cache, so as long as everything is cached, HFS+ won't notice a problem. > This is obviously a really nasty failure mode. At the very least, open > of new files should fail with -EIO. Preferably the fs should force a > read-only remount on IO errors. Given that the vast majority of HFS+ > filesystems Linux is likely to be used with are on hotpluggable media, > I think this FS should be marked EXPERIMENTAL until such integrity > problems are addressed. Currently nobody tells fs about such events, so even if I check for write errors, it can still take a while until the error is detected. I acknowledge that this is a problem, but I don't think it's a HFS+ specific problem, there is currently no standard procedure for fs what to do in such situations, so I didn't implement anything. It would be nice if the fs would be tould about plug/unplug events, e.g. HFS+ could check the mount count to see if it was connected to a different host in the meantime and react appropriately. > Having the whole directory tree seemingly pinned in memory is probably > something that wants addressing as well. This actually might be a real HFS+ problem :), I have to look into it. bye, Roman - 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/2] No-exec support for ppc64
Jake Moilanen writes: > diff -puN fs/binfmt_elf.c~nx-user-ppc64 fs/binfmt_elf.c > --- linux-2.6-bk/fs/binfmt_elf.c~nx-user-ppc642005-03-08 16:08:54 > -06:00 > +++ linux-2.6-bk-moilanen/fs/binfmt_elf.c 2005-03-08 16:08:54 -06:00 > @@ -99,6 +99,8 @@ static int set_brk(unsigned long start, > up_write(>mm->mmap_sem); > if (BAD_ADDR(addr)) > return addr; > + > + sys_mprotect(start, end-start, PROT_READ|PROT_WRITE|PROT_EXEC); I don't think I can push that upstream. What happens if you leave that out? More generally, we are making a user-visible change, even for programs that aren't marked as having non-executable stack or heap, because we are now enforcing that the program can't execute from mappings that don't have PROT_EXEC. Perhaps we should enforce the requirement for execute permission only on those programs that indicate somehow that they can handle it? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] fix mprotect() with len=(size_t)(-1) to return -ENOMEM
On Mon, 2005-03-14 at 17:55 +0800, Gordon Jin wrote: > This patch fixes a corner case in sys_mprotect(): > > Case: len is so large that will overflow to 0 after page alignment. shouldn't we just fix the alignment code instead that the overflow case doesn't align to 0??? that sounds really odd. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
On Mon, 14 Mar 2005, Steven Rostedt wrote: > > I just downloaded -40 and applied my patch, compiled it with > PREEMPT_DESKTOP and data=ordered, ran it and everything seems OK, except > I'm getting the following... > > BUG: Unable to handle kernel NULL pointer dereference at virtual address > > printing eip: > c0213438 > *pde = [snip] > > > I'll see if this happens without the patch, and if so, then I'll look into > this further. > Well, I took out my patch and this bug didn't happen, so I guess it's may fault! OK, I'll dig into it further. -- 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: Fw: [Bugme-new] [Bug 4334] New: kernel support for netmos 9835/9735 crippled since 2.6.9
Thomas Richter <[EMAIL PROTECTED]> wrote:
>
>
> Hi Andrew,
>
> > I'm inclined to simply revert that change.
>
> In case the mentioned lines do cause problems, please do not hesitate
> to remove them. As the comments indicate, the patch was completely
> untested as I haven't had the cards available. However, please ensure
> that the parallel port remains available for the 9835/9735 in case
> they are removed from the parport module. Their references should be
> removed *only* from parport_pc, not from the PCI name database.
>
OK. Like this?
Steven, do you agree?
diff -puN drivers/parport/parport_pc.c~parport_pc-revert-netmos-patch
drivers/parport/parport_pc.c
--- 25/drivers/parport/parport_pc.c~parport_pc-revert-netmos-patch
2005-03-14 01:55:52.0 -0800
+++ 25-akpm/drivers/parport/parport_pc.c2005-03-14 01:59:32.0
-0800
@@ -2738,8 +2738,6 @@ enum parport_pc_pci_cards {
netmos_9855,
netmos_9735,
netmos_9835,
- netmos_9755,
- netmos_9715
};
@@ -2813,10 +2811,8 @@ static struct parport_pc_pci {
/* netmos_9805 */ { 1, { { 0, -1 }, } }, /* untested */
/* netmos_9815 */ { 2, { { 0, -1 }, { 2, -1 }, } }, /*
untested */
/* netmos_9855 */ { 2, { { 0, -1 }, { 2, -1 }, } }, /*
untested */
- /* netmos_9735 */ { 1, { { 2, 3 }, } }, /* untested */
- /* netmos_9835 */ { 1, { { 2, 3 }, } }, /* untested */
-/* netmos_9755 */ { 2, { { 0, 1 }, { 2, 3 },} }, /*
untested */
-/* netmos_9715 */ { 2, { { 0, 1 }, { 2, 3 },} }, /*
untested */
+ /* netmos_9735 */ { 1, { { 2, 3 }, } },
+ /* netmos_9835 */ { 1, { { 2, 3 }, } },
};
static struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2899,10 +2895,6 @@ static struct pci_device_id parport_pc_p
PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9735 },
{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9835,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9835 },
- { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9755,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9755 },
- { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9715,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9715 },
{ 0, } /* terminate list */
};
MODULE_DEVICE_TABLE(pci,parport_pc_pci_tbl);
diff -puN include/linux/pci_ids.h~parport_pc-revert-netmos-patch
include/linux/pci_ids.h
--- 25/include/linux/pci_ids.h~parport_pc-revert-netmos-patch 2005-03-14
01:55:52.0 -0800
+++ 25-akpm/include/linux/pci_ids.h 2005-03-14 01:55:52.0 -0800
@@ -2530,8 +2530,6 @@
#define PCI_DEVICE_ID_NETMOS_9815 0x9815
#define PCI_DEVICE_ID_NETMOS_9835 0x9835
#define PCI_DEVICE_ID_NETMOS_9855 0x9855
-#define PCI_DEVICE_ID_NETMOS_9755 0x9755
-#define PCI_DEVICE_ID_NETMOS_9715 0x9715
#define PCI_SUBVENDOR_ID_EXSYS 0xd84d
#define PCI_SUBDEVICE_ID_EXSYS_40140x4014
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.4.29 'make dep' error
Hi all :) I don't know if I've had this error previously, I noticed it this morning when recompiling the kernel *I already use*. When doing 'make dep' I had this: make[1]: Leaving directory `/usr/kernel' scripts/mkdep -- `find /usr/kernel/include/asm /usr/kernel/include/linux /usr/kernel/include/scsi /usr/kernel/include/net /usr/kernel/include/math-emu \( -name SCCS -o -name .svn \) -prune -o -follow -name \*.h ! -name modversions.h -print` > .hdepend find: /usr/kernel/include/asm: Too many levels of symbolic links scripts/mkdep -- init/*.c > .depend I've break the long line invoking the 'scripts/mkdep' binary so it's easier to read. I don't know why the heck 'find' fails with ELOOP :?? Just a simple 'find /usr/kernel/include/asm -follow' causes 'find' to issue a open call that fails with ELOOP. I'm using version 4.2.18 (I updated recently my findutils) and version 4.2.15 doesn't show the problem. I just wanted to warn everybody on the list about this problem. I'm going to write to findutils people to report the bug. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 http://www.dervishd.net & http://www.pleyades.net/ It's my PC and I'll cry if I want to... - 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 2.6] fix mprotect() with len=(size_t)(-1) to return -ENOMEM
This patch fixes a corner case in sys_mprotect(): Case: len is so large that will overflow to 0 after page alignment. E.g. len=(size_t)(-1), i.e. 0xff...ff. Expected result: POSIX spec says it should return -ENOMEM. Current result: len is aligned to 0, then treated the same as len=0 and return success. --- linux-2.6.11.3/mm/mprotect.c.orig 2005-03-14 13:40:28.0 -0800 +++ linux-2.6.11.3/mm/mprotect.c2005-03-14 13:42:41.0 -0800 @@ -232,14 +232,14 @@ sys_mprotect(unsigned long start, size_t if (start & ~PAGE_MASK) return -EINVAL; + if (!len) + return 0; len = PAGE_ALIGN(len); end = start + len; - if (end < start) + if (end <= start) return -ENOMEM; if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) return -EINVAL; - if (end == start) - return 0; /* * Does the application expect PROT_READ to imply PROT_EXEC: */ - 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: fsck error on flashcard with ext2 filesystem
Hello, > Although "sync" doesnt seem to make any difference to fsck output, > "blockdev --flushbufs" fixes the issue. > > Still wondering why the flushing of buffer behavior is different on a > system with normal harddisk (Redhat 7.2 with 2.4.26 kernel ) as compared > to a system with flashcard (CoreLinux with 2.4.26 kernel) although the > system parameters/daemons are the same. I dont have to do sync or > blockdev --flushbufs on standard system. Any ideas? Hmm, are the kernels really vanilla kernels without any patches? Anyway the problem was that on the system with flashcard old data were still kept in the cache for userspace (userspace uses cache independent from the one filesystem uses), so it could be anything starting by different amount of memory and ending at a different timing/command sequence whatever... > I was using fsck with "-n" option which doesnt executes the command, just > shows what would be done. I thought it would be harmless. Ok, that won't harm the filesystem but you can still see errors which are not on the filesystem (because of the cache issues). > -Original Message- > From: Jan Kara [mailto:[EMAIL PROTECTED] > Sent: Friday, March 11, 2005 6:37 AM > To: Santosh Gupta > Cc: linux-kernel@vger.kernel.org > Subject: Re: fsck error on flashcard with ext2 filesystem > > > Hello, > > just a reminder for the next time - please keep the lines length under 80 > characters. > > > Detailed Description > > - > > I am using Core Linux system on flashcard. Its another minimal linux > > distribution. Root filesystem is cramfs and a rw partition on flash is > > ext2. The system is always shutdown properly and initial fsck upon > > bootup shows no error. But if I delete a file on flash card and run > > fsck, it gives error in fsck. On umount and mounting again (or > > reboot), fsck shows no problem. Issuing "sync" command doesnt make any > > difference. > > Why is the disk not getting updated with filesystem metadata even > > after I wait for so long? > Hmm, it may be a cache aliasing issue (anyway doing fsck on a mounted > filesystem is asking for a trouble and basically nobody promisses any > result). But you may try doing something like: > sync; blockdev --flushbufs > > before a fsck. > Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - 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: OSS Audio borked between 2.6.6 and 2.6.10
Greg Stark <[EMAIL PROTECTED]> wrote: > > > Greg Stark <[EMAIL PROTECTED]> writes: > > > > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > > > > Are you able to narrow it down to something more fine grained than > "between > > > > 2.6.6 and 2.6.9-rc1"? > > > > > > Er, I suppose I would have to build some more kernels. Ugh. Is there a > good > > > place to start or do I have to just do a binary search? > > Well, I built a slew of kernels but found it on the first reboot. > > 2.6.7 doesn't work. > > I compiled the 2.6.6 drivers for 2.6.10 but they give ENODEV when I load > them. > Herbert tells me that this might be fixed in 2.6.11. Did you try that? - 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: [TTY] overrun notify issue during 5 minutes after booting
moreau francis <[EMAIL PROTECTED]> wrote:
>
> I noticed that TTY is not able to notify overrun issue
> in "n_tty_receive_overrun". Actually it's because of
> "time_before" macro which tests "tty->overrun_time"
> (equals to 0) against "jiffies - HZ" (something very
> big
> after booting).
> I guess a simple way to solve it, is to initialize
> "tty->overrun_time" to "jiffies". But it won't work if
> an overrun appear after a very long while
How does this look?
--- 25/drivers/char/tty_io.c~tty-overrun-time-fix 2005-03-14
01:45:43.0 -0800
+++ 25-akpm/drivers/char/tty_io.c 2005-03-14 01:46:02.0 -0800
@@ -2632,6 +2632,7 @@ static void initialize_tty_struct(struct
tty->magic = TTY_MAGIC;
tty_ldisc_assign(tty, tty_ldisc_get(N_TTY));
tty->pgrp = -1;
+ tty->overrun_time = jiffies;
tty->flip.char_buf_ptr = tty->flip.char_buf;
tty->flip.flag_buf_ptr = tty->flip.flag_buf;
INIT_WORK(>flip.work, flush_to_ldisc, tty);
diff -puN drivers/char/n_tty.c~tty-overrun-time-fix drivers/char/n_tty.c
--- 25/drivers/char/n_tty.c~tty-overrun-time-fix2005-03-14
01:49:25.0 -0800
+++ 25-akpm/drivers/char/n_tty.c2005-03-14 01:50:10.0 -0800
@@ -606,9 +606,11 @@ static inline void n_tty_receive_overrun
char buf[64];
tty->num_overrun++;
- if (time_before(tty->overrun_time, jiffies - HZ)) {
- printk(KERN_WARNING "%s: %d input overrun(s)\n", tty_name(tty,
buf),
- tty->num_overrun);
+ if (time_before(tty->overrun_time, jiffies - HZ) ||
+ time_after(tty->overrun_time, jiffies)) {
+ printk(KERN_WARNING "%s: %d input overrun(s)\n",
+ tty_name(tty, buf),
+ tty->num_overrun);
tty->overrun_time = jiffies;
tty->num_overrun = 0;
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
BK-kernel-tools/shortlog update
Hello Linus, you can either use "bk receive" to patch with this mail, or you can Pull from: bk://krusty.dt.e-technik.uni-dortmund.de/BK-kernel-tools or in cases of dire need, you can apply the patch below. BK parent: http://bktools.bkbits.net/bktools Patch description: [EMAIL PROTECTED], 2005-03-14 08:17:19+01:00, [EMAIL PROTECTED] shortlog: add 22 new addresses; re-sort Matthias # DIFFSTAT # shortlog | 24 +++- 1 files changed, 23 insertions(+), 1 deletion(-) # GNUPATCH # --- 1.255/shortlog 2005-03-11 11:18:49 +01:00 +++ 1.256/shortlog 2005-03-14 08:16:36 +01:00 @@ -235,8 +235,8 @@ 'akpm:osdl.org' => 'Andrew Morton', # guessed 'akpm:reardensteel.com' => 'Andrew Morton', 'akpm:zip.com.au' => 'Andrew Morton', -'akropel:rochester.rr.com' => 'Adam Kropelin', # guessed 'akropel1:rochester.rr.com' => 'Adam Kropelin', # lbdb +'akropel:rochester.rr.com' => 'Adam Kropelin', # guessed 'al.fracchetti:tin.it' => 'Alessandro Fracchetti', 'alain.knaff:lll.lu' => 'Alain Knaff', 'alain:linux.lu' => 'Alain Knaff', @@ -329,6 +329,7 @@ 'aoki:sdl.hitachi.co.jp' => 'Hideo Aoki', 'aoliva:redhat.com' => 'Alexandre Oliva', 'ap:cipherica.com' => 'Alex Pankratov', +'apatard:mandrakesoft.com' => 'Arnaud Patard', 'apm:brigitte.dna.fi' => 'Antti P. Miettinen', 'apolkosnik:directvinternet.com' => 'Adam Polkosnik', 'appro:fy.chalmers.se' => 'Andy Polyakov', @@ -337,6 +338,7 @@ 'arashi:yomerashi.yi.org' => 'Matt Reppert', 'arekm:pld-linux.org' => 'Arkadiusz Miskiewicz', # lbdb 'arief_m_utama:telkomsel.co.id' => 'Arief Mulya Utama', +'ariel:blueslice.com' => 'Ariel Rosenblatt', 'aris:cathedrallabs.org' => 'Aristeu Sergio Rozanski Filho', 'arjan:fenrus.demon.nl' => 'Arjan van de Ven', 'arjan:infradead.org' => 'Arjan van de Ven', @@ -475,6 +477,7 @@ 'braam:clusterfs.com' => 'Peter Braam', 'brad:wasp.net.au' => 'Brad Campbell', 'brad_mssw:gentoo.org' => 'Brad House', +'bram.verweij:wanadoo.nl' => 'Bram Verweij', 'bram:sara.nl' => 'Bram Stolk', 'braunu:de.ibm.com' => 'Ursula Braun-Krahl', 'brazilnut:us.ibm.com' => 'Don Fry', @@ -580,6 +583,7 @@ 'cip307:cip.physik.uni-wuerzburg.de' => 'Jochen Karrer', # from shortlog 'ckoerner:sysgo.com' => 'Christian Koerner', 'ckulesa:as.arizona.edu' => 'Craig Kulesa', +'cl81:gmx.net' => 'Christian Ludwig', 'clameter:sgi.com' => 'Christoph Lameter', 'clear.zhang:uli.com.tw' => 'Clear Zhang', 'clemens-dated-1061728015.bf63:endorphin.org' => 'Fruhwirth Clemens', @@ -801,6 +805,7 @@ 'ducrot:poupinou.org' => 'Bruno Ducrot', 'duncan.sands:math.u-psud.fr' => 'Duncan Sands', 'duncan:sun.com' => 'Duncan Laurie', +'duraid:octopus.com.au' => 'Duraid Madina', 'duwe:suse.de' => 'Torsten Duwe', 'dvhltc:us.ibm.com' => 'Darren Hart', 'dvrabel:arcom.co.uk' => 'David Vrabel', @@ -871,6 +876,7 @@ 'eric.lemoine:gmail.com' => 'Eric Lemoine', 'eric.moore:lsil.com' => 'Eric Moore', 'eric.piel:bull.net' => 'Eric Piel', +'eric.piel:lifl.fr' => 'Eric Piel', 'eric.valette:free.fr' => 'Eric Valette', 'eric:lammerts.org' => 'Eric Lammerts', 'eric:yhbt.net' => 'Eric Wong', @@ -986,6 +992,7 @@ 'ghoz:sympatico.ca' => 'Ghozlane Toumi', 'gibbs:overdrive.btc.adaptec.com' => 'Justin T. Gibbs', 'gibbs:scsiguy.com' => 'Justin T. Gibbs', +'gijoe:poczta.onet.pl' => 'Daniel Johnson', 'gilbertd:treblig.org' => 'Dr. David Alan Gilbert', 'giorgio:org.rmk.(none)' => 'Giorgio Padrin', 'giri:lmc.cs.sunysb.edu' => 'Giridhar Pemmasani', @@ -1049,6 +1056,7 @@ 'hadi:znyx.com' => 'Jamal Hadi Salim', # typo 'hadi:zynx.com' => 'Jamal Hadi Salim', 'hager:cs.umu.se' => 'Peter Hagervall', +'hal:realmsys.com' => 'Hal Tolley', 'hall:vdata.com' => 'Jeff Hall', 'hallyn:cs.wm.edu' => 'Serge Hallyn', 'halr:voltaire.com' => 'Hal Rosenstock', @@ -1207,6 +1215,7 @@ 'jbarnes:sgi.com' => 'Jesse Barnes', 'jbaron:redhat.com' => 'Jason Baron', 'jbglaw:lug-owl.de' => 'Jan-Benedict Glaw', +'jbj1:ultraemail.net' => 'Jens B. Jorgensen', 'jblack:linuxguru.net' => 'James Blackwell', 'jbm:joshisanerd.com' => 'Josh Myer', 'jbourne:hardrock.org' => 'James Bourne', @@ -1296,6 +1305,7 @@ 'jim:jtan.com' => 'Jim Paris', 'jimix:watson.ibm.com' => 'Jimi Xenidis', 'jk:ozlabs.org' => 'Jeremy Kerr', +'jkacur:rogers.com' => 'John Kacur', 'jkenisto:us.ibm.com' => 'James Keniston', 'jkluebs:com.rmk.(none)' => 'John K. Luebs', 'jkmaline:cc.hut.fi' => 'Jouni Malinen', @@ -1376,6 +1386,7 @@ 'jsimmons:kozmo.(none)' => 'James Simmons', 'jsimmons:maxwell.earthlink.net' => 'James Simmons', 'jsimmons:transvirtual.com' => 'James Simmons', +'jsimmons:www.infradead.org' => 'James Simmons', 'jsm:fc.hp.com' => 'John S. Marvin', 'jsm:udlkern.fc.hp.com' => 'John S. Marvin', 'jstultz:us.ibm.com' => 'John Stultz', @@ -1592,6 +1603,7 @@ 'linux:de.rmk.(none)' => 'Dominik Brodowski', 'linux:de.rmk.(none2)' => 'Sebastian Henschel', 'linux:dominikbrodowski.de' => 'Dominik Brodowski', +'linux:dominikbrodowski.net'
Re: IA32 (2.6.11 - 2005-03-12.16.00) - 56 New warnings
> > struct dvb_pll_desc {
[ ... ]
> > struct {
[ ... ]
> > } entries[];
> > };
> >
> > while 2.6.11-mm3 changed it into entries[0].
>
> The original code failed to compile with gcc-2.95.4, so I stuck the [0] in
> there, then was vaguely surprised when no warnings came out. Seems that
> later compilers _do_ warn.
>
> I guess we could put a 9 in there.
Yep, that should do, I think that is enougth for all existing
entries ...
Gerd
--
#define printk(args...) fprintf(stderr, ## args)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] Make /proc/ chmod'able
Albert Cahalan wrote: This is a bad idea. Users should not be allowed to make this decision. This is rightly a decision for the admin to make. Why do you think users should not be allowed to chmod their processes' /proc directories? Isn't it similar to being able to chmod their home directories? They own both objects, after all (both conceptually and as attributed in the filesystem). Note: I'm the procps (ps, top, w, etc.) maintainer. Probably I'd have to make /bin/ps run setuid root to deal with this. (minor changes needed) The same goes for /usr/bin/top, which I know is currently unsafe and difficult to fix. Let's not go there, OK? I have to admit to not having done any real testing with those utilities. My excuse is this isn't such a new feature, Openwall had something similar for at least four years now and GrSecurity contains yet another flavour of it. Openwall also provides one patch for procps-2.0.6, so I figured that problem (whatever their patch is about) got fixed in later versions. Why do ps and top need to be setuid root to deal with a resticted /proc? What information in /proc/ needs to be available to any and all users? If you restricted this new ability to root, then I'd have much less of an objection. (not that I'd like it) How about a boot parameter or sysctl to enable the chmod'ability of /proc/, defaulting to off? But I'd like to resolve your more general objections above first, if possible. :) Thanks for your comments, Rene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PPC64 delete unused file iSeries_fixup.h
This patch is from Domen Puncer <[EMAIL PROTECTED]>.
Remove nowhere referenced file. (egrep "filename\." didn't find anything)
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Acked-by: Stephen Rothwell <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -L include/asm-ppc64/iSeries/iSeries_fixup.h -puN
include/asm-ppc64/iSeries/iSeries_fixup.h~remove_file-include_asm_ppc64_iSeries_iSeries_fixup.h
/dev/null
--- kj/include/asm-ppc64/iSeries/iSeries_fixup.h
+++ /dev/null 2005-03-02 11:34:59.0 +0100
@@ -1,25 +0,0 @@
-
-#ifndef__ISERIES_FIXUP_H__
-#define__ISERIES_FIXUP_H__
-#include
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-void iSeries_fixup (void);
-void iSeries_fixup_bus (struct pci_bus*);
-unsigned int iSeries_scan_slot (struct pci_dev*, u16, u8, u8);
-
-
-/* Need to store information related to the PHB bucc and make it accessible to
the hose */
-struct iSeries_hose_arch_data {
- u32 hvBusNumber;
-};
-
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif /* __ISERIES_FIXUP_H__ */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PPC64 delete unused file no_initrd.c
This patch is from Domen Puncer <[EMAIL PROTECTED]>. Remove nowhere referenced file. (egrep "filename\." didn't find anything) Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> diff -L arch/ppc64/boot/no_initrd.c -puN arch/ppc64/boot/no_initrd.c~remove_file-arch_ppc64_boot_no_initrd.c /dev/null --- kj/arch/ppc64/boot/no_initrd.c +++ /dev/null 2005-03-02 11:34:59.0 +0100 @@ -1,2 +0,0 @@ -char initrd_data[1]; -int initrd_len = 0; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
On Mon, 14 Mar 2005, Steven Rostedt wrote: > > > > I'll test this with PREEMPT_DESKTOP and data=ordered also and see how it > > > goes. > > > > Does not seem to work at all with the above settings. It seemed OK > > until I started X. Then every time I launched an xterm it would > > disappear as soon as I typed anything. I could not switch consoles to > > see the Oops. > > > > Hi Lee, > > I just compiled PREEMPT_DESKTOP and mounted root (only disk filesystem on > my test machine) as data=ordered. I had no problem getting to X, starting > an xterm and running a make. Actually it was a gnome-term since I didn't > have xterm. But then I su to root, apt-get xterm, ran xterm, and did a > make there with no problems. > > Did you patch this against 39-02 or -40-X? > > I haven't had time to upgrade to 40 yet. Maybe, I'll work on that today. > I just downloaded -40 and applied my patch, compiled it with PREEMPT_DESKTOP and data=ordered, ran it and everything seems OK, except I'm getting the following... BUG: Unable to handle kernel NULL pointer dereference at virtual address printing eip: c0213438 *pde = Oops: [#1] Modules linked in: ipv6 af_packet tsdev mousedev evdev floppy psmouse pcspkr snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug ehci_hcd intel_agp agpgart uhci_hcd usbcore e100 mii ide_cd cdrom unix CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.11-RT-V0.7.40-00) EIP is at vt_ioctl+0x18/0x1ab0 eax: ebx: 5603 ecx: 5603 edx: cb6c8780 esi: c0213420 edi: cc956000 ebp: cb613f18 esp: cb613e48 ds: 007b es: 007b ss: 0068 preempt: Process XFree86 (pid: 4713, threadinfo=cb612000 task=cb5e0a40) Stack: cb5e0b90 cb612000 cb5e0a40 c034494c cb5e0a40 0246 cb613e7c c0117217 c0344954 0006 0001 cb613ebc ce0cce24 c13e1800 cf1279b8 cb613ed4 c01707f1 cf1279b8 0007 Call Trace: [] show_stack+0x7f/0xa0 (28) [] show_registers+0x165/0x1d0 (56) [] die+0xc8/0x150 (64) [] do_page_fault+0x356/0x6c4 (216) [] error_code+0x2b/0x30 (268) [] tty_ioctl+0x34b/0x490 (52) [] do_ioctl+0x4f/0x70 (32) [] vfs_ioctl+0x62/0x1d0 (40) [] sys_ioctl+0x61/0x90 (40) [] syscall_call+0x7/0xb (-8124) Code: ff ff 8d 05 88 4d 34 c0 e8 f6 60 0a 00 e9 3a ff ff ff 90 55 89 e5 57 56 53 81 ec c4 00 00 00 8b 7d 08 8b 5d 10 8b 87 7c 09 00 00 <8b> 30 89 34 24 8b 04 b5 e0 b7 3c c0 89 45 8c e8 a4 6a 00 00 85 I'll see if this happens without the patch, and if so, then I'll look into this further. 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] x86: fix ESP corruption CPU bug
Stas Sergeev <[EMAIL PROTECTED]> writes: > >> Another way of saying the same thing: I absolutely hate seeing >> patches that fix some theoretical issue that no Linux apps will ever >> care about. > No, it is not theoretical, but it is mainly > about a DOS games and an MS linker, as for > me. The things I'd like to get working, but > the ones you may not care too much about:) > The particular game I want to get working, > is "Master of Orion 2" for DOS. How about you just run it in dosbox instead of dosemu ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TTY] overrun notify issue during 5 minutes after booting
I noticed that TTY is not able to notify overrun issue in "n_tty_receive_overrun". Actually it's because of "time_before" macro which tests "tty->overrun_time" (equals to 0) against "jiffies - HZ" (something very big after booting). I guess a simple way to solve it, is to initialize "tty->overrun_time" to "jiffies". But it won't work if an overrun appear after a very long while Thanks Francis Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi,
This issue is quite interesting. We removed all specific VIA quirk
recently and apply a generic VIA quirk. But in this case, the MCH 00:0.0
is from AMD, and the ISA bridge and built-in devices are from VIA, this
means VIA quirk is useless, since it takes action only when the MCH is
from VIA. We possibly should enable VIA quirk if a VIA ISA bridge is
found instead of a VIA MCH found, but Bjorn's method seems ok.
If you want to put the patch into kernel, please also change the '
pirq_enable_irq' case.
Thanks,
Shaohua
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:acpi-devel-
>[EMAIL PROTECTED] On Behalf Of Grzegorz Kulewski
>Sent: Sunday, March 13, 2005 11:15 PM
>To: Bjorn Helgaas
>Cc: Andrew Morton; ACPI List; lkml
>Subject: Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI
breaks
>USB
>
>On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
>
>> Can you do an "lspci -vvn"? I'm looking at quirk_via_irqpic() in
>> 2.6.9, which is what printed this:
>>
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
>>
>> but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
>> PCI_DEVICE_ID_VIA_82C686_5, and PCI_DEVICE_ID_VIA_82C686_6.
>>
>> You have:
>>
>> :00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo
Super
>South] (rev 40)
>> :00:07.1 IDE interface: VIA Technologies, Inc.
>VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
>> :00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a)
(prog-if
>00 [UHCI])
>> :00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a)
(prog-if
>00 [UHCI])
>>
>> and we apparently ran the quirk for 07.2 and 07.3. I wouldn't
>> have thought those would have one of the above device IDs. The
>> "lspci -vvn" should tell us for sure.
>>
>> 2.6.11 removed that quirk and runs quirk_via_bridge() for
>> all VIA devices, but only sets via_interrupt_line_quirk if
>> (pdev->devfn == 0), which you don't have. So that's why
>> my patch didn't do anything.
>>
>>> Also two more questions:
>>>
>>> 1. What is VIA fixup? Is it some hardware bug? Or BIOS problem? Why
is
>it
>>> needed? On what hardware / software it is needed?
>>
>> I really don't know much about the VIA fixup. I just noticed
>> that we seem to be doing it slightly differently in 2.6.11 than
>> we did in 2.6.9, and thought maybe it was related to your problem.
>> Here's a changeset that has a couple pointers:
>>
>>http://linux.bkbits.net:8080/linux-
>2.5/cset%4041cb9d48DRV4TYe77gvstTawuZFYyQ
>>
>>> 2. Why this patch shrinked bzImage that much:
>>>
>>> -rw-r--r-- 1 root root 1828186 mar 11 23:33 vmlinuz-2.6.11-cko1
>>> -rw-r--r-- 1 root root 1828355 mar 2 20:48 vmlinuz-2.6.11-cko1.old
>>
>> I have no idea about this. But it's only a couple hundred bytes.
>>
>> So here's another patch to try (revert the first one, then apply
this).
>>
>> = drivers/acpi/pci_irq.c 1.37 vs edited =
>> --- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
>> +++ edited/drivers/acpi/pci_irq.c2005-03-11 15:13:49 -07:00
>> @@ -30,6 +30,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -438,10 +439,17 @@
>> }
>> }
>>
>> -if (via_interrupt_line_quirk)
>> -pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq &
15);
>> -
>> dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
>> +
>> +if (dev->vendor == PCI_VENDOR_ID_VIA) {
>> +u8 old_irq, new_irq = dev->irq & 0xf;
>> +
>> +pci_read_config_byte(dev, PCI_INTERRUPT_LINE, _irq);
>> +printk(KERN_INFO PREFIX "Via IRQ fixup for %s, from %d "
>> +"to %d\n", pci_name(dev), old_irq, new_irq);
>> +udelay(15);
>> +pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
>> +}
>>
>> printk(KERN_INFO PREFIX "PCI interrupt %s[%c] -> GSI %u "
>> "(%s, %s) -> IRQ %d\n",
>>
>
>Ok, this patch works. Here is the log:
>
>Mar 13 17:16:17 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc
>version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6))
#3
>Sun Mar 13 17:10:10 CET 2005
>Mar 13 17:16:17 kangur BIOS-provided physical RAM map:
>Mar 13 17:16:17 kangur BIOS-e820: - 0009fc00
>(usable)
>Mar 13 17:16:17 kangur BIOS-e820: 0009fc00 - 000a
>(reserved)
>Mar 13 17:16:17 kangur BIOS-e820: 000f - 0010
>(reserved)
>Mar 13 17:16:17 kangur BIOS-e820: 0010 - 1fff
>(usable)
>Mar 13 17:16:17 kangur BIOS-e820: 1fff - 1fff3000
>(ACPI NVS)
>Mar 13 17:16:17 kangur BIOS-e820: 1fff3000 - 2000
>(ACPI data)
>Mar 13 17:16:17 kangur BIOS-e820: - 0001
>(reserved)
>Mar 13 17:16:17 kangur 511MB LOWMEM available.
>Mar 13 17:16:17 kangur On node 0 totalpages: 131056
>Mar 13 17:16:17 kangur DMA zone: 4096
Re: Fw: [Bugme-new] [Bug 4334] New: kernel support for netmos 9835/9735 crippled since 2.6.9
Hi Andrew, > I'm inclined to simply revert that change. In case the mentioned lines do cause problems, please do not hesitate to remove them. As the comments indicate, the patch was completely untested as I haven't had the cards available. However, please ensure that the parallel port remains available for the 9835/9735 in case they are removed from the parport module. Their references should be removed *only* from parport_pc, not from the PCI name database. So long, Thomas - 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] Fix kconfig docs typo: integer -> int
Trivial correction: the type of numbers for Kconfig is not integer but int (I just verified because I followed the wrong docs and got a error, I looked elsewhere and they are using int, and int works for me). Please apply. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> --- linux-2.6.11-paolo/Documentation/kbuild/kconfig-language.txt |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN Documentation/kbuild/kconfig-language.txt~doc-big-typo-fix Documentation/kbuild/kconfig-language.txt --- linux-2.6.11/Documentation/kbuild/kconfig-language.txt~doc-big-typo-fix 2005-03-10 16:35:38.0 +0100 +++ linux-2.6.11-paolo/Documentation/kbuild/kconfig-language.txt 2005-03-10 16:36:09.0 +0100 @@ -48,7 +48,7 @@ Menu attributes A menu entry can have a number of attributes. Not all of them are applicable everywhere (see syntax). -- type definition: "bool"/"tristate"/"string"/"hex"/"integer" +- type definition: "bool"/"tristate"/"string"/"hex"/"int" Every config option must have a type. There are only two basic types: tristate and string, the other types are based on these two. The type definition optionally accepts an input prompt, so these two examples @@ -100,7 +100,7 @@ applicable everywhere (see syntax). symbols. - numerical ranges: "range" ["if" ] - This allows to limit the range of possible input values for integer + This allows to limit the range of possible input values for int and hex symbols. The user can only input a value which is larger than or equal to the first symbol and smaller than or equal to the second symbol. _ - 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/
pam and nice-rt-prio-rlimits
Hello,
in the long thread on "[request for inclusion] Realtime LSM" there
doesn't appear to be too many people who has actually tested the
nice-and-rt-prio-rlimits.patch. Well, it works for me...
However, the patch to pam_limits posted here:
http://lkml.org/lkml/2005/1/14/174
is a little bit aggressive on the semi-colon side.
Tested patch (and pam.src.rpm for fedora c3) can be found here
http://home.hia.no/~vegardl/rlimit/
and below
--- Linux-PAM-0.77/modules/pam_limits/pam_limits.c.rtprio 2005-03-13
16:15:07.0 +0100
+++ Linux-PAM-0.77/modules/pam_limits/pam_limits.c 2005-03-13
16:27:54.0 +0100
@@ -39,6 +39,11 @@
#include
#include
+/* Hack to test new rlimit values */
+#define RLIMIT_NICE13
+#define RLIMIT_RTPRIO 14
+#define RLIM_NLIMITS 15
+
/* Module defines */
#define LINE_LENGTH 1024
@@ -293,6 +298,10 @@
else if (strcmp(lim_item, "locks") == 0)
limit_item = RLIMIT_LOCKS;
#endif
+else if (strcmp(lim_item, "rt_priority") == 0)
+ limit_item = RLIMIT_RTPRIO;
+else if (strcmp(lim_item, "nice") == 0)
+ limit_item = RLIMIT_NICE;
else if (strcmp(lim_item, "maxlogins") == 0) {
limit_item = LIMIT_LOGIN;
pl->flag_numsyslogins = 0;
@@ -360,6 +369,18 @@
case RLIMIT_AS:
limit_value *= 1024;
break;
+case RLIMIT_NICE:
+if (limit_value > 39)
+ limit_value = 39;
+ if (limit_value < 0)
+ limit_value = 0;
+break;
+case RLIMIT_RTPRIO:
+if (limit_value > 99)
+ limit_value = 99;
+ if (limit_value < 0)
+ limit_value = 0;
+break;
}
if ( (limit_item != LIMIT_LOGIN)
Thanks,
--
Vegard Lima
-
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: OSS Audio borked between 2.6.6 and 2.6.10
> Greg Stark <[EMAIL PROTECTED]> writes: > > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > > Are you able to narrow it down to something more fine grained than > > > "between > > > 2.6.6 and 2.6.9-rc1"? > > > > Er, I suppose I would have to build some more kernels. Ugh. Is there a good > > place to start or do I have to just do a binary search? Well, I built a slew of kernels but found it on the first reboot. 2.6.7 doesn't work. I compiled the 2.6.6 drivers for 2.6.10 but they give ENODEV when I load them. > > 2.6.7: > > <[EMAIL PROTECTED]> > [PATCH] I2C: ICH6/6300ESB i2c support > > This patch adds DID support for ICH6 and 6300ESB to i2c-i801.c(SMBus). > In order to add this support I needed to patch pci_ids.h with the SMBus > DID's. To keep things orginized I renumbered the ICH6 and ESB entries > in pci_ids.h. I then patched the piix IDE and i810 audio drivers to > reflect the updated #define's. I also removed an error from irq.c; > there was a reference to a 6300ESB DID that does not exist. > > <[EMAIL PROTECTED]> > [sound/oss i810] pci id cleanups > > The driver defined its own PCI id constants. Kill the majority, > which were redundant, and move the rest to include/linux/pci_ids.h. > > Also, move open-coded tests for "new ICH" audio chips to a single > helper function. These tests were being patched with each new > ICH motherboard from Intel, resulting in each new PCI id being added > to several places in the driver. > > Note that, even though this should be a harmless patch, there > exists the remote possibility that I mis-matched some of the > PCI ids, as I only tested ICH5. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix wait queue race in drain_dac > > This particular one fixes a textbook race condition in drain_dac > that causes it to timeout when it shouldn't. > <[EMAIL PROTECTED]> > [sound/oss i810] fix race > > This patch fixes the value of swptr in case of an underrun/overrun. > > Overruns/underruns probably won't occur at all when the driver is > fixed properly, but this doesn't hurt. > > <[EMAIL PROTECTED]> > [sound/oss] remove bogus CIV_TO_LVI > > This patch removes a pair of bogus LVI assignments. The explanation in > the comment is wrong because the value of PCIB tells the hardware that > the DMA buffer can be processed even if LVI == CIV. > > Setting LVI to CIV + 1 causes overruns when with short writes > (something that vmware is very fond of). > > <[EMAIL PROTECTED]> > [sound/oss i810] clean up with macros > > This patch adds a number macros to clean up the code. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix partial DMA transfers > > This patch fixes a longstanding bug in this driver where partial > fragments > are fed to the hardware. Worse yet, those fragments are then extended > while the hardware is doing DMA transfers causing all sorts of problems. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix playback SETTRIGGER > > This patch fixes SETTRIGGER with playback so that the LVI is always > set and the DAC is always started. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix OSS fragments > > This patch makes userfragsize do what it's meant to do: do not start > DAC/ADC until a full fragment is available. > > <[EMAIL PROTECTED]> > [sound/oss i810] remove divides on playback > > This patch removes a couple of divides on the playback path. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix drain_dac loop when signals_allowed==0 > > This patch fixes another bug in the drain_dac wait loop when it is > called with signals_allowed == 0. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix reads/writes % 4 != 0 > > This patch removes another bogus chunk of code that breaks when > the application does a partial write. > > In particular, a read/write of x bytes where x % 4 != 0 will loop > forever. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix deadlock in drain_dac > > This patch fixes a typo in a previous change that causes the driver > to deadlock under SMP. -- greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PPC64 Make RTAS code usable on non-pSeries machines
This patch is from Arnd Bergmann <[EMAIL PROTECTED]>. RTAS is not actually pSeries specific, but some PPC64 code that relies on RTAS is currently protected by CONFIG_PPC_PSERIES. This introduces a generic configuration option PPC_RTAS that can be used by other subarchitectures as well. The existing option with the same name is renamed to the more specific RTAS_PROC. Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> diff -urN linux-2.5/arch/ppc64/Kconfig test/arch/ppc64/Kconfig --- linux-2.5/arch/ppc64/Kconfig2005-03-14 08:25:07.0 +1100 +++ test/arch/ppc64/Kconfig 2005-03-14 19:31:22.0 +1100 @@ -255,16 +255,21 @@ config PPC_RTAS - bool "Proc interface to RTAS" + bool depends on PPC_PSERIES + default y + +config RTAS_PROC + bool "Proc interface to RTAS" + depends on PPC_RTAS config RTAS_FLASH tristate "Firmware flash interface" - depends on PPC_RTAS + depends on RTAS_PROC config SCANLOG tristate "Scanlog dump interface" - depends on PPC_RTAS + depends on RTAS_PROC && PPC_PSERIES config LPARCFG tristate "LPAR Configuration Data" diff -urN linux-2.5/arch/ppc64/kernel/Makefile test/arch/ppc64/kernel/Makefile --- linux-2.5/arch/ppc64/kernel/Makefile2005-03-07 08:21:53.0 +1100 +++ test/arch/ppc64/kernel/Makefile 2005-03-14 19:31:22.0 +1100 @@ -39,7 +39,7 @@ obj-$(CONFIG_RTAS_FLASH) += rtas_flash.o obj-$(CONFIG_SMP) += smp.o obj-$(CONFIG_MODULES) += module.o ppc_ksyms.o -obj-$(CONFIG_PPC_RTAS) += rtas-proc.o +obj-$(CONFIG_RTAS_PROC)+= rtas-proc.o obj-$(CONFIG_SCANLOG) += scanlog.o obj-$(CONFIG_VIOPATH) += viopath.o obj-$(CONFIG_LPARCFG) += lparcfg.o diff -urN linux-2.5/arch/ppc64/kernel/entry.S test/arch/ppc64/kernel/entry.S --- linux-2.5/arch/ppc64/kernel/entry.S 2005-02-07 07:55:28.0 +1100 +++ test/arch/ppc64/kernel/entry.S 2005-03-14 19:31:22.0 +1100 @@ -616,7 +616,7 @@ bl .unrecoverable_exception b unrecov_restore -#ifdef CONFIG_PPC_PSERIES +#ifdef CONFIG_PPC_RTAS /* * On CHRP, the Run-Time Abstraction Services (RTAS) have to be * called with the MMU off. @@ -753,7 +753,7 @@ mtlrr0 blr/* return to caller */ -#endif /* CONFIG_PPC_PSERIES */ +#endif /* CONFIG_PPC_RTAS */ #ifdef CONFIG_PPC_MULTIPLATFORM diff -urN linux-2.5/arch/ppc64/kernel/misc.S test/arch/ppc64/kernel/misc.S --- linux-2.5/arch/ppc64/kernel/misc.S 2005-03-14 08:25:07.0 +1100 +++ test/arch/ppc64/kernel/misc.S 2005-03-14 19:31:22.0 +1100 @@ -680,7 +680,7 @@ ld r30,-16(r1) blr -#ifndef CONFIG_PPC_PSERIES /* hack hack hack */ +#ifdef CONFIG_PPC_RTAS /* hack hack hack */ #define ppc_rtas sys_ni_syscall #endif diff -urN linux-2.5/arch/ppc64/kernel/prom.c test/arch/ppc64/kernel/prom.c --- linux-2.5/arch/ppc64/kernel/prom.c 2005-03-10 09:14:12.0 +1100 +++ test/arch/ppc64/kernel/prom.c 2005-03-14 19:31:22.0 +1100 @@ -894,7 +894,7 @@ if (get_flat_dt_prop(node, "linux,iommu-force-on", NULL) != NULL) iommu_force_on = 1; -#ifdef CONFIG_PPC_PSERIES +#ifdef CONFIG_PPC_RTAS /* To help early debugging via the front panel, we retreive a minimal * set of RTAS infos now if available */ @@ -910,7 +910,7 @@ rtas.size = *prop; } } -#endif /* CONFIG_PPC_PSERIES */ +#endif /* CONFIG_PPC_RTAS */ /* break now */ return 1; diff -urN linux-2.5/arch/ppc64/kernel/rtc.c test/arch/ppc64/kernel/rtc.c --- linux-2.5/arch/ppc64/kernel/rtc.c 2004-11-17 09:38:21.0 +1100 +++ test/arch/ppc64/kernel/rtc.c2005-03-14 19:31:22.0 +1100 @@ -337,7 +337,7 @@ } #endif -#ifdef CONFIG_PPC_PSERIES +#ifdef CONFIG_PPC_RTAS #define MAX_RTC_WAIT 5000 /* 5 sec */ #define RTAS_CLOCK_BUSY (-2) void pSeries_get_boot_time(struct rtc_time *rtc_tm) diff -urN linux-2.5/arch/ppc64/kernel/setup.c test/arch/ppc64/kernel/setup.c --- linux-2.5/arch/ppc64/kernel/setup.c 2005-03-07 08:21:53.0 +1100 +++ test/arch/ppc64/kernel/setup.c 2005-03-14 19:31:22.0 +1100 @@ -605,12 +605,12 @@ */ initialize_cache_info(); -#ifdef CONFIG_PPC_PSERIES +#ifdef CONFIG_PPC_RTAS /* * Initialize RTAS if available */ rtas_initialize(); -#endif /* CONFIG_PPC_PSERIES */ +#endif /* CONFIG_PPC_RTAS */ /* * Check if we have an initrd provided via the device-tree diff -urN linux-2.5/arch/ppc64/oprofile/op_model_power4.c test/arch/ppc64/oprofile/op_model_power4.c --- linux-2.5/arch/ppc64/oprofile/op_model_power4.c 2005-03-07 08:21:53.0 +1100 +++ test/arch/ppc64/oprofile/op_model_power4.c 2005-03-14
Re: [PATCH] break_lock forever broken
Arjan van de Ven wrote: Yes that's the tradeoff. I just feel that the former may be better, especially because the latter can be timing dependant (so you may get things randomly "happening"), and the former is apparently very low overhead compared with the cost of taking the lock. Any numbers, anyone? as I said, since the cacheline just got dirtied, the write is just half a cycle which is so much in the noise that it really doesn't matter. Yes, you were the "apparently" that I cited :) I just wondered if Ingo has or has seen numbers that make him dislike this way of doing it. I would have thought that the spinlock structure and code bloat, and the lock break checks in fast paths would be the far greater cost of lockbreak than what Hugh's patch adds. But real numbers are pretty important when it comes to this kind of thing. - 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/
dmesg verbosity [was Re: AGP bogosities]
Hi! > >>I'm fascinated that not a single person picked up on this problem > >>whilst the agp code sat in -mm. Even if DRI isn't enabled, > >>every box out there with AGP that uses the generic routines > >>(which is a majority), should have barfed loudly when it hit > >>this check during boot. Does no-one read dmesg output any more ? > > > >Its way too long these days. Like "so long it overflows even enlarged > >buffer". We should prune these messages down to "one line per hw > >device or serious problems only". > > especially if you turn on encryption options. I can understand that output > being useful for debugging, but there should be a way to not deal with it > in the normal case. Perhaps we could have a rule like "non-experimental driver may only print out one line per actual device?" (and perhaps: dmesg output for boot going okay should fit on one screen). Or perhaps we should have warnings-like regression testing. "New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg junk". Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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] break_lock forever broken
> > Yes that's the tradeoff. I just feel that the former may be better, > especially because the latter can be timing dependant (so you may get > things randomly "happening"), and the former is apparently very low > overhead compared with the cost of taking the lock. Any numbers, > anyone? as I said, since the cacheline just got dirtied, the write is just half a cycle which is so much in the noise that it really doesn't matter. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Mon, 14 Mar 2005, Pavel Machek wrote: I'm fascinated that not a single person picked up on this problem whilst the agp code sat in -mm. Even if DRI isn't enabled, every box out there with AGP that uses the generic routines (which is a majority), should have barfed loudly when it hit this check during boot. Does no-one read dmesg output any more ? Its way too long these days. Like "so long it overflows even enlarged buffer". We should prune these messages down to "one line per hw device or serious problems only". especially if you turn on encryption options. I can understand that output being useful for debugging, but there should be a way to not deal with it in the normal case. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - 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] break_lock forever broken
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
while writing the ->break_lock feature i intentionally avoided
overhead in the spinlock fastpath. A better solution for the bug you
noticed is to clear the break_lock flag in places that use
need_lock_break() explicitly.
What happens if break_lock gets set by random contention on the lock
somewhere (with no need_lock_break or cond_resched_lock)? Next time it
goes through a lockbreak will (may) be a false positive.
yes, and that's harmless. Lock contention is supposed to be a relatively
rare thing (compared to the frequency of uncontended locking), so all
the overhead is concentrated towards the contention case, not towards
the uncontended case. If the flag lingers then it may be a false
positive and the lock will be dropped once, the flag will be cleared,
and the lock will be reacquired. So we've traded a constant amount of
overhead in the fastpath for a somewhat higher, but still constant
amount of overhead in the slowpath.
Yes that's the tradeoff. I just feel that the former may be better,
especially because the latter can be timing dependant (so you may get
things randomly "happening"), and the former is apparently very low
overhead compared with the cost of taking the lock. Any numbers,
anyone?
One robust way for that seems to be to make the need_lock_break() macro
clear the flag if it sees it set, and to make all the other (internal)
users use __need_lock_break() that doesnt clear the flag. I'll cook up a
patch for this.
If you do this exactly as you describe, then you'll break
cond_resched_lock (eg. for the copy_page_range path), won't you?
(cond_resched_lock() is an 'internal' user that will use
__need_lock_break().)
Off the top of my head, this is what it looks like:
spin_lock(>lock);
spin_lock(>lock);
for (lots of stuff) {
if (need_lock_break(src->lock) || need_lock_break(dst->lock))
break;
}
spin_unlock(>lock);
cond_resched_lock(>lock);
Right? Now currently the src->lock is broken, but your change would break
the cond_resched_lock here, it will not trigger because need_lock_break
clears dst->lock... oh I see, the spinning CPU will set it again. Yuck :(
-
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.11] IBM TrackPoint support
On Mon, Mar 14, 2005 at 12:02:13AM -0500, Stephen Evanchik wrote: > Here's the latest patch for TracKPoint devices. I have changed the > sysfs filenames to be more descriptive for commonly used attributes. I > also implemented the set_properties flag for initialization. > > It patches against 2.6.11 and 2.6.11.3 however I have not tested it > with 2.6.11.3 . > > Any comments are appreciated. > +/* > + * Mode manipulation > + */ > +#define TP_SET_SOFT_TRANS (0x4E) /* Set mode */ > +#define TP_CANCEL_SOFT_TRANS (0xB9) /* Cancel mode */ > +#define TP_SET_HARD_TRANS (0x45) /* Mode can only be set */ What exactly is transparent mode? -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Pá 11-03-05 17:26:14, Dave Jones wrote: > On Sat, Mar 12, 2005 at 07:18:19AM +0900, OGAWA Hirofumi wrote: > > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > > > Hmm.. We seem to not have any tests for the counts becoming negative, and > > > this would seem to be an easy mistake to make considering that both I > and > > > Dave did it. > > > > I stole this from -mm. > > I'm fascinated that not a single person picked up on this problem > whilst the agp code sat in -mm. Even if DRI isn't enabled, > every box out there with AGP that uses the generic routines > (which is a majority), should have barfed loudly when it hit > this check during boot. Does no-one read dmesg output any more ? Its way too long these days. Like "so long it overflows even enlarged buffer". We should prune these messages down to "one line per hw device or serious problems only". Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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] break_lock forever broken
* Nick Piggin <[EMAIL PROTECTED]> wrote: > > while writing the ->break_lock feature i intentionally avoided > > overhead in the spinlock fastpath. A better solution for the bug you > > noticed is to clear the break_lock flag in places that use > > need_lock_break() explicitly. > > What happens if break_lock gets set by random contention on the lock > somewhere (with no need_lock_break or cond_resched_lock)? Next time it > goes through a lockbreak will (may) be a false positive. yes, and that's harmless. Lock contention is supposed to be a relatively rare thing (compared to the frequency of uncontended locking), so all the overhead is concentrated towards the contention case, not towards the uncontended case. If the flag lingers then it may be a false positive and the lock will be dropped once, the flag will be cleared, and the lock will be reacquired. So we've traded a constant amount of overhead in the fastpath for a somewhat higher, but still constant amount of overhead in the slowpath. > >One robust way for that seems to be to make the need_lock_break() macro > >clear the flag if it sees it set, and to make all the other (internal) > >users use __need_lock_break() that doesnt clear the flag. I'll cook up a > >patch for this. > > > > If you do this exactly as you describe, then you'll break > cond_resched_lock (eg. for the copy_page_range path), won't you? (cond_resched_lock() is an 'internal' user that will use __need_lock_break().) 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/
[PATCH] ppc64: kill might_sleep() warnings in __copy_*_user_inatomic
This patch is from Arnd Bergmann and Olof Johansson.
This implements the __copy_{to,from}_user_inatomic() functions on ppc64.
The only difference between the inatomic and regular version is that
inatomic does not call might_sleep() to detect possible faults while
holding locks/elevated preempt counts.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Acked-by: Olof Johansson <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
--- linux-2.6-ppc.orig/include/asm-ppc64/uaccess.h 2005-03-10
14:54:18.0 -0500
+++ linux-2.6-ppc/include/asm-ppc64/uaccess.h 2005-03-11 06:55:02.792926304
-0500
@@ -119,6 +119,7 @@ extern long __put_user_bad(void);
#define __put_user_nocheck(x,ptr,size) \
({ \
long __pu_err; \
+ might_sleep(); \
__chk_user_ptr(ptr);\
__put_user_size((x),(ptr),(size),__pu_err,-EFAULT); \
__pu_err; \
@@ -128,6 +129,7 @@ extern long __put_user_bad(void);
({ \
long __pu_err = -EFAULT;\
void __user *__pu_addr = (ptr); \
+ might_sleep(); \
if (access_ok(VERIFY_WRITE,__pu_addr,size)) \
__put_user_size((x),__pu_addr,(size),__pu_err,-EFAULT); \
__pu_err; \
@@ -135,7 +137,6 @@ extern long __put_user_bad(void);
#define __put_user_size(x,ptr,size,retval,errret) \
do { \
- might_sleep(); \
retval = 0; \
switch (size) { \
case 1: __put_user_asm(x,ptr,retval,"stb",errret); break; \
@@ -170,6 +171,7 @@ do {
\
#define __get_user_nocheck(x,ptr,size) \
({ \
long __gu_err, __gu_val;\
+ might_sleep(); \
__get_user_size(__gu_val,(ptr),(size),__gu_err,-EFAULT);\
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
@@ -179,6 +181,7 @@ do {
\
({ \
long __gu_err = -EFAULT, __gu_val = 0; \
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
+ might_sleep(); \
if (access_ok(VERIFY_READ,__gu_addr,size)) \
__get_user_size(__gu_val,__gu_addr,(size),__gu_err,-EFAULT);\
(x) = (__typeof__(*(ptr)))__gu_val; \
@@ -189,7 +192,6 @@ extern long __get_user_bad(void);
#define __get_user_size(x,ptr,size,retval,errret) \
do { \
- might_sleep(); \
retval = 0; \
__chk_user_ptr(ptr);\
switch (size) { \
@@ -223,9 +225,8 @@ extern unsigned long __copy_tofrom_user(
unsigned long size);
static inline unsigned long
-__copy_from_user(void *to, const void __user *from, unsigned long n)
+__copy_from_user_inatomic(void *to, const void __user *from, unsigned long n)
{
- might_sleep();
if (__builtin_constant_p(n)) {
unsigned long ret;
@@ -248,9 +249,15 @@ __copy_from_user(void *to, const void __
}
static inline unsigned long
-__copy_to_user(void __user *to, const void *from, unsigned long n)
+__copy_from_user(void *to, const void __user *from, unsigned long n)
{
might_sleep();
+ return __copy_from_user_inatomic(to, from, n);
+}
+
+static inline unsigned long
+__copy_to_user_inatomic(void __user *to, const void *from, unsigned long n)
+{
if (__builtin_constant_p(n)) {
unsigned long ret;
@@ -272,6 +279,13 @@ __copy_to_user(void __user *to, const vo
return __copy_tofrom_user(to, (__force const void __user *) from, n);
}
+static inline unsigned long
Re: [PATCH] break_lock forever broken
Ingo Molnar wrote: * Hugh Dickins <[EMAIL PROTECTED]> wrote: @@ -187,6 +187,8 @@ void __lockfunc _##op##_lock(locktype##_ cpu_relax();\ preempt_disable(); \ } \ + if ((lock)->break_lock) \ + (lock)->break_lock = 0; \ while writing the ->break_lock feature i intentionally avoided overhead in the spinlock fastpath. A better solution for the bug you noticed is to clear the break_lock flag in places that use need_lock_break() explicitly. What happens if break_lock gets set by random contention on the lock somewhere (with no need_lock_break or cond_resched_lock)? Next time it goes through a lockbreak will (may) be a false positive. I think I'd prefer the additional lock overhead of Hugh's patch if it gives better behaviour. I think. Any idea what the overhead actually is? One robust way for that seems to be to make the need_lock_break() macro clear the flag if it sees it set, and to make all the other (internal) users use __need_lock_break() that doesnt clear the flag. I'll cook up a patch for this. If you do this exactly as you describe, then you'll break cond_resched_lock (eg. for the copy_page_range path), won't you? - 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: Call for help: list of machines with working S3
Hi! > * MySQL (hinders the actual suspension process and kicks the pc back to > where it was) Try this patch... Pavel --- clean/kernel/signal.c 2005-02-03 22:27:26.0 +0100 +++ linux/kernel/signal.c 2005-02-03 22:28:19.0 +0100 @@ -,6 +,7 @@ ret = -EINTR; } + try_to_freeze(1); return ret; } -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: cpufreq on-demand governor up_treshold?
Jan De Luyck a écrit :
Hello lists,
(please cc me from cpufreq list)
I've since yesterday started using the ondemand governor. Seems to work fine,
tho I can't seem to find a reason why it keeps scaling my processor speed
upwards tho the processor use never exceeds 30% (been watching top -d 1).
:
:
Any hints?
You can try the three attached patches in the order :
ondemand-cleanup-factorise-idle-measurement-2.6.11.patch
ondemand-save-idle-up-for-all-cpu-2.6.11.patch
ondemand-automatic-downscaling-2.6.11-accepted.patch
They are available on the cpufreq list but as it's difficult to access
it I'm sending them again, all together. These are the last things that
Venki and I have been working on. It should solve your problem
(actually, only the last patch, but it depends on the two previous
patches). Please, let me know if it works.
BTW, DaveJ, Dominik, I couldn't find them in the daily-snapshot
available at codemonkey.org.uk. Should I worry, or is it just due to
some latency between your private trees and the public one?
Eric
diff -purN linux-2.6.11/drivers/cpufreq/cpufreq_ondemand.c linux-2.6.11-new/drivers/cpufreq/cpufreq_ondemand.c
--- linux-2.6.11/drivers/cpufreq/cpufreq_ondemand.c 2005-03-07 17:57:31.0 -0800
+++ linux-2.6.11-new/drivers/cpufreq/cpufreq_ondemand.c 2005-03-07 17:53:17.0 -0800
@@ -34,13 +34,9 @@
*/
#define DEF_FREQUENCY_UP_THRESHOLD (80)
-#define MIN_FREQUENCY_UP_THRESHOLD (0)
+#define MIN_FREQUENCY_UP_THRESHOLD (10)
#define MAX_FREQUENCY_UP_THRESHOLD (100)
-#define DEF_FREQUENCY_DOWN_THRESHOLD (20)
-#define MIN_FREQUENCY_DOWN_THRESHOLD (0)
-#define MAX_FREQUENCY_DOWN_THRESHOLD (100)
-
/*
* The polling frequency of this governor depends on the capability of
* the processor. Default polling frequency is 1000 times the transition
@@ -78,12 +74,10 @@ struct dbs_tuners {
unsigned int sampling_rate;
unsigned int sampling_down_factor;
unsigned int up_threshold;
- unsigned int down_threshold;
};
static struct dbs_tuners dbs_tuners_ins = {
.up_threshold = DEF_FREQUENCY_UP_THRESHOLD,
- .down_threshold = DEF_FREQUENCY_DOWN_THRESHOLD,
.sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR,
};
@@ -115,7 +109,6 @@ static ssize_t show_##file_name \
show_one(sampling_rate, sampling_rate);
show_one(sampling_down_factor, sampling_down_factor);
show_one(up_threshold, up_threshold);
-show_one(down_threshold, down_threshold);
static ssize_t store_sampling_down_factor(struct cpufreq_policy *unused,
const char *buf, size_t count)
@@ -161,8 +154,7 @@ static ssize_t store_up_threshold(struct
down(_sem);
if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
- input < MIN_FREQUENCY_UP_THRESHOLD ||
- input <= dbs_tuners_ins.down_threshold) {
+ input < MIN_FREQUENCY_UP_THRESHOLD) {
up(_sem);
return -EINVAL;
}
@@ -173,26 +165,6 @@ static ssize_t store_up_threshold(struct
return count;
}
-static ssize_t store_down_threshold(struct cpufreq_policy *unused,
- const char *buf, size_t count)
-{
- unsigned int input;
- int ret;
- ret = sscanf (buf, "%u", );
-
- down(_sem);
- if (ret != 1 || input > MAX_FREQUENCY_DOWN_THRESHOLD ||
- input < MIN_FREQUENCY_DOWN_THRESHOLD ||
- input >= dbs_tuners_ins.up_threshold) {
- up(_sem);
- return -EINVAL;
- }
-
- dbs_tuners_ins.down_threshold = input;
- up(_sem);
-
- return count;
-}
#define define_one_rw(_name) \
static struct freq_attr _name = \
@@ -201,7 +173,6 @@ __ATTR(_name, 0644, show_##_name, store_
define_one_rw(sampling_rate);
define_one_rw(sampling_down_factor);
define_one_rw(up_threshold);
-define_one_rw(down_threshold);
static struct attribute * dbs_attributes[] = {
_rate_max.attr,
@@ -209,7 +180,6 @@ static struct attribute * dbs_attributes
_rate.attr,
_down_factor.attr,
_threshold.attr,
- _threshold.attr,
NULL
};
@@ -222,8 +192,8 @@ static struct attribute_group dbs_attr_g
static void dbs_check_cpu(int cpu)
{
- unsigned int idle_ticks, up_idle_ticks, down_idle_ticks;
- unsigned int freq_down_step;
+ unsigned int idle_ticks, up_idle_ticks, total_ticks;
+ unsigned int freq_next;
unsigned int freq_down_sampling_rate;
static int down_skip[NR_CPUS];
struct cpu_dbs_info_s *this_dbs_info;
@@ -290,7 +260,12 @@ static void dbs_check_cpu(int cpu)
down_skip[cpu]++;
if (down_skip[cpu] < dbs_tuners_ins.sampling_down_factor)
return;
+ down_skip[cpu] = 0;
+ /* don't try to decrease the frequency if it's already the min */
+ if (policy->cur == policy->min)
+ return;
+
idle_ticks = UINT_MAX;
for_each_cpu_mask(j, policy->cpus) {
unsigned int tmp_idle_ticks, total_idle_ticks;
@@ -308,27 +283,23 @@ static void dbs_check_cpu(int cpu)
idle_ticks = tmp_idle_ticks;
}
- /* Scale idle ticks by 100 and compare with up and down ticks */
- idle_ticks *= 100;
- down_skip[cpu] = 0;
-
+ /* Compute how many ticks there are between two measurements */
freq_down_sampling_rate = dbs_tuners_ins.sampling_rate *
Re: cpufreq on-demand governor up_treshold?
Jan De Luyck a écrit :
Hello lists,
(please cc me from cpufreq list)
I've since yesterday started using the ondemand governor. Seems to work fine,
tho I can't seem to find a reason why it keeps scaling my processor speed
upwards tho the processor use never exceeds 30% (been watching top -d 1).
:
:
Any hints?
You can try the three attached patches in the order :
ondemand-cleanup-factorise-idle-measurement-2.6.11.patch
ondemand-save-idle-up-for-all-cpu-2.6.11.patch
ondemand-automatic-downscaling-2.6.11-accepted.patch
They are available on the cpufreq list but as it's difficult to access
it I'm sending them again, all together. These are the last things that
Venki and I have been working on. It should solve your problem
(actually, only the last patch, but it depends on the two previous
patches). Please, let me know if it works.
BTW, DaveJ, Dominik, I couldn't find them in the daily-snapshot
available at codemonkey.org.uk. Should I worry, or is it just due to
some latency between your private trees and the public one?
Eric
diff -purN linux-2.6.11/drivers/cpufreq/cpufreq_ondemand.c linux-2.6.11-new/drivers/cpufreq/cpufreq_ondemand.c
--- linux-2.6.11/drivers/cpufreq/cpufreq_ondemand.c 2005-03-07 17:57:31.0 -0800
+++ linux-2.6.11-new/drivers/cpufreq/cpufreq_ondemand.c 2005-03-07 17:53:17.0 -0800
@@ -34,13 +34,9 @@
*/
#define DEF_FREQUENCY_UP_THRESHOLD (80)
-#define MIN_FREQUENCY_UP_THRESHOLD (0)
+#define MIN_FREQUENCY_UP_THRESHOLD (10)
#define MAX_FREQUENCY_UP_THRESHOLD (100)
-#define DEF_FREQUENCY_DOWN_THRESHOLD (20)
-#define MIN_FREQUENCY_DOWN_THRESHOLD (0)
-#define MAX_FREQUENCY_DOWN_THRESHOLD (100)
-
/*
* The polling frequency of this governor depends on the capability of
* the processor. Default polling frequency is 1000 times the transition
@@ -78,12 +74,10 @@ struct dbs_tuners {
unsigned int sampling_rate;
unsigned int sampling_down_factor;
unsigned int up_threshold;
- unsigned int down_threshold;
};
static struct dbs_tuners dbs_tuners_ins = {
.up_threshold = DEF_FREQUENCY_UP_THRESHOLD,
- .down_threshold = DEF_FREQUENCY_DOWN_THRESHOLD,
.sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR,
};
@@ -115,7 +109,6 @@ static ssize_t show_##file_name \
show_one(sampling_rate, sampling_rate);
show_one(sampling_down_factor, sampling_down_factor);
show_one(up_threshold, up_threshold);
-show_one(down_threshold, down_threshold);
static ssize_t store_sampling_down_factor(struct cpufreq_policy *unused,
const char *buf, size_t count)
@@ -161,8 +154,7 @@ static ssize_t store_up_threshold(struct
down(dbs_sem);
if (ret != 1 || input MAX_FREQUENCY_UP_THRESHOLD ||
- input MIN_FREQUENCY_UP_THRESHOLD ||
- input = dbs_tuners_ins.down_threshold) {
+ input MIN_FREQUENCY_UP_THRESHOLD) {
up(dbs_sem);
return -EINVAL;
}
@@ -173,26 +165,6 @@ static ssize_t store_up_threshold(struct
return count;
}
-static ssize_t store_down_threshold(struct cpufreq_policy *unused,
- const char *buf, size_t count)
-{
- unsigned int input;
- int ret;
- ret = sscanf (buf, %u, input);
-
- down(dbs_sem);
- if (ret != 1 || input MAX_FREQUENCY_DOWN_THRESHOLD ||
- input MIN_FREQUENCY_DOWN_THRESHOLD ||
- input = dbs_tuners_ins.up_threshold) {
- up(dbs_sem);
- return -EINVAL;
- }
-
- dbs_tuners_ins.down_threshold = input;
- up(dbs_sem);
-
- return count;
-}
#define define_one_rw(_name) \
static struct freq_attr _name = \
@@ -201,7 +173,6 @@ __ATTR(_name, 0644, show_##_name, store_
define_one_rw(sampling_rate);
define_one_rw(sampling_down_factor);
define_one_rw(up_threshold);
-define_one_rw(down_threshold);
static struct attribute * dbs_attributes[] = {
sampling_rate_max.attr,
@@ -209,7 +180,6 @@ static struct attribute * dbs_attributes
sampling_rate.attr,
sampling_down_factor.attr,
up_threshold.attr,
- down_threshold.attr,
NULL
};
@@ -222,8 +192,8 @@ static struct attribute_group dbs_attr_g
static void dbs_check_cpu(int cpu)
{
- unsigned int idle_ticks, up_idle_ticks, down_idle_ticks;
- unsigned int freq_down_step;
+ unsigned int idle_ticks, up_idle_ticks, total_ticks;
+ unsigned int freq_next;
unsigned int freq_down_sampling_rate;
static int down_skip[NR_CPUS];
struct cpu_dbs_info_s *this_dbs_info;
@@ -290,7 +260,12 @@ static void dbs_check_cpu(int cpu)
down_skip[cpu]++;
if (down_skip[cpu] dbs_tuners_ins.sampling_down_factor)
return;
+ down_skip[cpu] = 0;
+ /* don't try to decrease the frequency if it's already the min */
+ if (policy-cur == policy-min)
+ return;
+
idle_ticks = UINT_MAX;
for_each_cpu_mask(j, policy-cpus) {
unsigned int tmp_idle_ticks, total_idle_ticks;
@@ -308,27 +283,23 @@ static void dbs_check_cpu(int cpu)
idle_ticks = tmp_idle_ticks;
}
- /* Scale idle ticks by 100 and compare with up and down ticks */
- idle_ticks *= 100;
- down_skip[cpu] = 0;
-
+ /* Compute how many ticks there are between two measurements */
freq_down_sampling_rate =
Re: Call for help: list of machines with working S3
Hi! * MySQL (hinders the actual suspension process and kicks the pc back to where it was) Try this patch... Pavel --- clean/kernel/signal.c 2005-02-03 22:27:26.0 +0100 +++ linux/kernel/signal.c 2005-02-03 22:28:19.0 +0100 @@ -,6 +,7 @@ ret = -EINTR; } + try_to_freeze(1); return ret; } -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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] break_lock forever broken
Ingo Molnar wrote: * Hugh Dickins [EMAIL PROTECTED] wrote: @@ -187,6 +187,8 @@ void __lockfunc _##op##_lock(locktype##_ cpu_relax();\ preempt_disable(); \ } \ + if ((lock)-break_lock) \ + (lock)-break_lock = 0; \ while writing the -break_lock feature i intentionally avoided overhead in the spinlock fastpath. A better solution for the bug you noticed is to clear the break_lock flag in places that use need_lock_break() explicitly. What happens if break_lock gets set by random contention on the lock somewhere (with no need_lock_break or cond_resched_lock)? Next time it goes through a lockbreak will (may) be a false positive. I think I'd prefer the additional lock overhead of Hugh's patch if it gives better behaviour. I think. Any idea what the overhead actually is? One robust way for that seems to be to make the need_lock_break() macro clear the flag if it sees it set, and to make all the other (internal) users use __need_lock_break() that doesnt clear the flag. I'll cook up a patch for this. If you do this exactly as you describe, then you'll break cond_resched_lock (eg. for the copy_page_range path), won't you? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ppc64: kill might_sleep() warnings in __copy_*_user_inatomic
This patch is from Arnd Bergmann and Olof Johansson.
This implements the __copy_{to,from}_user_inatomic() functions on ppc64.
The only difference between the inatomic and regular version is that
inatomic does not call might_sleep() to detect possible faults while
holding locks/elevated preempt counts.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Acked-by: Olof Johansson [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
--- linux-2.6-ppc.orig/include/asm-ppc64/uaccess.h 2005-03-10
14:54:18.0 -0500
+++ linux-2.6-ppc/include/asm-ppc64/uaccess.h 2005-03-11 06:55:02.792926304
-0500
@@ -119,6 +119,7 @@ extern long __put_user_bad(void);
#define __put_user_nocheck(x,ptr,size) \
({ \
long __pu_err; \
+ might_sleep(); \
__chk_user_ptr(ptr);\
__put_user_size((x),(ptr),(size),__pu_err,-EFAULT); \
__pu_err; \
@@ -128,6 +129,7 @@ extern long __put_user_bad(void);
({ \
long __pu_err = -EFAULT;\
void __user *__pu_addr = (ptr); \
+ might_sleep(); \
if (access_ok(VERIFY_WRITE,__pu_addr,size)) \
__put_user_size((x),__pu_addr,(size),__pu_err,-EFAULT); \
__pu_err; \
@@ -135,7 +137,6 @@ extern long __put_user_bad(void);
#define __put_user_size(x,ptr,size,retval,errret) \
do { \
- might_sleep(); \
retval = 0; \
switch (size) { \
case 1: __put_user_asm(x,ptr,retval,stb,errret); break; \
@@ -170,6 +171,7 @@ do {
\
#define __get_user_nocheck(x,ptr,size) \
({ \
long __gu_err, __gu_val;\
+ might_sleep(); \
__get_user_size(__gu_val,(ptr),(size),__gu_err,-EFAULT);\
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
@@ -179,6 +181,7 @@ do {
\
({ \
long __gu_err = -EFAULT, __gu_val = 0; \
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
+ might_sleep(); \
if (access_ok(VERIFY_READ,__gu_addr,size)) \
__get_user_size(__gu_val,__gu_addr,(size),__gu_err,-EFAULT);\
(x) = (__typeof__(*(ptr)))__gu_val; \
@@ -189,7 +192,6 @@ extern long __get_user_bad(void);
#define __get_user_size(x,ptr,size,retval,errret) \
do { \
- might_sleep(); \
retval = 0; \
__chk_user_ptr(ptr);\
switch (size) { \
@@ -223,9 +225,8 @@ extern unsigned long __copy_tofrom_user(
unsigned long size);
static inline unsigned long
-__copy_from_user(void *to, const void __user *from, unsigned long n)
+__copy_from_user_inatomic(void *to, const void __user *from, unsigned long n)
{
- might_sleep();
if (__builtin_constant_p(n)) {
unsigned long ret;
@@ -248,9 +249,15 @@ __copy_from_user(void *to, const void __
}
static inline unsigned long
-__copy_to_user(void __user *to, const void *from, unsigned long n)
+__copy_from_user(void *to, const void __user *from, unsigned long n)
{
might_sleep();
+ return __copy_from_user_inatomic(to, from, n);
+}
+
+static inline unsigned long
+__copy_to_user_inatomic(void __user *to, const void *from, unsigned long n)
+{
if (__builtin_constant_p(n)) {
unsigned long ret;
@@ -272,6 +279,13 @@ __copy_to_user(void __user *to, const vo
return __copy_tofrom_user(to, (__force const void __user *) from, n);
}
+static inline unsigned long
+__copy_to_user(void
Re: [PATCH] break_lock forever broken
* Nick Piggin [EMAIL PROTECTED] wrote: while writing the -break_lock feature i intentionally avoided overhead in the spinlock fastpath. A better solution for the bug you noticed is to clear the break_lock flag in places that use need_lock_break() explicitly. What happens if break_lock gets set by random contention on the lock somewhere (with no need_lock_break or cond_resched_lock)? Next time it goes through a lockbreak will (may) be a false positive. yes, and that's harmless. Lock contention is supposed to be a relatively rare thing (compared to the frequency of uncontended locking), so all the overhead is concentrated towards the contention case, not towards the uncontended case. If the flag lingers then it may be a false positive and the lock will be dropped once, the flag will be cleared, and the lock will be reacquired. So we've traded a constant amount of overhead in the fastpath for a somewhat higher, but still constant amount of overhead in the slowpath. One robust way for that seems to be to make the need_lock_break() macro clear the flag if it sees it set, and to make all the other (internal) users use __need_lock_break() that doesnt clear the flag. I'll cook up a patch for this. If you do this exactly as you describe, then you'll break cond_resched_lock (eg. for the copy_page_range path), won't you? (cond_resched_lock() is an 'internal' user that will use __need_lock_break().) 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: AGP bogosities
On Pá 11-03-05 17:26:14, Dave Jones wrote: On Sat, Mar 12, 2005 at 07:18:19AM +0900, OGAWA Hirofumi wrote: Linus Torvalds [EMAIL PROTECTED] writes: Hmm.. We seem to not have any tests for the counts becoming negative, and this would seem to be an easy mistake to make considering that both I and Dave did it. I stole this from -mm. I'm fascinated that not a single person picked up on this problem whilst the agp code sat in -mm. Even if DRI isn't enabled, every box out there with AGP that uses the generic routines (which is a majority), should have barfed loudly when it hit this check during boot. Does no-one read dmesg output any more ? Its way too long these days. Like so long it overflows even enlarged buffer. We should prune these messages down to one line per hw device or serious problems only. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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.11] IBM TrackPoint support
On Mon, Mar 14, 2005 at 12:02:13AM -0500, Stephen Evanchik wrote: Here's the latest patch for TracKPoint devices. I have changed the sysfs filenames to be more descriptive for commonly used attributes. I also implemented the set_properties flag for initialization. It patches against 2.6.11 and 2.6.11.3 however I have not tested it with 2.6.11.3 . Any comments are appreciated. +/* + * Mode manipulation + */ +#define TP_SET_SOFT_TRANS (0x4E) /* Set mode */ +#define TP_CANCEL_SOFT_TRANS (0xB9) /* Cancel mode */ +#define TP_SET_HARD_TRANS (0x45) /* Mode can only be set */ What exactly is transparent mode? -- Vojtech Pavlik SuSE Labs, SuSE CR - 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] break_lock forever broken
Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
while writing the -break_lock feature i intentionally avoided
overhead in the spinlock fastpath. A better solution for the bug you
noticed is to clear the break_lock flag in places that use
need_lock_break() explicitly.
What happens if break_lock gets set by random contention on the lock
somewhere (with no need_lock_break or cond_resched_lock)? Next time it
goes through a lockbreak will (may) be a false positive.
yes, and that's harmless. Lock contention is supposed to be a relatively
rare thing (compared to the frequency of uncontended locking), so all
the overhead is concentrated towards the contention case, not towards
the uncontended case. If the flag lingers then it may be a false
positive and the lock will be dropped once, the flag will be cleared,
and the lock will be reacquired. So we've traded a constant amount of
overhead in the fastpath for a somewhat higher, but still constant
amount of overhead in the slowpath.
Yes that's the tradeoff. I just feel that the former may be better,
especially because the latter can be timing dependant (so you may get
things randomly happening), and the former is apparently very low
overhead compared with the cost of taking the lock. Any numbers,
anyone?
One robust way for that seems to be to make the need_lock_break() macro
clear the flag if it sees it set, and to make all the other (internal)
users use __need_lock_break() that doesnt clear the flag. I'll cook up a
patch for this.
If you do this exactly as you describe, then you'll break
cond_resched_lock (eg. for the copy_page_range path), won't you?
(cond_resched_lock() is an 'internal' user that will use
__need_lock_break().)
Off the top of my head, this is what it looks like:
spin_lock(dst-lock);
spin_lock(src-lock);
for (lots of stuff) {
if (need_lock_break(src-lock) || need_lock_break(dst-lock))
break;
}
spin_unlock(src-lock);
cond_resched_lock(dst-lock);
Right? Now currently the src-lock is broken, but your change would break
the cond_resched_lock here, it will not trigger because need_lock_break
clears dst-lock... oh I see, the spinning CPU will set it again. Yuck :(
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Mon, 14 Mar 2005, Pavel Machek wrote: I'm fascinated that not a single person picked up on this problem whilst the agp code sat in -mm. Even if DRI isn't enabled, every box out there with AGP that uses the generic routines (which is a majority), should have barfed loudly when it hit this check during boot. Does no-one read dmesg output any more ? Its way too long these days. Like so long it overflows even enlarged buffer. We should prune these messages down to one line per hw device or serious problems only. especially if you turn on encryption options. I can understand that output being useful for debugging, but there should be a way to not deal with it in the normal case. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - 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] break_lock forever broken
Yes that's the tradeoff. I just feel that the former may be better, especially because the latter can be timing dependant (so you may get things randomly happening), and the former is apparently very low overhead compared with the cost of taking the lock. Any numbers, anyone? as I said, since the cacheline just got dirtied, the write is just half a cycle which is so much in the noise that it really doesn't matter. - 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/
dmesg verbosity [was Re: AGP bogosities]
Hi! I'm fascinated that not a single person picked up on this problem whilst the agp code sat in -mm. Even if DRI isn't enabled, every box out there with AGP that uses the generic routines (which is a majority), should have barfed loudly when it hit this check during boot. Does no-one read dmesg output any more ? Its way too long these days. Like so long it overflows even enlarged buffer. We should prune these messages down to one line per hw device or serious problems only. especially if you turn on encryption options. I can understand that output being useful for debugging, but there should be a way to not deal with it in the normal case. Perhaps we could have a rule like non-experimental driver may only print out one line per actual device? (and perhaps: dmesg output for boot going okay should fit on one screen). Or perhaps we should have warnings-like regression testing. New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg junk. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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] break_lock forever broken
Arjan van de Ven wrote: Yes that's the tradeoff. I just feel that the former may be better, especially because the latter can be timing dependant (so you may get things randomly happening), and the former is apparently very low overhead compared with the cost of taking the lock. Any numbers, anyone? as I said, since the cacheline just got dirtied, the write is just half a cycle which is so much in the noise that it really doesn't matter. Yes, you were the apparently that I cited :) I just wondered if Ingo has or has seen numbers that make him dislike this way of doing it. I would have thought that the spinlock structure and code bloat, and the lock break checks in fast paths would be the far greater cost of lockbreak than what Hugh's patch adds. But real numbers are pretty important when it comes to this kind of thing. - 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/
