Re: [PATCH] Kprobes i386 fix for mark ro data
On 6/7/07, S. P. Prasanna <[EMAIL PROTECTED]> wrote: > >It faulted when it tried to write the breakpoint instruction into the > >running kernel's executable code. Apparently the kernel code is now marked > >read-only? > > > > > Yes it would appear to be the case as user has CONFIG_DEBUG_RODATA > set. Patrick - can you turn this off and retest? It's under Kernel > Hacking, Write protect kernel read only data structures. > Ian, Please find the fix as suggested by Andi Kleen for the above stated problem. Thanks Prasanna I went to test the fix and first of all went to replicate the problem. My build has CONFIG_DEBUG_RODATA set but the problem does not occur without the patch. Should I be concerned about this and raise a bug for that as I would think that means there is a problem that the read only protection isn't working (this is off Linus' tree synced tonight). Patrick - can you test whether this patch fixes your problem? You said disabling CONFIG_DEBUG_RODATA fixed your problem but can you try re-enabling and testing this patch? Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/2] 2.6.22-rc5: known regressions with patches
Andrew,
Can this one be merged so that it makes it into 2.6.22?
Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on 2.6.22-rc2
References : http://lkml.org/lkml/2007/5/23/202
Submitter : William Cohen <[EMAIL PROTECTED]>
Ian McDonald <[EMAIL PROTECTED]>
Handled-By : S. P. Prasanna <[EMAIL PROTECTED]>
Patch : http://lkml.org/lkml/2007/6/7/2
Status : patch available
Regards,
Ian
--
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [1/2] 2.6.22-rc5: known regressions with patches
On 6/21/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote: >> Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on >> 2.6.22-rc2 >> References : http://lkml.org/lkml/2007/5/23/202 >> Submitter : William Cohen <[EMAIL PROTECTED]> >> Ian McDonald <[EMAIL PROTECTED]> >> Handled-By : S. P. Prasanna <[EMAIL PROTECTED]> >> Patch : http://lkml.org/lkml/2007/6/7/2 >> Status : patch available Patch was just merged: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55181000cd60334fe920c65ffbcdfe0e3f1de406 I see that just makes KPROBES and DEBUG_RODATA mutually exclusive which makes sense for 2.6.22 Michal - don't kill this one so we have the full fix in 2.6.23 Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/2] 2.6.22-rc5: known regressions with patches
On 6/21/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: Well, for 2.6.22, Kprobes will just be disabled if you use DEBUG_RODATA. And yes, that patch already got merged. However, the patch to *allow* Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, and quite frankly, I don't think I would even want that patch. Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in "working around it". Better just admit it. Linus It depends on the purpose of DEBUG_RODATA. If DEBUG_RODATA was for security reasons then I agree, but it seems to be more to catch accidental writes. Kprobes isn't an accidental write and I would suspect many developers would want to catch accidental writes and be able to insert kprobes. Or is there something else I'm missing - i.e. you're saying the patch itself is crap? Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/2] 2.6.22-rc5: known regressions with patches
On 6/21/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: And yes, sometimes debugging *does* change what it debugs. In timing, if nothing else, but also in the kinds of things you can do. Totally agree. For example, we don't allow slab redzoning on data structures that have alignment restrictions not compatible with the redzoning, and I'd argue that this is more of the same: we just should not do DEBUG_RODATA if you expect to change read-only data. Well the description for DEBUG_RODATA is: Mark the kernel read-only data as write-protected in the pagetables, in order to catch accidental (and incorrect) writes to such const data. What we are doing with kprobes is neither accidental, nor incorrect. There's just no *point*. Linus I understand your philosophical viewpoint here. Anyway it's no biggie as can keep the patch out of tree if I want it... Another option is to be able to enable and disable protecting read only data via a sysctl but that seems even uglier. Anyway I'll stop wasting your time now. Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Fwd: segfault : modprobe dccp_probe/tcp_probe
On 6/7/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote: On 06/06/2007 04:47 PM, Ian McDonald wrote: > Hi there, > > We've seen a report of a problem with dccp_probe as shown below. The > user has also verified that it occurs in tcp_probe as well. This is on > Dave Miller's tree but that currently tracks Linus' tree quite > closely. I do note that it is around 2.6.22-rc2 timeframe so there is > a possibility fixes may have gone in since. > It faulted when it tried to write the breakpoint instruction into the running kernel's executable code. Apparently the kernel code is now marked read-only? Yes it would appear to be the case as user has CONFIG_DEBUG_RODATA set. Patrick - can you turn this off and retest? It's under Kernel Hacking, Write protect kernel read only data structures. The list of commits that I see around this are at: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=commit&s=DEBUG_RODATA I suspect it's probably one of the latter ones giving the timing. I guess there are a couple of solutions here - either make kprobes conflict with CONFIG_DEBUG_RODATA so you can do one or the other, or look into more detail what access kprobes need. Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] the overdue eepro100 removal
On 7/10/07, Bill Davidsen <[EMAIL PROTECTED]> wrote: If there were any benefit to removing a working driver I would at least be able to see it as a resources issue, but as far as I can see you just seem to have a personal preference for the e100 driver and want to force others to use it because you are so much better able to decide what users need than the system administrators. That's one of the reasons people choose open source, because they have a choice, and can use what's best for them. And be thankful it is open source. If Microsoft drops a driver in Vista you don't have a choice. If Linux drops a driver you can go and patch it back in if you feel that passionate about it. Unfortunately things change in life but at least you have the choice of being stuck with the old bit-rotting driver if you really want to. Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][dccp] Fix memory leak and clean up style - dccp_feat_empty_confirm()
On 7/27/07, Jesper Juhl <[EMAIL PROTECTED]> wrote: Greetings, There's a memory leak in net/dccp/feat.c::dccp_feat_empty_confirm(). If we hit the 'default:' case of the 'switch' statement, then we return without freeing 'opt', thus leaking 'struct dccp_opt_pend' bytes. The leak is fixed easily enough by adding a kfree(opt); before the return statement. The patch also changes the layout of the 'switch' to be more in line with CodingStyle. Patch has been compile tested. Please consider merging. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> Signed-off-by: Ian McDonald <[EMAIL PROTECTED]> -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [148/2many] MAINTAINERS - DCCP PROTOCOL
On 8/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7f54480..c786066 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1434,6 +1434,8 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://linux-net.osdl.org/index.php/DCCP > S: Maintained > +F: include/linux/dccp.h > +F: net/dccp/ > Provided this patch series goes in then we need to add this in as well as part of DCCP subsystem: F: include/linux/tfrc.h Once this is done, and series goes in then: Acked-by: Ian McDonald <[EMAIL PROTECTED]> -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] net/DCCP: fix link error with !CONFIG_SYSCTL
On 10/16/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > Subject: net/DCCP: fix link error with !CONFIG_SYSCTL > From: Ingo Molnar <[EMAIL PROTECTED]> > > do not define the sysctl_dccp_sync_ratelimit sysctl variable in > the CONFIG_SYSCTL dependent sysctl.c module - move it to input.c instead. > > this fixes the following build bug: > > net/built-in.o: In function `dccp_check_seqno': > input.c:(.text+0xbd859): undefined reference to `sysctl_dccp_sync_ratelimit' > distcc[29953] ERROR: compile (null) on localhost failed > make: *** [vmlinux] Error 1 > > found via 'make randconfig' build testing. > > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Ingo - this should go via [EMAIL PROTECTED] or [EMAIL PROTECTED] so it gets picked up by a maintainer. Signed-off-by: Ian McDonald <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: {Spam?} [PATCH] NET: Remove obsolete traffic shaper code.
On 4/15/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: Remove the obsolete code for the traffic shaper. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> Apart from the merits of removing this which I can't comment on, I thought the usual procedure was to place a removal in Documentation/feature-removal-schedule.txt to notify people of what is going to be removed. Then wait the period you determine there and then remove. Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: {Spam?} Re: {Spam?} [PATCH] NET: Remove obsolete traffic shaper code.
On 4/15/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: in fact, according to this: http://lkml.org/lkml/2006/1/13/139 that notice was put in the feature removal file well over a year ago, during 2.6.15. so that would seem to be more than adequate time for everyone to prepare for it. but it must have been deleted from that file since then as well. Yes and that was never merged and so was resent on January 19th, 2006: http://www.nabble.com/-2.6-patch--schedule-SHAPER-for-removal-t949871.html At that point people debated about it being too short notice and the patch never went in. I therefore think we can't just remove with NO notice. Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Slab corruption - file_free_rcu ?
Folks, I'm getting this sort of message in my logs on occasion and my system dies on me some time later. Mar 13 08:52:02 localhost kernel: [ 343.931624] Slab corruption: start=d2756f04, len=208 Mar 13 08:52:02 localhost kernel: [ 343.932366] Redzone: 0x5a2cf071/0x5a2cf071. Mar 13 08:52:02 localhost kernel: [ 343.932797] Last user: [](file_free_rcu+0xf/0x11) Mar 13 08:52:02 localhost kernel: [ 343.933429] 090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 75 6b Mar 13 08:52:02 localhost kernel: [ 343.934225] 0a0: 6b 6b 6b 6b 6b 6b 00 6b 6b 6b 6b 6b 6b 6b 00 6b Mar 13 08:52:02 localhost kernel: [ 343.934999] 0b0: 6b 6b 6b 6b 6b 6b ad 6b 6b 6b 6b 6b 6b 6b 6b 6b Mar 13 08:52:02 localhost kernel: [ 343.935995] Prev obj: start=d2756e28, len=208 Mar 13 08:52:02 localhost kernel: [ 343.936740] Redzone: 0x5a2cf071/0x5a2cf071. Mar 13 08:52:02 localhost kernel: [ 343.937182] Last user: [](file_free_rcu+0xf/0x11) Mar 13 08:52:02 localhost kernel: [ 343.937682] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Mar 13 08:52:02 localhost kernel: [ 343.938473] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Mar 13 09:06:37 localhost kernel: klogd 1.4.1#20, log source = /proc/kmsg started. Kernel is Linus' git tree as of 3 days ago (i.e. post 2.6.21rc3). I do have some DCCP changes in there but those modules were not loaded at the time. I've had a quick look through lkml archives and can't find anything on this in last few days. Apologies if I've missed something. I'm not sure how long this has been occurring. I have been having slab corruption on earlier kernels but they did not put an identifier on last usage. This may have been issues with my Broadcom 4306 card as this used to have lots of errors as well, until more recent kernels where stability on that is much better. My config is attached. Please cc me on any queries as I'm not subscribed to lkml. Regards, Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group config.gz Description: GNU Zip compressed data
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On 3/5/07, Matt Mackall <[EMAIL PROTECTED]> wrote: > This is due to the recent sysfs restructuring I think. IIRC the fix is > to upgrade hal to a current git version. If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE. I will try a new HAL when it shows up in Debian/unstable and not a moment sooner. But you're running a kernel that's not in Debian/unstable so this seems a bit hypocritical. When you work with bleeding edge kernels you have to be prepared to work around things. Hell for ages git wasn't in Debian - unstable even, udev would break things etc. Just my 2c worth. -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/WARN] Error initialising drivers in PCI
I'm getting this in my logs when starting up after going from a
2.6.20rc5 kernel (which didn't do this) to Linus' latest tree as of 36
hours ago:
Feb 18 14:52:32 localhost kernel: [ 16.392136] Uniform
Multi-Platform E-IDE driver Revision: 7.00alpha2
Feb 18 14:52:32 localhost kernel: [ 16.392210] ide: Assuming 33MHz
system bus speed for PIO modes; override with idebus=xx
Feb 18 14:52:32 localhost kernel: [ 16.395039] Probing IDE interface ide0...
Feb 18 14:52:32 localhost kernel: [ 16.780057] hda: ST315310A, ATA DISK drive
Feb 18 14:52:32 localhost kernel: [ 17.391365] Probing IDE interface ide1...
Feb 18 14:52:32 localhost kernel: [ 18.184752] hdc: LTN485, ATAPI
CD/DVD-ROM drive
Feb 18 14:52:32 localhost kernel: [ 18.490570] ide0 at
0x1f0-0x1f7,0x3f6 on irq 14
Feb 18 14:52:32 localhost kernel: [ 18.490978] ide1 at
0x170-0x177,0x376 on irq 15
Feb 18 14:52:32 localhost kernel: [ 18.493214] hda: max request size: 128KiB
Feb 18 14:52:32 localhost kernel: [ 18.493735] hda: 29336832 sectors
(15020 MB) w/2048KiB Cache, CHS=29104/16/63
Feb 18 14:52:32 localhost kernel: [ 18.493899] hda: cache flushes
not supported
Feb 18 14:52:32 localhost kernel: [ 18.494530] hda: hda1 hda2 < hda5 >
Feb 18 14:52:32 localhost kernel: [ 18.536466] ata_piix
:00:1f.1: version 2.00ac7
Feb 18 14:52:32 localhost kernel: [ 18.536579] ata: 0x1F0 IDE port busy
Feb 18 14:52:32 localhost kernel: [ 18.536583] ata: conflict with ide0
Feb 18 14:52:32 localhost kernel: [ 18.536719] BUG: at
drivers/pci/pci.c:840 pcim_pin_device()
Feb 18 14:52:32 localhost kernel: [ 18.536786] []
show_trace_log_lvl+0x1a/0x2f
Feb 18 14:52:32 localhost kernel: [ 18.536897] []
show_trace+0x12/0x14
Feb 18 14:52:32 localhost kernel: [ 18.536991] []
dump_stack+0x16/0x18
Feb 18 14:52:32 localhost kernel: [ 18.537085] []
pcim_pin_device+0x40/0x4d
Feb 18 14:52:32 localhost kernel: [ 18.537201] []
ata_pci_init_one+0x1ac/0x4bb
Feb 18 14:52:32 localhost kernel: [ 18.537330] []
piix_init_one+0x418/0x435
Feb 18 14:52:32 localhost kernel: [ 18.537431] []
pci_device_probe+0x39/0x5b
Feb 18 14:52:32 localhost kernel: [ 18.537528] []
really_probe+0xbd/0x145
Feb 18 14:52:32 localhost kernel: [ 18.537638] []
driver_probe_device+0x95/0xa1
Feb 18 14:52:32 localhost kernel: [ 18.537734] []
__driver_attach+0x6a/0xa1
Feb 18 14:52:32 localhost kernel: [ 18.537829] []
bus_for_each_dev+0x36/0x5b
Feb 18 14:52:32 localhost kernel: [ 18.537925] []
driver_attach+0x19/0x1b
Feb 18 14:52:32 localhost kernel: [ 18.538019] []
bus_add_driver+0x6a/0x170
Feb 18 14:52:32 localhost kernel: [ 18.538114] []
driver_register+0x79/0x7e
Feb 18 14:52:32 localhost kernel: [ 18.538209] []
__pci_register_driver+0x7b/0xa8
Feb 18 14:52:32 localhost kernel: [ 18.538381] []
piix_init+0x14/0x27
Feb 18 14:52:32 localhost kernel: [ 18.538496] [] init+0x95/0x17a
Feb 18 14:52:32 localhost kernel: [ 18.538597] []
kernel_thread_helper+0x7/0x10
Feb 18 14:52:32 localhost kernel: [ 18.538693] ===
Feb 18 14:52:32 localhost kernel: [ 18.538752] ata: 0x170 IDE port busy
Feb 18 14:52:32 localhost kernel: [ 18.538756] ata: conflict with ide1
Feb 18 14:52:32 localhost kernel: [ 18.538905] ata_piix: probe of
:00:1f.1 failed with error -16
Kernel is standard tree with no modifications.
Relevant code which triggers this from devices/pci/pci.c is:
void pcim_pin_device(struct pci_dev *pdev)
{
struct pci_devres *dr;
dr = find_pci_dr(pdev);
WARN_ON(!dr || !dr->disable);
if (dr)
dr->disable = 0;
}
and it is the WARN_ON that is the line.
.config of kernel is attached.
output of lspci -vv is attached.
Can you please cc me on any discussions/requests as not subscribed to lkml.
NB Machine continues with boot and can run after this. Machine is a
little unstable though but could also be Broadcom 4306 issues as not
sure these drivers are yet stable on my machine...
Ian
--
Web: http://wand.net.nz/~iam4
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group
config.gz
Description: GNU Zip compressed data
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory
Controller Hub (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset
Graphics Controller] (rev 02) (prog-if 00 [VGA])
Subsystem: Compaq Computer Corporation Unknown device 0019
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 01) (prog-if 00
[Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66
Re: [BUG/WARN] Error initialising drivers in PCI
On 2/19/07, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: Ian, you have an PATA controller so there is no need to use ata_piix. Just disabling ata_piix should workaround the issue. OK. I have done this and the message goes away in boot logs. As you say I don't need the old drivers anymore. If you want me to test any fixes so both can coexist without throwing a warning then just drop me a line. Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: allow multiple calls to pcim_pin_device()
On 2/20/07, Tejun Heo <[EMAIL PROTECTED]> wrote: Sanity check in pcim_pin_device() was too restrictive in that it didn't allow multiple calls to the function, which is against the devres philosohpy of fire-and-forget. Track pinned status separately and allow pinning multiple times. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- It was an actual bug in pcim_pin_device() implementation. Thanks for spotting this. :-) Ian McDonald, please verify your warning goes away with this patch. Yes it does. Thanks for sorting. Greg, please forward this patch upstream once Ian acks it. Acked-by: Ian McDonald <[EMAIL PROTECTED]> -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?
On 2/21/07, bert hubert <[EMAIL PROTECTED]> wrote: I'm trying to figure out which processes have the most impact, I had already killed anything non-essential. But that still leaves 140 pids. Bert That sounds way too many pids. I run a script to shut down processes when I do testing as it makes a HUGE difference to my timing of things which can be quite critical. Here's my list of 46 and that includes me sshing into a box and checking for processes: UnIDPID PPID CMD root 1 0 init [2] root 2 1 [ksoftirqd/0] root 3 1 [watchdog/0] root 4 1 [events/0] root 5 1 [khelper] root 6 1 [kthread] root40 6 [kblockd/0] root41 6 [kacpid] root 110 6 [cqueue/0] root 111 6 [ata/0] root 112 6 [ata_aux] root 113 6 [kseriod] root 135 6 [rt-test-0] root 137 6 [rt-test-1] root 139 6 [rt-test-2] root 141 6 [rt-test-3] root 143 6 [rt-test-4] root 145 6 [rt-test-5] root 147 6 [rt-test-6] root 149 6 [rt-test-7] root 151 6 [pdflush] root 152 6 [pdflush] root 153 6 [kswapd0] root 154 6 [aio/0] root 838 6 [kedac] root 843 6 [kjournald] root 1720 6 [ksuspend_usbd] root 1721 6 [khubd] root 1741 6 [kpsmoused] root 2544 1 /sbin/syslogd root 2554 1 /sbin/klogd -x root 2851 1 /usr/sbin/inetd root 2863 1 /usr/sbin/sshd ntp 2954 1 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 111:111 -g root 3061 1 /bin/login -- root 3062 1 /sbin/getty 38400 tty2 root 3063 1 /sbin/getty 38400 tty3 root 3064 1 /sbin/getty 38400 tty4 root 3065 1 /sbin/getty 38400 tty5 root 3066 1 /sbin/getty 38400 tty6 ian 3083 3061 -bash root 21518 2863 sshd: ian [priv] ian 21520 21518 sshd: [EMAIL PROTECTED]/1 ian 21521 21520 -bash ian 21747 21521 ps -ef -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] CIFS won't link
In commit fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9
test_clear_page_dirty was removed a couple of days ago.
Now when I try and build I get this:
WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
This is caused by line 1248 of fs/cifs/file.c
if (PageWriteback(page) ||
!test_clear_page_dirty(page)) {
This isn't my area of expertise so I'm not providing a fix as I'm sure
I'll get it wrong!
My apologies if people have already fixed as I'm not on all the relevant lists.
Regards,
Ian
--
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
