Re: [PATCH] scripts: Make cleanfile/cleanpatch warn about long lines
Andrew Morton wrote: > On Fri, 25 May 2007 17:58:26 -0700 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > >> Make the "cleanfile" and "cleanpatch" script warn about long lines, >> by default lines whose visual width exceeds 79 characters. >> >> Per suggestion from Auke Kok. >> >> Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> >> --- >> scripts/cleanfile | 54 ++- >> scripts/cleanpatch | 58 >> +-- > > This functionality wholly duplicates the patch-sanity-checking script > which Andy, Randy and others are working on. > > The plan is to merge that script into the tree and, once it's looking > reasonably accurate, we wire a copy of it up to the email lists so that it > autonags patch-senders over the usual trivial junk. Think of it as an > akpm-over-SMTP server. LOL. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] fix compat console unimap regression
From: Hugh Dickins <[EMAIL PROTECTED]> Date: Sat, 26 May 2007 00:39:17 +0100 (BST) > Why is it that since the 2f1a2ccb9c0de632ab07193becf5f7121794f6ae console > UTF-8 fixes went into 2.6.22-rc1, the PowerMac G5 shows only inverse video > question marks for the text on tty2-6? whereas tty1 is fine, and so is x86. > > No fault of that patch: by removing the old fallback behaviour, it reveals > that 32-bit setfont running on 64-bit kernels has only really worked on > the current console, the rest getting faked by that inadequate fallback. > > Bring the compat do_unimap_ioctl into line with the main one: PIO_UNIMAP > and GIO_UNIMAP apply to the specified tty, not redirected to fg_console. > Use the same checks, and most particularly, remember to check access_ok: > con_set_unimap and con_get_unimap are using __get_user and __put_user. > > And the compat vt_check should ask for the same capability as the main > one, CAP_SYS_TTY_CONFIG rather than CAP_SYS_ADMIN. Added in vt_ioctl's > vc_cons_allocated check for safety, though failure may well be impossible. > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> Thanks for figuring this out, I've been wondering what in the world was causing this on sparc64. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] scripts: Make cleanfile/cleanpatch warn about long lines
On Fri, 25 May 2007 17:58:26 -0700 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > Make the "cleanfile" and "cleanpatch" script warn about long lines, > by default lines whose visual width exceeds 79 characters. > > Per suggestion from Auke Kok. > > Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> > --- > scripts/cleanfile | 54 ++- > scripts/cleanpatch | 58 +-- This functionality wholly duplicates the patch-sanity-checking script which Andy, Randy and others are working on. The plan is to merge that script into the tree and, once it's looking reasonably accurate, we wire a copy of it up to the email lists so that it autonags patch-senders over the usual trivial junk. Think of it as an akpm-over-SMTP server. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
reg: modules make in Ubuntu
make[1]: Entering directory `/usr/src/linux-headers-2.6.20-15-generic' CHK include/linux/version.h CHK include/linux/utsrelease.h make[2]: *** No rule to make target `arch/i386/kernel/msr.c', needed by `arch/i386/kernel/msr.o'. Stop. make[1]: *** [arch/i386/kernel] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.20-15-generic' make: *** [all] Error 2 what the hack is this. no kernel version is having this file in this particular location as asked in error. then why this error is coming in this kernel version. TEJ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Casey Schaufler wrote:
> --- Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
>
>> AppArmor cannot assume anything about argv[0],
>>
>> and it would be a really bad idea to change the well-established semantics of
>>
>> argv[0].
>>
>> There is no actual need for looking at argv[0], though: AppArmor decides
>> based
>> on the actual pathname of the executable...
>>
> Right. My point was that if you wanted to use the gzip/gunzip
> example of a file with two names being treated differently based
> on the name accessed as an argument for AppArmor you could.
AppArmor detects the pathname of the file exec'd at the time the parent
exec's it, and not anything inside the child involving argv[0].
As such, AA can detect whether you did exec("gzip") or exec("gunzip")
and apply the policy relevant to the program. It could apply different
policies to each of them, so whether it has access to /tmp/mumble/barf
depends on whether you called it 'gzip' or 'gunzip'. Caveat: it makes no
sense to profile either gzip or gunzip in the AppArmor model, so I won't
defend what kind of policy you would put on them.
Finally, AA doesn't care what the contents of the executable are. We
assume that it is a copy of metasploit or something, and confine it to
access only the resources that the policy says.
> If
> you don't want to, that's ok too. Jeremy raised a reasonable objection,
> and AppArmor could address it if y'all chose to do so. I seriously
> doubt that enforcing the argv[0] convention would break much, and I
> also expect that if it did there's a Consultant's Retirement to be
> made fixing the security hole it points out.
>
AppArmor does address it, and I hope this explains how we detect which
of multiple hard links to a file you used to access the file without
mucking about with argv[0].
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
Security: It's not linear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
On Fedora zcat, gzip and gunzip are all links to the same file. I
can imagine (although it is a bit of a stretch) allowing a set of
users access to gunzip but not gzip (or the other way around).
That is a COMPLETE straw-man argument. I can override your "check"
with this absolutely trivial perl code:
exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";
Pathname-based checks are pretty fundamentally insecure. If you want
to protect a "name", then you should tag the "name" with security
attributes (IE: AppArmor). On the other hand, if you actually want
to protect the _data_, then tagging the _name_ is flawed; tag the
*DATA* instead.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On Friday 25 May 2007 21:40, Uwe Bugla wrote: > Am Freitag, 25. Mai 2007 20:48 schrieben Sie: > > On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote: > > > Perhaps someone reading this could try to reproduce that problem on his > > > machine. > > > Now who of the readers owes a Broadcom 4401 NIC and can please try to > > > test kernel 2.6.22-rc2-mm1? > > > > > > Those NICs have been used very very often as onboard controllers, > > > especially on ASUS boards. > > > > I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2- > > mm1 and both work fine with the BCM4401 in my laptop. > > > > Maxi > > Hello Maxi, > > That may be true for your Laptop, but it unfortunately isn't true for my ASUS > mainboard onboard controller. > > Unfortunately I cannot confirm this: > > My broadcom 4401 driver is not part of a notebook, but instead part of an > ASUS > P4PE mainboard. > > At my second attempt I went the conventional path (i. e. ignoring the fact > that > "Broadcom 4400 ethernet support appears twice in section "Network device > support": > > Whether you leave out "EISA, VLB, PCI and on board controllers" or not it > simply appears twice in kernel config! This is bug number 1. No it is NOT a bug. It simply shows again that you don't know how b44, ssb or anything related works. Would you _please_ take a look at the code, before calling features bugs. And yes, this IS a feature. It is a feature to get b44 running on an OpenWRT embedded device. These devices don't have a PCI bus. So b44 MUST NOT depend on "EISA, VLB, PCI and on board controllers". "Broadcom 4400 PCI device support" does depend on "EISA, VLB, PCI and on board controllers". Everything is correct. Bug number 1 is solved. qed > This time I do get a "good" interrupt: IRQ 21 for the the device. > > BUT: > > Trying to ping another machine fails saying: > > "destination host unreachable" > > > That means, Although the interrupt is fine now, the device is still not > functionable. And it's completely impossible that you did a mistake when configuring the device? Typo in the IP? Typo in the gateway or DNS entries? Try it again, please. And please try with current wireless-dev tree. And I simply do not get it why you suddenly get a good IRQ number, like everybody else does, without fixing The Bug (tm). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] fix compat futex code for private futexes
When the private futex support was added the compat code wasn't changed.
The result is that code using compat code which fail, e.g., because the
timeout values are not correctly passed. The following patch should
fix that.
Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>
--- kernel/futex_compat.c 2007-05-09 15:01:23.0 -0700
+++ kernel/futex_compat.c-save 2007-05-25 20:53:35.0 -0700
@@ -144,20 +144,21 @@ asmlinkage long compat_sys_futex(u32 __u
struct timespec ts;
ktime_t t, *tp = NULL;
int val2 = 0;
+ int cmd = op & FUTEX_CMD_MASK;
- if (utime && (op == FUTEX_WAIT || op == FUTEX_LOCK_PI)) {
+ if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI)) {
if (get_compat_timespec(, utime))
return -EFAULT;
if (!timespec_valid())
return -EINVAL;
t = timespec_to_ktime(ts);
- if (op == FUTEX_WAIT)
+ if (cmd == FUTEX_WAIT)
t = ktime_add(ktime_get(), t);
tp =
}
- if (op == FUTEX_REQUEUE || op == FUTEX_CMP_REQUEUE
- || op == FUTEX_CMP_REQUEUE_PI)
+ if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE
+ || cmd == FUTEX_CMP_REQUEUE_PI)
val2 = (int) (unsigned long) utime;
return do_futex(uaddr, op, val, tp, uaddr2, val2, val3);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux v2.6.22-rc3
It's Friday evening, and the US is preparing for a long three-day weekend, often considered the official start of summer here. So what's a pasty white nerd to do? You can't go out on the beach, because the goodlooking people will laugh at you, and kick sand in your face. I'm not bitter. But now you _can_ do something: you can download the latest -rc kernel, and smile smugly to yourself, knowing that you are running the latest and greatest on your machine. And suddenly it doesn't even matter that summer is coming, because you can just sit in the basement, and close the blinds, and bask in the warm light from your LCD, rather than the harsh glare of the daystar.. The geeks with embedded hardware can consider themselves doubly special (and not just because your mothers told you you are), because we've got updates to ARM, SH and Blackfin. What more could you possibly want? Some ATA updates? USB suspend problem solving? Infiniband? DVB and MMC updates? Network drivers and some fixes for silly network problems? Yeah we got them! So stop worrying about those dangerous ultraviolet rays, and instead get your Vitamin D in the form God (and the pharmaceutical industry) intended: small easily swallowed pills. Beaches are overrated anyway, the sand gets into the laptop fan and soon it won't work. May you have a great summer, Linus --- Akinobu Mita (3): i2o: destroy event queue only when drv->event is set i2o: fix notifiers when max_drivers is configured i2o: eliminate a peculiar constraint on i2o_max_drivers Alan Cox (9): pata_hpt366: Enable bits are unreliable so don't use them ata_piix: clean up libata: Kiss post_set_mode goodbye ide/pci/serverworks.c: Fix corruption/timeouts with MegaIDE hpt3x2n: Correct revision boundary pata_sis: Fix and clean up some timing setups pata_via: Handle laptops via DMI pata: Trivia pata_hpt37x: Further improvements based on the IDE updates and vendor drivers Alan Stern (10): EHCI: fix problem with BIOS handoff USB: more autosuspend timer stuff USB: remove unneeded WARN_ON USB: set the correct Interrupt interval in usb_bulk_msg USB: remove short initial timeout for device descriptor fetch USB: don't try to kzalloc 0 bytes USB: make the autosuspend workqueue thread freezable USB: handle errors in power/level attribute USB: fix ratelimit call semantics HiSax: fix error checking for hisax_register()] Alexey Dobriyan (1): Detach sched.h from mm.h Ali Ayoub (1): IB/mthca: Fix use-after-free on device restart Andi Kleen (7): x86_64: Update defconfig i386: Update defconfig x86_64: Support x86_64 in make buildtar i386: Fix K8/core2 oprofile on multiple CPUs x86_64: Support gcc 5 properly i386: Clear MCE flag on AMD K6 i386: Enable CX8/PGE CPUID bits early on VIA C3 Andrew Morton (5): USB: auerswald: fix file release handler ide serverworks warning fixes capability.h warning fix capifunc warning fixes drivers/isdn/hardware/eicon/message.c warning fixes Andrew Victor (1): [ARM] 4378/1: KS8695: Serial driver fix Andrey Borzenkov (1): USB: Fix USB OHCI Subvendor for Toshiba Portege 4000 Anton Altaparmakov (1): LDM: Fix for Windows Vista dynamic disks Anton Blanchard (2): [POWERPC] Add missing pmc_type fields in cpu_table [POWERPC] Fix typo: MMCR0_PMA0 != MMCR0_PMAO Arnaud Patard (1): i2c-s3c2410: Fix build warning Atsushi Nemoto (1): kbuild: make better section mismatch reports on i386, arm and mips Aubrey Li (3): Blackfin arch: ISP1761 doesn't work for USB flash disk Blackfin arch: dma_memcpy borken for > 64K Blackfin serial driver: fix overhead issue Auke Kok (2): e1000: Don't enable polling in open() (was: e1000: assertion hit in e1000_clean(), kernel 2.6.21.1) Add constant for FCS/CRC length (frame check sequence) Ayaz Abdulla (1): forcedeth: fix cpu irq mask Badari Pulavarty (1): optimize compat_core_sys_select() by a using stack space for small fd sets Ben Collins (2): USB: Remove duplicate IDs from option card driver Avoid zero size allocation in cache_k8_northbridges() Ben Dooks (6): [ARM] 4395/1: S3C24XX: add include of to relevant machines [ARM] 4396/1: S3C2443: Add missing HCLK clocks [ARM] 4397/1: S3C2443: remove SDI0/1 IRQ ambiguity [ARM] 4398/1: S3C2443: Fix watchdog IRQ number [ARM] 4399/2: S3C2443: Fix SMDK2443 nand timings [ARM] 4400/1: S3C24XX: Add high-speed MMC device definition Benjamin Herrenschmidt (2): [POWERPC] Fix powerpc vmlinux.lds.S [POWERPC] Fix warning in 32-bit builds with CONFIG_HIGHMEM Bernd Schmidt (1): Blackfin arch: fix signal handling bug Brian Gerst (1): i386: fix PGE mask Bryan Wu (5): Blackfin arch: add SPI MMC driver
[PATCH, RFT, v4] sata_mv: convert to new EH
Already uncovered and fixed a few bugs in v3.
Here's v4 of the sata_mv new-EH patch.
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 705a020..4a75b48 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -192,8 +192,10 @@ enum {
EDMA_ERR_DEV_DCON = (1 << 3),
EDMA_ERR_DEV_CON= (1 << 4),
EDMA_ERR_SERR = (1 << 5),
- EDMA_ERR_SELF_DIS = (1 << 7),
+ EDMA_ERR_SELF_DIS = (1 << 7), /* Gen II/IIE self-disable */
+ EDMA_ERR_SELF_DIS_5 = (1 << 8), /* Gen I self-disable */
EDMA_ERR_BIST_ASYNC = (1 << 8),
+ EDMA_ERR_TRANS_IRQ_7= (1 << 8), /* Gen IIE transprt layer irq */
EDMA_ERR_CRBQ_PAR = (1 << 9),
EDMA_ERR_CRPB_PAR = (1 << 10),
EDMA_ERR_INTRL_PAR = (1 << 11),
@@ -204,13 +206,33 @@ enum {
EDMA_ERR_LNK_CTRL_TX= (0x1f << 21),
EDMA_ERR_LNK_DATA_TX= (0x1f << 26),
EDMA_ERR_TRANS_PROTO= (1 << 31),
- EDMA_ERR_FATAL = (EDMA_ERR_D_PAR | EDMA_ERR_PRD_PAR |
- EDMA_ERR_DEV_DCON | EDMA_ERR_CRBQ_PAR |
- EDMA_ERR_CRPB_PAR | EDMA_ERR_INTRL_PAR |
- EDMA_ERR_IORDY | EDMA_ERR_LNK_CTRL_RX_2 |
- EDMA_ERR_LNK_DATA_RX |
- EDMA_ERR_LNK_DATA_TX |
- EDMA_ERR_TRANS_PROTO),
+ EDMA_ERR_OVERRUN_5 = (1 << 5),
+ EDMA_ERR_UNDERRUN_5 = (1 << 6),
+ EDMA_EH_FREEZE = EDMA_ERR_D_PAR |
+ EDMA_ERR_PRD_PAR |
+ EDMA_ERR_DEV_DCON |
+ EDMA_ERR_DEV_CON |
+ EDMA_ERR_SERR |
+ EDMA_ERR_SELF_DIS |
+ EDMA_ERR_CRBQ_PAR |
+ EDMA_ERR_CRPB_PAR |
+ EDMA_ERR_INTRL_PAR |
+ EDMA_ERR_IORDY |
+ EDMA_ERR_LNK_CTRL_RX_2 |
+ EDMA_ERR_LNK_DATA_RX |
+ EDMA_ERR_LNK_DATA_TX |
+ EDMA_ERR_TRANS_PROTO,
+ EDMA_EH_FREEZE_5= EDMA_ERR_D_PAR |
+ EDMA_ERR_PRD_PAR |
+ EDMA_ERR_DEV_DCON |
+ EDMA_ERR_DEV_CON |
+ EDMA_ERR_OVERRUN_5 |
+ EDMA_ERR_UNDERRUN_5 |
+ EDMA_ERR_SELF_DIS_5 |
+ EDMA_ERR_CRBQ_PAR |
+ EDMA_ERR_CRPB_PAR |
+ EDMA_ERR_INTRL_PAR |
+ EDMA_ERR_IORDY,
EDMA_REQ_Q_BASE_HI_OFS = 0x10,
EDMA_REQ_Q_IN_PTR_OFS = 0x14, /* also contains BASE_LO */
@@ -244,6 +266,7 @@ enum {
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN = (1 << 0),
MV_PP_FLAG_EDMA_DS_ACT = (1 << 1),
+ MV_PP_FLAG_HAD_A_RESET = (1 << 2),
};
#define IS_50XX(hpriv) ((hpriv)->hp_flags & MV_HP_50XX)
@@ -340,14 +363,14 @@ static u32 mv_scr_read(struct ata_port *ap, unsigned int
sc_reg_in);
static void mv_scr_write(struct ata_port *ap, unsigned int sc_reg_in, u32 val);
static u32 mv5_scr_read(struct ata_port *ap, unsigned int sc_reg_in);
static void mv5_scr_write(struct ata_port *ap, unsigned int sc_reg_in, u32
val);
-static void mv_phy_reset(struct ata_port *ap);
-static void __mv_phy_reset(struct ata_port *ap, int can_sleep);
static int mv_port_start(struct ata_port *ap);
static void mv_port_stop(struct ata_port *ap);
static void mv_qc_prep(struct ata_queued_cmd *qc);
static void mv_qc_prep_iie(struct ata_queued_cmd *qc);
static unsigned int mv_qc_issue(struct ata_queued_cmd *qc);
-static void mv_eng_timeout(struct ata_port *ap);
+static void mv_error_handler(struct ata_port *ap);
+static void mv_eh_freeze(struct ata_port *ap);
+static void mv_eh_thaw(struct ata_port *ap);
static int mv_init_one(struct pci_dev *pdev, const struct pci_device_id *ent);
static void mv5_phy_errata(struct mv_host_priv *hpriv, void __iomem *mmio,
@@ -371,7 +394,6 @@ static void mv6_reset_flash(struct mv_host_priv *hpriv,
void __iomem *mmio);
static void mv_reset_pci_bus(struct pci_dev *pdev, void __iomem *mmio);
static void mv_channel_reset(struct mv_host_priv *hpriv, void __iomem *mmio,
unsigned int port_no);
-static void mv_stop_and_reset(struct ata_port *ap);
static struct scsi_host_template mv_sht = {
.module = THIS_MODULE,
@@ -400,19 +422,20 @@ static const struct ata_port_operations mv5_ops = {
.exec_command = ata_exec_command,
.dev_select = ata_std_dev_select,
Re: [PATCH] AFS: Implement file locking
On May 25, 2007, at 22:23:42, J. Bruce Fields wrote: On Thu, May 24, 2007 at 05:55:54PM +0100, David Howells wrote: + /* only whole-file locks are supported */ + if (fl->fl_start != 0 || fl->fl_end != OFFSET_MAX) + return -EINVAL; Do you allow upgrades and downgrades? (Just curious.) I was actually under the impression that OpenAFS had support for byte- range locking (as well as lock upgrade/downgrade); though IIRC there was some secondary protocol. That's probably why the support is so basic at the moment; David's getting the basics in first and the more complicated stuff can come later. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Work around Dell E520 BIOS reboot bug.
On Wed, May 23, 2007 at 01:12:44PM -0600, Tim Gardner wrote: > From: Tim Gardner <[EMAIL PROTECTED]> > Subject: [PATCH] Work around Dell E520 BIOS reboot bug. > > Force Dell E520 to use the BIOS to shutdown/reboot. > > Signed-off-by: Tim Gardner <[EMAIL PROTECTED]> Acked-by: Matt Domsch <[EMAIL PROTECTED]> Thanks Tim for submitting this. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub
--- Christoph Lameter <[EMAIL PROTECTED]> wrote: > I finally figured out the second issue. Took some time to get that figure > out. Sorry. But now all the bug reports make sense. [...] Impressive Christoph. Indeed, this fixes my problem on latest -git (its hg equivalent :-)). Well done. (Tested with CONFIG_SLAB_DEBUG without slub_debug; all was well. Then with slub_debug & slabinfo -v also; again all was well. I had many LOCKDEP and its relatives also compiled in.) Now hoping it'll be in 2.6.22-rc3 :-)). > Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> > > --- > mm/slub.c |7 +++ > 1 file changed, 7 insertions(+) > > Index: slub/mm/slub.c > === > --- slub.orig/mm/slub.c 2007-05-25 18:28:42.0 -0700 > +++ slub/mm/slub.c2007-05-25 18:29:46.0 -0700 > @@ -2473,6 +2473,7 @@ void __init kmem_cache_init(void) >*/ > create_kmalloc_cache(_caches[0], "kmem_cache_node", > sizeof(struct kmem_cache_node), GFP_KERNEL); > + kmalloc_caches[0].refcount = -1; > #endif > > /* Able to allocate the per node structures */ > @@ -2520,6 +2521,12 @@ static int slab_unmergeable(struct kmem_ > if (s->ctor) > return 1; > > + /* > + * We may have set a slab to be unmergeable during bootstrap. > + */ > + if (s->refcount < 0) > + return 1; > + > return 0; > } ___ How would you spend $50,000 to create a more sustainable environment in Australia? Go to Yahoo!7 Answers and share your idea. http://advision.webevents.yahoo.com/aunz/lifestyle/answers/y7ans-babp_reg.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1: evm BUG when reading sysfs file
On Tue, 22 May 2007 03:25:48 -0400 [EMAIL PROTECTED] (Joseph Fannin) wrote: > > I've been getting this since 2.6.21-rc7-mm1: > > [2.379310] BUG: unable to handle kernel paging request at virtual address 4400d340 > [2.379491] printing eip: > [2.379573] c021c978 > [2.379656] *pdpt = 0353c001 > [2.379739] *pde = > [2.379824] Oops: [#1] > [2.379906] PREEMPT SMP > [2.380059] Modules linked in: thermal processor dm_mod > [2.380288] CPU:0 > [2.380289] EIP:0060:[]Not tainted VLI > [2.380291] EFLAGS: 00010297 (2.6.22-rc1-mm1 #2) > [2.380547] EIP is at vsnprintf+0x448/0x5d0 > [2.380633] eax: 4400d340 ebx: c348f034 ecx: 4400d340 edx: fffe > [2.380721] esi: c03e0100 edi: 4400d340 ebp: c357ecc0 esp: c357ec68 > [2.380810] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > [2.380898] Process udevtrigger (pid: 686, ti=c357e000 task=c1876df0 task.ti=c357e000) > [2.380987] Stack: c348f014 0fec c03e1c60 c03e3cec c357eccc c0499b88 c357ece0 c0282513 > [2.381428]c348f014 0fec 3cb70fcb c348f034 > [2.381867] fffe c03e017c c357ed18 0034 c0494a20 c357ece0 c021cb9f > [2.382305] Call Trace: > [2.382470] [] sprintf+0x1f/0x30 > [2.382594] [] show_uevent+0xed/0x130 > [2.382720] [] dev_attr_show+0x23/0x30 > [2.382843] [] sysfs_read_file+0x97/0x140 > [2.382968] [] vfs_read+0xaf/0x180 > [2.383096] [] kernel_read+0x3a/0x50 > [2.383221] [] evm_calc_hash+0x11c/0x240 > [2.383347] [] evm_file_free+0xb9/0x330 > [2.383470] [] __fput+0xba/0x180 > [2.383593] [] fput+0x22/0x40 > [2.383715] [] filp_close+0x47/0x70 > [2.383839] [] sys_close+0x69/0xc0 > [2.383965] [] syscall_call+0x7/0xb > [2.384092] [] 0xb7ebd0a7 > [2.384212] === > [2.384295] INFO: lockdep is turned off. > [2.384379] Code: 21 fd ff ff c6 03 25 e9 19 fd ff ff 8d 4f 04 b8 > 3b a2 3d c0 8b 55 e4 89 4d 08 8b 3f 81 ff ff 0f 00 00 0f 46 f8 89 f9 > 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 89 c6 8b 45 e0 > f6 45 > [2.386787] EIP: [] vsnprintf+0x448/0x5d0 SS:ESP 0068:c357ec68 > > This comes a bit after IMA bails out successfully, if that's relevant: > > [1.708761] ima (ima_init): No TPM chip found(rc = -19), activating > TPM-bypass! Joseph, thank you for posting this problem. I cannot reconstruct it on my machine. Could you tell us which kernel configuration you used (drivers/char/tpm and security settings) ? Does it disappear when IMA is disabled in the kernel config? Reiner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86: fix oprofile double free (was Re: Multiple free during oprofile unload)
* Alan Cox ([EMAIL PROTECTED]) wrote:
> I'd agree entirely with Dave - if you are applying a fix to something
> that is currently totally broken which may make it work and which doesn't
> affect any other bit of code then it goes into the stable tree.
And, in this case we're in luck. It's not released in any -stable tree
yet (it's queued for the next release). So there's plenty of time to
fix it up before next -stable release.
Something like below should fix it.
thanks,
-chris
--
Subject: [PATCH] x86: fix oprofile double free
From: Chris Wright <[EMAIL PROTECTED]>
Chuck reports that the recent fix from Andi to oprofile
6c977aad03a18019015035958c65b6729cd0574c introduces a double
free. Each cpu's cpu_msrs is setup to point to cpu 0's, which
causes free_msrs to free cpu 0's pointers for_each_possible_cpu.
Rather than copy the pointers, do a deep copy instead.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
arch/i386/oprofile/nmi_int.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/i386/oprofile/nmi_int.c b/arch/i386/oprofile/nmi_int.c
index a7c0783..0c39443 100644
--- a/arch/i386/oprofile/nmi_int.c
+++ b/arch/i386/oprofile/nmi_int.c
@@ -211,8 +211,14 @@ static int nmi_setup(void)
/* Assume saved/restored counters are the same on all CPUs */
model->fill_in_addresses(_msrs[0]);
for_each_possible_cpu (cpu) {
- if (cpu != 0)
- cpu_msrs[cpu] = cpu_msrs[0];
+ if (cpu != 0) {
+ memcpy(cpu_msrs[cpu].counters, cpu_msrs[0].counters,
+ sizeof(struct op_msr) * model->num_counters);
+
+ memcpy(cpu_msrs[cpu].controls, cpu_msrs[0].controls,
+ sizeof(struct op_msr) * model->num_controls);
+ }
+
}
on_each_cpu(nmi_save_registers, NULL, 0, 1);
on_each_cpu(nmi_cpu_setup, NULL, 0, 1);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] AFS: Implement file locking
On Thu, May 24, 2007 at 05:55:54PM +0100, David Howells wrote:
> +/*
> + * initialise the lock manager thread if it isn't already running
> + */
> +static int afs_init_lock_manager(void)
> +{
> + if (!afs_lock_manager) {
> + afs_lock_manager = create_singlethread_workqueue("kafs_lockd");
> + if (!afs_lock_manager)
> + return -ENOMEM;
> + }
> + return 0;
Doesn't this need some locking?
> +/*
> + * request a lock on a file on the server
> + */
> +static int afs_do_setlk(struct file *file, struct file_lock *fl)
> +{
> + struct afs_vnode *vnode = AFS_FS_I(file->f_mapping->host);
> + afs_lock_type_t type;
> + struct key *key = file->private_data;
> + int ret;
> +
> + _enter("{%x:%u},%u", vnode->fid.vid, vnode->fid.vnode, fl->fl_type);
> +
> + /* only whole-file locks are supported */
> + if (fl->fl_start != 0 || fl->fl_end != OFFSET_MAX)
> + return -EINVAL;
Do you allow upgrades and downgrades? (Just curious.)
> + /* if we've already got a readlock on the server and no waiting
> + * writelocks, then we might be able to instantly grant another
Is that comment correct? (You don't really test for "waiting
writelocks", do you?)
> + * readlock */
> + if (type == AFS_LOCK_READ &&
> + vnode->flags & (1 << AFS_VNODE_READLOCKED)) {
> + _debug("instant readlock");
> + ASSERTCMP(vnode->flags &
> + ((1 << AFS_VNODE_LOCKING) |
> +(1 << AFS_VNODE_WRITELOCKED)), ==, 0);
> + ASSERT(!list_empty(>granted_locks));
> + goto sharing_existing_lock;
> + }
> + }
--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Current utrace breaks UML
On Fri, May 25, 2007 at 06:35:13PM -0700, Roland McGrath wrote: > Oops! I overlooked the need to preserve the orig_eax value, though its > necessity is obvious. This makes me wonder about those previous > reports that UML was working OK. The one from me was on x86_64, where PTRACE_SYSEMU isn't an issue yet. > I've fixed this in the latest utrace patch set. I also wired up > sysemu on x86_64. This means 32-bit processes calling ptrace now > support it for full compatibility with native i386, which the vanilla > kernel does not. It also means it works for 64-bit ptrace calls, > whether operating on a 64-bit or a 32-bit target process. Beautiful! Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub
I finally figured out the second issue. Took some time to get that figure out. Sorry. But now all the bug reports make sense. Here is the fix SLUB: Fix NUMA / SYSFS bootstrap issue The kmem_cache_node cache is very special because it is needed for NUMA bootstrap. Under certain conditions (like for example if lockdep is enabled and significantly increases the size of spinlock_t) the structure may become exactly the size as one of the larger caches in the kmalloc array. That early during bootstrap we cannot perform merging properly. The unique id for the kmem_cache_node cache will match one of the kmalloc array. Sysfs will complain about a duplicate directory entry. All of this occurs while the console is not yet fully operational. Thus boot may appear to be silently failing. The kmem_cache_node cache is very special. During early boostrap the main allocation function is not operational yet and so we have to run our own small special alloc function during early boot. It is also special in that it is never freed. We really do not want any merging on that cache. Set the refcount -1 and forbid merging of slabs that have a negative refcount. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/slub.c |7 +++ 1 file changed, 7 insertions(+) Index: slub/mm/slub.c === --- slub.orig/mm/slub.c 2007-05-25 18:28:42.0 -0700 +++ slub/mm/slub.c 2007-05-25 18:29:46.0 -0700 @@ -2473,6 +2473,7 @@ void __init kmem_cache_init(void) */ create_kmalloc_cache(_caches[0], "kmem_cache_node", sizeof(struct kmem_cache_node), GFP_KERNEL); + kmalloc_caches[0].refcount = -1; #endif /* Able to allocate the per node structures */ @@ -2520,6 +2521,12 @@ static int slab_unmergeable(struct kmem_ if (s->ctor) return 1; + /* +* We may have set a slab to be unmergeable during bootstrap. +*/ + if (s->refcount < 0) + return 1; + return 0; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Hello. Casey Schaufler wrote: > Sorry, but I don't understand your objection. If AppArmor is configured > to allow everyone access to /bin/gzip but only some people access to > /bin/gunzip and (important detail) the single binary uses argv[0] > as documented and (another important detail) there aren't other links > named gunzip to the binary (ok, that's lots of if's) you should be fine. The argv[0] defines the default behavior of hard linked or symbolic linked programs, but the behavior can be overridden using commandline options. If you want to allow access to /bin/gzip but deny access to /bin/gunzip , you also need to deny access to "/bin/gzip -d" "/bin/gzip --decompress" "/bin/gzip --uncompress". It is impossible to do so because options to override the default behavior depends on program's design and you can't know what programs and what options are there in the system. Even if you know all programs and all options in the system, it is a too tough job to find and reject options that override the default behavior in the kernel space. > > Well, my point was exactly that App Armor doesn't (as far as I know) do > > anything to enforce the argv[0] convention, > Sounds like an opportunity for improvement then. There are (I think) three types of program invocation. (1) Invocation of hard linked programs. /bin/gzip and /bin/gunzip and /bin/zcat are hard links. There is no problem because you can know which pathname was requested using d_namespace_path() with "struct linux_binprm"->file . (2) Invocation of symbolic linked programs. /sbin/pidof is a symbolic link to /sbin/killall . There is a problem because you can't know which pathname was requested using d_namespace_path() with "struct linux_binprm"->file because the symbolic links were already derefernced inside open_exec(). To know which pathname was requested, you need to lookup using "struct linux_binprm"->filename without LOOKUP_FOLLOW and then use d_namespace_path(). Although there is a race condition that the pathname the symbolic link "struct linux_binprm"->filename points to may change, but it is inevitable because you can't get dentry and vfsmount of both "without LOOKUP_FOLLOW flag" and "with LOOKUP_FOLLOW flag" at the same time. (3) Invocation of dynamically created programs with random names. /usr/sbin/logrotate creates files patterned /tmp/logrotate.?? and executes these dynamically created files. To keep execution of these dynamically created files under control, you need to aggregate pathnames of these files. AppArmor can't define profile if the pathname of programs is random, can it? Usually the argv[0] and the "struct linux_binprm"->filename are the same, but if you want to do something with argv[0], you will need to handle the (2) case to see whether the argv[0] and "struct linux_binprm"->filename are the same. 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: Current utrace breaks UML
> UML, obviously. Below is a smaller test. orig_eax is wrong, so you > can't read the system call number from the process. Oops! I overlooked the need to preserve the orig_eax value, though its necessity is obvious. This makes me wonder about those previous reports that UML was working OK. I refined the test case a little and that's in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241408 I've fixed this in the latest utrace patch set. I also wired up sysemu on x86_64. This means 32-bit processes calling ptrace now support it for full compatibility with native i386, which the vanilla kernel does not. It also means it works for 64-bit ptrace calls, whether operating on a 64-bit or a 32-bit target process. 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: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
On May 25, 2007 17:58 +1000, Neil Brown wrote: >These devices would find it very hard to support BIO_RW_BARRIER. >Doing this would require keeping track of all in-flight requests >(which some, possibly all, of the above don't) and then: > When a BIO_RW_BARRIER request arrives: > wait for all pending writes to complete > call blkdev_issue_flush on all devices > issue the barrier write to the target device(s) >as BIO_RW_BARRIER, > if that is -EOPNOTSUP, re-issue, wait, flush. We noticed when testing the SLES10 kernel (which has barriers enabled by default) that ext3 write throughput went from about 170MB/s to about 130MB/s (on high-end RAID storage using no-op scheduler). The reason (as far as we could tell) is that the barriers are implemented by flushing and waiting for all previosly submitted IOs to finish, but all that ext3/jbd really care about is that the journal blocks are safely on disk. Since the journal blocks are only a small fraction of the total IO in flight, the barrier + write cache ends up being a lot worse than just doing synchronous IO with the write cache disabled because no new IO can be submitted past the barrier, and since that IO is large and contiguous it might complete much faster than the scattered metadata updates that are also being checkpointed to disk from the previous transactions. With jbd there can be both a running and a committing transaction, and multiple checkpointing transactions, and the use of barriers breaks this important optimization. If ext3 used an external journal this problem would be avoided, but then there isn't really a need for barriers in the first place, since the jbd code already will handle the wait for the commit block itself. We've got a pretty-much complete version of the ext3 journal checksumming patch that avoids the need to do the pre-commit barrier, since the checksum can verify at recovery time whether all of the transaction's blocks made it to disk or not (which is what the commit block is all about in the end). Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] scripts: Make cleanfile/cleanpatch warn about long lines
Make the "cleanfile" and "cleanpatch" script warn about long lines,
by default lines whose visual width exceeds 79 characters.
Per suggestion from Auke Kok.
Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
---
scripts/cleanfile | 54 ++-
scripts/cleanpatch | 58 +--
2 files changed, 107 insertions(+), 5 deletions(-)
diff --git a/scripts/cleanfile b/scripts/cleanfile
index f1ba8aa..cefd29e 100755
--- a/scripts/cleanfile
+++ b/scripts/cleanfile
@@ -7,7 +7,9 @@
use bytes;
use File::Basename;
-#
+# Default options
+$max_width = 79;
+
# Clean up space-tab sequences, either by removing spaces or
# replacing them with tabs.
sub clean_space_tabs($)
@@ -48,9 +50,49 @@ sub clean_space_tabs($)
return $lo;
}
+# Compute the visual width of a string
+sub strwidth($) {
+no bytes; # Tab alignment depends on characters
+
+my($li) = @_;
+my($c, $i);
+my $pos = 0;
+my $mlen = 0;
+
+for ($i = 0; $i < length($li); $i++) {
+ $c = substr($li,$i,1);
+ if ($c eq "\t") {
+ $pos = ($pos+8) & ~7;
+ } elsif ($c eq "\n") {
+ $mlen = $pos if ($pos > $mlen);
+ $pos = 0;
+ } else {
+ $pos++;
+ }
+}
+
+$mlen = $pos if ($pos > $mlen);
+return $mlen;
+}
+
$name = basename($0);
-foreach $f ( @ARGV ) {
[EMAIL PROTECTED] = ();
+
+while (defined($a = shift(@ARGV))) {
+if ($a =~ /^-/) {
+ if ($a eq '-width' || $a eq '-w') {
+ $max_width = shift(@ARGV)+0;
+ } else {
+ print STDERR "Usage: $name [-width #] files...\n";
+ exit 1;
+ }
+} else {
+ push(@files, $a);
+}
+}
+
+foreach $f ( @files ) {
print STDERR "$name: $f\n";
if (! -f $f) {
@@ -90,8 +132,10 @@ foreach $f ( @ARGV ) {
@blanks = ();
@lines = ();
+$lineno = 0;
while ( defined($line = ) ) {
+ $lineno++;
$in_bytes += length($line);
$line =~ s/[ \t\r]*$//; # Remove trailing spaces
$line = clean_space_tabs($line);
@@ -107,6 +151,12 @@ foreach $f ( @ARGV ) {
@blanks = ();
$blank_bytes = 0;
}
+
+ $l_width = strwidth($line);
+ if ($max_width && $l_width > $max_width) {
+ print STDERR
+ "$f:$lineno: line exceeds $max_width characters ($l_width)\n";
+ }
}
# Any blanks at the end of the file are discarded
diff --git a/scripts/cleanpatch b/scripts/cleanpatch
index a53f987..9680d03 100755
--- a/scripts/cleanpatch
+++ b/scripts/cleanpatch
@@ -7,7 +7,9 @@
use bytes;
use File::Basename;
-#
+# Default options
+$max_width = 79;
+
# Clean up space-tab sequences, either by removing spaces or
# replacing them with tabs.
sub clean_space_tabs($)
@@ -48,9 +50,49 @@ sub clean_space_tabs($)
return $lo;
}
+# Compute the visual width of a string
+sub strwidth($) {
+no bytes; # Tab alignment depends on characters
+
+my($li) = @_;
+my($c, $i);
+my $pos = 0;
+my $mlen = 0;
+
+for ($i = 0; $i < length($li); $i++) {
+ $c = substr($li,$i,1);
+ if ($c eq "\t") {
+ $pos = ($pos+8) & ~7;
+ } elsif ($c eq "\n") {
+ $mlen = $pos if ($pos > $mlen);
+ $pos = 0;
+ } else {
+ $pos++;
+ }
+}
+
+$mlen = $pos if ($pos > $mlen);
+return $mlen;
+}
+
$name = basename($0);
-foreach $f ( @ARGV ) {
[EMAIL PROTECTED] = ();
+
+while (defined($a = shift(@ARGV))) {
+if ($a =~ /^-/) {
+ if ($a eq '-width' || $a eq '-w') {
+ $max_width = shift(@ARGV)+0;
+ } else {
+ print STDERR "Usage: $name [-width #] files...\n";
+ exit 1;
+ }
+} else {
+ push(@files, $a);
+}
+}
+
+foreach $f ( @files ) {
print STDERR "$name: $f\n";
if (! -f $f) {
@@ -86,6 +128,7 @@ foreach $f ( @ARGV ) {
$in_bytes = 0;
$out_bytes = 0;
+$lineno = 0;
@lines = ();
@@ -93,10 +136,12 @@ foreach $f ( @ARGV ) {
$err = 0;
while ( defined($line = ) ) {
+ $lineno++;
$in_bytes += length($line);
if (!$in_hunk) {
- if ($line =~ /[EMAIL
PROTECTED]@\s+\-([0-9]+),([0-9]+)\s+\+([0-9]+),([0-9]+)[EMAIL PROTECTED]@/) {
+ if ($line =~
+ /[EMAIL
PROTECTED]@\s+\-([0-9]+),([0-9]+)\s+\+([0-9]+),([0-9]+)[EMAIL PROTECTED]@/) {
$minus_lines = $2;
$plus_lines = $4;
if ($minus_lines || $plus_lines) {
@@ -117,6 +162,13 @@ foreach $f ( @ARGV ) {
$text =~ s/[ \t\r]*$//; # Remove trailing spaces
$text = clean_space_tabs($text);
+ $l_width = strwidth($text);
+ if ($max_width && $l_width > $max_width) {
+ print STDERR
+ "$f:$lineno: adds line exceeds $max_width ",
+
Re: [ckrm-tech] [RFC] [PATCH 0/3] Add group fairness to CFS
Srivatsa Vaddagiri wrote: Good example :) USER2's single task will have to share its CPU with USER1's 50 tasks (unless we modify the smpnice load balancer to disregard cpu affinity that is - which I would not prefer to do). I don't think that ignoring cpu affinity is an option. Setting the cpu affinity of tasks is a deliberate policy action on the part of the system administrator and has to be honoured. Load balancing has to do the best it can in these circumstances which may mean sub optimal distribution of the load BUT it is result of a deliberate policy decision by the system administrator. Ingo/Peter, any thoughts here? CFS and smpnice probably is "broken" with respect to such example as above albeit for nice-based tasks. See above. I think that faced with cpu affinity use by the system administrator that smpnice will tend towards a task to cpu allocation that is (close to) the best that can be achieved without violating the cpu affinity assignments. (It may take a little longer than normal but it should get there eventually.) You have to assume that the system administrator knows what (s)he's doing and is willing to accept the impact of their policy decision on the overall system performance. Having said that, if it was deemed necessary you could probably increase the speed at which the load balancer converged on a good result in the face of cpu affinity by keeping a "pinned weighted load" value for each run queue and using that to modify find_busiest_group() and find_busiest_queue() to be a bit smarter. But I'm not sure that it would be worth the added complexity. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] libata fixes
Mikael Pettersson wrote:
On Fri, 25 May 2007 18:03:07 -0400, Jeff Garzik wrote:
Jeff Garzik (4):
[libata] sata_promise: fix flags typo
...
--- a/drivers/ata/sata_promise.c
+++ b/drivers/ata/sata_promise.c
@@ -297,7 +297,7 @@ static const struct ata_port_info pdc_port_info[] = {
/* board_2057x_pata */
{
- .flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS,
+ .flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS |
PDC_FLAG_GEN_II,
.pio_mask = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
Acked-by: Mikael Pettersson <[EMAIL PROTECTED]>
Good catch. This typo would have prevented pdc_host_intr()
from detecting GEN_II-specific errors on the PATA port.
Oops -- I should have credited Al Viro for the catch, in the changelog.
This email hereby corrects the record :)
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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
On Fri, May 25, 2007 at 07:48:14PM -0400, Jeff Garzik wrote:
>
> Is this for -stable or upstream? I got confused with all the patches
> flying about.
>
> Send it to me, if it's for upstream.
It's for upstream. Once you take then I'll rediff it for stable.
[E1000]: Restore netif_poll_enable call but make sure IRQs are off
This restores the previously removed netif_poll_enable call in
e1000_open. It's needed on all but the first call to e1000_open
for a NIC as e1000_close always calls netif_poll_disable.
netif_poll_enable can only be called safely if no polls have been
scheduled. This should be the case as long as we don't enter our
IRQ handler.
In order to guarantee this we explicitly disable IRQs as early
as possible when we're probing the NIC.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index cbc7feb..9ec35b7 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1325,7 +1325,10 @@ e1000_sw_init(struct e1000_adapter *adapter)
spin_lock_init(>tx_queue_lock);
#endif
- atomic_set(>irq_sem, 1);
+ /* Explicitly disable IRQ since the NIC can be in any state. */
+ atomic_set(>irq_sem, 0);
+ e1000_irq_disable(adapter);
+
spin_lock_init(>stats_lock);
set_bit(__E1000_DOWN, >flags);
@@ -1431,6 +1434,10 @@ e1000_open(struct net_device *netdev)
/* From here on the code is the same as e1000_up() */
clear_bit(__E1000_DOWN, >flags);
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_enable(netdev);
+#endif
+
e1000_irq_enable(adapter);
/* fire a link status change interrupt to start the watchdog */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
trivial typo in CodingStyle patch
Hello, I casually noticed this trivial typo while lurking the mailing list archives: Signed-off-by: Auke Kok <[EMAIL PROTECTED]> [...] diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index f518395..3635b38 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -409,7 +409,36 @@ out: return result; } - Chapter 8: Commenting + Chapyer 8: Tests s/Chapyer/Chapter/ Claudio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] libata fixes
On Fri, 25 May 2007 18:03:07 -0400, Jeff Garzik wrote:
>Jeff Garzik (4):
> [libata] sata_promise: fix flags typo
...
>--- a/drivers/ata/sata_promise.c
>+++ b/drivers/ata/sata_promise.c
>@@ -297,7 +297,7 @@ static const struct ata_port_info pdc_port_info[] = {
>
> /* board_2057x_pata */
> {
>- .flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS,
>+ .flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS |
> PDC_FLAG_GEN_II,
> .pio_mask = 0x1f, /* pio0-4 */
> .mwdma_mask = 0x07, /* mwdma0-2 */
Acked-by: Mikael Pettersson <[EMAIL PROTECTED]>
Good catch. This typo would have prevented pdc_host_intr()
from detecting GEN_II-specific errors on the PATA port.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, 25 May 2007 16:12:57 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, May 25, 2007 at 06:01:09PM -0500, Matt Mackall wrote:
> > Bisect sequence went 56+ 84+ 98+ 105- 102- 100+ 101+. Looks like 102's
> > to blame:
> >
> > driver-core-check-return-code-of-sysfs_create_link.patch
> >
> > From: Cornelia Huck <[EMAIL PROTECTED]>
> >
> > Check for return value of sysfs_create_link() in device_add() and
> > device_rename(). Add helper functions device_add_class_symlinks() and
> > device_remove_class_symlinks() to make the code easier to read.
>
> {sigh}
>
> This wouldn't be the first time this patch has broken things :(
Why does checking these errors cause ipw2200 to fail?
> Andrew, can you drop this from your tree?
Would prefer that we debug things first. It could be that ipw2200 is
trying to create symlinks which already exist. This might indicate a
programming error in ipw2200, which is what the patch is *for*. If it
is indeed an ipw2200 bug then the lesson is that we should have been checking
for errors on day one - that way, we'd never have shipped a buggy ipw2200
driver.
I have an ipw2200 - I'll see if I can reproduce this and I'll add some
debugging code in there. Probably that debugging code should become
permanent.
> Cornelia, can you rework this to not break things?
Things might be already broken?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper
Ben Collins wrote: > On Fri, 2007-05-25 at 16:28 -0700, H. Peter Anvin wrote: >> Jesse Barnes wrote: >>> But how often do you have to debug bootloader or compressed boot code? In >>> fact, most debug output like this isn't very useful after some initial >>> debugging, so we usually take it out. I'm not sure why this would be any >>> different... >>> >> You're asking me this? >> >> I get to hear all the time about some new platform -- sometimes exotic, >> sometimes not -- breaking early boot. > > Truth be told, I'd much rather just remove the informational pustr's and > leave the error ones enabled. If it's acceptable, I can just remove > those lines, or make them only work with -DDEBUG. The problem with that is you don't have any idea how far a boot proceeded before a hang. That's actually a very important piece of information. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper
On Fri, 2007-05-25 at 16:28 -0700, H. Peter Anvin wrote: > Jesse Barnes wrote: > > > > But how often do you have to debug bootloader or compressed boot code? In > > fact, most debug output like this isn't very useful after some initial > > debugging, so we usually take it out. I'm not sure why this would be any > > different... > > > > You're asking me this? > > I get to hear all the time about some new platform -- sometimes exotic, > sometimes not -- breaking early boot. Truth be told, I'd much rather just remove the informational pustr's and leave the error ones enabled. If it's acceptable, I can just remove those lines, or make them only work with -DDEBUG. -- Ubuntu : http://www.ubuntu.com/ Linux1394: http://wiki.linux1394.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper
On Friday, May 25, 2007 4:43:41 H. Peter Anvin wrote: > Jesse Barnes wrote: > > Right, but you're special that way. And moreover, you would know how to > > add such debug statements as needed. But is this output something we > > really need enabled unconditionally for everyone? > > *I* can do that, yes, but I usually don't have access to the platform in > question. > > As such I really don't want to see this as a compilation option. Make > it a runtime option[*] so the user with the problematic machine. > > > I personally don't care that much, aside from the feeling that we have > > way too many printks in general... > > [*] FWIW, my setup rewrite has a proper command-line parser in it, so we > can use the command line from the start. Yeah, that sounds much better. Then it can just be under the usual 'debug' command line option. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
Kok, Auke wrote: Herbert Xu wrote: On Fri, May 25, 2007 at 11:04:04PM +1000, Herbert Xu wrote: [E1000]: Call netif_poll_enable in e1000_open Here is a better one. [E1000]: Restore netif_poll_enable call but make sure IRQs are off This restores the previously removed netif_poll_enable call in e1000_open. It's needed on all but the first call to e1000_open for a NIC as e1000_close always calls netif_poll_disable. netif_poll_enable can only be called safely if no polls have been scheduled. This should be the case as long as we don't enter our IRQ handler. In order to guarantee this we explicitly disable IRQs as early as possible when we're probing the NIC. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Ack! this also fixes all the issues we had seen ourselves. I took a bit of time to get our labs to test it. Who can pick this patch up for us? Jeff ? Is this for -stable or upstream? I got confused with all the patches flying about. Send it to me, if it's for upstream. 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: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper
Jesse Barnes wrote: > > Right, but you're special that way. And moreover, you would know how to add > such debug statements as needed. But is this output something we really need > enabled unconditionally for everyone? > *I* can do that, yes, but I usually don't have access to the platform in question. As such I really don't want to see this as a compilation option. Make it a runtime option[*] so the user with the problematic machine. > I personally don't care that much, aside from the feeling that we have way > too > many printks in general... [*] FWIW, my setup rewrite has a proper command-line parser in it, so we can use the command line from the start. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, 2007-05-25 at 16:12 -0700, Greg KH wrote:
> On Fri, May 25, 2007 at 06:01:09PM -0500, Matt Mackall wrote:
> > Bisect sequence went 56+ 84+ 98+ 105- 102- 100+ 101+. Looks like 102's
> > to blame:
> >
> > driver-core-check-return-code-of-sysfs_create_link.patch
> >
> > From: Cornelia Huck <[EMAIL PROTECTED]>
> >
> > Check for return value of sysfs_create_link() in device_add() and
> > device_rename(). Add helper functions device_add_class_symlinks() and
> > device_remove_class_symlinks() to make the code easier to read.
>
> {sigh}
>
> This wouldn't be the first time this patch has broken things :(
>
> Andrew, can you drop this from your tree?
>
> Cornelia, can you rework this to not break things?
Before we continue that road, we should define the expected behavior for
the "cleanup" in error paths. Implementing that transaction-like model,
to rewind a the complete device-creation when something like a symlink
can't be created, may not always be the right thing to do.
I think in most cases, we just want to write something like that to the
error logs and continue, instead of letting a whole subsystem fail, or
in the worst case, prevent the box from booting up.
Thanks,
Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fix compat console unimap regression
Why is it that since the 2f1a2ccb9c0de632ab07193becf5f7121794f6ae console
UTF-8 fixes went into 2.6.22-rc1, the PowerMac G5 shows only inverse video
question marks for the text on tty2-6? whereas tty1 is fine, and so is x86.
No fault of that patch: by removing the old fallback behaviour, it reveals
that 32-bit setfont running on 64-bit kernels has only really worked on
the current console, the rest getting faked by that inadequate fallback.
Bring the compat do_unimap_ioctl into line with the main one: PIO_UNIMAP
and GIO_UNIMAP apply to the specified tty, not redirected to fg_console.
Use the same checks, and most particularly, remember to check access_ok:
con_set_unimap and con_get_unimap are using __get_user and __put_user.
And the compat vt_check should ask for the same capability as the main
one, CAP_SYS_TTY_CONFIG rather than CAP_SYS_ADMIN. Added in vt_ioctl's
vc_cons_allocated check for safety, though failure may well be impossible.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
---
fs/compat_ioctl.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
--- 2.6.22-rc2/fs/compat_ioctl.c2007-05-13 05:40:57.0 +0100
+++ linux/fs/compat_ioctl.c 2007-05-25 21:25:34.0 +0100
@@ -1194,6 +1194,7 @@ static int vt_check(struct file *file)
{
struct tty_struct *tty;
struct inode *inode = file->f_path.dentry->d_inode;
+ struct vc_data *vc;
if (file->f_op->ioctl != tty_ioctl)
return -EINVAL;
@@ -1204,12 +1205,16 @@ static int vt_check(struct file *file)
if (tty->driver->ioctl != vt_ioctl)
return -EINVAL;
-
+
+ vc = (struct vc_data *)tty->driver_data;
+ if (!vc_cons_allocated(vc->vc_num)) /* impossible? */
+ return -ENOIOCTLCMD;
+
/*
* To have permissions to do most of the vt ioctls, we either have
-* to be the owner of the tty, or super-user.
+* to be the owner of the tty, or have CAP_SYS_TTY_CONFIG.
*/
- if (current->signal->tty == tty || capable(CAP_SYS_ADMIN))
+ if (current->signal->tty == tty || capable(CAP_SYS_TTY_CONFIG))
return 1;
return 0;
}
@@ -1310,16 +1315,28 @@ static int do_unimap_ioctl(unsigned int
struct unimapdesc32 tmp;
struct unimapdesc32 __user *user_ud = compat_ptr(arg);
int perm = vt_check(file);
-
- if (perm < 0) return perm;
+ struct vc_data *vc;
+
+ if (perm < 0)
+ return perm;
if (copy_from_user(, user_ud, sizeof tmp))
return -EFAULT;
+ if (tmp.entries)
+ if (!access_ok(VERIFY_WRITE, compat_ptr(tmp.entries),
+ tmp.entry_ct*sizeof(struct unipair)))
+ return -EFAULT;
+ vc = ((struct tty_struct *)file->private_data)->driver_data;
switch (cmd) {
case PIO_UNIMAP:
- if (!perm) return -EPERM;
- return con_set_unimap(vc_cons[fg_console].d, tmp.entry_ct,
compat_ptr(tmp.entries));
+ if (!perm)
+ return -EPERM;
+ return con_set_unimap(vc, tmp.entry_ct,
+ compat_ptr(tmp.entries));
case GIO_UNIMAP:
- return con_get_unimap(vc_cons[fg_console].d, tmp.entry_ct,
&(user_ud->entry_ct), compat_ptr(tmp.entries));
+ if (!perm && fg_console != vc->vc_num)
+ return -EPERM;
+ return con_get_unimap(vc, tmp.entry_ct, &(user_ud->entry_ct),
+ compat_ptr(tmp.entries));
}
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper
On Friday, May 25, 2007 4:28:18 H. Peter Anvin wrote: > Jesse Barnes wrote: > > But how often do you have to debug bootloader or compressed boot code? > > In fact, most debug output like this isn't very useful after some initial > > debugging, so we usually take it out. I'm not sure why this would be any > > different... > > You're asking me this? > > I get to hear all the time about some new platform -- sometimes exotic, > sometimes not -- breaking early boot. Right, but you're special that way. And moreover, you would know how to add such debug statements as needed. But is this output something we really need enabled unconditionally for everyone? I personally don't care that much, aside from the feeling that we have way too many printks in general... Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper
Jesse Barnes wrote: > > But how often do you have to debug bootloader or compressed boot code? In > fact, most debug output like this isn't very useful after some initial > debugging, so we usually take it out. I'm not sure why this would be any > different... > You're asking me this? I get to hear all the time about some new platform -- sometimes exotic, sometimes not -- breaking early boot. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper
On Friday, May 25, 2007 12:45:40 H. Peter Anvin wrote: > Ben Collins wrote: > > On Fri, 2007-05-25 at 13:33 +0200, Andi Kleen wrote: > >> Ben Collins <[EMAIL PROTECTED]> writes: > >> > >> Why? > > > > Because there's no other way to make the kernel totally quiet. We've > > been patching this out so that the boot sequence has that "clean look". > > > > Other than that, it's useless :) > > Worse than that, it's harmful. > > "Clean look" means "undebuggable." But how often do you have to debug bootloader or compressed boot code? In fact, most debug output like this isn't very useful after some initial debugging, so we usually take it out. I'm not sure why this would be any different... Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 06:01:09PM -0500, Matt Mackall wrote:
> Bisect sequence went 56+ 84+ 98+ 105- 102- 100+ 101+. Looks like 102's
> to blame:
>
> driver-core-check-return-code-of-sysfs_create_link.patch
>
> From: Cornelia Huck <[EMAIL PROTECTED]>
>
> Check for return value of sysfs_create_link() in device_add() and
> device_rename(). Add helper functions device_add_class_symlinks() and
> device_remove_class_symlinks() to make the code easier to read.
{sigh}
This wouldn't be the first time this patch has broken things :(
Andrew, can you drop this from your tree?
Cornelia, can you rework this to not break things?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 04:01:52PM -0500, Matt Mackall wrote: > On Fri, May 25, 2007 at 12:53:19PM -0500, Matt Mackall wrote: > > On Fri, May 25, 2007 at 07:37:46PM +0200, Kay Sievers wrote: > > > On 5/25/07, Greg KH <[EMAIL PROTECTED]> wrote: > > > >On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: > > > >> 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't > > > >> matter. Bringing up the interface manually still works, so I suspect > > > >> this is sysfs or HAL related again. Again, Debian unstable so > > > >> userspace is quite up-to-date. > > > > > > > >I don't have any driver model changes that affect network devices in my > > > >tree. Could you go through and bisect the -mm tree to see if you can > > > >find the patch that causes this? > > > > > > Does it work, when you unload and load the kernel module? > > > > rmmod followed by insmod had no effect. > > > > > Does it work when you restart HAL and then NetworkManager? > > > > I restarted dbus, which stopped and restarted HAL and NM. No effect. > > > > > Can you compare the sections for the wireless card in the output of > > > "lshal"? > > > > The unhappy one looks like this: > > > > udi = '/org/freedesktop/Hal/devices/pci_8086_4220' > > info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) > > linux.subsystem = 'pci' (string) > > linux.hotplug_type = 1 (0x1) (int) > > pci.subsys_product = 'Unknown (0x2711)' (string) > > pci.subsys_vendor = 'Intel Corporation' (string) > > info.product = 'PRO/Wireless 2200BG Network Connection' (string) > > pci.product = 'PRO/Wireless 2200BG Network Connection' (string) > > info.vendor = 'Intel Corporation' (string) > > pci.vendor = 'Intel Corporation' (string) > > pci.device_protocol = 0 (0x0) (int) > > pci.device_subclass = 128 (0x80) (int) > > pci.device_class = 2 (0x2) (int) > > pci.subsys_vendor_id = 32902 (0x8086) (int) > > pci.subsys_product_id = 10001 (0x2711) (int) > > pci.vendor_id = 32902 (0x8086) (int) > > pci.product_id = 16928 (0x4220) (int) > > info.linux.driver = 'ipw2200' (string) > > pci.linux.sysfs_path = > > '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) > > info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) > > info.bus = 'pci' (string) > > linux.sysfs_path_device = > > '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) > > linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' > > (string) > > > > Will let you know when my bisecting finds a happy one. > > Here's a happy one: > > udi = '/org/freedesktop/Hal/devices/pci_8086_4220' > info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) > linux.subsystem = 'pci' (string) > linux.hotplug_type = 1 (0x1) (int) > pci.subsys_product = 'Unknown (0x2711)' (string) > pci.subsys_vendor = 'Intel Corporation' (string) > info.product = 'PRO/Wireless 2200BG Network Connection' (string) > pci.product = 'PRO/Wireless 2200BG Network Connection' (string) > info.vendor = 'Intel Corporation' (string) > pci.vendor = 'Intel Corporation' (string) > pci.device_protocol = 0 (0x0) (int) > pci.device_subclass = 128 (0x80) (int) > pci.device_class = 2 (0x2) (int) > pci.subsys_vendor_id = 32902 (0x8086) (int) > pci.subsys_product_id = 10001 (0x2711) (int) > pci.vendor_id = 32902 (0x8086) (int) > pci.product_id = 16928 (0x4220) (int) > info.linux.driver = 'ipw2200' (string) > pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' > (string) > info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) > info.bus = 'pci' (string) > linux.sysfs_path_device = > '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) > linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' > (string) > > Look the same to me. > > So far I'm down to: > > patch 56: good > patch 113: bad > > 56 powerpc-ps3-use-__maybe_unused.patch > 57 do-not-select-macintosh-drivers-by-default.patch > 58 powerpc-promc-remove-undef-printk.patch > 59 powerpc-fix-kconfig-select-warning-with-ucc_fast.patch > 60 8xx-mpc885ads-pcmcia-support.patch > 61 8xx-mpc885ads-pcmcia-support-fix.patch > 62 8xx-fix-whitespace-and-indentation.patch > 63 dts-kill-hardcoded-phandles.patch > 64 gregkh-driver-debugfs-add-rename-for-debugfs-files.patch > 65 > gregkh-driver-update-documentation-driver-model-platformtxt.patch > 66 > gregkh-driver-driver-core-keep-physdev-for-old-struct-class_device.patch > 67 gregkh-driver-driver-core-kill-unused-code.patch > 68 gregkh-driver-howto-removing-duplicated-entry.patch > 69 gregkh-driver-dmi-based-module-autoloading.patch > 70 gregkh-driver-uio.patch > 71 gregkh-driver-uio-documentation.patch > 72 gregkh-driver-uio-hilscher-cif-card-driver.patch > 73
Re: [PATCH] MIPS: Transform old-style macros to newer "__noreturn" standard.
On 5/26/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: >> >> Sorry to say, but weren't you the person who didn't recognize !! as the >> idiomatic booleanizing operator? > > Yes, of course, please prove a link / connection between that and this? > Very simple: it shows a lack of understanding of idiomatic use of C. Ah, I could lecture / *prove* to you how this argument ad hominem is *absolutely* fallacious and nonsense, but I'll leave that just now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/7] ps3: Storage Driver Probing
On Fri, 2007-05-25 at 21:48 +0200, Geert Uytterhoeven wrote: > > > + msleep_interruptible(ms); > > > + if (ms < 6) > > > + ms <<= 1; > > > > Is this timeout only for the disk spinup, or also for detecting > media > > added at run time, like inserting a DVD? One minute timeout for > > detecting a DVD would sound very long to me. > > It's not for inserting DVDs, only for new devices showing up in the > repository. > Apparently new devices may keep on showing up a while after boot up, > but I > think this matters only for the kboot kernel, that's why I went with > the > exponential back-off with upper limit. Why not just have a kthread poll at 2 second interval for new devices or removed ones ? (And not for request processing) Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/7] ps3: Disk Storage Driver
On Fri, 2007-05-25 at 21:40 +0200, Geert Uytterhoeven wrote: > > I used a kthread because the request function of a block device driver > must be > non-blocking, and ps3stor_read_write_sectors() calls > wait_for_completion(). Which as I said before looks terribly sad... Why the heck would it have to do that ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/7] ps3: Disk Storage Driver
> So the hypervison uses guest-real addresses here? I would have expected > it to use the kernel page tables, which lets you use vmap() to do > scatter-gather. Ugh ? Maybe s390 can do that but no other hypervisor that I know about :-) It would be nice, sure, but heh. > I don't really understand what the kthread is needed for. You probably > thought about multiple options and ended up with this, but having > a comment in front of it might be helpful. Yeah, me neither... the driver looks very very very unefficient to me. I though the kthread was useful for hotplug detection becasue the hypervisor don't signal us, but from the patch, it looks like it's also used for actual request processing which is very yucky. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: Transform old-style macros to newer "__noreturn" standard.
Satyam Sharma wrote: >> >> Sorry to say, but weren't you the person who didn't recognize !! as the >> idiomatic booleanizing operator? > > Yes, of course, please prove a link / connection between that and this? > Very simple: it shows a lack of understanding of idiomatic use of C. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/7] ps3: Storage Driver Probing
On Fri, 2007-05-25 at 18:18 +0200, Arnd Bergmann wrote:
> > +static u64 ps3stor_wait_for_completion(u64 devid, u64 tag,
> > +unsigned int timeout)
> > +{
> > + unsigned int retries = 0;
> > + u64 res = -1, status;
> > +
> > + for (retries = 0; retries < timeout; retries++) {
> > + res =
> lv1_storage_check_async_status(NOTIFICATION_DEVID, tag,
> > + );
> > + if (!res)
> > + break;
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + schedule_timeout(1);
> > + }
>
> Any reason not to use msleep(1) instead of the schedule_timeout?
Both look equally ugly though... do you really have to poll ?
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21 1/3] x86_64: EFI64 support
Andi Kleen wrote:
On Tuesday 01 May 2007 20:59:46 Chandramouli Narayanan wrote:
General note on EFI x86_64 support
--
More review. This code unfortunately has some problems.
First this seems to be quite different from what the 32bit EFI
support does (which i suppose is pre UEFI) Are there plans to sync this
up eventually?
Consolidation of the efi support across architectures needs to be done
at some point and this will be a bigger task. But right now my focus is
x86_64.
Also your howto above should be somewhere in Documentation/
Will do.
- Create a VFAT partition on the disk
- Copy the following to the VFAT partition:
elilo bootloader with x86_64 support and elilo configuration file
efi64 kernel image, initrd
What format is the kernel image?
bzImage
- Boot to EFI shell and invoke elilo choosing efi64 kernel image
- On UEFI2.0 firmware systems, pass vga=fbcon for boot messages to appear
on console.
They don't have a compat mode for vga anymore?
I'm not sure what you mean by VGA compatibility mode. There is no
requirement in [U]EFI for VGA.
2. With CALGARY_IOMMU=y in the kernel configuration, the Calgary detection fails
with the message "Calgary: Unable to locate Rio Grande Table in EBDA - bailing".
However, the legacy kernel has no such error.
Getting that message when you don't have a IBM Summit system with Calgary is
expected.
It would be more worrying why the old kernel didn't give it.
All right. I will double-check into the older kernel.
+config EFI
+ bool "Boot from EFI support (EXPERIMENTAL)"
+ default n
The config should be only added after the feature works -- later in the series.
Drop the default n
To the extent I have tested, the feature works. Should this still be 'n'?
+ ---help---
+
+ This enables the the kernel to boot on EFI platforms using
+ system configuration information passed to it from the firmware.
+ This also enables the kernel to use any EFI runtime services that are
+ available (such as the EFI variable services).
+ This option is only useful on systems that have EFI firmware
+ and will result in a kernel image that is ~8k larger. However,
+ even with this option, the resultant kernel should continue to
+ boot on existing non-EFI platforms.
The description should probably have a reference to the Documentation describing
how to set this up.
Mention UEFI?
Will add to the doc.
+#define EFI_SYSTAB (*((unsigned long *)(PARAM+0x1b8)))
+#define EFI_LOADER_SIG ((unsigned char *)(PARAM+0x1c0))
+#define EFI_MEMDESC_SIZE (*((unsigned int *) (PARAM+0x1c4)))
+#define EFI_MEMDESC_VERSION (*((unsigned int *) (PARAM+0x1c8)))
+#define EFI_MEMMAP_SIZE (*((unsigned int *) (PARAM+0x1cc)))
+#define EFI_MEMMAP (*((unsigned long *)(PARAM+0x1d0)))
This needs to be documented in Documentation/i386/zero-page.txt
But it might be already obsolete with the early conversion to e820 change?
Not sure if this becomes obsolete with e820 change. I will look into it
and add to the doc.
+#define EFI_ARG_NUM_GET_TIME 2
+#define EFI_ARG_NUM_SET_TIME 1
+#define EFI_ARG_NUM_GET_WAKEUP_TIME3
+#define EFI_ARG_NUM_SET_WAKEUP_TIME2
+#define EFI_ARG_NUM_GET_VARIABLE 5
+#define EFI_ARG_NUM_GET_NEXT_VARIABLE 3
+#define EFI_ARG_NUM_SET_VARIABLE 5
+#define EFI_ARG_NUM_GET_NEXT_HIGH_MONO_COUNT 1
+#define EFI_ARG_NUM_RESET_SYSTEM 4
+#define EFI_ARG_NUM_SET_VIRTUAL_ADDRESS_MAP4
+
+#define EFI_ARG_NUM_MAX 10
+#define EFI_REG_ARG_NUM 4
+
+extern unsigned long efi_call_phys(void *fp, u64 arg_num, ...);
+struct efi efi;
+EXPORT_SYMBOL(efi);
+struct efi efi_phys __initdata;
+struct efi_memory_map memmap ;
+static efi_system_table_t efi_systab __initdata;
+
+static unsigned long efi_rt_eflags;
+static spinlock_t efi_rt_lock = SPIN_LOCK_UNLOCKED;
Each lock needs a comment what it protects and if there is a locking order.
I will add the comments. Ditto for i386.
+static pgd_t save_pgd;
That looks dubious, more comments later.
+
+/* Convert SysV calling convention to EFI x86_64 calling convention */
+
+static efi_status_t uefi_call_wrapper(void *fp, unsigned long va_num, ...)
+{
Any reason you can't do something simple like (untested)
/* rdi, rsi, rdx, rcx, r8, r9 -> rcx,rdx,r8,r9,stack,stack
arg1 function to call */
call_ms:
mov %rsi,%rcx
mov %rdx,%rdx
mov %rcx,%r8
mov %r8,%r9
push %r9
call *%rdi
pop %r9
ret
I assume none of the calls has more than 6 arguments.
ndiswrapper probably has already tested variants if you're lazy.
Then you also wouldn't need the defines for the number of arguments.
Also such code is better written in pure assembly; some versions off
gcc don't like clobbering of
Re: [patch 6/7] ps3: ROM Storage Driver
On Fri, 2007-05-25 at 13:24 +0200, Olaf Hering wrote: > On Fri, May 25, [EMAIL PROTECTED] wrote: > > > +++ b/drivers/scsi/ps3rom.c > > > + kaddr = kmap_atomic(sgpnt->page, KM_USER0); > > linux/highmem.h is not included to get the kmap_* prototypes. Beside, I don't see the point of using kmap on ppc64... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/7] ps3: Disk Storage Driver
On Friday 25 May 2007, Geert Uytterhoeven wrote: > On Fri, 25 May 2007, Arnd Bergmann wrote: > > > Ok, but why does it call wait_for_completion() then? > > I thought you could end_that_request_* from the interrupt handler instead. > > Actually I tried that first, but I ran into other problems, like my request > handler being called continuously and requests gotten stuck. But maybe it was > just a locking bug on my side. > > I can retry, but a disadvantage will be that there will be less code shared > with ps3flash and ps3rom. Not sure how much difference it will make performance-wise, but the context switch for each bio adds some extra cost at least. Changing it means you no longer share the ps3stor_read_write_sectors, but can at the same time simplify the disk driver, so that won't hurt in total. I don't care much, but I think it's worth trying. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] MIPS: Transform old-style macros to newer "__noreturn" standard.
On 5/26/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > > But __attribute__((noreturn)) is simply a _function attribute_. Of course, > it is legal / valid only for functions with return-type void, so it does > make > sense to combine both void and __attribute__((noreturn)) in the same > macro like you say. But that's not syntactically necessary. In fact, > grepping through the sources, a lot of people do prefer to place the > attribute _after_ the function declarator. > > Anyway, I'm fine either way. > Sorry to say, but weren't you the person who didn't recognize !! as the idiomatic booleanizing operator? Yes, of course, please prove a link / connection between that and this? I think you need to learn that everything that the compiler accepts isn't necessarily idiomatic, readable code. Consider __attribute__((noreturn)); it's a nonstandard feature implemented using a generic gcc mechanism -- thus what the compiler will accept is quite flexible, because it's a generic building block. It doesn't mean it's a good idea. The reason it's often written at the end of the expression mostly has to do with bugs in some very early versions of gcc. That might be, but I was only saying that there is no syntactical *compulsion* to combine the attribute with the return type. As for what's readable, it is subjective. And as for what's common / standard / idiomatic in the kernel code as of today, nothing beats a grep. Anyway, as I said previously, I'm fine with either way. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/7] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
On Fri, 2007-05-25 at 10:36 +0200, [EMAIL PROTECTED] wrote: > -#if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE) > +#if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE) || \ > +defined(CONFIG_PS3_FLASH_MODULE) || > defined(CONFIG_PS3_FLASH_MODULE) As I said multiple times, imho, #ifdef CONFIG_xxx_MODULE in the kernel is always a bug. You should always be able to build the module out of tree afteward and use it on a kernel that didn't have the CONFIG_xxx_MODULE set imho. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: Transform old-style macros to newer "__noreturn" standard.
Satyam Sharma wrote: > > But __attribute__((noreturn)) is simply a _function attribute_. Of course, > it is legal / valid only for functions with return-type void, so it does > make > sense to combine both void and __attribute__((noreturn)) in the same > macro like you say. But that's not syntactically necessary. In fact, > grepping through the sources, a lot of people do prefer to place the > attribute _after_ the function declarator. > > Anyway, I'm fine either way. > Sorry to say, but weren't you the person who didn't recognize !! as the idiomatic booleanizing operator? I think you need to learn that everything that the compiler accepts isn't necessarily idiomatic, readable code. Consider __attribute__((noreturn)); it's a nonstandard feature implemented using a generic gcc mechanism -- thus what the compiler will accept is quite flexible, because it's a generic building block. It doesn't mean it's a good idea. The reason it's often written at the end of the expression mostly has to do with bugs in some very early versions of gcc. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] MIPS: Transform old-style macros to newer "__noreturn" standard.
Hi Peter, On 5/26/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Robert P. J. Day wrote: >> ... and declare functions as: >> >> __noreturn f(); >> >> ... which is the syntactially sane way of doing it. > > that may be, but keep in mind that gcc allows attributes to *follow* > the parameter list as well, and some people might prefer to do the > following: > > f() __noreturn; > > that would fail badly if you defined __noreturn as you suggest. That's equally moronic that saying that "some people might prefer to write 'f() void;'", which is what it's *EXACTLY* equivalent to. Yes, they might "prefer" it, but it's syntactically invalid and the compiler won't accept it. As it shouldn't. __noreturn here takes the syntactic place of the return type, because that's what it IS. But __attribute__((noreturn)) is simply a _function attribute_. Of course, it is legal / valid only for functions with return-type void, so it does make sense to combine both void and __attribute__((noreturn)) in the same macro like you say. But that's not syntactically necessary. In fact, grepping through the sources, a lot of people do prefer to place the attribute _after_ the function declarator. Anyway, I'm fine either way. Thanks, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
Herbert Xu wrote: On Fri, May 25, 2007 at 11:04:04PM +1000, Herbert Xu wrote: [E1000]: Call netif_poll_enable in e1000_open Here is a better one. [E1000]: Restore netif_poll_enable call but make sure IRQs are off This restores the previously removed netif_poll_enable call in e1000_open. It's needed on all but the first call to e1000_open for a NIC as e1000_close always calls netif_poll_disable. netif_poll_enable can only be called safely if no polls have been scheduled. This should be the case as long as we don't enter our IRQ handler. In order to guarantee this we explicitly disable IRQs as early as possible when we're probing the NIC. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Ack! this also fixes all the issues we had seen ourselves. I took a bit of time to get our labs to test it. Who can pick this patch up for us? Jeff ? Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] please pull infiniband.git
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will get a few more 2.6.22-rc2 fixes:
Eli Cohen (1):
IB/mlx4: Initialize send queue entry ownership bits
Michael S. Tsirkin (2):
IPoIB/cm: Fix timeout check in ipoib_cm_dev_stop()
IPoIB/cm: Drain cq in ipoib_cm_dev_stop()
Roland Dreier (1):
IB/mlx4: Don't allocate RQ doorbell if using SRQ
Stefan Roscher (1):
IB/ehca: Fix number of send WRs reported for new QP
drivers/infiniband/hw/ehca/hcp_if.c |2 +-
drivers/infiniband/hw/mlx4/qp.c | 59 +++---
drivers/infiniband/ulp/ipoib/ipoib.h|1 +
drivers/infiniband/ulp/ipoib/ipoib_cm.c |3 +-
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 31 ++--
5 files changed, 60 insertions(+), 36 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/hcp_if.c
b/drivers/infiniband/hw/ehca/hcp_if.c
index 7f0beec..5766ae3 100644
--- a/drivers/infiniband/hw/ehca/hcp_if.c
+++ b/drivers/infiniband/hw/ehca/hcp_if.c
@@ -331,7 +331,7 @@ u64 hipz_h_alloc_resource_qp(const struct
ipz_adapter_handle adapter_handle,
0);
qp->ipz_qp_handle.handle = outs[0];
qp->real_qp_num = (u32)outs[1];
- parms->act_nr_send_sges =
+ parms->act_nr_send_wqes =
(u16)EHCA_BMASK_GET(H_ALL_RES_QP_ACT_OUTST_SEND_WR, outs[2]);
parms->act_nr_recv_wqes =
(u16)EHCA_BMASK_GET(H_ALL_RES_QP_ACT_OUTST_RECV_WR, outs[2]);
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index a824bc5..dc137de 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -270,9 +270,7 @@ static int create_qp_common(struct mlx4_ib_dev *dev, struct
ib_pd *pd,
struct ib_qp_init_attr *init_attr,
struct ib_udata *udata, int sqpn, struct mlx4_ib_qp
*qp)
{
- struct mlx4_wqe_ctrl_seg *ctrl;
int err;
- int i;
mutex_init(>mutex);
spin_lock_init(>sq.lock);
@@ -319,20 +317,24 @@ static int create_qp_common(struct mlx4_ib_dev *dev,
struct ib_pd *pd,
if (err)
goto err_mtt;
- err = mlx4_ib_db_map_user(to_mucontext(pd->uobject->context),
- ucmd.db_addr, >db);
- if (err)
- goto err_mtt;
+ if (!init_attr->srq) {
+ err =
mlx4_ib_db_map_user(to_mucontext(pd->uobject->context),
+ ucmd.db_addr, >db);
+ if (err)
+ goto err_mtt;
+ }
} else {
err = set_kernel_sq_size(dev, _attr->cap,
init_attr->qp_type, qp);
if (err)
goto err;
- err = mlx4_ib_db_alloc(dev, >db, 0);
- if (err)
- goto err;
+ if (!init_attr->srq) {
+ err = mlx4_ib_db_alloc(dev, >db, 0);
+ if (err)
+ goto err;
- *qp->db.db = 0;
+ *qp->db.db = 0;
+ }
if (mlx4_buf_alloc(dev->dev, qp->buf_size, PAGE_SIZE * 2,
>buf)) {
err = -ENOMEM;
@@ -348,11 +350,6 @@ static int create_qp_common(struct mlx4_ib_dev *dev,
struct ib_pd *pd,
if (err)
goto err_mtt;
- for (i = 0; i < qp->sq.max; ++i) {
- ctrl = get_send_wqe(qp, i);
- ctrl->owner_opcode = cpu_to_be32(1 << 31);
- }
-
qp->sq.wrid = kmalloc(qp->sq.max * sizeof (u64), GFP_KERNEL);
qp->rq.wrid = kmalloc(qp->rq.max * sizeof (u64), GFP_KERNEL);
@@ -386,7 +383,7 @@ static int create_qp_common(struct mlx4_ib_dev *dev, struct
ib_pd *pd,
return 0;
err_wrid:
- if (pd->uobject)
+ if (pd->uobject && !init_attr->srq)
mlx4_ib_db_unmap_user(to_mucontext(pd->uobject->context),
>db);
else {
kfree(qp->sq.wrid);
@@ -403,7 +400,7 @@ err_buf:
mlx4_buf_free(dev->dev, qp->buf_size, >buf);
err_db:
- if (!pd->uobject)
+ if (!pd->uobject && !init_attr->srq)
mlx4_ib_db_free(dev, >db);
err:
@@ -481,14 +478,16 @@ static void destroy_qp_common(struct mlx4_ib_dev *dev,
struct mlx4_ib_qp *qp,
mlx4_mtt_cleanup(dev->dev, >mtt);
if (is_user) {
- mlx4_ib_db_unmap_user(to_mucontext(qp->ibqp.uobject->context),
- >db);
+ if (!qp->ibqp.srq)
+
[git patches] libata fixes
And a few trivial documentation patches.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-scsi.c |5 ++-
drivers/ata/pata_artop.c |2 +-
drivers/ata/pata_hpt37x.c | 27 ++---
drivers/ata/pata_it821x.c |3 +-
drivers/ata/pata_scc.c | 46 ++-
drivers/ata/pata_via.c |9 ---
drivers/ata/sata_mv.c | 44 ++
drivers/ata/sata_promise.c |2 +-
drivers/ata/sata_sis.c |2 +-
drivers/ata/sata_via.c |3 ++
10 files changed, 98 insertions(+), 45 deletions(-)
Alan Cox (2):
pata: Trivia
pata_hpt37x: Further improvements based on the IDE updates and vendor
drivers
Jeff Garzik (4):
[libata] sata_promise: fix flags typo
[libata] sata_mv: add TODO list
[libata] Fix decoding of 6-byte commands
[libata] sata_via, pata_via: Add PCI IDs.
Tony Breeds (1):
Fix build failure for drivers/ata/pata_scc.c
Uwe Koziolek (1):
libata: sata_sis fixes
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 242c43e..b3900cf 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1050,14 +1050,15 @@ static unsigned int ata_scsi_flush_xlat(struct
ata_queued_cmd *qc)
static void scsi_6_lba_len(const u8 *cdb, u64 *plba, u32 *plen)
{
u64 lba = 0;
- u32 len = 0;
+ u32 len;
VPRINTK("six-byte command\n");
+ lba |= ((u64)(cdb[1] & 0x1f)) << 16;
lba |= ((u64)cdb[2]) << 8;
lba |= ((u64)cdb[3]);
- len |= ((u32)cdb[4]);
+ len = cdb[4];
*plba = lba;
*plen = len;
diff --git a/drivers/ata/pata_artop.c b/drivers/ata/pata_artop.c
index 7b4810c..03b6ddd 100644
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -97,7 +97,7 @@ static int artop6260_pre_reset(struct ata_port *ap, unsigned
long deadline)
* artop6260_cable_detect - identify cable type
* @ap: Port
*
- * Identify the cable type for the ARTOp interface in question
+ * Identify the cable type for the ARTOP interface in question
*/
static int artop6260_cable_detect(struct ata_port *ap)
diff --git a/drivers/ata/pata_hpt37x.c b/drivers/ata/pata_hpt37x.c
index a54c174..6446735 100644
--- a/drivers/ata/pata_hpt37x.c
+++ b/drivers/ata/pata_hpt37x.c
@@ -26,7 +26,7 @@
#include
#define DRV_NAME "pata_hpt37x"
-#define DRV_VERSION"0.6.5"
+#define DRV_VERSION"0.6.6"
struct hpt_clock {
u8 xfer_speed;
@@ -931,15 +931,6 @@ static int hpt37x_init_one(struct pci_dev *dev, const
struct pci_device_id *id)
.udma_mask = 0x7f,
.port_ops = _port_ops
};
- /* HPT371, 372 and friends - UDMA100 at 50MHz clock */
- static const struct ata_port_info info_hpt372_50 = {
- .sht = _sht,
- .flags = ATA_FLAG_SLAVE_POSS|ATA_FLAG_SRST,
- .pio_mask = 0x1f,
- .mwdma_mask = 0x07,
- .udma_mask = 0x3f,
- .port_ops = _port_ops
- };
/* HPT374 - UDMA133 */
static const struct ata_port_info info_hpt374 = {
.sht = _sht,
@@ -1098,17 +1089,21 @@ static int hpt37x_init_one(struct pci_dev *dev, const
struct pci_device_id *id)
* use a 50MHz DPLL by choice
*/
unsigned int f_low, f_high;
- int adjust;
+ int dpll, adjust;
- clock_slot = 2;
+ /* Compute DPLL */
+ dpll = 2;
if (port->udma_mask & 0xE0)
- clock_slot = 3;
+ dpll = 3;
- f_low = (MHz[clock_slot] * chip_table->base) / 192;
+ f_low = (MHz[clock_slot] * 48) / MHz[dpll];
f_high = f_low + 2;
+ if (clock_slot > 1)
+ f_high += 2;
/* Select the DPLL clock. */
pci_write_config_byte(dev, 0x5b, 0x21);
+ pci_write_config_dword(dev, 0x5C, (f_high << 16) | f_low);
for(adjust = 0; adjust < 8; adjust++) {
if (hpt37x_calibrate_dpll(dev))
@@ -1124,12 +1119,12 @@ static int hpt37x_init_one(struct pci_dev *dev, const
struct pci_device_id *id)
printk(KERN_WARNING "hpt37x: DPLL did not
stabilize.\n");
return -ENODEV;
}
- if (clock_slot == 3)
+ if (dpll == 3)
private_data = (void *)hpt37x_timings_66;
else
private_data = (void *)hpt37x_timings_50;
- printk(KERN_INFO "hpt37x: Bus clock %dMHz, using DPLL.\n",
MHz[clock_slot]);
+ printk(KERN_INFO "hpt37x: Bus
Re: [2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic: rmmod/0x00000001/4568
On Fri, 25 May 2007 14:40:05 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote: > > Hello, > > > > with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the > > following BUG: > > Thanks for letting me know. > > Stuart, any help here? pretty obvious. cpufreq_unregister_notifier() sleeps, and that patch causes it to be called under spinlock. Something like this... --- a/drivers/usb/host/ehci-hcd.c~fix-gregkh-usb-usb-ehci-cpufreq-fix +++ a/drivers/usb/host/ehci-hcd.c @@ -452,14 +452,14 @@ static void ehci_stop (struct usb_hcd *h if (HC_IS_RUNNING (hcd->state)) ehci_quiesce (ehci); -#ifdef CONFIG_CPU_FREQ - cpufreq_unregister_notifier(>cpufreq_transition, - CPUFREQ_TRANSITION_NOTIFIER); -#endif ehci_reset (ehci); ehci_writel(ehci, 0, >regs->intr_enable); spin_unlock_irq(>lock); +#ifdef CONFIG_CPU_FREQ + cpufreq_unregister_notifier(>cpufreq_transition, + CPUFREQ_TRANSITION_NOTIFIER); +#endif /* let companion controllers work when we aren't */ ehci_writel(ehci, 0, >regs->configured_flag); _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: idle=poll burns my box [was Re: 2.6.22-rc2-mm1]
On Fri, 25 May 2007 23:20:25 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > Is idle=poll a quick and dirty way to burn your box in flames ? yep ;) It makes the CPU(s) busy-wait when they have nothing else to do. It was originally added as a thing to maybe save a few cycles of latency in responding to interrupts. It's now useful as a trick to prevent oprofile from producing confusing numbers. I don't think it has any other uses. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] msi: Invert the sense of the MSI enables.
Eric W. Biederman wrote:
> @@ -1677,43 +1650,16 @@ static int __devinit msi_ht_cap_enabled(struct
> pci_dev *dev)
> return 0;
> }
>
> -/* Check the hypertransport MSI mapping to know whether MSI is enabled or
> not */
> +/* Enable MSI on hypertransport chipsets supporting MSI */
> static void __devinit quirk_msi_ht_cap(struct pci_dev *dev)
> {
> - if (dev->subordinate && !msi_ht_cap_enabled(dev)) {
> - printk(KERN_WARNING "PCI: MSI quirk detected. "
> -"MSI disabled on chipset %s.\n",
> -pci_name(dev));
> - dev->subordinate->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
> + if (dev->subordinate && msi_ht_cap_enabled(dev)) {
> + printk(KERN_INFO "PCI: Enabled MSI on chipset %s.\n",
> + pci_name(dev));
> + dev->subordinate->bus_flags |= PCI_BUS_FLAGS_MSI;
> }
> }
> -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS,
> PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE,
> - quirk_msi_ht_cap);
> +DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_msi_ht_cap);
>
> -/* The nVidia CK804 chipset may have 2 HT MSI mappings.
> - * MSI are supported if the MSI capability set in any of these mappings.
> - */
> -static void __devinit quirk_nvidia_ck804_msi_ht_cap(struct pci_dev *dev)
> -{
> - struct pci_dev *pdev;
> -
> - if (!dev->subordinate)
> - return;
>
> - /* check HT MSI cap on this chipset and the root one.
> - * a single one having MSI is enough to be sure that MSI are supported.
> - */
> - pdev = pci_get_slot(dev->bus, 0);
> - if (!pdev)
> - return;
> - if (!msi_ht_cap_enabled(dev) && !msi_ht_cap_enabled(pdev)) {
> - printk(KERN_WARNING "PCI: MSI quirk detected. "
> -"MSI disabled on chipset %s.\n",
> -pci_name(dev));
> - dev->subordinate->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
> - }
> - pci_dev_put(pdev);
> -}
> -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA,
> PCI_DEVICE_ID_NVIDIA_CK804_PCIE,
> - quirk_nvidia_ck804_msi_ht_cap);
>
Are you sure that calling quirk_msi_ht_cap() on all devices will really
replace my nVidia CK804 specific quirk above?
I haven't looked at all this for a while, but if I remember correctly,
the PCI hierarchy with an AMD8131 and a CK804 looks like the following.
-+-[08]-+-0a.0-[09]--
\-[00]-+-00.0
+-0e.0-[02]--
The HT MSI mapping of the CK804 may be either on device 00.0 (10de:005e)
and 0e.0 (10de:005d). The devices that are physically behind the CK804
chipset are on bus 02.
To get MSI enabled for these devices, the MSI flag should be set either
on bus 00 (looks impossible here) or on bus 02 (if the HT MSI mapping is
found on 0e.0). However, if the MSI mapping is found on device 00.0, I
don't see your code could enable MSI behind on bus 02.
Brice
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic: rmmod/0x00000001/4568
On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
> Hello,
>
> with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
> following BUG:
Thanks for letting me know.
Stuart, any help here?
thanks,
greg k-h
> [ 459.800033] BUG: scheduling while atomic: rmmod/0x0001/4568
> [ 459.800045] [] dump_trace+0x63/0x1ec
> [ 459.800055] [] show_trace_log_lvl+0x1a/0x30
> [ 459.800066] [] show_trace+0x12/0x14
> [ 459.800099] [] dump_stack+0x16/0x18
> [ 459.800135] [] __sched_text_start+0x56/0x7db
> [ 459.800142] [] wait_for_completion+0x65/0x9b
> [ 459.800147] [] synchronize_rcu+0x2d/0x33
> [ 459.800154] [] synchronize_srcu+0x23/0x5f
> [ 459.800160] [] srcu_notifier_chain_unregister+0x43/0x4d
> [ 459.800185] [] cpufreq_unregister_notifier+0x22/0x32
> [ 459.800203] [] ehci_stop+0x4f/0xb7 [ehci_hcd]
> [ 459.800248] [] usb_remove_hcd+0x97/0xd7 [usbcore]
> [ 459.800280] [] usb_hcd_pci_remove+0x18/0x6a [usbcore]
> [ 459.800317] [] pci_device_remove+0x1c/0x3d
> [ 459.800324] [] __device_release_driver+0x74/0x90
> [ 459.800332] [] driver_detach+0x81/0xc2
> [ 459.800337] [] bus_remove_driver+0x5d/0x7c
> [ 459.800342] [] driver_unregister+0xb/0xd
> [ 459.800347] [] pci_unregister_driver+0x13/0x65
> [ 459.800351] [] ehci_hcd_cleanup+0x10/0x12 [ehci_hcd]
> [ 459.800360] [] sys_delete_module+0x187/0x1ae
> [ 459.800367] [] sysenter_past_esp+0x5f/0x85
> [ 459.800373] [] 0xe410
> [ 459.800384] ===
>
> static void ehci_stop (struct usb_hcd *hcd)
> {
> ...
> spin_lock_irq(>lock);
> if (HC_IS_RUNNING (hcd->state))
> ehci_quiesce (ehci);
>
> #ifdef CONFIG_CPU_FREQ
> cpufreq_unregister_notifier(>cpufreq_transition,
> CPUFREQ_TRANSITION_NOTIFIER);
> #endif
>
> --
> mattia
> :wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] msi: Invert the sense of the MSI enables.
On Fri, May 25, 2007 at 03:06:22PM -0600, Eric W. Biederman wrote: > Greg KH <[EMAIL PROTECTED]> writes: > > It's a trade off, and I'd like to choose the one that over the long > > term, causes the least ammount of work and maintaiblity. I think the > > current blacklist meets that goal. > > A reasonable goal. I will come back to this after the long holiday > weekend here and see what makes sense. Ok, if you still think after looking into it some more that it's still needed, please resend the patches, and I'll reconsider it. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2 built on ppc (1)
On Sun, May 20, 2007 at 01:04:19PM +0200, Elimar Riesebieter wrote: > Hi, > > FYI, building 2.6.22-rc2 with > gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) > on my powerbook (PPC) gives: > > ... > arch/powerpc/kernel/pci_32.c: In function 'pcibios_assign_resources': > arch/powerpc/kernel/pci_32.c:562: warning: ignoring return value of > 'pci_assign_resource', declared with attribute warn_unused_result > arch/powerpc/kernel/pci_32.c: In function 'pcibios_add_platform_entries': > arch/powerpc/kernel/pci_32.c:1053: warning: ignoring return value of > 'device_create_file', declared with attribute warn_unused_result > arch/powerpc/mm/mem.c: In function 'paging_init': > arch/powerpc/mm/mem.c:313: warning: passing argument 1 of 'pmd_offset' from > incompatible pointer type > arch/powerpc/mm/mem.c:316: warning: passing argument 1 of 'pmd_offset' from > incompatible pointer type > ... > drivers/base/core.c: In function 'device_add': > drivers/base/core.c:714: warning: ignoring return value of > 'sysfs_create_link', declared with attribute warn_unused_result > drivers/base/core.c:719: warning: ignoring return value of > 'sysfs_create_link', declared with attribute warn_unused_result > drivers/base/core.c:722: warning: ignoring return value of > 'sysfs_create_link', declared with attribute warn_unused_result > drivers/base/core.c: In function 'device_rename': > drivers/base/core.c:1197: warning: ignoring return value of > 'sysfs_create_link', declared with attribute warn_unused_result > drivers/base/dd.c:211: warning: 'device_probe_drivers' defined but not used > ... > drivers/ide/setup-pci.c: In function 'ide_scan_pcibus': > drivers/ide/setup-pci.c:879: warning: ignoring return value of > '__pci_register_driver', declared with attribute warn_unused_result > drivers/pci/search.c: In function 'pci_find_slot': > drivers/pci/search.c:99: warning: 'pci_find_device' is deprecated (declared > at include/linux/pci.h:477) > drivers/pci/search.c: At top level: > drivers/pci/search.c:433: warning: 'pci_find_device' is deprecated (declared > at drivers/pci/search.c:241) > drivers/pci/search.c:433: warning: 'pci_find_device' is deprecated (declared > at drivers/pci/search.c:241) > ... > > If more info is needed, please contact me via PM, as I am not > subscribed. I see some warnings, but no errors, right? The pci and driver core warnings are known and are being worked on... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: any value to "NORET_TYPE" macro?
On Fri, May 25, 2007 at 03:40:18PM -0400, Robert P. J. Day wrote: > On Sat, 26 May 2007, Satyam Sharma wrote: > > > Hi Robert, > > > > On 5/25/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: > > > On Fri, 25 May 2007, Satyam Sharma wrote: > > > ... > > > > 1. If this is a function _declaration_ (i.e. a prototype in some > > > > header or some .c file), then remove the NORET_TYPE macro. Also, > > > > if an ATTRIB_NORET or NORET_AND already exists then you're done. > > > > Else, introduce an ATTRIB_NORET after the arglist but before ; > > > > > > actually, what i would be introducing in all cases is "__noreturn", > > > the short form currently defined in compiler-gcc.h. and i would be > > > removing every instance of ATTRIB_NORET and its buddies. > > > > Ummm ... you mean we're replacing all occurrences of ATTRIB_NORET > > as well? Note that NORET_TYPE and ATTRIB_NORET are both defined > > in the generic include/linux/linkage.h whereas __noreturn is in > > compiler-gcc.h which is included only for gcc builds -- hence, my > > preference for ATTRIB_NORET. Also, there is not even a single user of > > __noreturn anywhere in the kernel code whereas ATTRIB_NORET is used > > in all these places, which means it looks like to be the standard thing ... > > Anyway, I'm fine either way. > > ah, i hadn't noticed that. i must think on this more. man, i thought > this was going to be so simple. argh. It's only an optimization, so defining __noreturn to nothing for other compilers should work fine. > rday 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] MIPS: Transform old-style macros to newer "__noreturn" standard.
Robert P. J. Day wrote: >> ... and declare functions as: >> >> __noreturn f(); >> >> ... which is the syntactially sane way of doing it. > > that may be, but keep in mind that gcc allows attributes to *follow* > the parameter list as well, and some people might prefer to do the > following: > > f() __noreturn; > > that would fail badly if you defined __noreturn as you suggest. That's equally moronic that saying that "some people might prefer to write 'f() void;'", which is what it's *EXACTLY* equivalent to. Yes, they might "prefer" it, but it's syntactically invalid and the compiler won't accept it. As it shouldn't. __noreturn here takes the syntactic place of the return type, because that's what it IS. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Nvidiafb issues on Inspiron 8100
On Thu, 2007-05-24 at 01:37 -0400, Dmitry Torokhov wrote: > Hi Antonino, > > I am having the following issues on my Dell Inspiron 8100. They are not > new but I just got around to report them. > > With CONFIG_FB_NVIDIA_I2C I get 1600x1200 resolution but pixels > "swarming" and it is unuseable. There are following messages in > dmesg (note complaints from i2c): Looks like an EDID block not accessible by i2c and only available through the BIOS. And it's probably broken too. Can you #define DEBUG in drivers/video/fbmon.c, enable CONFIG_FIRMWARE_EDID, the post your dmesg? For now, the best you can do is disable i2c support and add: video=nvidiafb:[EMAIL PROTECTED] in your boot line. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double exclamation (!!) suckage in the kernel
On 5/26/07, Al Viro <[EMAIL PROTECTED]> wrote: On Sat, May 26, 2007 at 02:26:11AM +0530, Satyam Sharma wrote: > also be brave enough to take a C quiz here :-) > > >what type should x have for !!x to be a valid expression? > > Any integer type (includes pointers) Er, no... Pointers are not integer types *and* you can use ! on any scalar type (including floating ones, even though it's not particulary useful there). Yeah, I noticed this (with a sample program) just after the quiz ... > >what will be the type of result? > > int (I guess boolean for C99?) Actually, ! and comparisons still give int in C99 (and !x is defined as (x == 0) in all situations). Hmm, thanks for explaining this. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double exclamation (!!) suckage in the kernel
On Fri, May 25, 2007 at 10:32:13PM +0100, Al Viro wrote:
> On Sat, May 26, 2007 at 02:26:11AM +0530, Satyam Sharma wrote:
> > also be brave enough to take a C quiz here :-)
> >
> > >what type should x have for !!x to be a valid expression?
> >
> > Any integer type (includes pointers)
>
> Er, no... Pointers are not integer types *and* you can use ! on any
> scalar type (including floating ones, even though it's not particulary
> useful there).
... which means that original question ("what type should x have...")
gets the answer "scalars, arrays or functions". The last two variants
give you constant 1, though (arrays and functions decay to pointers in
such context and that pointer is not going to be different from null
pointer of the same type; thus you get !!x => !0 => 1).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] non-string based tsc unstable reasons
On Fri, 2007-05-25 at 23:05 +0200, Andi Kleen wrote:
> On Fri, May 25, 2007 at 12:32:10PM -0700, Daniel Walker wrote:
> > Just passing a string to mark_tsc_unstable() doesn't allow real code to
> > change
> > based on the reason for the instablility. I changed mark_tsc_unstable()
> > to accept a string and a flag which denotes a general reason why the tsc
> > is unstable, and can be evaluated in code.
> >
>
> I still think that's the wrong way to do this. If there is any
> special action that should be done on particular unstable events
> it should call a separate function or an addon function.
> First putting it all together and then try to distingush it again
> doesn't seem nice.
Off list John indicated a different way of doing this, which is in the
patch below. This seems similar to what your describing above.. I'm fine
with this method although I think this is a little confusing cause
mark_tsc_sched_clock_unstable() also makes it unstable for gettimeofday.
Which isn't totally clear just by looking at the functions.. (It's also
a super long function name..)
Any comments?
---
Subject: non-string based tsc unstable reasons
Just passing a string to mark_tsc_unstable() doesn't allow real code to change
based on the reason for the instablility. I changed mark_tsc_unstable()
to accept a string and a flag which denotes a general reason why the tsc
is unstable, and can be evaluated in code.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
Against 2.6.22-rc2
arch/i386/kernel/cpu/cyrix.c| 10 ---
arch/i386/kernel/tsc.c | 36 +++-
arch/x86_64/kernel/time.c |2 -
arch/x86_64/kernel/tsc.c| 26
arch/x86_64/kernel/tsc_sync.c |2 -
drivers/acpi/processor_idle.c |4 +--
include/asm-i386/mach-summit/mach_mpparse.h |5 ++-
include/asm-i386/tsc.h | 21 +++-
include/asm-x86_64/timex.h |1
9 files changed, 69 insertions(+), 38 deletions(-)
Index: linux-2.6.21/arch/i386/kernel/cpu/cyrix.c
===
--- linux-2.6.21.orig/arch/i386/kernel/cpu/cyrix.c
+++ linux-2.6.21/arch/i386/kernel/cpu/cyrix.c
@@ -274,12 +274,14 @@ static void __cpuinit init_cyrix(struct
vendor = read_pci_config_16(0, 0, 0x12, PCI_VENDOR_ID);
device = read_pci_config_16(0, 0, 0x12, PCI_DEVICE_ID);
- /*
-* The 5510/5520 companion chips have a funky PIT.
+ /*
+* The 5510/5520 companion chips have a funky PIT
+* and an unstable TSC.
*/
if (vendor == PCI_VENDOR_ID_CYRIX &&
-(device == PCI_DEVICE_ID_CYRIX_5510 || device ==
PCI_DEVICE_ID_CYRIX_5520))
- mark_tsc_unstable("cyrix 5510/5520 detected");
+ (device == PCI_DEVICE_ID_CYRIX_5510 ||
+device == PCI_DEVICE_ID_CYRIX_5520))
+ mark_tsc_sched_clock_unstable("cyrix 5510/5520
detected");
}
#endif
c->x86_cache_size=16; /* Yep 16K integrated cache thats it */
Index: linux-2.6.21/arch/i386/kernel/tsc.c
===
--- linux-2.6.21.orig/arch/i386/kernel/tsc.c
+++ linux-2.6.21/arch/i386/kernel/tsc.c
@@ -56,6 +56,7 @@ __setup("notsc", tsc_setup);
* due to cpufreq or due to unsynced TSCs
*/
static int tsc_unstable;
+static int tsc_unstable_sched_clock;
static inline int check_tsc_unstable(void)
{
@@ -107,7 +108,7 @@ unsigned long long sched_clock(void)
/*
* Fall back to jiffies if there's no TSC available:
*/
- if (unlikely(!tsc_enabled))
+ if (unlikely(tsc_unstable_sched_clock))
/* No locking but a rare wrong value is not a big deal: */
return (jiffies_64 - INITIAL_JIFFIES) * (10 / HZ);
@@ -230,7 +231,7 @@ time_cpufreq_notifier(struct notifier_bl
* TSC based sched_clock turns
* to junk w/ cpufreq
*/
- mark_tsc_unstable("cpufreq changes");
+ mark_tsc_gettimeofday_unstable("cpufreq
changes");
}
}
}
@@ -275,26 +276,29 @@ static struct clocksource clocksource_ts
CLOCK_SOURCE_MUST_VERIFY,
};
-void mark_tsc_unstable(char *reason)
+void mark_tsc_unstable(enum tsc_unstable_flags flag, char *reason)
{
- if (!tsc_unstable) {
- tsc_unstable = 1;
- tsc_enabled = 0;
- printk("Marking TSC unstable due to: %s.\n", reason);
- /* Can be called before registration */
- if (clocksource_tsc.mult)
-
Re: BUG in 2.6.22-rc2-mm1: Parts of Alsa sound architecture broken
At Fri, 25 May 2007 10:28:06 -0700, Andrew Morton wrote: > > On Fri, 25 May 2007 18:01:34 +0200 Takashi Iwai <[EMAIL PROTECTED]> wrote: > > > At Thu, 24 May 2007 13:09:21 -0700, > > Andrew Morton wrote: > > > > > > On Thu, 24 May 2007 22:00:52 +0200 > > > "Uwe Bugla" <[EMAIL PROTECTED]> wrote: > > > > > > > Hi everybody, > > > > > > > > with 2.6.22-rc2-mm1 I do get sound out of my machine using snd-intel8x0 > > > > module, BUT: > > > > > > > > At least parts of that Alsa sound architecture do seem to be broken: > > > > > > I assume you're referring to this stuff? > > > > > > > snd_seq_device: Unknown symbol snd_iprintf > > > > snd_seq_device: Unknown symbol snd_device_new > > > > snd_rawmidi: Unknown symbol snd_info_register > > > > snd_rawmidi: Unknown symbol snd_seq_device_new > > > > snd_rawmidi: Unknown symbol snd_info_free_entry > > > > > > Probably some silly missing dependency. Please send the .config, thanks. > > > > The culprit appears more ealier. It implies the missing > > soundcore.ko (or its dependency). > > > > > snd: Unknown symbol unregister_sound_special > > > snd: Unknown symbol register_sound_special_device > > > snd: Unknown symbol sound_class > > > > Uwe, could you try to revert this patch? > > use-menuconfig-objects-ii-sound.patch > > > > I think that patch has rotted. Too many underlying changes and the > handling of HAS_IOMEM (at least) appears to have been broken (by my > fixups). > > I'll drop it. > > If/when Jan resends it, pleze consider it promptly and don't leave > me trying to maintain the thing while you guys are madly changing other > stuff underneath it? Yeah, I'll check it again if reposted. Jan, could you split ALSA portins at the next time? This will make testing and merging much easier for me... But, above all, I'm not convinced much by that patch, especially because it introduces new kconfigs just for menuconfig. For example, CONFIG_SND_PCI_DRIVERS doesn't appear in any Makefiles. Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double exclamation (!!) suckage in the kernel
On Sat, May 26, 2007 at 02:26:11AM +0530, Satyam Sharma wrote: > also be brave enough to take a C quiz here :-) > > >what type should x have for !!x to be a valid expression? > > Any integer type (includes pointers) Er, no... Pointers are not integer types *and* you can use ! on any scalar type (including floating ones, even though it's not particulary useful there). > >what will be the type of result? > > int (I guess boolean for C99?) Actually, ! and comparisons still give int in C99 (and !x is defined as (x == 0) in all situations). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] pata_hpt37x: Further improvements based on the IDE updates and vendor drivers
Alan Cox wrote: Better DPLL use and calibration Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [CodingStyle] Add comment to not put spaces before tabs.
Kok, Auke wrote: > > ahh yes, I'll incorporate that. > > BTW, would it be possible for cleanfile/cleanpatch to dump warnings to > stderr for lines exceeding 80 characters? I think that would really be > useful... > Should be trivial enough to do, although it probably should be an option. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 5/7] ps3: Disk Storage Driver
On Fri, 25 May 2007, Arnd Bergmann wrote:
> On Friday 25 May 2007, Geert Uytterhoeven wrote:
> > > I don't really understand what the kthread is needed for. You probably
> > > thought about multiple options and ended up with this, but having
> > > a comment in front of it might be helpful.
> >
> > I used a kthread because the request function of a block device driver must
> > be
> > non-blocking, and ps3stor_read_write_sectors() calls wait_for_completion().
>
> Ok, but why does it call wait_for_completion() then?
> I thought you could end_that_request_* from the interrupt handler instead.
Actually I tried that first, but I ran into other problems, like my request
handler being called continuously and requests gotten stuck. But maybe it was
just a locking bug on my side.
I can retry, but a disadvantage will be that there will be less code shared
with ps3flash and ps3rom.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem, Belgium
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
idle=poll burns my box [was Re: 2.6.22-rc2-mm1]
On Wed, 23 May 2007 00:42:33 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ > Don't know if it's specific to this kernel, but as I have realized it now... I booted with idle=poll to check some issues (with nvidia driver, btw). And suddenly I noticed my box was running near 80ºC hot. I pulled out the lid, an try to see what happened. In short, idle=poll rises the temperature about 20ºC. I have an ASUS PC-DL mobo, with a couple Xeon Northwood with HypertThreading at 2.4 GHz, for a total of 4 threads. If I boot the box with idle=poll, and let it doing _nothing_ but staring at the gnome desktop, I get this temperatures: (Time,VRM,CPU0,CPU1) (wihtout the side cover, remember...) 15:46 64 56 54 15:55 70 60 56 16:02 71 62 57 If I reboot without idle=poll, the box colds quickly: 16:07 58 52 48 16:12 50 43 42 16:15 49 42 41 I I put the box to do some multithreaded render, so all four cores stay above 98% usage, the box warms again: 16:17 51 43 42 16:24 67 57 54 16:28 70 60 56 16:30 72 61 57 16:37 72 61 56 And as soon as I stop the work, it colds again: 16:41 71 60 56 16:42 64 56 52 16:43 60 54 50 16:45 55 48 46 16:46 53 46 44 Left alone for awhile, it stays at 46 39 39 (for VRM and both CPUs, as I said). Is idle=poll a quick and dirty way to burn your box in flames ? To warm your cpu doing nothing ? Summer is coming, but this... Any ideas ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam03 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] msi: Invert the sense of the MSI enables.
> I think for most of Intel I can reduce my test to:
> If (bus == 0 , device == 0, function == 0 && vendor == Intel &&
> has a pci express capability) {
> Enable msi on all busses().
> }
MSI was working on every Intel PCI-X chipset I ever saw too...
- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: double exclamation (!!) suckage in the kernel
From: "Satyam Sharma" <[EMAIL PROTECTED]> Date: Sat, 26 May 2007 01:53:59 +0530 WHat is with multiple people asking about "!!" all of a sudden today? > Are all these occurrences merely the debris of > s/something/!notsomething/g kind of patches or is there some > dark, unknown C / gcc wizardry I have absolutely no clue of? "!!" is used in contexts where pointers might be being tested as well as plain integers, the "!!" turns a pointer into the equivalent integer boolean for testing. NULL pointers become 0 non-NULL pointers become 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] MIPS: Transform old-style macros to newer "__noreturn" standard.
On Fri, 25 May 2007, H. Peter Anvin wrote: > Robert P. J. Day wrote: > > > > > > f() __attribute__((noreturn)) ; > > > > you get: > > > > warning: data definition has no type or storage class > > > > but gcc doesn't complain if you declare it thusly: > > > > __attribute__((noreturn)) f() ; > > > > that strikes me as a flaw in gcc, no? > > > > Doesn't matter. gcc accepts "void __attribute__((noreturn)) f();", and > thus, one can define: > > #define __noreturn void __attribute__((noreturn)) > > ... and declare functions as: > > __noreturn f(); > > ... which is the syntactially sane way of doing it. that may be, but keep in mind that gcc allows attributes to *follow* the parameter list as well, and some people might prefer to do the following: f() __noreturn; that would fail badly if you defined __noreturn as you suggest. is there, in fact, a tradition for attribute usage, along the lines of what satyam suggested earlier? because once there's an established standard, that's going to dictate what is and isn't possible in terms of macros and shortcuts. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] msi: Invert the sense of the MSI enables.
Greg KH <[EMAIL PROTECTED]> writes:
>> MSI appears to have enough problems that enabling it in a kernel
>> that is supposed to run lots of different hardware (like a distro
>> kernel) is a recipe for disaster.
>
> Oh, I agree it's a major pain in the ass at times...
>
> But I'm real hesitant to change things this way. We'll get reports of
> people who used to have MSI working, and now it will not (like all AMD
> chipsets). That's a regression...
You saw my quirk that enabled MSI if you happen to have a
hypertransport msi mapping capability. That should take care of
all hypertransport compliant AMD chipsets.
So at least 90% of what we have now should work.
> Perhaps we can trigger off of the same flag that Vista uses like Andi
> suggested? That's one way to "know" that the hardware works, right?
A little. It is redefining the problem as squarely a BIOS writers
problem and possibly we want to do that in the presence of pci-express.
> For non-x86 arches, they all seem to want to always enable MSI as they
> don't have to deal with as many broken chipsets, if any at all. So for
> them, we'd have to just whitelist the whole arch. Does that really make
> sense?
Non-x86 (unless I'm confused) already has white lists or some
equivalent because they can't use generic code for configuring MSI
because non-x86 does not have a standard MSI target window with a
standard meaning for the bits. So non-x86 has it's own set of arch
specific mechanisms to handle this, and they just don't want generic
code getting in the way.
So it may makes sense make the default all to be x86 specific.
> And again, over time, like years, this list is going to grow way beyond
> a managable thing, especially as any new chipset that comes out in 2009
> is going to have working MSI, right?
I haven't a clue. I know we are in we are in the teething pain stage
now which just generally makes things difficult.
> I think our blacklist is easier to
> manage over time, while causing a problem for some users in trying to
> determine their broken hardware that they currently have.
Possibly. It just doesn't seem straight forward to add something
safely to our blacklist.
> It's a trade off, and I'd like to choose the one that over the long
> term, causes the least ammount of work and maintaiblity. I think the
> current blacklist meets that goal.
A reasonable goal. I will come back to this after the long holiday
weekend here and see what makes sense.
I think for most of Intel I can reduce my test to:
If (bus == 0 , device == 0, function == 0 && vendor == Intel &&
has a pci express capability) {
Enable msi on all busses().
}
At which point I don't think we will need to do much maintenance.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rt2..8 troubles
Hi Ingo et al. It's been quite a while, since last time I've complained about the -rt kernel patch series. This time I'm afraid I have a nasty specialty I've been trying to figure out and isolate but to no definitive results. Fact is, since 2.6.21-rt2 and still on latest -rt8, that I'm facing troubled behavior while running on a Core2 T7200 laptop (SMP). Somehow, soon or later, the whole system starts crawling to death. It just slows down to some kind of Big Freeze, with no evidence over the console whatsoever, so that I'm ultimately left with a brick on my hands. This behavior is consistent and occurs every time after a while. It surely does not occur on 2.6.21-rt1 and earlier. Even stranger, it does not occur on another but older [EMAIL PROTECTED] desktop (HT/SMP) where a very identical system image is deployed (openSUSE 10.2 i386, gcc 4.1.2, KDE 3.5.7) I wish I could give you more details, but the fact is I don't know where to look. The machine just freezes silently, again and again, with all kernels from -rt2 to -rt8 inclusive, with no traceable evidence, at least to my knowledge. The only symptom that I can come about is that, from some moment on and ever since, the system cannot start any new process anymore, or otherwise takes forever to realize and launch any new started process thread. A sample dmesg output: http://www.rncbc.org/datahub/dmesg-2.6.21-rt5.0 The corresponding .config: http://www.rncbc.org/datahub/config-2.6.21-rt5.0 Again, there's no logged evidence of the problem, which is as nasty as repeatable after each boot. Unfortunately, it's not quite deterministically reproducible, this behavior of turning into an unresponsive brick ;) It's just a matter of time, or so I think. That's why I have no clues. Is there anything I can do better to help myself figuring out this issue? As this is a modern laptop such things like a serial console are unavailable, but it would be nice to track things up over netconsole perhaps? I just need some bright and nice directions now ;) Hope someone finds this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] msi: Invert the sense of the MSI enables.
> > In addition to PCI INTx compatible interrupt emulation, PCI Express > > requires support of MSI or MSI-X or both. > Which suggests that INTx support is required. > > I do not find any wording that suggest the opposite. > I do see it stated that it is intended to EOL support for INTx at > some point. > > Where did you see it mentioned that INTx was optional? I don't see any requirement that a device that generates MSI interrupts must also be able to signal the same interrupts via INTx. The spec explicitly says: "All PCI Express device Functions that are capable of generating interrupts must support MSI or MSI-X or both." but there is no corresponding explicit requirement that legacy INTx mode be supported, so it certainly seems permitted for a device not to generate INTx interrupts. In fact as you alluded to, the spec says, "The legacy INTx emulation mechanism may be deprecated in a future version of this specification." and I wouldn't think the intention would be for one version of the spec to *require* something that is planned on being deprecated later. And the Pathscale guys were pretty confident that their device was compliant with the PCIe spec. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc1-mm1: evm BUG when reading sysfs file
Andrew Morton <[EMAIL PROTECTED]> wrote on 05/22/2007 05:23:05 PM: > On Tue, 22 May 2007 03:25:48 -0400 > [EMAIL PROTECTED] (Joseph Fannin) wrote: > > > This comes a bit after IMA bails out successfully, if that's relevant: ... > > > > [1.708761] ima (ima_init): No TPM chip found(rc = -19), activating > > TPM-bypass! > > OK, thanks. Does the crash go away if you disable IMA, SLIM, etc in .config? > > I think I'll drop all those patches, actually - they don't seem to be going > anywhere. You are absolutely right, we have been stalled on EVM/IMA/SLIM, while trying to figure out the mtime and revocation issues. In retrospect we tried to submit too much complex code all at once. We will resubmit in small functional pieces as the technical issues have been resolved, starting with the LIM API and hooks, which are independent of the mtime and revocation issues. Mimi Zohar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 6/7] ps3: ROM Storage Driver
On Friday 25 May 2007, Geert Uytterhoeven wrote: > > > What is the problem? Is there infrastructure missing in the > > CD-ROM layer? > > As the CD/DVD/BD part just accepts SCSI/ATAPI commands (except for plain > read/write), I was suggested to keep it as a SCSI driver. Ok, so I guess the tradeoff here is that by writing it as a SCSI driver, you don't need to implement any of the cdrom_device_ops yourself but instead need to fake a few of the SCSI commands in ps3rom_request(). Fair enough. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] non-string based tsc unstable reasons
On Fri, May 25, 2007 at 12:32:10PM -0700, Daniel Walker wrote: > Just passing a string to mark_tsc_unstable() doesn't allow real code to change > based on the reason for the instablility. I changed mark_tsc_unstable() > to accept a string and a flag which denotes a general reason why the tsc > is unstable, and can be evaluated in code. > I still think that's the wrong way to do this. If there is any special action that should be done on particular unstable events it should call a separate function or an addon function. First putting it all together and then try to distingush it again doesn't seem nice. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, 25 May 2007 11:36:22 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote: > 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't > matter. Bringing up the interface manually still works, so I suspect > this is sysfs or HAL related again. Again, Debian unstable so > userspace is quite up-to-date. > Are you renaming network devices? Using /etc/iftab seems to confuse NM (maybe a HAL problem). -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double exclamation (!!) suckage in the kernel
On 5/26/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: On 5/26/07, Al Viro <[EMAIL PROTECTED]> wrote: > > That's a question for a quiz in introductory course on C: Ugh ... ok, I've embarrassed myself publicly already, so I'll also be brave enough to take a C quiz here :-) Hmmm, and now I seem to have flunked ... > what type should x have for !!x to be a valid expression? Any integer type (includes pointers) gcc doesn't seem to mind a ! on a float either (does it do an implicit cast to int first?). Can't think of too many situations where one would want to do a ! on a float, actually, in any case ... > what will be the type of result? int (I guess boolean for C99?) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 12:53:19PM -0500, Matt Mackall wrote: > On Fri, May 25, 2007 at 07:37:46PM +0200, Kay Sievers wrote: > > On 5/25/07, Greg KH <[EMAIL PROTECTED]> wrote: > > >On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: > > >> 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't > > >> matter. Bringing up the interface manually still works, so I suspect > > >> this is sysfs or HAL related again. Again, Debian unstable so > > >> userspace is quite up-to-date. > > > > > >I don't have any driver model changes that affect network devices in my > > >tree. Could you go through and bisect the -mm tree to see if you can > > >find the patch that causes this? > > > > Does it work, when you unload and load the kernel module? > > rmmod followed by insmod had no effect. > > > Does it work when you restart HAL and then NetworkManager? > > I restarted dbus, which stopped and restarted HAL and NM. No effect. > > > Can you compare the sections for the wireless card in the output of "lshal"? > > The unhappy one looks like this: > > udi = '/org/freedesktop/Hal/devices/pci_8086_4220' > info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) > linux.subsystem = 'pci' (string) > linux.hotplug_type = 1 (0x1) (int) > pci.subsys_product = 'Unknown (0x2711)' (string) > pci.subsys_vendor = 'Intel Corporation' (string) > info.product = 'PRO/Wireless 2200BG Network Connection' (string) > pci.product = 'PRO/Wireless 2200BG Network Connection' (string) > info.vendor = 'Intel Corporation' (string) > pci.vendor = 'Intel Corporation' (string) > pci.device_protocol = 0 (0x0) (int) > pci.device_subclass = 128 (0x80) (int) > pci.device_class = 2 (0x2) (int) > pci.subsys_vendor_id = 32902 (0x8086) (int) > pci.subsys_product_id = 10001 (0x2711) (int) > pci.vendor_id = 32902 (0x8086) (int) > pci.product_id = 16928 (0x4220) (int) > info.linux.driver = 'ipw2200' (string) > pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' > (string) > info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) > info.bus = 'pci' (string) > linux.sysfs_path_device = > '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) > linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' > (string) > > Will let you know when my bisecting finds a happy one. Here's a happy one: udi = '/org/freedesktop/Hal/devices/pci_8086_4220' info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) linux.subsystem = 'pci' (string) linux.hotplug_type = 1 (0x1) (int) pci.subsys_product = 'Unknown (0x2711)' (string) pci.subsys_vendor = 'Intel Corporation' (string) info.product = 'PRO/Wireless 2200BG Network Connection' (string) pci.product = 'PRO/Wireless 2200BG Network Connection' (string) info.vendor = 'Intel Corporation' (string) pci.vendor = 'Intel Corporation' (string) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 128 (0x80) (int) pci.device_class = 2 (0x2) (int) pci.subsys_vendor_id = 32902 (0x8086) (int) pci.subsys_product_id = 10001 (0x2711) (int) pci.vendor_id = 32902 (0x8086) (int) pci.product_id = 16928 (0x4220) (int) info.linux.driver = 'ipw2200' (string) pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) info.bus = 'pci' (string) linux.sysfs_path_device = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) Look the same to me. So far I'm down to: patch 56: good patch 113: bad 56 powerpc-ps3-use-__maybe_unused.patch 57 do-not-select-macintosh-drivers-by-default.patch 58 powerpc-promc-remove-undef-printk.patch 59 powerpc-fix-kconfig-select-warning-with-ucc_fast.patch 60 8xx-mpc885ads-pcmcia-support.patch 61 8xx-mpc885ads-pcmcia-support-fix.patch 62 8xx-fix-whitespace-and-indentation.patch 63 dts-kill-hardcoded-phandles.patch 64 gregkh-driver-debugfs-add-rename-for-debugfs-files.patch 65 gregkh-driver-update-documentation-driver-model-platformtxt.patch 66 gregkh-driver-driver-core-keep-physdev-for-old-struct-class_device.patch 67 gregkh-driver-driver-core-kill-unused-code.patch 68 gregkh-driver-howto-removing-duplicated-entry.patch 69 gregkh-driver-dmi-based-module-autoloading.patch 70 gregkh-driver-uio.patch 71 gregkh-driver-uio-documentation.patch 72 gregkh-driver-uio-hilscher-cif-card-driver.patch 73 gregkh-driver-idr-fix-obscure-bug-in-allocation-path.patch 74 gregkh-driver-idr-separate-out-idr_mark_full.patch 75 gregkh-driver-ida-implement-idr-based-id-allocator.patch 76 gregkh-driver-sysfs-move-release_sysfs_dirent-to-dirc.patch 77 gregkh-driver-sysfs-allocate-inode-number-using-ida.patch
Re: double exclamation (!!) suckage in the kernel
On 5/26/07, Al Viro <[EMAIL PROTECTED]> wrote:
On Sat, May 26, 2007 at 01:53:59AM +0530, Satyam Sharma wrote:
> Hello,
>
> Grepping through the sources I found 500+ occurrences of double
> exclamation marks before identifier names (such as !!x -- I took care
> to ignore occurrences of !! inside comment blocks, because there
> are plenty of that sort too).
>
> !! are to be found even in the definitions of common macros such as
> likely() and unlikely(), which hundreds of eyes must have seen over
> the last year or so ...
>
> Are all these occurrences merely the debris of
> s/something/!notsomething/g kind of patches or is there some
> dark, unknown C / gcc wizardry I have absolutely no clue of?
That's a question for a quiz in introductory course on C:
Ugh ... ok, I've embarrassed myself publicly already, so I'll
also be brave enough to take a C quiz here :-)
what type should x have for !!x to be a valid expression?
Any integer type (includes pointers)
what will be the type of result?
int (I guess boolean for C99?)
what are the possible values of the result?
{0, 1}
describe which values of x correspond to each possible value of !!x
Russell's mail has already answered that ...
You have 10 minutes (and that's a fairly generous, actually).
Hmmm, looking through the grep output, actually, it seems some of the
occurrences of !! are indeed debris, but yes, most are actually a way to
force the output to {0, 1} when dealing with individual bits in code.
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21] BUG: at fs/inotify.c:172 set_dentry_child_flags()
Matheus Izvekov wrote: Got this BUG_ON twice in a row, just found it by scrolling thru my dmesg. BUG: at fs/inotify.c:172 set_dentry_child_flags() http://bugzilla.kernel.org/show_bug.cgi?id=7785 If you can reproduce it, looks like some help diagnosing it would be useful. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/7] ps3: Disk Storage Driver
On Fri, May 25, Geert Uytterhoeven wrote: > On Fri, 25 May 2007, Olaf Hering wrote: > > On Fri, May 25, [EMAIL PROTECTED] wrote: > > > Add a Disk Storage Driver for the PS3: > > > > There is no device symlink in /sys/block/ps3da/ > > Interesting... Do you know how to create it? No, that was not obvious. But for gelic it goes like this: +++ b/drivers/net/gelic_net.c @@ -1364,6 +1364,7 @@ static int gelic_net_setup_netdev(struct u64 v1, v2; SET_MODULE_OWNER(netdev); + SET_NETDEV_DEV(netdev, >dev->core); spin_lock_init(>tx_dma_lock); card->rx_csum = GELIC_NET_RX_CSUM_DEFAULT; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 5/7] ps3: Disk Storage Driver
On Friday 25 May 2007, Geert Uytterhoeven wrote: > > > I don't really understand what the kthread is needed for. You probably > > thought about multiple options and ended up with this, but having > > a comment in front of it might be helpful. > > I used a kthread because the request function of a block device driver must be > non-blocking, and ps3stor_read_write_sectors() calls wait_for_completion(). Ok, but why does it call wait_for_completion() then? I thought you could end_that_request_* from the interrupt handler instead. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double exclamation (!!) suckage in the kernel
On Sat, May 26, 2007 at 01:53:59AM +0530, Satyam Sharma wrote: > Hello, > > Grepping through the sources I found 500+ occurrences of double > exclamation marks before identifier names (such as !!x -- I took care > to ignore occurrences of !! inside comment blocks, because there > are plenty of that sort too). > > !! are to be found even in the definitions of common macros such as > likely() and unlikely(), which hundreds of eyes must have seen over > the last year or so ... > > Are all these occurrences merely the debris of > s/something/!notsomething/g kind of patches or is there some > dark, unknown C / gcc wizardry I have absolutely no clue of? That's a question for a quiz in introductory course on C: what type should x have for !!x to be a valid expression? what will be the type of result? what are the possible values of the result? describe which values of x correspond to each possible value of !!x You have 10 minutes (and that's a fairly generous, actually). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double exclamation (!!) suckage in the kernel
On 2007.05.26 01:53:59 +0530, Satyam Sharma wrote:
> Hello,
>
> Grepping through the sources I found 500+ occurrences of double
> exclamation marks before identifier names (such as !!x -- I took care
> to ignore occurrences of !! inside comment blocks, because there
> are plenty of that sort too).
>
> !! are to be found even in the definitions of common macros such as
> likely() and unlikely(), which hundreds of eyes must have seen over
> the last year or so ...
>
> Are all these occurrences merely the debris of
> s/something/!notsomething/g kind of patches or is there some
> dark, unknown C / gcc wizardry I have absolutely no clue of?
It avoids useless warnings. If you have a pointer and want to store if
it is NULL/non-NULL in an integer variables, you have to use !x or !!x.
Just using x will result in a warning that you convert a pointer to an
integer without a cast.
Given this example:
int main()
{
int ret;
void *foo;
ret = foo;
ret = !!foo;
return 0;
}
gcc will emit this warning:
ttt.c:6: warning: assignment makes integer from pointer without a cast
HTH
Björn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/3] 2.6.22-rc2: known regressions v2
From: Chris Newport <[EMAIL PROTECTED]> Date: Fri, 25 May 2007 19:03:51 +0100 > Not really a Solaris feature. This is a feature of the Openboot PROM > which is also used by several other vendors. > The Openboot PROM knows how to write to disk. The same should > apply on Apple hardware and others which use the openboot > convention. This is totally unusable even if it weren't stupid, and as someone who loves OpenBoot I think it's very stupid. The reason it's unusable is that PowerPC already and sparc64 soon (in order to support LDOMs) totally drops the OBP firmware very soon after early kernel boot. We pull in the device tree and then say "see ya" to openboot. PowerPC does it because sharing the address space with openboot is next to impossible on that cpu, sparc64 will need to do it because dynamic-reconfiguration of cpus in an LDOM is too hard to do with openboot there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] msi: Invert the sense of the MSI enables.
On Fri, May 25, 2007 at 09:17:35AM -0600, Eric W. Biederman wrote: > Greg KH <[EMAIL PROTECTED]> writes: > > > Originally I would have thought this would be a good idea, but now that > > Vista is out, which supports MSI, I don't think we are going to need > > this in the future. All new chipsets should support MSI fine and this > > table will only grow in the future, while the blacklist should not need > > to have many new entries added to it. > > > > So I don't think this is a good idea, sorry. > > - The current situation is broken > - In spec hardware does not require MSI to generate interrupts > Which leaves enabling MSI optional. > > Do you have a better idea to solve the current brokenness? > > MSI appears to have enough problems that enabling it in a kernel > that is supposed to run lots of different hardware (like a distro > kernel) is a recipe for disaster. Oh, I agree it's a major pain in the ass at times... But I'm real hesitant to change things this way. We'll get reports of people who used to have MSI working, and now it will not (like all AMD chipsets). That's a regression... Perhaps we can trigger off of the same flag that Vista uses like Andi suggested? That's one way to "know" that the hardware works, right? For non-x86 arches, they all seem to want to always enable MSI as they don't have to deal with as many broken chipsets, if any at all. So for them, we'd have to just whitelist the whole arch. Does that really make sense? And again, over time, like years, this list is going to grow way beyond a managable thing, especially as any new chipset that comes out in 2009 is going to have working MSI, right? I think our blacklist is easier to manage over time, while causing a problem for some users in trying to determine their broken hardware that they currently have. It's a trade off, and I'd like to choose the one that over the long term, causes the least ammount of work and maintaiblity. I think the current blacklist meets that goal. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double exclamation (!!) suckage in the kernel
On 5/26/07, Russell King <[EMAIL PROTECTED]> wrote:
On Sat, May 26, 2007 at 01:53:59AM +0530, Satyam Sharma wrote:
> Are all these occurrences merely the debris of
> s/something/!notsomething/g kind of patches or is there some
> dark, unknown C / gcc wizardry I have absolutely no clue of?
Try building and running this:
#include
int main()
{
int i;
for (i = 0; i < 10; i++)
printf("%d: %d\n", i, !!i);
return 0;
}
and you should see it's effect.
Ah, yes, of course I see now!
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: double exclamation (!!) suckage in the kernel
On Sat, May 26, 2007 at 01:53:59AM +0530, Satyam Sharma wrote:
> Are all these occurrences merely the debris of
> s/something/!notsomething/g kind of patches or is there some
> dark, unknown C / gcc wizardry I have absolutely no clue of?
Try building and running this:
#include
int main()
{
int i;
for (i = 0; i < 10; i++)
printf("%d: %d\n", i, !!i);
return 0;
}
and you should see it's effect.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [CodingStyle] Add comment to not put spaces before tabs.
H. Peter Anvin wrote: Stefan Richter wrote: Auke Kok wrote: +Don't put spaces before tabs or mix them. Make it "Don't put spaces before tabs." We do mix them if we combine tabs for indentation with spaces for alignment. It would probably be good to add a pointer to the cleanfile/cleanpatch scripts here, too. ahh yes, I'll incorporate that. BTW, would it be possible for cleanfile/cleanpatch to dump warnings to stderr for lines exceeding 80 characters? I think that would really be useful... Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
--- Andreas Gruenbacher <[EMAIL PROTECTED]> wrote: > On Friday 25 May 2007 19:43, Casey Schaufler wrote: > > [...] but the AppArmor code could certainly check for that in exec by > > enforcing the argv[0] convention. It would be perfectly reasonable for a > > system that is so dependent on pathnames to require that. > > Hmm ... that's a strange idea. Yeah, I get that a lot. > AppArmor cannot assume anything about argv[0], > > and it would be a really bad idea to change the well-established semantics of > > argv[0]. > > There is no actual need for looking at argv[0], though: AppArmor decides > based > on the actual pathname of the executable... Right. My point was that if you wanted to use the gzip/gunzip example of a file with two names being treated differently based on the name accessed as an argument for AppArmor you could. If you don't want to, that's ok too. Jeremy raised a reasonable objection, and AppArmor could address it if y'all chose to do so. I seriously doubt that enforcing the argv[0] convention would break much, and I also expect that if it did there's a Consultant's Retirement to be made fixing the security hole it points out. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] msi: Invert the sense of the MSI enables.
On May 24, 2007, at 10:51 PM, Andi Kleen wrote: Do we have a feel for how much performace we're losing on those systems which _could_ do MSI, but which will end up defaulting to not using it? At least on 10GB ethernet it is a significant difference; you usually cannot go anywhere near line speed without MSI I suspect it is visible on high performance / multiple GB NICs too. Why would that be? As the packet rate goes up and NAPI polling kicks in, wouldn't MSI make less and less difference? I like the fact that MSI gives us finer control over CPU affinity than many INTx implementations, but that's a different issue. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
double exclamation (!!) suckage in the kernel
Hello, Grepping through the sources I found 500+ occurrences of double exclamation marks before identifier names (such as !!x -- I took care to ignore occurrences of !! inside comment blocks, because there are plenty of that sort too). !! are to be found even in the definitions of common macros such as likely() and unlikely(), which hundreds of eyes must have seen over the last year or so ... Are all these occurrences merely the debris of s/something/!notsomething/g kind of patches or is there some dark, unknown C / gcc wizardry I have absolutely no clue of? Thanks, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
