Re: 2.4.29 sk98lin patch for Asus K8W SE Deluxe
On Wed, Mar 02, 2005 at 02:00:30PM -0800, Philippe Troin wrote:
> + /* Asus K8V Se Deluxe bugfix. Correct VPD content */
> + /* MBo April 2004 */
> + if( ((unsigned char)pAC->vpd.vpd_buf[0x3f] == 0x38) &&
> + ((unsigned char)pAC->vpd.vpd_buf[0x40] == 0x3c) &&
> + ((unsigned char)pAC->vpd.vpd_buf[0x41] == 0x45) ) {
> + printk("sk98lin : humm... Asus mainboard with buggy VPD ?
> correcting data.\n");
^
Please, could you put some KERN_XXX here to avoid a buggy message level ?
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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
David S. Miller wrote: On Wed, 02 Mar 2005 23:46:22 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is preferable to even/odd. All of these arguments are circular. If people think that even/odd will devalue odd releases, guess what 2.6.x.y will do? By that line of reasoning nobody will test 2.6.x just the same as they aren't testing 2.6.x-rc* right now. even/odd means that certain releases (even ones) are more magical than others. That's weird, since users aren't used to that sort of thing in any other project. 2.6.x.y and 2.6.x-rc [where rc == serious bugfixes only!] are understandable to users, because they have seen that sort of thing before. Users _aren't_ fooled by naming games. The current 2.6-rc proves that. I think they will test the odd releases, because as a real release they will get slashdot/lwn.net/etc. announcements. That's one of the major things the -rc's don't get. Maybe it gets a reference in lwn.net's weekly kernel article, but mostly kernel geeks read those and that's not who we want testing -rc's (such geeks already are doing so). LWN, Slashdot and others will not be fooled though :) They will note that release 2.6. is not a real release. It has to be a "real" release. That does have an impact. However, I am ambivalent about how to make them real. Even/odd, 2.6.x.y, either is fine with me. 2.6.x.y has a very real engineering benefit: it becomes a stable release branch. That will encourage even more users to test it, over and above a simple release naming change. Users have been clamoring for a stable release branch in any case, as you see from comments about Alan's -ac and an LKML user's -as kernels. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
Benjamin Herrenschmidt wrote: On Fri, 2005-03-04 at 04:19 +1100, Nick Piggin wrote: You don't want to do that for all architectures, as I said earlier. eg. i386 can concurrently set the dirty bit with the MMU (which won't honour the lock). So you then need an atomic lock, atomic pte operations, and atomic unlock where previously you had only the atomic pte operation. This is disastrous for performance. Of course, but I was answering to David about sparc64 which uses software TLB load :) Oh sorry, I completely misunderstood what you said... and the context in which you said it :P - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
netdev-2.6 queue updated
Added a few patches, updated for 2.6.11 release. NOTE: BK users -must- reclone netdev-2.6. Do not pull. See attached for BK info, patch URL, and changelog. BK users: bk pull bk://gkernel.bkbits.net/netdev-2.6 or bk pull bk://kernel.bkbits.net/jgarzik/netdev-2.6 Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.11-netdev1.patch.bz2 This will update the following files: drivers/net/bagetlance.c| 1368 - drivers/net/wireless/ieee802_11.h | 78 include/linux/dp83840.h | 41 Documentation/networking/bonding.txt| 2101 + Documentation/networking/e100.txt |3 Documentation/networking/ixgb.txt |9 MAINTAINERS | 11 arch/arm/mach-pxa/lubbock.c |2 arch/arm/mach-sa1100/neponset.c |2 drivers/net/3c503.c | 67 drivers/net/3c509.c |4 drivers/net/3c515.c | 32 drivers/net/3c527.c |2 drivers/net/3c59x.c |2 drivers/net/8139cp.c| 100 drivers/net/8139too.c | 293 - drivers/net/Kconfig | 59 drivers/net/Makefile|2 drivers/net/Space.c | 11 drivers/net/amd8111e.c |8 drivers/net/arcnet/arc-rawmode.c|4 drivers/net/arcnet/arc-rimi.c | 14 drivers/net/arcnet/arcnet.c | 30 drivers/net/arcnet/com20020.c |6 drivers/net/arcnet/com90io.c|4 drivers/net/arcnet/com90xx.c|8 drivers/net/arcnet/rfc1051.c|8 drivers/net/arcnet/rfc1201.c| 12 drivers/net/au1000_eth.c| 1361 - drivers/net/au1000_eth.h| 55 drivers/net/b44.c |2 drivers/net/b44.h | 14 drivers/net/bonding/bond_3ad.c |2 drivers/net/bonding/bond_3ad.h |1 drivers/net/bonding/bond_alb.c | 12 drivers/net/bonding/bond_main.c | 35 drivers/net/cs89x0.c|4 drivers/net/depca.c |4 drivers/net/dgrs.c |6 drivers/net/dl2k.c |2 drivers/net/e100.c |4 drivers/net/e1000/e1000.h |3 drivers/net/e1000/e1000_ethtool.c | 11 drivers/net/e1000/e1000_hw.c| 86 drivers/net/e1000/e1000_hw.h| 11 drivers/net/e1000/e1000_main.c | 249 - drivers/net/eepro100.c | 25 drivers/net/epic100.c |2 drivers/net/es3210.c| 32 drivers/net/ethertap.c |4 drivers/net/ewrk3.c | 87 drivers/net/fealnx.c| 275 - drivers/net/hamradio/6pack.c|4 drivers/net/hamradio/baycom_epp.c | 53 drivers/net/hamradio/baycom_par.c |8 drivers/net/hamradio/baycom_ser_fdx.c |7 drivers/net/hamradio/baycom_ser_hdx.c |7 drivers/net/hamradio/bpqether.c | 19 drivers/net/hamradio/dmascc.c | 2073 drivers/net/hamradio/hdlcdrv.c | 48 drivers/net/hamradio/mkiss.c| 12 drivers/net/hamradio/yam.c | 38 drivers/net/ibm_emac/ibm_emac.h |4 drivers/net/ibm_emac/ibm_emac_core.c| 16 drivers/net/ibm_emac/ibm_emac_core.h|2 drivers/net/ibmlana.c | 99 drivers/net/ibmlana.h |1 drivers/net/ioc3-eth.c | 83 drivers/net/irda/act200l-sir.c |3 drivers/net/irda/donauboe.c |2 drivers/net/irda/irtty-sir.c|4 drivers/net/irda/ma600-sir.c| 12 drivers/net/irda/sir_dev.c |4 drivers/net/irda/tekram-sir.c |3 drivers/net/ixgb/ixgb.h |3 drivers/net/ixgb/ixgb_ee.c | 16 drivers/net/ixgb/ixgb_ee.h |3 drivers/net/ixgb/ixgb_ethtool.c |5 drivers/net/ixgb/ixgb_hw.c |2
Re: [PATCH] A new entry for /proc
Hi Hugh,
How about map an unmap each pte?
I mean remove the pte++ and use pte_offset_map for each incremented
address and then pte_unmap. So each incremented address is an index to
get the next pte via pte_offset_map.
BR,
Mauricio Lin.
On Wed, 2 Mar 2005 19:07:15 + (GMT), Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Mar 2005, Mauricio Lin wrote:
> > Does anyone know if the place I put pte_unmap is logical and safe
> > after several pte increments?
>
> The place is logical and safe, but it's still not quite right.
> You should have found several examples of loops having the same
> problem, and what do they do?
>
> > pte = pte_offset_map(pmd, address);
> > address &= ~PMD_MASK;
> > end = address + size;
> > if (end > PMD_SIZE)
> > end = PMD_SIZE;
> > do {
> > pte_t page = *pte;
> >
> > address += PAGE_SIZE;
> > pte++;
> > if (pte_none(page) || (!pte_present(page)))
> > continue;
> > *rss += PAGE_SIZE;
> > } while (address < end);
> > pte_unmap(pte);
>
> pte_unmap(pte - 1);
>
> which works because it's a do {} while () loop which has certainly
> incremented pte at least once. But some people probably loathe that
> style, and would prefer to save orig_pte then pte_unmap(orig_pte).
>
> Hugh
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 report -- keyboard not working Linux 2.6.11 on Inspiron 1150
On Wed, 2 Mar 2005 13:26:18 -0800 (PST), Joshua Hudson <[EMAIL PROTECTED]> wrote: > No obvous reason. Works fine with kernel 2.6.10 Does it work with i8042.noacpi kernel boot parameter? -- 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: Initrd and Initramfs
On Thu, Mar 03, 2005 at 11:40:27AM +0530, Amol wrote: > Hi, > For an embedded developers perspective, Is there any other advantage of > using initramfs over initrd apart from RAMFS benefits over RAMDISK ? The fact that both are cumulable is very handy. Basically, you put all the common tools and filesystem bits in the initramfs, and only add modules or add-ons in each initrd depending on your target system. Even if you work on embedded system, as soon as there are chances that you have to deal with several hardware models, you may be interested in supporting them with just a small initrd difference. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] openfirmware: generate device table for userspace
Jeffrey Mahoney <[EMAIL PROTECTED]> wrote: > > This patch converts the usage of struct of_match to struct of_device_id, > similar to pci_device_id. This allows a device table to be generated, which > can be parsed by depmod(8) to generate a map file for module loading. It breaks the power4 build all over the place. Below is a partial fix, but.. drivers/macintosh/via-pmu.c:157: warning: `async_req_locks' defined but not used drivers/macintosh/therm_pm72.c:1626: warning: `struct of_match' declared inside parameter list drivers/macintosh/therm_pm72.c:1626: warning: its scope is only this definition or declaration, which is probably not what you want drivers/macintosh/therm_pm72.c:1649: error: elements of array `fcu_of_match' have incomplete type drivers/macintosh/therm_pm72.c:1652: error: unknown field `name' specified in initializer drivers/macintosh/therm_pm72.c:1652: error: `OF_ANY_MATCH' undeclared here (not in a function) drivers/macintosh/therm_pm72.c:1652: warning: excess elements in struct initializer drivers/macintosh/therm_pm72.c:1652: warning: (near initialization for `fcu_of_match[0]') drivers/macintosh/therm_pm72.c:1653: error: unknown field `type' specified in initializer drivers/macintosh/therm_pm72.c:1653: warning: excess elements in struct initializer drivers/macintosh/therm_pm72.c:1653: warning: (near initialization for `fcu_of_match[0]') drivers/macintosh/therm_pm72.c:1654: error: unknown field `compatible' specified in initializer drivers/macintosh/therm_pm72.c:1655: error: `OF_ANY_MATCH' undeclared here (not in a function) drivers/macintosh/therm_pm72.c:1655: warning: excess elements in struct initializer drivers/macintosh/therm_pm72.c:1655: warning: (near initialization for `fcu_of_match[0]') drivers/macintosh/therm_pm72.c:1662: warning: initialization from incompatible pointer type drivers/macintosh/therm_pm72.c:1663: warning: initialization from incompatible pointer type make[2]: *** [drivers/macintosh/therm_pm72.o] Error 1 make[1]: *** [drivers/macintosh] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs So I'll drop these patches. Please get it build- and run-tested on ppc64, resend it all? arch/ppc64/kernel/of_device.c:20: error: conflicting types for `of_match_device' include/asm-ppc/of_device.h:28: error: previous declaration of `of_match_device' arch/ppc64/kernel/of_device.c: In function `of_match_device': arch/ppc64/kernel/of_device.c:23: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:23: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:23: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:25: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:25: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:25: error: `OF_ANY_MATCH' undeclared (first use in this function) arch/ppc64/kernel/of_device.c:25: error: (Each undeclared identifier is reported only once arch/ppc64/kernel/of_device.c:25: error: for each function it appears in.) arch/ppc64/kernel/of_device.c:27: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:28: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:28: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:30: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:31: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:31: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:33: error: dereferencing pointer to incomplete type arch/ppc64/kernel/of_device.c:36: error: increment of pointer to unknown structure arch/ppc64/kernel/of_device.c:36: error: arithmetic on pointer to an incomplete type arch/ppc64/kernel/of_device.c: In function `of_platform_bus_match': arch/ppc64/kernel/of_device.c:45: warning: initialization from incompatible pointer type arch/ppc64/kernel/of_device.c: In function `of_device_probe': arch/ppc64/kernel/of_device.c:88: warning: passing arg 1 of `of_match_device' from incompatible pointer type arch/ppc64/kernel/of_device.c:90: warning: passing arg 2 of pointer to function from incompatible pointer type Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/arch/ppc64/kernel/of_device.c | 15 --- 1 files changed, 8 insertions(+), 7 deletions(-) diff -puN arch/ppc64/kernel/of_device.c~openfirmware-generate-device-table-for-userspace-fix arch/ppc64/kernel/of_device.c --- 25/arch/ppc64/kernel/of_device.c~openfirmware-generate-device-table-for-userspace-fix 2005-03-03 06:52:37.0 -0700 +++ 25-akpm/arch/ppc64/kernel/of_device.c 2005-03-03 06:55:26.0 -0700 @@ -3,6 +3,7 @@ #include #include #include +#include #include #include @@ -15,20 +16,20 @@ * Used by a driver to check
Re: 2.6.11: suspending laptop makes system randomly unstable
Miguelanxo Otero Salgueiro <[EMAIL PROTECTED]> wrote: > > I just compiled 2.6.11 from a 2.6.10 configuration for a desktop machine > (with kernel preemption activated). > Doing a make oldconfig bring some new options. I selected the default > value (for my system) for them, so I keep configuring "make great kernel > lock preemtive" to true (complete kernel configuration follows). > > Apart from the ALPS touchpad thing (see "2.6.11: touchpad > unresponsive"), the new kernel keeps: > > - Setting randomly "last battery full charge" to a huge value > (example: 400 Ah when max battery capacity is 38 Ah) so I get random > charging/discharging timing patterns That's an ACPI problem, I assume? > - Locking "softly" the system: for example, preventing new proceses > from spawning. For example, if I suspend the laptop while in Xwindows, > resuming will keep X but new proceses can't be started. Changing to a > virtual console doesn't get past the login step, as a new shell can't be > started. Is there no oops trace? Could you switch to a vc, hit alt-sysrq-t and reboot, see if you get an all-task backtrace in the kernel logs and of so, send it? > - Disabling/enabling double-clicks in the synaptic touchpad. Randomly. > All of these symthoms are more or less randomly. As far as I can tell, > everything is ok before suspending but does Random Nasty Things(tm) > after coming out from suspension. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-dev-2.6] ide: ide_dma_intr oops fix
Hello, Jens.
Jens Axboe wrote:
On Thu, Mar 03 2005, Tejun Heo wrote:
Hello, Bartlomiej.
This patch fixes ide_dma_intr() oops which occurs for TASKFILE ioctl
using DMA dataphses. This is against the latest ide-dev-2.6 tree +
all your recent 9 patches.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-taskfile-ng/drivers/ide/ide-dma.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-dma.c2005-03-03
11:59:16.485582413 +0900
+++ linux-taskfile-ng/drivers/ide/ide-dma.c 2005-03-03 12:00:07.753376048
+0900
@@ -175,10 +175,14 @@ ide_startstop_t ide_dma_intr (ide_drive_
if (OK_STAT(stat,DRIVE_READY,drive->bad_wstat|DRQ_STAT)) {
if (!dma_stat) {
struct request *rq = HWGROUP(drive)->rq;
- ide_driver_t *drv;
- drv = *(ide_driver_t **)rq->rq_disk->private_data;;
- drv->end_request(drive, 1, rq->nr_sectors);
+ if (rq->rq_disk) {
+ide_driver_t *drv;
+
+drv = *(ide_driver_t **)rq->rq_disk->private_data;;
+drv->end_request(drive, 1, rq->nr_sectors);
+ } else
+ide_end_request(drive, 1, rq->nr_sectors);
return ide_stopped;
}
printk(KERN_ERR "%s: dma_intr: bad DMA status (dma_stat=%x)\n",
Why not just set rq_disk for taskfile requests as well, seems a lot
cleaner than special casing the end_request handling.
Just because other places were fixed this way and the whole drive
command issue/completion codes are just about to be restructured. Above
code will go away soon. Please consider it a quick fix.
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
> And the reason it does _not_ work is that all the people we > want testing sure as _hell_ won't be testing -rc versions. At least they still test "real" releases.. So instead of making sure rc is really "release-candidate", we want to trick people to test -pre as "real release", soon people will realize it and just stop testing even real releases. The trick won't last. What other names will we try then? Seriously, this is silly and the focus is wrong, and will accomplish nothing but confusing people one more time. Let's start by making rc really "release-candidate", not something with last-minute unpredictable random changes. Why should I test rc when I know the final release will be much different anyway? What is worse is that we actually _complain_ about the fact that people do not take rc seriously, while the release management doesn't take it seriously itself. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [request for inclusion] Filesystem in Userspace
> > Do you have any objections to merging FUSE in mainline kernel? > > > > It's been in -mm for the 2.6.11 cycle, and the same code was released > > a month ago as FUSE-2.2. So it should have received a fair amount of > > testing, with no problems found so far. > > > > The one originally merged into -mm already addressed all major issues > > that people found (most importantly the OOM deadlock thing), and > > though there were some minor changes in the interface since then, I > > feel that the current kernel interface will stand up to the test of > > time. > > > Please give me or some other filesystem person some time to look over > it, there were a few things that looked really fishy. Please do. Although I think the most complex part of FUSE is the device handling, which is not really "filesystem" code. The filesystem part is mostly really straightforward. Still the more people look at it, the better. > And apologies for not having time to look at it earlier, but I'm a little > bit too busy right now. Take your time, I don't want to hurry merging into mainline, but things went very quiet lately on the bug front. Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
On Wed, 2 Mar 2005, Andrew Morton wrote:
> > Any mmap changes requires the mmapsem.
>
> sys_remap_file_pages() will call install_page() under down_read(mmap_sem).
> It relies upon page_table_lock for pte atomicity.
This is not relevant since it only deals with file pages. ptes are only
installed atomically for anonymous memory (if CONFIG_ATOMIC_OPS
is defined).
do_file_page() does call the populate function which does the right thing
in acquiring the page_table_lock before a pte update. My patch does not
touch that.
/*
* Install a file pte to a given virtual memory address, release any
* previously existing mapping.
*/
int install_file_pte(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long addr, unsigned long pgoff, pgprot_t prot)
{
int err = -ENOMEM;
pte_t *pte;
pmd_t *pmd;
pud_t *pud;
pgd_t *pgd;
pte_t pte_val;
pgd = pgd_offset(mm, addr);
spin_lock(>page_table_lock);
pud = pud_alloc(mm, pgd, addr);
if (!pud)
goto err_unlock;
pmd = pmd_alloc(mm, pud, addr);
if (!pmd)
goto err_unlock;
pte = pte_alloc_map(mm, pmd, addr);
if (!pte)
goto err_unlock;
zap_pte(mm, vma, addr, pte);
set_pte(pte, pgoff_to_pte(pgoff));
pte_val = *pte;
pte_unmap(pte);
update_mmu_cache(vma, addr, pte_val);
spin_unlock(>page_table_lock);
return 0;
err_unlock:
spin_unlock(>page_table_lock);
return err;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
On Wed, 2005-03-02 at 21:51 -0800, Christoph Lameter wrote: > On Wed, 2 Mar 2005, David S. Miller wrote: > > > Actually, I guess I could do the pte_cmpxchg() stuff, but only if it's > > used to "add" access. If the TLB miss handler races, we just go into > > the handle_mm_fault() path unnecessarily in order to synchronize. > > > > However, if this pte_cmpxchg() thing is used for removing access, then > > sparc64 can't use it. In such a case a race in the TLB handler would > > result in using an invalid PTE. I could "spin" on some lock bit, but > > there is no way I'm adding instructions to the carefully constructed > > TLB miss handler assembler on sparc64 just for that :-) > > There is no need to provide pte_cmpxchg. If the arch does not support > cmpxchg on ptes (CONFIG_ATOMIC_TABLE_OPS not defined) > then it will fall back to using pte_get_and_clear while holding the > page_table_lock to insure that the entry is not touched while performing > the comparison. Nah, this is wrong :) We actually _want_ pte_cmpxchg on ppc64, because we can do the stuff, but it requires some careful manipulation of some bits in the PTE that are beyond linux common layer understanding :) Like the BUSY bit which is a lock bit for arbitrating with the hash fault handler for example. Also, if it's ever used to cmpxchg from anything but a !present PTE, it will need additional massaging (like the COW case where we just "replace" a PTE with set_pte). We also need to preserve some bits in there that indicate if the PTE was in the hash table and where in the hash so we can flush it afterward. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wed, Mar 02, 2005 at 05:15:36PM -0800, Linus Torvalds wrote: > On Wed, 2 Mar 2005, Greg KH wrote: > > I do understand what you are trying to achieve here, people don't really > > test the -rc releases as much as a "real" 2.6.11 release. Getting a > > week of testing and bugfix only type patches to then release a 2.6.12 > > makes a lot of sense. For example, see all of the bug reports that came > > out of the woodwork today on lkml from the 2.6.11 release... > > A large part of it is psychological. On the other hand, it may be that > Neil is right and it would just mean that people wouldn't even test the > odd releases (..because they want to wait a couple of weeks for the even > one), so it may not actually end up helping much. It's not the same thing to test ONE release and test SEVERAL -rc. I take my case as an example. I don't have enough time to keep up, so I try to compile at least each release and test them on one of my systems, maybe for curiosity. I would like to test the -rc, but the problem is that you don't know how much you can expect this or that -rc to be close to usable. You even expect it to fail or not build at all, so when you don't have much time to spend on this, unfortunately, you don't test them. On the contrary, Marcelo makes a strong difference between -pre and -rc. And when I see a 2.4-rc, I expect it to be a potential candidate, so I try to get some time to compile it just in case I would discover an awful bug, and avoid the 2.6.8 -> 2.6.8.1 situation. Honnestly, I would have reported the 2.6.8 NFS bug earlier if there had been a true -rc before it (=one which does not change except for trivial bug fixes). > The thing is, I _do_ believe the current setup is working reasonably well. > But I also do know that some people (a fairly small group, but anyway) > seem to want an extra level of stability - although those people seem to > not talk so much about "it works" kind of stability, but literally a "we > can't keep up" kind of stability (ie at least a noticeable percentage of > that group is not complaining about crashes, they are complaining about > speed of development). > > And I suspect that _anything_ I do won't make those people happy. The only solution against this is to freeze for real and start the devel tree in parallel. People are not complaining anymore about 2.4 change speed, because every time a folk sends something, we tell him to push that into 2.6 and not 2.4. The same thing must work with 2.6 and 2.7. In the end, there would a general feeling that "2.6 was not as stable as 2.8", etc... That's not a problem, there are always ups and downs in software. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-dev-2.6] ide: ide_dma_intr oops fix
On Thu, Mar 03 2005, Tejun Heo wrote:
> Hello, Bartlomiej.
>
> This patch fixes ide_dma_intr() oops which occurs for TASKFILE ioctl
> using DMA dataphses. This is against the latest ide-dev-2.6 tree +
> all your recent 9 patches.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>
> Index: linux-taskfile-ng/drivers/ide/ide-dma.c
> ===
> --- linux-taskfile-ng.orig/drivers/ide/ide-dma.c 2005-03-03
> 11:59:16.485582413 +0900
> +++ linux-taskfile-ng/drivers/ide/ide-dma.c 2005-03-03 12:00:07.753376048
> +0900
> @@ -175,10 +175,14 @@ ide_startstop_t ide_dma_intr (ide_drive_
> if (OK_STAT(stat,DRIVE_READY,drive->bad_wstat|DRQ_STAT)) {
> if (!dma_stat) {
> struct request *rq = HWGROUP(drive)->rq;
> - ide_driver_t *drv;
>
> - drv = *(ide_driver_t **)rq->rq_disk->private_data;;
> - drv->end_request(drive, 1, rq->nr_sectors);
> + if (rq->rq_disk) {
> + ide_driver_t *drv;
> +
> + drv = *(ide_driver_t
> **)rq->rq_disk->private_data;;
> + drv->end_request(drive, 1, rq->nr_sectors);
> + } else
> + ide_end_request(drive, 1, rq->nr_sectors);
> return ide_stopped;
> }
> printk(KERN_ERR "%s: dma_intr: bad DMA status (dma_stat=%x)\n",
Why not just set rq_disk for taskfile requests as well, seems a lot
cleaner than special casing the end_request handling.
--
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.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
On Wed, Mar 02, 2005 at 01:18:17PM -0800, Andrew Morton wrote: > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > > > Thing is, CRYPTO_AES on only selectable on x86. > > > > You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, > > the dependencies are a bit weird: > > > > config CRYPTO_AES > > tristate "AES cipher algorithms" > > depends on CRYPTO && !(X86 && !X86_64) > > config CRYPTO_AES_586 > > tristate "AES cipher algorithms (i586)" > > depends on CRYPTO && (X86 && !X86_64) > > That's pretty broken, isn't it? > > Would be better to just do: > > config CRYPTO_AES > select CRYPTO_AES_586 if (X86 && !X86_64) > select CRYPTO_AES_OTHER if !(X86 && !X86_64) > > and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0518.html http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0523.html cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] BDI: Provide backing device capability information
David Howells <[EMAIL PROTECTED]> wrote: > > > The attached patch does two things: > > (1) It gets rid of backing_dev_info::memory_backed and replaces it with a > pair of boolean values: > > (*) dirty_memory_acct > > True if the pages associated with this backing device should be > tracked by dirty page accounting. > > (*) writeback_if_dirty > > True if the pages associated with this backing device should have > writepage() or writepages() invoked upon them to clean them. Cool, thanks. > (2) It adds a backing device capability mask that indicates what a backing > device is capable of; currently only in regard to memory mapping > facilities. These flags indicate whether a device can be mapped directly, > whether it can be copied for a mapping, and whether direct mappings can > be read, written and/or executed. This information is primarily aimed at > improving no-MMU private mapping support. > > ... > +#define BDI_CAP_MAP_COPY 0x0001 /* Copy can be mapped > (MAP_PRIVATE) */ > +#define BDI_CAP_MAP_DIRECT 0x0002 /* Can be mapped directly > (MAP_SHARED) */ Why not make these bitfields as well? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, 2 Mar 2005, Andrew Morton wrote: > Kai Makisara <[EMAIL PROTECTED]> wrote: > > > > > > > > v2.6 also contains the same problem BTW. > > > > > > Try this: > > > > > > --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 > > > +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 > > > @@ -3778,7 +3778,6 @@ > > > read: st_read, > > > write: st_write, > > > ioctl: st_ioctl, > > > -llseek: no_llseek, > > > open: st_open, > > > flush: st_flush, > > > release:st_release, > > > > This change covers up the problem. The real bug is in tar. > > In that case we're kinda screwed, and should change the kernel to make tar > work again. We can send a bug report to the tar folks (good luck) and wait > a few years. > > > The first BSF did position the tape correctly although it did fail. > > (what's a BSF?) > > If it positioned the tape successfully, why did it claim that it failed? BSF moves the tape backwards over filemarks. tar tries to move over one filemark. It does not find it because it ends to the beginning of the tape. This is why the operation fails. However, the tape is at the beginning and this is the correct place with regard to what is done next. > If we were to fix that up, would tar then be happy? It is not fixable in the kernel. The beginning of the tape is a special case because there is no filemark. Any application should take this into account. We could fake a filemark there but this would lead to problems because then we could "skip" backwards indefinitely even when the tape moves nowhere. This could confuse other applications. If seek with tape is changed back to returning success, this would enable correct tar --verify at the beginning of the tape. However, I am not sure what happens if we are not at the beginning. I will investigate this and suggest a long term fix to the tar people (a fix that should be compatible with all Unix tape semantics I know) and also suggest possible fixes to st (this may include automatic writing of a filemark when BSF is used after writes). If you think want to make st return success for seeks even if nothing happens (as it did earlier), I don't have anything against that. It would solve the practical problem several people have reported recently. (My recommendation for the people seeing this problem is to do verification separately with 'tar -d'.) -- Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.29 sk98lin patch for Asus K8W SE Deluxe
The EEPROM (or whatever that is) on Asus K8V SE Deluxe motherboards
contains buggy firmware. This buggy firmware has one flipped bit, and
causes the sk98lin driver refuses to work correctly. Please look at
this thread:
http://www.ussg.iu.edu/hypermail/linux/kernel/0404.0/1439.html
It contains a patch for 2.6 that fixs the problem. Enclosed is a copy
of this patch for 2.4.29. Please consider applying.
Phil.
Signed-Off-By: Philippe Troin <[EMAIL PROTECTED]>
diff -ruN linux-2.4.29.orig/drivers/net/sk98lin/skvpd.c
linux-2.4.29/drivers/net/sk98lin/skvpd.c
--- linux-2.4.29.orig/drivers/net/sk98lin/skvpd.c Wed Apr 14 06:05:30 2004
+++ linux-2.4.29/drivers/net/sk98lin/skvpd.cMon Feb 21 02:03:00 2005
@@ -466,6 +466,15 @@
pAC->vpd.vpd_size = vpd_size;
+ /* Asus K8V Se Deluxe bugfix. Correct VPD content */
+ /* MBo April 2004 */
+ if( ((unsigned char)pAC->vpd.vpd_buf[0x3f] == 0x38) &&
+ ((unsigned char)pAC->vpd.vpd_buf[0x40] == 0x3c) &&
+ ((unsigned char)pAC->vpd.vpd_buf[0x41] == 0x45) ) {
+ printk("sk98lin : humm... Asus mainboard with buggy VPD ?
correcting data.\n");
+ (unsigned char)pAC->vpd.vpd_buf[0x40] = 0x38;
+ }
+
/* find the end tag of the RO area */
if (!(r = vpd_find_para(pAC, VPD_RV, ))) {
SK_DBG_MSG(pAC, SK_DBGMOD_VPD, SK_DBGCAT_ERR | SK_DBGCAT_FATAL,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
On Fri, 2005-03-04 at 04:19 +1100, Nick Piggin wrote: > You don't want to do that for all architectures, as I said earlier. > eg. i386 can concurrently set the dirty bit with the MMU (which won't > honour the lock). > > So you then need an atomic lock, atomic pte operations, and atomic > unlock where previously you had only the atomic pte operation. This is > disastrous for performance. Of course, but I was answering to David about sparc64 which uses software TLB load :) Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][9/11] IB/ipoib: small fixes
From: Shirley Ma <[EMAIL PROTECTED]> IPoIB small fixes: Initialize path->ah to NULL, and fix dereference after free of neigh in error path of neigh_add_path(). Signed-off-by: Shirley Ma <[EMAIL PROTECTED]> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> --- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-02 20:26:13.207621227 -0800 +++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-02 20:26:13.653524436 -0800 @@ -346,8 +346,9 @@ if (!path) return NULL; - path->dev = dev; + path->dev = dev; path->pathrec.dlid = 0; + path->ah = NULL; skb_queue_head_init(>queue); @@ -450,8 +451,8 @@ err: *to_ipoib_neigh(skb->dst->neighbour) = NULL; list_del(>list); - kfree(neigh); neigh->neighbour->ops->destructor = NULL; + kfree(neigh); ++priv->stats.tx_dropped; dev_kfree_skb_any(skb); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][8/11] IB/ipoib: rename global symbols
Make IPoIB data_debug_level module parameter static to the single file
where it is used. Also Rename IPoIB module parameter variable from
"debug_level" to "ipoib_debug_level". This avoids possible name
clashes if IPoIB is built into the kernel. We use module_param_named
so that the user-visible parameter names remain the same.
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib.h 2005-03-02
20:26:02.744892334 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib.h 2005-03-02
20:26:13.207621227 -0800
@@ -308,11 +308,11 @@
#ifdef CONFIG_INFINIBAND_IPOIB_DEBUG
-extern int debug_level;
+extern int ipoib_debug_level;
#define ipoib_dbg(priv, format, arg...)\
do {\
- if (debug_level > 0)\
+ if (ipoib_debug_level > 0) \
ipoib_printk(KERN_DEBUG, priv, format , ## arg); \
} while (0)
#define ipoib_dbg_mcast(priv, format, arg...) \
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2005-03-02
20:26:12.514771621 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_ib.c2005-03-02
20:26:13.208621010 -0800
@@ -40,7 +40,7 @@
#include "ipoib.h"
#ifdef CONFIG_INFINIBAND_IPOIB_DEBUG_DATA
-int data_debug_level;
+static int data_debug_level;
module_param(data_debug_level, int, 0644);
MODULE_PARM_DESC(data_debug_level,
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-02
20:26:02.744892334 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-02
20:26:13.207621227 -0800
@@ -51,9 +51,9 @@
MODULE_LICENSE("Dual BSD/GPL");
#ifdef CONFIG_INFINIBAND_IPOIB_DEBUG
-int debug_level;
+int ipoib_debug_level;
-module_param(debug_level, int, 0644);
+module_param_named(debug_level, ipoib_debug_level, int, 0644);
MODULE_PARM_DESC(debug_level, "Enable debug tracing if > 0");
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hweight: typecast return types
Make hweight() macros return unsigned int for 8,16,32 bits,
instead of requiring callers to do that.
drivers/input/joystick/analog.c:414: warning: int format, different type arg
(arg 3)
drivers/input/joystick/analog.c:414: warning: int format, different type arg
(arg 4)
drivers/input/joystick/analog.c:418: warning: int format, different type arg
(arg 4)
Note: does not address parisc, s390, or sparc64...
waiting for comments.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
diffstat:=
include/asm-alpha/bitops.h |6 +++---
include/asm-ia64/bitops.h |6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff -Naurp ./include/asm-alpha/bitops.h~hweight_types
./include/asm-alpha/bitops.h
--- ./include/asm-alpha/bitops.h~hweight_types 2005-03-01 23:38:09.0
-0800
+++ ./include/asm-alpha/bitops.h2005-03-02 12:56:01.746250696 -0800
@@ -353,9 +353,9 @@ static inline unsigned long hweight64(un
return __kernel_ctpop(w);
}
-#define hweight32(x) hweight64((x) & 0xul)
-#define hweight16(x) hweight64((x) & 0xul)
-#define hweight8(x) hweight64((x) & 0xfful)
+#define hweight32(x) (unsigned int) hweight64((x) & 0xul)
+#define hweight16(x) (unsigned int) hweight64((x) & 0xul)
+#define hweight8(x)(unsigned int) hweight64((x) & 0xfful)
#else
static inline unsigned long hweight64(unsigned long w)
{
diff -Naurp ./include/asm-ia64/bitops.h~hweight_types
./include/asm-ia64/bitops.h
--- ./include/asm-ia64/bitops.h~hweight_types 2005-03-01 23:38:38.0
-0800
+++ ./include/asm-ia64/bitops.h 2005-03-02 12:59:27.282004512 -0800
@@ -353,9 +353,9 @@ hweight64 (unsigned long x)
return result;
}
-#define hweight32(x) hweight64 ((x) & 0xul)
-#define hweight16(x) hweight64 ((x) & 0xul)
-#define hweight8(x) hweight64 ((x) & 0xfful)
+#define hweight32(x) (unsigned int) hweight64((x) & 0xul)
+#define hweight16(x) (unsigned int) hweight64((x) & 0xul)
+#define hweight8(x)(unsigned int) hweight64((x) & 0xfful)
#endif /* __KERNEL__ */
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
Christoph Lameter <[EMAIL PROTECTED]> wrote: > > On Wed, 2 Mar 2005, Andrew Morton wrote: > > > > Any mmap changes requires the mmapsem. > > > > sys_remap_file_pages() will call install_page() under down_read(mmap_sem). > > It relies upon page_table_lock for pte atomicity. > > This is not relevant since it only deals with file pages. OK. And CONFIG_DEBUG_PAGEALLOC? > ptes are only > installed atomically for anonymous memory (if CONFIG_ATOMIC_OPS > is defined). It's a shame. A *nice* solution to this problem would address all pte ops and wouldn't have such special cases... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
Benjamin Herrenschmidt wrote: However, if this pte_cmpxchg() thing is used for removing access, then sparc64 can't use it. In such a case a race in the TLB handler would result in using an invalid PTE. I could "spin" on some lock bit, but there is no way I'm adding instructions to the carefully constructed TLB miss handler assembler on sparc64 just for that :-) Can't you add a lock bit in the PTE itself like we do on ppc64 hash refill ? You don't want to do that for all architectures, as I said earlier. eg. i386 can concurrently set the dirty bit with the MMU (which won't honour the lock). So you then need an atomic lock, atomic pte operations, and atomic unlock where previously you had only the atomic pte operation. This is disastrous for performance. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
100% agree with you, Jeff. That's what I wrote in another mail. A real -rc should have only a handful of patches. And even more importantly, the final release MUST be EXACTLY the lastest -rc, without any new surprize. Willy On Wed, Mar 02, 2005 at 11:16:19PM -0500, Jeff Garzik wrote: > The reasons -rcs are not as good as they could be is that they include > more than just bug fixes. Users are discouraged from testing because > they must scan LKML, or guess, which -rc that Linus/Andrew started > getting serious about "bugfixes only." > > With the -pre/-rc scheme, it's clear to users. > > With the even/odd scheme, you just devalue releases. Previously, all > releases were worthy of testing and use. Now, half of them aren't. > > Jeff > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: United States Patent: 6,862,609]
On Wednesday 02 March 2005 23:28, Jeff V. Merkey wrote: >Gene Heskett wrote: >>On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote: >>>Another Linux patent. >> >>And that pretty much says it. Assigned to the Canopy Group. So >> SCO will have yet another lawsuit to threaten us with. If they >> survive the thrashing I've Been Moved will give them at the end of >> the day. > >The way to fight the patents is for Linux developers to file their > own and start >putting down stakes. Play your game your way or get out of Dodge eh? I have opinions on that, but they aren't printable on a public list. But at least we ALL know now who you are STILL working for, don't we? If you were such a gung-ho FOSS fan, it should have been offered to the eff or fsf. It brings up another sore point with me. I'm of the opinion that both copyright, and patent, should be granted to the author/inventor on a non-transferable basis. He could then sell rights to use it for a set period of time, at the end of which it is still his. The present, sell it to the highest bidder situation too often leaves talented folks in the soup lines at the local mission because they were screwed out of the benefits their invention or composition should have brought them. >> Why the hell would I want >> to look at the link in kwrite? > >Talk to the USPTO, they created these links from their website. BTW, > if you check >the verson of web server run on the uspto.gov server, you will > discover it is >Apache on IBM servers and IBM Linux. Ask them why IBM's sofware > outputs links this way. Correction Jeff, you sent that link to the list, and IMNSHO, it was your job to see to it the mimetype was properly set. It was not. -- 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/
[PATCH] procfs: fix printk arg type warning
On sparc32 build, there is a printk format arg-type warning: fs/proc/proc_misc.c:195: warning: long unsigned int format, unsigned int arg (arg 23) I tried to fix it with a change to asm-sparc/vaddrs.h: -#define VMALLOC_START 0xfe60 +#define VMALLOC_START 0xfe60UL -#define VMALLOC_END0xffc0 +#define VMALLOC_END0xffc0UL but that won't fly because the #defines are used in asm code and asm doesn't like the UL suffixes (reported by Bill Irwin). Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> diffstat:= fs/proc/proc_misc.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Naurp ./fs/proc/proc_misc.c~proc_misc_printk ./fs/proc/proc_misc.c --- ./fs/proc/proc_misc.c~proc_misc_printk 2005-03-01 23:37:49.0 -0800 +++ ./fs/proc/proc_misc.c 2005-03-02 20:47:33.305279976 -0800 @@ -189,7 +189,7 @@ static int meminfo_read_proc(char *page, K(allowed), K(committed), K(ps.nr_page_table_pages), - VMALLOC_TOTAL >> 10, + (unsigned long)VMALLOC_TOTAL >> 10, vmi.used >> 10, vmi.largest_chunk >> 10 ); --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ntfs: fix printk format warning (ia64)
ntfs: Fix printk format warnings on ia64:
fs/ntfs/aops.c:947: warning: long long unsigned int format, long int arg (arg 4)
fs/ntfs/debug.c:169: warning: long long unsigned int format, VCN arg (arg 2)
fs/ntfs/debug.c:169: warning: long long unsigned int format, s64 arg (arg 4)
fs/ntfs/debug.c:174: warning: long long unsigned int format, LCN arg (arg 3)
fs/ntfs/debug.c:174: warning: long long unsigned int format, VCN arg (arg 2)
fs/ntfs/debug.c:174: warning: long long unsigned int format, s64 arg (arg 4)
fs/ntfs/inode.c:2517: warning: long long unsigned int format, s64 arg (arg 6)
fs/ntfs/inode.c:2517: warning: long long unsigned int format, s64 arg (arg 7)
fs/ntfs/inode.c:2526: warning: long long unsigned int format, s64 arg (arg 6)
fs/ntfs/inode.c:2526: warning: long long unsigned int format, s64 arg (arg 7)
fs/ntfs/inode.c:2535: warning: long long unsigned int format, s64 arg (arg 6)
fs/ntfs/inode.c:2535: warning: long long unsigned int format, s64 arg (arg 7)
fs/ntfs/lcnalloc.c:759: warning: long long unsigned int format, long unsigned
int arg (arg 6)
fs/ntfs/mft.c:1775: warning: long long int format, s64 arg (arg 5)
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
diffstat:=
fs/ntfs/aops.c |3 ++-
fs/ntfs/debug.c| 15 +--
fs/ntfs/inode.c| 12 ++--
fs/ntfs/lcnalloc.c |2 +-
fs/ntfs/mft.c |2 +-
5 files changed, 19 insertions(+), 15 deletions(-)
diff -Naurp ./fs/ntfs/aops.c~ntfs_printk ./fs/ntfs/aops.c
--- ./fs/ntfs/aops.c~ntfs_printk2005-03-01 23:38:17.0 -0800
+++ ./fs/ntfs/aops.c2005-03-02 10:55:16.759656072 -0800
@@ -949,7 +949,8 @@ lock_retry_remap:
"attribute type 0x%x) because "
"its location on disk could "
"not be determined (error "
- "code %lli).", (s64)block <<
+ "code %lli).",
+ (long long)block <<
bh_size_bits >>
vol->mft_record_size_bits,
ni->mft_no, ni->type,
diff -Naurp ./fs/ntfs/mft.c~ntfs_printk ./fs/ntfs/mft.c
--- ./fs/ntfs/mft.c~ntfs_printk 2005-03-01 23:38:13.0 -0800
+++ ./fs/ntfs/mft.c 2005-03-02 10:58:11.409105320 -0800
@@ -1772,7 +1772,7 @@ static int ntfs_mft_data_extend_allocati
return PTR_ERR(rl);
}
mft_ni->runlist.rl = rl;
- ntfs_debug("Allocated %lli clusters.", nr);
+ ntfs_debug("Allocated %lli clusters.", (long long)nr);
/* Find the last run in the new runlist. */
for (; rl[1].length; rl++)
;
diff -Naurp ./fs/ntfs/lcnalloc.c~ntfs_printk ./fs/ntfs/lcnalloc.c
--- ./fs/ntfs/lcnalloc.c~ntfs_printk2005-03-01 23:38:34.0 -0800
+++ ./fs/ntfs/lcnalloc.c2005-03-02 11:00:07.080520592 -0800
@@ -761,7 +761,7 @@ out:
"could allocate up to 0x%llx "
"clusters.",
(unsigned long long)rl[0].lcn,
- (unsigned long long)count - clusters);
+ (unsigned long long)(count - clusters));
/* Deallocate all allocated clusters. */
ntfs_debug("Attempting rollback...");
err2 = ntfs_cluster_free_from_rl_nolock(vol, rl);
diff -Naurp ./fs/ntfs/inode.c~ntfs_printk ./fs/ntfs/inode.c
--- ./fs/ntfs/inode.c~ntfs_printk 2005-03-01 23:38:26.0 -0800
+++ ./fs/ntfs/inode.c 2005-03-02 11:06:34.090686104 -0800
@@ -2516,8 +2516,8 @@ int ntfs_write_inode(struct inode *vi, i
if (si->last_data_change_time != nt) {
ntfs_debug("Updating mtime for inode 0x%lx: old = 0x%llx, "
"new = 0x%llx", vi->i_ino,
- sle64_to_cpu(si->last_data_change_time),
- sle64_to_cpu(nt));
+ (long
long)sle64_to_cpu(si->last_data_change_time),
+ (long long)sle64_to_cpu(nt));
si->last_data_change_time = nt;
modified = TRUE;
}
@@ -2525,8 +2525,8 @@ int ntfs_write_inode(struct inode *vi, i
if (si->last_mft_change_time != nt) {
ntfs_debug("Updating ctime for inode 0x%lx: old = 0x%llx, "
"new = 0x%llx", vi->i_ino,
- sle64_to_cpu(si->last_mft_change_time),
- sle64_to_cpu(nt));
+ (long
long)sle64_to_cpu(si->last_mft_change_time),
+ (long long)sle64_to_cpu(nt));
si->last_mft_change_time = nt;
Initrd and Initramfs
Hi, For an embedded developers perspective, Is there any other advantage of using initramfs over initrd apart from RAMFS benefits over RAMDISK ? Please CC me Thanks Amol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] isdn: fix gcc data type/size warning
(resend) Fix gcc warning: drivers/isdn/i4l/isdn_ppp.c:1581: warning: large integer implicitly truncated to unsigned type is unsigned int. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> diffstat:= drivers/isdn/i4l/isdn_ppp.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Naurp ./drivers/isdn/i4l/isdn_ppp.c~isdn_types ./drivers/isdn/i4l/isdn_ppp.c --- ./drivers/isdn/i4l/isdn_ppp.c~isdn_types2004-12-24 13:35:01.0 -0800 +++ ./drivers/isdn/i4l/isdn_ppp.c 2005-01-10 12:27:37.645551176 -0800 @@ -1578,7 +1578,7 @@ static int isdn_ppp_mp_init( isdn_net_lo lp->next = lp->last = lp; /* nobody else in a queue */ lp->netdev->pb->frags = NULL; lp->netdev->pb->frames = 0; - lp->netdev->pb->seq = LONG_MAX; + lp->netdev->pb->seq = UINT_MAX; } lp->netdev->pb->ref_ct++; --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][7/11] IB/ipoib: use list_for_each_entry_safe when required
From: Shirley Ma <[EMAIL PROTECTED]>
Change uses of list_for_each_entry() where the loop variable is freed
inside the loop to list_for_each_entry_safe().
Signed-off-by: Shirley Ma <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
2005-03-02 20:26:02.832873236 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 2005-03-02
20:26:12.799709771 -0800
@@ -790,7 +790,7 @@
spin_unlock_irqrestore(>lock, flags);
- list_for_each_entry(mcast, _list, list) {
+ list_for_each_entry_safe(mcast, tmcast, _list, list) {
ipoib_mcast_leave(dev, mcast);
ipoib_mcast_free(mcast);
}
@@ -902,7 +902,7 @@
spin_unlock_irqrestore(>lock, flags);
/* We have to cancel outside of the spinlock */
- list_for_each_entry(mcast, _list, list) {
+ list_for_each_entry_safe(mcast, tmcast, _list, list) {
ipoib_mcast_leave(mcast->dev, mcast);
ipoib_mcast_free(mcast);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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
On Wed, 2 Mar 2005 21:08:07 -0800 Russell Miller <[EMAIL PROTECTED]> wrote: > How do you know that they won't stop the announcements if this change is made? Nobody knows such things for sure, let's test it and find out :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][11/11] IB/ipoib: fix locking on path deletion
Fix up locking for IPoIB path table. Make sure that destruction of
address handles, neighbour info and path structs is locked properly to
avoid races and deadlocks. (Problem originally diagnosed by Shirley Ma)
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-02
20:26:13.977454122 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-02
20:26:14.301383808 -0800
@@ -215,16 +215,25 @@
return 0;
}
-static void __path_free(struct net_device *dev, struct ipoib_path *path)
+static void path_free(struct net_device *dev, struct ipoib_path *path)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_neigh *neigh, *tn;
struct sk_buff *skb;
+ unsigned long flags;
while ((skb = __skb_dequeue(>queue)))
dev_kfree_skb_irq(skb);
+ spin_lock_irqsave(>lock, flags);
+
list_for_each_entry_safe(neigh, tn, >neigh_list, list) {
+ /*
+* It's safe to call ipoib_put_ah() inside priv->lock
+* here, because we know that path->ah will always
+* hold one more reference, so ipoib_put_ah() will
+* never do more than decrement the ref count.
+*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
*to_ipoib_neigh(neigh->neighbour) = NULL;
@@ -232,11 +241,11 @@
kfree(neigh);
}
+ spin_unlock_irqrestore(>lock, flags);
+
if (path->ah)
ipoib_put_ah(path->ah);
- rb_erase(>rb_node, >path_tree);
- list_del(>list);
kfree(path);
}
@@ -248,15 +257,20 @@
unsigned long flags;
spin_lock_irqsave(>lock, flags);
+
list_splice(>path_list, _list);
INIT_LIST_HEAD(>path_list);
+
+ list_for_each_entry(path, _list, list)
+ rb_erase(>rb_node, >path_tree);
+
spin_unlock_irqrestore(>lock, flags);
list_for_each_entry_safe(path, tp, _list, list) {
if (path->query)
ib_sa_cancel_query(path->query_id, path->query);
wait_for_completion(>done);
- __path_free(dev, path);
+ path_free(dev, path);
}
}
@@ -361,8 +375,6 @@
path->pathrec.pkey = cpu_to_be16(priv->pkey);
path->pathrec.numb_path = 1;
- __path_add(dev, path);
-
return path;
}
@@ -422,6 +434,8 @@
(union ib_gid *)
(skb->dst->neighbour->ha + 4));
if (!path)
goto err;
+
+ __path_add(dev, path);
}
list_add_tail(>list, >neigh_list);
@@ -497,8 +511,12 @@
skb_push(skb, sizeof *phdr);
__skb_queue_tail(>queue, skb);
- if (path_rec_start(dev, path))
- __path_free(dev, path);
+ if (path_rec_start(dev, path)) {
+ spin_unlock(>lock);
+ path_free(dev, path);
+ return;
+ } else
+ __path_add(dev, path);
} else {
++priv->stats.tx_dropped;
dev_kfree_skb_any(skb);
@@ -658,7 +676,7 @@
static void ipoib_neigh_destructor(struct neighbour *n)
{
- struct ipoib_neigh *neigh = *to_ipoib_neigh(n);
+ struct ipoib_neigh *neigh;
struct ipoib_dev_priv *priv = netdev_priv(n->dev);
unsigned long flags;
struct ipoib_ah *ah = NULL;
@@ -670,6 +688,7 @@
spin_lock_irqsave(>lock, flags);
+ neigh = *to_ipoib_neigh(n);
if (neigh) {
if (neigh->ah)
ah = neigh->ah;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][10/11] IB/ipoib: don't call ipoib_put_ah with lock held
From: Shirley Ma <[EMAIL PROTECTED]>
ipoib_put_ah() may call ipoib_free_ah(), which might take the device's
lock. Therefore we need to make sure we don't call ipoib_put_ah()
when holding the lock already.
Signed-off-by: Shirley Ma <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-02
20:26:13.653524436 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-02
20:26:13.977454122 -0800
@@ -661,6 +661,7 @@
struct ipoib_neigh *neigh = *to_ipoib_neigh(n);
struct ipoib_dev_priv *priv = netdev_priv(n->dev);
unsigned long flags;
+ struct ipoib_ah *ah = NULL;
ipoib_dbg(priv,
"neigh_destructor for %06x " IPOIB_GID_FMT "\n",
@@ -671,13 +672,16 @@
if (neigh) {
if (neigh->ah)
- ipoib_put_ah(neigh->ah);
+ ah = neigh->ah;
list_del(>list);
*to_ipoib_neigh(n) = NULL;
kfree(neigh);
}
spin_unlock_irqrestore(>lock, flags);
+
+ if (ah)
+ ipoib_put_ah(ah);
}
static int ipoib_neigh_setup(struct neighbour *neigh)
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
2005-03-02 20:26:12.799709771 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 2005-03-02
20:26:13.977454122 -0800
@@ -93,6 +93,8 @@
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_neigh *neigh, *tmp;
unsigned long flags;
+ LIST_HEAD(ah_list);
+ struct ipoib_ah *ah, *tah;
ipoib_dbg_mcast(netdev_priv(dev),
"deleting multicast group " IPOIB_GID_FMT "\n",
@@ -101,7 +103,8 @@
spin_lock_irqsave(>lock, flags);
list_for_each_entry_safe(neigh, tmp, >neigh_list, list) {
- ipoib_put_ah(neigh->ah);
+ if (neigh->ah)
+ list_add_tail(>ah->list, _list);
*to_ipoib_neigh(neigh->neighbour) = NULL;
neigh->neighbour->ops->destructor = NULL;
kfree(neigh);
@@ -109,6 +112,9 @@
spin_unlock_irqrestore(>lock, flags);
+ list_for_each_entry_safe(ah, tah, _list, list)
+ ipoib_put_ah(ah);
+
if (mcast->ah)
ipoib_put_ah(mcast->ah);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][4/11] IB/mthca: add missing break
Add missing break statements in switch in mthca_profile.c (pointed out by Michael Tsirkin). Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> --- linux-export.orig/drivers/infiniband/hw/mthca/mthca_profile.c 2005-03-02 20:26:03.023831785 -0800 +++ linux-export/drivers/infiniband/hw/mthca/mthca_profile.c2005-03-02 20:26:11.904904003 -0800 @@ -241,10 +241,12 @@ case MTHCA_RES_UDAV: dev->av_table.ddr_av_base = profile[i].start; dev->av_table.num_ddr_avs = profile[i].num; + break; case MTHCA_RES_UARC: init_hca->uarc_base = profile[i].start; init_hca->log_uarc_sz = ffs(request->uarc_size) - 13; init_hca->log_uar_sz = ffs(request->num_uar) - 1; + break; default: break; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][6/11] IB/ipoib: fix rx memory leak
Fix memory leak when posting a receive buffer (pointed out by Shirley Ma).
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2005-03-02
20:26:02.919854355 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_ib.c2005-03-02
20:26:12.514771621 -0800
@@ -137,6 +137,9 @@
if (ret) {
ipoib_warn(priv, "ipoib_ib_receive failed for buf %d (%d)\n",
id, ret);
+ dma_unmap_single(priv->ca->dma_device, addr,
+IPOIB_BUF_SIZE, DMA_FROM_DEVICE);
+ dev_kfree_skb_any(skb);
priv->rx_ring[id].skb = NULL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
On Wed, 2 Mar 2005, David S. Miller wrote: > Actually, I guess I could do the pte_cmpxchg() stuff, but only if it's > used to "add" access. If the TLB miss handler races, we just go into > the handle_mm_fault() path unnecessarily in order to synchronize. > > However, if this pte_cmpxchg() thing is used for removing access, then > sparc64 can't use it. In such a case a race in the TLB handler would > result in using an invalid PTE. I could "spin" on some lock bit, but > there is no way I'm adding instructions to the carefully constructed > TLB miss handler assembler on sparc64 just for that :-) There is no need to provide pte_cmpxchg. If the arch does not support cmpxchg on ptes (CONFIG_ATOMIC_TABLE_OPS not defined) then it will fall back to using pte_get_and_clear while holding the page_table_lock to insure that the entry is not touched while performing the comparison. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
> However, if this pte_cmpxchg() thing is used for removing access, then > sparc64 can't use it. In such a case a race in the TLB handler would > result in using an invalid PTE. I could "spin" on some lock bit, but > there is no way I'm adding instructions to the carefully constructed > TLB miss handler assembler on sparc64 just for that :-) Can't you add a lock bit in the PTE itself like we do on ppc64 hash refill ? Ok, ok, you don't want to add instructions, fair enough :) On ppc64, I had to do that to close some nasty race we had in the hash refill, but it came almost for free as we already had an atomic loop in there. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][3/11] IB: sparse fixes
From: Tom Duffy <[EMAIL PROTECTED]>
Fix some sparse warnings by making sure we have appropriate "extern"
declarations visible.
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock (<[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/core/agent.c 2005-03-02
20:26:10.599187430 -0800
+++ linux-export/drivers/infiniband/core/agent.c2005-03-02
20:26:11.456001445 -0800
@@ -45,14 +45,11 @@
#include "smi.h"
#include "agent_priv.h"
#include "mad_priv.h"
-
+#include "agent.h"
spinlock_t ib_agent_port_list_lock;
static LIST_HEAD(ib_agent_port_list);
-extern kmem_cache_t *ib_mad_cache;
-
-
/*
* Caller must hold ib_agent_port_list_lock
*/
--- linux-export.orig/drivers/infiniband/core/cache.c 2005-03-02
20:26:03.085818330 -0800
+++ linux-export/drivers/infiniband/core/cache.c2005-03-02
20:26:11.456001445 -0800
@@ -37,6 +37,8 @@
#include
#include
+#include
+
#include "core_priv.h"
struct ib_pkey_cache {
--- linux-export.orig/drivers/infiniband/core/mad_priv.h2005-03-02
20:26:10.980104746 -0800
+++ linux-export/drivers/infiniband/core/mad_priv.h 2005-03-02
20:26:11.457001228 -0800
@@ -192,4 +192,6 @@
struct ib_mad_qp_info qp_info[IB_MAD_QPS_CORE];
};
+extern kmem_cache_t *ib_mad_cache;
+
#endif /* __IB_MAD_PRIV_H__ */
--- linux-export.orig/drivers/infiniband/core/smi.c 2005-03-02
20:26:03.085818330 -0800
+++ linux-export/drivers/infiniband/core/smi.c 2005-03-02 20:26:11.458001011
-0800
@@ -37,7 +37,7 @@
*/
#include
-
+#include "smi.h"
/*
* Fixup a directed route SMP for sending
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc4-mm1] connector: Add a fork connector
On Thu, Mar 03, 2005 at 12:18:25PM +0900, Kaigai Kohei ([EMAIL PROTECTED])
wrote:
> Hello, Guillaume
>
> I tried to measure the process-creation/destruction performance on
> 2.6.11-rc4-mm1 plus
> some extensiton(Normal/with PAGG/with Fork-Connector).
> But I received a following messages endlessly on system console with
> Fork-Connector extensiton.
>
> # on IA-64 environment / When an simple fork() iteration is run in parallel.
> skb does not have enough length: requested msg->len=10[28],
> nlh->nlmsg_len=48[32], skb->len=48[must be 30].
> skb does not have enough length: requested msg->len=10[28],
> nlh->nlmsg_len=48[32], skb->len=48[must be 30].
> skb does not have enough length: requested msg->len=10[28],
> nlh->nlmsg_len=48[32], skb->len=48[must be 30].
> :
>
> Is's generated at drivers/connector/connector.c:__cn_rx_skb(), and this warn
> the length of msg's payload
> does not fit in nlmsghdr's length.
> This message means netlink packet is not sent to user space.
> I was notified occurence of fork() by printk(). :-(
No, lengths are correct, but skb can be dropped due to misaligned sizes check.
> The attached simple *.c file can enable/disable fork-connector and listen the
> fork-notification.
> Because It's first experimence for me to write a code to use netlink, point
> out a right how-to-use
> if there's some mistakes at user side apprication.
>
> Thanks.
>
> P.S. I can't reproduce lockup on 367th-fork() with your latest patch.
I've sent that patch to Guillaume and upstream, hopefully it will be
integrated into next -mm release.
> Guillaume Thouvenin wrote:
> > ChangeLog:
> >
> > - Add parenthesis around sizeof(struct cn_msg) + CN_FORK_INFO_SIZE
> > in the CN_FORK_MSG_SIZE macro
> > - fork_cn_lock is declareed with DEFINE_SPINLOCK()
> > - fork_cn_lock is defined as static and local to fork_connector()
> > - Create a specific module cn_fork.c in drivers/connector to
> > register the callback.
> > - Improve the callback that turns on/off the fork connector
> >
> > I also run the lmbench and results are send in response to another
> > thread "A common layer for Accounting packages". When fork connector is
> > turned off the overhead is negligible. This patch works with another
> > small patch that fix a problem in the connector. Without it, there is a
> > message that says "skb does not have enough length". It will be fix in
> > the next -mm tree I think.
> >
> >
> > Thanks everyone for the comments,
> > Guillaume
>
> --
> Linux Promotion Center, NEC
> KaiGai Kohei <[EMAIL PROTECTED]>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> void usage(){
> puts("usage: fclisten ");
> puts(" Default -> listening fork-connector");
> puts(" on -> fork-connector Enable");
> puts(" off -> fork-connector Disable");
> exit(0);
> }
>
> #define MODE_LISTEN (1)
> #define MODE_ENABLE (2)
> #define MODE_DISABLE (3)
>
> struct cb_id
> {
> __u32 idx;
> __u32 val;
> };
>
> struct cn_msg
> {
> struct cb_idid;
> __u32 seq;
> __u32 ack;
> __u32 len;/* Length of the following data */
> __u8data[0];
> };
>
>
> int main(int argc, char *argv[]){
> char buf[4096];
> int mode, sockfd, len;
> struct sockaddr_nl ad;
> struct nlmsghdr *hdr = (struct nlmsghdr *)buf;
> struct cn_msg *msg = (struct cn_msg *)(buf+sizeof(struct nlmsghdr));
>
> switch(argc){
> case 1:
> mode = MODE_LISTEN;
> break;
> case 2:
> if (strcasecmp("on",argv[1])==0) {
> mode = MODE_ENABLE;
> }else if (strcasecmp("off",argv[1])==0){
> mode = MODE_DISABLE;
> }else{
> usage();
> }
> break;
> default:
> usage();
> break;
> }
>
> if( (sockfd=socket(PF_NETLINK, SOCK_RAW, NETLINK_NFLOG)) < 0 ){
> fprintf(stderr, "Fault on socket().\n");
> return( 1 );
> }
> ad.nl_family = AF_NETLINK;
> ad.nl_pad = 0;
> ad.nl_pid = getpid();
> ad.nl_groups = -1;
Group should be CN_FORK_IDX to receive only fork's messages.
> if( bind(sockfd, (struct sockaddr *), sizeof(ad)) ){
> fprintf(stderr, "Fault on bind to netlink.\n");
> return( 2 );
> }
>
> if (mode==MODE_LISTEN) {
> while(-1){
> len = recvfrom(sockfd, buf, 4096, 0, NULL, NULL);
> printf("%d-byte recv Seq=%d\n", len, hdr->nlmsg_seq);
> }
> }else{
> ad.nl_family = AF_NETLINK;
> ad.nl_pad = 0;
> ad.nl_pid = 0;
> ad.nl_groups = 1;
>
> hdr->nlmsg_len = sizeof(struct nlmsghdr) + sizeof(struct cn_msg) +
> sizeof(int);
> hdr->nlmsg_type = 0;
> hdr->nlmsg_flags = 0;
> hdr->nlmsg_seq = 0;
> hdr->nlmsg_pid = getpid();
> msg->id.idx = 0xfeed;
> msg->id.val = 0xbeef;
> msg->seq = msg->ack = 0;
> msg->len = sizeof(int);
>
> if (mode==MODE_ENABLE){
> (*(int
[PATCH][2/11] IB: fix vendor MAD deregistration
From: Shahar Frank <[EMAIL PROTECTED]>
Fix bug when deregistering a vendor class MAD agent.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/core/mad.c 2005-03-02
20:26:03.185796628 -0800
+++ linux-export/drivers/infiniband/core/mad.c 2005-03-02 20:26:10.980104746
-0800
@@ -41,7 +41,6 @@
#include "smi.h"
#include "agent.h"
-
MODULE_LICENSE("Dual BSD/GPL");
MODULE_DESCRIPTION("kernel IB MAD API");
MODULE_AUTHOR("Hal Rosenstock");
@@ -490,6 +489,7 @@
cancel_mads(mad_agent_priv);
port_priv = mad_agent_priv->qp_info->port_priv;
+
cancel_delayed_work(_agent_priv->timed_work);
flush_workqueue(port_priv->wq);
@@ -1266,12 +1266,12 @@
}
port_priv = agent_priv->qp_info->port_priv;
+ mgmt_class = convert_mgmt_class(agent_priv->reg_req->mgmt_class);
class = port_priv->version[
agent_priv->reg_req->mgmt_class_version].class;
if (!class)
goto vendor_check;
- mgmt_class = convert_mgmt_class(agent_priv->reg_req->mgmt_class);
method = class->method_table[mgmt_class];
if (method) {
/* Remove any methods for this mad agent */
@@ -1293,16 +1293,21 @@
}
vendor_check:
+ if (!is_vendor_class(mgmt_class))
+ goto out;
+
+ /* normalize mgmt_class to vendor range 2 */
+ mgmt_class = vendor_class_index(agent_priv->reg_req->mgmt_class);
vendor = port_priv->version[
agent_priv->reg_req->mgmt_class_version].vendor;
+
if (!vendor)
goto out;
- mgmt_class = vendor_class_index(agent_priv->reg_req->mgmt_class);
vendor_class = vendor->vendor_class[mgmt_class];
if (vendor_class) {
index = find_vendor_oui(vendor_class, agent_priv->reg_req->oui);
- if (index == -1)
+ if (index < 0)
goto out;
method = vendor_class->method_table[index];
if (method) {
--- linux-export.orig/drivers/infiniband/core/mad_priv.h2005-03-02
20:26:03.185796628 -0800
+++ linux-export/drivers/infiniband/core/mad_priv.h 2005-03-02
20:26:10.980104746 -0800
@@ -58,8 +58,8 @@
#define MAX_MGMT_CLASS 80
#define MAX_MGMT_VERSION 8
#define MAX_MGMT_OUI 8
-#define MAX_MGMT_VENDOR_RANGE2 IB_MGMT_CLASS_VENDOR_RANGE2_END - \
- IB_MGMT_CLASS_VENDOR_RANGE2_START + 1
+#define MAX_MGMT_VENDOR_RANGE2 (IB_MGMT_CLASS_VENDOR_RANGE2_END - \
+ IB_MGMT_CLASS_VENDOR_RANGE2_START + 1)
struct ib_mad_list_head {
struct list_head list;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
On Wed, 2 Mar 2005, Andrew Morton wrote: > > There should be no change to these arches > > But we must at least confirm that these architectures can make these > changes in the future. If they make no changes then they haven't > benefitted from the patch. And the patch must be suitable for all > architectures which might hit this scalability problem. > > > Could we at least get the first two patches in? I can then gradually > > address the other issues piece by piece. > > The atomic ops patch should be coupled with the main patch series. The mm > counter one we could sneak in beforehand, I guess. The atomic ops patch basically just avoids doing a pte_clear and then setting the pte for archs that define CONFIG_ATOMIC_TABLE_OPS. This is unecessary on ia64 and ia32 AFAIK. > > > The necessary more sweeping design change can be found at > > > > http://marc.theaimsgroup.com/?l=linux-kernel=110922543030922=2 > > > > but these may be a long way off. > > Yes, that seemed sensible, although it may not work out to be as clean as > it appears. Of course. But at least we would like to start as clean as possible. > But how would that work allow us to address page_table_lock scalability > problems? Because the actual locking method is abstracted in a transaction (idea by Nick Piggins, I just tried to make it cleaner). The arch may use pte locking, pmd locking, atomic ops or whatever to provide synchronization for page table operations. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
Christoph Lameter <[EMAIL PROTECTED]> wrote: > > On Wed, 2 Mar 2005, Andrew Morton wrote: > > > Have the ppc64 and sparc64 people reviewed and acked the change? (Not a > > facetious question - I just haven't been following the saga sufficiently > > closely to remember). > > There should be no change to these arches But we must at least confirm that these architectures can make these changes in the future. If they make no changes then they haven't benefitted from the patch. And the patch must be suitable for all architectures which might hit this scalability problem. > > > Because if a pte is locked it should not be used. > > > > Confused. Why not just spin on the lock in the normal manner? > > I thought you wanted to lock the pte? This is realized through a lock bit > in the pte. If that lock bit is set one should not use the pte. Otherwise > the lock is bypassed. Or are you proposing a write lock only? I was suggesting a lock in (or associated with) the pageframe of the page which holds the pte. That's just a convenient way of hashing the locking. Probably that's not much different from the atomic pte ops. > > If the other relvant architecture people say "we can use this" then perhaps > > we should grin and bear it. But one does wonder whether some more sweeping > > design change is needed. > > Could we at least get the first two patches in? I can then gradually > address the other issues piece by piece. The atomic ops patch should be coupled with the main patch series. The mm counter one we could sneak in beforehand, I guess. > The necessary more sweeping design change can be found at > > http://marc.theaimsgroup.com/?l=linux-kernel=110922543030922=2 > > but these may be a long way off. Yes, that seemed sensible, although it may not work out to be as clean as it appears. But how would that work allow us to address page_table_lock scalability problems? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
On Thu, 3 Mar 2005 16:00:10 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote: > Andrew Morton writes: > > > But if the approach which these patches take is not suitable for these > > architectures then they have no solution to the scalability problem. The > > machines will perform suboptimally and more (perhaps conflicting) > > development will be needed. > > We can do a pte_cmpxchg on ppc64. We really can't make use of this on sparc64. Unlike ppc64 I don't have the hash table issue (although sparc64 TLB's have a hash lookup helping mechanism in hardware, which we ignore since virtually mapped linear page tables are faster than Sun's bogus TSB table scheme). I make all real faults go through the handle_mm_fault() path so all page table modifications are serialized by the page table lock. The TLB miss handlers never modify PTEs, not even to update access and dirty bits. Actually, I guess I could do the pte_cmpxchg() stuff, but only if it's used to "add" access. If the TLB miss handler races, we just go into the handle_mm_fault() path unnecessarily in order to synchronize. However, if this pte_cmpxchg() thing is used for removing access, then sparc64 can't use it. In such a case a race in the TLB handler would result in using an invalid PTE. I could "spin" on some lock bit, but there is no way I'm adding instructions to the carefully constructed TLB miss handler assembler on sparc64 just for that :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Dave Jones wrote: On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote: > Dave Jones <[EMAIL PROTECTED]> wrote: > > > > On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote: > > > > > I would not keep regular driver updates from a 2.6. thing. > > > > Then the notion of it being stable is bogus, given how many regressions > > the last few kernels have brought in drivers. Moving from 2.6.9 -> 2.6.10 > > broke ALSA, USB, parport, firewire, and countless other little bits and > > pieces that users tend to notice. > > Grump. Have all these regressions received the appropriate level of > visibility on this mailing list? For the most part these things are usually known about by their upstream authors. To give an example: ALSA update in 2.6.10 broke sound for a bunch of IBM thinkpads. As it turns out there are quite a lot of these out there, so when I released a 2.6.10 update for Fedora, bugzilla lit up like a christmas tree with "Hey, where'd my sound go?" reports. (It was further confused by a load of other sound card problems, but thats another issue). This got so out of control, Alan asked the ALSA folks to take a look, and iirc Takashi figured out what had caused the problem, and it got fixed in the ALSA folks tree, and subsequently, in 2.6.11rc. Now, during all this time, there hadn't been any reports of this problem at all on Linux-kernel. Not even from Linus' tree, let alone -mm. Which amazes me given how widespread the problem was. > I too am a little put off by the number of regressions which certain > (admittedly tricky) subsystems keep on introducing. One does wonder how > careful people are being at the development stage. And that's a thing > which we can surely fix. > For example, here's today's crop (so far): > > include/linux/soundcard.h:195: warning: `_PATCHKEY' redefined > include/linux/awe_voice.h:33: warning: this is the location of the previous definition compile time regressions we should be able to nail down fairly easily. (someone from OSDL is already doing compile stats and such on each release [too bad they're mostly incomprehensible to the casual viewer]) The bigger problem is runtime testing. If things aren't getting the exposure they need, we're going to get screwed over by something or other every time Linus bk pull's some random driver repo. I'll ding the OSDL release builder about that (I agree with you) -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][1/11] IB: simplify MAD code
From: Hal Rosenstock <[EMAIL PROTECTED]>
Remove unneeded MAD agent registration by using a single agent for
both directed-route and LID-routed MADs.
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/core/agent.c 2005-03-02
20:26:03.280776011 -0800
+++ linux-export/drivers/infiniband/core/agent.c2005-03-02
20:26:10.599187430 -0800
@@ -66,14 +66,13 @@
if (device) {
list_for_each_entry(entry, _agent_port_list, port_list) {
- if (entry->dr_smp_agent->device == device &&
+ if (entry->smp_agent->device == device &&
entry->port_num == port_num)
return entry;
}
} else {
list_for_each_entry(entry, _agent_port_list, port_list) {
- if ((entry->dr_smp_agent == mad_agent) ||
- (entry->lr_smp_agent == mad_agent) ||
+ if ((entry->smp_agent == mad_agent) ||
(entry->perf_mgmt_agent == mad_agent))
return entry;
}
@@ -111,7 +110,7 @@
return 1;
}
- return smi_check_local_smp(port_priv->dr_smp_agent, smp);
+ return smi_check_local_smp(port_priv->smp_agent, smp);
}
static int agent_mad_send(struct ib_mad_agent *mad_agent,
@@ -231,10 +230,8 @@
/* Get mad agent based on mgmt_class in MAD */
switch (mad->mad.mad.mad_hdr.mgmt_class) {
case IB_MGMT_CLASS_SUBN_DIRECTED_ROUTE:
- mad_agent = port_priv->dr_smp_agent;
- break;
case IB_MGMT_CLASS_SUBN_LID_ROUTED:
- mad_agent = port_priv->lr_smp_agent;
+ mad_agent = port_priv->smp_agent;
break;
case IB_MGMT_CLASS_PERF_MGMT:
mad_agent = port_priv->perf_mgmt_agent;
@@ -284,7 +281,6 @@
{
int ret;
struct ib_agent_port_private *port_priv;
- struct ib_mad_reg_req reg_req;
unsigned long flags;
/* First, check if port already open for SMI */
@@ -308,35 +304,19 @@
spin_lock_init(_priv->send_list_lock);
INIT_LIST_HEAD(_priv->send_posted_list);
- /* Obtain MAD agent for directed route SM class */
- reg_req.mgmt_class = IB_MGMT_CLASS_SUBN_DIRECTED_ROUTE;
- reg_req.mgmt_class_version = 1;
-
- port_priv->dr_smp_agent = ib_register_mad_agent(device, port_num,
- IB_QPT_SMI,
- NULL, 0,
- _send_handler,
- NULL, NULL);
+ /* Obtain send only MAD agent for SM class (SMI QP) */
+ port_priv->smp_agent = ib_register_mad_agent(device, port_num,
+IB_QPT_SMI,
+NULL, 0,
+ _send_handler,
+NULL, NULL);
- if (IS_ERR(port_priv->dr_smp_agent)) {
- ret = PTR_ERR(port_priv->dr_smp_agent);
+ if (IS_ERR(port_priv->smp_agent)) {
+ ret = PTR_ERR(port_priv->smp_agent);
goto error2;
}
- /* Obtain MAD agent for LID routed SM class */
- reg_req.mgmt_class = IB_MGMT_CLASS_SUBN_LID_ROUTED;
- port_priv->lr_smp_agent = ib_register_mad_agent(device, port_num,
- IB_QPT_SMI,
- NULL, 0,
- _send_handler,
- NULL, NULL);
- if (IS_ERR(port_priv->lr_smp_agent)) {
- ret = PTR_ERR(port_priv->lr_smp_agent);
- goto error3;
- }
-
- /* Obtain MAD agent for PerfMgmt class */
- reg_req.mgmt_class = IB_MGMT_CLASS_PERF_MGMT;
+ /* Obtain send only MAD agent for PerfMgmt class (GSI QP) */
port_priv->perf_mgmt_agent = ib_register_mad_agent(device, port_num,
IB_QPT_GSI,
NULL, 0,
@@ -344,15 +324,15 @@
NULL, NULL);
if (IS_ERR(port_priv->perf_mgmt_agent)) {
ret = PTR_ERR(port_priv->perf_mgmt_agent);
- goto error4;
+ goto error3;
}
- port_priv->mr = ib_get_dma_mr(port_priv->dr_smp_agent->qp->pd,
+ port_priv->mr = ib_get_dma_mr(port_priv->smp_agent->qp->pd,
[PATCH][5/11] IB/mthca: fix reset value endianness
MTHCA_RESET_VALUE must always be swapped, since the HCA expects to see it in big-endian order and we write it with writel. This means on little-endian systems we have to swap it to big-endian order before writing, and on big-endian systems we need to swap it to make up for the additional swap that writel will do. This fixes resetting the HCA on big-endian machines. Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> --- linux-export.orig/drivers/infiniband/hw/mthca/mthca_reset.c 2005-03-02 20:26:02.970843287 -0800 +++ linux-export/drivers/infiniband/hw/mthca/mthca_reset.c 2005-03-02 20:26:12.219835642 -0800 @@ -50,7 +50,7 @@ struct pci_dev *bridge = NULL; #define MTHCA_RESET_OFFSET 0xf0010 -#define MTHCA_RESET_VALUE cpu_to_be32(1) +#define MTHCA_RESET_VALUE swab32(1) /* * Reset the chip. This is somewhat ugly because we have to - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][0/11] InfiniBand fixes
Here is a batch of fixes from the OpenIB subversion tree for merging. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
On Wed, Mar 02, 2005 at 07:46:05AM -0800, Linus Torvalds wrote: > (In contrast the full ChangeLog was missing because the generation script > I use is not exactly the smart way, so it's O(slow(n)), where slow is n**3 > or worse, so the log from the last -rc release is fast, but going back all > the way to 2.6.10 took long long enough that I didn't wait for it). Is there some reason why bk changes -aem -rv2.6.10..+ | shortlog isn't sufficient? I'd guess your script will want to calculate the 2.6.10 part automatically, but that seems to run in a second or so on my machine, from a largely cold cache. I *think* this gets all the changes where a -d (date) based method gets very confused by parallel trees. Am I missing something? -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
Andrew Morton wrote: Christoph Lameter <[EMAIL PROTECTED]> wrote: On Wed, 2 Mar 2005, Andrew Morton wrote: Earlier releases back in September 2004 had some pte locking code (and AFAIK Nick also played around with pte locking) but that was less efficient than atomic operations. How much less efficient? Does anyone else have that code around? Nick may have some data. It got far too complicated too fast when I tried to introduce locking for individual ptes. It required bit spinlocks for the pte meaning multiple atomic operations. One could add a spinlock to the pageframe, or use hashed spinlocking. I did have a version using bit spin locks in the pte on ia64. That only works efficiently on architectures who's MMU hardware won't concurrently update the pte (so you can do non-atomic pte operations and non-atomic unlocks on a locked pte). I pretty much solved all the efficiency problems IIRC. Of course this doesn't work on i386 or x86_64. Having a spinlock for example per pte page might be another good option that we haven't looked at. One would have to check for the lock being active leading to significant code changes. Why? When using per-pte locks on ia64 for example, the low level code that walks page tables and sets dirty, accessed, etc bits needs to be made aware of the pte lock. But Keith made me up a little patch to do this, and it is pretty simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
On Wed, 2 Mar 2005, Andrew Morton wrote: > Have the ppc64 and sparc64 people reviewed and acked the change? (Not a > facetious question - I just haven't been following the saga sufficiently > closely to remember). There should be no change to these arches > > Because if a pte is locked it should not be used. > > Confused. Why not just spin on the lock in the normal manner? I thought you wanted to lock the pte? This is realized through a lock bit in the pte. If that lock bit is set one should not use the pte. Otherwise the lock is bypassed. Or are you proposing a write lock only? > If the other relvant architecture people say "we can use this" then perhaps > we should grin and bear it. But one does wonder whether some more sweeping > design change is needed. Could we at least get the first two patches in? I can then gradually address the other issues piece by piece. The necessary more sweeping design change can be found at http://marc.theaimsgroup.com/?l=linux-kernel=110922543030922=2 but these may be a long way off. These patches address an urgent issue that we have with higher CPU counts for a long time and the method used here has been used for years in our ProPack line. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
On Thu, 3 Mar 2005, Paul Mackerras wrote: > More generally, I would be interested to know what sorts of > applications or benchmarks show scalability problems on large machines > due to contention on mm->page_table_lock. Number crunching apps that use vast amounts of memory through MPI or large databases etc. They stall for a long time during their initialization phase without these patches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote: > Dave Jones <[EMAIL PROTECTED]> wrote: > > > > On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote: > > > > > I would not keep regular driver updates from a 2.6. thing. > > > > Then the notion of it being stable is bogus, given how many regressions > > the last few kernels have brought in drivers. Moving from 2.6.9 -> 2.6.10 > > broke ALSA, USB, parport, firewire, and countless other little bits and > > pieces that users tend to notice. > > Grump. Have all these regressions received the appropriate level of > visibility on this mailing list? For the most part these things are usually known about by their upstream authors. To give an example: ALSA update in 2.6.10 broke sound for a bunch of IBM thinkpads. As it turns out there are quite a lot of these out there, so when I released a 2.6.10 update for Fedora, bugzilla lit up like a christmas tree with "Hey, where'd my sound go?" reports. (It was further confused by a load of other sound card problems, but thats another issue). This got so out of control, Alan asked the ALSA folks to take a look, and iirc Takashi figured out what had caused the problem, and it got fixed in the ALSA folks tree, and subsequently, in 2.6.11rc. Now, during all this time, there hadn't been any reports of this problem at all on Linux-kernel. Not even from Linus' tree, let alone -mm. Which amazes me given how widespread the problem was. > I too am a little put off by the number of regressions which certain > (admittedly tricky) subsystems keep on introducing. One does wonder how > careful people are being at the development stage. And that's a thing > which we can surely fix. > For example, here's today's crop (so far): > > include/linux/soundcard.h:195: warning: `_PATCHKEY' redefined > include/linux/awe_voice.h:33: warning: this is the location of the previous > definition compile time regressions we should be able to nail down fairly easily. (someone from OSDL is already doing compile stats and such on each release [too bad they're mostly incomprehensible to the casual viewer]) The bigger problem is runtime testing. If things aren't getting the exposure they need, we're going to get screwed over by something or other every time Linus bk pull's some random driver repo. 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: RFD: Kernel release numbering
On Wed, 02 Mar 2005 15:53:36 MST, "Jeff V. Merkey" said: > __Stable__ would be a good thing. The entire 2.6 development has been a > disaster from > a stability viewpoint. I have to maintain a huge tree of patches in > order to ship appliance > builds due to the lack of stability for 2.6. I think that the even > number releases will take longer > but it's worth the wait. Remember - each patch you successfully push upstream is one less patch you have to maintain. So re-read Documentation/SubmittingPatches, beat the patches into shape, and send them on their way. ;) pgpOaSbd4d7VK.pgp Description: PGP signature
Re: Something is broken with SATA RAID ?
J.A. Magallon wrote: Hi... I posted this in other mail, but now I can confirm this. I have a box with a SATA RAID-5, and with 2.6.11-rc3-mm2+libata-dev1 works like a charm as a samba server, I dropped it 12Gb from an osx client, and people does backups from W2k boxes and everything was fine. With 2.6.11-rc4-mm1, it hangs shortly after the mac starts copying files. No oops, no messages... It even hanged on a local copy (wget), so I will discard samba as the buggy piece in the puzzle. I'm going to make a definitive test with rc5-mm1 vs rc5-mm1+libata-dev1. I already know that plain rc5-mm1 hangs. I have to wait the md reconstruction of the 1.2 TB to check rc5-mm1+libata (and no user putting things there...) But, anyone has a clue about what is happening ? I have seen other reports of RAID related hangs... Any important change after rc3 ? Any important bugfix in libata-dev1 ? Something broken in -mm ? There was (is) a bug in -rc4-mm1 that may still be there in -rc5-mm1 related to the way RAID-5 and RAID-6 writes out blocks that can cause a deadlock in the raid code. Do you processes just hang in the D state and any access to /proc/mdstat do the same thing? Can you try with just 2.6.11+libata+libata-dev? I moved to 2.6.11+libata+libata-dev+netdev and all my problems went away. CC'd to linux-raid Regards, Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc5] i2c chips: ds1337 RTC driver
James Chapman <[EMAIL PROTECTED]> wrote: > > Add DS1337 RTC chip driver. > drivers/i2c/chips/ds1337.c:60: `I2C_DRIVERID_DS1337' undeclared here (not in a function) Also, there are changes in Greg's i2c tree which break your new driver: drivers/i2c/chips/ds1337.c:60: initializer element is not constant drivers/i2c/chips/ds1337.c:60: (near initialization for `ds1337_driver.id') drivers/i2c/chips/ds1337.c: In function `ds1337_get_datetime': drivers/i2c/chips/ds1337.c:155: structure has no member named `id' drivers/i2c/chips/ds1337.c: In function `ds1337_set_datetime': drivers/i2c/chips/ds1337.c:206: structure has no member named `id' drivers/i2c/chips/ds1337.c: In function `ds1337_detect': drivers/i2c/chips/ds1337.c:333: structure has no member named `id' drivers/i2c/chips/ds1337.c:343: structure has no member named `id' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
On Wednesday 02 March 2005 20:58, David S. Miller wrote: > That's one of the major things the -rc's don't get. Maybe it gets > a reference in lwn.net's weekly kernel article, but mostly kernel > geeks read those and that's not who we want testing -rc's (such > geeks already are doing so). > How do you know that they won't stop the announcements if this change is made? --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
Andrew Morton writes: > But if the approach which these patches take is not suitable for these > architectures then they have no solution to the scalability problem. The > machines will perform suboptimally and more (perhaps conflicting) > development will be needed. We can do a pte_cmpxchg on ppc64. We already have a busy bit in the PTE and do most operations atomically, in order to ensure that we don't get races or inconsistencies due to accesses to the PTE by the low-level hash_page() routine (which instantiates a hardware PTE in the hardware hash table based on a Linux PTE), because it already accesses the linux page tables without taking the mm->page_table_lock. However, there are other developments we are considering in this area: notably Ben wants to change things so that when we invalidate a Linux PTE we leave it busy until we actually remove the hardware PTE from the hash table. Also we are looking forward to DaveM's patch which will change the generic MM code to give us the mm and address on all PTE operations, which will simplify some things for us. I don't really want to have to think about pte_cmpxchg until those other things are sorted out. More generally, I would be interested to know what sorts of applications or benchmarks show scalability problems on large machines due to contention on mm->page_table_lock. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wednesday 02 March 2005 19:37, Linus Torvalds wrote: > That's the whole point here, at least to me. I want to have people test > things out, but it doesn't matter how many -rc kernels I'd do, it just > won't happen. It's not a "real release". > > In contrast, making it a real release, and making it clear that it's a > release in its own right, might actually get people to use it. > > Might. Maybe. > Linus, I respect all of the work you have done on the Linux kernels over the years, and I have been an avid user of Linux almost since its inception (when I could get it to work with the hardware, at least in the early days ;-) And the fact that my contributions to the kernel are almost nonexistent probbly means you won't pay attention to a word I say anyway :-) that's alright, I'm going to say it and you can listen if you want. My respect for your accomplishments is why it pains me a great deal to have to tell you that I think you're wrong. I agree with the first part of your mail that I quoted above. Indeed, the -rc releases are not a "real release", and therefore people aren't going to test it. What you are missing is that if you use the method you have proposed. odd numberered kernels will stop being a "real release" as well to a great deal of users. I don't think you will actually gain anything here except for just changing the kernel naming scheme yet *again*. I certainly don't think you're going to solve the problem you are trying to solve. The problem as stated is that people are not downloading and testing the test releases. Your solution to that problem is to make test releases look like real releases and maybe people will test them anyway. The solution should be to find a way to encourage people to download and test the test releases. Perhaps a "bug bounty" of some kind (it doesn't have to be money), or something similar, may prove to be a better motivator than trying to trick the userbase. It's not going to work. If you take the motivational approach, then it won't matter what you name the test releases, people will test them anyway. Several ideas right off the top of my head: - a "bug bounty" as I mentioned above. - a volunteer army of people, similar to the "kernel janitors", whose job is to do QA for the kernel. --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
On Wed, 2 Mar 2005, Andrew Morton wrote: > > There have been extensive discussions on all aspects of this patch. > > This issue was discussed in > > http://marc.theaimsgroup.com/?t=11069449724=1=2 > > This is a difficult, intrusive and controversial patch. Things like the > above should be done in a separate patch. Not only does this aid > maintainability, it also allows the change to be performance tested in > isolation. Well it would have been great if this was mentioned in the actual discussion at the time. > > The cmpxchg will fail if that happens. > > How about if someone does remap_file_pages() against that virtual address > and that syscalls happens to pick the same physical page? We have the same > physical page at the same pte slot with different contents, and the cmpxchg > will succeed. Any mmap changes requires the mmapsem. > > http://marc.theaimsgroup.com/?l=linux-kernel=110272296503539=2 > > Those are different cases. I still don't see why the change is justified in > do_swap_page(). Lets undo that then. > > These architectures have the atomic pte's not enable. It would require > > them to submit a patch to activate atomic pte's for these architectures. > > > But if the approach which these patches take is not suitable for these > architectures then they have no solution to the scalability problem. The > machines will perform suboptimally and more (perhaps conflicting) > development will be needed. They can implement their own approach with the provided hooks. You could for example use SSE / MMX for atomic 64 bit ops on i386 with PAE mode by using the start/stop macros to deal with the floatingh point issues. > > One > > would have to check for the lock being active leading to significant code > > changes. > > Why? Because if a pte is locked it should not be used. Look this is an endless discussion with new things brought up at every corner and I have reworked the patches numerous times. Could you tell me some step by step way that we can finally deal with this? Specify a sequence of patches and I will submit them to you step by step. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
On Wed, 02 Mar 2005 21:32:23 EST, Jeff Garzik said: > I also note that part of the problem that motivates the even/odd thing > is a tacit acknowledgement that people only _really_ test the official > releases. > > Which IMHO backs up my opinion that we simply need more frequent releases. Or more testers of things other than (which is where I see the *real* problem as being). It doesn't matter *what* we call the "testing" releases. They aren't getting tested enough. I've posted a fair number of "the latest -mm broke FOO" notes - but assuming that "the first guy to hit it" is randomly distributed across all the -mm users, there really can't be a whole lot of others doing it, as my number seems to come up waaay too often if there's a large pool of testers... Either that, or I really *am* the most bleeding-edge loon in my time zone. pgpFHL1Pmsalz.pgp Description: PGP signature
Re: Page fault scalability patch V18: Drop first acquisition of ptl
Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > > The cmpxchg will fail if that happens. > > > > How about if someone does remap_file_pages() against that virtual address > > and that syscalls happens to pick the same physical page? We have the same > > physical page at the same pte slot with different contents, and the cmpxchg > > will succeed. > > Any mmap changes requires the mmapsem. sys_remap_file_pages() will call install_page() under down_read(mmap_sem). It relies upon page_table_lock for pte atomicity. > > > http://marc.theaimsgroup.com/?l=linux-kernel=110272296503539=2 > > > > Those are different cases. I still don't see why the change is justified in > > do_swap_page(). > > Lets undo that then. OK. > > > These architectures have the atomic pte's not enable. It would require > > > them to submit a patch to activate atomic pte's for these architectures. > > > > > > But if the approach which these patches take is not suitable for these > > architectures then they have no solution to the scalability problem. The > > machines will perform suboptimally and more (perhaps conflicting) > > development will be needed. > > They can implement their own approach with the provided hooks. You could > for example use SSE / MMX for atomic 64 bit ops on i386 with PAE mode by > using the start/stop macros to deal with the floatingh point issues. Have the ppc64 and sparc64 people reviewed and acked the change? (Not a facetious question - I just haven't been following the saga sufficiently closely to remember). > > > One > > > would have to check for the lock being active leading to significant code > > > changes. > > > > Why? > > Because if a pte is locked it should not be used. Confused. Why not just spin on the lock in the normal manner? > Look this is an endless discussion with new things brought up at every > corner and I have reworked the patches numerous times. Could you tell me > some step by step way that we can finally deal with this? Specify a > sequence of patches and I will submit them to you step by step. No, I couldn't do that - that's what the collective brain is for. Look, I'm sorry, but this patch is highly atypical. Few have this much trouble. I have queazy feeling about it (maybe too low-level locking, maybe inappropriate to other architectures, only addresses a subset of workloads on a tiny subset of machines, doesn't seem to address all uses of the lock, etc) and I know that others have had, and continue to have similar feelings. But if we could think of anything better, we'd have said so :( It's a diffucult problem. If the other relvant architecture people say "we can use this" then perhaps we should grin and bear it. But one does wonder whether some more sweeping design change is needed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
On Wed, 02 Mar 2005 23:46:22 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is > preferable to even/odd. All of these arguments are circular. If people think that even/odd will devalue odd releases, guess what 2.6.x.y will do? By that line of reasoning nobody will test 2.6.x just the same as they aren't testing 2.6.x-rc* right now. I think they will test the odd releases, because as a real release they will get slashdot/lwn.net/etc. announcements. That's one of the major things the -rc's don't get. Maybe it gets a reference in lwn.net's weekly kernel article, but mostly kernel geeks read those and that's not who we want testing -rc's (such geeks already are doing so). It has to be a "real" release. That does have an impact. However, I am ambivalent about how to make them real. Even/odd, 2.6.x.y, either is fine with me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BK PATCHES] 2.4.x libata update
Please do a
bk pull bk://kernel.bkbits.net/jgarzik/libata-upstream-2.4
This will update the following files:
Documentation/Configure.help |5
drivers/scsi/Config.in|1
drivers/scsi/Makefile |1
drivers/scsi/ahci.c | 26 +
drivers/scsi/ata_piix.c |4
drivers/scsi/libata-core.c| 120 ++-
drivers/scsi/libata-scsi.c|1
drivers/scsi/libata.h |1
drivers/scsi/sata_nv.c| 10
drivers/scsi/sata_promise.c | 10
drivers/scsi/sata_qstor.c | 699 ++
drivers/scsi/sata_sil.c | 10
drivers/scsi/sata_sis.c | 10
drivers/scsi/sata_svw.c | 10
drivers/scsi/sata_sx4.c | 14
drivers/scsi/sata_uli.c | 10
drivers/scsi/sata_via.c | 213 +---
drivers/scsi/sata_vsc.c | 12
include/linux/libata-compat.h | 22 +
include/linux/libata.h| 64 ---
20 files changed, 1079 insertions(+), 164 deletions(-)
through these ChangeSets:
:
o [libata] add ->bmdma_{stop,status} hooks
Jeff Garzik:
o [libata ahci] Print out port id on error messages
o [libata] Use DMA_{32,64}BIT_MASK in ahci, sata_vsc drivers
o [libata] Add missing hooks, to avoid oops in advanced SATA drivers
o [libata] do not call pci_disable_device() for certain errors
o [libata] trivial: whitespace sync with 2.6
o [libata] resync with 2.6 msleep() updates
o [libata sata_via] add support for VT6421 SATA
o [libata sata_via] minor cleanups
John W. Linville:
o libata: fix command queue leak when xlat_func fails
Mark Lord:
o [libata qstor] minor update per LKML comments
o sata_qstor: new basic driver for Pacific Digital
diff -Nru a/Documentation/Configure.help b/Documentation/Configure.help
--- a/Documentation/Configure.help 2005-03-02 23:23:22 -05:00
+++ b/Documentation/Configure.help 2005-03-02 23:23:22 -05:00
@@ -9345,6 +9345,11 @@
If unsure, say N.
+CONFIG_SCSI_SATA_QSTOR
+ This option enables support for Pacific Digital Serial ATA QStor.
+
+ If unsure, say N.
+
CONFIG_SCSI_SATA_SX4
This option enables support for Promise Serial ATA SX4.
diff -Nru a/drivers/scsi/Config.in b/drivers/scsi/Config.in
--- a/drivers/scsi/Config.in2005-03-02 23:23:22 -05:00
+++ b/drivers/scsi/Config.in2005-03-02 23:23:22 -05:00
@@ -73,6 +73,7 @@
dep_tristate ' ServerWorks Frodo / Apple K2 SATA support (EXPERIMENTAL)'
CONFIG_SCSI_SATA_SVW $CONFIG_SCSI_SATA $CONFIG_PCI $CONFIG_EXPERIMENTAL
dep_tristate ' Intel PIIX/ICH SATA support' CONFIG_SCSI_ATA_PIIX
$CONFIG_SCSI_SATA $CONFIG_PCI
dep_tristate ' NVIDIA SATA support (EXPERIMENTAL)' CONFIG_SCSI_SATA_NV
$CONFIG_SCSI_SATA $CONFIG_PCI $CONFIG_EXPERIMENTAL
+dep_tristate ' Pacific Digital SATA QStor support' CONFIG_SCSI_SATA_QSTOR
$CONFIG_SCSI_SATA $CONFIG_PCI
dep_tristate ' Promise SATA TX2/TX4 support (EXPERIMENTAL)'
CONFIG_SCSI_SATA_PROMISE $CONFIG_SCSI_SATA $CONFIG_PCI $CONFIG_EXPERIMENTAL
dep_tristate ' Promise SATA SX4 support (EXPERIMENTAL)' CONFIG_SCSI_SATA_SX4
$CONFIG_SCSI_SATA $CONFIG_PCI $CONFIG_EXPERIMENTAL
dep_tristate ' Silicon Image SATA support (EXPERIMENTAL)'
CONFIG_SCSI_SATA_SIL $CONFIG_SCSI_SATA $CONFIG_PCI $CONFIG_EXPERIMENTAL
diff -Nru a/drivers/scsi/Makefile b/drivers/scsi/Makefile
--- a/drivers/scsi/Makefile 2005-03-02 23:23:22 -05:00
+++ b/drivers/scsi/Makefile 2005-03-02 23:23:22 -05:00
@@ -134,6 +134,7 @@
obj-$(CONFIG_SCSI_SATA_SVW)+= libata.o sata_svw.o
obj-$(CONFIG_SCSI_ATA_PIIX)+= libata.o ata_piix.o
obj-$(CONFIG_SCSI_SATA_PROMISE)+= libata.o sata_promise.o
+obj-$(CONFIG_SCSI_SATA_QSTOR) += libata.o sata_qstor.o
obj-$(CONFIG_SCSI_SATA_SIL)+= libata.o sata_sil.o
obj-$(CONFIG_SCSI_SATA_VIA)+= libata.o sata_via.o
obj-$(CONFIG_SCSI_SATA_VITESSE)+= libata.o sata_vsc.o
diff -Nru a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
--- a/drivers/scsi/ahci.c 2005-03-02 23:23:22 -05:00
+++ b/drivers/scsi/ahci.c 2005-03-02 23:23:22 -05:00
@@ -40,8 +40,6 @@
#define DRV_NAME "ahci"
#define DRV_VERSION"1.00"
-#define msleep libata_msleep /* 2.4-specific */
-
enum {
AHCI_PCI_BAR= 5,
AHCI_MAX_SG = 168, /* hardware max is 64K */
@@ -180,6 +178,7 @@
static void ahci_host_stop(struct ata_host_set *host_set);
static void ahci_qc_prep(struct ata_queued_cmd *qc);
static u8 ahci_check_status(struct ata_port *ap);
+static u8 ahci_check_err(struct ata_port *ap);
static inline int ahci_host_intr(struct ata_port *ap, struct ata_queued_cmd
*qc);
static Scsi_Host_Template ahci_sht = {
@@ -206,6 +205,8 @@
.port_disable = ata_port_disable,
.check_status = ahci_check_status,
+ .check_altstatus= ahci_check_status,
+ .check_err = ahci_check_err,
.dev_select = ata_noop_dev_select,
.phy_reset = ahci_phy_reset,
@@ -454,6
Re: radeonfb blanks my monitor
On Thu, 2005-03-03 at 01:39 -0300, Frédéric L. W. Meunier wrote: > On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote: > > > On Wed, 2005-03-02 at 23:51 -0300, Frédéric L. W. Meunier wrote: > >> I just replaced my Matrox G400 with a Jetway Radeon 9600LE > >> (256Mb). If I run 'modprobe radeonfb', the monitor blanks out > >> and the power on light keeps flashing. > >> > >> What may be wrong ? Using 2.6.11. > > > > Do you have a way to capture the dmesg log produced ? > > These are the lines before I have to use SysRq. > > Mar 2 15:16:45 darkstar kernel: radeonfb: Found Intel x86 BIOS ROM Image > Mar 2 15:16:45 darkstar kernel: radeonfb: Retreived PLL infos from BIOS > Mar 2 15:16:45 darkstar kernel: i2c-algo-bit.o: dvi passed test. > Mar 2 15:16:45 darkstar kernel: i2c-algo-bit.o: vga passed test. > Mar 2 15:16:46 darkstar kernel: radeonfb: Monitor 1 type CRT found > Mar 2 15:16:46 darkstar kernel: radeonfb: EDID probed > Mar 2 15:16:46 darkstar kernel: radeonfb: Monitor 2 type no found > > BTW, I don't know if it could be related, but my motherboard > only supports AGP 4x There should be more than these... Does it continue booting afte the screen goes blank or not at all ? Can you send the full dmesg log too ? Also, enable radeonfb verbose debug in the config. > > Also, does it work if radeonfb is built-in ? > > I'll try later. Time to sleep. Ok, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wednesday 02 March 2005 22:17, Andrew Morton wrote: >Gene Heskett <[EMAIL PROTECTED]> wrote: >> Ditto for the 1394 fixes that have been upstream for at >> least a month, maybe more. > >-mm always holds the latest 1394 tree. So you can run -mm, or just > snarf bk-ieee1394.patch from the broken-out directory. > Thanks Andrew. If this is the same as I pulled from svn 2 weeks ago, it does need to be pushed on down the line. -- 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: radeonfb blanks my monitor
On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote: On Wed, 2005-03-02 at 23:51 -0300, Frédéric L. W. Meunier wrote: I just replaced my Matrox G400 with a Jetway Radeon 9600LE (256Mb). If I run 'modprobe radeonfb', the monitor blanks out and the power on light keeps flashing. What may be wrong ? Using 2.6.11. Do you have a way to capture the dmesg log produced ? These are the lines before I have to use SysRq. Mar 2 15:16:45 darkstar kernel: radeonfb: Found Intel x86 BIOS ROM Image Mar 2 15:16:45 darkstar kernel: radeonfb: Retreived PLL infos from BIOS Mar 2 15:16:45 darkstar kernel: i2c-algo-bit.o: dvi passed test. Mar 2 15:16:45 darkstar kernel: i2c-algo-bit.o: vga passed test. Mar 2 15:16:46 darkstar kernel: radeonfb: Monitor 1 type CRT found Mar 2 15:16:46 darkstar kernel: radeonfb: EDID probed Mar 2 15:16:46 darkstar kernel: radeonfb: Monitor 2 type no found BTW, I don't know if it could be related, but my motherboard only supports AGP 4x. Also, does it work if radeonfb is built-in ? I'll try later. Time to sleep. -- How to contact me - http://www.pervalidus.net/contact.html
Re: RFD: Kernel release numbering
If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is preferable to even/odd. Just create a 2.6.X repo at each release. For bug fixes to 2.6.X, commit to this repo, then pull into linux-2.6. For everything else, pull straight into linux-2.6. The linux-2.6 repo would be upstream, and linux-2.6.X repo would be where bugfix-only releases come from. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: United States Patent: 6,862,609]
Gene Heskett wrote: On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote: Another Linux patent. And that pretty much says it. Assigned to the Canopy Group. So SCO will have yet another lawsuit to threaten us with. If they survive the thrashing I've Been Moved will give them at the end of the day. The way to fight the patents is for Linux developers to file their own and start putting down stakes. Too bad that you can figure out how to file a patent, but can't figure out how to setup an html link. Why the hell would I want to look at the link in kwrite? Talk to the USPTO, they created these links from their website. BTW, if you check the verson of web server run on the uspto.gov server, you will discover it is Apache on IBM servers and IBM Linux. Ask them why IBM's sofware outputs links this way. Jeff Seems like a good question to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Dave Jones <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote: > > > I would not keep regular driver updates from a 2.6. thing. > > Then the notion of it being stable is bogus, given how many regressions > the last few kernels have brought in drivers. Moving from 2.6.9 -> 2.6.10 > broke ALSA, USB, parport, firewire, and countless other little bits and > pieces that users tend to notice. Grump. Have all these regressions received the appropriate level of visibility on this mailing list? I too am a little put off by the number of regressions which certain (admittedly tricky) subsystems keep on introducing. One does wonder how careful people are being at the development stage. And that's a thing which we can surely fix. For example, here's today's crop (so far): include/linux/soundcard.h:195: warning: `_PATCHKEY' redefined include/linux/awe_voice.h:33: warning: this is the location of the previous definition drivers/i2c/chips/ds1337.c:60: `I2C_DRIVERID_DS1337' undeclared here (not in a function) drivers/i2c/chips/ds1337.c:60: initializer element is not constant drivers/i2c/chips/ds1337.c:60: (near initialization for `ds1337_driver.id') drivers/i2c/chips/ds1337.c: In function `ds1337_get_datetime': drivers/i2c/chips/ds1337.c:155: structure has no member named `id' drivers/i2c/chips/ds1337.c: In function `ds1337_set_datetime': drivers/i2c/chips/ds1337.c:206: structure has no member named `id' drivers/i2c/chips/ds1337.c: In function `ds1337_detect': drivers/i2c/chips/ds1337.c:333: structure has no member named `id' drivers/i2c/chips/ds1337.c:343: structure has no member named `id' make[3]: *** [drivers/i2c/chips/ds1337.o] Error 1 make[2]: *** [drivers/i2c/chips] Error 2 make[1]: *** [drivers/i2c] Error 2 make[1]: *** Waiting for unfinished jobs sound/pci/als4000.c: In function `snd_als4000_create_gameport': sound/pci/als4000.c:572: warning: `r' might be used uninitialized in this function drivers/char/watchdog/alim1535_wdt.c:319: warning: `ali_pci_tbl' defined but not used drivers/char/sx.c:255: warning: `sx_pci_tbl' defined but not used drivers/char/applicom.c:68: warning: `applicom_pci_tbl' defined but not used make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs sound/pci/trident/trident_main.c: In function `snd_trident_gameport_trigger': sound/pci/trident/trident_main.c:3125: warning: `return' with a value, in function returning void > For it to truly be a stable kernel, the only patches I'd expect to > drivers would be ones fixing blindingly obvious bugs. No cleanups. > No new functionality. I'd even question new hardware support if it > wasn't just a PCI ID addition. Agree. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove dead cyrix/centaur mtrr init code
On Wed, Mar 02, 2005 at 01:45:43PM +, Alan Cox wrote:
> On Mer, 2005-03-02 at 08:02, Dave Jones wrote:
> > If there are any of them still being used out there, I'd be even
> > more surprised if they're running 2.6. Then again, there are
> > probably loonies out there running it on 386/486's. 8-)
>
> I have one here running 2.4 still. I can test a 2.6 fix for the mtrr
> init happily enough.
Good. If I understand things correctly - you or davej or someone will
correct me otherwise - failing to initialise mtrr does not break anything,
it would just mean slower access to certain kinds of memory for certain
kinds of access patterns. (Would you test using an X benchmark?)
Below roughly speaking the same patch as before, but with calls
to the cyrix and centaur mtrr init routines inserted.
Andries
-
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/centaur.c
b/arch/i386/kernel/cpu/mtrr/centaur.c
--- a/arch/i386/kernel/cpu/mtrr/centaur.c 2003-12-18 03:58:38.0
+0100
+++ b/arch/i386/kernel/cpu/mtrr/centaur.c 2005-03-02 23:22:10.0
+0100
@@ -86,6 +86,7 @@ static void centaur_set_mcr(unsigned int
centaur_mcr[reg].low = low;
wrmsr(MSR_IDT_MCR0 + reg, low, high);
}
+
/*
* Initialise the later (saner) Winchip MCR variant. In this version
* the BIOS can pass us the registers it has used (but not their values)
@@ -168,7 +169,7 @@ centaur_mcr0_init(void)
* Initialise Winchip series MCR registers
*/
-static void __init
+void __init
centaur_mcr_init(void)
{
struct set_mtrr_context ctxt;
@@ -203,7 +204,6 @@ static int centaur_validate_add_page(uns
static struct mtrr_ops centaur_mtrr_ops = {
.vendor= X86_VENDOR_CENTAUR,
- .init = centaur_mcr_init,
.set = centaur_set_mcr,
.get = centaur_get_mcr,
.get_free_region = centaur_get_free_region,
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/cyrix.c
b/arch/i386/kernel/cpu/mtrr/cyrix.c
--- a/arch/i386/kernel/cpu/mtrr/cyrix.c 2003-12-18 03:58:56.0 +0100
+++ b/arch/i386/kernel/cpu/mtrr/cyrix.c 2005-03-02 23:22:40.0 +0100
@@ -218,12 +218,12 @@ typedef struct {
mtrr_type type;
} arr_state_t;
-arr_state_t arr_state[8] __initdata = {
+static arr_state_t arr_state[8] __initdata = {
{0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL},
{0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}
};
-unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
+static unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
static void cyrix_set_all(void)
{
@@ -257,7 +257,7 @@ static void cyrix_set_all(void)
* - (maybe) disable ARR3
* Just to be sure, we enable ARR usage by the processor (CCR5 bit 5 set)
*/
-static void __init
+void __init
cyrix_arr_init(void)
{
struct set_mtrr_context ctxt;
@@ -344,7 +344,6 @@ cyrix_arr_init(void)
static struct mtrr_ops cyrix_mtrr_ops = {
.vendor= X86_VENDOR_CYRIX,
- .init = cyrix_arr_init,
.set_all = cyrix_set_all,
.set = cyrix_set_arr,
.get = cyrix_get_arr,
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
--- a/arch/i386/kernel/cpu/mtrr/generic.c 2005-03-02 20:54:48.0
+0100
+++ b/arch/i386/kernel/cpu/mtrr/generic.c 2005-03-02 20:56:19.0
+0100
@@ -19,8 +19,7 @@ struct mtrr_state {
};
static unsigned long smp_changes_mask;
-struct mtrr_state mtrr_state = {};
-
+static struct mtrr_state mtrr_state = {};
/* Get the MSR pair relating to a var range */
static void __init
@@ -383,7 +382,7 @@ int generic_validate_add_page(unsigned l
}
-int generic_have_wrcomb(void)
+static int generic_have_wrcomb(void)
{
unsigned long config, dummy;
rdmsr(MTRRcap_MSR, config, dummy);
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/main.c
b/arch/i386/kernel/cpu/mtrr/main.c
--- a/arch/i386/kernel/cpu/mtrr/main.c 2004-12-29 03:39:42.0 +0100
+++ b/arch/i386/kernel/cpu/mtrr/main.c 2005-03-02 23:21:46.0 +0100
@@ -57,10 +57,6 @@ static struct mtrr_ops * mtrr_ops[X86_VE
struct mtrr_ops * mtrr_if = NULL;
-__initdata char *mtrr_if_name[] = {
-"none", "Intel", "AMD K6", "Cyrix ARR", "Centaur MCR"
-};
-
static void set_mtrr(unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type);
@@ -100,7 +96,7 @@ static int have_wrcomb(void)
}
/* This function returns the number of variable MTRRs */
-void __init set_num_var_ranges(void)
+static void __init set_num_var_ranges(void)
{
unsigned long config = 0, dummy;
@@ -526,6 +522,8 @@ EXPORT_SYMBOL(mtrr_del);
* These should be called implicitly, but we can't yet until all the initcall
* stuff is done...
*/
+extern void
Re: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150
Joshua Hudson wrote: > No obvous reason. Works fine with kernel 2.6.10 > > Result of lspci: > 00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) > 00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control > Registers (rev 02) > 00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration > Process Registers (rev 02) > 00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated > Graphics Device (rev 02) > 00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics > Device (rev 02) > 00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 01) > 00:1d.1 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #2 (rev 01) > 00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 01) > 00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller > (rev 01) > 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 81) > 00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01) > 00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage > Controller (rev 01) > 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97 > Audio Controller (rev 01) > 00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 01) > 02:01.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev > 01) > 02:02.0 Network controller: Broadcom Corporation: Unknown device 4324 (rev > 03) > 02:04.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus > Controller > ditto with Inspiron 5150 lspci: :00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) :00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) :00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) :00:01.0 PCI bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to AGP Controller (rev 02) :00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) :00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) :00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) :00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) :00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81) :00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) :00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01) :00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) :01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go 5200] (rev a1) :02:01.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) :02:04.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus Controller (rev 02) :02:04.1 FireWire (IEEE 1394): Texas Instruments PCI4510 IEEE-1394 Controller - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] BDI: Provide backing device capability information
Linus Torvalds <[EMAIL PROTECTED]> wrote: > > On Wed, 2 Mar 2005, Andrew Morton wrote: > > > > Why not make these bitfields as well? > > Side note: bitfields aren't exactly wonderful. Yup. In this application the fields are initialised once (usually at compile time) and are never modified. So the compiler should be able to generate the same code as it would with an open-coded bit test. Which is about the only situation where we should use bitfields, IMO. That being said, there aren't many backing_dev_info's in a system, so we won't be saving much memory. Some architectures will presumably generate faster code with plain old integers. You'd only ever lose if the backing_dev_info happened to straddle a cacheline boundary. It's marginal. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
On Wed, Mar 02, 2005 at 05:41:50PM -0500, Jeff Garzik wrote: > Andrew Morton wrote: > >Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > >>>Thing is, CRYPTO_AES on only selectable on x86. > >> > >>You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, > >>the dependencies are a bit weird: > >> > >>config CRYPTO_AES > >> tristate "AES cipher algorithms" > >> depends on CRYPTO && !(X86 && !X86_64) > >>config CRYPTO_AES_586 > >> tristate "AES cipher algorithms (i586)" > >> depends on CRYPTO && (X86 && !X86_64) > > > > > >That's pretty broken, isn't it? > > > >Would be better to just do: > > > >config CRYPTO_AES > > select CRYPTO_AES_586 if (X86 && !X86_64) > > select CRYPTO_AES_OTHER if !(X86 && !X86_64) > > > >and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. > > Not really that easy. For x86 we have > > aes > aes-586 > aes-via Where is aes-via? > And my own personal custom-kernel preference is to use the C version of > the code on my x86 and x86-64 boxes. That's already not possible today. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
David S. Miller wrote: On Wed, 02 Mar 2005 22:40:57 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: People don't test 2.6-rc releases because they know they are not "release candidate, with only bug fixes" releases, which is how the rest of the world interprets the phrase. That's not %100 true. No matter what -rc* really is, people perceive it to be something based upon it's name and whether or not it is an official release. As far as I can see it's %95 perception vs. reality. And IT IS part of the reason the -rc's are not as good as they could be. The reasons -rcs are not as good as they could be is that they include more than just bug fixes. Users are discouraged from testing because they must scan LKML, or guess, which -rc that Linus/Andrew started getting serious about "bugfixes only." With the -pre/-rc scheme, it's clear to users. With the even/odd scheme, you just devalue releases. Previously, all releases were worthy of testing and use. Now, half of them aren't. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote: > - 2.6.: even at all levels, aim for having had minimally intrusive >patches leading up to it (timeframe: a week or two) > > with the odd numbers going like: > > - 2.6.: still a stable kernel, but accept bigger changes leading up >to it (timeframe: a month or two). > - 2..x: aim for big changes that may destabilize the kernel for >several releases (timeframe: a year or two) [...] Why not change the "2.6 prefix" to 2.8, 3.0 (or whatever) if/when you do go to a new naming scheme --- simply to make a clean break between the new and the old. Plus it will give the suckdork crowd[1] bigger numbers to drivel on about. That said it would be a large numerical leap without and real feature changes so perhaps that will further add to confusion? Sigh. [1] Well, and the CGL and similar people. "New CGL with improved version numbers and fewer calories!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeonfb blanks my monitor
On Wed, 2005-03-02 at 23:51 -0300, Frédéric L. W. Meunier wrote: > I just replaced my Matrox G400 with a Jetway Radeon 9600LE > (256Mb). If I run 'modprobe radeonfb', the monitor blanks out > and the power on light keeps flashing. > > What may be wrong ? Using 2.6.11. Do you have a way to capture the dmesg log produced ? Also, does it work if radeonfb is built-in ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 report -- keyboard not working Linux 2.6.11 on Inspiron 1150
On Wednesday 02 March 2005 23:02, Joshua Hudson wrote: > ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1 > ACPI: PS/2 Mouse Controller [PS2M] at irq 12 > i8042.c: Can't read CTR while initializing i8042. Ok, your BIOS is also reporting incorrect port values for the keyboard controller, it should be 0x60, 0x64. You'll have to use i8042.noacpi for now. Thank you for the log. -- 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: RFD: Kernel release numbering
Dave Jones wrote: On Wed, Mar 02, 2005 at 07:10:47PM -0800, Randy.Dunlap wrote: > >For it to truly be a stable kernel, the only patches I'd expect to > >drivers would be ones fixing blindingly obvious bugs. No cleanups. > >No new functionality. I'd even question new hardware support if it > >wasn't just a PCI ID addition. > > Maybe I don't understand? Is someone expecting distro > quality/stability from kernel.org kernels? My complaint is the charade of calling it 'stable' when it clearly wouldn't be anything of the sort, given that a majority of the bugs our users experienced on rebasing were driver related. The core itself may be rock-solid, but if we're continually pulling in random driver updates of questionable quality with limited testing, the result as a whole isn't stable. > I don't, but maybe I'm one of those minorities. Putting the onus on distributions to make things stable is no excuse for the ever-increasing number of regressions each release. Sure, I'm not trying to put the onus on distros, just saying that they add some real value there, but that doesn't excuse us from trying to make the mainline kernel as good as we can make it. This might sound over-dramatic, but it's the current state as far as I'm concerned. The 2.6.8->2.6.9 update for Fedora users brought a bunch of carnage that took time to shake out. 2.6.9->2.6.10 I'm still picking up the pieces of. If the 2.6.10->2.6.11 update that I'll do for Fedora in a week or two turns out to have less regressions than the previous releases, I'll be stunned. Really. Already I'm wondering how many userspace packages are going to randomly stop working as they have done in previous releases. With the clear delineation of stable/development, we were able to say things like "we won't change a user visible interface in a stable series" Now, we don't have that. So we find things ranging from slabtop to alsa-lib completely break unless you update the userspace too. regressions like this is what I'm bitching about. There's nothing a vendor can do to make such things stable (other than dropping the various patches that introduce the breakage, but at ~4000 csets per release right now, there will be stuff that gets missed). Whilst the slabinfo example was a non-driver related regression, it's a good example of how little care we're taking these days to make sure existing userspace continues to work correctly. Some may suggest the close tracking of mainline is the problem. Maybe they're right. Maybe we should have stuck with a 2.6.5 kernel until Fedora Core 2 reached end of life, and gone with the old 'have hundreds and hundreds of patches piling up' approach. But, as someone who has maintained vendor kernels that have tried both methods, the sticking close to mainline approach wins hands down. If something is broken, more often than not, I can bug the upstream developer and ask "hey, this is a wierd problem our fedora users hit, we don't have any patches against this code, can you take a look?" and developers have been very responsive, and helpful on many occasions, ultimatly leading bugs being fixed both in our kernel, and upstream. If I asked most upstream developers about a problem we've been facing with our 2.6.5 kernels, I'd get a much less helpful response. And rightly so. In their position I'd do exactly the same thing. -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Drop first acquisition of ptl
Christoph Lameter <[EMAIL PROTECTED]> wrote: > > On Wed, 2 Mar 2005, Andrew Morton wrote: > > > > This is a related change discussed during V16 with Nick. > > > > It's worth retaining a paragraph for the changelog. > > There have been extensive discussions on all aspects of this patch. > This issue was discussed in > http://marc.theaimsgroup.com/?t=11069449724=1=2 This is a difficult, intrusive and controversial patch. Things like the above should be done in a separate patch. Not only does this aid maintainability, it also allows the change to be performance tested in isolation. If the change gets folded into other changes then it would be best to draw attention to, and fully explain/justify the change within the changelog. > > > > > The page is protected from munmap because of the down_read(mmap_sem) in > > > the arch specific code before calling handle_mm_fault. > > > > We don't take mmap_sem during page reclaim. What prevents the page from > > being freed by, say, kswapd? > > The cmpxchg will fail if that happens. How about if someone does remap_file_pages() against that virtual address and that syscalls happens to pick the same physical page? We have the same physical page at the same pte slot with different contents, and the cmpxchg will succeed. Maybe mmap_sem will save us, maybe not. Either way, this change needs a ton of analysys, justification and documentation, please. Plus if the page gets freed under our feet, CONFIG_DEBUG_PAGEALLOC will oops during the copy. > > I forget. I do recall that we decided that the change was OK, but briefly > > looking at it now, it seems that we'll fail to move a > > PageReferenced,!PageActive onto the active list? > > See http://marc.theaimsgroup.com/?l=bk-commits-head=110481975332117=2 > > and > > http://marc.theaimsgroup.com/?l=linux-kernel=110272296503539=2 Those are different cases. I still don't see why the change is justified in do_swap_page(). > > > That is up to the arch maintainers. Add something to arch/xx/Kconfig to > > > allow atomic operations for an arch. Out of the box it only works for > > > x86_64, ia64 and ia32. > > > > Feedback from s390, sparc64 and ppc64 people would help in making a > > > > merge > > decision. > > These architectures have the atomic pte's not enable. It would require > them to submit a patch to activate atomic pte's for these architectures. But if the approach which these patches take is not suitable for these architectures then they have no solution to the scalability problem. The machines will perform suboptimally and more (perhaps conflicting) development will be needed. > > > Earlier releases back in September 2004 had some pte locking code (and > > > AFAIK Nick also played around with pte locking) but that > > > was less efficient than atomic operations. > > > > How much less efficient? > > Does anyone else have that code around? > > Nick may have some data. It got far too complicated too fast when I tried > to introduce locking for individual ptes. It required bit > spinlocks for the pte meaning multiple atomic operations. One could add a spinlock to the pageframe, or use hashed spinlocking. > One > would have to check for the lock being active leading to significant code > changes. Why? > This would include the arch specific low level fault handers to > update bits, walk the page table etc etc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Whitelist-Entry (FORCELUN) for SGS Thomson Microelectronics Cytronix 6in1 card reader in scsi_devinfo.c
I have an usb-cardreader here that needs some FORCELUN-entries in
scsi_devinfo.c.
lsusb says about the device:
Bus 001 Device 003: ID 0483:1307 SGS Thomson Microelectronics Cytronix 6in1
card reader
Patch see below. Please apply.
--- linux-2.6.11-buju/drivers/scsi/scsi_devinfo.c 2005-03-02
08:37:54.0 +0100
+++ linux-2.6.11/drivers/scsi/scsi_devinfo.c2005-03-02 23:42:56.961751736
+0100
@@ -148,6 +148,10 @@
{"Generic", "USB SD Reader", "1.00", BLIST_FORCELUN | BLIST_INQUIRY_36},
{"Generic", "USB Storage-SMC", "0180", BLIST_FORCELUN |
BLIST_INQUIRY_36},
{"Generic", "USB Storage-SMC", "0207", BLIST_FORCELUN |
BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-SMC", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-CF", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-SD", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-MS", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
{"HITACHI", "DF400", "*", BLIST_SPARSELUN},
{"HITACHI", "DF500", "*", BLIST_SPARSELUN},
{"HITACHI", "DF600", "*", BLIST_SPARSELUN},
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
stack/routing kernel modification - consult needed
I committed to a fairly complex project to run on Linux while assuming that the Linux stack implementation would provide equivalent functionality to that of the BSD-style stacks I am familiar with. At this point, quite far down the design path, I looked at what I thought would be trivial details and I am facing two major roadblocks. Problem #1 The physical driver layer which itself is quite complex and does additional routing, needs access to the destination (next hop) IP address in order to transmit the packet. Under BSD, the ip output method passes down the IP address, but under Linux that does not seem to be the case. I need some method of getting hold of the IP address. Note that there is no protocol address resolution on these interfaces, but there are multiple hosts to be addressed. The physical layer does the necessary addressing and additional routing, but it needs the IP address of where the packet is being forwarded. Problem #2 This device is a routing class device, i.e., it routes network traffic on some network segment. As such, it must be able to handle both public (e.g., 18.x.x.x) and private (e.g., 192.168.x.x) IP addresses. The device itself has multiple, loosely-coupled cards that communicate via TCP/IP sockets. To separate the "device internal" TCP traffic from the external "real" network traffic, the standard BSD solution is to subnet the 127/8 "lo" interface to 127.0/16 for "lo" and e.g., 127.1/16 for a driver accessing the other cards. Unfortunately, the Linux stack does not seem to allow subnetting of the 127 net. Assuming that my observation are accurate (please feel free to indicate otherwise), it would appear to me that I have two options: 1. Hack the Linux kernel/stack to add the required functionality (pass IP on transmit, allow 127/16 subnets). This would be the preferred solution given the late stage of the project, but I am not familiar (obviously) with the Linux stack code. I am now also nervous about other possible surprises (I got VLANs, multiple interfaces with same IP address, multiple proxy ARPs on the same processor etc.) 2. Scrap the project and restart under BSD. This is quite an expensive option; the only advantage would be my certainty that all of the concepts will work as architected because they were based on such stack. I am looking for advice, and, if possible, help. Any pointers addressing any of the above will be quite useful to me. If you are familiar with the relevant kernel code, and would be willing to help me with the modifications, please let me know. If you could do it, but think it would take too much of your time, please let me know, too, I'd be glad to set up a paid consulting arrangement if that would help. BTW, this is being developed on the 2.4.25 kernel. Please respond to me directly: zdenek at rcn.com Thanks, -Zdenek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
On Wed, 02 Mar 2005 21:32:23 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > I also note that part of the problem that motivates the even/odd thing > is a tacit acknowledgement that people only _really_ test the official > releases. > > Which IMHO backs up my opinion that we simply need more frequent releases. This more frequent release idea will basically mimmick what the even/odd idea will do, except that even/odd will have specific engineering goals. Development vs. pure bug fixing. There are changes that simply have to sit for weeks if not months in order for all the problems to be weeded out. I think something like the 4-level pagetable stuff is the best example. And yes it has to occur in Linus's tree so what precious few people do test his live tree try out the new code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
In article <[EMAIL PROTECTED]> (at Wed, 2 Mar 2005 19:37:44 -0800 (PST)), Linus Torvalds <[EMAIL PROTECTED]> says: > In contrast, making it a real release, and making it clear that it's a > release in its own right, might actually get people to use it. > > Might. Maybe. I believe people soon stop using 2.6. "release"s. --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: [SATA] libata-dev queue updated
Joerg Sommrey wrote: Jeff Garzik wrote: BK users: bk pull bk://gkernel.bkbits.net/libata-dev-2.6 Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.11-rc5-bk4-libata-dev1.patch.bz2 Still not usable here. The same errors as before when backing up: Please try 2.6.11 without any patches. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 report -- keyboard not working Linux 2.6.11 on Inspiron 1150
PCI: Using ACPI for IRQ routing ACPI: AC Adapter [AC] (on-line) ACPI: Battery Slot [BAT0] (battery present) ACPI: Lid Switch [LID] ACPI: Power Button (CM) [PBTN] ACPI: Sleep Button (CM) [SBTN] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) ACPI: Video Device [VID2] (multi-head: yes rom: no post: no) ACPI: CPU0 (power states: C1[C1] C2[C2]) ACPI: Processor [CPU0] (supports 8 throttling states) ACPI: Thermal Zone [THM] (59 C) ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 ACPI: PCI interrupt :00:02.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1 ACPI: PS/2 Mouse Controller [PS2M] at irq 12 i8042.c: Can't read CTR while initializing i8042. ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7 ACPI: PCI interrupt :00:1f.6[B] -> GSI 7 (level, low) -> IRQ 7 ACPI: PCI interrupt :02:01.0[A] -> GSI 7 (level, low) -> IRQ 7 ACPI: PCI interrupt :00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt :02:04.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11 ACPI: PCI interrupt :00:1d.7[D] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt :00:1d.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 ACPI: PCI interrupt :00:1d.1[B] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI interrupt :00:1d.2[C] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt :00:1f.5[B] -> GSI 7 (level, low) -> IRQ 7 ACPI wakeup devices: ACPI: (supports S0 S1 S3 S4 S4bios S5) More like it, hmmm? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc5-mm1] mips: calculate clock at any time
This patch changes bcu.c to calculate clock at any time.
Because clock can be changed.
Moreover, EXPORT_SYMBOL_GPLs are added to it.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/bcu.c
a/arch/mips/vr41xx/common/bcu.c
--- a-orig/arch/mips/vr41xx/common/bcu.cFri Feb 25 01:40:40 2005
+++ a/arch/mips/vr41xx/common/bcu.c Thu Mar 3 07:04:29 2005
@@ -3,7 +3,7 @@
*
* Copyright (C) 2002 MontaVista Software Inc.
*Author: Yoichi Yuasa <[EMAIL PROTECTED], or [EMAIL PROTECTED]>
- * Copyright (C) 2003-2004 Yoichi Yuasa <[EMAIL PROTECTED]>
+ * Copyright (C) 2003-2005 Yoichi Yuasa <[EMAIL PROTECTED]>
*
* 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
@@ -28,20 +28,16 @@
* Yoichi Yuasa <[EMAIL PROTECTED]>
* - Added support for NEC VR4133.
*/
-#include
-#include
#include
+#include
#include
#include
#include
#include
-#define IO_MEM_RESOURCE_START 0UL
-#define IO_MEM_RESOURCE_END0x1fffUL
-
-#define CLKSPEEDREG_TYPE1 KSEG1ADDR(0x0b14)
-#define CLKSPEEDREG_TYPE2 KSEG1ADDR(0x0f14)
+#define CLKSPEEDREG_TYPE1 (void __iomem *)KSEG1ADDR(0x0b14)
+#define CLKSPEEDREG_TYPE2 (void __iomem *)KSEG1ADDR(0x0f14)
#define CLKSP(x) ((x) & 0x001f)
#define CLKSP_VR4133(x) ((x) & 0x0007)
@@ -63,11 +59,15 @@
return vr41xx_vtclock;
}
+EXPORT_SYMBOL_GPL(vr41xx_get_vtclock_frequency);
+
unsigned long vr41xx_get_tclock_frequency(void)
{
return vr41xx_tclock;
}
+EXPORT_SYMBOL_GPL(vr41xx_get_tclock_frequency);
+
static inline uint16_t read_clkspeed(void)
{
switch (current_cpu_data.cputype) {
@@ -207,7 +207,7 @@
return tclock;
}
-static int __init vr41xx_bcu_init(void)
+void vr41xx_calculate_clock_frequency(void)
{
unsigned long pclock;
uint16_t clkspeed;
@@ -217,11 +217,6 @@
pclock = calculate_pclock(clkspeed);
vr41xx_vtclock = calculate_vtclock(clkspeed, pclock);
vr41xx_tclock = calculate_tclock(clkspeed, pclock, vr41xx_vtclock);
-
- iomem_resource.start = IO_MEM_RESOURCE_START;
- iomem_resource.end = IO_MEM_RESOURCE_END;
-
- return 0;
}
-early_initcall(vr41xx_bcu_init);
+EXPORT_SYMBOL_GPL(vr41xx_calculate_clock_frequency);
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/init.c
a/arch/mips/vr41xx/common/init.c
--- a-orig/arch/mips/vr41xx/common/init.c Fri Feb 25 01:40:31 2005
+++ a/arch/mips/vr41xx/common/init.cThu Mar 3 07:05:03 2005
@@ -1,7 +1,7 @@
/*
* init.c, Common initialization routines for NEC VR4100 series.
*
- * Copyright (C) 2003-2004 Yoichi Yuasa <[EMAIL PROTECTED]>
+ * Copyright (C) 2003-2005 Yoichi Yuasa <[EMAIL PROTECTED]>
*
* 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
@@ -18,9 +18,20 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include
+#include
#include
#include
+#include
+
+#define IO_MEM_RESOURCE_START 0UL
+#define IO_MEM_RESOURCE_END0x1fffUL
+
+static void __init iomem_resource_init(void)
+{
+ iomem_resource.start = IO_MEM_RESOURCE_START;
+ iomem_resource.end = IO_MEM_RESOURCE_END;
+}
void __init prom_init(void)
{
@@ -35,6 +46,10 @@
if (i < (argc - 1))
strcat(arcs_cmdline, " ");
}
+
+ vr41xx_calculate_clock_frequency();
+
+ iomem_resource_init();
}
unsigned long __init prom_free_prom_memory (void)
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/ksyms.c
a/arch/mips/vr41xx/common/ksyms.c
--- a-orig/arch/mips/vr41xx/common/ksyms.c Fri Feb 25 01:40:05 2005
+++ a/arch/mips/vr41xx/common/ksyms.c Thu Mar 3 00:51:33 2005
@@ -22,9 +22,6 @@
#include
-EXPORT_SYMBOL(vr41xx_get_vtclock_frequency);
-EXPORT_SYMBOL(vr41xx_get_tclock_frequency);
-
EXPORT_SYMBOL(vr41xx_set_rtclong1_cycle);
EXPORT_SYMBOL(vr41xx_read_rtclong1_counter);
EXPORT_SYMBOL(vr41xx_set_rtclong2_cycle);
diff -urN -X dontdiff a-orig/include/asm-mips/vr41xx/vr41xx.h
a/include/asm-mips/vr41xx/vr41xx.h
--- a-orig/include/asm-mips/vr41xx/vr41xx.h Wed Mar 2 01:05:57 2005
+++ a/include/asm-mips/vr41xx/vr41xx.h Thu Mar 3 07:05:43 2005
@@ -45,6 +45,7 @@
/*
* Bus Control Uint
*/
+extern unsigned long vr41xx_calculate_clock_frequency(void);
extern unsigned long vr41xx_get_vtclock_frequency(void);
extern unsigned long vr41xx_get_tclock_frequency(void);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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
On Wed, 02 Mar 2005 22:40:57 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > People don't test 2.6-rc releases because they know they are not > "release candidate, with only bug fixes" releases, which is how the rest > of the world interprets the phrase. That's not %100 true. No matter what -rc* really is, people perceive it to be something based upon it's name and whether or not it is an official release. As far as I can see it's %95 perception vs. reality. And IT IS part of the reason the -rc's are not as good as they could be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
On Wed, 2 Mar 2005 14:21:38 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]> wrote: > > Comments? > Just rename: 2..-rcX -> 2..y-preX 2.. -> 2..y-rcX 2.. -> 2..y -- 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: RFD: Kernel release numbering
On Wed, Mar 02, 2005 at 07:10:47PM -0800, Randy.Dunlap wrote: > >For it to truly be a stable kernel, the only patches I'd expect to > >drivers would be ones fixing blindingly obvious bugs. No cleanups. > >No new functionality. I'd even question new hardware support if it > >wasn't just a PCI ID addition. > > Maybe I don't understand? Is someone expecting distro > quality/stability from kernel.org kernels? My complaint is the charade of calling it 'stable' when it clearly wouldn't be anything of the sort, given that a majority of the bugs our users experienced on rebasing were driver related. The core itself may be rock-solid, but if we're continually pulling in random driver updates of questionable quality with limited testing, the result as a whole isn't stable. > I don't, but maybe I'm one of those minorities. Putting the onus on distributions to make things stable is no excuse for the ever-increasing number of regressions each release. This might sound over-dramatic, but it's the current state as far as I'm concerned. The 2.6.8->2.6.9 update for Fedora users brought a bunch of carnage that took time to shake out. 2.6.9->2.6.10 I'm still picking up the pieces of. If the 2.6.10->2.6.11 update that I'll do for Fedora in a week or two turns out to have less regressions than the previous releases, I'll be stunned. Really. Already I'm wondering how many userspace packages are going to randomly stop working as they have done in previous releases. With the clear delineation of stable/development, we were able to say things like "we won't change a user visible interface in a stable series" Now, we don't have that. So we find things ranging from slabtop to alsa-lib completely break unless you update the userspace too. regressions like this is what I'm bitching about. There's nothing a vendor can do to make such things stable (other than dropping the various patches that introduce the breakage, but at ~4000 csets per release right now, there will be stuff that gets missed). Whilst the slabinfo example was a non-driver related regression, it's a good example of how little care we're taking these days to make sure existing userspace continues to work correctly. Some may suggest the close tracking of mainline is the problem. Maybe they're right. Maybe we should have stuck with a 2.6.5 kernel until Fedora Core 2 reached end of life, and gone with the old 'have hundreds and hundreds of patches piling up' approach. But, as someone who has maintained vendor kernels that have tried both methods, the sticking close to mainline approach wins hands down. If something is broken, more often than not, I can bug the upstream developer and ask "hey, this is a wierd problem our fedora users hit, we don't have any patches against this code, can you take a look?" and developers have been very responsive, and helpful on many occasions, ultimatly leading bugs being fixed both in our kernel, and upstream. If I asked most upstream developers about a problem we've been facing with our 2.6.5 kernels, I'd get a much less helpful response. And rightly so. In their position I'd do exactly the same thing. 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: RFD: Kernel release numbering
On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote: > > This is an idea that has been brewing for some time: Andrew has mentioned > it a couple of times, I've talked to some people about it, and today Davem > sent a suggestion along similar lines to me for 2.6.12. > > Namely that we could adopt the even/odd numbering scheme that we used to > do on a minor number basis, and instead of dropping it entirely like we > did, we could have just moved it to the release number, as an indication > of what was the intent of the release. Random ideas. Why not use the already established 2.6.x.y method ? This allows development to continue on 2.6.x+1, and if needed, you should be able to bk pull the 2.6.x.y[n] tree(s) into 2.6.x+1 no ? My concern about this 'stable kernel every other release' method is that if a particular development cycle drags on for some reason, and certain bugs never got fixed in the previous release, that's a long time users have to wait until they get things fixed. It's somewhat akin to the problem with the infrequent out-of-tree merges that some subsystem maintainers have. If the latest push they do doesn't fix your bug, you typically have to wait until the next release until they do another push. 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: RFD: Kernel release numbering
On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote: > The problem with major development trees like 2.4.x vs 2.5.x was that the > release cycles were too long, and that people hated the back- and > forward-porting. That said, it did serve a purpose - people kind of knew > where they stood, even though we always ended up having to have big > changes in the stable tree too, just to keep up with a changing landscape. How about this idea, instead: At 2.6.12, make two parallel BitKeeper trees: 2.6 and 2.7 Push bugfixes into 2.6. Push *everything* that's not a bugfix into 2.7. "bk pull" the 2.6 tree into the 2.7 tree each day when you wake up. A week later, release 2.6.12.1 from the 2.6 tree, then immediately bk pull the 2.7 tree into the 2.6 tree. Release 2.6.13-rc1 at about the same time, and again only take bugfixes into the 2.6 tree. In 3-7 weeks, after a few more -rc iterations with just bugfixes, release 2.6.13. This should keep the differences between the trees down to something somewhat... sane, and, hopefully, keep the stable tree stable. People working on big changes can do them against 2.6.x if they need stability, and know that if they stay current with each 2.6.x release as they work, they should have a controllable amount of pain for merges. My thinking is simply that if you're going to use BitKeeper, you might as well abuse it for all that it's worth. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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. My first response is: this is a recipe for great confusion among users. I'd far rather see things only make it into your tree when they've been thoroughly tested (in -mm and prior to that). Following that strategy, your tree could always be relied upon to be stable and -rcs would only needed for dealing with the unforeseen interactions between otherwise mature patches. Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [request for inclusion] Filesystem in Userspace
Hi, On Wed, Mar 02, 2005 at 12:31:23PM -0800, Andrew Morton wrote: > Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > Do you have any objections to merging FUSE in mainline kernel? > > I was planning on sending FUSE into Linus in a week or two. That and > cpusets are the notable features which are 2.6.12 candidates. > > - crashdump seems permanently not-quite-ready > > - perfctr works fine, but is rather deadlocked because it is > similar-to-but-different-from ia64's perfmon, and might not be suitable > for ppc64 (although things have gone quiet on the latter front). I once asked Mikael about using PMC's from kernel-space, he told me it wouldnt be too hard to make them usable via kernel-space through perfctr. Is perfmon's API useable to kernel users? That sounds like a good point in favour of a given implementation, no? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Something is broken with SATA RAID ? [and PATA raid and reiserfs?]
Jeff Garzik wrote: On Thu, Mar 03, 2005 at 12:39:41AM +, J.A. Magallon wrote: Hi... I posted this in other mail, but now I can confirm this. I have a box with a SATA RAID-5, and with 2.6.11-rc3-mm2+libata-dev1 works like a charm as a samba server, I dropped it 12Gb from an osx client, and people does backups from W2k boxes and everything was fine. With 2.6.11-rc4-mm1, it hangs shortly after the mac starts copying files. No oops, no messages... It even hanged on a local copy (wget), so I will discard samba as the buggy piece in the puzzle. I'm going to make a definitive test with rc5-mm1 vs rc5-mm1+libata-dev1. I already know that plain rc5-mm1 hangs. I have to wait the md reconstruction of the 1.2 TB to check rc5-mm1+libata (and no user putting things there...) Please eliminate -mm and -libata-dev from the equation. Jeff I have a possibly similar issue. I'm running 2.6.11-rc4, with 5 drives. I had the usual slew of hideous Promise IDE controller problems (Maxtor's rebranded 20269's, I think -- data corruption and dma errors), so I switched them to master and slaves on the VIA chipset and one drive on sata-via through a Silicon Image adapter. On large writes (i.e. copying several gigs of small files over samba), I sometimes hang reiserfs (/home below). It'll give some error in dmesg when that happens. I have no problem with XFS. The last time this happened, there was no corruption at all (reiserfsck was clean). Any way to test this better? I'll upgrade to 2.6.11 final today. Thanks, Andy The most recent error was: md_d0p2: warning: PAP-5660: reiserfs_do_truncate: wrong result -1 of search for [27 8553 0 0xfff810007ca03a0 UNKNOWN] /proc/mdstat: Personalities : [raid0] [raid1] [raid5] md_d0 : active raid5 hdc3[0] sda3[4] hdb3[3] hdd3[2] hda3[1] 606035712 blocks level 5, 64k chunk, algorithm 2 [5/5] [U] md3 : active raid0 hdd2[0] hdb2[1] 38877056 blocks 64k chunks md2 : active raid1 hdd1[0] hdb1[1] 24410624 blocks [2/2] [UU] md1 : active raid1 hdc2[0] hda2[1] 34081792 blocks [2/2] [UU] md0 : active raid1 hdc1[0] hda1[1] 9767424 blocks [2/2] [UU] unused devices: mount says: /dev/md0 on / type ext3 (rw,noatime,acl) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev type ramfs (rw) none on /dev/pts type devpts (rw) /dev/md1 on /usr type reiserfs (rw,noatime,acl) /dev/md3 on /tmp type reiserfs (rw,acl,usrquota) /dev/md2 on /var type reiserfs (rw,noatime,acl) /dev/md/main1 on /data type xfs (rw,noatime,quota,logbufs=8) /dev/md/main2 on /home type reiserfs (rw,noatime,acl,usrquota) none on /dev/shm type tmpfs (rw,size=2000) /var/mntbackups on /mnt/backups type bind (rw,bind) /tmp/vartmp on /var/tmp type bind (rw,bind) none on /proc/bus/usb type usbfs (rw) / on /magic/root type none (rw,bind) [/dev/md/main1 is /dev/md_d0p1 and /dev/md/main2 is /dev/md_d0p2] dmesg: ock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected AGP bridge 0 agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 256M @ 0xd000 [drm] Initialized drm 1.0.0 20040925 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 128000K size 1024 blocksize loop: loaded (max 8 devices) Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot :00:0f.1 ACPI: PCI interrupt :00:0f.1[A] -> GSI 20 (level, low) -> IRQ 20 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci:00:0f.1 ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: Maxtor 6B200P0, ATA DISK drive hdb: Maxtor 6B200R0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: ST3200822A, ATA DISK drive hdd: Maxtor 6B200P0, ATA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... hda: max request size: 1024KiB hda: 398297088 sectors (203928 MB) w/8192KiB Cache, CHS=24792/255/63, UDMA(133) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 hdb: max request size: 1024KiB hdb: 398297088 sectors (203928 MB) w/16384KiB Cache, CHS=24792/255/63, UDMA(133) hdb: cache flushes supported hdb: hdb1 hdb2 hdb3 hdc: max request size: 1024KiB hdc: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(100) hdc: cache flushes supported hdc: hdc1 hdc2 hdc3 hdd: max request size: 1024KiB hdd: 398297088 sectors
Re: RFD: Kernel release numbering
Linus Torvalds wrote: On Wed, 2 Mar 2005, Jeff Garzik wrote: If we want a calming period, we need to do development like 2.4.x is done today. It's sane, understandable and it works. No. It's insane, and the only reason it works is that 2.4.x is a totally different animal. Namely it doesn't have the kind of active development AT ALL any more. It _only_ has the "even" number kind of things, and quite frankly, even those are a lot less than 2.6.x has. 2.6.x-pre: bugfixes and features 2.6.x-rc: bugfixes only And the reason it does _not_ work is that all the people we want testing sure as _hell_ won't be testing -rc versions. That's the whole point here, at least to me. I want to have people test things out, but it doesn't matter how many -rc kernels I'd do, it just won't happen. It's not a "real release". People don't test 2.6-rc releases because they know they are not "release candidate, with only bug fixes" releases, which is how the rest of the world interprets the phrase. Making them official releases in the even/odd manner is what neilb implies. You'll just be diminishing the value of releases. A "real release" won't be a real release anymore. You're just renaming the -rc that isn't really an -rc. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
On Wed, 2 Mar 2005, Jeff Garzik wrote: > > If we want a calming period, we need to do development like 2.4.x is > done today. It's sane, understandable and it works. No. It's insane, and the only reason it works is that 2.4.x is a totally different animal. Namely it doesn't have the kind of active development AT ALL any more. It _only_ has the "even" number kind of things, and quite frankly, even those are a lot less than 2.6.x has. > 2.6.x-pre: bugfixes and features > 2.6.x-rc: bugfixes only And the reason it does _not_ work is that all the people we want testing sure as _hell_ won't be testing -rc versions. That's the whole point here, at least to me. I want to have people test things out, but it doesn't matter how many -rc kernels I'd do, it just won't happen. It's not a "real release". In contrast, making it a real release, and making it clear that it's a release in its own right, might actually get people to use it. Might. Maybe. 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/
Re: Keyboard broken on Inspiron 5150 with 2.6.11
On Wednesday 02 March 2005 17:33, David Johnson wrote: > On Wednesday 02 Mar 2005 22:03, Dmitry Torokhov wrote: > > On Wed, 2 Mar 2005 21:35:16 +, David Johnson <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > > > I've just booted 2.6.11 and the keyboard on my Dell Inspiron 5150 laptop > > > doesn't work at all. I've not tried the -rc versions, but it works fine > > > with 2.6.10. > > > > Does it work if you boot with i8042.noacpi boot option? And what about > > your touchpad? > > Ah yes, it works perfectly with that boot option. > Can you check dmesg for 2.6.11 when booted _without_ i8042.noacpi for messages from ACPI and i8042 please? Do you see something like following: > ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1 > ACPI: PS/2 Mouse Controller [PS2M] at irq 12 > i8042.c: Can't read CTR while initializing i8042. -- 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/
