Re: Hard lockups using 3.10.0
Borislav Petkov wrote: On Sun, Aug 11, 2013 at 08:09:19AM +0200, Rolf Eike Beer wrote: Meanwhile I found that there was a hardware defect on this machine. So if it does not happen again I will assume that this was caused by this. What hardware defect exactly? DIMMs failing...? Probably, since it looks like the spinlock gets corrupted and the assertion fires... In any case, it would be interesting to know for future reference. The RAM seems fine. It looks like it is the mainboard or a harddisk. The issues have magically disappeared since 3 weeks, but I have not done any suspend2disk since then anymore. Before that I had suspended the machine on the evening and resumed when I came to work. So it's possible that there was some corrupted stuff in the image. This is the smart output I got of one disk yesterday: Vendor: /0:0:0:0 Product: User Capacity:600,332,565,813,390,450 bytes [600 PB] Logical block size: 774843950 bytes scsiModePageOffset: response length too short, resp_len=47 offset=50 bd_len=46 Terminate command early due to bad response to IEC mode page A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. Eike signature.asc Description: This is a digitally signed message part.
Re: Hard lockups using 3.10.0
Paul E. McKenney wrote: > On Thu, Jul 11, 2013 at 12:52:07PM +0200, Peter Zijlstra wrote: > > On Thu, Jul 11, 2013 at 12:07:21PM +0200, Borislav Petkov wrote: > > > On Thu, Jul 11, 2013 at 11:38:37AM +0200, Rolf Eike Beer wrote: > > > > Hi, > > > > > > > > I'm running 3.10.0 (from openSUSE packages) on an "Intel(R) Core(TM) > > > > i7-2600 CPU @ 3.40GHz". I got a hard lockup on one of my CPUs twice, > > > > once with backtrace (see attached image). Graphics is the builtin > > > > Intel, used with X 7.6 and KDE 4.10beta2 (basically current openSUSE > > > > 12.3+KDE). > > > > > > > > I'm not aware that I had done anything special, just "normal" desktop > > > > and > > > > development usage, but no heavy compile work at the moment the lockups > > > > happened. > > > > > > Hmm, I can see commit_creds() doing some rcu pointers assignment and rcu > > > calling into the scheduler which screams about a cpu runqueue of the > > > task we're about to reschedule not being locked. Let's add some more > > > people who should know better. > > > > Ok, for the other people too lazy to bother finding the picture: > > http://marc.info/?l=linux-kernel=137353587012001=p3 > > > > So we bug at: > > > > kernel/sched/core.c:519 assert_raw_spin_locked(_rq(p)->lock); > > > > and get there through: > > resched_task() > > check_preempt_wakeup() > > check_preempt_curr() > > try_to_wake_up() > > autoremove_wake_function() > > __call_rcu_nocb_enqueue() > > __call_rcu() > > commit_creds() > > call_usermodehelper() > > ret_from_fork() > > > > That don't make much sense though. Since: > > try_to_wake_up() > > > > ttwu_queue() > > > > raw_spin_lock(>lock) > > ttwu_do_activate() > > > > ttwu_do_wakeup() > > > > check_preempt_curr() > > > > check_preempt_wakeup() > > > > resched_task(rq->curr) > > > > assert_raw_spin_locked(task_rq(p)->lock) > > > > It would somehow mean that 'task_rq(rq->curr) != rq', that's completely > > bonkers, we do after all have rq->lock locked. > > > > I must also say that I've _never_ seen this bug before. > > New one on me as well. Is this reproducible? If so, does it happen > when CONFIG_RCU_NOCB_CPU=n? (Given the call to call_rcu_nocb_enqueue(), > I expect that you built with CONFIG_RCU_NOCB_CPU=y.) Can't say that I > see how call_rcu_nocb_enqueue() would have caused this, but... > > Well, I supposed that if RCU's callback lists got corrupted, this > (and much else besides) could in fact happen. Does your build have > CONFIG_DEBUG_OBJECTS_RCU_HEAD=y? If not, could you please try it? I will look tomorrow. This is a "standard" openSUSE kernel RPM, dunno right now which repository. It is not really reproducible, it suddenly happened again today but this time without backtrace. Eike signature.asc Description: This is a digitally signed message part.
Re: Hard lockups using 3.10.0
Paul E. McKenney wrote: On Thu, Jul 11, 2013 at 12:52:07PM +0200, Peter Zijlstra wrote: On Thu, Jul 11, 2013 at 12:07:21PM +0200, Borislav Petkov wrote: On Thu, Jul 11, 2013 at 11:38:37AM +0200, Rolf Eike Beer wrote: Hi, I'm running 3.10.0 (from openSUSE packages) on an Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz. I got a hard lockup on one of my CPUs twice, once with backtrace (see attached image). Graphics is the builtin Intel, used with X 7.6 and KDE 4.10beta2 (basically current openSUSE 12.3+KDE). I'm not aware that I had done anything special, just normal desktop and development usage, but no heavy compile work at the moment the lockups happened. Hmm, I can see commit_creds() doing some rcu pointers assignment and rcu calling into the scheduler which screams about a cpu runqueue of the task we're about to reschedule not being locked. Let's add some more people who should know better. Ok, for the other people too lazy to bother finding the picture: http://marc.info/?l=linux-kernelm=137353587012001q=p3 So we bug at: kernel/sched/core.c:519 assert_raw_spin_locked(task_rq(p)-lock); and get there through: resched_task() check_preempt_wakeup() check_preempt_curr() try_to_wake_up() autoremove_wake_function() __call_rcu_nocb_enqueue() __call_rcu() commit_creds() call_usermodehelper() ret_from_fork() That don't make much sense though. Since: try_to_wake_up() ttwu_queue() raw_spin_lock(rq-lock) ttwu_do_activate() ttwu_do_wakeup() check_preempt_curr() check_preempt_wakeup() resched_task(rq-curr) assert_raw_spin_locked(task_rq(p)-lock) It would somehow mean that 'task_rq(rq-curr) != rq', that's completely bonkers, we do after all have rq-lock locked. I must also say that I've _never_ seen this bug before. New one on me as well. Is this reproducible? If so, does it happen when CONFIG_RCU_NOCB_CPU=n? (Given the call to call_rcu_nocb_enqueue(), I expect that you built with CONFIG_RCU_NOCB_CPU=y.) Can't say that I see how call_rcu_nocb_enqueue() would have caused this, but... Well, I supposed that if RCU's callback lists got corrupted, this (and much else besides) could in fact happen. Does your build have CONFIG_DEBUG_OBJECTS_RCU_HEAD=y? If not, could you please try it? I will look tomorrow. This is a standard openSUSE kernel RPM, dunno right now which repository. It is not really reproducible, it suddenly happened again today but this time without backtrace. Eike signature.asc Description: This is a digitally signed message part.
[PATCH] ThunderLAN: remove is_eisa flag
These 2 places are the only matches for is_eisa in the whole tree.
Signed-off-by: Rolf Eike Beer
---
drivers/net/ethernet/ti/tlan.c | 1 -
drivers/net/ethernet/ti/tlan.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index 60c400f..59abfbc 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -533,7 +533,6 @@ static int tlan_probe1(struct pci_dev *pdev, long ioaddr,
int irq, int rev,
/* This is a hack. We need to know which board structure
* is suited for this adapter */
device_id = inw(ioaddr + EISA_ID2);
- priv->is_eisa = 1;
if (device_id == 0x20F1) {
priv->adapter = _info[13]; /* NetFlex-3/E */
priv->adapter_rev = 23; /* TLAN 2.3 */
diff --git a/drivers/net/ethernet/ti/tlan.h b/drivers/net/ethernet/ti/tlan.h
index 5fc98a8..2eb33a2 100644
--- a/drivers/net/ethernet/ti/tlan.h
+++ b/drivers/net/ethernet/ti/tlan.h
@@ -207,7 +207,6 @@ struct tlan_priv {
u8 tlan_full_duplex;
spinlock_t lock;
u8 link;
- u8 is_eisa;
struct work_struct tlan_tqueue;
u8 neg_be_verbose;
};
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ThunderLAN: remove is_eisa flag
These 2 places are the only matches for is_eisa in the whole tree.
Signed-off-by: Rolf Eike Beer eike-ker...@sf-tec.de
---
drivers/net/ethernet/ti/tlan.c | 1 -
drivers/net/ethernet/ti/tlan.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index 60c400f..59abfbc 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -533,7 +533,6 @@ static int tlan_probe1(struct pci_dev *pdev, long ioaddr,
int irq, int rev,
/* This is a hack. We need to know which board structure
* is suited for this adapter */
device_id = inw(ioaddr + EISA_ID2);
- priv-is_eisa = 1;
if (device_id == 0x20F1) {
priv-adapter = board_info[13]; /* NetFlex-3/E */
priv-adapter_rev = 23; /* TLAN 2.3 */
diff --git a/drivers/net/ethernet/ti/tlan.h b/drivers/net/ethernet/ti/tlan.h
index 5fc98a8..2eb33a2 100644
--- a/drivers/net/ethernet/ti/tlan.h
+++ b/drivers/net/ethernet/ti/tlan.h
@@ -207,7 +207,6 @@ struct tlan_priv {
u8 tlan_full_duplex;
spinlock_t lock;
u8 link;
- u8 is_eisa;
struct work_struct tlan_tqueue;
u8 neg_be_verbose;
};
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] parisc updates for v3.10
> Helge Deller (2): > parisc: make default cross compiler search more robust (v3) Needs CC:stable as without this building 3.9.x is not possible in some configurations. > John David Anglin (1): > parisc: fix SMP races when updating PTE and TLB entries in entry.S Possibly also this as it's a bugfix, but Dave is the one who may be judge how "clear" it is. The same is probably true for these from the first round of updates: John David Anglin (2): parisc: use long branch in fork_like macro Mike Frysinger (1): parisc: fix NATIVE set up in build While I _really_ appreciate the speedup that recently happened to the parisc development recently I would also appreciate if we can can finally get the bugfix parts of that into stable kernels so we have the non-development tree buildable and working without the need to backport all those stuff by hand. Eike signature.asc Description: This is a digitally signed message part.
Re: [GIT PULL] parisc updates for v3.10
Helge Deller (2): parisc: make default cross compiler search more robust (v3) Needs CC:stable as without this building 3.9.x is not possible in some configurations. John David Anglin (1): parisc: fix SMP races when updating PTE and TLB entries in entry.S Possibly also this as it's a bugfix, but Dave is the one who may be judge how clear it is. The same is probably true for these from the first round of updates: John David Anglin (2): parisc: use long branch in fork_like macro Mike Frysinger (1): parisc: fix NATIVE set up in build While I _really_ appreciate the speedup that recently happened to the parisc development recently I would also appreciate if we can can finally get the bugfix parts of that into stable kernels so we have the non-development tree buildable and working without the need to backport all those stuff by hand. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] parisc: unbreak automounter support on 64-bit kernel with 32-bit userspace
H. Peter Anvin wrote: > On 01/31/2013 01:42 PM, James Bottomley wrote: > > On Thu, 2013-01-31 at 13:29 -0800, H. Peter Anvin wrote: > >> On 01/31/2013 12:26 PM, James Bottomley wrote: > >>> [adding autofs list and maintainer for their perusal and ack, although > >>> this is an obvious fix to me > >>> > >>> James] > >> > >> The #if list probably should be inverted, and only specific platforms > >> should have unsigned long... > > > > The whitelist is 64 bit only platforms, like ia64, isn't it? So yes, > > they're far less numerous. > > Correct. It is basically the 64-bit platforms without any 32-bit > userspace, like Alpha and IA64. Arm64? Should this be a CONFIG_ARCH_CAN_HAVE_32BIT_USERSPACE that would cover this? And may e.g. be used to remove compat_ioctl on those archs, too? Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] parisc: unbreak automounter support on 64-bit kernel with 32-bit userspace
James Bottomley wrote: > [adding autofs list and maintainer for their perusal and ack, although > this is an obvious fix to me > > James] > > On Thu, 2013-01-31 at 21:01 +0100, Helge Deller wrote: > > Similiar to other 64 bit Linux targets autofs_wqt_t needs to be of type > > int > > which has a size of 32 bits on 32- and 64-bit parisc kernels. > > > > Signed-off-by: Helge Deller > > > > diff --git a/include/uapi/linux/auto_fs.h b/include/uapi/linux/auto_fs.h > > index 77cdba9..d551754 100644 > > --- a/include/uapi/linux/auto_fs.h > > +++ b/include/uapi/linux/auto_fs.h > > @@ -43,7 +43,7 @@ > > > > */ > > > > #if defined(__sparc__) || defined(__mips__) || defined(__x86_64__) \ > > > > - || defined(__powerpc__) || defined(__s390__) > > + || defined(__powerpc__) || defined(__s390__) || defined(__hppa__) > > > > typedef unsigned int autofs_wqt_t; > > #else > > typedef unsigned long autofs_wqt_t; Wouldn't it make sense to make it an unsigned int on all platforms? This wouldn't make any difference on 32 bit platforms and would prevent that to happen on the next 32-on-64 bit platform again. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] parisc: unbreak automounter support on 64-bit kernel with 32-bit userspace
James Bottomley wrote: [adding autofs list and maintainer for their perusal and ack, although this is an obvious fix to me James] On Thu, 2013-01-31 at 21:01 +0100, Helge Deller wrote: Similiar to other 64 bit Linux targets autofs_wqt_t needs to be of type int which has a size of 32 bits on 32- and 64-bit parisc kernels. Signed-off-by: Helge Deller del...@gmx.de diff --git a/include/uapi/linux/auto_fs.h b/include/uapi/linux/auto_fs.h index 77cdba9..d551754 100644 --- a/include/uapi/linux/auto_fs.h +++ b/include/uapi/linux/auto_fs.h @@ -43,7 +43,7 @@ */ #if defined(__sparc__) || defined(__mips__) || defined(__x86_64__) \ - || defined(__powerpc__) || defined(__s390__) + || defined(__powerpc__) || defined(__s390__) || defined(__hppa__) typedef unsigned int autofs_wqt_t; #else typedef unsigned long autofs_wqt_t; Wouldn't it make sense to make it an unsigned int on all platforms? This wouldn't make any difference on 32 bit platforms and would prevent that to happen on the next 32-on-64 bit platform again. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] parisc: unbreak automounter support on 64-bit kernel with 32-bit userspace
H. Peter Anvin wrote: On 01/31/2013 01:42 PM, James Bottomley wrote: On Thu, 2013-01-31 at 13:29 -0800, H. Peter Anvin wrote: On 01/31/2013 12:26 PM, James Bottomley wrote: [adding autofs list and maintainer for their perusal and ack, although this is an obvious fix to me James] The #if list probably should be inverted, and only specific platforms should have unsigned long... The whitelist is 64 bit only platforms, like ia64, isn't it? So yes, they're far less numerous. Correct. It is basically the 64-bit platforms without any 32-bit userspace, like Alpha and IA64. Arm64? Should this be a CONFIG_ARCH_CAN_HAVE_32BIT_USERSPACE that would cover this? And may e.g. be used to remove compat_ioctl on those archs, too? Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 0/5] Multiqueue virtio-scsi, and API for piecewise buffer submission
Paolo Bonzini wrote: > Hi all, > > this series adds multiqueue support to the virtio-scsi driver, based > on Jason Wang's work on virtio-net. It uses a simple queue steering > algorithm that expects one queue per CPU. LUNs in the same target always > use the same queue (so that commands are not reordered); queue switching > occurs when the request being queued is the only one for the target. > Also based on Jason's patches, the virtqueue affinity is set so that > each CPU is associated to one virtqueue. > > I tested the patches with fio, using up to 32 virtio-scsi disks backed > by tmpfs on the host. These numbers are with 1 LUN per target. > > FIO configuration > - > [global] > rw=read > bsrange=4k-64k > ioengine=libaio > direct=1 > iodepth=4 > loops=20 > > overall bandwidth (MB/s) > > > # of targetssingle-queuemulti-queue, 4 VCPUsmulti-queue, 8 VCPUs > 1 540 626 599 > 2 795 965 925 > 4 997 13761500 > 8 1136 21302060 > 161440 22692474 > 241408 21792436 > 321515 19782319 > > (These numbers for single-queue are with 4 VCPUs, but the impact of adding > more VCPUs is very limited). > > avg bandwidth per LUN (MB/s) > > > # of targetssingle-queuemulti-queue, 4 VCPUsmulti-queue, 8 VCPUs > 1 540 626 599 > 2 397 482 462 > 4 249 344 375 > 8 142 266 257 > 16 90 141 154 > 24 5890 101 > 32 4761 72 Is there an explanation why 8x8 is slower then 4x8 in both cases? 8x1 and 8x2 being slower than 4x1 and 4x2 is more or less expected, but 8x8 loses against 4x8 while 8x4 wins against 4x4 and 8x16 against 4x16. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 0/5] Multiqueue virtio-scsi, and API for piecewise buffer submission
Paolo Bonzini wrote: Hi all, this series adds multiqueue support to the virtio-scsi driver, based on Jason Wang's work on virtio-net. It uses a simple queue steering algorithm that expects one queue per CPU. LUNs in the same target always use the same queue (so that commands are not reordered); queue switching occurs when the request being queued is the only one for the target. Also based on Jason's patches, the virtqueue affinity is set so that each CPU is associated to one virtqueue. I tested the patches with fio, using up to 32 virtio-scsi disks backed by tmpfs on the host. These numbers are with 1 LUN per target. FIO configuration - [global] rw=read bsrange=4k-64k ioengine=libaio direct=1 iodepth=4 loops=20 overall bandwidth (MB/s) # of targetssingle-queuemulti-queue, 4 VCPUsmulti-queue, 8 VCPUs 1 540 626 599 2 795 965 925 4 997 13761500 8 1136 21302060 161440 22692474 241408 21792436 321515 19782319 (These numbers for single-queue are with 4 VCPUs, but the impact of adding more VCPUs is very limited). avg bandwidth per LUN (MB/s) # of targetssingle-queuemulti-queue, 4 VCPUsmulti-queue, 8 VCPUs 1 540 626 599 2 397 482 462 4 249 344 375 8 142 266 257 16 90 141 154 24 5890 101 32 4761 72 Is there an explanation why 8x8 is slower then 4x8 in both cases? 8x1 and 8x2 being slower than 4x1 and 4x2 is more or less expected, but 8x8 loses against 4x8 while 8x4 wins against 4x4 and 8x16 against 4x16. Eike signature.asc Description: This is a digitally signed message part.
Re: [patch] [SCSI] mpt3sas: cut and paste bug storing trigger mpi
ioc->diag_trigger_mpi is an SL_WH_MPI_TRIGGERS_T struct. There is a cut and paste error here and SL_WH_EVENT_TRIGGERS_T is used instead of SL_WH_MPI_TRIGGERS_T. Since the SL_WH_EVENT_TRIGGERS_T is smaller than SL_WH_MPI_TRIGGERS_T, it means we only clear part of the buffer. Signed-off-by: Dan Carpenter --- Only needed in linux-next. This is a static analysis patch. Even though I'm pretty sure it's correct, I'm not able to test it. diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c b/drivers/scsi/mpt3sas/mpt3sas_ctl.c index 8af944d..3e35e64 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c +++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c @@ -3136,7 +3136,7 @@ _ctl_diag_trigger_mpi_store(struct device *cdev, spin_lock_irqsave(>diag_trigger_lock, flags); sz = min(sizeof(struct SL_WH_MPI_TRIGGERS_T), count); memset(>diag_trigger_mpi, 0, - sizeof(struct SL_WH_EVENT_TRIGGERS_T)); + sizeof(struct SL_WH_MPI_TRIGGERS_T)); memcpy(>diag_trigger_mpi, buf, sz); if (ioc->diag_trigger_mpi.ValidEntries > NUM_VALID_ENTRIES) ioc->diag_trigger_mpi.ValidEntries = NUM_VALID_ENTRIES; Then just use sizeof(ioc->diag_trigger_mpi), then it's irrelevant how that type is ever called. Eike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] [SCSI] mpt3sas: cut and paste bug storing trigger mpi
ioc-diag_trigger_mpi is an SL_WH_MPI_TRIGGERS_T struct. There is a cut and paste error here and SL_WH_EVENT_TRIGGERS_T is used instead of SL_WH_MPI_TRIGGERS_T. Since the SL_WH_EVENT_TRIGGERS_T is smaller than SL_WH_MPI_TRIGGERS_T, it means we only clear part of the buffer. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- Only needed in linux-next. This is a static analysis patch. Even though I'm pretty sure it's correct, I'm not able to test it. diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c b/drivers/scsi/mpt3sas/mpt3sas_ctl.c index 8af944d..3e35e64 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c +++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c @@ -3136,7 +3136,7 @@ _ctl_diag_trigger_mpi_store(struct device *cdev, spin_lock_irqsave(ioc-diag_trigger_lock, flags); sz = min(sizeof(struct SL_WH_MPI_TRIGGERS_T), count); memset(ioc-diag_trigger_mpi, 0, - sizeof(struct SL_WH_EVENT_TRIGGERS_T)); + sizeof(struct SL_WH_MPI_TRIGGERS_T)); memcpy(ioc-diag_trigger_mpi, buf, sz); if (ioc-diag_trigger_mpi.ValidEntries NUM_VALID_ENTRIES) ioc-diag_trigger_mpi.ValidEntries = NUM_VALID_ENTRIES; Then just use sizeof(ioc-diag_trigger_mpi), then it's irrelevant how that type is ever called. Eike -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi: prevent stack buffer overflow in host_reset
Am Donnerstag 15 November 2012, 15:51:46 schrieb Sasha Levin:
> store_host_reset() has tried to re-invent the wheel to compare sysfs
> strings. Unfortunately it did so poorly and never bothered to check the
> input from userspace before overwriting stack with it, so something simple
> as:
>
> echo "WoopsieWoopsie" >
> /sys/devices/pseudo_0/adapter0/host0/scsi_host/host0/host_reset
>
> would result in:
>
> [ 316.310101] Kernel panic - not syncing: stack-protector: Kernel stack is
> corrupted in: 81f5bac7 [ 316.310101]
> [ 316.320051] Pid: 6655, comm: sh Tainted: GW
> 3.7.0-rc5-next-20121114-sasha-00016-g5c9d68d-dirty #129 [ 316.320051] Call
> Trace:
> [ 316.340058] pps pps0: PPS event at 1352918752.620355751
> [ 316.340062] pps pps0: capture assert seq #303
> [ 316.320051] [] panic+0xcd/0x1f4
> [ 316.320051] [] ? store_host_reset+0xd7/0x100
> [ 316.320051] [] __stack_chk_fail+0x16/0x20
> [ 316.320051] [] store_host_reset+0xd7/0x100
> [ 316.320051] [] dev_attr_store+0x13/0x30
> [ 316.320051] [] sysfs_write_file+0x101/0x170
> [ 316.320051] [] vfs_write+0xb8/0x180
> [ 316.320051] [] sys_write+0x50/0xa0
> [ 316.320051] [] tracesys+0xe1/0xe6
>
> Fix this by uninventing whatever was going on there and just use
> sysfs_streq.
>
> Bug introduced by 29443691 ("[SCSI] scsi: Added support for adapter and
> firmware reset").
>
> Signed-off-by: Sasha Levin
That revision is in 3.2 and all following, so I think this needs to go into
stable, too.
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] scsi: prevent stack buffer overflow in host_reset
Am Donnerstag 15 November 2012, 15:51:46 schrieb Sasha Levin: store_host_reset() has tried to re-invent the wheel to compare sysfs strings. Unfortunately it did so poorly and never bothered to check the input from userspace before overwriting stack with it, so something simple as: echo WoopsieWoopsie /sys/devices/pseudo_0/adapter0/host0/scsi_host/host0/host_reset would result in: [ 316.310101] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: 81f5bac7 [ 316.310101] [ 316.320051] Pid: 6655, comm: sh Tainted: GW 3.7.0-rc5-next-20121114-sasha-00016-g5c9d68d-dirty #129 [ 316.320051] Call Trace: [ 316.340058] pps pps0: PPS event at 1352918752.620355751 [ 316.340062] pps pps0: capture assert seq #303 [ 316.320051] [83b3856b] panic+0xcd/0x1f4 [ 316.320051] [81f5bac7] ? store_host_reset+0xd7/0x100 [ 316.320051] [8110b996] __stack_chk_fail+0x16/0x20 [ 316.320051] [81f5bac7] store_host_reset+0xd7/0x100 [ 316.320051] [81e55bb3] dev_attr_store+0x13/0x30 [ 316.320051] [812f7db1] sysfs_write_file+0x101/0x170 [ 316.320051] [8127acc8] vfs_write+0xb8/0x180 [ 316.320051] [8127ae80] sys_write+0x50/0xa0 [ 316.320051] [83c03418] tracesys+0xe1/0xe6 Fix this by uninventing whatever was going on there and just use sysfs_streq. Bug introduced by 29443691 ([SCSI] scsi: Added support for adapter and firmware reset). Signed-off-by: Sasha Levin sasha.le...@oracle.com That revision is in 3.2 and all following, so I think this needs to go into stable, too. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] qla2xxx: silence two GCC warnings
Am Sonntag 30 September 2012, 13:07:54 schrieb Paul Bolle: > Compiling qla_gs.o (part of the qla2xxx module) triggers two GCC > warnings: > drivers/scsi/qla2xxx/qla_gs.c: In function ‘qla2x00_fdmi_rhba’: > drivers/scsi/qla2xxx/qla_gs.c:1339:7: warning: array subscript is above > array bounds [-Warray-bounds] drivers/scsi/qla2xxx/qla_gs.c: In function > ‘qla2x00_fdmi_register’: drivers/scsi/qla2xxx/qla_gs.c:1663:15: warning: > array subscript is above array bounds [-Warray-bounds] > > It seems that the sequence of a strcpy followed by a strlen confuses GCC > when it is keeping track of array bounds here. (It is not clear to me > which array triggers this warning and by how much GCC thinks the > subscript is above its bounds. Neither is it clear to me why comparable > code in these two functions doesn't trigger this warning.) > > The easiest way to silence these warnings is to hardcode the length of > these two strings in the code here. The length used here is the length > of the string, including its NUL terminator, rounded up to the next > multiple of four. This adds some magic values, which is asking for trouble once someone changes the manufacturer string or something. What about something like this: const char *qlogic = "QLogic Corporation"; strcpy(eiter->a.manufacturer, qlogic); alen += round_up(strlen(qlogic), 4); ... Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] qla2xxx: silence two GCC warnings
Am Sonntag 30 September 2012, 13:07:54 schrieb Paul Bolle: Compiling qla_gs.o (part of the qla2xxx module) triggers two GCC warnings: drivers/scsi/qla2xxx/qla_gs.c: In function ‘qla2x00_fdmi_rhba’: drivers/scsi/qla2xxx/qla_gs.c:1339:7: warning: array subscript is above array bounds [-Warray-bounds] drivers/scsi/qla2xxx/qla_gs.c: In function ‘qla2x00_fdmi_register’: drivers/scsi/qla2xxx/qla_gs.c:1663:15: warning: array subscript is above array bounds [-Warray-bounds] It seems that the sequence of a strcpy followed by a strlen confuses GCC when it is keeping track of array bounds here. (It is not clear to me which array triggers this warning and by how much GCC thinks the subscript is above its bounds. Neither is it clear to me why comparable code in these two functions doesn't trigger this warning.) The easiest way to silence these warnings is to hardcode the length of these two strings in the code here. The length used here is the length of the string, including its NUL terminator, rounded up to the next multiple of four. This adds some magic values, which is asking for trouble once someone changes the manufacturer string or something. What about something like this: const char *qlogic = QLogic Corporation; strcpy(eiter-a.manufacturer, qlogic); alen += round_up(strlen(qlogic), 4); ... Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
Am 25.07.2012 10:29, schrieb Wang Sen: When using the commands below to write some data to a virtio-scsi LUN of the QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash. # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) # sudo mount /dev/sdb /mnt # dd if=/dev/zero of=/mnt/file bs=1M count=1024 In current implementation, sg_set_buf is called to add buffers to sg list which is put into the virtqueue eventually. The next sentence is somehow broken: But there are some HighMem pages in table->sgl can not get virtual address by sg_virt. Maybe something like "But _if_ there are ... _you_ can not get ..."? Eike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
Am 25.07.2012 10:29, schrieb Wang Sen: When using the commands below to write some data to a virtio-scsi LUN of the QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash. # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) # sudo mount /dev/sdb /mnt # dd if=/dev/zero of=/mnt/file bs=1M count=1024 In current implementation, sg_set_buf is called to add buffers to sg list which is put into the virtqueue eventually. The next sentence is somehow broken: But there are some HighMem pages in table-sgl can not get virtual address by sg_virt. Maybe something like But _if_ there are ... _you_ can not get ...? Eike -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/4] [SCSI] drivers/scsi/ufs: Add PCI glue driver
Vinayak Holikatti wrote:
> +static int __devinit
> +ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> +{
> + struct ufs_hba *hba;
> + void __iomem *mmio_base;
> + int err;
> +
> + err = pci_enable_device(pdev);
> + if (err) {
> + dev_err(>dev, "pci_enable_device failed\n");
> + goto out_error;
> + }
My question as basically every time at this point: why not use devres, i.e.
pcim_enable_device()? This would make the cleanup and error handling much
easier. See Documentation/driver-model/devres.txt.
> +
> + pci_set_master(pdev);
> +
> +
Duplicate newline.
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH V2 2/4] [SCSI] drivers/scsi/ufs: Add PCI glue driver
Vinayak Holikatti wrote:
+static int __devinit
+ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+ struct ufs_hba *hba;
+ void __iomem *mmio_base;
+ int err;
+
+ err = pci_enable_device(pdev);
+ if (err) {
+ dev_err(pdev-dev, pci_enable_device failed\n);
+ goto out_error;
+ }
My question as basically every time at this point: why not use devres, i.e.
pcim_enable_device()? This would make the cleanup and error handling much
easier. See Documentation/driver-model/devres.txt.
+
+ pci_set_master(pdev);
+
+
Duplicate newline.
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [2.6 patch] scsi/qla4xxx/ql4_isr.c: remove dead code
> The correct patch needs to be
>
> Signed-off-by: David C Somayajulu <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/drivers/scsi/qla4xxx/ql4_isr.c
> b/drivers/scsi/qla4xxx/ql4_isr.c
> index 0f029d0..fc84db4 100644
> --- a/drivers/scsi/qla4xxx/ql4_isr.c
> +++ b/drivers/scsi/qla4xxx/ql4_isr.c
> @@ -100,8 +100,7 @@ static void qla4xxx_status_entry(struct
>
> if (sts_entry->iscsiFlags _FLAG_RESIDUAL_UNDER) {
> scsi_set_resid(cmd, residual);
> - if (!scsi_status && ((scsi_bufflen(cmd) -
> residual) <
> - cmd->underflow)) {
> + if ((scsi_bufflen(cmd) - residual) <
> cmd->underflow) {
The patch is line-wrapped and can' be applied.
Greetings,
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [2.6 patch] scsi/qla4xxx/ql4_isr.c: remove dead code
The correct patch needs to be
Signed-off-by: David C Somayajulu [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/qla4xxx/ql4_isr.c
b/drivers/scsi/qla4xxx/ql4_isr.c
index 0f029d0..fc84db4 100644
--- a/drivers/scsi/qla4xxx/ql4_isr.c
+++ b/drivers/scsi/qla4xxx/ql4_isr.c
@@ -100,8 +100,7 @@ static void qla4xxx_status_entry(struct
if (sts_entry-iscsiFlags ISCSI_FLAG_RESIDUAL_UNDER) {
scsi_set_resid(cmd, residual);
- if (!scsi_status ((scsi_bufflen(cmd) -
residual)
- cmd-underflow)) {
+ if ((scsi_bufflen(cmd) - residual)
cmd-underflow) {
The patch is line-wrapped and can' be applied.
Greetings,
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [JANITOR PROPOSAL] Switch ioctl functions to ->unlocked_ioctl
Andi Kleen wrote: > > Can you explain the rationale behind that running on the BKL? What type > > of > > It used to always run with the BKL because everything used to > and originally nobody wanted to review all ioctl handlers in tree to see if > they can run with more fine grained locking. A lot probably can though. > > > things needs to be protected so that this huge hammer is needed? What > > would be an earlier point to release the BKL? > > That depends on the driver. A lot don't need BKL at all and > in others it can be easily eliminated. But it needs case-by-case > review of the locking situation. > > The goal of the proposal here is just to make it more visible. So if I write my own driver and have never heard of ioctls running on BKL before I can rather be sure that I just can change the interface of the ioctl function, put it in unlocked_ioctl and are fine? Cool. Eike signature.asc Description: This is a digitally signed message part.
Re: [JANITOR PROPOSAL] Switch ioctl functions to ->unlocked_ioctl
Andi Kleen wrote: > Here's a proposal for some useful code transformations the kernel janitors > could do as opposed to running checkpatch.pl. > > Most ioctl handlers still running implicitely under the big kernel > lock (BKL). But long term Linux is trying to get away from that. There is a > new ->unlocked_ioctl entry point that allows ioctls without BKL, but the > code needs to be explicitely converted to use this. > > The first step of getting rid of the BKL is typically to make it visible > in the source. Once it is visible people will have incentive to eliminate > it. That is how the BKL conversion project for Linux long ago started too. > On 2.0 all system calls were still implicitely BKL and in 2.1 the > lock/unlock_kernel()s were moved into the various syscall functions and > then step by step eliminated. Can you explain the rationale behind that running on the BKL? What type of things needs to be protected so that this huge hammer is needed? What would be an earlier point to release the BKL? Greetings, Eike signature.asc Description: This is a digitally signed message part.
Re: [JANITOR PROPOSAL] Switch ioctl functions to -unlocked_ioctl
Andi Kleen wrote: Here's a proposal for some useful code transformations the kernel janitors could do as opposed to running checkpatch.pl. Most ioctl handlers still running implicitely under the big kernel lock (BKL). But long term Linux is trying to get away from that. There is a new -unlocked_ioctl entry point that allows ioctls without BKL, but the code needs to be explicitely converted to use this. The first step of getting rid of the BKL is typically to make it visible in the source. Once it is visible people will have incentive to eliminate it. That is how the BKL conversion project for Linux long ago started too. On 2.0 all system calls were still implicitely BKL and in 2.1 the lock/unlock_kernel()s were moved into the various syscall functions and then step by step eliminated. Can you explain the rationale behind that running on the BKL? What type of things needs to be protected so that this huge hammer is needed? What would be an earlier point to release the BKL? Greetings, Eike signature.asc Description: This is a digitally signed message part.
Re: [JANITOR PROPOSAL] Switch ioctl functions to -unlocked_ioctl
Andi Kleen wrote: Can you explain the rationale behind that running on the BKL? What type of It used to always run with the BKL because everything used to and originally nobody wanted to review all ioctl handlers in tree to see if they can run with more fine grained locking. A lot probably can though. things needs to be protected so that this huge hammer is needed? What would be an earlier point to release the BKL? That depends on the driver. A lot don't need BKL at all and in others it can be easily eliminated. But it needs case-by-case review of the locking situation. The goal of the proposal here is just to make it more visible. So if I write my own driver and have never heard of ioctls running on BKL before I can rather be sure that I just can change the interface of the ioctl function, put it in unlocked_ioctl and are fine? Cool. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Fix segfault when printing battery status
Alexey Starikovskiy wrote: > Rolf Eike Beer wrote: > > cat > > /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:19/PNP0C0A:00/power_ > >supply/BAT1/status > > > > This leads to a stacktrace as acpi_battery_get_property() returns 0 for a > > case where it does not set val->intval. These value is used as an array > > index in > > drivers/power/power_supply_sysfs.c::power_supply_show_property(). I had a > > situation where the value was 4096 which caused a problem as the array > > only has 5 entries. > > > > Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> > > Rolf, thanks for remainding. Huh? This one is unrelated to the problem I reported two weeks ago... Eike signature.asc Description: This is a digitally signed message part.
[PATCH] Fix segfault when printing battery status
cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:19/PNP0C0A:00/power_supply/BAT1/status This leads to a stacktrace as acpi_battery_get_property() returns 0 for a case where it does not set val->intval. These value is used as an array index in drivers/power/power_supply_sysfs.c::power_supply_show_property(). I had a situation where the value was 4096 which caused a problem as the array only has 5 entries. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index 192c244..2e8e790 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -153,6 +153,8 @@ static int acpi_battery_get_property(struct power_supply *psy, val->intval = POWER_SUPPLY_STATUS_CHARGING; else if (battery->state == 0) val->intval = POWER_SUPPLY_STATUS_FULL; + else + val->intval = POWER_SUPPLY_STATUS_UNKNOWN; break; case POWER_SUPPLY_PROP_PRESENT: val->intval = acpi_battery_present(battery); signature.asc Description: This is a digitally signed message part.
[PATCH] Fix segfault when printing battery status
cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:19/PNP0C0A:00/power_supply/BAT1/status This leads to a stacktrace as acpi_battery_get_property() returns 0 for a case where it does not set val-intval. These value is used as an array index in drivers/power/power_supply_sysfs.c::power_supply_show_property(). I had a situation where the value was 4096 which caused a problem as the array only has 5 entries. Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED] diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index 192c244..2e8e790 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -153,6 +153,8 @@ static int acpi_battery_get_property(struct power_supply *psy, val-intval = POWER_SUPPLY_STATUS_CHARGING; else if (battery-state == 0) val-intval = POWER_SUPPLY_STATUS_FULL; + else + val-intval = POWER_SUPPLY_STATUS_UNKNOWN; break; case POWER_SUPPLY_PROP_PRESENT: val-intval = acpi_battery_present(battery); signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Fix segfault when printing battery status
Alexey Starikovskiy wrote: Rolf Eike Beer wrote: cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:19/PNP0C0A:00/power_ supply/BAT1/status This leads to a stacktrace as acpi_battery_get_property() returns 0 for a case where it does not set val-intval. These value is used as an array index in drivers/power/power_supply_sysfs.c::power_supply_show_property(). I had a situation where the value was 4096 which caused a problem as the array only has 5 entries. Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED] Rolf, thanks for remainding. Huh? This one is unrelated to the problem I reported two weeks ago... Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2/5] Construct one fakephp slot per pci slot
Am Mittwoch, 14. November 2007 schrieb Alex Chiang: > * Matthew Wilcox <[EMAIL PROTECTED]>: > > On Wed, Nov 14, 2007 at 12:37:29PM -0700, Alex Chiang wrote: > > > Register one slot per slot, rather than one slot per function. > > > Change the name of the slot to fake%d instead of the pci address. > > > > > > +#define SLOT_NAME_SIZE KOBJ_NAME_LEN > > > > Defined, then never used ... how about s/KOBJ_NAME_LEN/8/, then use > > SLOT_NAME_SIZE throughout? > > Whoops, good catch. I had a braino there. Just drop it and use sizeof(dslot->name) in snprintf(). Just be careful not to use slot->name there as it would always be sizeof(void*)! Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2/5] Construct one fakephp slot per pci slot
Am Mittwoch, 14. November 2007 schrieb Alex Chiang: * Matthew Wilcox [EMAIL PROTECTED]: On Wed, Nov 14, 2007 at 12:37:29PM -0700, Alex Chiang wrote: Register one slot per slot, rather than one slot per function. Change the name of the slot to fake%d instead of the pci address. +#define SLOT_NAME_SIZE KOBJ_NAME_LEN Defined, then never used ... how about s/KOBJ_NAME_LEN/8/, then use SLOT_NAME_SIZE throughout? Whoops, good catch. I had a braino there. Just drop it and use sizeof(dslot-name) in snprintf(). Just be careful not to use slot-name there as it would always be sizeof(void*)! Eike signature.asc Description: This is a digitally signed message part.
Re: [Pcihpd-discuss] [PATCH 2/5] Construct one fakephp slot per pci slot
Am Mittwoch, 14. November 2007 schrieb Alex Chiang:
> Hi Eike,
>
> * Rolf Eike Beer <[EMAIL PROTECTED]>:
> > Alex Chiang wrote:
> > > --- a/drivers/pci/hotplug/fakephp.c
> > > +++ b/drivers/pci/hotplug/fakephp.c
> > > @@ -93,6 +93,7 @@ static int add_slot(struct pci_dev *dev)
> > > struct dummy_slot *dslot;
> > > struct hotplug_slot *slot;
> > > int retval = -ENOMEM;
> > > + static int count = 1;
> > >
> > > slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL);
> > > if (!slot)
> > > @@ -106,7 +107,8 @@ static int add_slot(struct pci_dev *dev)
> > > slot->info->max_bus_speed = PCI_SPEED_UNKNOWN;
> > > slot->info->cur_bus_speed = PCI_SPEED_UNKNOWN;
> > >
> > > - slot->name = >dev.bus_id[0];
> > > + slot->name = kmalloc(8, GFP_KERNEL);
> > > + sprintf(slot->name, "fake%d", count++);
> > > dbg("slot->name = %s\n", slot->name);
> > >
> > > dslot = kmalloc(sizeof(struct dummy_slot), GFP_KERNEL);
> >
> > This is ugly. Please do it the way we already do e.g. for
> > acpiphp: add a char[8] to "struct dummy_slot" and just
> > reference that here.
>
> I took at look at the code in acpiphp you're talking about, and
> I'm not sure why you think the above is "ugly". We're talking
> about a runtime vs compile time storage for the name, and doing a
> kmalloc/sprintf is a pretty standard idiom.
>
> BTW, I did incorporate both Linas' and Willy's comments, by
> changing the kmalloc size to an explicit 32, and using snprintf
> instead.
>
> In any case, for your particular comment, I think I'm going to
> leave it alone for now, and let Greg weigh in with the final
> recommendation.
Because we have another allocation of very small size for every slot here.
struct dummy_slot has a size of 4 pointers, that's 16 byte for 32 bit
architectures. Putting 8 byte of additional storage here would save a
complete allocation on 32 bit platforms. For 64 bit platforms the memory
usage is the same but we do less allocations (i.e. less points to fail) and
less memory fragmentation.
Btw: your code lacks a check if kmalloc() returns NULL.
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [Pcihpd-discuss] [PATCH 2/5] Construct one fakephp slot per pci slot
Alex Chiang wrote:
> Register one slot per slot, rather than one slot per function.
> Change the name of the slot to fake%d instead of the pci address.
>
> Signed-off-by: Alex Chiang <[EMAIL PROTECTED]>
> Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
> ---
> drivers/pci/hotplug/fakephp.c | 75
> +++-- 1 files changed, 27
> insertions(+), 48 deletions(-)
>
> diff --git a/drivers/pci/hotplug/fakephp.c b/drivers/pci/hotplug/fakephp.c
> index 027f686..828335e 100644
> --- a/drivers/pci/hotplug/fakephp.c
> +++ b/drivers/pci/hotplug/fakephp.c
> @@ -93,6 +93,7 @@ static int add_slot(struct pci_dev *dev)
> struct dummy_slot *dslot;
> struct hotplug_slot *slot;
> int retval = -ENOMEM;
> + static int count = 1;
>
> slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL);
> if (!slot)
> @@ -106,7 +107,8 @@ static int add_slot(struct pci_dev *dev)
> slot->info->max_bus_speed = PCI_SPEED_UNKNOWN;
> slot->info->cur_bus_speed = PCI_SPEED_UNKNOWN;
>
> - slot->name = >dev.bus_id[0];
> + slot->name = kmalloc(8, GFP_KERNEL);
> + sprintf(slot->name, "fake%d", count++);
> dbg("slot->name = %s\n", slot->name);
>
> dslot = kmalloc(sizeof(struct dummy_slot), GFP_KERNEL);
This is ugly. Please do it the way we already do e.g. for acpiphp: add a
char[8] to "struct dummy_slot" and just reference that here. Or better do
what this name suggests: kill fakephp completely and use dummyphp[1] instead.
Eike
1) http://opensource.sf-tec.de/kernel/
signature.asc
Description: This is a digitally signed message part.
Re: [Pcihpd-discuss] [PATCH 2/5] Construct one fakephp slot per pci slot
Alex Chiang wrote: Register one slot per slot, rather than one slot per function. Change the name of the slot to fake%d instead of the pci address. Signed-off-by: Alex Chiang [EMAIL PROTECTED] Signed-off-by: Matthew Wilcox [EMAIL PROTECTED] --- drivers/pci/hotplug/fakephp.c | 75 +++-- 1 files changed, 27 insertions(+), 48 deletions(-) diff --git a/drivers/pci/hotplug/fakephp.c b/drivers/pci/hotplug/fakephp.c index 027f686..828335e 100644 --- a/drivers/pci/hotplug/fakephp.c +++ b/drivers/pci/hotplug/fakephp.c @@ -93,6 +93,7 @@ static int add_slot(struct pci_dev *dev) struct dummy_slot *dslot; struct hotplug_slot *slot; int retval = -ENOMEM; + static int count = 1; slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL); if (!slot) @@ -106,7 +107,8 @@ static int add_slot(struct pci_dev *dev) slot-info-max_bus_speed = PCI_SPEED_UNKNOWN; slot-info-cur_bus_speed = PCI_SPEED_UNKNOWN; - slot-name = dev-dev.bus_id[0]; + slot-name = kmalloc(8, GFP_KERNEL); + sprintf(slot-name, fake%d, count++); dbg(slot-name = %s\n, slot-name); dslot = kmalloc(sizeof(struct dummy_slot), GFP_KERNEL); This is ugly. Please do it the way we already do e.g. for acpiphp: add a char[8] to struct dummy_slot and just reference that here. Or better do what this name suggests: kill fakephp completely and use dummyphp[1] instead. Eike 1) http://opensource.sf-tec.de/kernel/ signature.asc Description: This is a digitally signed message part.
Re: [Pcihpd-discuss] [PATCH 2/5] Construct one fakephp slot per pci slot
Am Mittwoch, 14. November 2007 schrieb Alex Chiang: Hi Eike, * Rolf Eike Beer [EMAIL PROTECTED]: Alex Chiang wrote: --- a/drivers/pci/hotplug/fakephp.c +++ b/drivers/pci/hotplug/fakephp.c @@ -93,6 +93,7 @@ static int add_slot(struct pci_dev *dev) struct dummy_slot *dslot; struct hotplug_slot *slot; int retval = -ENOMEM; + static int count = 1; slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL); if (!slot) @@ -106,7 +107,8 @@ static int add_slot(struct pci_dev *dev) slot-info-max_bus_speed = PCI_SPEED_UNKNOWN; slot-info-cur_bus_speed = PCI_SPEED_UNKNOWN; - slot-name = dev-dev.bus_id[0]; + slot-name = kmalloc(8, GFP_KERNEL); + sprintf(slot-name, fake%d, count++); dbg(slot-name = %s\n, slot-name); dslot = kmalloc(sizeof(struct dummy_slot), GFP_KERNEL); This is ugly. Please do it the way we already do e.g. for acpiphp: add a char[8] to struct dummy_slot and just reference that here. I took at look at the code in acpiphp you're talking about, and I'm not sure why you think the above is ugly. We're talking about a runtime vs compile time storage for the name, and doing a kmalloc/sprintf is a pretty standard idiom. BTW, I did incorporate both Linas' and Willy's comments, by changing the kmalloc size to an explicit 32, and using snprintf instead. In any case, for your particular comment, I think I'm going to leave it alone for now, and let Greg weigh in with the final recommendation. Because we have another allocation of very small size for every slot here. struct dummy_slot has a size of 4 pointers, that's 16 byte for 32 bit architectures. Putting 8 byte of additional storage here would save a complete allocation on 32 bit platforms. For 64 bit platforms the memory usage is the same but we do less allocations (i.e. less points to fail) and less memory fragmentation. Btw: your code lacks a check if kmalloc() returns NULL. Eike signature.asc Description: This is a digitally signed message part.
Re: [2.6.24-rc1][BUG] Oops on battery removal
Alexey Starikovskiy wrote: > Rolf Eike Beer wrote: > > Alexey Starikovskiy wrote: > >> Rolf Eike Beer wrote: > >>> Alexey Starikovskiy wrote: > >>>> Rolf Eike Beer wrote: > >>>>> Rolf Eike Beer wrote: > >>>>>> Hi, > >>>>>> > >>>>>> this happened while I removed my battery on bootup. Complete dmesg > >>>>>> is attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was > >>>>>> d919fd433b5823d1cf9d0688eb2eec183de9b74c). > >>>>> > >>>>> Ok, I found out that it has nothing to do with the actual removal as > >>>>> it seems. When I start the laptop with battery already detached I get > >>>>> the same error. > >>>> > >>>> Please check if this patch helps. > >>> > >>> It made things worse: > >> > >> How about this patch? > > > > Ehm, that is the same patch as before! > > Yes, sorry... Two patches in parallel -- not good. Tested-by: Rolf Eike Beer <[EMAIL PROTECTED]> It makes the crash go away. But there is something weird going on. Before I logged into X I did an "cat /proc/acpi/battery/BAT1/*" and it showed the battery as present with some (random?) values. Now I'm in X and everything looks fine there (as in "not present"). Eike signature.asc Description: This is a digitally signed message part.
Re: [2.6.24-rc1][BUG] Oops on battery removal
Alexey Starikovskiy wrote: > Rolf Eike Beer wrote: > > Alexey Starikovskiy wrote: > >> Rolf Eike Beer wrote: > >>> Rolf Eike Beer wrote: > >>>> Hi, > >>>> > >>>> this happened while I removed my battery on bootup. Complete dmesg is > >>>> attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was > >>>> d919fd433b5823d1cf9d0688eb2eec183de9b74c). > >>> > >>> Ok, I found out that it has nothing to do with the actual removal as it > >>> seems. When I start the laptop with battery already detached I get the > >>> same error. > >> > >> Please check if this patch helps. > > > > It made things worse: > > How about this patch? Ehm, that is the same patch as before! Btw: it has an empty From: line Eike signature.asc Description: This is a digitally signed message part.
Re: [2.6.24-rc1][BUG] Oops on battery removal
Alexey Starikovskiy wrote: > Rolf Eike Beer wrote: > > Rolf Eike Beer wrote: > >> Hi, > >> > >> this happened while I removed my battery on bootup. Complete dmesg is > >> attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was > >> d919fd433b5823d1cf9d0688eb2eec183de9b74c). > > > > Ok, I found out that it has nothing to do with the actual removal as it > > seems. When I start the laptop with battery already detached I get the > > same error. > Please check if this patch helps. It made things worse: Nov 2 12:37:20 donald kernel: ACPI: EC: non-query interrupt received, switching to interrupt mode Nov 2 12:37:20 donald acpid: received event "battery BAT1 0080 " Nov 2 12:37:20 donald acpid: notifying client 2856[101:102] Nov 2 12:37:20 donald acpid: notifying client 2911[0:0] Nov 2 12:37:20 donald acpid: notifying client 3048[0:0] Nov 2 12:37:20 donald acpid: completed event "battery BAT1 0080 " Nov 2 12:37:20 donald kernel: WARNING: at /home/eike/repos/linux-2.6/lib/kref.c:33 kref_get() Nov 2 12:37:20 donald kernel: [] show_trace_log_lvl+0x1a/0x2f Nov 2 12:37:20 donald kernel: [] show_trace+0x12/0x14 Nov 2 12:37:20 donald kernel: [] dump_stack+0x16/0x18 Nov 2 12:37:20 donald kernel: [] kref_get+0x37/0x43 Nov 2 12:37:20 donald kernel: [] kobject_get+0x12/0x17 Nov 2 12:37:20 donald kernel: [] get_device+0x13/0x1d Nov 2 12:37:20 donald kernel: [] device_remove_file+0xe/0x2a Nov 2 12:37:20 donald kernel: [] sysfs_remove_battery+0x17/0x22 [battery] Nov 2 12:37:20 donald kernel: [] acpi_battery_update+0x3f/0x255 [battery] Nov 2 12:37:20 donald kernel: [] acpi_battery_read+0x11/0x20 [battery] Nov 2 12:37:20 donald powersaved[3048]: WARNING (filter_function:201) Hal service stopped. Battery information no longer available Nov 2 12:37:20 donald kernel: [] acpi_battery_read_state+0xf/0x11 [battery] Nov 2 12:37:20 donald kernel: [] seq_read+0xea/0x264 Nov 2 12:37:20 donald kernel: [] proc_reg_read+0x63/0x76 Nov 2 12:37:20 donald kernel: [] vfs_read+0xa6/0x12f Nov 2 12:37:20 donald kernel: [] sys_read+0x3d/0x61 Nov 2 12:37:20 donald kernel: [] sysenter_past_esp+0x5f/0x85 Nov 2 12:37:20 donald kernel: === Nov 2 12:37:20 donald kernel: WARNING: at /home/eike/repos/linux-2.6/lib/kref.c:33 kref_get() Nov 2 12:37:20 donald kernel: [] show_trace_log_lvl+0x1a/0x2f Nov 2 12:37:20 donald kernel: [] show_trace+0x12/0x14 Nov 2 12:37:20 donald kernel: [] dump_stack+0x16/0x18 Nov 2 12:37:20 donald kernel: [] kref_get+0x37/0x43 Nov 2 12:37:20 donald kernel: [] kobject_get+0x12/0x17 Nov 2 12:37:20 donald kernel: [] get_device+0x13/0x1d Nov 2 12:37:20 donald kernel: [] device_remove_file+0xe/0x2a Nov 2 12:37:20 donald kernel: [] power_supply_remove_attrs+0x16/0x37 [power_supply] Nov 2 12:37:20 donald kernel: [] power_supply_unregister+0x12/0x1d [power_supply] Nov 2 12:37:20 donald kernel: [] sysfs_remove_battery+0x1f/0x22 [battery] Nov 2 12:37:20 donald kernel: [] acpi_battery_update+0x3f/0x255 [battery] Nov 2 12:37:20 donald kernel: [] acpi_battery_read+0x11/0x20 [battery] Nov 2 12:37:20 donald kernel: [] acpi_battery_read_state+0xf/0x11 [battery] Nov 2 12:37:20 donald kernel: [] seq_read+0xea/0x264 Nov 2 12:37:20 donald kernel: [] proc_reg_read+0x63/0x76 Nov 2 12:37:20 donald kernel: [] vfs_read+0xa6/0x12f Nov 2 12:37:20 donald kernel: [] sys_read+0x3d/0x61 Nov 2 12:37:20 donald kernel: [] sysenter_past_esp+0x5f/0x85 Nov 2 12:37:20 donald kernel: === tons more of stuff like this, system us unusable with this kernel now. In the meantime I upgraded to current git, last commit is now b4d367fb20ed19be4a53fa88b407248aeb8bd461 Eike signature.asc Description: This is a digitally signed message part.
Re: [2.6.24-rc1][BUG] Oops on battery removal
Rolf Eike Beer wrote: > Hi, > > this happened while I removed my battery on bootup. Complete dmesg is > attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was > d919fd433b5823d1cf9d0688eb2eec183de9b74c). Ok, I found out that it has nothing to do with the actual removal as it seems. When I start the laptop with battery already detached I get the same error. Eike signature.asc Description: This is a digitally signed message part.
[2.6.24-rc1][BUG] Oops on battery removal
Hi, this happened while I removed my battery on bootup. Complete dmesg is attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was d919fd433b5823d1cf9d0688eb2eec183de9b74c). Greetings, Eike BUG: unable to handle kernel NULL pointer dereference at virtual address 001c printing eip: c02a82cb *pde = Oops: [#1] SMP Modules linked in: iptable_filter ip_tables ip6table_filter ip6_tables x_tables ipv6 af_packet cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_powersave acpi_cpufreq speedstep_lib freq_table snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device twofish twofish_common cbc blkcipher dm_crypt nls_utf8 ntfs ext3 jbd loop mmc_block pcmcia container battery iwl3945 firmware_class yenta_socket button ohci1394 backlight output ac power_supply rsrc_nonstatic pcmcia_core mmc_core ieee1394 intel_agp joydev agpgart snd_hda_intel sr_mod cdrom r8169 snd_pcm snd_timer mac80211 snd soundcore snd_page_alloc i2c_i801 i2c_core cfg80211 serio_raw sg usbhid ehci_hcd uhci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan ata_piix libata scsi_mod thermal processor Pid: 47, comm: kacpi_notify Not tainted (2.6.24-rc1-git #68) EIP: 0060:[] EFLAGS: 00010286 CPU: 0 EIP is at klist_del+0xc/0x39 EAX: EBX: ECX: EDX: ESI: c2e2bc00 EDI: c2e2bc20 EBP: c1c88d7c ESP: c1c88d70 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Process kacpi_notify (pid: 47, ti=c1c88000 task=c1cb5350 task.ti=c1c88000) Stack: c2e2bc00 c2e2bc00 c1ce960c c1c88d90 c0231ab6 c2e2bc00 c2e2ba00 c1c88e1c c1c88d9c c0231ced c2e2ba1c c1c88da8 f8bee01a c2e2ba00 c1c88db4 f8c3904b c2e2ba00 c1c88de4 f8c391a2 c01d47bc c01d47bc 0001 80d0 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9b/0xa3 [] show_registers+0xa7/0x179 [] die+0x114/0x1f5 [] do_page_fault+0x4b0/0x589 [] error_code+0x72/0x78 [] device_del+0x1a/0x246 [] device_unregister+0xb/0x15 [] power_supply_unregister+0x1a/0x1d [power_supply] [] sysfs_remove_battery+0x1f/0x22 [battery] [] acpi_battery_update+0x3f/0x255 [battery] [] acpi_battery_get_property+0x2b/0x149 [battery] [] power_supply_show_property+0x32/0xf0 [power_supply] [] power_supply_uevent+0xfd/0x187 [power_supply] [] dev_uevent+0xca/0xe8 [] kobject_uevent_env+0x15a/0x376 [] kobject_uevent+0xa/0xc [] device_del+0x21d/0x246 [] device_unregister+0xb/0x15 [] power_supply_unregister+0x1a/0x1d [power_supply] [] sysfs_remove_battery+0x1f/0x22 [battery] [] acpi_battery_update+0x3f/0x255 [battery] [] acpi_battery_notify+0x1e/0x73 [battery] [] acpi_ev_notify_dispatch+0x4f/0x5a [] acpi_os_execute_notify+0x24/0x2f [] run_workqueue+0x7d/0x110 [] worker_thread+0xbe/0xcd [] kthread+0x3b/0x64 [] kernel_thread_helper+0x7/0x10 === Code: 08 e8 63 20 00 00 83 7d f0 00 74 09 85 ff 74 05 89 f8 ff 55 f0 8b 45 ec 5a 59 5b 5e 5f 5d c3 55 89 e5 57 89 c7 56 53 8b 18 89 d8 <8b> 73 1c e8 7b 20 00 00 89 f8 e8 58 ff ff ff 85 c0 b8 00 00 00 EIP: [] klist_del+0xc/0x39 SS:ESP 0068:c1c88d70 CPU0 attaching NULL sched-domain. CPU1 attaching NULL sched-domain. CPU0 attaching sched-domain: domain 0: span 3 groups: 1 2 CPU1 attaching sched-domain: domain 0: span 3 groups: 2 1 BUG: unable to handle kernel NULL pointer dereference at virtual address 001c printing eip: c02a82cb *pde = Oops: [#2] SMP Modules linked in: iptable_filter ip_tables ip6table_filter ip6_tables x_tables ipv6 af_packet cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_powersave acpi_cpufreq speedstep_lib freq_table snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device twofish twofish_common cbc blkcipher dm_crypt nls_utf8 ntfs ext3 jbd loop mmc_block pcmcia container battery iwl3945 firmware_class yenta_socket button ohci1394 backlight output ac power_supply rsrc_nonstatic pcmcia_core mmc_core ieee1394 intel_agp joydev agpgart snd_hda_intel sr_mod cdrom r8169 snd_pcm snd_timer mac80211 snd soundcore snd_page_alloc i2c_i801 i2c_core cfg80211 serio_raw sg usbhid ehci_hcd uhci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan ata_piix libata scsi_mod thermal processor Pid: 2773, comm: hald Tainted: G D (2.6.24-rc1-git #68) EIP: 0060:[] EFLAGS: 00010286 CPU: 1 EIP is at klist_del+0xc/0x39 EAX: EBX: ECX: EDX: ESI: c2e2bc00 EDI: c2e2bc20 EBP: c33b9e8c ESP: c33b9e80 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process hald (pid: 2773, ti=c33b9000 task=c3304d30 task.ti=c33b9000) Stack: c2e2bc00 c2e2bc00 c1ce960c c33b9ea0 c0231ab6 c2e2bc00 c2e2ba00 0001 c33b9eac c0231ced c2e2ba1c c33b9eb8 f8bee01a c2e2ba00 c33b9ec4 f8c3904b c39b3ec0 c33b9ef4 f8c391a2 c0163a98 c27f1cbc 0246 c3bf9cf8 c33b9efc Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9b/0xa3 [] show_registers+0xa7/0x179 [] die+0x114/0x1f5 [] do_page_fault+0x4b0/0x589 [] error_code+0x72/0x78 [] device_del+0x1a/0x246 [] device_unregister+0xb/0x15 []
Re: [2.6.24-rc1][BUG] Oops on battery removal
Alexey Starikovskiy wrote: Rolf Eike Beer wrote: Rolf Eike Beer wrote: Hi, this happened while I removed my battery on bootup. Complete dmesg is attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was d919fd433b5823d1cf9d0688eb2eec183de9b74c). Ok, I found out that it has nothing to do with the actual removal as it seems. When I start the laptop with battery already detached I get the same error. Please check if this patch helps. It made things worse: Nov 2 12:37:20 donald kernel: ACPI: EC: non-query interrupt received, switching to interrupt mode Nov 2 12:37:20 donald acpid: received event battery BAT1 0080 Nov 2 12:37:20 donald acpid: notifying client 2856[101:102] Nov 2 12:37:20 donald acpid: notifying client 2911[0:0] Nov 2 12:37:20 donald acpid: notifying client 3048[0:0] Nov 2 12:37:20 donald acpid: completed event battery BAT1 0080 Nov 2 12:37:20 donald kernel: WARNING: at /home/eike/repos/linux-2.6/lib/kref.c:33 kref_get() Nov 2 12:37:20 donald kernel: [c0104edd] show_trace_log_lvl+0x1a/0x2f Nov 2 12:37:20 donald kernel: [c010576e] show_trace+0x12/0x14 Nov 2 12:37:20 donald kernel: [c010585b] dump_stack+0x16/0x18 Nov 2 12:37:20 donald kernel: [c01d1d3c] kref_get+0x37/0x43 Nov 2 12:37:20 donald kernel: [c01d10af] kobject_get+0x12/0x17 Nov 2 12:37:20 donald kernel: [c0231509] get_device+0x13/0x1d Nov 2 12:37:20 donald kernel: [c02319e8] device_remove_file+0xe/0x2a Nov 2 12:37:20 donald kernel: [f8be7043] sysfs_remove_battery+0x17/0x22 [battery] Nov 2 12:37:20 donald kernel: [f8be71a2] acpi_battery_update+0x3f/0x255 [battery] Nov 2 12:37:20 donald kernel: [f8be73ed] acpi_battery_read+0x11/0x20 [battery] Nov 2 12:37:20 donald powersaved[3048]: WARNING (filter_function:201) Hal service stopped. Battery information no longer available Nov 2 12:37:20 donald kernel: [f8be741c] acpi_battery_read_state+0xf/0x11 [battery] Nov 2 12:37:20 donald kernel: [c01889ca] seq_read+0xea/0x264 Nov 2 12:37:20 donald kernel: [c019fddb] proc_reg_read+0x63/0x76 Nov 2 12:37:20 donald kernel: [c0172631] vfs_read+0xa6/0x12f Nov 2 12:37:20 donald kernel: [c0172a2a] sys_read+0x3d/0x61 Nov 2 12:37:20 donald kernel: [c0103f12] sysenter_past_esp+0x5f/0x85 Nov 2 12:37:20 donald kernel: === Nov 2 12:37:20 donald kernel: WARNING: at /home/eike/repos/linux-2.6/lib/kref.c:33 kref_get() Nov 2 12:37:20 donald kernel: [c0104edd] show_trace_log_lvl+0x1a/0x2f Nov 2 12:37:20 donald kernel: [c010576e] show_trace+0x12/0x14 Nov 2 12:37:20 donald kernel: [c010585b] dump_stack+0x16/0x18 Nov 2 12:37:20 donald kernel: [c01d1d3c] kref_get+0x37/0x43 Nov 2 12:37:20 donald kernel: [c01d10af] kobject_get+0x12/0x17 Nov 2 12:37:20 donald kernel: [c0231509] get_device+0x13/0x1d Nov 2 12:37:20 donald kernel: [c02319e8] device_remove_file+0xe/0x2a Nov 2 12:37:20 donald kernel: [f8b9b3dd] power_supply_remove_attrs+0x16/0x37 [power_supply] Nov 2 12:37:20 donald kernel: [f8b9b012] power_supply_unregister+0x12/0x1d [power_supply] Nov 2 12:37:20 donald kernel: [f8be704b] sysfs_remove_battery+0x1f/0x22 [battery] Nov 2 12:37:20 donald kernel: [f8be71a2] acpi_battery_update+0x3f/0x255 [battery] Nov 2 12:37:20 donald kernel: [f8be73ed] acpi_battery_read+0x11/0x20 [battery] Nov 2 12:37:20 donald kernel: [f8be741c] acpi_battery_read_state+0xf/0x11 [battery] Nov 2 12:37:20 donald kernel: [c01889ca] seq_read+0xea/0x264 Nov 2 12:37:20 donald kernel: [c019fddb] proc_reg_read+0x63/0x76 Nov 2 12:37:20 donald kernel: [c0172631] vfs_read+0xa6/0x12f Nov 2 12:37:20 donald kernel: [c0172a2a] sys_read+0x3d/0x61 Nov 2 12:37:20 donald kernel: [c0103f12] sysenter_past_esp+0x5f/0x85 Nov 2 12:37:20 donald kernel: === tons more of stuff like this, system us unusable with this kernel now. In the meantime I upgraded to current git, last commit is now b4d367fb20ed19be4a53fa88b407248aeb8bd461 Eike signature.asc Description: This is a digitally signed message part.
Re: [2.6.24-rc1][BUG] Oops on battery removal
Alexey Starikovskiy wrote: Rolf Eike Beer wrote: Alexey Starikovskiy wrote: Rolf Eike Beer wrote: Alexey Starikovskiy wrote: Rolf Eike Beer wrote: Rolf Eike Beer wrote: Hi, this happened while I removed my battery on bootup. Complete dmesg is attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was d919fd433b5823d1cf9d0688eb2eec183de9b74c). Ok, I found out that it has nothing to do with the actual removal as it seems. When I start the laptop with battery already detached I get the same error. Please check if this patch helps. It made things worse: How about this patch? Ehm, that is the same patch as before! Yes, sorry... Two patches in parallel -- not good. Tested-by: Rolf Eike Beer [EMAIL PROTECTED] It makes the crash go away. But there is something weird going on. Before I logged into X I did an cat /proc/acpi/battery/BAT1/* and it showed the battery as present with some (random?) values. Now I'm in X and everything looks fine there (as in not present). Eike signature.asc Description: This is a digitally signed message part.
Re: [2.6.24-rc1][BUG] Oops on battery removal
Alexey Starikovskiy wrote: Rolf Eike Beer wrote: Alexey Starikovskiy wrote: Rolf Eike Beer wrote: Rolf Eike Beer wrote: Hi, this happened while I removed my battery on bootup. Complete dmesg is attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was d919fd433b5823d1cf9d0688eb2eec183de9b74c). Ok, I found out that it has nothing to do with the actual removal as it seems. When I start the laptop with battery already detached I get the same error. Please check if this patch helps. It made things worse: How about this patch? Ehm, that is the same patch as before! Btw: it has an empty From: line Eike signature.asc Description: This is a digitally signed message part.
[2.6.24-rc1][BUG] Oops on battery removal
Hi, this happened while I removed my battery on bootup. Complete dmesg is attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was d919fd433b5823d1cf9d0688eb2eec183de9b74c). Greetings, Eike BUG: unable to handle kernel NULL pointer dereference at virtual address 001c printing eip: c02a82cb *pde = Oops: [#1] SMP Modules linked in: iptable_filter ip_tables ip6table_filter ip6_tables x_tables ipv6 af_packet cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_powersave acpi_cpufreq speedstep_lib freq_table snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device twofish twofish_common cbc blkcipher dm_crypt nls_utf8 ntfs ext3 jbd loop mmc_block pcmcia container battery iwl3945 firmware_class yenta_socket button ohci1394 backlight output ac power_supply rsrc_nonstatic pcmcia_core mmc_core ieee1394 intel_agp joydev agpgart snd_hda_intel sr_mod cdrom r8169 snd_pcm snd_timer mac80211 snd soundcore snd_page_alloc i2c_i801 i2c_core cfg80211 serio_raw sg usbhid ehci_hcd uhci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan ata_piix libata scsi_mod thermal processor Pid: 47, comm: kacpi_notify Not tainted (2.6.24-rc1-git #68) EIP: 0060:[c02a82cb] EFLAGS: 00010286 CPU: 0 EIP is at klist_del+0xc/0x39 EAX: EBX: ECX: EDX: ESI: c2e2bc00 EDI: c2e2bc20 EBP: c1c88d7c ESP: c1c88d70 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Process kacpi_notify (pid: 47, ti=c1c88000 task=c1cb5350 task.ti=c1c88000) Stack: c2e2bc00 c2e2bc00 c1ce960c c1c88d90 c0231ab6 c2e2bc00 c2e2ba00 c1c88e1c c1c88d9c c0231ced c2e2ba1c c1c88da8 f8bee01a c2e2ba00 c1c88db4 f8c3904b c2e2ba00 c1c88de4 f8c391a2 c01d47bc c01d47bc 0001 80d0 Call Trace: [c0104edd] show_trace_log_lvl+0x1a/0x2f [c0104f8d] show_stack_log_lvl+0x9b/0xa3 [c010503c] show_registers+0xa7/0x179 [c0105222] die+0x114/0x1f5 [c02abced] do_page_fault+0x4b0/0x589 [c02aa58a] error_code+0x72/0x78 [c0231ab6] device_del+0x1a/0x246 [c0231ced] device_unregister+0xb/0x15 [f8bee01a] power_supply_unregister+0x1a/0x1d [power_supply] [f8c3904b] sysfs_remove_battery+0x1f/0x22 [battery] [f8c391a2] acpi_battery_update+0x3f/0x255 [battery] [f8c396e9] acpi_battery_get_property+0x2b/0x149 [battery] [f8bee2c2] power_supply_show_property+0x32/0xf0 [power_supply] [f8bee59e] power_supply_uevent+0xfd/0x187 [power_supply] [c02322d8] dev_uevent+0xca/0xe8 [c01d1a28] kobject_uevent_env+0x15a/0x376 [c01d1c4e] kobject_uevent+0xa/0xc [c0231cb9] device_del+0x21d/0x246 [c0231ced] device_unregister+0xb/0x15 [f8bee01a] power_supply_unregister+0x1a/0x1d [power_supply] [f8c3904b] sysfs_remove_battery+0x1f/0x22 [battery] [f8c391a2] acpi_battery_update+0x3f/0x255 [battery] [f8c398ff] acpi_battery_notify+0x1e/0x73 [battery] [c01f9b50] acpi_ev_notify_dispatch+0x4f/0x5a [c01f447d] acpi_os_execute_notify+0x24/0x2f [c0130d05] run_workqueue+0x7d/0x110 [c01316f5] worker_thread+0xbe/0xcd [c0134247] kthread+0x3b/0x64 [c0104b63] kernel_thread_helper+0x7/0x10 === Code: 08 e8 63 20 00 00 83 7d f0 00 74 09 85 ff 74 05 89 f8 ff 55 f0 8b 45 ec 5a 59 5b 5e 5f 5d c3 55 89 e5 57 89 c7 56 53 8b 18 89 d8 8b 73 1c e8 7b 20 00 00 89 f8 e8 58 ff ff ff 85 c0 b8 00 00 00 EIP: [c02a82cb] klist_del+0xc/0x39 SS:ESP 0068:c1c88d70 CPU0 attaching NULL sched-domain. CPU1 attaching NULL sched-domain. CPU0 attaching sched-domain: domain 0: span 3 groups: 1 2 CPU1 attaching sched-domain: domain 0: span 3 groups: 2 1 BUG: unable to handle kernel NULL pointer dereference at virtual address 001c printing eip: c02a82cb *pde = Oops: [#2] SMP Modules linked in: iptable_filter ip_tables ip6table_filter ip6_tables x_tables ipv6 af_packet cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_powersave acpi_cpufreq speedstep_lib freq_table snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device twofish twofish_common cbc blkcipher dm_crypt nls_utf8 ntfs ext3 jbd loop mmc_block pcmcia container battery iwl3945 firmware_class yenta_socket button ohci1394 backlight output ac power_supply rsrc_nonstatic pcmcia_core mmc_core ieee1394 intel_agp joydev agpgart snd_hda_intel sr_mod cdrom r8169 snd_pcm snd_timer mac80211 snd soundcore snd_page_alloc i2c_i801 i2c_core cfg80211 serio_raw sg usbhid ehci_hcd uhci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan ata_piix libata scsi_mod thermal processor Pid: 2773, comm: hald Tainted: G D (2.6.24-rc1-git #68) EIP: 0060:[c02a82cb] EFLAGS: 00010286 CPU: 1 EIP is at klist_del+0xc/0x39 EAX: EBX: ECX: EDX: ESI: c2e2bc00 EDI: c2e2bc20 EBP: c33b9e8c ESP: c33b9e80 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process hald (pid: 2773, ti=c33b9000 task=c3304d30 task.ti=c33b9000) Stack: c2e2bc00 c2e2bc00 c1ce960c c33b9ea0 c0231ab6 c2e2bc00 c2e2ba00 0001 c33b9eac c0231ced c2e2ba1c c33b9eb8 f8bee01a c2e2ba00 c33b9ec4 f8c3904b c39b3ec0 c33b9ef4 f8c391a2 c0163a98 c27f1cbc 0246 c3bf9cf8
Re: [2.6.24-rc1][BUG] Oops on battery removal
Rolf Eike Beer wrote: Hi, this happened while I removed my battery on bootup. Complete dmesg is attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was d919fd433b5823d1cf9d0688eb2eec183de9b74c). Ok, I found out that it has nothing to do with the actual removal as it seems. When I start the laptop with battery already detached I get the same error. Eike signature.asc Description: This is a digitally signed message part.
Re: iwl3945 in 2.6.24-rc1 dies under load
Am Donnerstag, 1. November 2007 schrieb Rafael J. Wysocki: > On Wednesday, 31 October 2007 01:52, Pavel Machek wrote: > > Hi! > > > > ...does not seem to work too well :-(. It connects with the AP > > (good!), and survives some "normal" use, but it died at first big > > tcpspray (bd!). > > Is this a regression from 2.6.23? No, iwlwifi was merged after 2.6.23. Eike signature.asc Description: This is a digitally signed message part.
Re: iwl3945 in 2.6.24-rc1 dies under load
Am Donnerstag, 1. November 2007 schrieb Rafael J. Wysocki: On Wednesday, 31 October 2007 01:52, Pavel Machek wrote: Hi! ...does not seem to work too well :-(. It connects with the AP (good!), and survives some normal use, but it died at first big tcpspray (bd!). Is this a regression from 2.6.23? No, iwlwifi was merged after 2.6.23. Eike signature.asc Description: This is a digitally signed message part.
Re: Possible 2.6.23 regression - Disappearing disk space
James Ausmus wrote: > Since updating my laptop to 2.6.23, occasionally all of my free disk > space on my root partition will just go away, with no files accounting > for the space, with no odd messages in dmesg or my syslog. If I > reboot, I immediately have the proper amount of free space again. Here > is the output of a du -sx * on /, and the output of the df command > when the problem is occuring, followed by the same info after a fresh > reboot (literally just did the command in the failed state, then > immediately rebooted and ran the same commands again) - any thoughts > as to what might be happening? The file that eats up the memory is still opened by a process, but deleted. HTH Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
Jens Axboe wrote: > On Thu, Oct 25 2007, Rolf Eike Beer wrote: > > Jens Axboe wrote: > > > On Thu, Oct 25 2007, Rolf Eike Beer wrote: > > > > Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven: > > > > > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > > > > > > --- > > > > > > Whether this is a complete patch, suitable for all architectures, > > > > > > I'm not sure: it builds, boots and runs correctly on the x86_32 > > > > > > box in question, but you'll be a lot wiser than me about using > > > > > > dma_addr_t for everyone. (Seems a bit of a shame to include > > > > > > here, when I think all arches already get to > > > > > > include it one way or another, typically via asm/scatterlist.h; > > > > > > but I guess it's safest to repeat it.) > > > > > > > > > > there is a problem with this... sg_phys doesn't return an actual > > > > > *dma* address at least not an address you can give to the > > > > > device. Using dma_addr_t is thus a bit misleading. > > > > > > > > Ok, then: how do I actually get such an address? > > > > > > You use the dma mapping api, Documentation/DMA-mapping.txt > > > > Which comes back always to the same point: if I get a buffer from > > userspace to use for DMA: what can I do then? I need to convert a > > given list of (physical, pinned) pages to DMA addresses. > > get_user_pages() -> fill in sg table -> pci/dma_map_sg() So the answer to the first question should have been sg_dma_address() ;) Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
Jens Axboe wrote: > On Thu, Oct 25 2007, Rolf Eike Beer wrote: > > Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven: > > > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > > > > --- > > > > Whether this is a complete patch, suitable for all architectures, > > > > I'm not sure: it builds, boots and runs correctly on the x86_32 box > > > > in question, but you'll be a lot wiser than me about using dma_addr_t > > > > for everyone. (Seems a bit of a shame to include here, > > > > when I think all arches already get to include it one way or another, > > > > typically via asm/scatterlist.h; but I guess it's safest to repeat > > > > it.) > > > > > > there is a problem with this... sg_phys doesn't return an actual *dma* > > > address at least not an address you can give to the device. > > > Using dma_addr_t is thus a bit misleading. > > > > Ok, then: how do I actually get such an address? > > You use the dma mapping api, Documentation/DMA-mapping.txt Which comes back always to the same point: if I get a buffer from userspace to use for DMA: what can I do then? I need to convert a given list of (physical, pinned) pages to DMA addresses. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven: > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > > --- > > Whether this is a complete patch, suitable for all architectures, > > I'm not sure: it builds, boots and runs correctly on the x86_32 box > > in question, but you'll be a lot wiser than me about using dma_addr_t > > for everyone. (Seems a bit of a shame to include here, > > when I think all arches already get to include it one way or another, > > typically via asm/scatterlist.h; but I guess it's safest to repeat > > it.) > > there is a problem with this... sg_phys doesn't return an actual *dma* > address at least not an address you can give to the device. > Using dma_addr_t is thus a bit misleading. Ok, then: how do I actually get such an address? Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 3/4] [SCSI] ips: PCI API cleanups
Jeff Garzik wrote:
> * pass Scsi_Host to ips_remove_device() via pci_set_drvdata(),
> allowing us to eliminate the ips_ha[] search loop and call
> ips_release() directly.
>
> * call pci_{request,release}_regions() and eliminate individual
> request/release_[mem_]region() calls
>
> * call pci_disable_device(), paired with pci_enable_device()
>
> * s/0/NULL/ in a few places
>
> * check ioremap() return value
> @@ -7036,32 +7042,17 @@ ips_init_phase1(struct pci_dev *pci_dev, int
> *indexPtr) uint32_t base;
> uint32_t offs;
>
> - if (!request_mem_region(mem_addr, mem_len, "ips")) {
> - IPS_PRINTK(KERN_WARNING, pci_dev,
> -"Couldn't allocate IO Memory space %x len
> %d.\n",
> -mem_addr, mem_len);
> - return -1;
> - }
> -
> base = mem_addr & PAGE_MASK;
> offs = mem_addr - base;
> ioremap_ptr = ioremap(base, PAGE_SIZE);
This looks odd. What are we actually doing here?
It seems that we want to map that PCI BAR. Since we're playing with PAGE_MASK
I assume the BAR always has a length
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 3/4] [SCSI] ips: PCI API cleanups
Jeff Garzik wrote:
* pass Scsi_Host to ips_remove_device() via pci_set_drvdata(),
allowing us to eliminate the ips_ha[] search loop and call
ips_release() directly.
* call pci_{request,release}_regions() and eliminate individual
request/release_[mem_]region() calls
* call pci_disable_device(), paired with pci_enable_device()
* s/0/NULL/ in a few places
* check ioremap() return value
@@ -7036,32 +7042,17 @@ ips_init_phase1(struct pci_dev *pci_dev, int
*indexPtr) uint32_t base;
uint32_t offs;
- if (!request_mem_region(mem_addr, mem_len, ips)) {
- IPS_PRINTK(KERN_WARNING, pci_dev,
-Couldn't allocate IO Memory space %x len
%d.\n,
-mem_addr, mem_len);
- return -1;
- }
-
base = mem_addr PAGE_MASK;
offs = mem_addr - base;
ioremap_ptr = ioremap(base, PAGE_SIZE);
This looks odd. What are we actually doing here?
It seems that we want to map that PCI BAR. Since we're playing with PAGE_MASK
I assume the BAR always has a length PAGE_SIZE, else we would get page
aligned memory anyway. If that's true something like
mem_ptr = pci_iomap(pci_dev, bar, 0)
should do the trick. Later we would do
pci_iounmap(pci_dev, mem_ptr)
This whole ioremap_ptr stuff can go away at all. Am I right? Then I'll cook up
a patch soon.
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven: Signed-off-by: Hugh Dickins [EMAIL PROTECTED] --- Whether this is a complete patch, suitable for all architectures, I'm not sure: it builds, boots and runs correctly on the x86_32 box in question, but you'll be a lot wiser than me about using dma_addr_t for everyone. (Seems a bit of a shame to include asm/types.h here, when I think all arches already get to include it one way or another, typically via asm/scatterlist.h; but I guess it's safest to repeat it.) there is a problem with this... sg_phys doesn't return an actual *dma* address at least not an address you can give to the device. Using dma_addr_t is thus a bit misleading. Ok, then: how do I actually get such an address? Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
Jens Axboe wrote: On Thu, Oct 25 2007, Rolf Eike Beer wrote: Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven: Signed-off-by: Hugh Dickins [EMAIL PROTECTED] --- Whether this is a complete patch, suitable for all architectures, I'm not sure: it builds, boots and runs correctly on the x86_32 box in question, but you'll be a lot wiser than me about using dma_addr_t for everyone. (Seems a bit of a shame to include asm/types.h here, when I think all arches already get to include it one way or another, typically via asm/scatterlist.h; but I guess it's safest to repeat it.) there is a problem with this... sg_phys doesn't return an actual *dma* address at least not an address you can give to the device. Using dma_addr_t is thus a bit misleading. Ok, then: how do I actually get such an address? You use the dma mapping api, Documentation/DMA-mapping.txt Which comes back always to the same point: if I get a buffer from userspace to use for DMA: what can I do then? I need to convert a given list of (physical, pinned) pages to DMA addresses. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
Jens Axboe wrote: On Thu, Oct 25 2007, Rolf Eike Beer wrote: Jens Axboe wrote: On Thu, Oct 25 2007, Rolf Eike Beer wrote: Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven: Signed-off-by: Hugh Dickins [EMAIL PROTECTED] --- Whether this is a complete patch, suitable for all architectures, I'm not sure: it builds, boots and runs correctly on the x86_32 box in question, but you'll be a lot wiser than me about using dma_addr_t for everyone. (Seems a bit of a shame to include asm/types.h here, when I think all arches already get to include it one way or another, typically via asm/scatterlist.h; but I guess it's safest to repeat it.) there is a problem with this... sg_phys doesn't return an actual *dma* address at least not an address you can give to the device. Using dma_addr_t is thus a bit misleading. Ok, then: how do I actually get such an address? You use the dma mapping api, Documentation/DMA-mapping.txt Which comes back always to the same point: if I get a buffer from userspace to use for DMA: what can I do then? I need to convert a given list of (physical, pinned) pages to DMA addresses. get_user_pages() - fill in sg table - pci/dma_map_sg() So the answer to the first question should have been sg_dma_address() ;) Eike signature.asc Description: This is a digitally signed message part.
Re: Possible 2.6.23 regression - Disappearing disk space
James Ausmus wrote: Since updating my laptop to 2.6.23, occasionally all of my free disk space on my root partition will just go away, with no files accounting for the space, with no odd messages in dmesg or my syslog. If I reboot, I immediately have the proper amount of free space again. Here is the output of a du -sx * on /, and the output of the df command when the problem is occuring, followed by the same info after a fresh reboot (literally just did the command in the failed state, then immediately rebooted and ran the same commands again) - any thoughts as to what might be happening? The file that eats up the memory is still opened by a process, but deleted. HTH Eike signature.asc Description: This is a digitally signed message part.
[PATCH] Typo: depricated -> deprecated
Typo: depricated -> deprecated Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit b7ec07d26c9fd915fd32b759aa05a1ead8c432f5 tree 6f6dafac4072fddd670a97f68cbd64bf505d0408 parent 43dcafe3f7bfc07bdaf55d353fd4c5112c5f2be6 author Rolf Eike Beer <[EMAIL PROTECTED]> Sun, 07 Oct 2007 10:29:39 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Sun, 07 Oct 2007 10:29:39 +0200 drivers/acpi/Kconfig|2 +- drivers/net/natsemi.c |2 +- drivers/net/tulip/winbond-840.c |2 +- include/linux/cdrom.h |4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 4875f01..efd9690 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -52,7 +52,7 @@ config ACPI_PROCFS depends on PROC_FS ---help--- For backwards compatibility, this option allows - depricated /proc/acpi/ files to exist, even when + deprecated /proc/acpi/ files to exist, even when they have been replaced by functions in /sys. The deprecated files (and their replacements) include: diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c index b47a12d..4df046d 100644 --- a/drivers/net/natsemi.c +++ b/drivers/net/natsemi.c @@ -997,7 +997,7 @@ static int __devinit natsemi_probe1 (struct pci_dev *pdev, a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that made udelay() unreliable. The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is - depricated. + deprecated. */ #define eeprom_delay(ee_addr) readl(ee_addr) diff --git a/drivers/net/tulip/winbond-840.c b/drivers/net/tulip/winbond-840.c index 5824f6a..2fad782 100644 --- a/drivers/net/tulip/winbond-840.c +++ b/drivers/net/tulip/winbond-840.c @@ -485,7 +485,7 @@ err_out_netdev: a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that made udelay() unreliable. The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is - depricated. + deprecated. */ #define eeprom_delay(ee_addr) ioread32(ee_addr) diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h index 2b641b1..5394d47 100644 --- a/include/linux/cdrom.h +++ b/include/linux/cdrom.h @@ -76,7 +76,7 @@ (struct cdrom_multisession) */ #define CDROM_GET_MCN 0x5311 /* Obtain the "Universal Product Code" if available (struct cdrom_mcn) */ -#define CDROM_GET_UPC CDROM_GET_MCN /* This one is depricated, +#define CDROM_GET_UPC CDROM_GET_MCN /* This one is deprecated, but here anyway for compatibility */ #define CDROMRESET 0x5312 /* hard-reset the drive */ #define CDROMVOLREAD 0x5313 /* Get the drive's volume setting @@ -506,7 +506,7 @@ struct cdrom_generic_command #define GPMODE_TO_PROTECT_PAGE 0x1d #define GPMODE_CAPABILITIES_PAGE 0x2a #define GPMODE_ALL_PAGES 0x3f -/* Not in Mt. Fuji, but in ATAPI 2.6 -- depricated now in favor +/* Not in Mt. Fuji, but in ATAPI 2.6 -- deprecated now in favor * of MODE_SENSE_POWER_PAGE */ #define GPMODE_CDROM_PAGE 0x0d - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Typo: depricated - deprecated
Typo: depricated - deprecated Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED] --- commit b7ec07d26c9fd915fd32b759aa05a1ead8c432f5 tree 6f6dafac4072fddd670a97f68cbd64bf505d0408 parent 43dcafe3f7bfc07bdaf55d353fd4c5112c5f2be6 author Rolf Eike Beer [EMAIL PROTECTED] Sun, 07 Oct 2007 10:29:39 +0200 committer Rolf Eike Beer [EMAIL PROTECTED] Sun, 07 Oct 2007 10:29:39 +0200 drivers/acpi/Kconfig|2 +- drivers/net/natsemi.c |2 +- drivers/net/tulip/winbond-840.c |2 +- include/linux/cdrom.h |4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 4875f01..efd9690 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -52,7 +52,7 @@ config ACPI_PROCFS depends on PROC_FS ---help--- For backwards compatibility, this option allows - depricated /proc/acpi/ files to exist, even when + deprecated /proc/acpi/ files to exist, even when they have been replaced by functions in /sys. The deprecated files (and their replacements) include: diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c index b47a12d..4df046d 100644 --- a/drivers/net/natsemi.c +++ b/drivers/net/natsemi.c @@ -997,7 +997,7 @@ static int __devinit natsemi_probe1 (struct pci_dev *pdev, a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that made udelay() unreliable. The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is - depricated. + deprecated. */ #define eeprom_delay(ee_addr) readl(ee_addr) diff --git a/drivers/net/tulip/winbond-840.c b/drivers/net/tulip/winbond-840.c index 5824f6a..2fad782 100644 --- a/drivers/net/tulip/winbond-840.c +++ b/drivers/net/tulip/winbond-840.c @@ -485,7 +485,7 @@ err_out_netdev: a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that made udelay() unreliable. The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is - depricated. + deprecated. */ #define eeprom_delay(ee_addr) ioread32(ee_addr) diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h index 2b641b1..5394d47 100644 --- a/include/linux/cdrom.h +++ b/include/linux/cdrom.h @@ -76,7 +76,7 @@ (struct cdrom_multisession) */ #define CDROM_GET_MCN 0x5311 /* Obtain the Universal Product Code if available (struct cdrom_mcn) */ -#define CDROM_GET_UPC CDROM_GET_MCN /* This one is depricated, +#define CDROM_GET_UPC CDROM_GET_MCN /* This one is deprecated, but here anyway for compatibility */ #define CDROMRESET 0x5312 /* hard-reset the drive */ #define CDROMVOLREAD 0x5313 /* Get the drive's volume setting @@ -506,7 +506,7 @@ struct cdrom_generic_command #define GPMODE_TO_PROTECT_PAGE 0x1d #define GPMODE_CAPABILITIES_PAGE 0x2a #define GPMODE_ALL_PAGES 0x3f -/* Not in Mt. Fuji, but in ATAPI 2.6 -- depricated now in favor +/* Not in Mt. Fuji, but in ATAPI 2.6 -- deprecated now in favor * of MODE_SENSE_POWER_PAGE */ #define GPMODE_CDROM_PAGE 0x0d - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accessing 64-bit BARs
Am Donnerstag, 4. Oktober 2007 schrieb yogeshwar sonawane: > Hello all, > > For accessing memory-mapped 64bit-BAR regions of a PCI card, the > respective BAR regions has to be made accessible to the kernel using > ioremap() function. Then readl()/writel() can be used on the address > returned by ioremap(). You should use pci_iomap() to get an access pointer to the BAR. After this you can access the memory with ioread*() and iowrite*(). See "man pci_iomap(9)" if you build kernel manpages. Greetings, Eike signature.asc Description: This is a digitally signed message part.
Re: Accessing 64-bit BARs
Am Donnerstag, 4. Oktober 2007 schrieb yogeshwar sonawane: Hello all, For accessing memory-mapped 64bit-BAR regions of a PCI card, the respective BAR regions has to be made accessible to the kernel using ioremap() function. Then readl()/writel() can be used on the address returned by ioremap(). You should use pci_iomap() to get an access pointer to the BAR. After this you can access the memory with ioread*() and iowrite*(). See man pci_iomap(9) if you build kernel manpages. Greetings, Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 19/30] scsi: Remove explicit casts of [kv]alloc return values in osst driver
Jesper Juhl wrote:
> [kv]alloc() return void *. No need to cast the return value.
> @@ -5756,7 +5756,7 @@ static int osst_probe(struct device *dev)
> write_lock(_scsi_tapes_lock);
> if (os_scsi_tapes == NULL) {
> os_scsi_tapes =
> - (struct osst_tape **)kmalloc(osst_max_dev *
> sizeof(struct osst_tape *),
> + kmalloc(osst_max_dev * sizeof(struct osst_tape *),
> GFP_ATOMIC);
> if (os_scsi_tapes == NULL) {
> write_unlock(_scsi_tapes_lock);
Three lines later:
for (i=0; i < osst_max_dev; ++i) os_scsi_tapes[i] = NULL;
This wants to be
os_scsi_tapes = kcalloc(osst_max_dev, sizeof(struct osst_tape *), GFP_ATOMIC);
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 19/30] scsi: Remove explicit casts of [kv]alloc return values in osst driver
Jesper Juhl wrote:
[kv]alloc() return void *. No need to cast the return value.
@@ -5756,7 +5756,7 @@ static int osst_probe(struct device *dev)
write_lock(os_scsi_tapes_lock);
if (os_scsi_tapes == NULL) {
os_scsi_tapes =
- (struct osst_tape **)kmalloc(osst_max_dev *
sizeof(struct osst_tape *),
+ kmalloc(osst_max_dev * sizeof(struct osst_tape *),
GFP_ATOMIC);
if (os_scsi_tapes == NULL) {
write_unlock(os_scsi_tapes_lock);
Three lines later:
for (i=0; i osst_max_dev; ++i) os_scsi_tapes[i] = NULL;
This wants to be
os_scsi_tapes = kcalloc(osst_max_dev, sizeof(struct osst_tape *), GFP_ATOMIC);
Eike
signature.asc
Description: This is a digitally signed message part.
[PATCH][Doc] Typo: fro -> from
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit 11a9dc32fadc7fe6722dc62ce84f0e483eb85368 tree bc08486dd569753148b5e09d000866cec4d971d7 parent a3036bca04b4e27427e01ed74fb93b8600595bce author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 17 Jul 2007 09:54:47 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 17 Jul 2007 09:54:47 +0200 Documentation/console/console.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/console/console.txt b/Documentation/console/console.txt index d3e1744..877a1b2 100644 --- a/Documentation/console/console.txt +++ b/Documentation/console/console.txt @@ -29,7 +29,7 @@ In newer kernels, the following are also available: If sysfs is enabled, the contents of /sys/class/vtconsole can be examined. This shows the console backends currently registered by the -system which are named vtcon where is an integer fro 0 to 15. Thus: +system which are named vtcon where is an integer from 0 to 15. Thus: ls /sys/class/vtconsole . .. vtcon0 vtcon1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][Doc] Typo: fro - from
Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED] --- commit 11a9dc32fadc7fe6722dc62ce84f0e483eb85368 tree bc08486dd569753148b5e09d000866cec4d971d7 parent a3036bca04b4e27427e01ed74fb93b8600595bce author Rolf Eike Beer [EMAIL PROTECTED] Tue, 17 Jul 2007 09:54:47 +0200 committer Rolf Eike Beer [EMAIL PROTECTED] Tue, 17 Jul 2007 09:54:47 +0200 Documentation/console/console.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/console/console.txt b/Documentation/console/console.txt index d3e1744..877a1b2 100644 --- a/Documentation/console/console.txt +++ b/Documentation/console/console.txt @@ -29,7 +29,7 @@ In newer kernels, the following are also available: If sysfs is enabled, the contents of /sys/class/vtconsole can be examined. This shows the console backends currently registered by the -system which are named vtconn where n is an integer fro 0 to 15. Thus: +system which are named vtconn where n is an integer from 0 to 15. Thus: ls /sys/class/vtconsole . .. vtcon0 vtcon1 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Test_Module] Changing brightness in Toshiba notebooks with Phoenix Bios
Am Freitag, 15. Juni 2007 schrieb Renato S. Yamane: > Forwarding from: Toshiba_Linux-Users ([EMAIL PROTECTED]) > > = > I only tested on my Toshiba Satellite Pro A100 and it works. You may want to have a look on the "omnibook" project on http://omnibook.sf.net. Although it's named omnibook it added support for many laptop goodies on my A178. Eike signature.asc Description: This is a digitally signed message part.
Re: [Test_Module] Changing brightness in Toshiba notebooks with Phoenix Bios
Am Freitag, 15. Juni 2007 schrieb Renato S. Yamane: Forwarding from: Toshiba_Linux-Users ([EMAIL PROTECTED]) = I only tested on my Toshiba Satellite Pro A100 and it works. You may want to have a look on the omnibook project on http://omnibook.sf.net. Although it's named omnibook it added support for many laptop goodies on my A178. Eike signature.asc Description: This is a digitally signed message part.
[PATCH] Fix typo in include/linux/pci.h
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit f57463dabf991c306dc43dcf7445ec574484e4ee
tree 37c5d48baf200d7c8d04e506fd8b99217953
parent 58056c2424917e90b86ca11c2c5d3fd35313d7b6
author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 10 Jul 2007 13:32:29 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 10 Jul 2007 13:32:29 +0200
include/linux/pci.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 086a0e5..87aa73e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -313,7 +313,7 @@ struct pci_dynids {
/* */
/** PCI Error Recovery System (PCI-ERS). If a PCI device driver provides
- * a set fof callbacks in struct pci_error_handlers, then that device driver
+ * a set of callbacks in struct pci_error_handlers, then that device driver
* will be notified of PCI bus errors, and will be driven to recovery
* when an error occurs.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][Doc] Document pci_iomap()
This useful interface is hardly mentioned anywhere in the in-tree
documentation.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit bdf4a23b9b1ff4be79a6f9b863f7203dba2dc808
tree a53c4a6c90e13d55fbf2a0b40cd9676bd9a5d0e5
parent 33738cbb6555861de1dce626c913fad06ce658cc
author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 10 Jul 2007 11:08:51 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 10 Jul 2007 11:08:51 +0200
Documentation/DocBook/deviceiobook.tmpl |3 ++-
include/asm-i386/io.h |3 +++
lib/iomap.c | 15 ++-
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/deviceiobook.tmpl
b/Documentation/DocBook/deviceiobook.tmpl
index 90ed23d..c917de6 100644
--- a/Documentation/DocBook/deviceiobook.tmpl
+++ b/Documentation/DocBook/deviceiobook.tmpl
@@ -316,7 +316,8 @@ CPU B: spin_unlock_irqrestore(dev_lock, flags)
Public Functions Provided
-!Einclude/asm-i386/io.h
+!Iinclude/asm-i386/io.h
+!Elib/iomap.c
diff --git a/include/asm-i386/io.h b/include/asm-i386/io.h
index e797586..c48ef18 100644
--- a/include/asm-i386/io.h
+++ b/include/asm-i386/io.h
@@ -112,6 +112,9 @@ extern void __iomem * __ioremap(unsigned long offset,
unsigned long size, unsign
* writew/writel functions and the other mmio helpers. The returned
* address is not guaranteed to be usable directly as a virtual
* address.
+ *
+ * If the area you are trying to map is a PCI BAR you should have a
+ * look at pci_iomap().
*/
static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
diff --git a/lib/iomap.c b/lib/iomap.c
index a57d262..864f2ec 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -240,7 +240,20 @@ void ioport_unmap(void __iomem *addr)
EXPORT_SYMBOL(ioport_map);
EXPORT_SYMBOL(ioport_unmap);
-/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
+/**
+ * pci_iomap - create a virtual mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @maxlen: length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR without checking for its length first, pass %0 here.
+ * */
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
{
unsigned long start = pci_resource_start(dev, bar);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][Doc] Document pci_iomap()
This useful interface is hardly mentioned anywhere in the in-tree
documentation.
Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED]
---
commit bdf4a23b9b1ff4be79a6f9b863f7203dba2dc808
tree a53c4a6c90e13d55fbf2a0b40cd9676bd9a5d0e5
parent 33738cbb6555861de1dce626c913fad06ce658cc
author Rolf Eike Beer [EMAIL PROTECTED] Tue, 10 Jul 2007 11:08:51 +0200
committer Rolf Eike Beer [EMAIL PROTECTED] Tue, 10 Jul 2007 11:08:51 +0200
Documentation/DocBook/deviceiobook.tmpl |3 ++-
include/asm-i386/io.h |3 +++
lib/iomap.c | 15 ++-
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/deviceiobook.tmpl
b/Documentation/DocBook/deviceiobook.tmpl
index 90ed23d..c917de6 100644
--- a/Documentation/DocBook/deviceiobook.tmpl
+++ b/Documentation/DocBook/deviceiobook.tmpl
@@ -316,7 +316,8 @@ CPU B: spin_unlock_irqrestore(amp;dev_lock, flags)
chapter id=pubfunctions
titlePublic Functions Provided/title
-!Einclude/asm-i386/io.h
+!Iinclude/asm-i386/io.h
+!Elib/iomap.c
/chapter
/book
diff --git a/include/asm-i386/io.h b/include/asm-i386/io.h
index e797586..c48ef18 100644
--- a/include/asm-i386/io.h
+++ b/include/asm-i386/io.h
@@ -112,6 +112,9 @@ extern void __iomem * __ioremap(unsigned long offset,
unsigned long size, unsign
* writew/writel functions and the other mmio helpers. The returned
* address is not guaranteed to be usable directly as a virtual
* address.
+ *
+ * If the area you are trying to map is a PCI BAR you should have a
+ * look at pci_iomap().
*/
static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
diff --git a/lib/iomap.c b/lib/iomap.c
index a57d262..864f2ec 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -240,7 +240,20 @@ void ioport_unmap(void __iomem *addr)
EXPORT_SYMBOL(ioport_map);
EXPORT_SYMBOL(ioport_unmap);
-/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
+/**
+ * pci_iomap - create a virtual mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @maxlen: length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR without checking for its length first, pass %0 here.
+ * */
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
{
unsigned long start = pci_resource_start(dev, bar);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 typo in include/linux/pci.h
Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED]
---
commit f57463dabf991c306dc43dcf7445ec574484e4ee
tree 37c5d48baf200d7c8d04e506fd8b99217953
parent 58056c2424917e90b86ca11c2c5d3fd35313d7b6
author Rolf Eike Beer [EMAIL PROTECTED] Tue, 10 Jul 2007 13:32:29 +0200
committer Rolf Eike Beer [EMAIL PROTECTED] Tue, 10 Jul 2007 13:32:29 +0200
include/linux/pci.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 086a0e5..87aa73e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -313,7 +313,7 @@ struct pci_dynids {
/* */
/** PCI Error Recovery System (PCI-ERS). If a PCI device driver provides
- * a set fof callbacks in struct pci_error_handlers, then that device driver
+ * a set of callbacks in struct pci_error_handlers, then that device driver
* will be notified of PCI bus errors, and will be driven to recovery
* when an error occurs.
*/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4][Doc] Document pci_iomap()
This useful interface is hardly mentioned anywhere in the in-tree
documentation.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit 2cb2450818804edcbcb1486a4df0db06e5d49969
tree 2c53fbd2e0be832767446a8684561200b437a695
parent 288a3f1fd00365669ed9ad725b15ff67004cee0a
author Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 14 Aug 2006 14:20:30 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 14 Aug 2006 14:20:30 +0200
Documentation/DocBook/deviceiobook.tmpl |1 +
include/asm-i386/io.h |3 +++
lib/iomap.c | 15 ++-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/DocBook/deviceiobook.tmpl
b/Documentation/DocBook/deviceiobook.tmpl
index 90ed23d..4f85515 100644
--- a/Documentation/DocBook/deviceiobook.tmpl
+++ b/Documentation/DocBook/deviceiobook.tmpl
@@ -317,6 +317,7 @@ CPU B: spin_unlock_irqrestore(dev_lock, flags)
Public Functions Provided
!Einclude/asm-i386/io.h
+!Elib/iomap.c
diff --git a/include/asm-i386/io.h b/include/asm-i386/io.h
index b3724fe..e176483 100644
--- a/include/asm-i386/io.h
+++ b/include/asm-i386/io.h
@@ -112,6 +112,9 @@ extern void __iomem * __ioremap(unsigned long offset,
unsigned long size, unsign
* writew/writel functions and the other mmio helpers. The returned
* address is not guaranteed to be usable directly as a virtual
* address.
+ *
+ * If the area you are trying to map is a PCI BAR you should have a
+ * look on pci_iomap().
*/
static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
diff --git a/lib/iomap.c b/lib/iomap.c
index 55689c5..8de891d 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -202,7 +202,20 @@ void ioport_unmap(void __iomem *addr)
EXPORT_SYMBOL(ioport_map);
EXPORT_SYMBOL(ioport_unmap);
-/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
+/**
+ * pci_iomap - create a virtual mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @maxlen: length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR without checking for their length first pass %0 here.
+ **/
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
{
unsigned long start = pci_resource_start(dev, bar);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] Initialize filp->private_data only once in em28xx_v4l2_open
Some lines later filp->private_data is initialized to dev again. Since there
are some checks that might fail in the mean time keep the later version.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit 7103e0b114b01a16d7c1ea71914d5069d974167d
tree 6b976d7ce4e872b32805d7df73dd13b5349d439f
parent 39c068bce1d63f6c1345c1ddfda1841d9fd20c74
author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 25 Jul 2006 17:55:34 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 25 Jul 2006 17:55:34 +0200
drivers/media/video/em28xx/em28xx-video.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-video.c
b/drivers/media/video/em28xx/em28xx-video.c
index 2a461dd..b2ae0c8 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -268,8 +268,6 @@ static int em28xx_v4l2_open(struct inode *inode, struct
file *filp)
if (NULL == dev)
return -ENODEV;
- filp->private_data=dev;
-
em28xx_videodbg("open minor=%d type=%s users=%d\n",
minor,v4l2_type_names[dev->type],dev->users);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4][Doc] Fix typos in fs/sysfs/file.c
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit 966fef8404d59056d8524bf94d7dff790fe1fa82 tree 1adc274bc9b8e7e420db0b0023c8b70bd294e84e parent 0cbdc367b144a95709852c642a069ed652989520 author Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 21 May 2007 22:55:30 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 21 May 2007 22:55:30 +0200 fs/sysfs/file.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index b502c71..dcb8e83 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -370,7 +370,7 @@ static int sysfs_release(struct inode * inode, struct file * filp) * again will not get new data, or reset the state of 'poll'. * Reminder: this only works for attributes which actively support * it, and it is not possible to test an attribute from userspace - * to see if it supports poll (Nether 'poll' or 'select' return + * to see if it supports poll (Neither 'poll' nor 'select' return * an appropriate error code). When in doubt, set a suitable timeout value. */ static unsigned int sysfs_poll(struct file *filp, poll_table *wait) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] Use kcalloc() in drivers/video/aty/atyfb_base.c
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit cc4a7b5dfee25083a6a5741b5b640ae2a1d3aa12
tree a4763216a61fa1501bf9b5dbb60f8860d1620b99
parent dcd9673a1ca36cb084de58f443edf42fd64b186b
author Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 07 Aug 2006 13:36:24 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 07 Aug 2006 13:36:24 +0200
drivers/video/aty/atyfb_base.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
index 053ff63..6bc51bb 100644
--- a/drivers/video/aty/atyfb_base.c
+++ b/drivers/video/aty/atyfb_base.c
@@ -2995,12 +2995,11 @@ static int __devinit atyfb_setup_sparc(struct pci_dev
*pdev,
/* nothing */ ;
j = i + 4;
- par->mmap_map = kmalloc(j * sizeof(*par->mmap_map), GFP_ATOMIC);
+ par->mmap_map = kcalloc(j, sizeof(*par->mmap_map), GFP_ATOMIC);
if (!par->mmap_map) {
PRINTKE("atyfb_setup_sparc() can't alloc mmap_map\n");
return -ENOMEM;
}
- memset(par->mmap_map, 0, j * sizeof(*par->mmap_map));
for (i = 0, j = 2; i < 6 && pdev->resource[i].start; i++) {
struct resource *rp = >resource[i];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] misc patches
This are some random patches I've lying around here. They are not related to each other 1) Use kcalloc() in drivers/video/aty/atyfb_base.c 2) Initialize filp->private_data only once in em28xx_v4l2_open 3) [Doc] Fix typos in fs/sysfs/file.c 4) [Doc] Document pci_iomap() Eike signature.asc Description: This is a digitally signed message part.
[PATCH 0/4] misc patches
This are some random patches I've lying around here. They are not related to each other 1) Use kcalloc() in drivers/video/aty/atyfb_base.c 2) Initialize filp-private_data only once in em28xx_v4l2_open 3) [Doc] Fix typos in fs/sysfs/file.c 4) [Doc] Document pci_iomap() Eike signature.asc Description: This is a digitally signed message part.
[PATCH 1/4] Use kcalloc() in drivers/video/aty/atyfb_base.c
Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED]
---
commit cc4a7b5dfee25083a6a5741b5b640ae2a1d3aa12
tree a4763216a61fa1501bf9b5dbb60f8860d1620b99
parent dcd9673a1ca36cb084de58f443edf42fd64b186b
author Rolf Eike Beer [EMAIL PROTECTED] Mon, 07 Aug 2006 13:36:24 +0200
committer Rolf Eike Beer [EMAIL PROTECTED] Mon, 07 Aug 2006 13:36:24 +0200
drivers/video/aty/atyfb_base.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
index 053ff63..6bc51bb 100644
--- a/drivers/video/aty/atyfb_base.c
+++ b/drivers/video/aty/atyfb_base.c
@@ -2995,12 +2995,11 @@ static int __devinit atyfb_setup_sparc(struct pci_dev
*pdev,
/* nothing */ ;
j = i + 4;
- par-mmap_map = kmalloc(j * sizeof(*par-mmap_map), GFP_ATOMIC);
+ par-mmap_map = kcalloc(j, sizeof(*par-mmap_map), GFP_ATOMIC);
if (!par-mmap_map) {
PRINTKE(atyfb_setup_sparc() can't alloc mmap_map\n);
return -ENOMEM;
}
- memset(par-mmap_map, 0, j * sizeof(*par-mmap_map));
for (i = 0, j = 2; i 6 pdev-resource[i].start; i++) {
struct resource *rp = pdev-resource[i];
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] Initialize filp-private_data only once in em28xx_v4l2_open
Some lines later filp-private_data is initialized to dev again. Since there are some checks that might fail in the mean time keep the later version. Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED] --- commit 7103e0b114b01a16d7c1ea71914d5069d974167d tree 6b976d7ce4e872b32805d7df73dd13b5349d439f parent 39c068bce1d63f6c1345c1ddfda1841d9fd20c74 author Rolf Eike Beer [EMAIL PROTECTED] Tue, 25 Jul 2006 17:55:34 +0200 committer Rolf Eike Beer [EMAIL PROTECTED] Tue, 25 Jul 2006 17:55:34 +0200 drivers/media/video/em28xx/em28xx-video.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/em28xx/em28xx-video.c b/drivers/media/video/em28xx/em28xx-video.c index 2a461dd..b2ae0c8 100644 --- a/drivers/media/video/em28xx/em28xx-video.c +++ b/drivers/media/video/em28xx/em28xx-video.c @@ -268,8 +268,6 @@ static int em28xx_v4l2_open(struct inode *inode, struct file *filp) if (NULL == dev) return -ENODEV; - filp-private_data=dev; - em28xx_videodbg(open minor=%d type=%s users=%d\n, minor,v4l2_type_names[dev-type],dev-users); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4][Doc] Fix typos in fs/sysfs/file.c
Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED] --- commit 966fef8404d59056d8524bf94d7dff790fe1fa82 tree 1adc274bc9b8e7e420db0b0023c8b70bd294e84e parent 0cbdc367b144a95709852c642a069ed652989520 author Rolf Eike Beer [EMAIL PROTECTED] Mon, 21 May 2007 22:55:30 +0200 committer Rolf Eike Beer [EMAIL PROTECTED] Mon, 21 May 2007 22:55:30 +0200 fs/sysfs/file.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index b502c71..dcb8e83 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -370,7 +370,7 @@ static int sysfs_release(struct inode * inode, struct file * filp) * again will not get new data, or reset the state of 'poll'. * Reminder: this only works for attributes which actively support * it, and it is not possible to test an attribute from userspace - * to see if it supports poll (Nether 'poll' or 'select' return + * to see if it supports poll (Neither 'poll' nor 'select' return * an appropriate error code). When in doubt, set a suitable timeout value. */ static unsigned int sysfs_poll(struct file *filp, poll_table *wait) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4][Doc] Document pci_iomap()
This useful interface is hardly mentioned anywhere in the in-tree
documentation.
Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED]
---
commit 2cb2450818804edcbcb1486a4df0db06e5d49969
tree 2c53fbd2e0be832767446a8684561200b437a695
parent 288a3f1fd00365669ed9ad725b15ff67004cee0a
author Rolf Eike Beer [EMAIL PROTECTED] Mon, 14 Aug 2006 14:20:30 +0200
committer Rolf Eike Beer [EMAIL PROTECTED] Mon, 14 Aug 2006 14:20:30 +0200
Documentation/DocBook/deviceiobook.tmpl |1 +
include/asm-i386/io.h |3 +++
lib/iomap.c | 15 ++-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/DocBook/deviceiobook.tmpl
b/Documentation/DocBook/deviceiobook.tmpl
index 90ed23d..4f85515 100644
--- a/Documentation/DocBook/deviceiobook.tmpl
+++ b/Documentation/DocBook/deviceiobook.tmpl
@@ -317,6 +317,7 @@ CPU B: spin_unlock_irqrestore(amp;dev_lock, flags)
chapter id=pubfunctions
titlePublic Functions Provided/title
!Einclude/asm-i386/io.h
+!Elib/iomap.c
/chapter
/book
diff --git a/include/asm-i386/io.h b/include/asm-i386/io.h
index b3724fe..e176483 100644
--- a/include/asm-i386/io.h
+++ b/include/asm-i386/io.h
@@ -112,6 +112,9 @@ extern void __iomem * __ioremap(unsigned long offset,
unsigned long size, unsign
* writew/writel functions and the other mmio helpers. The returned
* address is not guaranteed to be usable directly as a virtual
* address.
+ *
+ * If the area you are trying to map is a PCI BAR you should have a
+ * look on pci_iomap().
*/
static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
diff --git a/lib/iomap.c b/lib/iomap.c
index 55689c5..8de891d 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -202,7 +202,20 @@ void ioport_unmap(void __iomem *addr)
EXPORT_SYMBOL(ioport_map);
EXPORT_SYMBOL(ioport_unmap);
-/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
+/**
+ * pci_iomap - create a virtual mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @maxlen: length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR without checking for their length first pass %0 here.
+ **/
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
{
unsigned long start = pci_resource_start(dev, bar);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add INPUT support to toshiba_acpi
Renato S. Yamane wrote: > Rolf Eike Beer wrote: > > Richard Hughes wrote: > >> Yes, although this is out of my area or expertise, sorry. > > > > I've looked a bit but can't find any driver interaction of those > > programs. Any further ideas welcome. > > Do you try omnibook driver? > svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk > > toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try > this module above and now I can change brightness writing in > /proc/omnibook/lcd and kpowersave can change brightness too. > > But, is impossible use multimedia keys (play, pause, browser, etc) and > couple keys (fn-fx), because Fn key and Multimedia keys don't is > recognized. Oh wow! Even my Multimedia keys get recognized. Thanks very much for your pointer. Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Renato S. Yamane wrote: Rolf Eike Beer wrote: Richard Hughes wrote: Yes, although this is out of my area or expertise, sorry. I've looked a bit but can't find any driver interaction of those programs. Any further ideas welcome. Do you try omnibook driver? svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try this module above and now I can change brightness writing in /proc/omnibook/lcd and kpowersave can change brightness too. But, is impossible use multimedia keys (play, pause, browser, etc) and couple keys (fn-fx), because Fn key and Multimedia keys don't is recognized. Oh wow! Even my Multimedia keys get recognized. Thanks very much for your pointer. Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: > On Tue, 2007-06-26 at 07:03 +0200, Rolf Eike Beer wrote: >> Richard Hughes wrote: >>> On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: >>>> None of the above keys generated a key event. Neither does >>>> "Brightness down", but it still works. "Brightness up" generates an event >>>> and works. >> >>>> Kpowersave tells me it can't do brightness switching in software >>>> (which works in WinXtraPain). >> >> Yes, I need a special process running for this. Would it be of some >> use if I take a look with IRPtracker on it or is that all you need to >> know? > > Yes, although this is out of my area or expertise, sorry. I've looked a bit but can't find any driver interaction of those programs. Any further ideas welcome. Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: On Tue, 2007-06-26 at 07:03 +0200, Rolf Eike Beer wrote: Richard Hughes wrote: On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: None of the above keys generated a key event. Neither does Brightness down, but it still works. Brightness up generates an event and works. Kpowersave tells me it can't do brightness switching in software (which works in WinXtraPain). Yes, I need a special process running for this. Would it be of some use if I take a look with IRPtracker on it or is that all you need to know? Yes, although this is out of my area or expertise, sorry. I've looked a bit but can't find any driver interaction of those programs. Any further ideas welcome. Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: > On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: > > None of the above keys generated a key event. Neither does "Brightness > > down", but it still works. "Brightness up" generates an event and works. > > Kpowersave tells me it can't do brightness switching in software (which > > works in WinXtraPain). > > Do you know how windows does this? Do you have to load a special > system-try thing to make the keys work? Yes, I need a special process running for this. Would it be of some use if I take a look with IRPtracker on it or is that all you need to know? Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: None of the above keys generated a key event. Neither does Brightness down, but it still works. Brightness up generates an event and works. Kpowersave tells me it can't do brightness switching in software (which works in WinXtraPain). Do you know how windows does this? Do you have to load a special system-try thing to make the keys work? Yes, I need a special process running for this. Would it be of some use if I take a look with IRPtracker on it or is that all you need to know? Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: > On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: > > None of the above keys generated a key event. Neither does "Brightness > > down", but it still works. "Brightness up" generates an event and works. > > Kpowersave tells me it can't do brightness switching in software (which > > works in WinXtraPain). > > Do you know how windows does this? Do you have to load a special > system-try thing to make the keys work? I'll have a look once I find time to boot Windows. Eike signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] Linux Kernel Tester’s Guide v0.3-rc1
Michal Piotrowski wrote:
> Hi,
>
> We are pleased to announce the availability of "Linux Kernel Tester's
> Guide" v0.3-rc1.
It would be cool if we can get a clickable table of contents. Normally it's
enough to include \usepackage{hyperref} before running pdflatex.
Eike
signature.asc
Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: > Attached patch adds a kernel thread to do polling on Toshiba hardware. Is there something similar available to support other Toshiba laptops? I own a A110-178 that is not supported by the driver but has a lot of keys that I can't use currently: Fn: -screen zoom (I actually don't care about this one) -S2RAM -S2Disk -Mute* Multimedia: -Browser -Video player -Play/pause -Stop -Forward -Reverse *Mute: it's a bit special. If I use it I can an on screen display (mute/sound) but regardless of which setting is displayed the sound is still there. None of the above keys generated a key event. Neither does "Brightness down", but it still works. "Brightness up" generates an event and works. Kpowersave tells me it can't do brightness switching in software (which works in WinXtraPain). If you need an acpidump or I can do some testing just ask. Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: Attached patch adds a kernel thread to do polling on Toshiba hardware. Is there something similar available to support other Toshiba laptops? I own a A110-178 that is not supported by the driver but has a lot of keys that I can't use currently: Fn: -screen zoom (I actually don't care about this one) -S2RAM -S2Disk -Mute* Multimedia: -Browser -Video player -Play/pause -Stop -Forward -Reverse *Mute: it's a bit special. If I use it I can an on screen display (mute/sound) but regardless of which setting is displayed the sound is still there. None of the above keys generated a key event. Neither does Brightness down, but it still works. Brightness up generates an event and works. Kpowersave tells me it can't do brightness switching in software (which works in WinXtraPain). If you need an acpidump or I can do some testing just ask. Eike signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] Linux Kernel Tester’s Guide v0.3-rc1
Michal Piotrowski wrote:
Hi,
We are pleased to announce the availability of Linux Kernel Tester's
Guide v0.3-rc1.
It would be cool if we can get a clickable table of contents. Normally it's
enough to include \usepackage{hyperref} before running pdflatex.
Eike
signature.asc
Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: None of the above keys generated a key event. Neither does Brightness down, but it still works. Brightness up generates an event and works. Kpowersave tells me it can't do brightness switching in software (which works in WinXtraPain). Do you know how windows does this? Do you have to load a special system-try thing to make the keys work? I'll have a look once I find time to boot Windows. Eike signature.asc Description: This is a digitally signed message part.
Re: [patch 34/54] Fix roundup_pow_of_two(1)
Chris Wright wrote: > * Theodore Tso ([EMAIL PROTECTED]) wrote: > > If this doesn't fix a user-visiable bug, should we be including it in > > the stable patch series? (Assuming that it doesn't, I wouldn't, but I > > tend to be more conservative about what I would include in a stable > > production release.) > > Rolf, despite simplicity of patch, I'm inclined to agree with Ted. > Were you effected by this in the wild, or just noticed by code > inspection? Code inspection. Drop it if you like, it's in mainline already. signature.asc Description: This is a digitally signed message part.
Re: [patch 34/54] Fix roundup_pow_of_two(1)
Chris Wright wrote: * Theodore Tso ([EMAIL PROTECTED]) wrote: If this doesn't fix a user-visiable bug, should we be including it in the stable patch series? (Assuming that it doesn't, I wouldn't, but I tend to be more conservative about what I would include in a stable production release.) Rolf, despite simplicity of patch, I'm inclined to agree with Ted. Were you effected by this in the wild, or just noticed by code inspection? Code inspection. Drop it if you like, it's in mainline already. signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Fix roundup_pow_of_two(1)
Adrian Bunk wrote: > On Thu, May 17, 2007 at 11:56:56PM +0200, Rolf Eike Beer wrote: > > Fix roundup_pow_of_two(1) > > > > 1 is a power of two, therefore roundup_pow_of_two(1) should return 1. It > > does in case the argument is a variable but in case it's a constant it > > behaves wrong and returns 0. Probably nobody ever did it so this was > > never noticed. > > I'm not getting the problem. > 2^0 = 1 Yes. But it returned 0 (not 1 << 0). Eike signature.asc Description: This is a digitally signed message part.
