Re: [PATCH v2] iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc()

[David Weinehall]

On Tue, Aug 22, 2017 at 10:37:29AM +0300, Luca Coelho wrote:
> From: Luca Coelho <luciano.coe...@intel.com>
> 
> Work queues cannot be allocated when a mutex is held because the mutex
> may be in use and that would make it sleep.  Doing so generates the
> following splat with 4.13+:
> 
> [   19.513298] ==
> [   19.513429] WARNING: possible circular locking dependency detected
> [   19.513557] 4.13.0-rc5+ #6 Not tainted
> [   19.513638] --
> [   19.513767] cpuhp/0/12 is trying to acquire lock:
> [   19.513867]  (>lock){+.+.+.}, at: [] 
> thermal_zone_get_temp+0x5b/0xb0
> [   19.514047]
> [   19.514047] but task is already holding lock:
> [   19.514166]  (cpuhp_state){+.+.+.}, at: [] 
> cpuhp_thread_fun+0x3a/0x210
> [   19.514338]
> [   19.514338] which lock already depends on the new lock.
> 
> This lock dependency already existed with previous kernel versions,
> but it was not detected until commit 49dfe2a67797 ("cpuhotplug: Link
> lock stacks for hotplug callbacks") was introduced.
> 
> Reported-by: David Weinehall <david.weineh...@intel.com>
> Reported-by: Jiri Kosina <ji...@kernel.org>
> Signed-off-by: Luca Coelho <luciano.coe...@intel.com>

With this patch I no longer get the lockdep warning,
and the driver seems to work just as well as before.

Thanks!

Tested-by: David Weinehall <david.weineh...@linux.intel.com>

> ---
> In v2:
>- updated the commit message to a new version, with a grammar fix
>  and the actual commit that exposed the problem;
> 
>  drivers/net/wireless/intel/iwlwifi/pcie/internal.h |  2 ++
>  drivers/net/wireless/intel/iwlwifi/pcie/rx.c   | 10 +-
>  drivers/net/wireless/intel/iwlwifi/pcie/trans.c|  9 +
>  3 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h 
> b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> index fa315d84e98e..a1ea9ef97ed9 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> @@ -787,6 +787,8 @@ int iwl_pci_fw_enter_d0i3(struct iwl_trans *trans);
>  
>  void iwl_pcie_enable_rx_wake(struct iwl_trans *trans, bool enable);
>  
> +void iwl_pcie_rx_allocator_work(struct work_struct *data);
> +
>  /* common functions that are used by gen2 transport */
>  void iwl_pcie_apm_config(struct iwl_trans *trans);
>  int iwl_pcie_prepare_card_hw(struct iwl_trans *trans);
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c 
> b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> index 351c4423125a..942736d3fa75 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -597,7 +597,7 @@ static void iwl_pcie_rx_allocator_get(struct iwl_trans 
> *trans,
>   rxq->free_count += RX_CLAIM_REQ_ALLOC;
>  }
>  
> -static void iwl_pcie_rx_allocator_work(struct work_struct *data)
> +void iwl_pcie_rx_allocator_work(struct work_struct *data)
>  {
>   struct iwl_rb_allocator *rba_p =
>   container_of(data, struct iwl_rb_allocator, rx_alloc);
> @@ -900,10 +900,6 @@ static int _iwl_pcie_rx_init(struct iwl_trans *trans)
>   return err;
>   }
>   def_rxq = trans_pcie->rxq;
> - if (!rba->alloc_wq)
> - rba->alloc_wq = alloc_workqueue("rb_allocator",
> - WQ_HIGHPRI | WQ_UNBOUND, 1);
> - INIT_WORK(>rx_alloc, iwl_pcie_rx_allocator_work);
>  
>   spin_lock(>lock);
>   atomic_set(>req_pending, 0);
> @@ -1017,10 +1013,6 @@ void iwl_pcie_rx_free(struct iwl_trans *trans)
>   }
>  
>   cancel_work_sync(>rx_alloc);
> - if (rba->alloc_wq) {
> - destroy_workqueue(rba->alloc_wq);
> - rba->alloc_wq = NULL;
> - }
>  
>   iwl_pcie_free_rbs_pool(trans);
>  
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c 
> b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> index f95eec52508e..3927bbf04f72 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> @@ -1786,6 +1786,11 @@ void iwl_trans_pcie_free(struct iwl_trans *trans)
>   iwl_pcie_tx_free(trans);
>   iwl_pcie_rx_free(trans);
>  
> + if (trans_pcie->rba.alloc_wq) {
> + destroy_workqueue(trans_pcie->rba.alloc_wq);
> + trans_pcie->rba.alloc_wq = NULL;
> + }
> +
>   if (trans_pcie->msix_enabled) {
>   for (i = 0; i < trans_pcie-

Re: [PATCH v2] iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc()

[David Weinehall]

On Tue, Aug 22, 2017 at 10:37:29AM +0300, Luca Coelho wrote:
> From: Luca Coelho 
> 
> Work queues cannot be allocated when a mutex is held because the mutex
> may be in use and that would make it sleep.  Doing so generates the
> following splat with 4.13+:
> 
> [   19.513298] ==
> [   19.513429] WARNING: possible circular locking dependency detected
> [   19.513557] 4.13.0-rc5+ #6 Not tainted
> [   19.513638] --
> [   19.513767] cpuhp/0/12 is trying to acquire lock:
> [   19.513867]  (>lock){+.+.+.}, at: [] 
> thermal_zone_get_temp+0x5b/0xb0
> [   19.514047]
> [   19.514047] but task is already holding lock:
> [   19.514166]  (cpuhp_state){+.+.+.}, at: [] 
> cpuhp_thread_fun+0x3a/0x210
> [   19.514338]
> [   19.514338] which lock already depends on the new lock.
> 
> This lock dependency already existed with previous kernel versions,
> but it was not detected until commit 49dfe2a67797 ("cpuhotplug: Link
> lock stacks for hotplug callbacks") was introduced.
> 
> Reported-by: David Weinehall 
> Reported-by: Jiri Kosina 
> Signed-off-by: Luca Coelho 

With this patch I no longer get the lockdep warning,
and the driver seems to work just as well as before.

Thanks!

Tested-by: David Weinehall 

> ---
> In v2:
>- updated the commit message to a new version, with a grammar fix
>  and the actual commit that exposed the problem;
> 
>  drivers/net/wireless/intel/iwlwifi/pcie/internal.h |  2 ++
>  drivers/net/wireless/intel/iwlwifi/pcie/rx.c   | 10 +-
>  drivers/net/wireless/intel/iwlwifi/pcie/trans.c|  9 +
>  3 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h 
> b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> index fa315d84e98e..a1ea9ef97ed9 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> @@ -787,6 +787,8 @@ int iwl_pci_fw_enter_d0i3(struct iwl_trans *trans);
>  
>  void iwl_pcie_enable_rx_wake(struct iwl_trans *trans, bool enable);
>  
> +void iwl_pcie_rx_allocator_work(struct work_struct *data);
> +
>  /* common functions that are used by gen2 transport */
>  void iwl_pcie_apm_config(struct iwl_trans *trans);
>  int iwl_pcie_prepare_card_hw(struct iwl_trans *trans);
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c 
> b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> index 351c4423125a..942736d3fa75 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -597,7 +597,7 @@ static void iwl_pcie_rx_allocator_get(struct iwl_trans 
> *trans,
>   rxq->free_count += RX_CLAIM_REQ_ALLOC;
>  }
>  
> -static void iwl_pcie_rx_allocator_work(struct work_struct *data)
> +void iwl_pcie_rx_allocator_work(struct work_struct *data)
>  {
>   struct iwl_rb_allocator *rba_p =
>   container_of(data, struct iwl_rb_allocator, rx_alloc);
> @@ -900,10 +900,6 @@ static int _iwl_pcie_rx_init(struct iwl_trans *trans)
>   return err;
>   }
>   def_rxq = trans_pcie->rxq;
> - if (!rba->alloc_wq)
> - rba->alloc_wq = alloc_workqueue("rb_allocator",
> - WQ_HIGHPRI | WQ_UNBOUND, 1);
> - INIT_WORK(>rx_alloc, iwl_pcie_rx_allocator_work);
>  
>   spin_lock(>lock);
>   atomic_set(>req_pending, 0);
> @@ -1017,10 +1013,6 @@ void iwl_pcie_rx_free(struct iwl_trans *trans)
>   }
>  
>   cancel_work_sync(>rx_alloc);
> - if (rba->alloc_wq) {
> - destroy_workqueue(rba->alloc_wq);
> - rba->alloc_wq = NULL;
> - }
>  
>   iwl_pcie_free_rbs_pool(trans);
>  
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c 
> b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> index f95eec52508e..3927bbf04f72 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> @@ -1786,6 +1786,11 @@ void iwl_trans_pcie_free(struct iwl_trans *trans)
>   iwl_pcie_tx_free(trans);
>   iwl_pcie_rx_free(trans);
>  
> + if (trans_pcie->rba.alloc_wq) {
> + destroy_workqueue(trans_pcie->rba.alloc_wq);
> + trans_pcie->rba.alloc_wq = NULL;
> + }
> +
>   if (trans_pcie->msix_enabled) {
>   for (i = 0; i < trans_pcie->alloc_vecs; i++) {
>   irq_set_affinity_hint(
> @@ -3169,6 +3174,10 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev

Re: [Intel-gfx] [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

[David Weinehall]

On Mon, Jun 26, 2017 at 04:40:08PM -0400, Lyude wrote:
> There's quite a number of machines on the market, mainly Lenovo
> ThinkPads, that make the horrible mistake in their firmware of reusing
> the PCIBAR space reserved for the SMBus for things that are completely
> unrelated to the SMBus controller, such as the OpRegion used for i915.
> This is very bad and entirely evil, but with Lenovo's historically poor
> track record of fixing their firmware, it is extremely unlikely this is
> ever going to be properly fixed.
> 
> So, while it would be nice if we could just cut off the SMBus controller
> and call it a day this unfortunately breaks RMI4 mode completely for
> most of the ThinkPads. Even though this behavior is extremely wrong, for
> whatever reason sharing the PCIBAR between the OpRegion and SMBus seems
> to be just fine. Regardless however, I think it's safe to assume that
> when the BIOS accesses the PCIBAR space of the SMBus controller like
> this that it's trying to get to something else that we mapped the SMBus
> controller over.
> 
> On my X1 Carbon, this assumption appears to be correct. I've traced down
> the firmware accesses to being caused by the firmware mistakenly placing
> the SWSCI mailbox for i915 on top of the SMBus host controller region.
> And indeed, blacklisting i915 causes the firmware to never attempt to
> touch this region.
> 
> So, in order to try to workaround this and not break either SMBus or
> i915, we temporarily unmap the PCI device for the SMBus controller,
> do the thing that the firmware wanted to do, then remap the device and
> report a firmware bug.
> 
> Signed-off-by: Lyude 
> Cc: Rafael J. Wysocki 
> Cc: Benjamin Tissoires 
> Cc: Mika Westerberg 
> Cc: Jean Delvare 
> Cc: Wolfram Sang 
> Cc: intel-...@lists.freedesktop.org
> ---
> So: unfortunately
> 
> a7ae81952cda (i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI 
> BAR)
> 
> Seems to prevent the ThinkPad X1 Carbon 4th gen and the T460s from actually
> using their SMBus controllers at all. As mentioned above, I've traced the 
> issue
> down to the firmware responding to the SWSCI by sticking data in places it
> shouldn't, e.g. the SMBus registers.
> 
> I'm entirely unsure if this patch is the correct fix for this, and wouldn't be
> at all surprised if it's just as bad of a patch as I think it is ;P. So I
> figured I'd send it to intel-gfx and the authors of the original version of 
> this
> patch to get their take on it and see if there might be something less hacky 
> we
> can do to fix this.

How does "that other" operating system handle this?

FWIW I own a ThinkPad X1 Carbon 4th Gen, so I'm happy for your work on
it :)


Kind regards, David

Re: [Intel-gfx] [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

[David Weinehall]

On Mon, Jun 26, 2017 at 04:40:08PM -0400, Lyude wrote:
> There's quite a number of machines on the market, mainly Lenovo
> ThinkPads, that make the horrible mistake in their firmware of reusing
> the PCIBAR space reserved for the SMBus for things that are completely
> unrelated to the SMBus controller, such as the OpRegion used for i915.
> This is very bad and entirely evil, but with Lenovo's historically poor
> track record of fixing their firmware, it is extremely unlikely this is
> ever going to be properly fixed.
> 
> So, while it would be nice if we could just cut off the SMBus controller
> and call it a day this unfortunately breaks RMI4 mode completely for
> most of the ThinkPads. Even though this behavior is extremely wrong, for
> whatever reason sharing the PCIBAR between the OpRegion and SMBus seems
> to be just fine. Regardless however, I think it's safe to assume that
> when the BIOS accesses the PCIBAR space of the SMBus controller like
> this that it's trying to get to something else that we mapped the SMBus
> controller over.
> 
> On my X1 Carbon, this assumption appears to be correct. I've traced down
> the firmware accesses to being caused by the firmware mistakenly placing
> the SWSCI mailbox for i915 on top of the SMBus host controller region.
> And indeed, blacklisting i915 causes the firmware to never attempt to
> touch this region.
> 
> So, in order to try to workaround this and not break either SMBus or
> i915, we temporarily unmap the PCI device for the SMBus controller,
> do the thing that the firmware wanted to do, then remap the device and
> report a firmware bug.
> 
> Signed-off-by: Lyude 
> Cc: Rafael J. Wysocki 
> Cc: Benjamin Tissoires 
> Cc: Mika Westerberg 
> Cc: Jean Delvare 
> Cc: Wolfram Sang 
> Cc: intel-...@lists.freedesktop.org
> ---
> So: unfortunately
> 
> a7ae81952cda (i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI 
> BAR)
> 
> Seems to prevent the ThinkPad X1 Carbon 4th gen and the T460s from actually
> using their SMBus controllers at all. As mentioned above, I've traced the 
> issue
> down to the firmware responding to the SWSCI by sticking data in places it
> shouldn't, e.g. the SMBus registers.
> 
> I'm entirely unsure if this patch is the correct fix for this, and wouldn't be
> at all surprised if it's just as bad of a patch as I think it is ;P. So I
> figured I'd send it to intel-gfx and the authors of the original version of 
> this
> patch to get their take on it and see if there might be something less hacky 
> we
> can do to fix this.

How does "that other" operating system handle this?

FWIW I own a ThinkPad X1 Carbon 4th Gen, so I'm happy for your work on
it :)


Kind regards, David

Re: [Intel-gfx] [REGRESSION] Black screen after switching desktop session (was: Re: Linux 4.10-rc5)

[David Weinehall]

nstance, can
take weeks or months--I haven't done a full run recently--to complete.

I hope this helps you understand why bugs can slip under the radar,
and why a bisect is so important.


Kind regards, David Weinehall

Re: [Intel-gfx] [REGRESSION] Black screen after switching desktop session (was: Re: Linux 4.10-rc5)

[David Weinehall]

nstance, can
take weeks or months--I haven't done a full run recently--to complete.

I hope this helps you understand why bugs can slip under the radar,
and why a bisect is so important.


Kind regards, David Weinehall

Re: [Intel-gfx] [PATCH v11 3/4] drm/i915: Use new CRC debugfs API

[David Weinehall]

On Mon, Nov 14, 2016 at 12:44:25PM +0200, Jani Nikula wrote:
> On Thu, 06 Oct 2016, Tomeu Vizoso  wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 23a6c7213eca..7412a05fa5d9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14636,6 +14636,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs 
> > = {
> > .page_flip = intel_crtc_page_flip,
> > .atomic_duplicate_state = intel_crtc_duplicate_state,
> > .atomic_destroy_state = intel_crtc_destroy_state,
> > +   .set_crc_source = intel_crtc_set_crc_source,
> >  };
> >  
> >  /**
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 737261b09110..31894b7c6517 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1844,6 +1844,14 @@ void intel_color_load_luts(struct drm_crtc_state 
> > *crtc_state);
> >  /* intel_pipe_crc.c */
> >  int intel_pipe_crc_create(struct drm_minor *minor);
> >  void intel_pipe_crc_cleanup(struct drm_minor *minor);
> > +#ifdef CONFIG_DEBUG_FS
> > +int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char 
> > *source_name,
> > + size_t *values_cnt);
> > +#else
> > +static inline int intel_crtc_set_crc_source(struct drm_crtc *crtc,
> > +   const char *source_name,
> > +   size_t *values_cnt) { return 0; }
> > +#endif
> 
> "inline" here doesn't work because it's used as a function pointer.
> 
> Is it better to have a function that returns 0 for .set_crc_source, or
> to set .set_crc_source to NULL when CONFIG_DEBUG_FS=n?

I'd say that whenever we have a function pointer we should have a dummy
function without side-effects for this kind of things.


Kind regards, David

Re: [Intel-gfx] [PATCH v11 3/4] drm/i915: Use new CRC debugfs API

[David Weinehall]

On Mon, Nov 14, 2016 at 12:44:25PM +0200, Jani Nikula wrote:
> On Thu, 06 Oct 2016, Tomeu Vizoso  wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 23a6c7213eca..7412a05fa5d9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14636,6 +14636,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs 
> > = {
> > .page_flip = intel_crtc_page_flip,
> > .atomic_duplicate_state = intel_crtc_duplicate_state,
> > .atomic_destroy_state = intel_crtc_destroy_state,
> > +   .set_crc_source = intel_crtc_set_crc_source,
> >  };
> >  
> >  /**
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 737261b09110..31894b7c6517 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1844,6 +1844,14 @@ void intel_color_load_luts(struct drm_crtc_state 
> > *crtc_state);
> >  /* intel_pipe_crc.c */
> >  int intel_pipe_crc_create(struct drm_minor *minor);
> >  void intel_pipe_crc_cleanup(struct drm_minor *minor);
> > +#ifdef CONFIG_DEBUG_FS
> > +int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char 
> > *source_name,
> > + size_t *values_cnt);
> > +#else
> > +static inline int intel_crtc_set_crc_source(struct drm_crtc *crtc,
> > +   const char *source_name,
> > +   size_t *values_cnt) { return 0; }
> > +#endif
> 
> "inline" here doesn't work because it's used as a function pointer.
> 
> Is it better to have a function that returns 0 for .set_crc_source, or
> to set .set_crc_source to NULL when CONFIG_DEBUG_FS=n?

I'd say that whenever we have a function pointer we should have a dummy
function without side-effects for this kind of things.


Kind regards, David

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

[David Weinehall]

On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> Weine's investigation on benchmarking the suspend/resume process pointed
> out a lot of the time in suspend/resume is being spent reprobing. While
> the reprobing process is a lengthy one for good reason, we don't need to
> hold up the entire suspend/resume process while we wait for it to
> finish. Luckily as it turns out, we already trigger a full connector
> reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> i915_drm_resume() entirely.
> 
> This won't lead to less time spent resuming just yet since now the
> bottleneck will be waiting for the mode_config lock in
> drm_kms_helper_poll_enable(), since that will be held as long as
> i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> address that in the next patch.
> 
> Signed-off-by: Lyude <ly...@redhat.com>
> Cc: David Weinehall <david.weineh...@linux.intel.com>

Tested-by: David Weinehall <david.weineh...@linux.intel.com>
Reviewed-by: David Weinehall <david.weineh...@linux.intel.com>
Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index bfb2efd..532cc0f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
>* notifications.
>* */
>   intel_hpd_init(dev_priv);
> - /* Config may have changed between suspend and resume */
> - drm_helper_hpd_irq_event(dev);
>  
>   intel_opregion_register(dev_priv);
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

[David Weinehall]

On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> Weine's investigation on benchmarking the suspend/resume process pointed
> out a lot of the time in suspend/resume is being spent reprobing. While
> the reprobing process is a lengthy one for good reason, we don't need to
> hold up the entire suspend/resume process while we wait for it to
> finish. Luckily as it turns out, we already trigger a full connector
> reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> i915_drm_resume() entirely.
> 
> This won't lead to less time spent resuming just yet since now the
> bottleneck will be waiting for the mode_config lock in
> drm_kms_helper_poll_enable(), since that will be held as long as
> i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> address that in the next patch.
> 
> Signed-off-by: Lyude 
> Cc: David Weinehall 

Tested-by: David Weinehall 
Reviewed-by: David Weinehall 
Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index bfb2efd..532cc0f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
>* notifications.
>* */
>   intel_hpd_init(dev_priv);
> - /* Config may have changed between suspend and resume */
> - drm_helper_hpd_irq_event(dev);
>  
>   intel_opregion_register(dev_priv);
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reinit polling before hpd when resuming

[David Weinehall]

On Thu, Nov 03, 2016 at 11:42:38AM -0400, Lyude wrote:
> Now that we don't run the connector reprobing from i915_drm_resume(), we
> need to make it so we don't have to wait for reprobing to finish so that
> we actually speed things up. In order to do this, we need to make sure
> that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work()
> while trying to acquire the mode_config lock that
> drm_kms_helper_poll_enable() needs to acquire.
> 
> The easiest way to do this is to just enable polling before hpd. This
> shouldn't break anything since at that point we have everything else we
> need for polling enabled.
> 
> As well, this should result in a rather significant improvement in how
> quickly we can resume the system.
> 
> Signed-off-by: Lyude <ly...@redhat.com>
> Cc: David Weinehall <david.weineh...@linux.intel.com>

Tested-by: David Weinehall <david.weineh...@linux.intel.com>
Reviewed-by: David Weinehall <david.weineh...@linux.intel.com>
Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 532cc0f..f605dde 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1595,6 +1595,8 @@ static int i915_drm_resume(struct drm_device *dev)
>  
>   intel_display_resume(dev);
>  
> + drm_kms_helper_poll_enable(dev);
> +
>   /*
>* ... but also need to make sure that hotplug processing
>* doesn't cause havoc. Like in the driver load code we don't
> @@ -1614,7 +1616,6 @@ static int i915_drm_resume(struct drm_device *dev)
>   intel_opregion_notify_adapter(dev_priv, PCI_D0);
>  
>   intel_autoenable_gt_powersave(dev_priv);
> - drm_kms_helper_poll_enable(dev);
>  
>   enable_rpm_wakeref_asserts(dev_priv);
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reinit polling before hpd when resuming

[David Weinehall]

On Thu, Nov 03, 2016 at 11:42:38AM -0400, Lyude wrote:
> Now that we don't run the connector reprobing from i915_drm_resume(), we
> need to make it so we don't have to wait for reprobing to finish so that
> we actually speed things up. In order to do this, we need to make sure
> that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work()
> while trying to acquire the mode_config lock that
> drm_kms_helper_poll_enable() needs to acquire.
> 
> The easiest way to do this is to just enable polling before hpd. This
> shouldn't break anything since at that point we have everything else we
> need for polling enabled.
> 
> As well, this should result in a rather significant improvement in how
> quickly we can resume the system.
> 
> Signed-off-by: Lyude 
> Cc: David Weinehall 

Tested-by: David Weinehall 
Reviewed-by: David Weinehall 
Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 532cc0f..f605dde 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1595,6 +1595,8 @@ static int i915_drm_resume(struct drm_device *dev)
>  
>   intel_display_resume(dev);
>  
> + drm_kms_helper_poll_enable(dev);
> +
>   /*
>* ... but also need to make sure that hotplug processing
>* doesn't cause havoc. Like in the driver load code we don't
> @@ -1614,7 +1616,6 @@ static int i915_drm_resume(struct drm_device *dev)
>   intel_opregion_notify_adapter(dev_priv, PCI_D0);
>  
>   intel_autoenable_gt_powersave(dev_priv);
> - drm_kms_helper_poll_enable(dev);
>  
>   enable_rpm_wakeref_asserts(dev_priv);
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate

[David Weinehall]

On Fri, Feb 27, 2015 at 08:23:41PM +0200, Imre Deak wrote:
> We've checked today with Ville a few machines we've found from GEN2 to
> GEN5+. There was one Thinkpad x61s (GEN4) where I could reproduce the
> exact same problem and get rid of it using the same workaround. All the
> others were non-Lenovo (including GEN4) mobile and desktop platforms and
> none of these had the problem. I also tried it on a Lenovo IVB
> ultrabook, which also works fine. So the current theory is that it's
> related to GEN4 Thinkpad BIOSes, and so we need to change the condition
> to match that at least.

If you need more ThinkPads to test with I have a few at home :)


Kind regards, David
--
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: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate

[David Weinehall]

On Fri, Feb 27, 2015 at 08:23:41PM +0200, Imre Deak wrote:
 We've checked today with Ville a few machines we've found from GEN2 to
 GEN5+. There was one Thinkpad x61s (GEN4) where I could reproduce the
 exact same problem and get rid of it using the same workaround. All the
 others were non-Lenovo (including GEN4) mobile and desktop platforms and
 none of these had the problem. I also tried it on a Lenovo IVB
 ultrabook, which also works fine. So the current theory is that it's
 related to GEN4 Thinkpad BIOSes, and so we need to change the condition
 to match that at least.

If you need more ThinkPads to test with I have a few at home :)


Kind regards, David
--
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: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate

[David Weinehall]

On Thu, Feb 26, 2015 at 09:01:27PM +0100, Daniel Vetter wrote:
> On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote:

[snip]
> > 
> > The problem seems to be that after the kernel puts the device into D3
> > the BIOS still tries to access it, or otherwise assumes that it's in D0.
> > This is clearly bogus, since ACPI mandates that devices are put into D3
> > by the OSPM if they are not wake-up sources. In the future we want to
> > unify more of the driver's runtime and system suspend paths, for example
> > by skipping all the system suspend/hibernation hooks if the device is
> > runtime suspended already. Accordingly for all other platforms the goal
> > is still to properly power down the device during hibernation.

[snip]
> 
> If we see more of these troublesome machines we might need to apply an
> even bigger hammer like gen < 5 or so. But as long as there's just 1
> report I think this is the right approach.
> 
> Bjorn, as soon as we have your tested-by that this work we can apply this
> and shovel it through the backporting machinery.

Isn't there a risk that this will negatively impact machines using gen4
that *don't* have a buggy BIOS?  Wouldn't a quirk tied to the laptop
or BIOS version be better suited -- or possibly a parameter that can be
passed to the driver, which would make it easier to test if others
suffering from similar symptoms on other systems suffer from the same
issue or not?

Just my 2¢.


Kind regards, David Weinehall
--
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: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate

[David Weinehall]

On Thu, Feb 26, 2015 at 09:01:27PM +0100, Daniel Vetter wrote:
 On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote:

[snip]
  
  The problem seems to be that after the kernel puts the device into D3
  the BIOS still tries to access it, or otherwise assumes that it's in D0.
  This is clearly bogus, since ACPI mandates that devices are put into D3
  by the OSPM if they are not wake-up sources. In the future we want to
  unify more of the driver's runtime and system suspend paths, for example
  by skipping all the system suspend/hibernation hooks if the device is
  runtime suspended already. Accordingly for all other platforms the goal
  is still to properly power down the device during hibernation.

[snip]
 
 If we see more of these troublesome machines we might need to apply an
 even bigger hammer like gen  5 or so. But as long as there's just 1
 report I think this is the right approach.
 
 Bjorn, as soon as we have your tested-by that this work we can apply this
 and shovel it through the backporting machinery.

Isn't there a risk that this will negatively impact machines using gen4
that *don't* have a buggy BIOS?  Wouldn't a quirk tied to the laptop
or BIOS version be better suited -- or possibly a parameter that can be
passed to the driver, which would make it easier to test if others
suffering from similar symptoms on other systems suffer from the same
issue or not?

Just my 2¢.


Kind regards, David Weinehall
--
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: Linux 2.6.23-rc2

[David Weinehall]

On Sun, Aug 05, 2007 at 07:52:07PM +0800, Jeff Chua wrote:
> On 8/5/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> 
> > Okay, since you're using VGA console this means suspend-to-ram isn't
> > restoring the mode.
> > Does it matter if you suspend from inside X or not?
> 
> Just tested it. It doesn't matter... text console still messed up. X
> is ok after resume.

Try adding acpi_sleep=s3_bios to your kernel boot options and see if it
helps.


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.23-rc2

[David Weinehall]

On Sun, Aug 05, 2007 at 07:52:07PM +0800, Jeff Chua wrote:
 On 8/5/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
 
  Okay, since you're using VGA console this means suspend-to-ram isn't
  restoring the mode.
  Does it matter if you suspend from inside X or not?
 
 Just tested it. It doesn't matter... text console still messed up. X
 is ok after resume.

Try adding acpi_sleep=s3_bios to your kernel boot options and see if it
helps.


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] LogFS take three

[David Weinehall]

On Wed, May 16, 2007 at 03:53:19PM +0200, Jörn Engel wrote:
> On Wed, 16 May 2007 09:41:10 -0400, John Stoffel wrote:
> > Jörn> On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote:
> > 
> > Jörn> How many of you have worked for IBM before?  Vowels are not
> > evil. ;)
> > 
> > Nope, they're not.  I just think that LogFS isn't descriptive enough,
> > or more accurately, is the *wrong* description of this filesystem.  
> 
> That was the whole point.  JFFS2, the journaling flash filesystem, is a
> strictly log-structured filesystem.  LogFS has a journal.
> 
> It is also the filesystem that tries to scale logarithmically, as Arnd
> has noted.  Maybe I should call it Log2 to emphesize this point.  Log1
> would be horrible scalability.

So, log2fs...  Sounds great to me.

[snip]


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] LogFS take three

[David Weinehall]

On Wed, May 16, 2007 at 03:53:19PM +0200, Jörn Engel wrote:
 On Wed, 16 May 2007 09:41:10 -0400, John Stoffel wrote:
  Jörn On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote:
  
  Jörn How many of you have worked for IBM before?  Vowels are not
  evil. ;)
  
  Nope, they're not.  I just think that LogFS isn't descriptive enough,
  or more accurately, is the *wrong* description of this filesystem.  
 
 That was the whole point.  JFFS2, the journaling flash filesystem, is a
 strictly log-structured filesystem.  LogFS has a journal.
 
 It is also the filesystem that tries to scale logarithmically, as Arnd
 has noted.  Maybe I should call it Log2 to emphesize this point.  Log1
 would be horrible scalability.

So, log2fs...  Sounds great to me.

[snip]


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scripts/makelst: bc -> shell Re: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[David Weinehall]

On Sat, Jan 27, 2007 at 06:38:36AM +, Oleg Verych wrote:
[snip]
> ,-*- diff snip -*-
> |-t4=`echo $t3 | gawk '{ print $1 }'`
> |-t5=`echo $t1 | gawk '{ print $1 }'`
> |+t4=`pos_param 1 $t3`
> |+t5=`pos_param 1 $t1`
> 5 t6=`echo $t4 - $t5 | tr a-f A-F`
> 6 t7=`( echo  ibase=16 ; echo $t6 ) | bc`
> `-*-
> 
> I've just noticed, that things on lines 5 and 6 may be optimized.
> 
> t7=`printf "%lu" $(( 0x$t4 - 0x$t5 ))`

%lu does not seem to agree with SuSv3:

http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap05.html

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[David Weinehall]

On Thu, Jan 25, 2007 at 07:14:07PM +, Oleg Verych wrote:
> On Thu, Jan 25, 2007 at 01:03:32PM -0500, Rob Landley wrote:
> > On Thursday 25 January 2007 4:40 am, Oleg Verych wrote:
> > > > Your objection is a bit like saying "and don't use cat".  I'm saying 
> > > > don't 
> > > > call cat "gcat" when you just mean plain old cat.
> > > 
> > > No it's not, really. I don't want to see pipes, fork()s, disk seek,
> > > when task can be done without it. I know, what awk is, and i hope it
> > > will have its better time.
> > 
> > *shrug*  Making the need for "gawk" go away was my goal, and gawk->awk was 
> > the 
> > minimal change.  If you want more than that, I'm not objecting, just not 
> > personally interested.
> 
> Yes making uclibc as a bit more work, than rename things ;D. And my
> change is mainly from optimization point of view (say modern embedded ;)
> 
> > I believe "shift 5" is also SUSv3. :)
> 
> If you have tested, please send ack or nack to us.

Yes, shift [n] is available in SuSv3:

http://www.opengroup.org/onlinepubs/009695399/utilities/shift.html


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[David Weinehall]

On Thu, Jan 25, 2007 at 07:14:07PM +, Oleg Verych wrote:
 On Thu, Jan 25, 2007 at 01:03:32PM -0500, Rob Landley wrote:
  On Thursday 25 January 2007 4:40 am, Oleg Verych wrote:
Your objection is a bit like saying and don't use cat.  I'm saying 
don't 
call cat gcat when you just mean plain old cat.
   
   No it's not, really. I don't want to see pipes, fork()s, disk seek,
   when task can be done without it. I know, what awk is, and i hope it
   will have its better time.
  
  *shrug*  Making the need for gawk go away was my goal, and gawk-awk was 
  the 
  minimal change.  If you want more than that, I'm not objecting, just not 
  personally interested.
 
 Yes making uclibc as a bit more work, than rename things ;D. And my
 change is mainly from optimization point of view (say modern embedded ;)
 
  I believe shift 5 is also SUSv3. :)
 
 If you have tested, please send ack or nack to us.

Yes, shift [n] is available in SuSv3:

http://www.opengroup.org/onlinepubs/009695399/utilities/shift.html


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scripts/makelst: bc - shell Re: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[David Weinehall]

On Sat, Jan 27, 2007 at 06:38:36AM +, Oleg Verych wrote:
[snip]
 ,-*- diff snip -*-
 |-t4=`echo $t3 | gawk '{ print $1 }'`
 |-t5=`echo $t1 | gawk '{ print $1 }'`
 |+t4=`pos_param 1 $t3`
 |+t5=`pos_param 1 $t1`
 5 t6=`echo $t4 - $t5 | tr a-f A-F`
 6 t7=`( echo  ibase=16 ; echo $t6 ) | bc`
 `-*-
 
 I've just noticed, that things on lines 5 and 6 may be optimized.
 
 t7=`printf %lu $(( 0x$t4 - 0x$t5 ))`

%lu does not seem to agree with SuSv3:

http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap05.html

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Open letter to Linux kernel developers (was Re: Binary Drivers)

[David Weinehall]

On Tue, Jan 02, 2007 at 06:13:46PM +0100, Jan Engelhardt wrote:
> 
> On Jan 2 2007 16:15, David Weinehall wrote:
> >On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> >> On Tue, 2 Jan 2007, Theodore Tso wrote:
> >> 
> >> 1) mcdonald's was not merely serving their coffee "hot," but
> >> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> >> will produce third-degree burns almost immediately, and
> >
> >That's less than 90°C.
> [1]
> 
> >Water boils at 100°C.  How the hell do 
> >people expect coffee to be made without boiling water?  Magic?
> 
> Boil or not - I've done a test some years ago with some friend
> arguing about what the best temperature for tea is. Result of an
> experiment involving actual temperature sensors: my default tea is 40
> deg celsius. Theirs was about 60. And to note, drinking 60 deg water
> already starts to scald my tongue slightly so that it 'itches' for a
> while. So nothing[1] is unreasonable.

For tea, you're not supposed to boil the water, only let it seethe, as
far as I know.  But yes, drinking scalding hot beverages is quite
stupid.  I'm not arguing against that.  But not realising that something
you need to at the very least seethe to prepare might be hot when served
is showing total ignorance.

> >> 2) there had, for a decade prior, been some *700* cases where people
> >> had burned themselves with mcdonald's coffee, so it's not as if
> >> mcdonald's was unaware of the danger, yet continued to ignore it.
> >
> >No, the customers continued to prove to be total morons by total
> >ignorance of the fact that coffee *is* hot when fresh.  If they
> >cannot handle hot coffee, they can order ice coffee or ask for a
> >refill of their cola.
> 
> Reminds me of http://qdb.us/4753

Sounds quite reasonable.  Things have gone too far when there are
warnings about even the most obvious things.


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Open letter to Linux kernel developers (was Re: Binary Drivers)

[David Weinehall]

On Tue, Jan 02, 2007 at 07:44:24PM +0100, Bodo Eggert wrote:
> David Weinehall <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> 
> >> 1) mcdonald's was not merely serving their coffee "hot," but
> >> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> >> will produce third-degree burns almost immediately, and
> > 
> > That's less than 90°C.  Water boils at 100°C.  How the hell do
> > people expect coffee to be made without boiling water?  Magic?
> 
> The recommendet _serving_ temperature for coffe is 55 °C or below.
> 
> >> 2) there had, for a decade prior, been some *700* cases where people
> >> had burned themselves with mcdonald's coffee, so it's not as if
> >> mcdonald's was unaware of the danger, yet continued to ignore it.
> > 
> > No, the customers continued to prove to be total morons by total
> > ignorance of the fact that coffee *is* hot when fresh.
> 
> So everybody at McDrive should wait for five minutes to let it cool down.

Don't drink and drive just got another application =)


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Open letter to Linux kernel developers (was Re: Binary Drivers)

[David Weinehall]

On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> On Tue, 2 Jan 2007, Theodore Tso wrote:
> 
> > I can very easily believe it.  The US patent system and "justice"
> > system in the US is completely and totally insane, and companies
> > often feel they have to act accordingly.  Remember this is the
> > country that has issued multi-million dollar awards to people who
> > spill hot coffee in their lap ...
> 
> MASSIVELY OFF TOPIC:  can we please stop using this "hot coffee in
> lap" story as an example of the idiocy of the justice system?  i'm
> guessing there's more to this story than most folks are aware of, and
> you're welcome to read the details here:
> 
>   http://www.lectlaw.com/files/cur78.htm
> 
> as you can see, there are two salient points that change the
> complexion of this story thoroughly:
> 
> 1) mcdonald's was not merely serving their coffee "hot," but
> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> will produce third-degree burns almost immediately, and

That's less than 90°C.  Water boils at 100°C.  How the hell do 
people expect coffee to be made without boiling water?  Magic?

> 2) there had, for a decade prior, been some *700* cases where people
> had burned themselves with mcdonald's coffee, so it's not as if
> mcdonald's was unaware of the danger, yet continued to ignore it.

No, the customers continued to prove to be total morons by total
ignorance of the fact that coffee *is* hot when fresh.  If they
cannot handle hot coffee, they can order ice coffee or ask for a refill
of their cola.

[snip]


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Open letter to Linux kernel developers (was Re: Binary Drivers)

[David Weinehall]

On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
 On Tue, 2 Jan 2007, Theodore Tso wrote:
 
  I can very easily believe it.  The US patent system and justice
  system in the US is completely and totally insane, and companies
  often feel they have to act accordingly.  Remember this is the
  country that has issued multi-million dollar awards to people who
  spill hot coffee in their lap ...
 
 MASSIVELY OFF TOPIC:  can we please stop using this hot coffee in
 lap story as an example of the idiocy of the justice system?  i'm
 guessing there's more to this story than most folks are aware of, and
 you're welcome to read the details here:
 
   http://www.lectlaw.com/files/cur78.htm
 
 as you can see, there are two salient points that change the
 complexion of this story thoroughly:
 
 1) mcdonald's was not merely serving their coffee hot, but
 *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
 will produce third-degree burns almost immediately, and

That's less than 90°C.  Water boils at 100°C.  How the hell do 
people expect coffee to be made without boiling water?  Magic?

 2) there had, for a decade prior, been some *700* cases where people
 had burned themselves with mcdonald's coffee, so it's not as if
 mcdonald's was unaware of the danger, yet continued to ignore it.

No, the customers continued to prove to be total morons by total
ignorance of the fact that coffee *is* hot when fresh.  If they
cannot handle hot coffee, they can order ice coffee or ask for a refill
of their cola.

[snip]


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Open letter to Linux kernel developers (was Re: Binary Drivers)

[David Weinehall]

On Tue, Jan 02, 2007 at 07:44:24PM +0100, Bodo Eggert wrote:
 David Weinehall [EMAIL PROTECTED] wrote:
  On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
 
  1) mcdonald's was not merely serving their coffee hot, but
  *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
  will produce third-degree burns almost immediately, and
  
  That's less than 90°C.  Water boils at 100°C.  How the hell do
  people expect coffee to be made without boiling water?  Magic?
 
 The recommendet _serving_ temperature for coffe is 55 °C or below.
 
  2) there had, for a decade prior, been some *700* cases where people
  had burned themselves with mcdonald's coffee, so it's not as if
  mcdonald's was unaware of the danger, yet continued to ignore it.
  
  No, the customers continued to prove to be total morons by total
  ignorance of the fact that coffee *is* hot when fresh.
 
 So everybody at McDrive should wait for five minutes to let it cool down.

Don't drink and drive just got another application =)


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Open letter to Linux kernel developers (was Re: Binary Drivers)

[David Weinehall]

On Tue, Jan 02, 2007 at 06:13:46PM +0100, Jan Engelhardt wrote:
 
 On Jan 2 2007 16:15, David Weinehall wrote:
 On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
  On Tue, 2 Jan 2007, Theodore Tso wrote:
  
  1) mcdonald's was not merely serving their coffee hot, but
  *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
  will produce third-degree burns almost immediately, and
 
 That's less than 90°C.
 [1]
 
 Water boils at 100°C.  How the hell do 
 people expect coffee to be made without boiling water?  Magic?
 
 Boil or not - I've done a test some years ago with some friend
 arguing about what the best temperature for tea is. Result of an
 experiment involving actual temperature sensors: my default tea is 40
 deg celsius. Theirs was about 60. And to note, drinking 60 deg water
 already starts to scald my tongue slightly so that it 'itches' for a
 while. So nothing[1] is unreasonable.

For tea, you're not supposed to boil the water, only let it seethe, as
far as I know.  But yes, drinking scalding hot beverages is quite
stupid.  I'm not arguing against that.  But not realising that something
you need to at the very least seethe to prepare might be hot when served
is showing total ignorance.

  2) there had, for a decade prior, been some *700* cases where people
  had burned themselves with mcdonald's coffee, so it's not as if
  mcdonald's was unaware of the danger, yet continued to ignore it.
 
 No, the customers continued to prove to be total morons by total
 ignorance of the fact that coffee *is* hot when fresh.  If they
 cannot handle hot coffee, they can order ice coffee or ask for a
 refill of their cola.
 
 Reminds me of http://qdb.us/4753

Sounds quite reasonable.  Things have gone too far when there are
warnings about even the most obvious things.


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Open letter to Linux kernel developers (was Re: Binary Drivers)

[David Weinehall]

On Mon, Jan 01, 2007 at 11:04:49PM -0500, [EMAIL PROTECTED] wrote:
> On Sun, 31 Dec 2006 23:03:27 +1000, Trent Waddington said:
> > Why don't you release source?  To protect the intellectual property.
> > Well, duh!  That's why everyone holds back source.  So allow me to
> > translate..
> > 
> > Why don't you release source?  Because we don't believe in freedom, we
> > don't "get it" and we don't want you to have it.
> 
> There's believing in freedom, and there's wanting to be able to ship code
> without getting sued...
> 
> The binary blob in question is several megabytes in size.  Now, even
> totally *ignoring* who knowingly licensed/stole/whatever IP from who,
> that *still* leaves the problem of trying to write several megabytes of
> code that doesn't infringe on anybody's IP - particularly some of those
> vague submarine patents that should have been killed on "prior art" or
> "obviousness" grounds.

You know, not releasing source code doesn't  make "IP" violations
magically disappear, so if anything you should be more suspicious about
closed source drivers infringing others patents than anything.

> So tell me - how *do* you release that much code without worrying about IP
> issues?

If you have to worry about "IP", you're screwed no matter if you release
source or not.  The only problem is that it might be trickier for the
other party to prove.  The only case where a closed source driver makes
some kind of sense from an "IP" point of view is when you're trying to
protect your own code (or code you have licensed).

> Remember - somebody *can* "get it" but be unable to actually *deploy*.
> I *get* the whole global warming thing - but I'm not in a position to buy
> a hybrid car unless somebody else kicks in US$15K or $20K or so.

Well, you can always make a contribution by using public transportation
or switching to low energy light bulbs.  Every little thing counts =)


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Open letter to Linux kernel developers (was Re: Binary Drivers)

[David Weinehall]

On Mon, Jan 01, 2007 at 11:04:49PM -0500, [EMAIL PROTECTED] wrote:
 On Sun, 31 Dec 2006 23:03:27 +1000, Trent Waddington said:
  Why don't you release source?  To protect the intellectual property.
  Well, duh!  That's why everyone holds back source.  So allow me to
  translate..
  
  Why don't you release source?  Because we don't believe in freedom, we
  don't get it and we don't want you to have it.
 
 There's believing in freedom, and there's wanting to be able to ship code
 without getting sued...
 
 The binary blob in question is several megabytes in size.  Now, even
 totally *ignoring* who knowingly licensed/stole/whatever IP from who,
 that *still* leaves the problem of trying to write several megabytes of
 code that doesn't infringe on anybody's IP - particularly some of those
 vague submarine patents that should have been killed on prior art or
 obviousness grounds.

You know, not releasing source code doesn't  make IP violations
magically disappear, so if anything you should be more suspicious about
closed source drivers infringing others patents than anything.

 So tell me - how *do* you release that much code without worrying about IP
 issues?

If you have to worry about IP, you're screwed no matter if you release
source or not.  The only problem is that it might be trickier for the
other party to prove.  The only case where a closed source driver makes
some kind of sense from an IP point of view is when you're trying to
protect your own code (or code you have licensed).

 Remember - somebody *can* get it but be unable to actually *deploy*.
 I *get* the whole global warming thing - but I'm not in a position to buy
 a hybrid car unless somebody else kicks in US$15K or $20K or so.

Well, you can always make a contribution by using public transportation
or switching to low energy light bulbs.  Every little thing counts =)


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFC] Delete JFFS (version 1)

[David Weinehall]

On Tue, Dec 12, 2006 at 05:28:43PM +, Alan wrote:
> On Tue, 12 Dec 2006 12:01:25 -0500
> Bill Nottingham <[EMAIL PROTECTED]> wrote:
> 
> > Jeff Garzik ([EMAIL PROTECTED]) said: 
> > > It's always been the case that we remove Linux kernel code when the 
> > > number of users (and more importantly, developers) drops to near-nil.
> > 
> > So, drivers/net/3c501.c?
> 
> I think 3c501.c is a case where putting in an "If you use this email ..
> or it will go away" might be a good idea indeed.

Maybe even: "the people who are using 3c501's - please chime up and we'll
donate better cards to you."

After all, 3c501 is one of the crappier pieces of network cards,
I feel sorry for the people using them...


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFC] Delete JFFS (version 1)

[David Weinehall]

On Tue, Dec 12, 2006 at 05:28:43PM +, Alan wrote:
 On Tue, 12 Dec 2006 12:01:25 -0500
 Bill Nottingham [EMAIL PROTECTED] wrote:
 
  Jeff Garzik ([EMAIL PROTECTED]) said: 
   It's always been the case that we remove Linux kernel code when the 
   number of users (and more importantly, developers) drops to near-nil.
  
  So, drivers/net/3c501.c?
 
 I think 3c501.c is a case where putting in an If you use this email ..
 or it will go away might be a good idea indeed.

Maybe even: the people who are using 3c501's - please chime up and we'll
donate better cards to you.

After all, 3c501 is one of the crappier pieces of network cards,
I feel sorry for the people using them...


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFC] CodingStyle updates

[David Weinehall]

On Thu, Dec 07, 2006 at 12:48:38AM -0800, Randy Dunlap wrote:

[snip]

> +but no space after unary operators:
> + sizeof  ++  --  &  *  +  -  ~  !  defined

Uhm, that doesn't compute...  If you don't put a space after sizeof,
the program won't compile.

int c;
printf("%d", sizeofc);

Options are:

sizeof c
sizeof(c)

or

sizeof (c)

If you take sizeof the type rather than the variable, the options are

sizeof(int)

or

sizeof (int)

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFC] CodingStyle updates

[David Weinehall]

On Thu, Dec 07, 2006 at 12:48:38AM -0800, Randy Dunlap wrote:

[snip]

 +but no space after unary operators:
 + sizeof  ++  --*  +  -  ~  !  defined

Uhm, that doesn't compute...  If you don't put a space after sizeof,
the program won't compile.

int c;
printf(%d, sizeofc);

Options are:

sizeof c
sizeof(c)

or

sizeof (c)

If you take sizeof the type rather than the variable, the options are

sizeof(int)

or

sizeof (int)

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mass-storage problems with Archos AV500

[David Weinehall]

On Fri, Dec 01, 2006 at 06:32:25AM -0800, Pete Zaitcev wrote:
> On Wed, 29 Nov 2006 22:47:36 +0100, David Weinehall <[EMAIL PROTECTED]> wrote:
> 
> > I've got an Archos AV500 here (running the very latest firmware), pretty
> > much acting as a doorstop, since I cannot get it to be recognized
> > properly by Linux.
> >[...]
> > [  118.144000] SCSI device sdb: 58074975 512-byte hdwr sectors (29734
> > MB)
> > [  118.144000] sdb: Write Protect is off
> > [  118.144000] sdb: Mode Sense: 33 00 00 00
> > [  118.144000] sdb: assuming drive cache: write through
> > [  118.144000]  sdb: unknown partition table
> > [  118.452000] sd 4:0:0:0: Attached scsi removable disk sdb
> 
> It seems to be working just fine. What does parted say about it?

In the end it turned out not even Windows recognized the filesystem.
Reformatting solved the issue.  Sorry for the false alarm.


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mass-storage problems with Archos AV500

[David Weinehall]

On Fri, Dec 01, 2006 at 06:32:25AM -0800, Pete Zaitcev wrote:
 On Wed, 29 Nov 2006 22:47:36 +0100, David Weinehall [EMAIL PROTECTED] wrote:
 
  I've got an Archos AV500 here (running the very latest firmware), pretty
  much acting as a doorstop, since I cannot get it to be recognized
  properly by Linux.
 [...]
  [  118.144000] SCSI device sdb: 58074975 512-byte hdwr sectors (29734
  MB)
  [  118.144000] sdb: Write Protect is off
  [  118.144000] sdb: Mode Sense: 33 00 00 00
  [  118.144000] sdb: assuming drive cache: write through
  [  118.144000]  sdb: unknown partition table
  [  118.452000] sd 4:0:0:0: Attached scsi removable disk sdb
 
 It seems to be working just fine. What does parted say about it?

In the end it turned out not even Windows recognized the filesystem.
Reformatting solved the issue.  Sorry for the false alarm.


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mass-storage problems with Archos AV500

[David Weinehall]

On Thu, Nov 30, 2006 at 10:50:20AM +0100, Jan Dittmer wrote:
> David Weinehall wrote:
> >On Wed, Nov 29, 2006 at 10:35:29PM -0600, Robert Hancock wrote:
> >>David Weinehall wrote:
> >>>I've got an Archos AV500 here (running the very latest firmware), pretty
> >>>much acting as a doorstop, since I cannot get it to be recognized
> >>>properly by Linux.
> >>..
> >>
> >>>[  118.144000] SCSI device sdb: 58074975 512-byte hdwr sectors (29734
> >>>MB)
> >>>[  118.144000] sdb: Write Protect is off
> >>>[  118.144000] sdb: Mode Sense: 33 00 00 00
> >>>[  118.144000] sdb: assuming drive cache: write through
> >>>[  118.144000]  sdb: unknown partition table
> >>>[  118.452000] sd 4:0:0:0: Attached scsi removable disk sdb
> >>>[  118.452000] usb-storage: device scan complete
> >>>
> >>>This is with linux-image-2.6.19-7-generic 2.6.19-7.10 from Ubuntu edgy.
> >>>I get similar results with a home-brew 2.6.18-rc4.
> >>>
> >>>Any mass storage quirk needed that might be missing?
> >>That all seems normal, other than the unknown partition table, but the 
> >>device might be all one unpartitioned disk.. at what point is it failing?
> >
> >Mounting it just claims wrong FS type.  And I've tried most file systems
> >I can think of just to be sure.
> 
> Can you read the whole volume with 'dd'? If yes, you could provide
> a hex dump of the first few sectors? Probably someone on this list will
> recognize the format...

I did this and looked into the image myself.  It definitely looks like a
FAT32 image.

I've made the first MB available here:

http://www.acc.umu.se/~tao/transfer/archos.img.bz2


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mass-storage problems with Archos AV500

[David Weinehall]

On Wed, Nov 29, 2006 at 10:35:29PM -0600, Robert Hancock wrote:
> David Weinehall wrote:
> >I've got an Archos AV500 here (running the very latest firmware), pretty
> >much acting as a doorstop, since I cannot get it to be recognized
> >properly by Linux.
> 
> ..
> 
> >[  118.144000] SCSI device sdb: 58074975 512-byte hdwr sectors (29734
> >MB)
> >[  118.144000] sdb: Write Protect is off
> >[  118.144000] sdb: Mode Sense: 33 00 00 00
> >[  118.144000] sdb: assuming drive cache: write through
> >[  118.144000]  sdb: unknown partition table
> >[  118.452000] sd 4:0:0:0: Attached scsi removable disk sdb
> >[  118.452000] usb-storage: device scan complete
> >
> >This is with linux-image-2.6.19-7-generic 2.6.19-7.10 from Ubuntu edgy.
> >I get similar results with a home-brew 2.6.18-rc4.
> >
> >Any mass storage quirk needed that might be missing?
> 
> That all seems normal, other than the unknown partition table, but the 
> device might be all one unpartitioned disk.. at what point is it failing?

Mounting it just claims wrong FS type.  And I've tried most file systems
I can think of just to be sure.


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mass-storage problems with Archos AV500

[David Weinehall]

On Wed, Nov 29, 2006 at 10:35:29PM -0600, Robert Hancock wrote:
 David Weinehall wrote:
 I've got an Archos AV500 here (running the very latest firmware), pretty
 much acting as a doorstop, since I cannot get it to be recognized
 properly by Linux.
 
 ..
 
 [  118.144000] SCSI device sdb: 58074975 512-byte hdwr sectors (29734
 MB)
 [  118.144000] sdb: Write Protect is off
 [  118.144000] sdb: Mode Sense: 33 00 00 00
 [  118.144000] sdb: assuming drive cache: write through
 [  118.144000]  sdb: unknown partition table
 [  118.452000] sd 4:0:0:0: Attached scsi removable disk sdb
 [  118.452000] usb-storage: device scan complete
 
 This is with linux-image-2.6.19-7-generic 2.6.19-7.10 from Ubuntu edgy.
 I get similar results with a home-brew 2.6.18-rc4.
 
 Any mass storage quirk needed that might be missing?
 
 That all seems normal, other than the unknown partition table, but the 
 device might be all one unpartitioned disk.. at what point is it failing?

Mounting it just claims wrong FS type.  And I've tried most file systems
I can think of just to be sure.


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mass-storage problems with Archos AV500

[David Weinehall]

On Thu, Nov 30, 2006 at 10:50:20AM +0100, Jan Dittmer wrote:
 David Weinehall wrote:
 On Wed, Nov 29, 2006 at 10:35:29PM -0600, Robert Hancock wrote:
 David Weinehall wrote:
 I've got an Archos AV500 here (running the very latest firmware), pretty
 much acting as a doorstop, since I cannot get it to be recognized
 properly by Linux.
 ..
 
 [  118.144000] SCSI device sdb: 58074975 512-byte hdwr sectors (29734
 MB)
 [  118.144000] sdb: Write Protect is off
 [  118.144000] sdb: Mode Sense: 33 00 00 00
 [  118.144000] sdb: assuming drive cache: write through
 [  118.144000]  sdb: unknown partition table
 [  118.452000] sd 4:0:0:0: Attached scsi removable disk sdb
 [  118.452000] usb-storage: device scan complete
 
 This is with linux-image-2.6.19-7-generic 2.6.19-7.10 from Ubuntu edgy.
 I get similar results with a home-brew 2.6.18-rc4.
 
 Any mass storage quirk needed that might be missing?
 That all seems normal, other than the unknown partition table, but the 
 device might be all one unpartitioned disk.. at what point is it failing?
 
 Mounting it just claims wrong FS type.  And I've tried most file systems
 I can think of just to be sure.
 
 Can you read the whole volume with 'dd'? If yes, you could provide
 a hex dump of the first few sectors? Probably someone on this list will
 recognize the format...

I did this and looked into the image myself.  It definitely looks like a
FAT32 image.

I've made the first MB available here:

http://www.acc.umu.se/~tao/transfer/archos.img.bz2


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mass-storage problems with Archos AV500

[David Weinehall]

I've got an Archos AV500 here (running the very latest firmware), pretty
much acting as a doorstop, since I cannot get it to be recognized
properly by Linux.

This device has two modes, and one usb-id for each:

Windows device mode:
0e79:1129

mass storage mode:
0e79:1128

I didn't really expect any luck with the former (and didn't have any
either), but I was kind of hoping that the latter would be supported.
Not so.

Relevant info from dmesg:

[  112.904000] usb 5-5: new high speed USB device using ehci_hcd and
address 4
[  113.036000] usb 5-5: configuration #1 chosen from 1 choice
[  113.124000] usbcore: registered new interface driver libusual
[  113.14] Initializing USB Mass Storage driver...
[  113.14] scsi4 : SCSI emulation for USB Mass Storage devices
[  113.14] usb-storage: device found at 4
[  113.14] usb-storage: waiting for device to settle before scanning
[  113.14] usbcore: registered new interface driver usb-storage
[  113.14] USB Mass Storage support registered.
[  118.14] scsi 4:0:0:0: Direct-Access Archos   AV500
 PQ: 0 ANSI: 4
[  118.14] SCSI device sdb: 58074975 512-byte hdwr sectors (29734
MB)
[  118.144000] sdb: Write Protect is off
[  118.144000] sdb: Mode Sense: 33 00 00 00
[  118.144000] sdb: assuming drive cache: write through
[  118.144000] SCSI device sdb: 58074975 512-byte hdwr sectors (29734
MB)
[  118.144000] sdb: Write Protect is off
[  118.144000] sdb: Mode Sense: 33 00 00 00
[  118.144000] sdb: assuming drive cache: write through
[  118.144000]  sdb: unknown partition table
[  118.452000] sd 4:0:0:0: Attached scsi removable disk sdb
[  118.452000] usb-storage: device scan complete

This is with linux-image-2.6.19-7-generic 2.6.19-7.10 from Ubuntu edgy.
I get similar results with a home-brew 2.6.18-rc4.

Any mass storage quirk needed that might be missing?


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mass-storage problems with Archos AV500

[David Weinehall]

I've got an Archos AV500 here (running the very latest firmware), pretty
much acting as a doorstop, since I cannot get it to be recognized
properly by Linux.

This device has two modes, and one usb-id for each:

Windows device mode:
0e79:1129

mass storage mode:
0e79:1128

I didn't really expect any luck with the former (and didn't have any
either), but I was kind of hoping that the latter would be supported.
Not so.

Relevant info from dmesg:

[  112.904000] usb 5-5: new high speed USB device using ehci_hcd and
address 4
[  113.036000] usb 5-5: configuration #1 chosen from 1 choice
[  113.124000] usbcore: registered new interface driver libusual
[  113.14] Initializing USB Mass Storage driver...
[  113.14] scsi4 : SCSI emulation for USB Mass Storage devices
[  113.14] usb-storage: device found at 4
[  113.14] usb-storage: waiting for device to settle before scanning
[  113.14] usbcore: registered new interface driver usb-storage
[  113.14] USB Mass Storage support registered.
[  118.14] scsi 4:0:0:0: Direct-Access Archos   AV500
 PQ: 0 ANSI: 4
[  118.14] SCSI device sdb: 58074975 512-byte hdwr sectors (29734
MB)
[  118.144000] sdb: Write Protect is off
[  118.144000] sdb: Mode Sense: 33 00 00 00
[  118.144000] sdb: assuming drive cache: write through
[  118.144000] SCSI device sdb: 58074975 512-byte hdwr sectors (29734
MB)
[  118.144000] sdb: Write Protect is off
[  118.144000] sdb: Mode Sense: 33 00 00 00
[  118.144000] sdb: assuming drive cache: write through
[  118.144000]  sdb: unknown partition table
[  118.452000] sd 4:0:0:0: Attached scsi removable disk sdb
[  118.452000] usb-storage: device scan complete

This is with linux-image-2.6.19-7-generic 2.6.19-7.10 from Ubuntu edgy.
I get similar results with a home-brew 2.6.18-rc4.

Any mass storage quirk needed that might be missing?


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: acpiphp makes noise on every lid close/open

[David Weinehall]

On Fri, Nov 17, 2006 at 04:31:28PM +, Matthew Garrett wrote:
> On Fri, Nov 17, 2006 at 05:08:10PM +0100, David Weinehall wrote:
> 
> > Good question.  Personally I'd say we refuse to suspend when we have
> > devices we *know* to be dock-devices etc mounted.
> 
> Kernel-level or userspace? IBM certainly used to sell bay-mounted hard 
> drives, and while it's possible for a user to pull one out while the 
> machine is suspended, I suspect that the general use case is probably 
> for it to carry on being used.

I'd say that kind of policies should be left to userspace, since it's up
to userspace to decide if we suspend at all or not.  If the user tells
the kernel to shoot him in the foot, the kernel should take aim
carefully and turn him into a cripple.

> Possibly what's needed is something like Apple's nullfs - force unmount 
> the drive on suspend, and put a nullfs there instead. On resume, if the 
> drive is still there, remount it. If not, userspace applications get 
> upset about the missing drive but no data is lost. The downside to this 
> approach would be trying to figure out how to get the drive remounted 
> before the rest of userspace starts trying to scribble over it again...

Mmmm.


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: acpiphp makes noise on every lid close/open

[David Weinehall]

On Fri, Nov 17, 2006 at 03:46:27PM +, Matthew Garrett wrote:
> On Fri, Nov 17, 2006 at 04:37:17PM +0100, David Weinehall wrote:
> 
> > The fact that the dock starts to beep annoyingly. It has a button that
> > you should press before undocking, and wait for a green light to light
> > up before removing the laptop.  If you remove the computer without
> > doing so, the dock starts beeping, and it doesn't stop (AFAIK, haven't
> > managed to stand the beeping for more than 30 seconds or so) until you
> > replug the laptop.
> 
> Ah, hm. Interesting. Maybe it does want OS support, then. Have you tried 
> it in the Leading Brand OS?

Nope.

> > My guess is that there is some wait to trigger an undock event from
> > software as well, and that it would be nice to send that signal to the
> > dock before suspending...
> 
> You possibly don't want to do that if there's a mounted bay device in 
> the dock.

Well, right now I don't have a bay device in the dock, but refusing to
suspend in that case would be reasonable.  I need to add some hotplug
script for the bay device anyway if I add one.

> We really need to determine some sort of policy when it comes to mounted 
> devices that will potentially be removed by the user over 
> suspend/resume. Do we support this configuration (by not killing the 
> mount point), or do we prevent users from shooting themselves in the 
> foot?

Good question.  Personally I'd say we refuse to suspend when we have
devices we *know* to be dock-devices etc mounted.


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: acpiphp makes noise on every lid close/open

[David Weinehall]

On Fri, Nov 17, 2006 at 03:13:41PM +, Matthew Garrett wrote:
> On Fri, Nov 17, 2006 at 11:22:38AM +0100, David Weinehall wrote:
> 
> > That was with 2.6.17; with 2.7.19-pre? (don't remember right now),
> > docking seems to work without acpiphp.  It still would be nice to be
> > able to undock when the laptop is sleeping though; how do I achieve
> > that?
> 
> My experience of most laptops is that they'll fire off a bus check 
> notification when you resume, so as long as nothing actually tries to 
> access the hardware before that's handled, everything should be fine. 
> What currently breaks when you undock while asleep?

The fact that the dock starts to beep annoyingly. It has a button that
you should press before undocking, and wait for a green light to light
up before removing the laptop.  If you remove the computer without
doing so, the dock starts beeping, and it doesn't stop (AFAIK, haven't
managed to stand the beeping for more than 30 seconds or so) until you
replug the laptop.

My guess is that there is some wait to trigger an undock event from
software as well, and that it would be nice to send that signal to the
dock before suspending...


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: acpiphp makes noise on every lid close/open

[David Weinehall]

On Tue, Nov 07, 2006 at 01:44:39PM -0800, Kristen Carlson Accardi wrote:
> On Tue, 7 Nov 2006 21:44:09 +0100
> David Weinehall <[EMAIL PROTECTED]> wrote:
> 
> > On Mon, Nov 06, 2006 at 10:21:17AM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > > With 2.6.19-rc4, acpi complains about "acpiphp_glue: cannot get 
> > > > > > bridge
> > > > > > info" each time I close/reopen the lid... On thinkpad x60. Any 
> > > > > > ideas?
> > > > > > (-mm1 behaves the same).
> > > > > 
> > > > > Looks like acpi is sending a BUS_CHECK notification to acpiphp on the 
> > > > > PCI Root Bridge whenever the lid opens up.
> > > > > 
> > > > > There is a bug here in that acpiphp shouldn't even be used on the X60 
> > > > > -
> > > > > it has no hotpluggable slots.
> > > > 
> > > > How about the docking station?
> > > 
> > > "Dock" for x60 only contains cdrom slot and aditional slots, no PCI or
> > > PCMCIA slots.
> > 
> > Well, when I press the undock button on the dock without the acpiphp
> > module loaded, I never get the green light that confirms that removing
> > the laptop is safe.  If acpiphp is loaded, things work just fine.
> > 
> > 
> > Regards: David
> > -- 
> >  /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
> > //  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
> > \)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
> 
> David,
> What kernel version are you using?  You should not need acpiphp to do
> docking on the X60.  If you are using a recent kernel, do you mind sending
> the dmesg output so we can figure out why this doesn't work for you?

That was with 2.6.17; with 2.7.19-pre? (don't remember right now),
docking seems to work without acpiphp.  It still would be nice to be
able to undock when the laptop is sleeping though; how do I achieve
that?


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: acpiphp makes noise on every lid close/open

[David Weinehall]

On Tue, Nov 07, 2006 at 01:44:39PM -0800, Kristen Carlson Accardi wrote:
 On Tue, 7 Nov 2006 21:44:09 +0100
 David Weinehall [EMAIL PROTECTED] wrote:
 
  On Mon, Nov 06, 2006 at 10:21:17AM +0100, Pavel Machek wrote:
   Hi!
   
  With 2.6.19-rc4, acpi complains about acpiphp_glue: cannot get 
  bridge
  info each time I close/reopen the lid... On thinkpad x60. Any 
  ideas?
  (-mm1 behaves the same).
 
 Looks like acpi is sending a BUS_CHECK notification to acpiphp on the 
 PCI Root Bridge whenever the lid opens up.
 
 There is a bug here in that acpiphp shouldn't even be used on the X60 
 -
 it has no hotpluggable slots.

How about the docking station?
   
   Dock for x60 only contains cdrom slot and aditional slots, no PCI or
   PCMCIA slots.
  
  Well, when I press the undock button on the dock without the acpiphp
  module loaded, I never get the green light that confirms that removing
  the laptop is safe.  If acpiphp is loaded, things work just fine.
  
  
  Regards: David
  -- 
   /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
  //  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
  \)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
 
 David,
 What kernel version are you using?  You should not need acpiphp to do
 docking on the X60.  If you are using a recent kernel, do you mind sending
 the dmesg output so we can figure out why this doesn't work for you?

That was with 2.6.17; with 2.7.19-pre? (don't remember right now),
docking seems to work without acpiphp.  It still would be nice to be
able to undock when the laptop is sleeping though; how do I achieve
that?


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: acpiphp makes noise on every lid close/open

[David Weinehall]

On Fri, Nov 17, 2006 at 03:13:41PM +, Matthew Garrett wrote:
 On Fri, Nov 17, 2006 at 11:22:38AM +0100, David Weinehall wrote:
 
  That was with 2.6.17; with 2.7.19-pre? (don't remember right now),
  docking seems to work without acpiphp.  It still would be nice to be
  able to undock when the laptop is sleeping though; how do I achieve
  that?
 
 My experience of most laptops is that they'll fire off a bus check 
 notification when you resume, so as long as nothing actually tries to 
 access the hardware before that's handled, everything should be fine. 
 What currently breaks when you undock while asleep?

The fact that the dock starts to beep annoyingly. It has a button that
you should press before undocking, and wait for a green light to light
up before removing the laptop.  If you remove the computer without
doing so, the dock starts beeping, and it doesn't stop (AFAIK, haven't
managed to stand the beeping for more than 30 seconds or so) until you
replug the laptop.

My guess is that there is some wait to trigger an undock event from
software as well, and that it would be nice to send that signal to the
dock before suspending...


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: acpiphp makes noise on every lid close/open

[David Weinehall]

On Fri, Nov 17, 2006 at 03:46:27PM +, Matthew Garrett wrote:
 On Fri, Nov 17, 2006 at 04:37:17PM +0100, David Weinehall wrote:
 
  The fact that the dock starts to beep annoyingly. It has a button that
  you should press before undocking, and wait for a green light to light
  up before removing the laptop.  If you remove the computer without
  doing so, the dock starts beeping, and it doesn't stop (AFAIK, haven't
  managed to stand the beeping for more than 30 seconds or so) until you
  replug the laptop.
 
 Ah, hm. Interesting. Maybe it does want OS support, then. Have you tried 
 it in the Leading Brand OS?

Nope.

  My guess is that there is some wait to trigger an undock event from
  software as well, and that it would be nice to send that signal to the
  dock before suspending...
 
 You possibly don't want to do that if there's a mounted bay device in 
 the dock.

Well, right now I don't have a bay device in the dock, but refusing to
suspend in that case would be reasonable.  I need to add some hotplug
script for the bay device anyway if I add one.

 We really need to determine some sort of policy when it comes to mounted 
 devices that will potentially be removed by the user over 
 suspend/resume. Do we support this configuration (by not killing the 
 mount point), or do we prevent users from shooting themselves in the 
 foot?

Good question.  Personally I'd say we refuse to suspend when we have
devices we *know* to be dock-devices etc mounted.


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: acpiphp makes noise on every lid close/open

[David Weinehall]

On Fri, Nov 17, 2006 at 04:31:28PM +, Matthew Garrett wrote:
 On Fri, Nov 17, 2006 at 05:08:10PM +0100, David Weinehall wrote:
 
  Good question.  Personally I'd say we refuse to suspend when we have
  devices we *know* to be dock-devices etc mounted.
 
 Kernel-level or userspace? IBM certainly used to sell bay-mounted hard 
 drives, and while it's possible for a user to pull one out while the 
 machine is suspended, I suspect that the general use case is probably 
 for it to carry on being used.

I'd say that kind of policies should be left to userspace, since it's up
to userspace to decide if we suspend at all or not.  If the user tells
the kernel to shoot him in the foot, the kernel should take aim
carefully and turn him into a cripple.

 Possibly what's needed is something like Apple's nullfs - force unmount 
 the drive on suspend, and put a nullfs there instead. On resume, if the 
 drive is still there, remount it. If not, userspace applications get 
 upset about the missing drive but no data is lost. The downside to this 
 approach would be trying to figure out how to get the drive remounted 
 before the rest of userspace starts trying to scribble over it again...

Mmmm.


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Updated dynamic tick patches

[David Weinehall]

On Thu, Sep 01, 2005 at 04:07:22PM +0300, Tony Lindgren wrote:
[snip]
> I tried this quickly on a loaner ThinkPad T30, and needed the following
> patch to compile. The patch does work with PIT, but with lapic the
> system does not wake to timer interrupts :(

That may be a thinkpad issue; I have to boot my Thinkpad with nolapic.

[snip]


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Updated dynamic tick patches

[David Weinehall]

On Thu, Sep 01, 2005 at 04:07:22PM +0300, Tony Lindgren wrote:
[snip]
 I tried this quickly on a loaner ThinkPad T30, and needed the following
 patch to compile. The patch does work with PIT, but with lapic the
 system does not wake to timer interrupts :(

That may be a thinkpad issue; I have to boot my Thinkpad with nolapic.

[snip]


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Initramfs and TMPFS!

[David Weinehall]

On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote:
> On Sat, Aug 27, 2005 at 02:28:17PM -0700, Chris Wedgwood wrote:
> > How about you do a little research on some things for a bit?  The
> > initramfs code is done the way it is for a good reason.  cpio is used
> > over tar for another good reason.
> 
> Why don't you do some research on manners?
  
Pot.  Kettle.  Black.

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Initramfs and TMPFS!

[David Weinehall]

On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote:
 On Sat, Aug 27, 2005 at 02:28:17PM -0700, Chris Wedgwood wrote:
  How about you do a little research on some things for a bit?  The
  initramfs code is done the way it is for a good reason.  cpio is used
  over tar for another good reason.
 
 Why don't you do some research on manners?
  
Pot.  Kettle.  Black.

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace

[David Weinehall]

On Tue, Jan 01, 2002 at 08:53:39AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > New, simplified version of the sysfs whitespace strip patch...
> > > 
> > > Could you tell me why you don't just fail the operation if malformed
> > > input is supplied?
> > 
> > Leading/trailing white space should be allowed. For example echo
> > appends '\n' unless you know to use -n. It is easier to fix the kernel
> > than to teach everyone to use -n.
> 
> Please, NO! echo -n is the right thing to do, and users will eventually learn.
> We are not going to add such workarounds all over the kernel...

Ahhh, this would be so much easier if people just got used to using
printf instead of echo when doing text output. =)


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace

[David Weinehall]

On Tue, Jan 01, 2002 at 08:53:39AM +0100, Pavel Machek wrote:
 Hi!
 
New, simplified version of the sysfs whitespace strip patch...
   
   Could you tell me why you don't just fail the operation if malformed
   input is supplied?
  
  Leading/trailing white space should be allowed. For example echo
  appends '\n' unless you know to use -n. It is easier to fix the kernel
  than to teach everyone to use -n.
 
 Please, NO! echo -n is the right thing to do, and users will eventually learn.
 We are not going to add such workarounds all over the kernel...

Ahhh, this would be so much easier if people just got used to using
printf instead of echo when doing text output. =)


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Power consumption HZ100, HZ250, HZ1000: new numbers

[David Weinehall]

On Sun, Jul 31, 2005 at 07:23:54PM -0400, Lee Revell wrote:
> On Mon, 2005-08-01 at 00:47 +0200, Pavel Machek wrote:
> > I'm pretty sure at least one distro will go with HZ<300 real soon now
> > ;-).
> > 
> 
> Any idea what their official recommendation for people running apps that
> require the 1ms sleep resolution is?  Something along the lines of "Get
> bent"?

Calm down.  Any argument along the lines of the change of a default
value in the defconfig screwing people over equally applies the other
way around; by not changing the defconfig, you're screwing laptop users
(and others that want less power consumption) over.  The world is not
black and white, it's a very boring gray (or a very sadening bloody
red; but I hope we won't come to that point just because of a silly
argument on lkml...)

In the end, Linus will decide this anyway.  I can understand that you
don't want to change your application.  Help developing the dynamic
tick patch, and maybe you won't have to =)


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Average instruction length in x86-built kernel?

[David Weinehall]

On Sat, Jul 30, 2005 at 03:57:25PM -0400, Karim Yaghmour wrote:
[snip]
> # Remove non-instruction lines:
> sed /^[^c].*/d $2-dissassembled-kernel > $2-stage-1
> 
> # Remove empty lines:
> sed /^'\t'*$/d $2-stage-1 > $2-stage-2
> 
> # Remove function names:
> sed /^c[0-9,a-f]*' '\<.*\>:$/d $2-stage-2 > $2-stage-3
> 
> # Remove addresses:
> sed s/^c[0-9,a-f]*:'\t'// $2-stage-3 > $2-stage-4
> 
> # Remove instruction text:
> sed s/'\t'.*// $2-stage-4 > $2-stage-5
> 
> # Remove trailing whitespace:
> sed s/'\s'*$// $2-stage-5 > $2-stage-6

Uhm, you do know that sed allows you to execute several commands after
eachother, right?

sed -e 's/foo/bar/;s/baz/omph/'

That way you should be able to save a few stages.
Also, your script is, as far as I could see, a clean sh-script;
no need for /bin/bash; use /bin/sh instead.


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Average instruction length in x86-built kernel?

[David Weinehall]

On Sat, Jul 30, 2005 at 03:57:25PM -0400, Karim Yaghmour wrote:
[snip]
 # Remove non-instruction lines:
 sed /^[^c].*/d $2-dissassembled-kernel  $2-stage-1
 
 # Remove empty lines:
 sed /^'\t'*$/d $2-stage-1  $2-stage-2
 
 # Remove function names:
 sed /^c[0-9,a-f]*' '\.*\:$/d $2-stage-2  $2-stage-3
 
 # Remove addresses:
 sed s/^c[0-9,a-f]*:'\t'// $2-stage-3  $2-stage-4
 
 # Remove instruction text:
 sed s/'\t'.*// $2-stage-4  $2-stage-5
 
 # Remove trailing whitespace:
 sed s/'\s'*$// $2-stage-5  $2-stage-6

Uhm, you do know that sed allows you to execute several commands after
eachother, right?

sed -e 's/foo/bar/;s/baz/omph/'

That way you should be able to save a few stages.
Also, your script is, as far as I could see, a clean sh-script;
no need for /bin/bash; use /bin/sh instead.


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Power consumption HZ100, HZ250, HZ1000: new numbers

[David Weinehall]

On Sun, Jul 31, 2005 at 07:23:54PM -0400, Lee Revell wrote:
 On Mon, 2005-08-01 at 00:47 +0200, Pavel Machek wrote:
  I'm pretty sure at least one distro will go with HZ300 real soon now
  ;-).
  
 
 Any idea what their official recommendation for people running apps that
 require the 1ms sleep resolution is?  Something along the lines of Get
 bent?

Calm down.  Any argument along the lines of the change of a default
value in the defconfig screwing people over equally applies the other
way around; by not changing the defconfig, you're screwing laptop users
(and others that want less power consumption) over.  The world is not
black and white, it's a very boring gray (or a very sadening bloody
red; but I hope we won't come to that point just because of a silly
argument on lkml...)

In the end, Linus will decide this anyway.  I can understand that you
don't want to change your application.  Help developing the dynamic
tick patch, and maybe you won't have to =)


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel guide to space (updated)

[David Weinehall]

On Sat, Jul 30, 2005 at 01:41:55PM +0200, Jan Engelhardt wrote:
> 
> >Ehrm, yes, I'm perfectly aware of that.  Note the "for consistency" in
> >that sentence.  If we add an extra space in front of the labels that
> >have an indentation level of 0, we'd better do it with the labels that
> >have an indentation level > 0 too.
> 
> Labels at level > 0???

A case in a switch construct is a label.


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel guide to space (updated)

[David Weinehall]

On Sat, Jul 30, 2005 at 01:41:55PM +0200, Jan Engelhardt wrote:
 
 Ehrm, yes, I'm perfectly aware of that.  Note the for consistency in
 that sentence.  If we add an extra space in front of the labels that
 have an indentation level of 0, we'd better do it with the labels that
 have an indentation level  0 too.
 
 Labels at level  0???

A case in a switch construct is a label.


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel guide to space (updated)

[David Weinehall]

On Fri, Jul 29, 2005 at 09:52:01PM +0200, Jan Engelhardt wrote:
> 
> >I'd definitely call that a joe-bug.  Adding extra space for no good
> >reason is just silly; for consistency we'd have to add a space for the
> >case : labels also...
> 
> No, the word "case" never starts at column 1 (counting from 1), but at least 
> in column , where minimalIndent is the default indent for that 
> particular piece of code.

Ehrm, yes, I'm perfectly aware of that.  Note the "for consistency" in
that sentence.  If we add an extra space in front of the labels that
have an indentation level of 0, we'd better do it with the labels that
have an indentation level > 0 too.


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel guide to space (updated)

[David Weinehall]

On Fri, Jul 29, 2005 at 09:40:14AM +0200, Jan Engelhardt wrote:
[snip]
> Would it be reasonable to say that the first column can be a space?
> Some editors (e.g. joe) list the function in some status bar and do
> that based on the fact that all C code in a function is indented, and
> only the function header is non-indented. Putting a label statement
> fools the algorithm.  joe-bug or option for freedom?

I'd definitely call that a joe-bug.  Adding extra space for no good
reason is just silly; for consistency we'd have to add a space for the
case : labels also...


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel guide to space (updated)

[David Weinehall]

On Fri, Jul 29, 2005 at 09:40:14AM +0200, Jan Engelhardt wrote:
[snip]
 Would it be reasonable to say that the first column can be a space?
 Some editors (e.g. joe) list the function in some status bar and do
 that based on the fact that all C code in a function is indented, and
 only the function header is non-indented. Putting a label statement
 fools the algorithm.  joe-bug or option for freedom?

I'd definitely call that a joe-bug.  Adding extra space for no good
reason is just silly; for consistency we'd have to add a space for the
case foo: labels also...


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel guide to space (updated)

[David Weinehall]

On Fri, Jul 29, 2005 at 09:52:01PM +0200, Jan Engelhardt wrote:
 
 I'd definitely call that a joe-bug.  Adding extra space for no good
 reason is just silly; for consistency we'd have to add a space for the
 case foo: labels also...
 
 No, the word case never starts at column 1 (counting from 1), but at least 
 in column minimalIndent, where minimalIndent is the default indent for that 
 particular piece of code.

Ehrm, yes, I'm perfectly aware of that.  Note the for consistency in
that sentence.  If we add an extra space in front of the labels that
have an indentation level of 0, we'd better do it with the labels that
have an indentation level  0 too.


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]Fix menuconfig error message

[David Weinehall]

On Mon, Jul 04, 2005 at 09:57:00AM -0400, Kurt Wall wrote:
> If you try to run `make menuconfig' on a system that lacks ncurses
> development libs, you get an error message telling you to install
> ncurses-devel. Some popular distributions don't have an ncurses-devel
> package. This patch generalizes the error message. Patch is against
> 2.6.12.
> 
> MAINTAINERS doesn't list a maintainer for menuconfig or lxdialog,
> so I sent this to lkml, kbuild-devel, and to the kconfig maintainer.
> 
> Signed-off-by: Kurt Wall <[EMAIL PROTECTED]>
> 
> 
> --- a/scripts/lxdialog/Makefile   2005-07-04 09:31:38.0 -0400
> +++ b/scripts/lxdialog/Makefile   2005-07-04 09:38:05.0 -0400
> @@ -35,8 +35,10 @@
>   echo -e "\007" ;\
>   echo ">> Unable to find the Ncurses libraries." ;\
>   echo ">>" ;\
> - echo ">> You must install ncurses-devel in order" ;\
> - echo ">> to use 'make menuconfig'" ;\
> + echo ">> You must install ncurses development libraries" ;\
> + echo ">> to use 'make menuconfig'. If you have an RPM-based" ;\
> + echo ">> Debian-based distribution you should install the" ;\ 
> + echo ">> ncurses-devel package." ;\
>   echo ;\
>   exit 1 ;\
>   fi

You know, I'd say that *very* few (approximately zero)
Debian-based distributions are RPM-based =)  The Debian package is
called libncurses5-dev, btw.


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]Fix menuconfig error message

[David Weinehall]

On Mon, Jul 04, 2005 at 09:57:00AM -0400, Kurt Wall wrote:
 If you try to run `make menuconfig' on a system that lacks ncurses
 development libs, you get an error message telling you to install
 ncurses-devel. Some popular distributions don't have an ncurses-devel
 package. This patch generalizes the error message. Patch is against
 2.6.12.
 
 MAINTAINERS doesn't list a maintainer for menuconfig or lxdialog,
 so I sent this to lkml, kbuild-devel, and to the kconfig maintainer.
 
 Signed-off-by: Kurt Wall [EMAIL PROTECTED]
 
 
 --- a/scripts/lxdialog/Makefile   2005-07-04 09:31:38.0 -0400
 +++ b/scripts/lxdialog/Makefile   2005-07-04 09:38:05.0 -0400
 @@ -35,8 +35,10 @@
   echo -e \007 ;\
   echo  Unable to find the Ncurses libraries. ;\
   echo  ;\
 - echo  You must install ncurses-devel in order ;\
 - echo  to use 'make menuconfig' ;\
 + echo  You must install ncurses development libraries ;\
 + echo  to use 'make menuconfig'. If you have an RPM-based ;\
 + echo  Debian-based distribution you should install the ;\ 
 + echo  ncurses-devel package. ;\
   echo ;\
   exit 1 ;\
   fi

You know, I'd say that *very* few (approximately zero)
Debian-based distributions are RPM-based =)  The Debian package is
called libncurses5-dev, btw.


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch to fix bashism

[David Weinehall]

On Fri, Apr 08, 2005 at 11:11:38PM +0159, Han Boetes wrote:
> Hi,
> 
> This patch fixes a three bashisms in
> scripts/gen_initramfs_list.sh;
> 
> I'm not sure of the intention of the second change (local
> name=...). So it's very well possible that:
> 
> +   local name="${location%/$srcdir}"
> 
> is more appropriate.

This patch is not going to work; local is a bash:ism too, hence this
will fail when /bin/sh is a more strict POSIX-shell.  However,
it is quite likely that the use of local is merely due to the
(totally correct) instinct of always limiting the scope of variables.
Most scripts that I've POSIX-fixed so far could just have the local
removed with no bad effects.

> --- scripts/gen_initramfs_list.sh.orig2005-03-27 14:53:15.628883408 
> +0200
> +++ scripts/gen_initramfs_list.sh 2005-03-27 15:12:20.093898280 +0200
> @@ -1,4 +1,7 @@
> -#!/bin/bash
> +#!/bin/sh
> +
> +# script is sourced, the shebang is ignored.
> +
>  # Copyright (C) Martin Schlemmer <[EMAIL PROTECTED]>
>  # Released under the terms of the GNU GPL
>  #
> @@ -56,9 +59,9 @@
>  
>  parse() {
>   local location="$1"
> - local name="${location/${srcdir}//}"
> + local name="${location#$srcdir/}"
>   # change '//' into '/'
> - name="${name//\/\///}"
> + name=`echo $name|sed -e 's|//|/|g'`

Using $(...) instead of `...` helps readability quite a lot for
things like this...

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch to fix bashism

[David Weinehall]

On Fri, Apr 08, 2005 at 11:11:38PM +0159, Han Boetes wrote:
 Hi,
 
 This patch fixes a three bashisms in
 scripts/gen_initramfs_list.sh;
 
 I'm not sure of the intention of the second change (local
 name=...). So it's very well possible that:
 
 +   local name=${location%/$srcdir}
 
 is more appropriate.

This patch is not going to work; local is a bash:ism too, hence this
will fail when /bin/sh is a more strict POSIX-shell.  However,
it is quite likely that the use of local is merely due to the
(totally correct) instinct of always limiting the scope of variables.
Most scripts that I've POSIX-fixed so far could just have the local
removed with no bad effects.

 --- scripts/gen_initramfs_list.sh.orig2005-03-27 14:53:15.628883408 
 +0200
 +++ scripts/gen_initramfs_list.sh 2005-03-27 15:12:20.093898280 +0200
 @@ -1,4 +1,7 @@
 -#!/bin/bash
 +#!/bin/sh
 +
 +# script is sourced, the shebang is ignored.
 +
  # Copyright (C) Martin Schlemmer [EMAIL PROTECTED]
  # Released under the terms of the GNU GPL
  #
 @@ -56,9 +59,9 @@
  
  parse() {
   local location=$1
 - local name=${location/${srcdir}//}
 + local name=${location#$srcdir/}
   # change '//' into '/'
 - name=${name//\/\///}
 + name=`echo $name|sed -e 's|//|/|g'`

Using $(...) instead of `...` helps readability quite a lot for
things like this...

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFD: Kernel release numbering

[David Weinehall]

On Fri, Mar 04, 2005 at 11:32:18AM +, Ian Campbell wrote:
> On Fri, 2005-03-04 at 11:16 +, Russell King wrote:
> > On Fri, Mar 04, 2005 at 11:11:38AM +, Ian Campbell wrote:
> > > On Fri, 2005-03-04 at 10:52 +, Russell King wrote:
> > > > Unfortunately, http://l4x.org/k/ doesn't save any build logs for
> > > > investigation.
> > > 
> > > If you click the 'Fail' then it seems to keep the make output etc.
> > 
> > elinks doesn't show any of the "fail" in the matrix as links - this
> > seems to be using javascript.
> > 
> > In fact there doesn't appear to be a reason to use javascript for
> > this - it seems to be implementing a standard link to:
> 
> The links and row headers high-light when you mouse over each cell,
> which appears to be why there is javascript involved at all.
> 
> I don't know if javascript is necessary for that feature, but I agree
> that using it for the links seems wrong.

No it isn't necessary; the CSS attribute :hover is the correct way to do
this.  Using Javascript for any kind of design is just wrong, wrong,
wrong.


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFD: Kernel release numbering

[David Weinehall]

On Fri, Mar 04, 2005 at 11:32:18AM +, Ian Campbell wrote:
 On Fri, 2005-03-04 at 11:16 +, Russell King wrote:
  On Fri, Mar 04, 2005 at 11:11:38AM +, Ian Campbell wrote:
   On Fri, 2005-03-04 at 10:52 +, Russell King wrote:
Unfortunately, http://l4x.org/k/ doesn't save any build logs for
investigation.
   
   If you click the 'Fail' then it seems to keep the make output etc.
  
  elinks doesn't show any of the fail in the matrix as links - this
  seems to be using javascript.
  
  In fact there doesn't appear to be a reason to use javascript for
  this - it seems to be implementing a standard link to:
 
 The links and row headers high-light when you mouse over each cell,
 which appears to be why there is javascript involved at all.
 
 I don't know if javascript is necessary for that feature, but I agree
 that using it for the links seems wrong.

No it isn't necessary; the CSS attribute :hover is the correct way to do
this.  Using Javascript for any kind of design is just wrong, wrong,
wrong.


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BK] upgrade will be needed

[David Weinehall]

On Mon, Feb 14, 2005 at 09:12:19AM -0800, Larry McVoy wrote:
> > >So how would you suggest that we resolve it?  The protection we need is
> > >that people don't get to
> > >
> > >   - use BK
> > >   - stop using BK so they can go work on another system
> > >   - start using BK again
> > >   - stop using BK so they can go work on another system
> > 
> > What??? Why not? BK is a PROGRAM. You can't tell somebody
> > that once they use some program in one job, they can't
> > use it again. What kind of "protection" are you claiming?
> 
> It is a program that comes with a license.  Licenses have terms which
> survive the termination of the license, that's industry standard, they
> all have such terms.
> 
> In this case the situation is unusual because we have a program that is
> ahead, in some ways, of all the other programs out there that do the
> same thing.  We'd like to protect that lead.  We put that lead at risk
> by giving you BK for free, that's more or less suicide because the open
> source world has a long track record of copying that which they find
> useful.  We don't want you to copy it.  If you can't agree to not copy
> it then you don't get to use it in the first place.

Does these license terms (the ones concerning developing competing
software while, or within a year of, using BK) also apply to the
commercial license?

BTW: Wishlist request.  Would you consider adding -p (--show-c-function)
to the set of flags used for the diffs created by BitKeeper?


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BK] upgrade will be needed

[David Weinehall]

On Mon, Feb 14, 2005 at 09:12:19AM -0800, Larry McVoy wrote:
  So how would you suggest that we resolve it?  The protection we need is
  that people don't get to
  
 - use BK
 - stop using BK so they can go work on another system
 - start using BK again
 - stop using BK so they can go work on another system
  
  What??? Why not? BK is a PROGRAM. You can't tell somebody
  that once they use some program in one job, they can't
  use it again. What kind of protection are you claiming?
 
 It is a program that comes with a license.  Licenses have terms which
 survive the termination of the license, that's industry standard, they
 all have such terms.
 
 In this case the situation is unusual because we have a program that is
 ahead, in some ways, of all the other programs out there that do the
 same thing.  We'd like to protect that lead.  We put that lead at risk
 by giving you BK for free, that's more or less suicide because the open
 source world has a long track record of copying that which they find
 useful.  We don't want you to copy it.  If you can't agree to not copy
 it then you don't get to use it in the first place.

Does these license terms (the ones concerning developing competing
software while, or within a year of, using BK) also apply to the
commercial license?

BTW: Wishlist request.  Would you consider adding -p (--show-c-function)
to the set of flags used for the diffs created by BitKeeper?


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: the "Turing Attack" (was: Sabotaged PaXtest)

[David Weinehall]

On Thu, Feb 10, 2005 at 04:21:49PM +0100, Ingo Molnar wrote:
> 
> * Jakob Oestergaard <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, Feb 10, 2005 at 02:43:14PM +0100, Ingo Molnar wrote:
> > > 
> > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > 
> > > > the bigger problem is however that you're once again fixing the
> > > > symptoms, instead of the underlying problem - not the correct
> > > > approach/mindset.
> > > 
> > > i'll change my approach/mindset when it is proven that "the underlying
> > > problem" can be solved. (in a deterministic fashion)
> > 
> > I know neither exec-shield nor PaX and therefore have no bias or
> > preference - I thought I should chirp in on your comment here Ingo...
> > 
> > ...
> > > PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield
> > > is in the 6th month, but that does not change the fundamental
> > > end-result: a child will be born ;-)
> > 
> > Yes and no.  I would think that the chances of a child being born are
> > greater if the pregnancy has lasted successfully up until the 6th month,
> > compared to a first week pregnancy.
> > 
> > I assume you get my point  :)
> 
> the important point is: neither PaX nor exec-shield can claim _for sure_
> that no child will be born, and neither can claim virginity ;-)
> 
> [ but i guess there's a point where a bad analogy must stop ;) ]

Yeah, sex is *usually* a much more pleasant experience than having your
machine broken into, even if it results in a pregnancy. =)


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: the Turing Attack (was: Sabotaged PaXtest)

[David Weinehall]

On Thu, Feb 10, 2005 at 04:21:49PM +0100, Ingo Molnar wrote:
 
 * Jakob Oestergaard [EMAIL PROTECTED] wrote:
 
  On Thu, Feb 10, 2005 at 02:43:14PM +0100, Ingo Molnar wrote:
   
   * [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   
the bigger problem is however that you're once again fixing the
symptoms, instead of the underlying problem - not the correct
approach/mindset.
   
   i'll change my approach/mindset when it is proven that the underlying
   problem can be solved. (in a deterministic fashion)
  
  I know neither exec-shield nor PaX and therefore have no bias or
  preference - I thought I should chirp in on your comment here Ingo...
  
  ...
   PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield
   is in the 6th month, but that does not change the fundamental
   end-result: a child will be born ;-)
  
  Yes and no.  I would think that the chances of a child being born are
  greater if the pregnancy has lasted successfully up until the 6th month,
  compared to a first week pregnancy.
  
  I assume you get my point  :)
 
 the important point is: neither PaX nor exec-shield can claim _for sure_
 that no child will be born, and neither can claim virginity ;-)
 
 [ but i guess there's a point where a bad analogy must stop ;) ]

Yeah, sex is *usually* a much more pleasant experience than having your
machine broken into, even if it results in a pregnancy. =)


Regards: David
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch 0/6 virtual address space randomisation

[David Weinehall]

On Thu, Jan 27, 2005 at 09:13:04PM +0100, Arjan van de Ven wrote:
> On Thu, 2005-01-27 at 20:34 +0100, Julien TINNES wrote:
> > > 
> > > Yeah, if it came from PaX the randomization would actually be useful.
> > > Sorry, I've just woken up and already explained in another post.
> > > 
> > 
> > Please, no hard feelings.
> > 
> > Speaking about implementation of the non executable pages semantics on 
> > IA32, PaX and Exec-Shield are very different (well not that much since 
> > 2.6 in fact because PAGEEXEC is now "segmentation when I can").
> > But when it comes to ASLR it's pretty much the same thing.
> > 
> > The only difference may be the (very small) randomization of the brk() 
> > managed heap on ET_EXEC (which is probably the more "hackish" feature of 
> > PaX ASLR) but it seems that Arjan is even going to propose a patch for 
> > that (Is this in ES too ?).
> 
> Exec shield randomized brk() too yes.
> However that is a both more dangerous and more invasive change to do
> correctly (you have no idea how hard it is to get that right for
> emacs...) so that's reserved for the second batch of patches once this
> first batch is dealt with.

Oh, so you mean that we can both get a more secure system, *and* make
emacs stop working?  A win-win situation! =)


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch 0/6 virtual address space randomisation

[David Weinehall]

On Thu, Jan 27, 2005 at 09:13:04PM +0100, Arjan van de Ven wrote:
 On Thu, 2005-01-27 at 20:34 +0100, Julien TINNES wrote:
   
   Yeah, if it came from PaX the randomization would actually be useful.
   Sorry, I've just woken up and already explained in another post.
   
  
  Please, no hard feelings.
  
  Speaking about implementation of the non executable pages semantics on 
  IA32, PaX and Exec-Shield are very different (well not that much since 
  2.6 in fact because PAGEEXEC is now segmentation when I can).
  But when it comes to ASLR it's pretty much the same thing.
  
  The only difference may be the (very small) randomization of the brk() 
  managed heap on ET_EXEC (which is probably the more hackish feature of 
  PaX ASLR) but it seems that Arjan is even going to propose a patch for 
  that (Is this in ES too ?).
 
 Exec shield randomized brk() too yes.
 However that is a both more dangerous and more invasive change to do
 correctly (you have no idea how hard it is to get that right for
 emacs...) so that's reserved for the second batch of patches once this
 first batch is dealt with.

Oh, so you mean that we can both get a more secure system, *and* make
emacs stop working?  A win-win situation! =)


Regards: David Weinehall
-- 
 /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] RE: 2.4.5-ac14 through to 2.4.6-ac1 fdomain.c initialisation for shared IRQ

[David Weinehall]

On Thu, Jul 05, 2001 at 07:16:26PM +0100, Alan Cox wrote:
> > I have recently had a problem with the fdomain driver initialisation and
> > have found the problem to be the way in which it requests the irq. Here is
> > my patch that has so far work ok.
> 
> I've seen this patch before. It needs at least one change
> 
> > -do_fdomain_16x0_intr, 0, "fdomain", NULL);
> > +  retcode = request_irq( shpnt->irq,
> > +do_fdomain_16x0_intr, SA_SHIRQ, "fdomain", shpnt);
> 
> Only set SA_SHIRQ if PCI - say -
> 
>   pdev?SA_SHIRQ:0
> 
> The other problem is that the code doesnt have support for handling IRQ
> source checking, so if the line it shares with generates interrupts we might
> sometimes do the right thing
> 
> I have a long outstanding request with adaptec (who bought future domain)
> for the info needed to fix this, but obviously its a dead product, from a
> bought company and hardly on their priorities.
> 
> I suspect the IRQ handler needs to either
> 
> A.Check bit 0 of the status port and return 
> 
> B.Check bit 4 or bit 9 of the interrupt control register
> 
> Without docs someone would need to play with the various combinations and
> see what happened

Uhmmm, an idea would be to look in fd_mcs.c as that driver already has
working support for irq-sharing.


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] RE: 2.4.5-ac14 through to 2.4.6-ac1 fdomain.c initialisation for shared IRQ

[David Weinehall]

On Thu, Jul 05, 2001 at 07:16:26PM +0100, Alan Cox wrote:
  I have recently had a problem with the fdomain driver initialisation and
  have found the problem to be the way in which it requests the irq. Here is
  my patch that has so far work ok.
 
 I've seen this patch before. It needs at least one change
 
  -do_fdomain_16x0_intr, 0, fdomain, NULL);
  +  retcode = request_irq( shpnt-irq,
  +do_fdomain_16x0_intr, SA_SHIRQ, fdomain, shpnt);
 
 Only set SA_SHIRQ if PCI - say -
 
   pdev?SA_SHIRQ:0
 
 The other problem is that the code doesnt have support for handling IRQ
 source checking, so if the line it shares with generates interrupts we might
 sometimes do the right thing
 
 I have a long outstanding request with adaptec (who bought future domain)
 for the info needed to fix this, but obviously its a dead product, from a
 bought company and hardly on their priorities.
 
 I suspect the IRQ handler needs to either
 
 A.Check bit 0 of the status port and return 
 
 B.Check bit 4 or bit 9 of the interrupt control register
 
 Without docs someone would need to play with the various combinations and
 see what happened

Uhmmm, an idea would be to look in fd_mcs.c as that driver already has
working support for irq-sharing.


/David
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange errors in /var/log/messages

[David Weinehall]

On Mon, Jul 02, 2001 at 09:51:44PM +0200, [EMAIL PROTECTED] wrote:
> On Mon, 2 Jul 2001, Guest section DW wrote:
> 
> > On Mon, Jul 02, 2001 at 05:16:23PM +0100, Alan Cox wrote:
> >
> > > > I'm running RedHat 7.0 with all official RH patches applied. The kernel I
> > > > currently run fow a few days is 2.2.19-7.0.8
> > > > I run the pre-compiled kernel of RH. Suddenly I the following messages:
> > > >
> > > > Jul  2 15:12:16 gateway SERVER[1240]: Dispatch_input: bad request line
> > > > 'BBXX%.176u%3
> > > > 
>00$nsecurity.%301$n%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22
> >
> > > These are for an application.  Not sure which or why
> >
> > See CERT Advisory CA-2000-22
> > http://www.infowar.com/iwftp/cert/advisories/CA-2000-22.html
> >
> >   "A popular replacement software package to the BSD lpd printing service
> >called LPRng contains at least one software defect, known as a "format string
> >vulnerability," which may allow remote users to execute arbitrary code on
> >vulnerable systems."
> 
> I just read the article. It seems somebody tried to exploid a bug in
> LPRng. Unfortunately I didn't check the TCP/IP connections at the time of
> attack (with netstat), so I couldn't tell who was connected to port 515.
> The article suggest upgrading to 3.6.25. I'm currenlty running 3.7.4-23.
> I assume I'm not vulnerable, but those 'errors' in the logfile really
> scared the heck out of me! :) To be certain, I just blocked poort 515 for
> outbound connections. :)
> 
> Bye the way, sorry this message was off-topic, but I didn't know it was a
> LPRng issue, not a kernel issue.

A good idea is to block all ports, then open only those you know needs to
be open. Paranoia is good.


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange errors in /var/log/messages

[David Weinehall]

On Mon, Jul 02, 2001 at 09:51:44PM +0200, [EMAIL PROTECTED] wrote:
 On Mon, 2 Jul 2001, Guest section DW wrote:
 
  On Mon, Jul 02, 2001 at 05:16:23PM +0100, Alan Cox wrote:
 
I'm running RedHat 7.0 with all official RH patches applied. The kernel I
currently run fow a few days is 2.2.19-7.0.8
I run the pre-compiled kernel of RH. Suddenly I the following messages:
   
Jul  2 15:12:16 gateway SERVER[1240]: Dispatch_input: bad request line
'BBXX%.176u%3

00$nsecurity.%301$n%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22
 
   These are for an application.  Not sure which or why
 
  See CERT Advisory CA-2000-22
  http://www.infowar.com/iwftp/cert/advisories/CA-2000-22.html
 
A popular replacement software package to the BSD lpd printing service
 called LPRng contains at least one software defect, known as a format string
 vulnerability, which may allow remote users to execute arbitrary code on
 vulnerable systems.
 
 I just read the article. It seems somebody tried to exploid a bug in
 LPRng. Unfortunately I didn't check the TCP/IP connections at the time of
 attack (with netstat), so I couldn't tell who was connected to port 515.
 The article suggest upgrading to 3.6.25. I'm currenlty running 3.7.4-23.
 I assume I'm not vulnerable, but those 'errors' in the logfile really
 scared the heck out of me! :) To be certain, I just blocked poort 515 for
 outbound connections. :)
 
 Bye the way, sorry this message was off-topic, but I didn't know it was a
 LPRng issue, not a kernel issue.

A good idea is to block all ports, then open only those you know needs to
be open. Paranoia is good.


/David
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[David Weinehall]

On Thu, Jun 28, 2001 at 11:19:37AM +0200, Bjorn Wesen wrote:
> On Thu, 28 Jun 2001, Laramie Leavitt wrote:
> > > dmesg buffer space is rather limited and IMHO there isn't space to
> > > waste on credit-giving in boot logs.
> > 
> > Here here.  You don't see annoying log-eating copyright messages
> > printed out in the Windows boot. Just imagine:
> 
> There's a difference; someone paid for that Windows code and you paid to
> get windows and don't care about who did what. But when someone puts down
> a lot of work to contributes something for free which others find useful
> and actually use, don't you think it might be prudent to let them at least
> write who contributed it, if a line is going to be printed anyway to say
> device that or that has been registred ?
> 
> I know it sounds a bit like an "advertisment space" but it's always been
> so; people have been releasing code for free since noone knows how long
> and often one major factor has been that their peers will go "wow did
> you do that". Otherwise why would anyone ever write their name in an About
> box when they release a freeware program. And dmesg is the Linux kernels
> About box (someone might argue that the code is the about box but
> unfortunately most people dont read the headers in every .c file they
> use).
> 
> See the old BSD license - distribution-wise it's more free than the GPL
> but you still had to give credit where credit is due when getting a free
> lunch from someone elses work (I think this requirement was dropped in the
> current BSD license)
> 
> The risk is that some people might take it quite personally to get their
> names removed and might not be as interested to see their code in the
> kernel in the future. Of course as long as it's GPL nothing would stop it
> anyway, but I still think it's a good idea to give credit for others hard
> work.

tao@tictac$ grep "^N:" CREDITS | sed -e "s/N: //" | wc
392 8635916

Add a little for (c)  and other stuff, and you're getting close
to the size of the dmesg-buffer. Is it worth it?

Now, I can't claim to be 100% innocent; my name appears in the procinfo
for at least one MCA-driver. This will be remedied in due time, I can
assure you. I hope others follow my example.


/David Weinehall
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[David Weinehall]

On Thu, Jun 28, 2001 at 11:19:37AM +0200, Bjorn Wesen wrote:
 On Thu, 28 Jun 2001, Laramie Leavitt wrote:
   dmesg buffer space is rather limited and IMHO there isn't space to
   waste on credit-giving in boot logs.
  
  Here here.  You don't see annoying log-eating copyright messages
  printed out in the Windows boot. Just imagine:
 
 There's a difference; someone paid for that Windows code and you paid to
 get windows and don't care about who did what. But when someone puts down
 a lot of work to contributes something for free which others find useful
 and actually use, don't you think it might be prudent to let them at least
 write who contributed it, if a line is going to be printed anyway to say
 device that or that has been registred ?
 
 I know it sounds a bit like an advertisment space but it's always been
 so; people have been releasing code for free since noone knows how long
 and often one major factor has been that their peers will go wow did
 you do that. Otherwise why would anyone ever write their name in an About
 box when they release a freeware program. And dmesg is the Linux kernels
 About box (someone might argue that the code is the about box but
 unfortunately most people dont read the headers in every .c file they
 use).
 
 See the old BSD license - distribution-wise it's more free than the GPL
 but you still had to give credit where credit is due when getting a free
 lunch from someone elses work (I think this requirement was dropped in the
 current BSD license)
 
 The risk is that some people might take it quite personally to get their
 names removed and might not be as interested to see their code in the
 kernel in the future. Of course as long as it's GPL nothing would stop it
 anyway, but I still think it's a good idea to give credit for others hard
 work.

tao@tictac$ grep ^N: CREDITS | sed -e s/N: // | wc
392 8635916

Add a little for (c)  and other stuff, and you're getting close
to the size of the dmesg-buffer. Is it worth it?

Now, I can't claim to be 100% innocent; my name appears in the procinfo
for at least one MCA-driver. This will be remedied in due time, I can
assure you. I hope others follow my example.


/David Weinehall
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Configure.help is complete

[David Weinehall]

On Fri, Jun 01, 2001 at 08:43:58AM -0400, Phil Auld wrote:
> Alexander Viro wrote:
> 
> ...snip...
> 
> > 
> > We should start removing the crap from procfs in 2.5. Documenting shit is
> > a good step, but taking it out would be better.
> > 
> 
> Not to open a what may be can of worms but ...
> 
> What's wrong with procfs? 

Imho, a procfs should be for process-information, nothing else.
The procfs in its current form, while useful, is something horrible
that should be taken out on the backyard and shot using slugs.

Ehrmmm. No, but seriously, the non-process stuff should be separate
from the procfs. Maybe call it kernfs or whatever.

> It allows a general interface to the kernel that does not require new
> syscalls/ioctls and can be accessed from user space without specifically
> compiled programs. You can use shell scripts, java, command line etc.

Yes, and it's also totally non standardised.


/David Weinehall
  _     _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Configure.help is complete

[David Weinehall]

On Fri, Jun 01, 2001 at 08:43:58AM -0400, Phil Auld wrote:
 Alexander Viro wrote:
 
 ...snip...
 
  
  We should start removing the crap from procfs in 2.5. Documenting shit is
  a good step, but taking it out would be better.
  
 
 Not to open a what may be can of worms but ...
 
 What's wrong with procfs? 

Imho, a procfs should be for process-information, nothing else.
The procfs in its current form, while useful, is something horrible
that should be taken out on the backyard and shot using slugs.

Ehrmmm. No, but seriously, the non-process stuff should be separate
from the procfs. Maybe call it kernfs or whatever.

 It allows a general interface to the kernel that does not require new
 syscalls/ioctls and can be accessed from user space without specifically
 compiled programs. You can use shell scripts, java, command line etc.

Yes, and it's also totally non standardised.


/David Weinehall
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] new PCI ids

[David Weinehall]

On Thu, May 31, 2001 at 06:17:06PM -0700, Tim Hockin wrote:
> Attached is a patch for cleaning up some PCI ids and adding a few that were
> missing.  Please let me know of any problems with this.
> 
> (diff against 2.4.5)
> 
> Tim
> 
> -- 
> Tim Hockin
> Systems Software Engineer
> Sun Microsystems, Cobalt Server Appliances
> [EMAIL PROTECTED]
> diff -ruN dist-2.4.5/drivers/pci/pci.ids cobalt-2.4.5/drivers/pci/pci.ids
> --- dist-2.4.5/drivers/pci/pci.idsSat May 19 17:49:14 2001
> +++ cobalt-2.4.5/drivers/pci/pci.ids  Thu May 31 14:32:33 2001
> @@ -4,7 +4,7 @@
>  #Maintained by Martin Mares <[EMAIL PROTECTED]>
>  #If you have any new entries, send them to the maintainer.
>  #
> -#$Id: pci.ids,v 1.62 2000/06/28 10:56:36 mj Exp $
> +#$Id: pci.ids,v 1.3 2001/04/04 20:40:25 thockin Exp $

Shouldn't that be 1.63?!


/David Weinehall
  _     _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] new PCI ids

[David Weinehall]

On Thu, May 31, 2001 at 06:17:06PM -0700, Tim Hockin wrote:
 Attached is a patch for cleaning up some PCI ids and adding a few that were
 missing.  Please let me know of any problems with this.
 
 (diff against 2.4.5)
 
 Tim
 
 -- 
 Tim Hockin
 Systems Software Engineer
 Sun Microsystems, Cobalt Server Appliances
 [EMAIL PROTECTED]
 diff -ruN dist-2.4.5/drivers/pci/pci.ids cobalt-2.4.5/drivers/pci/pci.ids
 --- dist-2.4.5/drivers/pci/pci.idsSat May 19 17:49:14 2001
 +++ cobalt-2.4.5/drivers/pci/pci.ids  Thu May 31 14:32:33 2001
 @@ -4,7 +4,7 @@
  #Maintained by Martin Mares [EMAIL PROTECTED]
  #If you have any new entries, send them to the maintainer.
  #
 -#$Id: pci.ids,v 1.62 2000/06/28 10:56:36 mj Exp $
 +#$Id: pci.ids,v 1.3 2001/04/04 20:40:25 thockin Exp $

Shouldn't that be 1.63?!


/David Weinehall
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[David Weinehall]

On Wed, May 23, 2001 at 05:51:50PM +, Scott Anderson wrote:
> David Weinehall wrote:
> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
> > still a pain to work with.
> 
> If you really want to have fun, remove all swap...

Oh, I've done some testing without swap too, mainly to test Rik's
oom-killer. Seemed to work pretty well. Can't say it was enjoyable, though.


/David
  _     _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[David Weinehall]

On Wed, May 23, 2001 at 05:51:50PM +, Scott Anderson wrote:
 David Weinehall wrote:
  IMVHO every developer involved in memory-management (and indeed, any
  software development; the authors of ntpd comes in mind here) should
  have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
  luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
  still a pain to work with.
 
 If you really want to have fun, remove all swap...

Oh, I've done some testing without swap too, mainly to test Rik's
oom-killer. Seemed to work pretty well. Can't say it was enjoyable, though.


/David
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.4-ac14

[David Weinehall]

On Wed, May 23, 2001 at 05:36:20AM -0400, Olivier Galibert wrote:
> On Wed, May 23, 2001 at 07:07:38PM +1000, Keith Owens wrote:
> > On Wed, 23 May 2001 09:17:08 +0200 (CEST), 
> > Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> > >On Wed, 23 May 2001, Keith Owens wrote:
> > >> Is drivers/char/ser_a2232fw.ax supposed to be included?  Nothing uses it.
> > >
> > >It's the source for the firmware hexdump in ser_a2232fw.h, provided as a
> > >reference.
> > 
> > What is the point of including it in the kernel source tree without the
> > code to convert it to ser_a2232fw.h?  Nobody can use ser_a2232fw.ax, it
> > is just bloat.
> 
> We don't provide the binutils or gcc with the kernel either.  The 6502
> is a rather well known processor.  Try plonking "6502 assembler" in
> google and you'll have a lot of choice.

Me likee, finally asm in the kernel I can grok.


/Tao of TRIAD aka David Weinehall
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.4-ac14

[David Weinehall]

On Wed, May 23, 2001 at 05:36:20AM -0400, Olivier Galibert wrote:
 On Wed, May 23, 2001 at 07:07:38PM +1000, Keith Owens wrote:
  On Wed, 23 May 2001 09:17:08 +0200 (CEST), 
  Geert Uytterhoeven [EMAIL PROTECTED] wrote:
  On Wed, 23 May 2001, Keith Owens wrote:
   Is drivers/char/ser_a2232fw.ax supposed to be included?  Nothing uses it.
  
  It's the source for the firmware hexdump in ser_a2232fw.h, provided as a
  reference.
  
  What is the point of including it in the kernel source tree without the
  code to convert it to ser_a2232fw.h?  Nobody can use ser_a2232fw.ax, it
  is just bloat.
 
 We don't provide the binutils or gcc with the kernel either.  The 6502
 is a rather well known processor.  Try plonking 6502 assembler in
 google and you'll have a lot of choice.

Me likee, finally asm in the kernel I can grok.


/Tao of TRIAD aka David Weinehall
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: write to dvd ram

[David Weinehall]

On Tue, May 22, 2001 at 10:38:49AM -0600, [EMAIL PROTECTED] wrote:
> OK, I've asked this question four weeks in a row and received no response
> whatsoever.  Linux is supposed to be the OS where you can turn to the
> newsgroups/IRC and get able help.
> 
> This is to those who couldn't lift a finger to help with this compile/driver
> problem:

Ignoring your obvious attitude problem for now (you haven't ever
considered the fact that (almost) all the people on this list develop
Linux voluntarily, in their spare-time?!), I suggest you try
at #kernelnewbies on irc if you want response. Or you could try to
download a newer version of the kernel. You know, the bug might've been
fixed since v2.4.2...


/David Weinehall
  _     _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: write to dvd ram

[David Weinehall]

On Tue, May 22, 2001 at 10:38:49AM -0600, [EMAIL PROTECTED] wrote:
 OK, I've asked this question four weeks in a row and received no response
 whatsoever.  Linux is supposed to be the OS where you can turn to the
 newsgroups/IRC and get able help.
 
 This is to those who couldn't lift a finger to help with this compile/driver
 problem:

Ignoring your obvious attitude problem for now (you haven't ever
considered the fact that (almost) all the people on this list develop
Linux voluntarily, in their spare-time?!), I suggest you try
at #kernelnewbies on irc if you want response. Or you could try to
download a newer version of the kernel. You know, the bug might've been
fixed since v2.4.2...


/David Weinehall
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[David Weinehall]

On Tue, May 22, 2001 at 05:22:35AM +0200, Dave Jones wrote:
> On Mon, 21 May 2001, Steven Walter wrote:
> 
> > > Any particular reason this needs to be done in the kernel, as opposed
> > > to having your script read /dev/cpu/*/cpuid?
> > Wouldn't that be the same reason we have /anything/ in cpuinfo?
> 
> When /proc/cpuinfo was added, we didn't have /dev/cpu/*/cpuid
> Now that we do, we're stuck with keeping /proc/cpuinfo for
> compatability reasons.

AFAIK, not all processors support cpuid.


/david
  _     _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[David Weinehall]

On Sun, May 20, 2001 at 11:54:09PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > You're right.  It should never dump too much data at once.  OTOH, if
> > > those cleaned pages are really old (front of reclaim list), there's no
> > > value in keeping them either.  Maybe there should be a slow bleed for
> > > mostly idle or lightly loaded conditions.
> > 
> > If you don't think it's worthwhile keeping the oldest pages
> > in memory around, please hand me your excess DIMMS ;)
> 
> Sorry, Rik, you can't have that that DIMM. You know, you are
> developing memory managment, and we can't have you having too much
> memory available ;-).

IMVHO every developer involved in memory-management (and indeed, any
software development; the authors of ntpd comes in mind here) should
have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
still a pain to work with.


/David
  _     _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[David Weinehall]

On Sun, May 20, 2001 at 11:54:09PM +0200, Pavel Machek wrote:
 Hi!
 
   You're right.  It should never dump too much data at once.  OTOH, if
   those cleaned pages are really old (front of reclaim list), there's no
   value in keeping them either.  Maybe there should be a slow bleed for
   mostly idle or lightly loaded conditions.
  
  If you don't think it's worthwhile keeping the oldest pages
  in memory around, please hand me your excess DIMMS ;)
 
 Sorry, Rik, you can't have that that DIMM. You know, you are
 developing memory managment, and we can't have you having too much
 memory available ;-).

IMVHO every developer involved in memory-management (and indeed, any
software development; the authors of ntpd comes in mind here) should
have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
still a pain to work with.


/David
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[David Weinehall]

On Tue, May 22, 2001 at 05:22:35AM +0200, Dave Jones wrote:
 On Mon, 21 May 2001, Steven Walter wrote:
 
   Any particular reason this needs to be done in the kernel, as opposed
   to having your script read /dev/cpu/*/cpuid?
  Wouldn't that be the same reason we have /anything/ in cpuinfo?
 
 When /proc/cpuinfo was added, we didn't have /dev/cpu/*/cpuid
 Now that we do, we're stuck with keeping /proc/cpuinfo for
 compatability reasons.

AFAIK, not all processors support cpuid.


/david
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/