Re: [PATCH 2.6] Fix i2c messsage flags in video drivers
Hi Ronald, [Jean Delvare] It is possible that people are able to get their board to still work without my patch, if the chips were properly configured in the first place and they don't attempt to reconfigure them (like norm change). I don't know the chips well enough to tell how probable this is. [Ronald S. Bultje] I'm pretty sure the patch is correct, I trust you a lot more on that than myself (I still need to test it, though; but that's a detail). However, this statement is not correct. I test this driver daily, I still own a whole bunch of such cards. Even after hard reboots, they still just work. Norm changes, input changes, everything works. I test (and use) all of this. I would've noticed if it was really as broken as you're describing above. I'm glad to learn you are testing things. Still the oops in saa7110 went unnoticed for the past 3 months, so I guess that either you don't have a DC10(+) in your test panel, or you did not test mm/rc kernels. I've gone through the code again, and here is what I think is broken in 2.6.11 on the various Zoran-based boards. Then everyone will be free to pick any patch chunk he/she wants and apply it to any tree he/she likes. BUZ: Input (saa7111): works Output (saa7185): no init, cannot set norm DC10: Input (saa7110): oops Output (adv7175): no init, cannot set norm DC30: Input (vpx3220): works Output (adv7175): no init, cannot set norm LM33: Input (bt819): no init Output (bt856): works LM33R10: Input (saa7114): no init, cannot set norm Output (adv7170): no init, cannot set norm As you can see, all boards are affected at some level but every user might not be equally affected, depends whether you use input or output or both. Note that no init might not affect everyone either, depends on the chip init defaults and the user needs. Ronald, can you tell us what exactly in the above you are testing? Personally I have only been able to test input on a DC10+ board (saa7110 driver). I lack hardware to test the output. Hope that clarifies things, -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 i2c messsage flags in video drivers
Hi Jean, thanks for the reply. On Thu, 10 Mar 2005, Jean Delvare wrote: I'm glad to learn you are testing things. Still the oops in saa7110 went unnoticed for the past 3 months, so I guess that either you don't have a DC10(+) in your test panel, or you did not test mm/rc kernels. I indeed don't test RC/MM kernels. I'm fairly happy with the current driver status, so I'm not doing any active new development on it. I run standard Fedora kernels with CVS of the driver (which is the same as what's in 2.6.10). BUZ: Input (saa7111): works Output (saa7185): no init, cannot set norm I have this card, but it's no in my computer (not enough PCI slots). Last test is from a few months back. Other people (co-developers) test this for me whenever I make small driver changes. They report that it works, whatever that means. ;). I know they regularly use it for capture, so at least MJPEG capture and overlay display has to work to some degree. Output may be untested. DC10: Input (saa7110): oops Output (adv7175): no init, cannot set norm DC30: Input (vpx3220): works Output (adv7175): no init, cannot set norm I have those two. Both work fine. I test raw capture, MJPEG capture and overlay display at least once a week. I don't get an oops on the DC10. I haven't tested output lately. I basically only test output when I make changes to the relevant modules, and I haven't done that lately. Last time I tested it (which must be around the time the driver was integrated into the kernel, so before 2.6.0...), it worked for me. LM33: Input (bt819): no init Output (bt856): works LM33R10: Input (saa7114): no init, cannot set norm Output (adv7170): no init, cannot set norm See Buz. As you can see, all boards are affected at some level but every user might not be equally affected, depends whether you use input or output or both. Note that no init might not affect everyone either, depends on the chip init defaults and the user needs. Ronald, can you tell us what exactly in the above you are testing? My experience is not the same as yours, it seems... I cannot explain why, unfortunately. Again, I'm sure your patch is correct, I'm just reporting that I'm not seeing the same thing that you're seeing. Ronald - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 i2c messsage flags in video drivers
Hi Ronald, I indeed don't test RC/MM kernels. I'm fairly happy with the current driver status, so I'm not doing any active new development on it. I run standard Fedora kernels with CVS of the driver (which is the same as what's in 2.6.10). (...) My experience is not the same as yours, it seems... I cannot explain why, unfortunately. (...) I can. You are using a 2.6.10 kernel at best (that's what FC3 updates have), and the bug is triggered by changes made to the i2c-algo-bit driver somewhere between 2.6.10 and 2.6.11. So it's not surprising that you don't see any problem. Note that the version of the media/video drivers you use is not relevant here. The bug has been there for over a year, but the code path where it lies was never taken until i2c-algo-bit was updated recently. What matters is the version of i2c-algo-bit. So as long as you don't move to a 2.6.11 kernel, don't even bother trying my patches, because you will never hit the code that I am trying to fix. Thanks, -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] fix call kobject_get_path() with zero kobject argument in drivers/base/class.c
The attached patch fix call kobject_get_path() with zero kobject argument. I'm sorry. My previous patch was incorrect. -- Regards, JustMan. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 pull] drm tree for 2.6.12
Hi Linus, The latest DRM tree is ready (bit late but I got there..), it contains updated radeon driver, splitting of drm structure to allow for multi-head (no drivers just internal structure changes, credits updates, static function updates and pci ids update. The patch is up at http://www.skynet.ie/~airlied/patches/lk_drm/drm_2_6_12_heads_fixes.patch The BK Tree is at: bk pull bk://drm.bkbits.net/drm-linus This will include the latest DRM changes and will update the following files: CREDITS |5 MAINTAINERS |4 drivers/char/drm/drmP.h | 42 +++--- drivers/char/drm/drm_agpsupport.c | 16 +- drivers/char/drm/drm_auth.c |4 drivers/char/drm/drm_bufs.c | 20 +-- drivers/char/drm/drm_context.c| 12 - drivers/char/drm/drm_drv.c| 48 ++- drivers/char/drm/drm_fops.c | 20 +-- drivers/char/drm/drm_ioctl.c | 12 + drivers/char/drm/drm_irq.c|6 drivers/char/drm/drm_lock.c |4 drivers/char/drm/drm_os_linux.h |2 drivers/char/drm/drm_pciids.h |2 drivers/char/drm/drm_proc.c |6 drivers/char/drm/drm_scatter.c|4 drivers/char/drm/drm_stub.c | 166 + drivers/char/drm/drm_vm.c | 16 +- drivers/char/drm/i810_dma.c | 130 ++-- drivers/char/drm/i810_drv.c |3 drivers/char/drm/i810_drv.h | 46 --- drivers/char/drm/i830_dma.c | 142 ++ drivers/char/drm/i830_drv.c |3 drivers/char/drm/i830_drv.h | 40 -- drivers/char/drm/i830_irq.c |4 drivers/char/drm/i915_drv.c |2 drivers/char/drm/mga_dma.c| 61 - drivers/char/drm/mga_drv.c|2 drivers/char/drm/mga_drv.h| 13 -- drivers/char/drm/mga_state.c | 44 +++--- drivers/char/drm/r128_cce.c |4 drivers/char/drm/r128_drv.c |2 drivers/char/drm/r128_drv.h | 16 -- drivers/char/drm/r128_state.c | 62 - drivers/char/drm/radeon_cp.c |5 drivers/char/drm/radeon_drm.h |9 + drivers/char/drm/radeon_drv.c |2 drivers/char/drm/radeon_drv.h | 35 + drivers/char/drm/radeon_irq.c | 10 - drivers/char/drm/radeon_state.c | 245 +++--- drivers/char/drm/sis_drv.c|2 drivers/char/drm/sis_drv.h|7 - drivers/char/drm/sis_ds.c | 84 - drivers/char/drm/sis_ds.h | 19 -- drivers/char/drm/sis_mm.c | 41 +++--- drivers/char/drm/tdfx_drv.c |2 46 files changed, 651 insertions(+), 773 deletions(-) through these ChangeSets: [EMAIL PROTECTED](none) (05/03/10 1.2011) drm: fix setversion ioctl zeroing Egbert Eich reported a bug 2673 on bugs.freedesktop.org and tracked it down to a missing memset in the setversion ioctl, this causes X server crashes so I would like to see the fix in a 2.6.11.x tree if possible.. From: Egbert Eich [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] [EMAIL PROTECTED](none) (05/03/10 1.1994.21.4) drm: upgrade radeon driver to 1.15 add support for texture micro tiling on radeon/r200. Add support for r100 cube maps (since it also requires a version bump). From: Roland Scheidegger [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] [EMAIL PROTECTED](none) (05/03/10 1.1994.21.3) drm: cleanup i810/i830 drivers Cleanup patch for i810/i830 From: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] [EMAIL PROTECTED](none) (05/03/10 1.1994.21.2) drm: cleanup patch This makes a lot of functions static and cleans up a few other minor things. From: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] [EMAIL PROTECTED](none) (05/03/10 1.1994.21.1) drm: fix radeon pci id fd.o bug #2576: Add support for ATI RN50/ES1000. (ATI Technologies Inc.) From: Michel Daenzer [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] [EMAIL PROTECTED](none) (05/03/10 1.1994.20.1) drm: split out structure into heads This patch splits out the main drm structures for future multi-head support. It just sets up the structures and the stub functions for putting/getting heads From: Jon Smirl [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] [EMAIL PROTECTED](none) (05/03/09 1.1994.9.3) drm: fixup CREDITS and MAINTAINERS Add myself to MAINTAINERS for drm, and fixup my CREDITS. Signed-off-by: Dave Airlie [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make st seekable again
On Wed, 9 Mar 2005, Alan Cox wrote: On Mer, 2005-03-09 at 21:58, Kai Makisara wrote: While waiting for the application to be fixed, it was decided to restore the old behaviour of the tape drivers. Which means tar won't get fixed 8( Bet that's true. I don't think implementing proper read-only lseek for tapes is worth the trouble (reliable tracking of the current location is tricky). Purist kernels can refuse lseeks. Pragmatic kernels can allow lseeks until refusing those won't break common applications. The problem is the existing behaviour code isn't just 'not useful' its badly broken. No locking, no overflow checks, updates the wrong variable etc. It is asking for nasty accidents with critical user data. In other words, it should work correctly or not at all. At the least this should be a config option, like UNSAFE_TAPE_POSITIONING or some such. And show the option if the build includes BROKEN features. That should put the decision where it belongs and clarify the possible failures. Caould you live with that, Alan? -- bill davidsen [EMAIL PROTECTED] CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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: One more Asus SMBus quirk
On Wed, 9 Mar 2005, Greg KH wrote: On Wed, Mar 09, 2005 at 11:06:15AM -0500, Bill Davidsen wrote: On Tue, 8 Mar 2005, Greg KH wrote: On Tue, Mar 08, 2005 at 05:18:16PM -0500, Bill Davidsen wrote: Greg KH wrote: ChangeSet 1.1998.11.27, 2005/02/25 15:48:28-08:00, [EMAIL PROTECTED] [PATCH] PCI: One more Asus SMBus quirk One more Asus laptop requiring the SMBus quirk (W1N model). Signed-off-by: Jean Delvare [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] Hopefully this and the double-free patch will be included in 2.6.11.n+1? what double-free patch? ChangeSet 1.1998.11.26, 2005/02/25 15:48:12-08:00 See [EMAIL PROTECTED]. Giving just the Subject: would have been easier to find the patch... But... but... but it was YOUR PATCH, wasn't it? That's kind of why I didn't expect much problem identifying it, I got it from you. Or do you feel the possible results are harmless enough to wait for the next release? Your call, obviously. I'll add it to the -stable queue, thanks for pointing it out. Great, then I didn't waste your time with it. I'm still feeling out what's worth suggesting for -stable, as you probably guessed. -- bill davidsen [EMAIL PROTECTED] CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] make st seekable again
critical user data. In other words, it should work correctly or not at all. At the least this should be a config option, like UNSAFE_TAPE_POSITIONING or some such. And show the option if the build includes BROKEN features. That should put the decision where it belongs and clarify the possible failures. CONFIG_SECURITY_HOLES doesn't make sense. Better to just fix the security holes instead. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.11] fix: drivers/base/class.c
fix: drivers/base/class.c
Signed-off-by: Serge A. Suchkov [EMAIL PROTECTED]
diff -uNrp linux/drivers/base/class.orig.c linux/drivers/base/class.c
--- linux/drivers/base/class.orig.c 2005-03-10 12:19:00.0 +0300
+++ linux/drivers/base/class.c 2005-03-10 13:59:27.0 +0300
@@ -307,12 +307,14 @@ static int class_hotplug(struct kset *ks
if (class_dev-dev) {
/* add physical device, backing this device */
struct device *dev = class_dev-dev;
- char *path = kobject_get_path(dev-kobj, GFP_KERNEL);
- add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size,
-length, PHYSDEVPATH=%s, path);
- kfree(path);
+ if(kobject_name(dev-kobj)) {
+ char *path = kobject_get_path(dev-kobj, GFP_KERNEL);
+ add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size,
+length, PHYSDEVPATH=%s, path);
+ kfree(path);
+ }
/* add bus name of physical device */
if (dev-bus)
add_hotplug_env_var(envp, num_envp, i,
--
Regards, JustMan.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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]
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?
It it does, I'll do a correct [PATCH] post later with all the
signed-off-by and subject and stuff.
Please make sure you test with the same configuration that produces the
error, because this is a pretty hard to hit bug. The needed conditions are:
- 'nm' changes the order of 2 aliased symbols from the 1st to the 2nd pass
- one of those symbols get sampled for token optimization. With your
configuration the sampling was about 1 out of 12.
- the difference in the name of those symbols makes the algorithm
select different tokens. As 1024 symbols are used to produce the tokens,
changing just one of these symbols can easily go unnoticed.
- the difference in the tokens selected makes the size of the
compressed data change, so that it goes above (or below) an alignment
boundary. In your case it only changed 2 bytes in size, but it crossed a
4 byte alignment boundary.
With your .config file but a different set of tools (gcc, binutils
versions) I couldn't trigger the bug in my machine.
--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
--- ./scripts/kallsyms.c.orig 2005-03-10 11:00:26.0 +
+++ ./scripts/kallsyms.c2005-03-10 11:11:50.0 +
@@ -499,11 +499,30 @@ static void forget_symbol(unsigned char
forget_token(symbol + i, len - i);
}
+/* sort the symbols by address-name so that even if aliased symbols
+ * change position, or the symbols are not supplied in address order
+ * the algorithm will work nevertheless */
+
+static int sort_by_address_name(const void *a, const void *b)
+{
+ struct sym_entry *sa, *sb;
+
+ sa = (struct sym_entry *) a;
+ sb = (struct sym_entry *) b;
+
+ if (sa-addr != sb-addr)
+ return sa-addr - sb-addr;
+
+ return strcmp(sa-sym + 1, sb-sym + 1);
+}
+
/* set all the symbol flags and do the initial token count */
static void build_initial_tok_table(void)
{
int i, use_it, valid;
+ qsort(table, cnt, sizeof(table[0]), sort_by_address_name);
+
valid = 0;
for (i = 0; i cnt; i++) {
table[i].flags = 0;
Re: [BUG] 2.6.11- sym53c8xx Broken on pp64
On Thu, Mar 10, 2005 at 04:59:43PM +1100, Benjamin Herrenschmidt wrote: Ok, we have it working here on a similar machine with 2.6.11 and failing in a similar way with bk which is why I asked ;) The bk problem is found fixed here tho. I'll send a patch later, it's a bug with ppc64 iounmap() not properly flushing the hash table after the set_pte_at() patch due to some crap in our custom implementation of that guy. Heh, the devel version of sym2 (that isn't submitted yet because it depends on a few changes to the SPI transport that James hasn't integrated yet) would probably fix this as it doesn't call iounmap() until the driver exits. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] keys: Discard key spinlock and use RCU for key payload [try #3]
David Howells [EMAIL PROTECTED] wrote: The attached patch changes the key implementation in a number of ways: That worked. What's with the preempt_enable()/disable() added to __key_link()? It's not obvious what is being protected from what, and why. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ITE8212
Well I got my ITE8212 today (only ordered it last night - whee) and here
are the happy fun results. Basically the card shoved itself to the front
of the queue, gave some weird errors on bootup and had no multisec set
on the drives attached to it. I can boot the machine though and am using
it right now to route my traffic (amongst other things). Am quite happy
to help debug - just need to know what to do. :)
Thanks.
IT8212: IDE controller at PCI slot :00:0d.0
PCI: Found IRQ 11 for device :00:0d.0
IT8212: chipset revision 17
it821x: controller in smart mode.
IT8212: 100% native mode on irq 11
ide0: BM-DMA at 0x1040-0x1047, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1048-0x104f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: ST3200822A, ATA DISK drive
hda: Performing identify fixups.
ide0 at 0x1050-0x1057,0x1072 on irq 11
Probing IDE interface ide1...
hdc: IC35L060AVV207-0, ATA DISK drive
hdc: Performing identify fixups.
ide1 at 0x1058-0x105f,0x1076 on irq 11
PIIX4: IDE controller at PCI slot :00:14.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0x10a0-0x10a7, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0x10a8-0x10af, BIOS settings: hdg:DMA, hdh:DMA
Probing IDE interface ide2...
hde: SAMSUNG SV1022D, ATA DISK drive
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide3...
hdg: AOPEN CD-RW CRW3248 1.12 20020417, ATAPI CD/DVD-ROM drive
hdh: QUANTUM FIREBALLlct20 10, ATA DISK drive
ide3 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG
hda: cache flushes not supported
hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
hda: recal_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda1
hdc: max request size: 128KiB
hdc: 120103200 sectors (61492 MB) w/1821KiB Cache, CHS=16383/255/63, BUG
hdc: cache flushes not supported
hdc:hdc: recal_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: recal_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hdc1 hdc2
hde: max request size: 128KiB
hde: 19931184 sectors (10204 MB) w/472KiB Cache, CHS=19773/16/63
hde: cache flushes not supported
hde: hde1 hde2 hde3 hde4 hde5 hde6 hde7
hdh: max request size: 128KiB
hdh: 20044080 sectors (10262 MB) w/418KiB Cache, CHS=19885/16/63
hdh: cache flushes not supported
hdh: hdh1 hdh2
hdg: ATAPI 48X CD-ROM CD-R/RW drive, 8192kB Cache
[EMAIL PROTECTED]:~# hdparm -v /dev/hda
/dev/hda:
multcount= 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 24321/255/63, sectors = 200049647616, start = 0
[EMAIL PROTECTED]:~# hdparm -v /dev/hdc
/dev/hdc:
multcount= 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 16383/255/63, sectors = 61492838400, start = 0
Both drives have a multcount:
/dev/hda:
Model=ST3200822A, FwRev=3.01, SerialNo=3LJ22Y8F
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs RotSpdTol.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off
CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455
IORDY=on/off
PIO modes: pio0 pio1 pio2
DMA modes: mdma0 mdma1 mdma2
AdvancedPM=no
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:
* signifies the current active mode
/dev/hda:
ATA device, with non-removable media
Model Number: ST3200822A
Serial Number: 3LJ22Y8F
Firmware Revision: 3.01
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 2
Supported: 6 5 4 3
Configuration:
Logical max current
cylinders 16383 65535
heads 16 1
sectors/track 63 63
--
CHS current addressable sectors:4128705
LBAuser addressable sectors: 268435455
LBA48 user addressable sectors: 390721968
device size with M = 1024*1024: 190782 MBytes
device size with M = 1000*1000: 200049 MBytes (200 GB)
Capabilities:
LBA, IORDY(can be disabled)
bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = ?
Recommended acoustic management value: 128, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
*READ BUFFER cmd
[PATCH] AB-BA deadlock between uidhash_lock and tasklist_lock.
We have uncovered a very difficult to trip AB-BA deadlock between the
uidhash_lock and tasklist_lock.
reparent_to_init() does write_lock_irq(tasklist_lock) then calls
switch_uid() which calls free_uid() which grabs the uidhash_lock.
Independent of that, we have seen a different cpu call free_uid as a
result of sys_wait4 and, immediately after acquiring the uidhash_lock,
receive a timer interrupt which eventually leads to an attempt to grab
the tasklist_lock.
Signed-off-by: Robin Holt [EMAIL PROTECTED]
Index: linux/kernel/user.c
===
--- linux.orig/kernel/user.c2004-12-22 13:10:49.0 -0600
+++ linux/kernel/user.c 2004-12-23 11:07:21.100577562 -0600
@@ -90,6 +90,9 @@
void free_uid(struct user_struct *up)
{
+ unsigned long flags;
+
+ local_irq_save(flags);
if (up atomic_dec_and_lock(up-__count, uidhash_lock)) {
uid_hash_remove(up);
key_put(up-uid_keyring);
@@ -97,16 +100,18 @@
kmem_cache_free(uid_cachep, up);
spin_unlock(uidhash_lock);
}
+ local_irq_restore(flags);
}
struct user_struct * alloc_uid(uid_t uid)
{
struct list_head *hashent = uidhashentry(uid);
struct user_struct *up;
+ unsigned long flags;
- spin_lock(uidhash_lock);
+ spin_lock_irqsave(uidhash_lock, flags);
up = uid_hash_find(uid, hashent);
- spin_unlock(uidhash_lock);
+ spin_unlock_irqrestore(uidhash_lock, flags);
if (!up) {
struct user_struct *new;
@@ -132,7 +137,7 @@
* Before adding this, check whether we raced
* on adding the same user already..
*/
- spin_lock(uidhash_lock);
+ spin_lock_irqsave(uidhash_lock, flags);
up = uid_hash_find(uid, hashent);
if (up) {
key_put(new-uid_keyring);
@@ -142,7 +147,7 @@
uid_hash_insert(new, hashent);
up = new;
}
- spin_unlock(uidhash_lock);
+ spin_unlock_irqrestore(uidhash_lock, flags);
}
return up;
@@ -170,6 +175,7 @@
static int __init uid_cache_init(void)
{
int n;
+ unsigned long flags;
uid_cachep = kmem_cache_create(uid_cache, sizeof(struct user_struct),
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
@@ -178,9 +184,9 @@
INIT_LIST_HEAD(uidhash_table + n);
/* Insert the root user immediately (init already runs as root) */
- spin_lock(uidhash_lock);
+ spin_lock_irqsave(uidhash_lock, flags);
uid_hash_insert(root_user, uidhashentry(0));
- spin_unlock(uidhash_lock);
+ spin_unlock_irqrestore(uidhash_lock, flags);
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/
Re: [0/many] Acrypto - asynchronous crypto layer for linux kernel 2.6
Am Dienstag, den 08.03.2005, 00:08 -0500 schrieb Kyle Moffett: Did you include support for the new key/keyring infrastructure introduced a couple versions ago by David Howells? It allows userspace to create and manage various sorts of keys in kernelspace. If you create and register a few keytypes for various symmetric and asymmetric ciphers, you could then take advantage of its support for securely passing keys around in and out of userspace. I've written a dm-crypt patch some weeks ago that does what you describe. The crypto information (cipher and key) is added to a keyring and then the device is constructed using a reference to this key. I had some issues with the keyring code (mainly a deadlock problem with crypto module autoloading): http://lkml.org/lkml/2005/2/4/113 I would also like to switch dm-crypt to acrypto once it's accepted into the kernel. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PATCH] keys: Discard key spinlock and use RCU for key payload [try #3]
Andrew Morton [EMAIL PROTECTED] wrote: What's with the preempt_enable()/disable() added to __key_link()? It's not obvious what is being protected from what, and why. Ummm... Yes... They're probably not necessary. A wmb() may be required after the klist-nkeys++ to commit to memory the fact there's now an extra key link available, but I'm not sure that it's necessary. Do you want me to redo the patch? David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.2
On Wednesday 09 March 2005 18:11, Greg KH wrote: On Wed, Mar 09, 2005 at 01:06:31PM -0800, Matt Mackall wrote: On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote: And to further test this whole -stable system, I've released 2.6.11.2. It contains one patch, which is already in the -bk tree, and came from the security team (hence the lack of the longer review cycle). It's available now in the normal kernel.org places: kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz which is a patch against the 2.6.11.1 release. Argh! @*#$!!! If consensus arrives that this patch should be against the 2.6.11 tree, it will be done that way in the future. Consensus arrived back when 2.6.8.1 came out. It did? So, what was it agreed to be? Any pointers to that agreement? Please, folks, there are automated tools that know about kernel release numbering and so on. Said tools broke with 2.6.11.1 because it wasn't in the same place that 2.6.8.1 was and now this breaks with all precedent by being an interdiff along a branch. 2.6.11.1 is now in the proper place, sorry for any inconvience that caused. This happened yesterday. Fixing it in the future is too #*$%* late because you've now turned it into a special case. No, I can always respin the patch, and re-release it if it's a problem. Somewhat Greg, it caught me out. OTOH, once we know that .2 needs .1, we'll be ok. And it does give a quick method for us frogs to define if one of them is a regression. The only thing that should break if we leave one out of the squence is the EXTRAVERSION path in the Makefile we can certainly fix that easily enough for testing. Question? Is it a given that these, if they don't have warts, will be in mainline 2.6.12? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] keys: Discard key spinlock and use RCU for key payload [try #3]
David Howells [EMAIL PROTECTED] wrote: What's with the preempt_enable()/disable() added to __key_link()? It's not obvious what is being protected from what, and why. Ummm... Yes... They're probably not necessary. A wmb() may be required after the klist-nkeys++ to commit to memory the fact there's now an extra key link available, but I'm not sure that it's necessary. I should perhaps be using smp_wmb() not wmb(). David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] keys: Discard key spinlock and use RCU for key payload [try #3]
David Howells [EMAIL PROTECTED] wrote: Andrew Morton [EMAIL PROTECTED] wrote: What's with the preempt_enable()/disable() added to __key_link()? It's not obvious what is being protected from what, and why. Ummm... Yes... They're probably not necessary. A wmb() may be required after the klist-nkeys++ to commit to memory the fact there's now an extra key link available, but I'm not sure that it's necessary. ok... Do you want me to redo the patch? That, or a delta. At your convenience. What's your feeling on the stabilitypriority of this work? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] keys: Discard key spinlock and use RCU for key payload [try #3]
Andrew Morton [EMAIL PROTECTED] wrote: Do you want me to redo the patch? That, or a delta. At your convenience. A new patch is just as easy. There'll be one with you shortly. What's your feeling on the stability Well... it boots:-) That involves creating and destroying keyrings and linking keyrings into keyrings when knowledge about users other than uid 0 is added to or removed from the kernel. No other key management code is touched except by explicit invocation by syscall or from its in-kernel APIs, and no code in the kernel does that yet. I've also prodded it with my key utilities; adding keys, requesting keys, linking keys, unlinking keys, finding keys, revoking keys, expiring keys, reading keys, listing/describing keys, joining sessions. I've also checked that user-defined keys work using that same set of tools. These tools can be found at: http://people.redhat.com/~dhowells/keys/key-utils.tar.bz2 I've worked them into a form more suitable for release. I still need to write documentation/manual pages and a spec file, and to get it to run on more than just i386, ppc and ppc64. priority of this work? Well... this changes the API for key type implementations, if only in the way locking is used. Various people are looking at using keys for various things, and this change will affect all of them. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: using smp_processor_id() in preemptible [00000001] code: hotplug/461
On Thu, 2005-03-10 at 13:55 +0100, Knut J Bjuland wrote: caller is arch_add_exec_range+0x49/0x6a Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit When booting linux 2.6.11 with preemetable enable I get BUG: using smp_processor_id() in preemptible [0001] code: hotplug/461caller is arch_add_exec_range+0x49/0x6a when I load the kernel. I get this error messeage before loading xorg ,and the kernel is untained. that function isn't in kernel.org kernels... but only in the Exec Shield patch series.. sounds like you have a misapplied patch somewhere... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.x.y gatekeeper discipline
DHollenbeck wrote: Where do you see that patch as being applied in the new .y stable series? Chris I got that patch description from here: When you go to http://kernel.org, and click on the stand alone C to the right of 2.6.11.2 It is a hyperlink to: http://kernel.org/pub/linux/kernel/v2.6/testing/cset/ Have I mis-understood something, or is the website misleading? Or both :) The website is wrong. That URL points to Linus' tree. -- Brian Gerst - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.11.2 1/1] PCI Allow OutOfRange PIRQ table address
Hi Greg, PCI folk,
In our hardware situation, the BIOS is unable to store or generate it's PIRQ
table in the Fh-10h standard range. This patch adds a pci kernel
parameter, pirqaddr to allow the bootloader (or BIOS based loader) to inform
the kernel where the PIRQ table got stored. A beneficial side-effect is that,
if one's BIOS uses a static address each time for it's PIRQ table, then
pirqaddr can be used to avoid the $pirq search through that address block each
time at boot for normal PIRQ BIOSes.
Signed-off-by: Jaya Kumar [EMAIL PROTECTED]
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/pci/common.c
linux-2.6.11.2/arch/i386/pci/common.c
--- linux-2.6.11.2-vanilla/arch/i386/pci/common.c 2005-03-10
16:31:25.0 +0800
+++ linux-2.6.11.2/arch/i386/pci/common.c 2005-03-10 16:56:09.0
+0800
@@ -25,6 +25,7 @@ unsigned int pci_probe = PCI_PROBE_BIOS
int pci_routeirq;
int pcibios_last_bus = -1;
+unsigned int pirq_table_addr = 0;
struct pci_bus *pci_root_bus = NULL;
struct pci_raw_ops *raw_pci_ops;
@@ -188,6 +189,9 @@ char * __devinit pcibios_setup(char *st
} else if (!strcmp(str, biosirq)) {
pci_probe |= PCI_BIOS_IRQ_SCAN;
return NULL;
+ } else if (!strncmp(str, pirqaddr=, 9)) {
+ pirq_table_addr = simple_strtol(str+9, NULL, 0);
+ return NULL;
}
#endif
#ifdef CONFIG_PCI_DIRECT
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/pci/irq.c
linux-2.6.11.2/arch/i386/pci/irq.c
--- linux-2.6.11.2-vanilla/arch/i386/pci/irq.c 2005-03-10 16:31:25.0
+0800
+++ linux-2.6.11.2/arch/i386/pci/irq.c 2005-03-10 20:43:02.479487640 +0800
@@ -58,6 +58,35 @@ struct irq_router_handler {
int (*pcibios_enable_irq)(struct pci_dev *dev) = NULL;
/*
+ * Check passed address for the PCI IRQ Routing Table signature
+ * and perform checksum verification.
+ */
+
+static inline struct irq_routing_table * __init pirq_check_routing_table(u8
*addr)
+{
+ struct irq_routing_table *rt;
+ int i;
+ u8 sum;
+
+ rt = (struct irq_routing_table *) addr;
+ if (rt-signature != PIRQ_SIGNATURE ||
+ rt-version != PIRQ_VERSION ||
+ rt-size % 16 ||
+ rt-size sizeof(struct irq_routing_table))
+ return NULL;
+ sum = 0;
+ for(i=0; irt-size; i++)
+ sum += addr[i];
+ if (!sum) {
+ DBG(PCI: Interrupt Routing Table found at 0x%p\n, rt);
+ return rt;
+ }
+ return NULL;
+}
+
+
+
+/*
* Search 0xf -- 0xf for the PCI IRQ Routing Table.
*/
@@ -65,21 +94,16 @@ static struct irq_routing_table * __init
{
u8 *addr;
struct irq_routing_table *rt;
- int i;
- u8 sum;
+ if (pirq_table_addr) {
+ rt = pirq_check_routing_table((u8 *) __va(pirq_table_addr));
+ if (rt) {
+ return rt;
+ }
+ }
for(addr = (u8 *) __va(0xf); addr (u8 *) __va(0x10); addr +=
16) {
- rt = (struct irq_routing_table *) addr;
- if (rt-signature != PIRQ_SIGNATURE ||
- rt-version != PIRQ_VERSION ||
- rt-size % 16 ||
- rt-size sizeof(struct irq_routing_table))
- continue;
- sum = 0;
- for(i=0; irt-size; i++)
- sum += addr[i];
- if (!sum) {
- DBG(PCI: Interrupt Routing Table found at 0x%p\n, rt);
+ rt = pirq_check_routing_table(addr);
+ if (rt) {
return rt;
}
}
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/pci/pci.h
linux-2.6.11.2/arch/i386/pci/pci.h
--- linux-2.6.11.2-vanilla/arch/i386/pci/pci.h 2005-03-10 16:31:25.0
+0800
+++ linux-2.6.11.2/arch/i386/pci/pci.h 2005-03-10 16:52:09.0 +0800
@@ -27,6 +27,7 @@
#define PCI_ASSIGN_ALL_BUSSES 0x4000
extern unsigned int pci_probe;
+extern unsigned int pirq_table_addr;
/* pci-i386.c */
diff -uprN -X dontdiff
linux-2.6.11.2-vanilla/Documentation/kernel-parameters.txt
linux-2.6.11.2/Documentation/kernel-parameters.txt
--- linux-2.6.11.2-vanilla/Documentation/kernel-parameters.txt 2005-03-10
16:31:44.0 +0800
+++ linux-2.6.11.2/Documentation/kernel-parameters.txt 2005-03-10
16:45:48.0 +0800
@@ -967,6 +967,10 @@ running once the system is up.
irqmask=0x [IA-32] Set a bit mask of IRQs allowed
to be assigned
automatically to PCI devices. You can
make the kernel
exclude IRQs of your ISA cards this way.
+ pirqaddr=0xA[IA-32] Specify the physical address
+ of the PIRQ table (normally generated
+ by the BIOS)
Re: [PATCH 2.6.11.2 1/1] PCI Allow OutOfRange PIRQ table address
On Thu, Mar 10, 2005 at 05:29:35AM -0800, [EMAIL PROTECTED] wrote:
Nice work, I like it. You could make it even prettier:
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/pci/irq.c
linux-2.6.11.2/arch/i386/pci/irq.c
--- linux-2.6.11.2-vanilla/arch/i386/pci/irq.c2005-03-10
16:31:25.0 +0800
+++ linux-2.6.11.2/arch/i386/pci/irq.c2005-03-10 20:43:02.479487640
+0800
@@ -58,6 +58,35 @@ struct irq_router_handler {
int (*pcibios_enable_irq)(struct pci_dev *dev) = NULL;
/*
+ * Check passed address for the PCI IRQ Routing Table signature
+ * and perform checksum verification.
+ */
+
+static inline struct irq_routing_table * __init pirq_check_routing_table(u8
*addr)
+{
+ struct irq_routing_table *rt;
+ int i;
+ u8 sum;
+
+ rt = (struct irq_routing_table *) addr;
static inline struct irq_routing_table * __init
pirq_check_routing_table(unsigned long phys)
{
struct irq_routing_table *rt = __va(phys);
[...]
@@ -65,21 +94,16 @@ static struct irq_routing_table * __init
{
u8 *addr;
unsigned long addr;
struct irq_routing_table *rt;
- int i;
- u8 sum;
+ if (pirq_table_addr) {
+ rt = pirq_check_routing_table((u8 *) __va(pirq_table_addr));
+ if (rt) {
+ return rt;
+ }
+ }
if (pirq_table_addr) {
rt = pirq_check_routing_table(pirq_table_addr);
if (rt)
return rt;
}
Should we fall back to searching if someone's specified an address? If not,
it becomes even simpler:
if (pirq_table_addr) {
return pirq_check_routing_table(pirq_table_addr);
}
for(addr = (u8 *) __va(0xf); addr (u8 *) __va(0x10); addr +=
16) {
This loop would become:
for (addr = 0xf; addr 0x10; addr += 16) {
@@ -27,6 +27,7 @@
#define PCI_ASSIGN_ALL_BUSSES0x4000
extern unsigned int pci_probe;
+extern unsigned int pirq_table_addr;
Completely nitpicking, but I think this should be an unsigned long rather
than an int -- physical addresses are normally expressed in terms of
unsigned long.
+ pirqaddr=0xA[IA-32] Specify the physical address
+ of the PIRQ table (normally generated
+ by the BIOS) if it is outside the .
+ Fh-10h range.
And you even bothered to update the documentation! This is definitely
a cut above most of the patches I review ;-)
--
Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception. -- Mark Twain
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 series] ia64 specific /dev/mem handlers
Andrew == Andrew Morton [EMAIL PROTECTED] writes: Andrew Jes Sorensen [EMAIL PROTECTED] wrote: Convert /dev/mem read/write calls to use arch_translate_mem_ptr if available. Needed on ia64 for pages converted fo uncached mappings to avoid it being accessed in cached mode after the conversion which can lead to memory corruption. Introduces PG_uncached page flag for marking pages uncached. Andrew For some reason this patch still gives me the creeps. Maybe Andrew it's because we lose a page flag for something so obscure. Andrew Nothing ever clears PG_uncached. We'll end up with every page Andrew in the machine marked as being uncached. Actually there's restrictions to how many pages are getting converted as converting pages over from cached to uncached isn't trivial on ia64. Andrew But then, nothing ever sets PG_uncached, either. Is there Andrew some patch which you're hiding from me? Actually I posted that earlier, but it must have gotten lost in the noise. It's part of the genalloc/mspec patchset. I'll send it to you directly. Andrew If a page is marked uncached then it'll remain marked as Andrew uncached even after it's unmapped. Or will it? Would like to Andrew see the other patch, please. Coming your way in a jiffy. Andrew We should add PG_uncached checks to the page allocator. Is Andrew this OK? I don't see any problems with that. The way it's meant to be used is that once pages are converted over, they don't go back into the allocator. Cheers, Jes - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Hi! The fact that not a script, but Linus Torvalds, decides that the tree is in a state he likes to share with others. You have been doing -pre's all this time, it's just that you are calling them -rc's. No. I used to do -pre, a long time ago. Exactly because they were synchronization points for developers. These days, that's pointless. We keep the tree in pretty good working order (certainly as good as my -pre's ever were) constantly, and developers who need to can synchronize with either the BK tree or the nightly snapshots. The fact is, 99% of the developers don't even need to Actually, sync to -pre is easier than sync to -bk snapshot: * you get incremental patches from kernel.org * there's reasonable number of pre-s so that you can be up-to-date without syncing each day Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dm-crypt vs. cryptoloop reminder
Hi! 2.6.3-mm1 'dm-crypt vs. cryptoloop' discussion was some time ago, it is time to bring this up again: http://kerneltrap.org/node/2433 Are you a troll? This is not something to be quoted by anybody serious. Andrew referred to well-known weaknesses in cryptoloop, and when I inquired it turned out that what he referred to were properties of cryptoloop and dm-crypt alike, so that his remarks that started that discussion were misguided. Of course people may prefer dm-crypt or cryptoloop or loop-aes, just like people prefer ide-cd or ide-scsi. I have not yet seen a valid reason to deprecate one of these three very soon. I'd say that no-maintainer + maintained code can do the same is enough, but... I thought that ide-scsi was deprecated, too? -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce 7/7] fbsplash - documentation
Hi! +The userspace helper + + +The userspace splash helper (by default: /sbin/splash_helper) is called by the +kernel whenever an important event occurs and the kernel needs some kind of +job to be carried out. Important events include console switches and graphic +mode switches (the kernel requests background images and configuration +parameters for the current console). The splash helper must be accessible at +all times. If it's not, fbsplash will be switched off automatically. Ugh, is not calling userspace when switching consoles deadlock-prone? What if that helper tries to do printf()? -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bk commits and dates
On Thu, 2005-03-10 at 01:13 -0500, Jeff Garzik wrote: Speaking strictly in terms of implementation, David Woodhouse's bk-commits mailer scripts could probably easily be tweaked to -not- set an explicit Date header on the outgoing emails. It then becomes a matter of deciding whether this is a good idea or not :) The original changeset date is also in the body of the mail anyway so it wouldn't be lost if we changed this. I have no real preference either way. Bear in mind that the Date: header you got would then be the time my script ran, not the time it was actually committed. That may differ by days, in some cases (thankfully not often). -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb-priority in case forwarded frame has VLAN-header]
From looking at the patch: j -- j + /* j +* We map VLAN_TCI priority (0..7) to skb-priority (0..15) j +* most similarly e.g. 0-0, 1-1, .., 7-7 j +*/ j + skb-priority = (vlan_TCI 13) 7; j -- j This is wrong. IEEE priorities are opposite of IETF priorities (as used by skb-prio). j Unless you install a prio qdisc and rewrite the priomap, you are screwed. j So you should do opposite mapping, i.e something along the lines of j VLAN_TCI priority (0..7) to skb-priority (15..8) i,e skb-priority = 15 - vlan_TCI; j cheers, j jamal Jamal, you are wrong! 802.1p defines priority as linear from 0 to 7, the 0 is lowest priority and 7 is highest. couple FoC links: http://www.linktionary.com/q/qos.html http://www.nwfusion.com/details/475.html -- , Leo mailto:[EMAIL PROTECTED] -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6 mQCPA0HMImkBbQEEALnWXpnchl1dHaCfwnXe2RO8ft9e7K5IGRW1lE9RERMy6R3L JnMXMPiuWm/4tx6H/yTRUML8LbuACzf2Np9oHTxbDWxP40wGxQKrPDlzv/9gLEp6 ZwGF8mSfvZrPHux1LwIbryQxjlmwfNCkE+qiVOBWMsD7yAFCWrZztbWTWJ6pABEB AAG0GkxlbyBZdXJpZXYgPGxlb0B5dXJpZXYucnU+iQCVAwUQQcwiabZztbWTWJ6p AQG6cAP9H0O+MMa0WDlGE2JGG+SWuu9Iuqg76Hp6tjtrz2pLWEzbq8oqCkE0THff /YUUaKqnrLELwEaptE+MrWSv9Zt1K/PauMpKUWXhlYqGcGB2NqJL69AONQte0M4B rPSSts4CU7gK2Zuds1DOLiON7e9Sbpjc5T+4D7Jw5XGKMz66nhY= =qGIk -END PGP PUBLIC KEY BLOCK- pgpzpcS7E3wfw.pgp Description: PGP signature
[patch 1/1] /proc/$$/ipaddr and per-task networking bits
Ported feature from grSecurity that makes possible to add an ipaddr
entry in each /proc/pid (/proc/pid/ipaddr), where the task originating
IP address is stored, and subsequently made available (readable) by the process
itself and also the root user with CAP_DAC_OVERRIDE capability (that can be
managed
by specific security models implementations like SELinux).
Available also at http://pearls.tuxedo-es.org/patches/task-curr_ip.patch
Signed-off-by: Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED]
---
linux-2.6.11-lorenzo/fs/Kconfig| 16 ++
linux-2.6.11-lorenzo/fs/proc/array.c | 10 +
linux-2.6.11-lorenzo/fs/proc/base.c| 12 ++
linux-2.6.11-lorenzo/fs/proc/internal.h|3
linux-2.6.11-lorenzo/include/linux/sched.h |8 +
linux-2.6.11-lorenzo/kernel/exit.c |8 +
linux-2.6.11-lorenzo/net/Makefile |4
linux-2.6.11-lorenzo/net/ipv4/tcp_ipv4.c | 14 ++
linux-2.6.11-lorenzo/net/proc_ipaddr.c | 166 +
linux-2.6.11-lorenzo/net/socket.c |2
10 files changed, 243 insertions(+)
diff -puN fs/proc/base.c~task-curr_ip fs/proc/base.c
--- linux-2.6.11/fs/proc/base.c~task-curr_ip2005-03-10 14:56:13.931854168
+0100
+++ linux-2.6.11-lorenzo/fs/proc/base.c 2005-03-10 14:56:14.048836384 +0100
@@ -74,6 +74,9 @@ enum pid_directory_inos {
#ifdef CONFIG_AUDITSYSCALL
PROC_TGID_LOGINUID,
#endif
+#ifdef CONFIG_PROC_IPADDR
+ PROC_TGID_IPADDR,
+#endif
PROC_TGID_FD_DIR,
PROC_TGID_OOM_SCORE,
PROC_TGID_OOM_ADJUST,
@@ -134,6 +137,9 @@ static struct pid_entry tgid_base_stuff[
E(PROC_TGID_ROOT, root,S_IFLNK|S_IRWXUGO),
E(PROC_TGID_EXE, exe, S_IFLNK|S_IRWXUGO),
E(PROC_TGID_MOUNTS,mounts, S_IFREG|S_IRUGO),
+#ifdef CONFIG_PROC_IPADDR
+ E(PROC_TGID_IPADDR, ipaddr, S_IFREG|S_IRUSR),
+#endif
#ifdef CONFIG_SECURITY
E(PROC_TGID_ATTR, attr,S_IFDIR|S_IRUGO|S_IXUGO),
#endif
@@ -1416,6 +1422,12 @@ static struct dentry *proc_pident_lookup
inode-i_fop = proc_info_file_operations;
ei-op.proc_read = proc_pid_status;
break;
+#ifdef CONFIG_PROC_IPADDR
+ case PROC_TGID_IPADDR:
+ inode-i_fop = proc_info_file_operations;
+ ei-op.proc_read = proc_pid_ipaddr;
+ break;
+#endif
case PROC_TID_STAT:
inode-i_fop = proc_info_file_operations;
ei-op.proc_read = proc_tid_stat;
diff -puN fs/proc/internal.h~task-curr_ip fs/proc/internal.h
--- linux-2.6.11/fs/proc/internal.h~task-curr_ip2005-03-10
14:56:13.932854016 +0100
+++ linux-2.6.11-lorenzo/fs/proc/internal.h 2005-03-10 14:56:14.048836384
+0100
@@ -36,6 +36,9 @@ extern int proc_tid_stat(struct task_str
extern int proc_tgid_stat(struct task_struct *, char *);
extern int proc_pid_status(struct task_struct *, char *);
extern int proc_pid_statm(struct task_struct *, char *);
+#ifdef CONFIG_PROC_IPADDR
+extern int proc_pid_ipaddr(struct task_struct*,char*);
+#endif
static inline struct task_struct *proc_task(struct inode *inode)
{
diff -puN fs/proc/array.c~task-curr_ip fs/proc/array.c
--- linux-2.6.11/fs/proc/array.c~task-curr_ip 2005-03-10 14:56:13.934853712
+0100
+++ linux-2.6.11-lorenzo/fs/proc/array.c2005-03-10 14:56:14.048836384
+0100
@@ -473,3 +473,13 @@ int proc_pid_statm(struct task_struct *t
return sprintf(buffer,%d %d %d %d %d %d %d\n,
size, resident, shared, text, lib, data, 0);
}
+
+#ifdef CONFIG_PROC_IPADDR
+int proc_pid_ipaddr(struct task_struct *task, char * buffer)
+{
+ int len;
+
+ len = sprintf(buffer, %u.%u.%u.%u\n, NIPQUAD(task-curr_ip));
+ return len;
+}
+#endif
diff -puN fs/Kconfig~task-curr_ip fs/Kconfig
--- linux-2.6.11/fs/Kconfig~task-curr_ip2005-03-10 14:56:13.936853408
+0100
+++ linux-2.6.11-lorenzo/fs/Kconfig 2005-03-10 14:56:14.049836232 +0100
@@ -716,6 +716,22 @@ config PROC_FS
config PROC_KCORE
bool /proc/kcore support if !ARM
depends on PROC_FS MMU
+
+config PROC_IPADDR
+ bool /proc/pid/ipaddr support
+ depends on PROC_FS NET INET
+ help
+ If you say Y here, a new entry will be added to each /proc/pid
+ directory that contains the IP address of the person using the task.
+ The IP is carried across local TCP and AF_UNIX stream sockets.
+ This information can be useful for IDS/IPSes to perform remote
response
+ to a local attack. The entry is readable by only the owner of the
+ process (and root if he has CAP_DAC_OVERRIDE, which can be handled in
+ different manners depending on the used model, ie. RBAC and the engine
+ implementing it, ie. SELinux), and thus does not create privacy
concerns.
+
+ This feature has been
Re: [patch 1/1] /proc/$$/ipaddr and per-task networking bits
On Thu, 2005-03-10 at 15:16 +0100, Lorenzo Hernndez Garca-Hierro wrote: Ported feature from grSecurity that makes possible to add an ipaddr entry in each /proc/pid (/proc/pid/ipaddr), where the task originating IP address is stored, and subsequently made available (readable) by the process itself and also the root user with CAP_DAC_OVERRIDE capability (that can be managed by specific security models implementations like SELinux). Available also at http://pearls.tuxedo-es.org/patches/task-curr_ip.patch a few questions 1) Why is this a config option; if it's useful it should just be always on really 2) Can you explain briefly what this is useful for? 3) How does this work for existing stuff if, say, your dhcp lease changes and your machine no longer owns a certain IP, what will happen to the tasks? 4) if a machine has multiple IPs.. which one is chosen ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 Mon, 7 Mar 2005, Dave Hansen wrote: On Mon, 2005-03-07 at 19:39 +, Mel Gorman wrote: The placement policy patch should now be more Hotplug-friendly and I would like to hear from the Hotplug people if they have more requirements of this patch. It looks like most of what we need is there already. There are two things that come to mind. We'll likely need some modifications that will deal with committing memory areas that are larger than MAX_ORDER to the different allocation pools. That's because a hotplug area (memory section) might be larger than a single MAX_ORDER area, and each section may need to be limited to a single allocation type. As you say later, stuff like that can be easily grafted on by fiddling with the bitmap, just with more than one block of MAX_ORDER pages. The other thing is that we'll probably have to be a lot more strict about how the allocations fall back. Some users will probably prefer to kill an application rather than let a kernel allocation fall back into a user memory area. That will be a tad trickier because we'll need a way of specifying a fallback policy at configure time. However, the fallback policy is currently isolated within one while loop, having different fallback policies is doable. The kicker is that that there might be nasty interaction with the page reclaim code where the allocator is not falling back due to policy but the reclaim code things everything is just fine. BTW, I wrote some requirements about how these section divisions might be dealt with. Note that this is a completely hotplug-centric view of the whole problem, I didn't discern between reclaimable and unreclaimable kernel memory as your patch does. This is probably wy more than you wanted to hear, but I thought I'd share anyway. :) No, better to hear about it now so I have something to chew over :) There are 2 kinds of sections: user and kernel. The traditional ZONE_HIGHMEM is full of user sections (except for vmalloc). And PTEs if configured to be allocated from high memory. I have not double checked but I don't think they can be trivially reclaimed. Any section which has slab pages or any kernel caller to alloc_pages() is a kernel section. Slab pages could be moved to the user section as long as the cache owner was able to reclaim the slabs on demand. Some properties of these sections: a. User sections are easily removed. b. Kernel sections are hard to remove. (considered impossible) c. User sections may *NOT* be used for kernel pages if all user sections are full. (but, see f.) d. Kernel sections may be used for user pages if all user sections are full. e. A transition from a kernel section to a user section is hard, and requires that it be empty of all kernel users. f. A transition from a user section to a kernel section is easy. (although easy, this should be avoided because it's hard to turn it _back_ into a user section) All of these requirements are similar (just not as strict) as those for fragmentation so common ground should continue to exist. -- Mel Gorman Part-time Phd Student Java Applications Developer University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Reduce cacheline bouncing in cpu_idle_wait
On Thu, 10 Mar 2005, Andi Kleen wrote:
Zwane Mwaikambo [EMAIL PROTECTED] writes:
Andi noted that during normal runtime cpu_idle_map is bounced around a
lot, and occassionally at a higher frequency than the timer interrupt
wakeup which we normally exit pm_idle from. So switch to a percpu
variable. Andi i didn't move things to the slow path because it would
involve adding scheduler code to wakeup the idle thread on the cpus we're
waiting for.
Thanks.
-
void cpu_idle_wait(void)
{
-int cpu;
-cpumask_t map;
+ unsigned int cpu, this_cpu = get_cpu();
+ cpumask_t map;
+
+ set_cpus_allowed(current, cpumask_of_cpu(this_cpu));
+ put_cpu();
You need a cpus_clear(map); here I think (probably same for the other
archs)
A bit subtle, the cpus_and will clear the offline processors after the
first pass.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ITE8212
On Iau, 2005-03-10 at 12:28, CaT wrote:
hda: max request size: 128KiB
hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG
hda: cache flushes not supported
hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
hda: recal_intr: error=0x04 { DriveStatusError }
Ooh great stuff, definitely want to know more. A couple of folks report
that and mine won't do it.
/dev/hdc:
Model=IC35L060AVV207-0, FwRev=V22OA63A, SerialNo=VNVB01G2RAK8XH
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
BuffType=DualPortCache, BuffSize=1821kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=120103200
IORDY=on/off
PIO modes: pio0 pio1 pio2
DMA modes: mdma0 mdma1 mdma2
Ok its correctly trimmed the modes, but not it seems the current mode.
I'll send you a tweak to avoid multisect being played with.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: current linus bk, error mounting root
LABEL=/ / ext3defaults1 1 label / is on /dev/sda6 Creating root device Mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root Switchroot: mount failed 22 umount /initrd/dev failed: 2 This is what is left on the screen when the boot fails. There is a another line about failed to mount root machine halted. I am still broken with using the Linus bk tree as of when I wrote this mail. That should be all of bk6 plus anything that came in this morning. On Thu, 10 Mar 2005 08:50:53 +0100, Jens Axboe [EMAIL PROTECTED] wrote: On Wed, Mar 09 2005, Jon Smirl wrote: On Wed, 9 Mar 2005 22:09:26 +0100, Jens Axboe [EMAIL PROTECTED] wrote: probably not worth the bother, looks like barrier problems. get the serial console running instead and send the full output, I'll take a look in the morning. serial console boot output attached. Hmm ok, nothing of interest there. What does the mount error 6 and 2 from your original mail mean? I need some more info on what fails specifically. What mount options are used? What partition is mounted (is it md or hdaX)? I'm not sure -bk5 had the follow up fix patch for the barrier rework, you should probably just retry with -bk6 first. -- Jens Axboe -- Jon Smirl [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: Linux 2.6.11-ac1
On Iau, 2005-03-10 at 09:06, Tupshin Harper wrote: Alan...since you disagreed with the earlier characterization of what it would take to get into the mainline kernels, could you let us know what it would take in your opinion? FWIW, I'm happily using it with a -ac kernel. It needs some small changes in the base ide-disk code to handle drives having only a logical geometry (legal but Linux can't cope). Most if not all the other hooks are there to an extent the driver for the it821x can work without core code changes. It might be cleaner with core changes but it's better that the it821x code handles the weirdness of the hardware. Longer term it (and probably every other IDE PATA driver) should be moved to the Jeff Garzik SATA layer. That's also Bart's position I believe ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] SELinux AVC audit log ipaddr field support (for task_struct-curr_ip)
Provides support for a new field ipaddr within the SELinux
AVC audit log, relying in task_struct-curr_ip (ipv4 only)
provided by the task-curr_ip or grSecurity patch to be applied
before.It was first implemented by Joshua Brindle (a.k.a Method)
from the Hardened Gentoo project.
An example of the audit messages with ipaddr field:
audit(1110432234.161:0): avc: denied { search } for pid=19057
exe=/usr/bin/wget name=portage dev=hda3 ino=1024647 ipaddr=192.168.1.30
scontext=root:sysadm_r:portage_fetch_t tcontext=system_u:object_r:portage_tmp_t
tclass=dir
It's also available at
http://pearls.tuxedo-es.org/patches/selinux-avc_audit-log-curr_ip.patch
Signed-off-by: Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED]
---
linux-2.6.11-lorenzo/security/selinux/avc.c |6 ++
1 files changed, 6 insertions(+)
diff -puN security/selinux/avc.c~selinux-avc_audit-log-curr_ip
security/selinux/avc.c
--- linux-2.6.11/security/selinux/avc.c~selinux-avc_audit-log-curr_ip
2005-03-10 15:52:12.810227040 +0100
+++ linux-2.6.11-lorenzo/security/selinux/avc.c 2005-03-10 15:52:12.817225976
+0100
@@ -205,6 +205,12 @@ void avc_dump_query(struct audit_buffer
char *scontext;
u32 scontext_len;
+/* CONFIG_GRKERNSEC_PROC_IPADDR if grSecurity is present */
+#ifdef CONFIG_PROC_IPADDR
+ if (current-curr_ip)
+ audit_log_format(ab, ipaddr=%u.%u.%u.%u ,
NIPQUAD(current-curr_ip));
+#endif /* CONFIG_PROC_IPADDR */
+
rc = security_sid_to_context(ssid, scontext, scontext_len);
if (rc)
audit_log_format(ab, ssid=%d, ssid);
_
Cheers,
--
Lorenzo Hernández GarcÃa-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: This is a digitally signed message part
Re: oom with 2.6.11
ok, as promised, it the OOM happened again with the same plain 2.6.11, details here. http://nerdbynature.de/bits/sheep/2.6.11/oom/oom_2.6.11_2.txt the following is a quite long, but please read on (if anyone is reading at all :)) this time it happened at 08:01, and i could image some heavy cron jobs were going on. but as i said: it did not happen before. there are also output of SYSRQ-T/M/P. i did SYSRQ-E to recover the machine, but then decided to reboot back to 2.6.11-rc5-bk2. i had a look at the changelogs too and noticed that ChangeLog-2.6.11 contains 7 occurrences of OOM in the patch desctiption: [PATCH] mm: overcommit updates, 2005-01-03 [PATCH] vmscan: count writeback pages in nr_scanned, 2005-01-08 [PATCH] possible rq starvation on oom, 2005-01-13 [PATCH] mm: adjust dirty threshold for lowmem-only mappings, 2005-01-25 [PATCH] mm: oom-killer tunable, 2005-02-02 [PATCH] mm: fix several oom killer bugs, 2005-02-02 [PATCH] Fix oops in alloc_zeroed_user_highpage() when [...],2005-02-09 release dates: 2.6.11-rc5-bk1 26-Feb-2005 2.6.11-rc5-bk2 27-Feb-2005 2.6.11-rc5-bk3 28-Feb-2005 2.6.11-rc5-bk4 01-Mar-2005 2.6.11 02-Mar-2005 so i really don't see any patches that *could* have something to do with the issue here. now comes the weird part: i was going to compile 2.6.11-rc5-bk4, to sort out the bad kernel. compiling went fine. ok, finished some email, ok, suddenly my swap was used up again, and no memory left - uh oh! OOM again, with 2.6.11-rc5-bk2! to summarize it: i've run 2.6.11-rc2-bk10 during whole february, then switched to 2.6.11-rc5-bk2 on 28.02.2005, then to 2.6.11 on 05.03.2005 - and only noticed with 2.6.11 first, now with 2.6.11-rc5-bk2 too. there is an interesting part in the logfiles: http://nerdbynature.de/bits/sheep/2.6.11/oom/oom_2.6.11.txt http://nerdbynature.de/bits/sheep/2.6.11/oom/oom_2.6.11_2.txt http://nerdbynature.de/bits/sheep/2.6.11/oom/oom_2.6.11-rc5-bk2.txt every last message before the OOM messages is something with pppd: Mar 10 13:45:55 sheep pppd[1567]: Starting link Mar 10 14:12:29 sheep kernel: oom-killer: gfp_mask=0x1d2 Mar 8 00:59:58 sheep pppd[418]: Starting link Mar 8 01:27:33 sheep kernel: oom-killer: gfp_mask=0xd0 Mar 9 07:33:49 sheep pppd[30937]: Starting link Mar 9 08:01:35 sheep kernel: oom-killer: gfp_mask=0x1d2 and 30min later OOM kicks in. normally, pppd (pppoe) gives messages like this: Mar 10 14:23:38 sheep pppd[26365]: Starting link Mar 10 14:23:38 sheep pppd[26365]: Serial connection established. Mar 10 14:23:38 sheep pppd[26365]: Connect: ppp0 -- /dev/pts/0 Mar 10 14:23:38 sheep pppoe[26383]: PADS: Service-Name: '' Mar 10 14:23:38 sheep pppoe[26383]: PPP session is 6804 Mar 10 14:23:39 sheep pppd[26365]: CHAP authentication succeeded Mar 10 14:23:40 sheep pppd[26365]: Local IP address changed to [...] is this strange? or not? i hope someone has a hint for me, because going back to the stable kernel would mean being bound to 2.6.11-rc2-bk10 :( thank you for any hints, Christian. PS: Steven, i've cc'ed you because you have trouble with new 2.6.11 kernels and pppd too. maybe unrelated, maybe not. -- BOFH excuse #185: system consumed all the paper for paging - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] 2.6.11- sym53c8xx Broken on pp64
On Thu, 2005-03-10 at 12:17 +, Matthew Wilcox wrote: Heh, the devel version of sym2 (that isn't submitted yet because it depends on a few changes to the SPI transport that James hasn't integrated yet) would probably fix this as it doesn't call iounmap() until the driver exits. They're integrated into the scsi-misc-2.6 tree, so if you send in the sym2 patch to linux-scsi, everything should still work... James - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] /proc/$$/ipaddr and per-task networking bits
In article [EMAIL PROTECTED] (at Thu, 10 Mar 2005 15:16:42 +0100), Lorenzo Hernández GarcÃa-Hierro [EMAIL PROTECTED] says: Ported feature from grSecurity that makes possible to add an ipaddr entry in each /proc/pid (/proc/pid/ipaddr), where the task originating IP address is stored, and subsequently made available (readable) by the process itself and also the root user with CAP_DAC_OVERRIDE capability (that can be managed by specific security models implementations like SELinux). Available also at http://pearls.tuxedo-es.org/patches/task-curr_ip.patch Please don't. You already can get this information via procfs; e.g. lsof does, It does support IPv6 as well. --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: [patch 1/1] SELinux AVC audit log ipaddr field support (for task_struct-curr_ip)
On Thu, 2005-03-10 at 16:05 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
Provides support for a new field ipaddr within the SELinux
AVC audit log, relying in task_struct-curr_ip (ipv4 only)
provided by the task-curr_ip or grSecurity patch to be applied
before.It was first implemented by Joshua Brindle (a.k.a Method)
from the Hardened Gentoo project.
An example of the audit messages with ipaddr field:
audit(1110432234.161:0): avc: denied { search } for pid=19057
exe=/usr/bin/wget name=portage dev=hda3 ino=1024647 ipaddr=192.168.1.30
scontext=root:sysadm_r:portage_fetch_t
tcontext=system_u:object_r:portage_tmp_t tclass=dir
Even if the basic idea were sound (doubtful), this would need to be
generalized (i.e. not ipv4-specific). Also, I think I'd rather see
extensions to the audit data be incorporated into the audit framework,
not the AVC-specific audit code, and some of the existing avc_audit()
code migrated into the audit framework (e.g. the exe= information
currently generated by avc_audit could be done by audit_log_exit
instead).
--
Stephen Smalley [EMAIL PROTECTED]
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] /proc/$$/ipaddr and per-task networking bits
El jue, 10-03-2005 a las 15:26 +0100, Arjan van de Ven escribió: a few questions 1) Why is this a config option; if it's useful it should just be always on really Just to be removed if it applies for mainline. 2) Can you explain briefly what this is useful for? For keeping track on the originating ip address of the task/process (the ipv4 address of the user that started the task/process). It adds an ipaddr entry if available for each /proc/pid entry, among the API changes. Example: [EMAIL PROTECTED]:/usr/src# cat /proc/5907/ipaddr 192.128.102.93 3) How does this work for existing stuff if, say, your dhcp lease changes and your machine no longer owns a certain IP, what will happen to the tasks? 4) if a machine has multiple IPs.. which one is chosen ? The patch has nothing to do with this, as it's objective is different. See http://lkml.org/lkml/2005/3/10/108 and http://pearls.tuxedo-es.org/patches/selinux-avc_audit-log-curr_ip.patch if you want useful and real examples on how it works and helps. Cheers, -- Lorenzo Hernández GarcÃa-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [patch 1/1] SELinux AVC audit log ipaddr field support (for task_struct-curr_ip)
On Thursday 10 March 2005 10:16, Stephen Smalley wrote: (e.g. the exe= information currently generated by avc_audit could be done by audit_log_exit instead). I already have a patch that does that. It tells you what program is being run instead of /bin/bash. I'll send it in a day or two for everyone to look over. -Steve Grubb - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] OSS gameport fixes
On Wed, 9 Mar 2005 12:32:17 +0100, Adrian Bunk [EMAIL PROTECTED] wrote: This patch adds dummy gameport_register_port, gameport_unregister_port and gameport_set_phys functions to gameport.h for the case when a driver can't use gameport. This fixes the compilation of some OSS drivers with GAMEPORT=n without the need to #if inside every single driver. This patch also removes the non-working and now obsolete SOUND_GAMEPORT. This patch is also an alternative solution for ALSA drivers with similar problems (but #if's inside the drivers might have the advantage of saving some more bytes of gameport is not available). The only user-visible change is that for GAMEPORT=m the affected OSS drivers are now allowed to be built statically (but they won't have gameport support). Hi Adrian, I have somewhat mixed feeling about the patch. Some solutions is definitely needed but I don't like allocating memory that will never be used. I think I would perfer #ifdefing gameport support is OSS modules, _if_ #ifdefs are out of line and not in the middle of code path. I'll let Vojtech decide which way he wants to go - he could probably apply the patch and then we could convert drivers one by one and kill the stubs later. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: current linus bk, error mounting root
On Thu, Mar 10 2005, Jon Smirl wrote: LABEL=/ / ext3defaults1 1 label / is on /dev/sda6 Creating root device Mounting root filesystem mount: error 6 mounting ext3 if 6 is the errno, it looks like it is trying to open a device that does not exist (ENXIO). Can you up the verbosity of those commands, I'd like to see what it is doing exactly. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
minor 2.6.11-bk6 config issue or user error
Hi, I went from bk4 to bk6. After patching i just typed make to recompile (as I thought this would be enough). But it errored out because CONFIG_BASE_SMALL wasn't defined. So I did make menuconfig and saved my config again and now it compiles through. Is it needed to run make oldconfig or make menuconfig and save before kernel upgrade? I thought make oldconfig is run automatically on make? -- Prakash Punnoor formerly known as Prakash K. Cheemplavam signature.asc Description: OpenPGP digital signature
Re: [patch 1/1] /proc/$$/ipaddr and per-task networking bits
On Thu, 2005-03-10 at 16:28 +0100, Lorenzo Hernndez Garca-Hierro wrote: 2) Can you explain briefly what this is useful for? For keeping track on the originating ip address of the task/process (the ipv4 address of the user that started the task/process). but tasks don't have an IP address. Hosts do. Hosts can have multiple IP addresses. Both ipv4 and ipv6. Users don't have IP addresses either (they do have user IDs so that link is clear). I think I'm missing something big here. What does it *mean* for a task to have an IP address. Once that is clear maybe I can start to understand the rest, but until the meaning of task has an IP address is better explained/more clear I think I'm stuck. (and no the output in a log isn't a meaning, it's only a result) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: current linus bk, error mounting root
On Thu, 10 Mar 2005 16:31:51 +0100, Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Mar 10 2005, Jon Smirl wrote: LABEL=/ / ext3defaults1 1 label / is on /dev/sda6 Creating root device Mounting root filesystem mount: error 6 mounting ext3 if 6 is the errno, it looks like it is trying to open a device that does not exist (ENXIO). Can you up the verbosity of those commands, I'd like to see what it is doing exactly. Jeff, how can I up the verbosity? This is on Fedora Core 3 but before user space is up. Is there some way to tell the boot ramdisk to display more info? -- Jens Axboe -- Jon Smirl [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: current linus bk, error mounting root
On Thu, Mar 10 2005, Jon Smirl wrote: On Thu, 10 Mar 2005 16:31:51 +0100, Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Mar 10 2005, Jon Smirl wrote: LABEL=/ / ext3defaults1 1 label / is on /dev/sda6 Creating root device Mounting root filesystem mount: error 6 mounting ext3 if 6 is the errno, it looks like it is trying to open a device that does not exist (ENXIO). Can you up the verbosity of those commands, I'd like to see what it is doing exactly. Jeff, how can I up the verbosity? This is on Fedora Core 3 but before user space is up. Is there some way to tell the boot ramdisk to display more info? Perhaps you can mount the initrd and change the script to echo the commands before executing them? Then boot with the modified initrd. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] OSS gameport fixes
On Thu, Mar 10, 2005 at 10:36:57AM -0500, Dmitry Torokhov wrote: On Wed, 9 Mar 2005 12:32:17 +0100, Adrian Bunk [EMAIL PROTECTED] wrote: This patch adds dummy gameport_register_port, gameport_unregister_port and gameport_set_phys functions to gameport.h for the case when a driver can't use gameport. This fixes the compilation of some OSS drivers with GAMEPORT=n without the need to #if inside every single driver. This patch also removes the non-working and now obsolete SOUND_GAMEPORT. This patch is also an alternative solution for ALSA drivers with similar problems (but #if's inside the drivers might have the advantage of saving some more bytes of gameport is not available). The only user-visible change is that for GAMEPORT=m the affected OSS drivers are now allowed to be built statically (but they won't have gameport support). Hi Adrian, I have somewhat mixed feeling about the patch. Some solutions is definitely needed but I don't like allocating memory that will never be used. I think I would perfer #ifdefing gameport support is OSS modules, _if_ #ifdefs are out of line and not in the middle of code path. I'll let Vojtech decide which way he wants to go - he could probably apply the patch and then we could convert drivers one by one and kill the stubs later. OK, I'll add it, since it fixes immediate breakage. I'll also accept patches that #ifdef-out the relevant parts of sound drivers if gameport support is not present. -- 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: current linus bk, error mounting root
Here's what it is doing... looks like the first mount is failing echo Creating root device mkrootdev /dev/root umount /sys echo Mounting root filesystem mount -o defaults --ro -t ext3 /dev/root /sysroot mount -t tmpfs --bind /dev /sysroot/dev echo Switching to new root switchroot /sysroot umount /initrd/dev On Thu, 10 Mar 2005 16:48:31 +0100, Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Mar 10 2005, Jon Smirl wrote: On Thu, 10 Mar 2005 16:31:51 +0100, Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Mar 10 2005, Jon Smirl wrote: LABEL=/ / ext3defaults 1 1 label / is on /dev/sda6 Creating root device Mounting root filesystem mount: error 6 mounting ext3 if 6 is the errno, it looks like it is trying to open a device that does not exist (ENXIO). Can you up the verbosity of those commands, I'd like to see what it is doing exactly. Jeff, how can I up the verbosity? This is on Fedora Core 3 but before user space is up. Is there some way to tell the boot ramdisk to display more info? Perhaps you can mount the initrd and change the script to echo the commands before executing them? Then boot with the modified initrd. -- Jens Axboe -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] /proc/$$/ipaddr and per-task networking bits
El jue, 10-03-2005 a las 16:38 +0100, Arjan van de Ven escribió: but tasks don't have an IP address. Hosts do. Hosts can have multiple IP addresses. Both ipv4 and ipv6. Users don't have IP addresses either (they do have user IDs so that link is clear). I think I'm missing something big here. What does it *mean* for a task to have an IP address. Once that is clear maybe I can start to understand the rest, but until the meaning of task has an IP address is better explained/more clear I think I'm stuck. (and no the output in a log isn't a meaning, it's only a result) I think I've explained it well, more concretely, it tries to fill the ipaddr member of the task_struct structure with the IP address associated to the user running @current task/process,if available. Then, it will be attached within the proc fs in an entry called ipaddr, under the proper pid directory. The whole thing is almost self-explaining by just looking at the code. Cheers, -- Lorenzo Hernández GarcÃa-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: current linus bk, error mounting root
On Thu, Mar 10 2005, Jon Smirl wrote: Here's what it is doing... looks like the first mount is failing echo Creating root device mkrootdev /dev/root umount /sys echo Mounting root filesystem mount -o defaults --ro -t ext3 /dev/root /sysroot mount -t tmpfs --bind /dev /sysroot/dev echo Switching to new root switchroot /sysroot umount /initrd/dev what are the major/minor numbers of /dev/root? -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bk commits and dates
On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote: Now, if James trigger scripts set the date of the email by the date of the commit, that sounds like a misfeature, but you'd better talk to James, not me, since he's the one doing that part.. Hah ok. Which James ? I was thinking about Bottomley, but Jeff points out that it's not James who does it, but David Woodhouse. I'm a retard. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Compile into static and dynamic problem
Hai all, I recompiled kernel and copied to Compact Flash and also copy the library file from the samecompiled machine. now dhcpd I copied from the source machine to Compact flash .CF hard disk for into net4521. This is not working in the net4521 When I downloaded source code and compiled as static in the source machine and copied to Comapct Flash .It is working . where i was wrong? _ Click, Upload, Print. http://www.kodakexpress.co.in?soe=4956 Deliver in India. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/2] readahead: improve sequential read detection
Ram wrote: On Wed, 2005-03-02 at 11:08, Oleg Nesterov wrote: out: - return newsize; + return ra-prev_page + 1; This change introduces one key behavioural change in page_cache_readahead(). Instead of returning the number-of-pages successfully read, it now returns the next-page-index which is yet to be read. Was this essential? The problem is that with this change: + if (offset == ra-prev_page --req_size) + ++offset; we can't just return newsize. Because the caller of page_cache_readahead(offset, req_size) expects that returned value is the number-of-pages successfully read from this original offset. Consider do_generic_mapping_read() reading two pages at offset 10, with ra-prev_page == 10. 1st page, index == 10: ret_size = page_cache_readahead(10, 2); // returns 1 next_index += ret_size; // next_index == 11 2nd page, index == 11: if (index == next_index)// Yes page_cache_readahead(11, 1);// BOGUS! It can be solved without behavioural change of course, but it will be more complex. At least, a comment towards this effect at the top of the function is worth adding. Yes, it's my fault. I should have added comment in changelog at least. Oleg. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] /proc/$$/ipaddr and per-task networking bits
On Thu, 2005-03-10 at 17:00 +0100, Lorenzo Hernndez Garca-Hierro wrote: it tries to fill the ipaddr member of the task_struct structure with the IP address associated to the user running @current task/process,if available. but... a use doesn't hane an IP. a host does. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] new driver for ITM Touch touchscreen
On Tue, Mar 08, 2005 at 05:01:00PM +0100, Hans-Christian Egtvedt wrote:
I really don't think the controller can now anything about the size of
the screen.
I've attached version 1.2.1 of the driver, fixed some typo, code cleanup
and discovered I used depricated functions so I moved to the new correct
way of doing killing of the urb.
Pacth applied, with minor cleanups.
--- kernel-source-2.6.11/drivers/usb/input/Kconfig2004-12-24
22:35:23.0 +0100
+++ linux-2.6.11/drivers/usb/input/Kconfig2005-03-02 10:58:41.0
+0100
@@ -190,6 +190,18 @@
To compile this driver as a module, choose M here: the
module will be called mtouchusb.
+config USB_ITMTOUCH
+ tristate ITM Touch USB Touchscreen Driver
+ depends on USB INPUT
+ ---help---
+ Say Y here if you want to use a ITM Touch USB
+ Touchscreen controller.
+
+ This touchscreen is used in LG 1510SF monitors.
+
+ To compile this driver as a module, choose M here: the
+ module will be called itmtouch.
+
config USB_EGALAX
tristate eGalax TouchKit USB Touchscreen Driver
depends on USB INPUT
--- kernel-source-2.6.11/drivers/usb/input/Makefile 2004-12-24
22:35:00.0 +0100
+++ linux-2.6.11/drivers/usb/input/Makefile 2005-03-02 10:57:11.0
+0100
@@ -33,6 +33,7 @@
obj-$(CONFIG_USB_KBTAB) += kbtab.o
obj-$(CONFIG_USB_MOUSE) += usbmouse.o
obj-$(CONFIG_USB_MTOUCH) += mtouchusb.o
+obj-$(CONFIG_USB_ITMTOUCH) += itmtouch.o
obj-$(CONFIG_USB_EGALAX) += touchkitusb.o
obj-$(CONFIG_USB_POWERMATE) += powermate.o
obj-$(CONFIG_USB_WACOM) += wacom.o
--- /dev/null 2005-03-01 19:15:30.0 +0100
+++ linux-2.6.11/drivers/usb/input/itmtouch.c 2005-03-02 11:05:04.0
+0100
@@ -0,0 +1,318 @@
+/**
+ * itmtouch.c -- Driver for ITM touchscreen panel
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Based upon original work by Chris Collins [EMAIL PROTECTED].
+ *
+ * History
+ * 1.0 1.1 2003 (CC) [EMAIL PROTECTED]
+ * Original version for 2.4.x kernels
+ *
+ * 1.2 02/03/2005 (HCE) [EMAIL PROTECTED]
+ * Complete rewrite to support Linux 2.6.10, thanks to mtouchusb.c for
hints.
+ * Unfortunately no calibration support at this time.
+ *
+ * 1.2.1 09/03/2005 (HCE) [EMAIL PROTECTED]
+ * Code cleanup and adjusting syntax to start matching kernel standards
+ *
+
*/
+
+/* In order to prevent poluting device space with YET ANOTHER character
+ * device, this driver pumps out raw coordinate events into the input
+ * event stream.
+ *
+ * They can be extracted using the input core raw events module.
+ *
+ * Kudos to ITM for providing me with the datasheet for the panel,
+ * even though it was a day later than I had finished writing this
+ * driver.
+ *
+ * It has meant that I've been able to correct my interpretation of the
+ * protocol packets however.
+ *
+ * CC -- 2003/9/29
+ */
+
+#include linux/config.h
+
+#ifdef CONFIG_USB_DEBUG
+ #define DEBUG
+#else
+ #undef DEBUG
+#endif
+
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/input.h
+#include linux/module.h
+#include linux/init.h
+#include linux/usb.h
+
+/* only an 8 byte buffer necessary for a single packet */
+#define ITM_BUFSIZE 8
+/* support a maximum of 4 such touchscreens at once */
+#define MAXTOUCH 4
+#define UCP(x) ((unsigned char*)(x))
+#define UCOM(x,y,z) ((UCP((x)-transfer_buffer)[y]) (z))
+#define PATH_SIZE64
+
+#define USB_VENDOR_ID_ITMINC 0x0403
+#define USB_PRODUCT_ID_TOUCHPANEL0xf9e9
+
+#define DRIVER_AUTHOR Hans-Christian Egtvedt [EMAIL PROTECTED]
+#define DRIVER_VERSION v1.2.1
+#define DRIVER_DESC USB ITM Inc Touch Panel Driver
+#define DRIVER_LICENSE GPL
+
+MODULE_AUTHOR( DRIVER_AUTHOR );
+MODULE_DESCRIPTION( DRIVER_DESC );
+MODULE_LICENSE( DRIVER_LICENSE );
+
+struct itmtouch_dev {
+ struct usb_device *usbdev; /* usb device */
+ struct
Re: current linus bk, error mounting root
On Thu, 10 Mar 2005 17:01:55 +0100, Jens Axboe [EMAIL PROTECTED] wrote: what are the major/minor numbers of /dev/root? If I boot on a working system it is 8,5 mkrootdev is a nash command mkrootdev path Makes path a block inode for the device which should be mounted as root. To determine this device nash uses the device sug- gested by the root= kernel command line argument (if root=LABEL is used devices are probed to find one with that label). If no root= argument is available, /proc/sys/kernel/real-root-dev provides the device number. I already tried switching from the label syntax to /dev/sda5 without effect. -- Jon Smirl [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: [Ipsec] Issue on input process of Linux native IPsec
On Thu, 2005-03-10 at 02:37 -0800, Park Lee wrote: On Fri, 24 Dec 2004 at 16:15, David Dillow wrote: xfrm_lookup() is only called for outgoing packets, not for received packets. I don't think ping replies (ICMP echo replies) will ever have a non- NULL sk, as they are not associated with a socket. Then, Why did you say that ping replies (ICMP echo replies) were not associated with a socket? Because your crashes where caused by blindly assuming the sk would never be NULL in xfrm_lookup(), and it clearly was. The simple debugging printk() I suggested you insert with your code would have shown you that that was the reason for your crashes. And if I was feeling nice that day, which is possible, since it was Christmas Eve, I may have even put the printk() in myself and tested. Is there any difference between the special purpose socket and the socket you mentioned above? I have no idea. You have the code, and probably as much understanding of the networking stack as I do. I suggest you use find and grep to track down the what you are interested in, and how xfrm_lookup() is called in various situations. Take good notes, especially about avenues of exploration that come time mind as you chase one code path. It's not very hard, it's how I learned. -- Dave Dillow [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] /proc/$$/ipaddr and per-task networking bits
Replying to Arjan van de Ven: On Thu, 2005-03-10 at 17:00 +0100, Lorenzo Hernndez Garca-Hierro wrote: it tries to fill the ipaddr member of the task_struct structure with the IP address associated to the user running @current task/process,if available. but... a use doesn't hane an IP. a host does. I don't get it too With multihomed setup same process I have can send and receive on many addresses simultaneously. So single ip_addr cannot describe this situation. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key - my pgp key This message represents the official view of the voices in my head - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: current linus bk, error mounting root
On Thu, Mar 10 2005, Jon Smirl wrote: On Thu, 10 Mar 2005 17:01:55 +0100, Jens Axboe [EMAIL PROTECTED] wrote: what are the major/minor numbers of /dev/root? If I boot on a working system it is 8,5 I see no /dev/sda detected in your system from the dmesg. Ahh this is where it panics on loading ata_piix I suppose, can't you capture that panic with the serial console as well? -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: make -j4 gets stuck w/ ccache over NFS - solved!
On Thu, Mar 10, 2005 at 12:47:37AM -0500, Mark M. Hoffman wrote: Thanks for the suggestions. It wasn't very important to me so I didn't make time to follow up on it. I was just playing w/ ccache at the time. Finally I noticed this patch from -mm1... and it solves the problem. nfsd--lockd-dont-try-to-match-callback-requests-against-export-table.patch How I tested: I applied the first 12 patches in 2.6.11-mm1; the above mentioned was last - couldn't reproduce the bug. When I unapplied just that one, I saw it again. original bug report: http://marc.theaimsgroup.com/?l=linux-kernelm=110238645132535w=3 Greg: have you considered this one for 2.6.11.x? That patch depends on 3 of the previous 4 patches. Taken together I doubt they meet the criteria for 2.6.11.x. It's probably possible to write a shorter and more obvious one-off fix just for that tree, but I'm not sure it's worth it for a bug that, while it's obviously extremely annoying for some workloads, doesn't quite reach the level of, say, a root exploit. --b. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
binary drivers and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been looking at the UDI project[1] and thinking about binary drivers and the like, and wondering what most peoples' take on these are and what impact that UDI support would have on the kernel's development. I know the immediate first reactions are probably Portable drivers are slow and We don't support closed source crap. I think benchmarks are needed, and closed drivers can always be replaced by rewritten open ones. Really critical drivers that need the extra few microseconds can always be low-level instead of abstracted. The major considerations I come across mainly involve development focus and kernel tree size. UDI drivers would be separated from the kernel, so their development would be focused; a driver fix would not warrent a 2.6, 2.4, and 2.2 patch, plus backports in 100 distributions (which don't concern the LKML). They'd also be in their own tarball, so the kernel tree size would be a lot smaller if most drivers were UDI, though by how much I'm not sure. I'm aware that drivers would have to be loaded to the kernel like this, being separated. Aside from having the kernel build eat drivers from some /lib/modules/udi/ directory, grub has a module command that can load multiple modules. If the kernel used that to load drivers (does it now?), an initrd wouldn't be needed; a very straightforward bootloader configuration would come in its place. There is a 2.4 UDI reference model out with SCSI and NIC driver support. Perhaps some experimentation with these would be interesting, since the disk and the network are performance focuses. I don't think the UDI reference model is ready quite yet for mainline, but it's ready for some cross-examination by unbiased kernel developers. [1] http://projectudi.sourceforge.net/ - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMHW2hDd4aOud5P8RAnhSAJ9+8VdgR6EX0JwjUpysXsTMRl1ewwCeOWJR g6mNs6NuEltgNS6qtVat5Mo= =DrWO -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/
Re: [PATCH] new driver for ITM Touch touchscreen
On Thu, 2005-03-10 at 17:18 +0100, Vojtech Pavlik wrote: On Tue, Mar 08, 2005 at 05:01:00PM +0100, Hans-Christian Egtvedt wrote: I really don't think the controller can now anything about the size of the screen. I've attached version 1.2.1 of the driver, fixed some typo, code cleanup and discovered I used depricated functions so I moved to the new correct way of doing killing of the urb. Pacth applied, with minor cleanups. Could you send me your changes? snip patch file -- Hans-Christian Egtvedt [EMAIL PROTECTED] MIVU Solutions DA - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] /proc/$$/ipaddr and per-task networking bits
On Thu, 2005-03-10 at 17:08 +0100, Arjan van de Ven wrote: On Thu, 2005-03-10 at 17:00 +0100, Lorenzo Hernndez Garca-Hierro wrote: it tries to fill the ipaddr member of the task_struct structure with the IP address associated to the user running @current task/process,if available. but... a use doesn't hane an IP. a host does. I'm not sure i understand but i've just tried to read the code and it looks like the IP address is the address of the other end of a socket. This address is set when a process does accept(). So this user IP we are talking about would be the remote users host IP (or gateway in case of NAT). I don't think i fully understand the code but it looks like it only holds the remote IP address of the last accept()-ed connection. Joost Remijn signature.asc Description: This is a digitally signed message part
Re: [PATCH] make st seekable again
On Iau, 2005-03-10 at 12:10, Arjan van de Ven wrote: CONFIG_SECURITY_HOLES doesn't make sense. Better to just fix the security holes instead. In the case of st its merely broken. I reviewed the code again to double check for Marcelo. Still should be a ask your vendor to fix tar item. 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: [PATCH] new driver for ITM Touch touchscreen
On Thu, Mar 10, 2005 at 05:41:42PM +0100, Hans-Christian Egtvedt wrote: On Thu, 2005-03-10 at 17:18 +0100, Vojtech Pavlik wrote: On Tue, Mar 08, 2005 at 05:01:00PM +0100, Hans-Christian Egtvedt wrote: I really don't think the controller can now anything about the size of the screen. I've attached version 1.2.1 of the driver, fixed some typo, code cleanup and discovered I used depricated functions so I moved to the new correct way of doing killing of the urb. Pacth applied, with minor cleanups. Could you send me your changes? Here is the final patch: [EMAIL PROTECTED], 2005-03-10 17:17:56+01:00, [EMAIL PROTECTED] input: Add driver for ITM Touch USB touchscreens. From: Hans-Christian Egtvedt [EMAIL PROTECTED] Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] Kconfig| 12 ++ Makefile |1 itmtouch.c | 281 + 3 files changed, 294 insertions(+) diff -Nru a/drivers/usb/input/Kconfig b/drivers/usb/input/Kconfig --- a/drivers/usb/input/Kconfig 2005-03-10 17:45:56 +01:00 +++ b/drivers/usb/input/Kconfig 2005-03-10 17:45:56 +01:00 @@ -190,6 +190,18 @@ To compile this driver as a module, choose M here: the module will be called mtouchusb. +config USB_ITMTOUCH + tristate ITM Touch USB Touchscreen Driver + depends on USB INPUT + ---help--- + Say Y here if you want to use a ITM Touch USB + Touchscreen controller. + + This touchscreen is used in LG 1510SF monitors. + + To compile this driver as a module, choose M here: the + module will be called itmtouch. + config USB_EGALAX tristate eGalax TouchKit USB Touchscreen Driver depends on USB INPUT diff -Nru a/drivers/usb/input/Makefile b/drivers/usb/input/Makefile --- a/drivers/usb/input/Makefile2005-03-10 17:45:56 +01:00 +++ b/drivers/usb/input/Makefile2005-03-10 17:45:56 +01:00 @@ -33,6 +33,7 @@ obj-$(CONFIG_USB_KBTAB)+= kbtab.o obj-$(CONFIG_USB_MOUSE)+= usbmouse.o obj-$(CONFIG_USB_MTOUCH) += mtouchusb.o +obj-$(CONFIG_USB_ITMTOUCH) += itmtouch.o obj-$(CONFIG_USB_EGALAX) += touchkitusb.o obj-$(CONFIG_USB_POWERMATE)+= powermate.o obj-$(CONFIG_USB_WACOM)+= wacom.o diff -Nru a/drivers/usb/input/itmtouch.c b/drivers/usb/input/itmtouch.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/usb/input/itmtouch.c 2005-03-10 17:45:56 +01:00 @@ -0,0 +1,281 @@ +/** + * itmtouch.c -- Driver for ITM touchscreen panel + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + * Based upon original work by Chris Collins [EMAIL PROTECTED]. + * + * Kudos to ITM for providing me with the datasheet for the panel, + * even though it was a day later than I had finished writing this + * driver. + * + * It has meant that I've been able to correct my interpretation of the + * protocol packets however. + * + * CC -- 2003/9/29 + * + * History + * 1.0 1.1 2003 (CC) [EMAIL PROTECTED] + * Original version for 2.4.x kernels + * + * 1.2 02/03/2005 (HCE) [EMAIL PROTECTED] + * Complete rewrite to support Linux 2.6.10, thanks to mtouchusb.c for hints. + * Unfortunately no calibration support at this time. + * + * 1.2.1 09/03/2005 (HCE) [EMAIL PROTECTED] + * Code cleanup and adjusting syntax to start matching kernel standards + * + */ + +#include linux/config.h + +#ifdef CONFIG_USB_DEBUG + #define DEBUG +#else + #undef DEBUG +#endif + +#include linux/kernel.h +#include linux/slab.h +#include linux/input.h +#include linux/module.h +#include linux/init.h +#include linux/usb.h + +/* only an 8 byte buffer necessary for a single packet */ +#define ITM_BUFSIZE8 +#define PATH_SIZE 64 + +#define USB_VENDOR_ID_ITMINC 0x0403 +#define USB_PRODUCT_ID_TOUCHPANEL 0xf9e9 + +#define DRIVER_AUTHOR Hans-Christian Egtvedt [EMAIL PROTECTED] +#define DRIVER_VERSION v1.2.1 +#define DRIVER_DESC USB ITM Inc Touch Panel Driver +#define DRIVER_LICENSE GPL + +MODULE_AUTHOR( DRIVER_AUTHOR ); +MODULE_DESCRIPTION( DRIVER_DESC );
Re: [RFC] -stable, how it's going to work.
On Thu, Mar 10, 2005 at 09:00:51PM +1100, Neil Brown wrote: On Tuesday March 8, [EMAIL PROTECTED] wrote: So here's a first cut at how this 2.6 -stable release process is going to work that Chris and I have come up with. Does anyone have any problems/issues/questions with this? One rule that I thought would make sense, but that I don't see listed is: - must fix a regression That, and a zillion other specific wordings that people suggested fall under the: or some oh, that's not good issue rule. I didn't feel like being all lawyer-like and explicitly spelling out all of the different kinds of bugs that we would be accepting patches for :) So yes, I don't have a problem with patches to fix regressions. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add timing information to printk messages
On Wed, 09 Mar 2005 15:50:52 PST, Tim Bird said: Tony Luck wrote: Setting CONFIG_PRINTK_TIME=y I see (the NUL pieces are actually each a single ASCII '\0' character): Tony, Can you try the patch below? (inspired by a patch from Tom Zanussi - gotta give credit where credit is due... :-) This solves the problem for me but I'd like independent confirmation. I was seeing this issue as well, and the patch clears it up here too pgpJVqFYfGaMA.pgp Description: PGP signature
Re: [PATCH] PPC64 NUMA memory fixup
On Thu, Mar 10, 2005 at 02:36:13AM -0800, Andrew Morton wrote: This patch causes the non-numa G5 to oops very early in boot in smp_call_function(). OK - Let me take a look. -- Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binary drivers and development
On Thu, Mar 10, 2005 at 11:28:39AM -0500, John Richard Moser wrote: I've been looking at the UDI project[1] and thinking about binary drivers and the like, and wondering what most peoples' take on these are and what impact that UDI support would have on the kernel's development. Please, the UDI stuff has been proven to be broken and wrong. If you want to work on it, feel free to do so, just don't expect for anyone to accept the UDI layer into the kernel mainline. What's that phrase about people forgetting history are doomed... greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: One more Asus SMBus quirk
On Thu, Mar 10, 2005 at 06:54:57AM -0500, Bill Davidsen wrote: On Wed, 9 Mar 2005, Greg KH wrote: On Wed, Mar 09, 2005 at 11:06:15AM -0500, Bill Davidsen wrote: On Tue, 8 Mar 2005, Greg KH wrote: On Tue, Mar 08, 2005 at 05:18:16PM -0500, Bill Davidsen wrote: Greg KH wrote: ChangeSet 1.1998.11.27, 2005/02/25 15:48:28-08:00, [EMAIL PROTECTED] [PATCH] PCI: One more Asus SMBus quirk One more Asus laptop requiring the SMBus quirk (W1N model). Signed-off-by: Jean Delvare [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] Hopefully this and the double-free patch will be included in 2.6.11.n+1? what double-free patch? ChangeSet 1.1998.11.26, 2005/02/25 15:48:12-08:00 See [EMAIL PROTECTED]. Giving just the Subject: would have been easier to find the patch... But... but... but it was YOUR PATCH, wasn't it? That's kind of why I didn't expect much problem identifying it, I got it from you. No, I didn't write it. If you notice, I sent out over 200 patches in the past few days, the majority from other people. So trying to remember exactly which patch you were referring to took a bit of searching :) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11] fix: drivers/base/class.c
On Thu, Mar 10, 2005 at 03:08:56PM +0300, JustMan wrote:
fix: drivers/base/class.c
fix how? What are you fixing?
diff -uNrp linux/drivers/base/class.orig.c linux/drivers/base/class.c
--- linux/drivers/base/class.orig.c 2005-03-10 12:19:00.0 +0300
+++ linux/drivers/base/class.c 2005-03-10 13:59:27.0 +0300
@@ -307,12 +307,14 @@ static int class_hotplug(struct kset *ks
if (class_dev-dev) {
/* add physical device, backing this device */
struct device *dev = class_dev-dev;
Your email client ate all of the tabs, this patch can't be applied :(
- char *path = kobject_get_path(dev-kobj, GFP_KERNEL);
- add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size,
-length, PHYSDEVPATH=%s, path);
- kfree(path);
+ if(kobject_name(dev-kobj)) {
+ char *path = kobject_get_path(dev-kobj, GFP_KERNEL);
+ add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size,
+length, PHYSDEVPATH=%s, path);
+ kfree(path);
+ }
Let me guess, you are using an out-of-tree driver that incorrectly sets
up the kobject and the hotplug userspace code doesn't like the NULL in
the strings?
Fix the driver, the kobject should have a name.
thanks,
greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: binary drivers and development
On Thu, Mar 10, 2005 at 11:28:39AM -0500, John Richard Moser wrote: I've been looking at the UDI project[1] and thinking about binary drivers and the like, and wondering what most peoples' take on these are and what impact that UDI support would have on the kernel's development. UDI is already dead. You just haven't noticed. And just like with dead people it's death also had a cause :-) 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/
x86-64 linux-2.6.11-mm2 - BUG: soft lockup detected on CPU#0! (ohci_hub_resume)
Just booted 2.6.11-mm2 with a new .config and ran into this BUG(). Here
is the snippet from dmesg.
[ 25.088135] ohci_hcd :00:02.0: wakeup
[ 25.113120] BUG: soft lockup detected on CPU#0!
[ 25.113128]
[ 25.113135] Modules linked in: ehci_hcd ohci_hcd usbcore i2c_nforce2
it87 eeprom i2c_sensor i2c_isa i2c_dev i2c_core cpufreq_userspace
powernow_k8 freq_table processor r8169 psmouse forcedeth unix
[ 25.113216] Pid: 4, comm: events/0 Not tainted 2.6.11-mm2
[ 25.113225] RIP: 0010:[801f7db5] 801f7db5{__delay
+5}
[ 25.113240] RSP: :810002145e20 EFLAGS: 0283
[ 25.113255] RAX: 0005f88c RBX: 8015e88b RCX:
c355687a
[ 25.113265] RDX: 000b RSI: 0001 RDI:
001e5d70
[ 25.113274] RBP: 810001d888c8 R08: 0720 R09:
0004
[ 25.113284] R10: R11: 0001 R12:
[ 25.113294] R13: 810002144000 R14: c2004000 R15:
81003fed8108
[ 25.113305] FS: 2ae00520() GS:80459800()
knlGS:
[ 25.113317] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
[ 25.113326] CR2: 005cec28 CR3: 3f31b000 CR4:
06e0
[ 25.113335]
[ 25.113336] Call Trace:8807f3c4{:ohci_hcd:ohci_hub_resume
+388} 8807f5e5{:ohci_hcd:ohci_rh_resume+21}
[ 25.113376]801448c1{worker_thread+497}
8012e180{default_wake_function+0}
[ 25.113410]802f96ba{thread_return+118}
8012e180{default_wake_function+0}
[ 25.113444]801446d0{worker_thread+0}
80149438{kthread+136}
[ 25.113475]8010edeb{child_rip+8}
801446d0{worker_thread+0}
[ 25.113507]801493b0{kthread+0}
8010ede3{child_rip+0}
[ 25.113538]
[ 25.548709] usb 1-4: new full speed USB device using ohci_hcd and
address 2
Attached is the .config.
Sam
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux EvilTwin 2.6.11-mm2 #1 Tue Mar 8 22:56:38 GMT 2005 x86_64 GNU/Linux
Gnu C 3.3.5
Gnu make 3.80
binutils 2.15
util-linux 2.12p
mount 2.12p
module-init-tools 3.2-pre1
e2fsprogs 1.36
reiserfsprogs line
reiser4progs line
nfs-utils 1.0.7
Linux C Library2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.2.5
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.2.1
udev 054
Modules Loaded rfcomm l2cap ipv6 af_packet mousedev evdev floppy rtc
usbhid usblp hci_usb bluetooth snd_emu10k1 snd_rawmidi snd_seq_device
snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd
soundcore ehci_hcd ohci_hcd usbcore i2c_nforce2 it87 eeprom i2c_sensor i2c_isa
i2c_dev i2c_core cpufreq_userspace powernow_k8 freq_table processor r8169
psmouse forcedeth unix
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-mm2
# Thu Mar 10 16:08:54 2005
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_HPET_TIMER=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
#
# General setup
#
CONFIG_LOCALVERSION=
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Processor type and features
#
CONFIG_MK8=y
# CONFIG_MPSC is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_NUMA is not set
CONFIG_GART_IOMMU=y
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_PHYSICAL_START=0x10
# CONFIG_KEXEC is not set
CONFIG_SECCOMP=y
CONFIG_GENERIC_HARDIRQS=y
Re: [patch 4/5] audit mips fix
On Fri, Mar 04, 2005 at 01:16:57PM -0800, [EMAIL PROTECTED] wrote:
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
@@ -307,7 +308,7 @@ asmlinkage void do_syscall_trace(struct
{
if (unlikely(current-audit_context)) {
if (!entryexit)
- audit_syscall_entry(current, regs-orig_eax,
+ audit_syscall_entry(current, regs-regs[2],
Wrong. regs[2] can will contain the syscall return value and can be
modified by ptrace also.
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] make st seekable again
On Thu, 2005-03-10 at 11:56 -0500, Bill Davidsen wrote: On Thu, 10 Mar 2005, Arjan van de Ven wrote: critical user data. In other words, it should work correctly or not at all. At the least this should be a config option, like UNSAFE_TAPE_POSITIONING or some such. And show the option if the build includes BROKEN features. That should put the decision where it belongs and clarify the possible failures. CONFIG_SECURITY_HOLES doesn't make sense. Better to just fix the security holes instead. I think you're an idealist. If this were something other than tar it would be simple, and you would be right. Well, you ARE right, but a change which breaks tar, which many sites use for backups, is really not practical, without a loophole until tar gets fixed. And as Alan noted, keeping track of the physical position is very hard, and getting a tar fix might take a while. No the problem is that the *st* code has a security hole. THAT is the problem. Not that it would be seekable. But how it implements the seeks. THAT part is the problem. And THAT can be fixed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm1
On Fri, Mar 04, 2005 at 03:32:15AM -0800, Andrew Morton wrote: [snip] +fix-scripts-mkubootsh-to-return-status.patch kbuild fix Please drop this. The problem is that 'make uImage' was saying that it sucessfully built a uImage when it didn't. The reason we have a wrapper script around mkimage (mkuboot.sh) is so that we can always provide a uImage (it's cheap) if the user has the tools around (and thus probably wants it), but can still have it in the 'all' target, and do no harm, in the case where people don't. This is currently upsetting a number of ppc32 folks since uImage is a default target, but not really needed in the common case (pmac). -- Tom Rini http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binary drivers and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg KH wrote: On Thu, Mar 10, 2005 at 11:28:39AM -0500, John Richard Moser wrote: I've been looking at the UDI project[1] and thinking about binary drivers and the like, and wondering what most peoples' take on these are and what impact that UDI support would have on the kernel's development. Please, the UDI stuff has been proven to be broken and wrong. If you want to work on it, feel free to do so, just don't expect for anyone to accept the UDI layer into the kernel mainline. 1. What's broken about it 2. Is it possible to fix it I require information or else I can't assess things. What's that phrase about people forgetting history are doomed... greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMIGqhDd4aOud5P8RAl+PAJ4ndKTmqyRRc+qaJjPK62HBABb0rgCgjCTR 8kQ9MOOdZiH3FUsNG1Hoe3E= =NIcs -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/
Re: make -j4 gets stuck w/ ccache over NFS - solved!
On Thu, Mar 10, 2005 at 12:47:37AM -0500, Mark M. Hoffman wrote: Finally I noticed this patch from -mm1... and it solves the problem. nfsd--lockd-dont-try-to-match-callback-requests-against-export-table.patch How I tested: I applied the first 12 patches in 2.6.11-mm1; the above mentioned was last - couldn't reproduce the bug. When I unapplied just that one, I saw it again. original bug report: http://marc.theaimsgroup.com/?l=linux-kernelm=110238645132535w=3 Greg: have you considered this one for 2.6.11.x? No, it hasn't been submitted to the [EMAIL PROTECTED] address :) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make st seekable again
On Thu, 10 Mar 2005, Arjan van de Ven wrote: critical user data. In other words, it should work correctly or not at all. At the least this should be a config option, like UNSAFE_TAPE_POSITIONING or some such. And show the option if the build includes BROKEN features. That should put the decision where it belongs and clarify the possible failures. CONFIG_SECURITY_HOLES doesn't make sense. Better to just fix the security holes instead. I think you're an idealist. If this were something other than tar it would be simple, and you would be right. Well, you ARE right, but a change which breaks tar, which many sites use for backups, is really not practical, without a loophole until tar gets fixed. And as Alan noted, keeping track of the physical position is very hard, and getting a tar fix might take a while. None of the choices is good; I see: - leave it the way it is - fix the hole and break tar - wait for FSF to fix tar, then fix the hole - try to fix it without breaking tar, which may not be really possible and could leave part of the problem and still break tar somehow - fix it, and leave the admin a way to build a kernel with the hole other than just reverting the fix I proposed the last, I won't cry if no one else likes it, it just seemed realistic for people who don't use certain features of tar. -- bill davidsen [EMAIL PROTECTED] CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: minor 2.6.11-bk6 config issue or user error
On Thursday 10 March 2005 10:38, Prakash Punnoor wrote: Hi, I went from bk4 to bk6. After patching i just typed make to recompile (as I thought this would be enough). But it errored out because CONFIG_BASE_SMALL wasn't defined. So I did make menuconfig and saved my config again and now it compiles through. Is it needed to run make oldconfig or make menuconfig and save before kernel upgrade? I thought make oldconfig is run automatically on make? -- Prakash Punnoor I believe thats mistaken Prakash. One should do a make oldconfig after applying any patch, or when moving an existing .config from an older version's tree to the new tree you are building. Its all part of my scripts so I don't forget. formerly known as Prakash K. Cheemplavam -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.11- sym53c8xx Broken on pp64
James Bottomley wrote: On Thu, 2005-03-10 at 12:17 +, Matthew Wilcox wrote: Heh, the devel version of sym2 (that isn't submitted yet because it depends on a few changes to the SPI transport that James hasn't integrated yet) would probably fix this as it doesn't call iounmap() until the driver exits. They're integrated into the scsi-misc-2.6 tree, so if you send in the sym2 patch to linux-scsi, everything should still work... James 2.6.10 seems to have a different kernel panic which I'm investigating (could be a problem with my ramdisk as it happens in my linuxrc). So long story short the 2.6.10 sym driver looks ok. Omkhar - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] ide: hdio.txt update
Hi,
On Thu, 3 Mar 2005 11:16:38 +0900, Tejun Heo [EMAIL PROTECTED] wrote:
+ [2] Both the input and output buffers are copied from the
+ user and written back to the user, even when not used. The
+ out_flags and in_flags are written back to the user after
+ the ioctl completes. These are the same as the input
+ values, unchanged.
This is incorrect, please refer to flagged_taskfile() and ide_taskfile_ioctl().
Unfortunately you've based your latest patch series on this assumption.
+ Taskfile registers are read back from the drive into
+ {io|hob}_ports[] after the command completes iff one of the
+ following conditions is met; otherwise, the original values
+ will be written back, unchanged.
+
+ 1. The drive fails the command (EIO).
+ 2. More than one bit is set in tf_out_flags.
Isn't one bit enough?
The rest is of the update is fine, thanks for doing this.
Bartlomiej
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add TPM hardware enablement driver
On Wed, 9 Mar 2005 16:42:01 -0800, Greg KH [EMAIL PROTECTED] wrote:
ChangeSet 1.2035, 2005/03/09 10:12:19-08:00, [EMAIL PROTECTED]
[PATCH] Add TPM hardware enablement driver
snip
+void tpm_time_expired(unsigned long ptr)
+{
+ int *exp = (int *) ptr;
+ *exp = 1;
+}
+
+EXPORT_SYMBOL_GPL(tpm_time_expired);
snip
+ down(chip-timer_manipulation_mutex);
+ chip-time_expired = 0;
+ init_timer(chip-device_timer);
+ chip-device_timer.function = tpm_time_expired;
+ chip-device_timer.expires = jiffies + 2 * 60 * HZ;
+ chip-device_timer.data = (unsigned long) chip-time_expired;
+ add_timer(chip-device_timer);
+ up(chip-timer_manipulation_mutex);
+
+ do {
+ u8 status = inb(chip-vendor-base + 1);
+ if ((status chip-vendor-req_complete_mask) ==
+ chip-vendor-req_complete_val) {
+ down(chip-timer_manipulation_mutex);
+ del_singleshot_timer_sync(chip-device_timer);
+ up(chip-timer_manipulation_mutex);
+ goto out_recv;
+ }
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(TPM_TIMEOUT);
+ rmb();
+ } while (!chip-time_expired);
snip
It seems like this use of schedule_timeout() and the others are a bit
excessive. In this case, a timer is set to go off in 2 hours or so,
with tpm_time_expired() as the callback. tpm_time_expired(), it seems
just takes data and sets it to 1, which in this case is
chip-time_expired (and is similar in the other cases). We then loop
while (!chip-time_expired), which to me means until
chip-device_timer goes off, checking if the request is complete every
5 milliseconds. The chip-device_timer doesn't really do anything,
does it? It just guarantees a maximum time (of 2 hours). Couldn't the
same be achieved with (please excuse the lack of tabs, any real
patches I submit will have them):
unsigned long stop = jiffies + 2 * 60 * HZ;
do {
u8 status = inb(chip-vendor-base + 1);
if ((status chip-vendor-req_complete_mask ==
chip-vendor-req_complete_val)
goto out_recv;
msleep(TPM_TIMEOUT); // TPM_TIMEOUT could now be 5 ms
rmb();
} while (time_before(jiffies, stop);
I think similar replacements would work in the other locations.
If people agree, I will send patches.
Thanks,
Nish
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] -stable, how it's going to work.
On Thu, 2005-03-10 at 08:43 -0800, Greg KH wrote: That, and a zillion other specific wordings that people suggested fall under the: or some oh, that's not good issue rule. So just to be 100% clear, no sound with 2.6.N where the sound worked with 2.6.N-1 absolutely does qualify. Right? Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binary drivers and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've done more thought, here's a small list of advantages on using binary drivers, specifically considering UDI. You can consider a different implementation for binary drivers as well, with most of the same advantages. - Smaller kernel tree The kernel tree would no longer contain all of the drivers; they'd slowly have to bleed into UDI until most were there - Better focused development The kernel's core would be the core. Driver code would be isolated, so work on the kernel would affect the kernel only and not any drivers. UDI is a standard interface that shouldn't be broken. This means that work on the high-level drivers will not need to be sanity checked a thousand times against the PCI Bus interface or the USB host controler API or whatnot. - Faster rebuilding for developers The isolation between drivers and core would make rebuilding involve the particular component (driver, core). A broken driver would just require recoding and rebuilding the driver; a broken kernel would require building pretty much a skeletal core - UDI supplies SMP safety The UDI page brags[1]: An advanced scheduling model. Multiple driver instances can be run in parallel on multiple processors with no lock management performed by the driver. Free paralllism and scalability! Drivers can be considered SMP safe, apparently. Inside the same driver, however, I have my doubts; I can see a driver maintaining a linked list that needs to be locked during insertions or deletions, which needs lock managment for the driver. Still, no consideration for anything outside the driver need be made, apparently. - Vendor drivers and religious issues Vendors can supply third party drivers until there are open source alternatives, since they have this religious thing where they don't want people to see their driver code, which is kind of annoying and impedes progress Disadvantages: - Preemption Is it still possible to implement a soft realtime kernel that responds to interrupts quickly? - Performance UDI's developers claim that the performance overhead is negligible. It's still added work, but it remains to be seen if it's significant enough to degrade performance. - Religious battles People have this religious thing about binary drivers, which is kind of annoying and impedes progress - Constriction This would of course create an abstraction layer that constricts the driver developer's ability to do low level complex operations for any portable binary driver A Linux specific binary driver format might be more useful, but wouldn't potentially allow for sharing the drivers across operating systems [1] http://projectudi.sourceforge.net/about.php - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMIK8hDd4aOud5P8RAo+EAJwIF7zEmiyxKzRJJ037TQ2FhYG5bACffTBX JLhXPcidbQbf18LyTmjHgh0= =gbyB -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/
Re: [PATCH] 0/2 Buddy allocator with placement policy (Version 9) + prezeroing (Version 4)
On Thu, 2005-03-10 at 14:31 +, Mel Gorman wrote: There are 2 kinds of sections: user and kernel. The traditional ZONE_HIGHMEM is full of user sections (except for vmalloc). And PTEs if configured to be allocated from high memory. I have not double checked but I don't think they can be trivially reclaimed. We've run into a couple of these pieces of highmem that can't be reclaimed. The latest one are pages for the new pipe buffers. We could code these up with a flag something like __GFP_HIGHMEM_NORCLM, that is __GFP_HIGHMEM in the normal case, but 0 in the hotplug case (at least for now). Any section which has slab pages or any kernel caller to alloc_pages() is a kernel section. Slab pages could be moved to the user section as long as the cache owner was able to reclaim the slabs on demand. At least for the large consumers of slab (dentry/inode caches), they can't quite reclaim on demand. I was picking Dipankar's brain about this one day, and there are going to be particularly troublesome dentries, like /, that are going to need some serious rethinking to be able to forcefully free. -- Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binary drivers and development
On Thu, Mar 10, 2005 at 12:19:39PM -0500, John Richard Moser wrote: Greg KH wrote: Please, the UDI stuff has been proven to be broken and wrong. If you want to work on it, feel free to do so, just don't expect for anyone to accept the UDI layer into the kernel mainline. 1. What's broken about it 2. Is it possible to fix it I require information or else I can't assess things. Please do your own research on why the UDI project failed. greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] qtronix missing failure handling
On Sat, Mar 05, 2005 at 04:08:44PM +0100, Panagiotis Issaris wrote: Hi, The Qtronix keyboard driver doesn't handle the possible failure of memory allocation. Thanks, applied. Please copy Linux/MIPS-specific patches to me or [EMAIL PROTECTED]; it was more a coincidence that I noticed your patch on this list. Thanks, 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: 2.6.11-mm2 + Radeon crash
On Wed, 2005-03-09 at 21:12 +0100, Christian Henz wrote: Hi, I wanted to try 2.6.11-mm2 for the low latency/realtime lsm stuff and I've run into a severe problem. There is absolutely no reason to use the -mm kernel anymore for low latency audio. The -mm kernels were never stable enough to work well for audio users anyway. The latest version of Ingo's realtime preempt patch is against 2.6.11-rc4. Supposedly it applies and works with 2.6.11 vanilla, you just have to edit the patch not to expect -rc4 as the EXTRAVERSION. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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)
Mel Gorman, responding to Dave Hansen The other thing is that we'll probably have to be a lot more strict about how the allocations fall back. Some users will probably prefer to kill an application rather than let a kernel allocation fall back into a user memory area. That will be a tad trickier because we'll need a way of specifying a fallback policy at configure time. However, the fallback policy is currently isolated within one while loop, having different fallback policies is doable. The kicker is that that there might be nasty interaction with the page reclaim code where the allocator is not falling back due to policy but the reclaim code things everything is just fine. There is at least one, perhaps a few, policies that I'd like to see in the current allocator as well. 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 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? I'd be glad to investigate providing the cpuset part of the code, exposing the appropriate boolean, enum, scalar or bitmap type(s) to user land query and setting, as another file in each cpuset directory, if that would facilitate this. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 PATCHES] ide-2.6 update
Hi Linus,
Please do a
bk pull bk://bart.bkbits.net/ide-2.6
This will update the following files:
drivers/ide/Kconfig|1
drivers/ide/ide-cd.c | 58
drivers/ide/ide-default.c | 17 ++-
drivers/ide/ide-disk.c | 213 +++--
drivers/ide/ide-floppy.c | 15 ++-
drivers/ide/ide-io.c | 169 ++-
drivers/ide/ide-iops.c | 20
drivers/ide/ide-probe.c| 62 -
drivers/ide/ide-proc.c |8 -
drivers/ide/ide-tape.c | 21 +---
drivers/ide/ide-taskfile.c |6 -
drivers/ide/ide.c | 80
drivers/scsi/ide-scsi.c| 11 ++
include/linux/ide.h|6 -
14 files changed, 329 insertions(+), 358 deletions(-)
through these ChangeSets:
[EMAIL PROTECTED](none) (05/03/10 1.2016)
[ide] kill setup_driver_defaults()
* move default_do_request() to ide-default.c
* fix drivers to set ide_driver_t-{do_request,end_request,error,abort}
* kill setup_driver_defaults()
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
[EMAIL PROTECTED](none) (05/03/10 1.2015)
[ide] kill ide_driver_t-capacity
* add private /proc/ide/hd?/capacity handlers to ide-{cd,disk,floppy}.c
* use generic proc_ide_read_capacity() for ide-{scsi,tape}.c
* kill -capacity, default_capacity() and generic_subdriver_entries[]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
[EMAIL PROTECTED](none) (05/03/10 1.2014)
[ide] kill ide_driver_t-pre_reset
Add ide_drive_t-post_reset flag and use it to signal post reset
condition to the ide-tape driver (the only user of -pre_reset).
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
[EMAIL PROTECTED](none) (05/03/10 1.2013)
[ide] fix some rare ide-default vs ide-disk races
Some rare races between ide-default and ide-disk are possible, i.e.:
* ide-default is used, I/O request is triggered (ie. /proc/ide/hd?/identify),
drive-special is cleared silently (so CHS is not initialized properly),
ide-disk is loaded and fails if drive uses CHS
* ide-disk is used, drive is resetted, ide-disk is unloaded, ide-default
takes control over drive and on the first I/O request silently clears
drive-special without restoring settings
Fix them by moving idedisk_{special,pre_reset}() and company to IDE core.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
[EMAIL PROTECTED](none) (05/03/10 1.2012)
[ide] generic Power Management for IDE devices
Move PM code from ide-cd.c and ide-disk.c to IDE core so:
* PM is supported for other ATAPI devices (floppy, tape)
* PM is supported even if specific driver is not loaded
Also s/HWIF(drive)/drive-hwif/ while at it.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
[EMAIL PROTECTED](none) (05/03/10 1.2011)
[ide] fix drive-ready_stat for ATAPI
ATAPI devices ignore DRDY bit so drive-ready_stat must be set to zero.
It is currently done by device drivers (including ide-default fake driver)
but for PMAC driver it is too late as wait_for_ready() may be called during
probe: probe_hwif()-pmac_ide_dma_check()-pmac_ide_{mdma,udma}_enable()-
-pmac_ide_do_setfeature()-wait_for_ready().
Fixup drive-ready_stat just after detecting ATAPI device.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
[EMAIL PROTECTED] (05/03/10 1.2010)
[ide] fix DMA support for LBA48 disks on ALi15x3 (revs 0xC5)
From: Bram Verweij [EMAIL PROTECTED]
The problem seems to be that ide-disk.c tries to use PIO mode for
blocks 137 GB (which is good), and LBA48 + DMA for blocks = 137GB
(which is known to be a problem, i.e., this is why the no_lba48_dma
field was introduced in the first place). Attached is a small patch
that makes ide-disk.c use PIO mode for blocks 137 GB, and LBA28 DMA
(instead of LBA48 DMA) for blocks = 137 GB.
bart: argh, I forgot about 'lba48' flag; patch slightly modified by me
Signed-off-by: Bartlomiej Zolnierkiewicz [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: Average power consumption in S3?
Matthew Garrett wrote: Radeons don't actually power down in D3 unless some registers are set, and even then the kernel doesn't currently have any code that would put the Radeon in D3. If you're willing to test something, could you try the code at http://www.srcf.ucam.org/~mjg59/radeon/ immediately before putting the machine into suspend? Make sure that you do this from something other than X. This reduces power consumption from ca. 1500 to ca. 1200 mWh, so it's already a huge improvement, but with 1.5 days of maximal suspend still pretty far away from a week. Cheers, Moritz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] -stable, how it's going to work.
On Thu, Mar 10, 2005 at 12:27:23PM -0500, Lee Revell wrote: On Thu, 2005-03-10 at 08:43 -0800, Greg KH wrote: That, and a zillion other specific wordings that people suggested fall under the: or some oh, that's not good issue rule. So just to be 100% clear, no sound with 2.6.N where the sound worked with 2.6.N-1 absolutely does qualify. Right? Hm, do you think that is a good thing to have happen?... greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] -stable, how it's going to work.
On Thu, 10 Mar 2005, Lee Revell wrote: So just to be 100% clear, no sound with 2.6.N where the sound worked with 2.6.N-1 absolutely does qualify. Right? If you can send in a patch that fixes it in an obvious way and in less than 100 lines of context diff, hell yes. Remember: all the other constraints still hold. Don't fall into the trap of believing that if it fixes a regression, it's for -stable. It needs to be _obvious_, and it needs to be small enough that bugs are unlikely. And that small enough is really important. Bugs do happen. Even in obvious patches. The whole _point_ of -stable is to try to make them less likely, and the strict constraints are very much a part of that. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] printk-times bugfix for loglevel-only printks
Linus,
This patch fixes a bug with the recently added printk-times feature.
In the case where a printk consists of only the log level (followed
subsequently by printks with more text for the same line), the
printk-times code doesn't correctly recognize the end of the
string, and starts emitting chars at the 0 byte at the end of the
string.
The patch below fixes this problem. It also adjusts the handling
of printed_len in the routine, which was affected by the
printk-times feature.
Please apply. Thanks.
-- Tim Bird, Senior Software Engineer, Sony Electronics
diffstat:
printk.c |5 +
1 files changed, 5 insertions(+)
Signed-off-by: Tim Bird [EMAIL PROTECTED]
Acked-by: Tony Luck [EMAIL PROTECTED]
--
diff -pruN printk-1/kernel/printk.c printk-fix1/kernel/printk.c
--- printk-1/kernel/printk.c2005-03-09 15:42:04.550944124 -0800
+++ printk-fix1/kernel/printk.c 2005-03-09 15:36:18.928567360 -0800
@@ -579,6 +579,7 @@ asmlinkage int vprintk(const char *fmt,
p[1] = '7' p[2] == '') {
loglev_char = p[1];
p += 3;
+ printed_len += 3;
} else {
loglev_char = default_message_loglevel
+ '0';
@@ -593,6 +594,7 @@ asmlinkage int vprintk(const char *fmt,
for (tp = tbuf; tp tbuf + tlen; tp++)
emit_log_char (*tp);
+ printed_len += tlen - 3;
} else {
if (p[0] != '' || p[1] '0' ||
p[1] '7' || p[2] != '') {
@@ -601,8 +603,11 @@ asmlinkage int vprintk(const char *fmt,
+ '0');
emit_log_char('');
}
+ printed_len += 3;
}
log_level_unknown = 0;
+ if (!*p)
+ break;
}
emit_log_char(*p);
if (*p == '\n')
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 64-bit resources?
On Thu, Mar 10, 2005 at 01:46:10AM -0600, Kumar Gala wrote: Greg, I was wondering what the state of the change to 64-bit resources was? On hold till I get the time to fix all of the kernel tree up due to the changes required. Unless someone else wants to volunteer to do the work :) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
