Re: [PATCH] scripts: Make cleanfile/cleanpatch warn about long lines

2007-05-25 Thread H. Peter Anvin
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

2007-05-25 Thread David Miller
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

2007-05-25 Thread Andrew Morton
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

2007-05-25 Thread Tej Parkash

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

2007-05-25 Thread Crispin Cowan
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

2007-05-25 Thread Kyle Moffett

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)

2007-05-25 Thread Michael Buesch
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

2007-05-25 Thread Ulrich Drepper
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

2007-05-25 Thread Linus Torvalds

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

2007-05-25 Thread Jeff Garzik

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

2007-05-25 Thread Kyle Moffett

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.

2007-05-25 Thread Matt Domsch
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

2007-05-25 Thread Srihari Vijayaraghavan
--- 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

2007-05-25 Thread Reiner Sailer
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)

2007-05-25 Thread Chris Wright
* 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

2007-05-25 Thread J. Bruce Fields
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

2007-05-25 Thread Jeff Dike
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

2007-05-25 Thread Christoph Lameter
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

2007-05-25 Thread Tetsuo Handa
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

2007-05-25 Thread Roland McGrath
> 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.

2007-05-25 Thread Andreas Dilger
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

2007-05-25 Thread H. Peter Anvin
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

2007-05-25 Thread Peter Williams

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

2007-05-25 Thread Jeff Garzik

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)

2007-05-25 Thread Herbert Xu
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

2007-05-25 Thread Claudio Fontana

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

2007-05-25 Thread Mikael Pettersson
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

2007-05-25 Thread Andrew Morton
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

2007-05-25 Thread H. Peter Anvin
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

2007-05-25 Thread Ben Collins
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

2007-05-25 Thread Jesse Barnes
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)

2007-05-25 Thread Jeff Garzik

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

2007-05-25 Thread H. Peter Anvin
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

2007-05-25 Thread Kay Sievers
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

2007-05-25 Thread Hugh Dickins
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

2007-05-25 Thread Jesse Barnes
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

2007-05-25 Thread H. Peter Anvin
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

2007-05-25 Thread Jesse Barnes
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

2007-05-25 Thread Greg KH
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

2007-05-25 Thread Matt Mackall
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.

2007-05-25 Thread Satyam Sharma

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

2007-05-25 Thread Benjamin Herrenschmidt
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

2007-05-25 Thread Benjamin Herrenschmidt
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

2007-05-25 Thread Benjamin Herrenschmidt

> 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.

2007-05-25 Thread H. Peter Anvin
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

2007-05-25 Thread Benjamin Herrenschmidt
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

2007-05-25 Thread chandramouli narayanan

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

2007-05-25 Thread Benjamin Herrenschmidt
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

2007-05-25 Thread Arnd Bergmann
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.

2007-05-25 Thread Satyam Sharma

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

2007-05-25 Thread Benjamin Herrenschmidt
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.

2007-05-25 Thread H. Peter Anvin
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.

2007-05-25 Thread Satyam Sharma

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)

2007-05-25 Thread Kok, Auke

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

2007-05-25 Thread Roland Dreier
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

2007-05-25 Thread Jeff Garzik

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

2007-05-25 Thread Andrew Morton
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]

2007-05-25 Thread Andrew Morton
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.

2007-05-25 Thread Brice Goglin
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

2007-05-25 Thread Greg KH
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.

2007-05-25 Thread Greg KH
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)

2007-05-25 Thread Greg KH
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?

2007-05-25 Thread Adrian Bunk
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.

2007-05-25 Thread H. Peter Anvin
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

2007-05-25 Thread Antonino A. Daplas
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

2007-05-25 Thread Satyam Sharma

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

2007-05-25 Thread Al Viro
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

2007-05-25 Thread Daniel Walker
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

2007-05-25 Thread Takashi Iwai
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

2007-05-25 Thread Al Viro
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

2007-05-25 Thread Jeff Garzik

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.

2007-05-25 Thread H. Peter Anvin
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

2007-05-25 Thread Geert Uytterhoeven
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]

2007-05-25 Thread J.A. Magallón
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.

2007-05-25 Thread Roland Dreier
 > 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

2007-05-25 Thread David Miller
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.

2007-05-25 Thread Robert P. J. Day
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.

2007-05-25 Thread Eric W. Biederman
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

2007-05-25 Thread Rui Nuno Capela
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.

2007-05-25 Thread Roland Dreier
 > > 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

2007-05-25 Thread Mimi Zohar
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

2007-05-25 Thread Arnd Bergmann
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

2007-05-25 Thread Andi Kleen
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

2007-05-25 Thread Stephen Hemminger
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

2007-05-25 Thread Satyam Sharma

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

2007-05-25 Thread Matt Mackall
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

2007-05-25 Thread Satyam Sharma

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()

2007-05-25 Thread Daniel Drake

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

2007-05-25 Thread Olaf Hering
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

2007-05-25 Thread Arnd Bergmann
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

2007-05-25 Thread Al Viro
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

2007-05-25 Thread Björn Steinbrink
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

2007-05-25 Thread David Miller
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.

2007-05-25 Thread Greg KH
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

2007-05-25 Thread Satyam Sharma

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

2007-05-25 Thread Russell King
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.

2007-05-25 Thread Kok, Auke

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

2007-05-25 Thread Casey Schaufler

--- 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.

2007-05-25 Thread Jonathan Lundell

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

2007-05-25 Thread Satyam Sharma

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/


  1   2   3   4   5   6   7   8   9   >