[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 10:29 PM, Peter Stuge wrote: > Justin P. Mattock wrote: >>> *baffled* Why did you think that would work? transmit_cmd()s signature >>> has 4 parameters. >> >> I have no manual in front of me. Did a quick google, but came up with >> (no hits) info on what that function does. grep showed too many entries >> to really see why/what this is. > > Check out the tool cscope. (Or kscope, if you prefer a GUI.) > > > //Peter > thanks for this tool.. I think this is what I need.. running around not knowing what/where the manual is for a call is a bit daunting. I'll give this a look. Thanks for this.. Justin P. Mattock
[PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: > > > Em 14-06-2010 23:26, Justin P. Mattock escreveu: >> not sure if this is correct or not for >> fixing this warning: >>CC [M] drivers/media/common/tuners/tuner-simple.o >> drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': >> drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' >> set but not used >> >> Signed-off-by: Justin P. Mattock >> >> --- >> drivers/media/common/tuners/tuner-simple.c |4 +--- >> 1 files changed, 1 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/media/common/tuners/tuner-simple.c >> b/drivers/media/common/tuners/tuner-simple.c >> index 8abbcc5..4465b99 100644 >> --- a/drivers/media/common/tuners/tuner-simple.c >> +++ b/drivers/media/common/tuners/tuner-simple.c >> @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, >> struct tuner_simple_priv *priv = fe->tuner_priv; >> u8 config, cb; >> u16 div; >> -struct tunertype *tun; >> u8 buffer[4]; >> int rc, IFPCoff, i; >> enum param_type desired_type; >> struct tuner_params *t_params; >> >> -tun = priv->tun; >> - >> + > Why are you adding an extra blank line here? Except for that, the patch > looks sane. > >> /* IFPCoff = Video Intermediate Frequency - Vif: >> 940 =16*58.75 NTSC/J (Japan) >> 732 =16*45.75 M/N STD > > o.k. resent this.. I ended up doing a git reset do make sure things dont get funky etc.. Justin P. Mattock
[PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: > > > Em 14-06-2010 23:26, Justin P. Mattock escreveu: >> not sure if this is correct or not for >> fixing this warning: >>CC [M] drivers/media/common/tuners/tuner-simple.o >> drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': >> drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' >> set but not used >> >> Signed-off-by: Justin P. Mattock >> >> --- >> drivers/media/common/tuners/tuner-simple.c |4 +--- >> 1 files changed, 1 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/media/common/tuners/tuner-simple.c >> b/drivers/media/common/tuners/tuner-simple.c >> index 8abbcc5..4465b99 100644 >> --- a/drivers/media/common/tuners/tuner-simple.c >> +++ b/drivers/media/common/tuners/tuner-simple.c >> @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, >> struct tuner_simple_priv *priv = fe->tuner_priv; >> u8 config, cb; >> u16 div; >> -struct tunertype *tun; >> u8 buffer[4]; >> int rc, IFPCoff, i; >> enum param_type desired_type; >> struct tuner_params *t_params; >> >> -tun = priv->tun; >> - >> + > Why are you adding an extra blank line here? Except for that, the patch > looks sane. > I think I was doing something wrong when creating these patches. i.g. I just hightlight the code then move the cursor highlight all the way to the right before pressing "x". normally would be o.k. but for some reason seems to be doing this. found if I highlight left to ; (or the end of the code I want to delete) then git commit creates the patch properly. >> /* IFPCoff = Video Intermediate Frequency - Vif: >> 940 =16*58.75 NTSC/J (Japan) >> 732 =16*45.75 M/N STD > > I'll resend this. Thanks for having a look. Justin P. Mattock
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 08:49 PM, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 14 Jun 2010 19:12:31 PDT, "Justin P. Mattock" said:
>
>> what I tried was this:
>>
>> if (!rc)
>> printk("test"\n")
>>
>> and everything looked good,
>> but as a soon as I changed
>>
>> rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE,
>> "attempting to determine the timeouts");
>>
>> to this:
>>
>> rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE);
>>
>> if (!rc)
>> printk("attempting to determine the timeouts\n");
>
> *baffled* Why did you think that would work? transmit_cmd()s signature
> has 4 parameters.
I have no manual in front of me. Did a quick google, but came up with
(no hits) info on what that function does. grep showed too many entries
to really see why/what this is. So I kind of just scrambled with this one.
Justin P. Mattock
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 05:13 PM, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 14 Jun 2010 13:26:44 PDT, "Justin P. Mattock" said:
>> Im getting this warning when compiling:
>> CC drivers/char/tpm/tpm.o
>> drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt':
>> drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used
>>
>> The below patch gets rid of the warning,
>> but I'm not sure if it's the best solution.
>
>> rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE,
>> "attempting to determine the timeouts");
>> +if (!rc)
>> +rc = 0;
>> }
>
> Good thing that's a void function. ;)
>
> Unless transmit_cmd() is marked 'must_check', maybe losing the 'rc =' would
> be a better solution?
what I tried was this:
if (!rc)
printk("test"\n")
and everything looked good,
but as a soon as I changed
rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE,
"attempting to determine the timeouts");
to this:
rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE);
if (!rc)
printk("attempting to determine the timeouts\n");
I error out with transmit_cmd not having enough
functions to it.. so I just added the rc = 0;
and went on to the next.
Justin P. Mattock
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 04:07 PM, Stefan Richter wrote: > On 14 Jun, Justin P. Mattock wrote: >> On 06/14/2010 02:47 PM, Edward Shishkin wrote: >>> Whitespaces should be removed. >>> I recommend quilt package for managing patches: >>> "quilt refresh --strip-trailing-whitespace" is your friend.. >> >> o.k. I resent this.. fixed the whitespace(hopefully) >> and add your Acked to it. >> as for quilt I'll have to look into that.. >> (using a lfs system, so if the sourcecode is easy >> to deal with(build), then it's a good but if it becomes >> a nightmare maybe not!!). > > Since you appear to generate the patches with git, you can use "git diff > --check [...]" for some basic whitespace checks (additions of trailing > space, additions of space before tab). For more extensive checks, try > "git diff [...] | scripts/checkpatch.pl -". Check this before you > commit. If you committed already, "git commit --amend [-a] [...]" lets > you alter the very last commit of course. Thanks for the info on this, copied it down in my book of commands... Justin P. Mattock
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:47 PM, Edward Shishkin wrote: > Justin P. Mattock wrote: >> On 06/14/2010 02:05 PM, Edward Shishkin wrote: >>> Justin P. Mattock wrote: >>>> Not sure if this is correct or not. >>>> the below patch gets rid of this warning message >>>> produced by gcc 4.6.0 >>>> >>>> fs/reiserfs/stree.c: In function 'search_by_key': >>>> fs/reiserfs/stree.c:602:6: warning: variable >>>> 'right_neighbor_of_leaf_node' set but not used >>>> >>>> Signed-off-by: Justin P. Mattock >>> >>> Acked-by: Edward Shishkin >>> >> >> o.k.!! >> what about the whitespace issue? > > Whitespaces should be removed. > I recommend quilt package for managing patches: > "quilt refresh --strip-trailing-whitespace" is your friend.. > > Thanks, > Edward. > o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Justin P. Mattock
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:05 PM, Edward Shishkin wrote: > Justin P. Mattock wrote: >> Not sure if this is correct or not. >> the below patch gets rid of this warning message >> produced by gcc 4.6.0 >> >> fs/reiserfs/stree.c: In function 'search_by_key': >> fs/reiserfs/stree.c:602:6: warning: variable >> 'right_neighbor_of_leaf_node' set but not used >> >> Signed-off-by: Justin P. Mattock > > Acked-by: Edward Shishkin > o.k.!! what about the whitespace issue? from what I remember I did notice the "+" that git does when making patches like this but given some many of these warnings I just did a quick workaround or however then figured to worry later on that. >> --- >> fs/reiserfs/stree.c | 7 ++- >> 1 files changed, 2 insertions(+), 5 deletions(-) >> >> diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c >> index 313d39d..73086ad 100644 >> --- a/fs/reiserfs/stree.c >> +++ b/fs/reiserfs/stree.c >> @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const >> struct cpu_key *key, /* Key to s >> struct buffer_head *bh; >> struct path_element *last_element; >> int node_level, retval; >> - int right_neighbor_of_leaf_node; >> int fs_gen; >> struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; >> b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; >> @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const >> struct cpu_key *key, /* Key to s >> >> pathrelse(search_path); >> >> - right_neighbor_of_leaf_node = 0; >> - >> + >> /* With each iteration of this loop we search through the items in the >> current node, and calculate the next current node(next path element) >> for the next iteration of this loop.. */ >> @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const >> struct cpu_key *key, /* Key to s >> starting from the root. */ >> block_number = SB_ROOT_BLOCK(sb); >> expected_level = -1; >> - right_neighbor_of_leaf_node = 0; >> - >> + >> /* repeat search from the root */ >> continue; >> } > >
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 01:48 PM, Nick Bowler wrote: > On 13:26 Mon 14 Jun , Justin P. Mattock wrote: >> @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct >> cpu_key *key, /* Key to s >> >> pathrelse(search_path); >> >> -right_neighbor_of_leaf_node = 0; >> - >> + > > This hunk introduces whitespace on the empty line, which is not cool. I can resend!!(biggest problem is working through these warnings) > >> /* With each iteration of this loop we search through the items in the >> current node, and calculate the next current node(next path element) >> for the next iteration of this loop.. */ >> @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct >> cpu_key *key, /* Key to s >> starting from the root. */ >> block_number = SB_ROOT_BLOCK(sb); >> expected_level = -1; >> -right_neighbor_of_leaf_node = 0; >> - >> + > > Here, too. > > Most of the patches in this series have similar issues. > main thing now(for me atleast)is, is this actual dead code or what? if not then something else needs to be done, if yes then I guess I can resend this, with out the whitespace issue. Justin P. Mattock
[PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
On 06/14/2010 01:53 PM, Jean Delvare wrote: > Hi Justin, > > On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: >> could be a right solution, could be wrong >> here is the warning: >>CC drivers/i2c/i2c-core.o >> drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': >> drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used >> >> Signed-off-by: Justin P. Mattock >> >> --- >> drivers/i2c/i2c-core.c |2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c >> index 1cca263..79c6c26 100644 >> --- a/drivers/i2c/i2c-core.c >> +++ b/drivers/i2c/i2c-core.c >> @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) >> mutex_lock(_lock); >> dummy = bus_for_each_drv(_bus_type, NULL, adap, >> __process_new_adapter); >> +if(!dummy) >> +dummy = 0; > > One word: scripts/checkpatch.pl it was this, and/or just take the code out (since I'm a newbie) > > In other news, the above is just plain wrong. First we force people to > read the result of bus_for_each_drv() and then when they do and don't > need the value, gcc complains, so we add one more layer of useless > code, which developers and possibly tools will later wonder and > complain about? I can easily imagine that a static code analyzer would > spot the above code as being a potential bug. > > Let's stop this madness now please. > your telling me!! I haven't even compiled all the way through the kernel yet.(lots of warnings) > Either __must_check goes away from bus_for_each_drv() and from every > other function which raises this problem, or we must disable that new > type of warning gcc 4.6.0 generates. Depends which warnings we value > more, as we can't sanely have both. > >> mutex_unlock(_lock); >> >> return 0; > > up to you guys.. best thing now is deciphering what and what not is an actual issue. Justin P. Mattock
[PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattock --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe->tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv->tun; - + /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD -- 1.7.1.rc1.21.gf3bd6
[PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used
Temporary fix until something is resolved to fix the below warning: CC [M] drivers/ieee1394/sbp2.o drivers/ieee1394/sbp2.c: In function 'sbp2_parse_unit_directory': drivers/ieee1394/sbp2.c:1353:6: warning: variable 'unit_characteristics' set but not used Signed-off-by: Justin P. Mattock --- drivers/ieee1394/sbp2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c index 4565cb5..fcf8bd5 100644 --- a/drivers/ieee1394/sbp2.c +++ b/drivers/ieee1394/sbp2.c @@ -1356,6 +1356,8 @@ static void sbp2_parse_unit_directory(struct sbp2_lu *lu, management_agent_addr = 0; unit_characteristics = 0; + if (!unit_characteristics) + unit_characteristics = 0; firmware_revision = SBP2_ROM_VALUE_MISSING; model = ud->flags & UNIT_DIRECTORY_MODEL_ID ? ud->model_id : SBP2_ROM_VALUE_MISSING; -- 1.7.1.rc1.21.gf3bd6
[PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattock --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(_lock); dummy = bus_for_each_drv(_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; mutex_unlock(_lock); return 0; -- 1.7.1.rc1.21.gf3bd6
[PATCH 5/8]drm:drm_gem Fix warning: variable 'dev' set but not used
Probably not even a fix for this warning: CC [M] drivers/gpu/drm/drm_gem.o drivers/gpu/drm/drm_gem.c: In function 'drm_gem_handle_delete': drivers/gpu/drm/drm_gem.c:188:21: warning: variable 'dev' set but not used Signed-off-by: Justin P. Mattock --- drivers/gpu/drm/drm_gem.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 33dad3f..e8180c9 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -206,6 +206,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) return -EINVAL; } dev = obj->dev; + if (!dev) + dev = 0; /* Release reference and decrement refcount. */ idr_remove(>object_idr, handle); -- 1.7.1.rc1.21.gf3bd6
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. Signed-off-by: Justin P. Mattock --- drivers/char/tpm/tpm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c index 05ad4a1..3d685dc 100644 --- a/drivers/char/tpm/tpm.c +++ b/drivers/char/tpm/tpm.c @@ -514,6 +514,8 @@ void tpm_gen_interrupt(struct tpm_chip *chip) rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, "attempting to determine the timeouts"); + if (!rc) + rc = 0; } EXPORT_SYMBOL_GPL(tpm_gen_interrupt); -- 1.7.1.rc1.21.gf3bd6
[PATCH 3/8]char/hpet.c Fix variable 'hpet' set but not used
The below fixes this warning:
drivers/char/hpet.c: In function 'hpet_ioctl_common':
drivers/char/hpet.c:559:23: warning: variable 'hpet' set but not used
please have a look.
Signed-off-by: Justin P. Mattock
---
drivers/char/hpet.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index a0a1829..7932858 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -556,7 +556,6 @@ static int
hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned long arg, int
kernel)
{
struct hpet_timer __iomem *timer;
- struct hpet __iomem *hpet;
struct hpets *hpetp;
int err;
unsigned long v;
@@ -568,7 +567,6 @@ hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned
long arg, int kernel)
case HPET_DPI:
case HPET_IRQFREQ:
timer = devp->hd_timer;
- hpet = devp->hd_hpet;
hpetp = devp->hd_hpets;
break;
case HPET_IE_ON:
--
1.7.1.rc1.21.gf3bd6
[PATCH 2/8]bluetooth/hci_ldisc.c Fix warning: variable 'tty' set but not used
Im getting this while building:
CC [M] drivers/bluetooth/hci_ldisc.o
drivers/bluetooth/hci_ldisc.c: In function 'hci_uart_send_frame':
drivers/bluetooth/hci_ldisc.c:213:21: warning: variable 'tty' set but not used
the below fixed it for me, but am not sure if
it's correct.
Signed-off-by: Justin P. Mattock
---
drivers/bluetooth/hci_ldisc.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 76a1abb..f693dfe 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -210,7 +210,6 @@ static int hci_uart_close(struct hci_dev *hdev)
static int hci_uart_send_frame(struct sk_buff *skb)
{
struct hci_dev* hdev = (struct hci_dev *) skb->dev;
- struct tty_struct *tty;
struct hci_uart *hu;
if (!hdev) {
@@ -222,8 +221,7 @@ static int hci_uart_send_frame(struct sk_buff *skb)
return -EBUSY;
hu = (struct hci_uart *) hdev->driver_data;
- tty = hu->tty;
-
+
BT_DBG("%s: type %d len %d", hdev->name, bt_cb(skb)->pkt_type,
skb->len);
hu->proto->enqueue(hu, skb);
--
1.7.1.rc1.21.gf3bd6
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock --- fs/reiserfs/stree.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- 1.7.1.rc1.21.gf3bd6
[PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages.
First and foremost, I must thank anybody taking the time to even look at these(I know you people have better things to be doing). And secondly here is my try at trying to fix some of the warning messages spammed by gcc 4.6.0 when building the kernel. Some of them I removed, and some of them I just shut off. Note: Removing the code does seem like a good approach(if it's actually dead), but if not then something needs to be fixed. As for shutting off the code to shutup gcc does seem like a temporary fix, but would rather have a warning message, than see it get lost in the sands of time. In any case Thanks for taking the time, and hopefully we can get fixes for all of this mess generated by gcc.. Justin P. Mattock
[PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages.
First and foremost, I must thank anybody taking the time to even look at these(I know you people have better things to be doing). And secondly here is my try at trying to fix some of the warning messages spammed by gcc 4.6.0 when building the kernel. Some of them I removed, and some of them I just shut off. Note: Removing the code does seem like a good approach(if it's actually dead), but if not then something needs to be fixed. As for shutting off the code to shutup gcc does seem like a temporary fix, but would rather have a warning message, than see it get lost in the sands of time. In any case Thanks for taking the time, and hopefully we can get fixes for all of this mess generated by gcc.. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- fs/reiserfs/stree.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- 1.7.1.rc1.21.gf3bd6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8]char/hpet.c Fix variable 'hpet' set but not used
The below fixes this warning:
drivers/char/hpet.c: In function 'hpet_ioctl_common':
drivers/char/hpet.c:559:23: warning: variable 'hpet' set but not used
please have a look.
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
drivers/char/hpet.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index a0a1829..7932858 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -556,7 +556,6 @@ static int
hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned long arg, int
kernel)
{
struct hpet_timer __iomem *timer;
- struct hpet __iomem *hpet;
struct hpets *hpetp;
int err;
unsigned long v;
@@ -568,7 +567,6 @@ hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned
long arg, int kernel)
case HPET_DPI:
case HPET_IRQFREQ:
timer = devp-hd_timer;
- hpet = devp-hd_hpet;
hpetp = devp-hd_hpets;
break;
case HPET_IE_ON:
--
1.7.1.rc1.21.gf3bd6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/char/tpm/tpm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c index 05ad4a1..3d685dc 100644 --- a/drivers/char/tpm/tpm.c +++ b/drivers/char/tpm/tpm.c @@ -514,6 +514,8 @@ void tpm_gen_interrupt(struct tpm_chip *chip) rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); + if (!rc) + rc = 0; } EXPORT_SYMBOL_GPL(tpm_gen_interrupt); -- 1.7.1.rc1.21.gf3bd6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8]drm:drm_gem Fix warning: variable 'dev' set but not used
Probably not even a fix for this warning: CC [M] drivers/gpu/drm/drm_gem.o drivers/gpu/drm/drm_gem.c: In function 'drm_gem_handle_delete': drivers/gpu/drm/drm_gem.c:188:21: warning: variable 'dev' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/gpu/drm/drm_gem.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 33dad3f..e8180c9 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -206,6 +206,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) return -EINVAL; } dev = obj-dev; + if (!dev) + dev = 0; /* Release reference and decrement refcount. */ idr_remove(filp-object_idr, handle); -- 1.7.1.rc1.21.gf3bd6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(core_lock); dummy = bus_for_each_drv(i2c_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; mutex_unlock(core_lock); return 0; -- 1.7.1.rc1.21.gf3bd6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used
Temporary fix until something is resolved to fix the below warning: CC [M] drivers/ieee1394/sbp2.o drivers/ieee1394/sbp2.c: In function 'sbp2_parse_unit_directory': drivers/ieee1394/sbp2.c:1353:6: warning: variable 'unit_characteristics' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/ieee1394/sbp2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c index 4565cb5..fcf8bd5 100644 --- a/drivers/ieee1394/sbp2.c +++ b/drivers/ieee1394/sbp2.c @@ -1356,6 +1356,8 @@ static void sbp2_parse_unit_directory(struct sbp2_lu *lu, management_agent_addr = 0; unit_characteristics = 0; + if (!unit_characteristics) + unit_characteristics = 0; firmware_revision = SBP2_ROM_VALUE_MISSING; model = ud-flags UNIT_DIRECTORY_MODEL_ID ? ud-model_id : SBP2_ROM_VALUE_MISSING; -- 1.7.1.rc1.21.gf3bd6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
On 06/14/2010 01:53 PM, Jean Delvare wrote: Hi Justin, On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(core_lock); dummy = bus_for_each_drv(i2c_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; One word: scripts/checkpatch.pl it was this, and/or just take the code out (since I'm a newbie) In other news, the above is just plain wrong. First we force people to read the result of bus_for_each_drv() and then when they do and don't need the value, gcc complains, so we add one more layer of useless code, which developers and possibly tools will later wonder and complain about? I can easily imagine that a static code analyzer would spot the above code as being a potential bug. Let's stop this madness now please. your telling me!! I haven't even compiled all the way through the kernel yet.(lots of warnings) Either __must_check goes away from bus_for_each_drv() and from every other function which raises this problem, or we must disable that new type of warning gcc 4.6.0 generates. Depends which warnings we value more, as we can't sanely have both. mutex_unlock(core_lock); return 0; up to you guys.. best thing now is deciphering what and what not is an actual issue. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 01:48 PM, Nick Bowler wrote: On 13:26 Mon 14 Jun , Justin P. Mattock wrote: @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + This hunk introduces whitespace on the empty line, which is not cool. I can resend!!(biggest problem is working through these warnings) /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + Here, too. Most of the patches in this series have similar issues. main thing now(for me atleast)is, is this actual dead code or what? if not then something else needs to be done, if yes then I guess I can resend this, with out the whitespace issue. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:05 PM, Edward Shishkin wrote: Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com Acked-by: Edward Shishkin edward.shish...@gmail.com o.k.!! what about the whitespace issue? from what I remember I did notice the + that git does when making patches like this but given some many of these warnings I just did a quick workaround or however then figured to worry later on that. --- fs/reiserfs/stree.c | 7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:47 PM, Edward Shishkin wrote: Justin P. Mattock wrote: On 06/14/2010 02:05 PM, Edward Shishkin wrote: Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com Acked-by: Edward Shishkin edward.shish...@gmail.com o.k.!! what about the whitespace issue? Whitespaces should be removed. I recommend quilt package for managing patches: quilt refresh --strip-trailing-whitespace is your friend.. Thanks, Edward. o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 10:29 PM, Peter Stuge wrote: Justin P. Mattock wrote: *baffled* Why did you think that would work? transmit_cmd()s signature has 4 parameters. I have no manual in front of me. Did a quick google, but came up with (no hits) info on what that function does. grep showed too many entries to really see why/what this is. Check out the tool cscope. (Or kscope, if you prefer a GUI.) //Peter thanks for this tool.. I think this is what I need.. running around not knowing what/where the manual is for a call is a bit daunting. I'll give this a look. Thanks for this.. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages.
First and foremost, I must thank anybody taking the time to even look at these(I know you people have better things to be doing). And secondly here is my try at trying to fix some of the warning messages spammed by gcc 4.6.0 when building the kernel. Some of them I removed, and some of them I just shut off. Note: Removing the code does seem like a good approach(if it's actually dead), but if not then something needs to be fixed. As for shutting off the code to shutup gcc does seem like a temporary fix, but would rather have a warning message, than see it get lost in the sands of time. In any case Thanks for taking the time, and hopefully we can get fixes for all of this mess generated by gcc.. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- fs/reiserfs/stree.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- 1.7.1.rc1.21.gf3bd6 -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/char/tpm/tpm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c index 05ad4a1..3d685dc 100644 --- a/drivers/char/tpm/tpm.c +++ b/drivers/char/tpm/tpm.c @@ -514,6 +514,8 @@ void tpm_gen_interrupt(struct tpm_chip *chip) rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); + if (!rc) + rc = 0; } EXPORT_SYMBOL_GPL(tpm_gen_interrupt); -- 1.7.1.rc1.21.gf3bd6 -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
On 06/14/2010 01:53 PM, Jean Delvare wrote: Hi Justin, On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(core_lock); dummy = bus_for_each_drv(i2c_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; One word: scripts/checkpatch.pl it was this, and/or just take the code out (since I'm a newbie) In other news, the above is just plain wrong. First we force people to read the result of bus_for_each_drv() and then when they do and don't need the value, gcc complains, so we add one more layer of useless code, which developers and possibly tools will later wonder and complain about? I can easily imagine that a static code analyzer would spot the above code as being a potential bug. Let's stop this madness now please. your telling me!! I haven't even compiled all the way through the kernel yet.(lots of warnings) Either __must_check goes away from bus_for_each_drv() and from every other function which raises this problem, or we must disable that new type of warning gcc 4.6.0 generates. Depends which warnings we value more, as we can't sanely have both. mutex_unlock(core_lock); return 0; up to you guys.. best thing now is deciphering what and what not is an actual issue. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 01:48 PM, Nick Bowler wrote: On 13:26 Mon 14 Jun , Justin P. Mattock wrote: @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + This hunk introduces whitespace on the empty line, which is not cool. I can resend!!(biggest problem is working through these warnings) /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + Here, too. Most of the patches in this series have similar issues. main thing now(for me atleast)is, is this actual dead code or what? if not then something else needs to be done, if yes then I guess I can resend this, with out the whitespace issue. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:47 PM, Edward Shishkin wrote: Justin P. Mattock wrote: On 06/14/2010 02:05 PM, Edward Shishkin wrote: Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com Acked-by: Edward Shishkin edward.shish...@gmail.com o.k.!! what about the whitespace issue? Whitespaces should be removed. I recommend quilt package for managing patches: quilt refresh --strip-trailing-whitespace is your friend.. Thanks, Edward. o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 04:07 PM, Stefan Richter wrote: On 14 Jun, Justin P. Mattock wrote: On 06/14/2010 02:47 PM, Edward Shishkin wrote: Whitespaces should be removed. I recommend quilt package for managing patches: quilt refresh --strip-trailing-whitespace is your friend.. o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Since you appear to generate the patches with git, you can use git diff --check [...] for some basic whitespace checks (additions of trailing space, additions of space before tab). For more extensive checks, try git diff [...] | scripts/checkpatch.pl -. Check this before you commit. If you committed already, git commit --amend [-a] [...] lets you alter the very last commit of course. Thanks for the info on this, copied it down in my book of commands... Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 05:13 PM, valdis.kletni...@vt.edu wrote: On Mon, 14 Jun 2010 13:26:44 PDT, Justin P. Mattock said: Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); + if (!rc) + rc = 0; } Good thing that's a void function. ;) Unless transmit_cmd() is marked 'must_check', maybe losing the 'rc =' would be a better solution? what I tried was this: if (!rc) printk(test\n) and everything looked good, but as a soon as I changed rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); to this: rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE); if (!rc) printk(attempting to determine the timeouts\n); I error out with transmit_cmd not having enough functions to it.. so I just added the rc = 0; and went on to the next. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 08:49 PM, valdis.kletni...@vt.edu wrote: On Mon, 14 Jun 2010 19:12:31 PDT, Justin P. Mattock said: what I tried was this: if (!rc) printk(test\n) and everything looked good, but as a soon as I changed rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); to this: rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE); if (!rc) printk(attempting to determine the timeouts\n); *baffled* Why did you think that would work? transmit_cmd()s signature has 4 parameters. I have no manual in front of me. Did a quick google, but came up with (no hits) info on what that function does. grep showed too many entries to really see why/what this is. So I kind of just scrambled with this one. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: Em 14-06-2010 23:26, Justin P. Mattock escreveu: not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe-tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv-tun; - + Why are you adding an extra blank line here? Except for that, the patch looks sane. I think I was doing something wrong when creating these patches. i.g. I just hightlight the code then move the cursor highlight all the way to the right before pressing x. normally would be o.k. but for some reason seems to be doing this. found if I highlight left to ; (or the end of the code I want to delete) then git commit creates the patch properly. /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD I'll resend this. Thanks for having a look. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: Em 14-06-2010 23:26, Justin P. Mattock escreveu: not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe-tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv-tun; - + Why are you adding an extra blank line here? Except for that, the patch looks sane. /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD o.k. resent this.. I ended up doing a git reset do make sure things dont get funky etc.. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 10:29 PM, Peter Stuge wrote: Justin P. Mattock wrote: *baffled* Why did you think that would work? transmit_cmd()s signature has 4 parameters. I have no manual in front of me. Did a quick google, but came up with (no hits) info on what that function does. grep showed too many entries to really see why/what this is. Check out the tool cscope. (Or kscope, if you prefer a GUI.) //Peter thanks for this tool.. I think this is what I need.. running around not knowing what/where the manual is for a call is a bit daunting. I'll give this a look. Thanks for this.. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages.
First and foremost, I must thank anybody taking the time to even look at these(I know you people have better things to be doing). And secondly here is my try at trying to fix some of the warning messages spammed by gcc 4.6.0 when building the kernel. Some of them I removed, and some of them I just shut off. Note: Removing the code does seem like a good approach(if it's actually dead), but if not then something needs to be fixed. As for shutting off the code to shutup gcc does seem like a temporary fix, but would rather have a warning message, than see it get lost in the sands of time. In any case Thanks for taking the time, and hopefully we can get fixes for all of this mess generated by gcc.. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe-tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv-tun; - + /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD -- 1.7.1.rc1.21.gf3bd6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used
Temporary fix until something is resolved to fix the below warning: CC [M] drivers/ieee1394/sbp2.o drivers/ieee1394/sbp2.c: In function 'sbp2_parse_unit_directory': drivers/ieee1394/sbp2.c:1353:6: warning: variable 'unit_characteristics' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/ieee1394/sbp2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c index 4565cb5..fcf8bd5 100644 --- a/drivers/ieee1394/sbp2.c +++ b/drivers/ieee1394/sbp2.c @@ -1356,6 +1356,8 @@ static void sbp2_parse_unit_directory(struct sbp2_lu *lu, management_agent_addr = 0; unit_characteristics = 0; + if (!unit_characteristics) + unit_characteristics = 0; firmware_revision = SBP2_ROM_VALUE_MISSING; model = ud-flags UNIT_DIRECTORY_MODEL_ID ? ud-model_id : SBP2_ROM_VALUE_MISSING; -- 1.7.1.rc1.21.gf3bd6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8]drm:drm_gem Fix warning: variable 'dev' set but not used
Probably not even a fix for this warning: CC [M] drivers/gpu/drm/drm_gem.o drivers/gpu/drm/drm_gem.c: In function 'drm_gem_handle_delete': drivers/gpu/drm/drm_gem.c:188:21: warning: variable 'dev' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/gpu/drm/drm_gem.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 33dad3f..e8180c9 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -206,6 +206,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) return -EINVAL; } dev = obj-dev; + if (!dev) + dev = 0; /* Release reference and decrement refcount. */ idr_remove(filp-object_idr, handle); -- 1.7.1.rc1.21.gf3bd6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- fs/reiserfs/stree.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- 1.7.1.rc1.21.gf3bd6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8]char/hpet.c Fix variable 'hpet' set but not used
The below fixes this warning:
drivers/char/hpet.c: In function 'hpet_ioctl_common':
drivers/char/hpet.c:559:23: warning: variable 'hpet' set but not used
please have a look.
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
drivers/char/hpet.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index a0a1829..7932858 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -556,7 +556,6 @@ static int
hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned long arg, int
kernel)
{
struct hpet_timer __iomem *timer;
- struct hpet __iomem *hpet;
struct hpets *hpetp;
int err;
unsigned long v;
@@ -568,7 +567,6 @@ hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned
long arg, int kernel)
case HPET_DPI:
case HPET_IRQFREQ:
timer = devp-hd_timer;
- hpet = devp-hd_hpet;
hpetp = devp-hd_hpets;
break;
case HPET_IE_ON:
--
1.7.1.rc1.21.gf3bd6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(core_lock); dummy = bus_for_each_drv(i2c_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; mutex_unlock(core_lock); return 0; -- 1.7.1.rc1.21.gf3bd6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/char/tpm/tpm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c index 05ad4a1..3d685dc 100644 --- a/drivers/char/tpm/tpm.c +++ b/drivers/char/tpm/tpm.c @@ -514,6 +514,8 @@ void tpm_gen_interrupt(struct tpm_chip *chip) rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); + if (!rc) + rc = 0; } EXPORT_SYMBOL_GPL(tpm_gen_interrupt); -- 1.7.1.rc1.21.gf3bd6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8]bluetooth/hci_ldisc.c Fix warning: variable 'tty' set but not used
Im getting this while building:
CC [M] drivers/bluetooth/hci_ldisc.o
drivers/bluetooth/hci_ldisc.c: In function 'hci_uart_send_frame':
drivers/bluetooth/hci_ldisc.c:213:21: warning: variable 'tty' set but not used
the below fixed it for me, but am not sure if
it's correct.
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
drivers/bluetooth/hci_ldisc.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 76a1abb..f693dfe 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -210,7 +210,6 @@ static int hci_uart_close(struct hci_dev *hdev)
static int hci_uart_send_frame(struct sk_buff *skb)
{
struct hci_dev* hdev = (struct hci_dev *) skb-dev;
- struct tty_struct *tty;
struct hci_uart *hu;
if (!hdev) {
@@ -222,8 +221,7 @@ static int hci_uart_send_frame(struct sk_buff *skb)
return -EBUSY;
hu = (struct hci_uart *) hdev-driver_data;
- tty = hu-tty;
-
+
BT_DBG(%s: type %d len %d, hdev-name, bt_cb(skb)-pkt_type,
skb-len);
hu-proto-enqueue(hu, skb);
--
1.7.1.rc1.21.gf3bd6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
On 06/14/2010 01:53 PM, Jean Delvare wrote: Hi Justin, On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(core_lock); dummy = bus_for_each_drv(i2c_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; One word: scripts/checkpatch.pl it was this, and/or just take the code out (since I'm a newbie) In other news, the above is just plain wrong. First we force people to read the result of bus_for_each_drv() and then when they do and don't need the value, gcc complains, so we add one more layer of useless code, which developers and possibly tools will later wonder and complain about? I can easily imagine that a static code analyzer would spot the above code as being a potential bug. Let's stop this madness now please. your telling me!! I haven't even compiled all the way through the kernel yet.(lots of warnings) Either __must_check goes away from bus_for_each_drv() and from every other function which raises this problem, or we must disable that new type of warning gcc 4.6.0 generates. Depends which warnings we value more, as we can't sanely have both. mutex_unlock(core_lock); return 0; up to you guys.. best thing now is deciphering what and what not is an actual issue. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:05 PM, Edward Shishkin wrote: Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com Acked-by: Edward Shishkin edward.shish...@gmail.com o.k.!! what about the whitespace issue? from what I remember I did notice the + that git does when making patches like this but given some many of these warnings I just did a quick workaround or however then figured to worry later on that. --- fs/reiserfs/stree.c | 7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:47 PM, Edward Shishkin wrote: Justin P. Mattock wrote: On 06/14/2010 02:05 PM, Edward Shishkin wrote: Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com Acked-by: Edward Shishkin edward.shish...@gmail.com o.k.!! what about the whitespace issue? Whitespaces should be removed. I recommend quilt package for managing patches: quilt refresh --strip-trailing-whitespace is your friend.. Thanks, Edward. o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 04:07 PM, Stefan Richter wrote: On 14 Jun, Justin P. Mattock wrote: On 06/14/2010 02:47 PM, Edward Shishkin wrote: Whitespaces should be removed. I recommend quilt package for managing patches: quilt refresh --strip-trailing-whitespace is your friend.. o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Since you appear to generate the patches with git, you can use git diff --check [...] for some basic whitespace checks (additions of trailing space, additions of space before tab). For more extensive checks, try git diff [...] | scripts/checkpatch.pl -. Check this before you commit. If you committed already, git commit --amend [-a] [...] lets you alter the very last commit of course. Thanks for the info on this, copied it down in my book of commands... Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 05:13 PM, valdis.kletni...@vt.edu wrote: On Mon, 14 Jun 2010 13:26:44 PDT, Justin P. Mattock said: Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); + if (!rc) + rc = 0; } Good thing that's a void function. ;) Unless transmit_cmd() is marked 'must_check', maybe losing the 'rc =' would be a better solution? what I tried was this: if (!rc) printk(test\n) and everything looked good, but as a soon as I changed rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); to this: rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE); if (!rc) printk(attempting to determine the timeouts\n); I error out with transmit_cmd not having enough functions to it.. so I just added the rc = 0; and went on to the next. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 08:49 PM, valdis.kletni...@vt.edu wrote: On Mon, 14 Jun 2010 19:12:31 PDT, Justin P. Mattock said: what I tried was this: if (!rc) printk(test\n) and everything looked good, but as a soon as I changed rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); to this: rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE); if (!rc) printk(attempting to determine the timeouts\n); *baffled* Why did you think that would work? transmit_cmd()s signature has 4 parameters. I have no manual in front of me. Did a quick google, but came up with (no hits) info on what that function does. grep showed too many entries to really see why/what this is. So I kind of just scrambled with this one. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: Em 14-06-2010 23:26, Justin P. Mattock escreveu: not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe-tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv-tun; - + Why are you adding an extra blank line here? Except for that, the patch looks sane. I think I was doing something wrong when creating these patches. i.g. I just hightlight the code then move the cursor highlight all the way to the right before pressing x. normally would be o.k. but for some reason seems to be doing this. found if I highlight left to ; (or the end of the code I want to delete) then git commit creates the patch properly. /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD I'll resend this. Thanks for having a look. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: Em 14-06-2010 23:26, Justin P. Mattock escreveu: not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe-tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv-tun; - + Why are you adding an extra blank line here? Except for that, the patch looks sane. /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD o.k. resent this.. I ended up doing a git reset do make sure things dont get funky etc.. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 10:29 PM, Peter Stuge wrote: Justin P. Mattock wrote: *baffled* Why did you think that would work? transmit_cmd()s signature has 4 parameters. I have no manual in front of me. Did a quick google, but came up with (no hits) info on what that function does. grep showed too many entries to really see why/what this is. Check out the tool cscope. (Or kscope, if you prefer a GUI.) //Peter thanks for this tool.. I think this is what I need.. running around not knowing what/where the manual is for a call is a bit daunting. I'll give this a look. Thanks for this.. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6]afs:fsclient.c Fix variable 'bp' set but not used
This fixes this warning message I'm getting:
CC [M] fs/afs/fsclient.o
fs/afs/fsclient.c: In function 'afs_deliver_fs__lock':
fs/afs/fsclient.c:1759:16: warning: variable 'bp' set but not used
CC [M] fs/afs/inode.o
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
fs/afs/fsclient.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/fs/afs/fsclient.c b/fs/afs/fsclient.c
index 4bd0218..aca2ccb 100644
--- a/fs/afs/fsclient.c
+++ b/fs/afs/fsclient.c
@@ -1756,8 +1756,7 @@ int afs_fs_get_volume_status(struct afs_server *server,
static int afs_deliver_fs__lock(struct afs_call *call,
struct sk_buff *skb, bool last)
{
- const __be32 *bp;
-
+
_enter({%u},{%u},%d, call-unmarshall, skb-len, last);
afs_transfer_reply(call, skb);
@@ -1767,8 +1766,6 @@ static int afs_deliver_fs__lock(struct afs_call *call,
if (call-reply_size != call-reply_max)
return -EBADMSG;
- /* unmarshall the reply once we've received all of it */
- bp = call-buffer;
/* xdr_decode_AFSVolSync(bp, call-replyX); */
_leave( = 0 [done]);
--
1.7.1.rc1.21.gf3bd6
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH 2/6]kernel:audit.c Fix warning: variable 'nlh' set but not used
Removing dead code(hopefully), fixes a warning
when compiling the kernel.
CC kernel/audit.o
kernel/audit.c: In function 'audit_buffer_alloc':
kernel/audit.c:1044:19: warning: variable 'nlh' set but not used
CC kernel/auditfilter.o
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
kernel/audit.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index c71bd26..783d958 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1041,8 +1041,7 @@ static struct audit_buffer * audit_buffer_alloc(struct
audit_context *ctx,
{
unsigned long flags;
struct audit_buffer *ab = NULL;
- struct nlmsghdr *nlh;
-
+
spin_lock_irqsave(audit_freelist_lock, flags);
if (!list_empty(audit_freelist)) {
ab = list_entry(audit_freelist.next,
@@ -1065,8 +1064,7 @@ static struct audit_buffer * audit_buffer_alloc(struct
audit_context *ctx,
if (!ab-skb)
goto nlmsg_failure;
- nlh = NLMSG_NEW(ab-skb, 0, 0, type, 0, 0);
-
+
return ab;
nlmsg_failure: /* Used by NLMSG_NEW */
--
1.7.1.rc1.21.gf3bd6
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH 5/6]kernel:module.c variable 'nowarn' set but not used
On 06/11/2010 02:17 PM, Geert Uytterhoeven wrote:
On Fri, Jun 11, 2010 at 22:41, Justin P. Mattock
justinmatt...@gmail.com wrote:
The below patch fixes a warning message
reported by gcc 4.6.0.
CC kernel/module.o
kernel/module.c: In function 'add_usage_links':
kernel/module.c:1343:6: warning: variable 'nowarn' set but not used
Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com
---
kernel/module.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 8c6b428..a71027a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1340,13 +1340,9 @@ static void add_usage_links(struct module *mod)
{
#ifdef CONFIG_MODULE_UNLOAD
struct module_use *use;
- int nowarn;
-
+
mutex_lock(module_mutex);
- list_for_each_entry(use,mod-target_list, target_list) {
- nowarn = sysfs_create_link(use-target-holders_dir,
-mod-mkobj.kobj, mod-name);
- }
+ list_for_each_entry(use,mod-target_list, target_list);
mutex_unlock(module_mutex);
#endif
}
Also wrong, you removed the creation of the links in sysfs.
that's not good..
The assignment to nowarn was there to avoid another compiler warning,
as sysfs_create_link() is marked __must_check.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
alright.. thanks for having a look
and a response. if somebody has a fix
for this then let me know, and I can
test it out over here(I can also try
fixing this as well, but my knowledge
of code only goes so far)..
Justin P. Mattock
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
Re: super_bisq...@yahoo.com None
On 05/28/2010 03:55 AM, Brad Rogers wrote: On Fri, 28 May 2010 01:42:24 -0700 Justin P. Mattockjustinmatt...@gmail.com wrote: Hello Justin, I need verification over here please!! You're still receiving message from the list. Ergo, you're still subscribed. It follows then, that you're not doing anything wrong WRT the list. In any case, Tollef has found the guilty party and unsubbed them. He did post a message to the list saying so. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: justinmatt...@gmail.com alright cool.. yeah this e-mail thing was tripping me up thinking I had a config messd up somewhere (but wasn't the case). cheers, Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: undefined symbol: _glapi_tls_Context
On 05/30/2010 01:17 PM, Nix wrote: On 30 May 2010, Justin Mattock verbalised: [ 12701.506] (EE) AIGLX error: dlopen of /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: _glapi_tls_Context) [...] my switches are these: ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --disable-ipv6 --enable-secure-rpc --enable-gallium-radeon --enable-selinux --enable-glx-tls --enable-64-bit --enable-gles2 --enable-opengl --enable-gl-osmesa am I missing something with a switch for mesa or somewhere else? If you have --enable-glx-tls in the server configure switches, you need it in the Mesa configure switches too, and vice versa. alright!! I know mesa has it enabled, I must have missed a lib somewhere.. cheers, Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: super_bisq...@yahoo.com None
On 05/28/2010 01:07 AM, Super Biscuit wrote: What? You've got the wrong idea if you think I'm spamming the list. Maybe you should go back into the history and see where I had asked for help with an ati rage 128 on a BW G3 with FreeBSD on it. --- On *Thu, 5/27/10, Justin P. Mattock /justinmatt...@gmail.com/* wrote: I don't think so.. just noticed something like this on linux-kernel so maybe something else is up.. Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: super_bisq...@yahoo.com None
On 05/28/2010 01:15 AM, Łukasz Jernaś wrote: On Fri, May 28, 2010 at 10:10 AM, Super Biscuitsuper_bisq...@yahoo.com wrote: Let me put it this way. If I am spamming the list, then anyone who uses ATT or Comcast is spamming the list. You might as well cut off half the Eastern Seaboard. You obviously didn't read the rest of this thread before posting. (hint - you weren't spamming the list) I think this thread won't die at least until Godwin's Law is fulfilled... I need verification over here please!! why: because I'm running(hopefully) bleeding edge technology, and if by chance something got messd up, well then we can go from there.. so please verify(for my sake) that I'm not doing this, (cause I' going crazy going over everything over here) Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
arch...@mail-archive.com None
On 05/27/2010 09:19 AM, Tollef Fog Heen wrote: Hi, somebody on this list appears to forward their mail to a ticketing system which spams everybody who mails the list. Earlier attempts at working out who the responsible part is has failed, so I have modified mailman a little bit to prepend the recipient to the subject field. Hopefully this should allow us to work out who the responsible part is and unsubscribe that address. Sorry for the noise. Regards, o.k... Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: matts...@gmail.com None
On 05/27/2010 09:44 AM, Matt Turner wrote: On Thu, May 27, 2010 at 12:30 PM, Tollef Fog Heen tfh...@freedesktop.org wrote: ]] Tollef Fog Heen | somebody on this list appears to forward their mail to a ticketing | system which spams everybody who mails the list. Earlier attempts at | working out who the responsible part is has failed, so I have modified | mailman a little bit to prepend the recipient to the subject field. | Hopefully this should allow us to work out who the responsible part is | and unsubscribe that address. Ok, I did a silly error in that patch to mailman, hopefully the second try should work. Again, sorry for the noise. Regards, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: matts...@gmail.com Uh, did I do something? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: justinmatt...@gmail.com I'm getting something from sourceforge (not sure if this is a bounce test or not) FWIW here is the header: From - Thu May 27 09:40:22 2010 X-Account-Key: account1 X-UIDL: GmailId128da9db6ced2430 X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Delivered-To: justinmatt...@gmail.com Received: by 10.140.201.1 with SMTP id y1cs74033rvf; Thu, 27 May 2010 09:34:49 -0700 (PDT) Received: by 10.141.101.16 with SMTP id d16mr8137540rvm.169.1274978088865; Thu, 27 May 2010 09:34:48 -0700 (PDT) Return-Path:tfh...@freedesktop.org Received: from secure.mpcustomer.com (secure.mpcustomer.com [208.43.146.75]) by mx.google.com with ESMTP id h11si2744922rvm.120.2010.05.27.09.34.48; Thu, 27 May 2010 09:34:48 -0700 (PDT) Received-SPF: neutral (google.com: 208.43.146.75 is neither permitted nor denied by best guess record for domain of tfh...@freedesktop.org) client-ip=208.43.146.75; Authentication-Results: mx.google.com; spf=neutral (google.com: 208.43.146.75 is neither permitted nor denied by best guess record for domain of tfh...@freedesktop.org) smtp.mail=tfh...@freedesktop.org Received: by secure.mpcustomer.com (Postfix, from userid 99) id 96C711540FE8; Thu, 27 May 2010 11:34:47 -0500 (CDT) To: Justin P. Mattockjustinmatt...@gmail.com Subject: [#24522234] supp...@resell.biz None Date: Thu, 27 May 2010 11:34:47 -0500 From: Tollef Fog Heentfh...@freedesktop.org Reply-To: supp...@mpcustomer.com Message-ID:fd9add30edf809f3974941d19db4c...@secure.mpcustomer.com X-Priority: 3 X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4] X-Uberinst: uber_phase-support X-Mailer: Ubersmith MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Your ticket 24522234 has been received and will be answered during our normal business hours 9-5 central time Monday through Friday. If you need your password reset please try going to http://cp.us2.net/customer and clicking forgot password. **If you are a reseller please use http://cp.us2.net/reseller If you are able to login after this suggestion please reply to this email to let us know we can close your ticket. Thank You, Hosting Services, Inc. :: resell.biz Last I remember was talking to these guys about acpid(about a year ago or so). Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: sisib...@gmail.com None
On 05/27/2010 10:03 AM, Tollef Fog Heen wrote: ]] Scott Sibley | I'm not sure why I'm spamming the list. Know how I can fix this? I | checked Gmail's settings; nothing's being forwarded through Gmail. You are/were not, even if your address appears in the Subject field, see below for the longer explanation. | What do you mean by ticketing system? This makes me nervous... My | mail's been going somewhere else? No. Let me explain what happened: Somebody managed to subscribe xorg@ to a «resell our service» system. How they did that, I'm not sure. This system would send emails to everybody emailing xorg@ saying «Thanks for your email, we'll get back to you». As they did not include enough identifying information in the «we'll get back to you» emails, I had to change the list software we use on freedesktop.org slightly. What it did include was the Subject field from the original mail. I made the mailing list software put the address of each recipient into the Subject field as it was sending out mails, and when I got the «we'll get back to you» email, it had the offending address in the subject field and I could unsubscribe them. The offender has been removed and all is now good, please go back to your regularly scheduled discussions. :-) Regards, cool!! Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: r...@reedmedia.net None
On 05/27/2010 11:13 AM, Gerald Dachs wrote: Am Thu, 27 May 2010 12:23:25 -0500 (CDT) schrieb Jeremy C. Reedr...@reedmedia.net: On Thu, 27 May 2010, Justin P. Mattock wrote: o.k... So I see a reply to the list has my email address in the subject line. That doesn't seem correct if others got the test of my email address. You are funny! Why you didn't delete your email address from the subject line before you sent your reply? Gerald ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: justinmatt...@gmail.com shit..I didn't think anything of it.. my bad.(maybe the sysadm can delete this thread since it exposes vital info). Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: r...@reedmedia.net None
On 05/27/2010 04:45 PM, Pat Kane wrote: On Thu, May 27, 2010 at 1:51 PM, Justin P. Mattock wrote: my bad.(maybe the sysadm can delete this thread since it exposes vital info). If you go here: http://lists.freedesktop.org/archives/xorg/2010-May/date.html you can see which emails contain an email address. Not a Spammer, Pat looking at the list I see mattst88 at gmail.com None http://lists.freedesktop.org/archives/xorg/2010-May/050278.html for my address, which is good, but then I ended up sending the header which had some e-mail addresses in it. (which was a mistake by me). Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ath9k-devel] [PATCH]wireless:ath9k Fix ath_print in xmit.c
On 05/27/2010 01:59 PM, Roland Dreier wrote: - Unable to stop TxDMA. Reset HAL!\n); + Unable to stop TxDMA. Reseting hardware!\n); I hate to mention it but the correct spelling is resetting. no.. mention it!! anyways the resend is here: http://thread.gmane.org/gmane.linux.kernel.wireless.general/51431 Justin P. Mattock ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath: Failed to stop TX DMA in 100 msec after killing last frame
On 05/26/2010 09:33 AM, Luis R. Rodriguez wrote: On Wed, May 26, 2010 at 12:04 AM, Justin P. Mattock justinmatt...@gmail.com wrote: This is new: [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL! I don't have hal installed!! should I be concerned? No, the print can be changed to say reseting hardware, patch welcomed. Luis sure!! let me fix that up, and also send you something else I had kicking around.. Justin P. Mattock ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH]wireless:ath9k Fix ath_print in xmit.c
ath_print in xmit.c should say Reseting hardware instead of Reaseting HAL!(since HAL is being fazed out). dmesg shows: [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL! Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/net/wireless/ath/ath9k/xmit.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c index 3db1917..2a0558e 100644 --- a/drivers/net/wireless/ath/ath9k/xmit.c +++ b/drivers/net/wireless/ath/ath9k/xmit.c @@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx) int r; ath_print(common, ATH_DBG_FATAL, - Unable to stop TxDMA. Reset HAL!\n); + Unable to stop TxDMA. Reseting hardware!\n); spin_lock_bh(sc-sc_resetlock); r = ath9k_hw_reset(ah, sc-sc_ah-curchan, false); -- 1.6.5.GIT ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath: Failed to stop TX DMA in 100 msec after killing last frame
On 05/26/2010 09:40 AM, Luis R. Rodriguez wrote: On Wed, May 26, 2010 at 9:35 AM, Justin P. Mattock justinmatt...@gmail.com wrote: On 05/26/2010 09:33 AM, Luis R. Rodriguez wrote: On Wed, May 26, 2010 at 12:04 AM, Justin P. Mattock justinmatt...@gmail.comwrote: This is new: [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL! I don't have hal installed!! should I be concerned? No, the print can be changed to say reseting hardware, patch welcomed. Luis sure!! let me fix that up, and also send you something else I had kicking around.. Sure, BTW, no need to use lkml unless you need further review, use instead just linux-wireless for patches/raves/rants for 802.11. In fact you can drop ath9k-devel when using linux-wireless. Luis alright!! (and of course after pressing send I get this post!!) Anyways I'll send another patch that I was experimenting with(just to see!!). cheers, Justin P. Mattock ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH]wireless:ath9k Fix ath_print in xmit.c
On 05/26/2010 10:05 AM, Luis R. Rodriguez wrote: On Wed, May 26, 2010 at 9:49 AM, Justin P. Mattock justinmatt...@gmail.com wrote: ath_print in xmit.c should say Reseting hardware instead of Reaseting HAL!(since HAL is being fazed out). dmesg shows: [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL! Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/net/wireless/ath/ath9k/xmit.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c index 3db1917..2a0558e 100644 --- a/drivers/net/wireless/ath/ath9k/xmit.c +++ b/drivers/net/wireless/ath/ath9k/xmit.c @@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx) int r; ath_print(common, ATH_DBG_FATAL, - Unable to stop TxDMA. Reset HAL!\n); + Unable to stop TxDMA. Reseting hardware!\n); Thanks for the patch but you need to send this to John, cc linux-wireless. Luis I'll resend with the proper Cc's Justin P. mattock ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH]wireless:ath9k Fix ath_print in xmit.c
Oops.. should be: http://thread.gmane.org/gmane.linux.kernel.wireless.general/51431 Justin P. Mattock ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH]wireless:ath9k Fix ath_print in xmit.c
On 05/26/2010 04:06 PM, Peter Stuge wrote: Justin P. Mattock wrote: ath_print in xmit.c should say Reseting hardware I think that should be Resetting hardware with two t:s. //Peter yep!! here is the updated version.. http://thread.gmane.org/gmane.linux.kernel.wireless.general (duh!! I didn't even think about that) Thanks for the response. Justin P. Mattock ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [PATCH][bisected]pcmcia:yenta_socket.c fix broken wireless cards.
On 05/20/2010 09:34 AM, Dominik Brodowski wrote:
Jens, Justin,
could both of you test this patch on top of 2.6.34, please?
pcmcia: only keep saved I365_CSCING flag if there is no PCI irq
Signed-off-by: Dominik Brodowskili...@dominikbrodowski.net
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
index 424e576..151ca43 100644
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -371,8 +371,11 @@ static int yenta_set_socket(struct pcmcia_socket *sock,
socket_state_t *state)
exca_writeb(socket, I365_POWER, reg);
/* CSC interrupt: no ISA irq for CSC */
- reg = exca_readb(socket, I365_CSCINT);
- reg= I365_CSC_IRQ_MASK;
+ reg = 0;
+ if (!socket-dev-irq) {
+ reg = exca_readb(socket, I365_CSCINT);
+ reg= I365_CSC_IRQ_MASK;
+ }
reg |= I365_CSC_DETECT;
if (state-flags SS_IOCARD) {
if (state-csc_mask SS_STSCHG)
o.k. finally built the kernel
with this machine..
with the current head, there is
no fix, after applying your patch
to the current, seems this thing is still
broken. here is some info from dmesg
with the current head with your patch on top:
agpgart-intel :00:00.0: Intel 915GM Chipset
[9.700307] agpgart-intel :00:00.0: detected 7932K stolen memory
[9.773503] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xc000
[9.824628] yenta_cardbus :02:01.0: CardBus bridge found [1028:01a6]
[9.824657] yenta_cardbus :02:01.0: Using CSCINT to route CSC
interrupts to PCI
[9.824661] yenta_cardbus :02:01.0: Routing CardBus interrupts to PCI
[9.824669] yenta_cardbus :02:01.0: TI: mfunc 0x1002, devctl 0x64
[9.914482] input: Video Bus as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/LNXVIDEO:00/input/input2
[9.914614] ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[9.914658] [Firmware Bug]: Duplicate ACPI video bus devices for the
same VGA controller, please try module parameter
video.allow_duplicates=1if the current driver doesn't work.
[ 10.286343] yenta_cardbus :02:01.0: TI: probing PCI interrupt
failed, trying to fix
[ 10.387050] yenta_cardbus :02:01.0: Yenta TI: no PCI interrupts.
Fish. Please report.
[ 10.387062] yenta_cardbus :02:01.0: no PCI IRQ, CardBus support
disabled for this socket.
[ 10.387066] yenta_cardbus :02:01.0: check your BIOS CardBus, BIOS
IRQ or ACPI settings.
[ 10.490080] Synaptics Touchpad, model: 1, fw: 6.2, id: 0x8fa0b1,
caps: 0xa04713/0x20/0x0
[ 10.531380] input: SynPS/2 Synaptics TouchPad as
/devices/platform/i8042/serio1/input/input3
power_supply BAT0: prop SERIAL_NUMBER=4211
[ 10.696902] yenta_cardbus :02:01.0: ISA IRQ mask 0x0cf8, PCI irq 0
[ 10.696910] yenta_cardbus :02:01.0: Socket status: 3020
[ 10.696916] pci_bus :02: Raising subordinate bus# of parent bus
(#02) from #03 to #06
[ 10.696935] yenta_cardbus :02:01.0: pcmcia: parent PCI bridge
window: [io 0xd000-0xdfff]
[ 10.696941] yenta_cardbus :02:01.0: pcmcia: parent PCI bridge
window: [mem 0xdfd0-0xdfdf]
[ 10.696948] pcmcia_socket pcmcia_socket0: cs: memory probe
0xdfd0-0xdfdf: excluding 0xdfd0-0xdfd0 0xdfdf-0xdfdf
[ 10.697033] yenta_cardbus :02:01.0: pcmcia: parent PCI bridge
window: [mem 0x2000-0x23ff pref]
[ 10.697039] pcmcia_socket pcmcia_socket0: cs: memory probe
0x2000-0x23ff: excluding 0x2000-0x23ff
[ 10.727273] pcmcia_socket pcmcia_socket0: cs: memory probe
0x0c-0x0f: excluding 0xc-0xc7fff 0xcc000-0xc 0xf-0xf
[ 10.727541] pcmcia_socket pcmcia_socket0: cs: memory probe
0xa000-0xa0ff: clean.
[ 10.727801] pcmcia_socket pcmcia_socket0: cs: memory probe
0x6000-0x60ff: clean.
[ 10.823429] Intel ICH :00:1e.2: PCI INT A - GSI 16 (level, low)
- IRQ 16
[ 10.823487] Intel ICH :00:1e.2: setting latency timer to 64
[ 11.070034] pcmcia_socket pcmcia_socket0: cardbus cards are not
supported.
[ 11.134038] intel8x0_measure_ac97_clock: measured 50713 usecs (2444
samples)
[ 11.134044] intel8x0: clocking to 48000
this is all the info I see in dmesg on this machine
(if you need full log let me know).
Justin P. Mattock
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[PATCH]pacmcia:yena_socket.c Remove extra #ifdef CONFIG_YENTA_TI
Seems pointless to have two #ifdef's with the same
CONFIG_YENTA_TI.. Remove the extra one and
move CARDBUS_TYPE_ENE with the others.
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
drivers/pcmcia/yenta_socket.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
index 83ace27..5a09bbb 100644
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -880,6 +880,12 @@ static struct cardbus_type cardbus_type[] = {
.restore_state = ti_restore_state,
.sock_init = ti_init,
},
+ [CARDBUS_TYPE_ENE] = {
+ .override = ene_override,
+ .save_state = ti_save_state,
+ .restore_state = ti_restore_state,
+ .sock_init = ti_init,
+ },
#endif
#ifdef CONFIG_YENTA_RICOH
[CARDBUS_TYPE_RICOH]= {
@@ -902,14 +908,6 @@ static struct cardbus_type cardbus_type[] = {
.restore_state = o2micro_restore_state,
},
#endif
-#ifdef CONFIG_YENTA_TI
- [CARDBUS_TYPE_ENE] = {
- .override = ene_override,
- .save_state = ti_save_state,
- .restore_state = ti_restore_state,
- .sock_init = ti_init,
- },
-#endif
};
--
1.6.5.2.180.gc5b3e
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[PATCH][bisected]pcmcia:yenta_socket.c fix broken wireless cards.
I've an old dell inspiron 1200(amazingly still works), that use's a D-Link DWL-G650, and/or a Dell Wireless 1350 for it's wireless connection. With using opensuse11.2(kernel:2.6.32*), the card(s) work fine, but as soon as I pulled the latest HEAD, all hell broke loose. So after doing a days worth of bisecting with this machine(painfully slow), it finally came down to this commit: commit 28ca8dd71fc170090edca62cb8129625d01b7760 Author: Jens KC3BCnzer jens.kuen...@fpga.homeip.net Date: Sat Mar 6 07:46:16 2010 +0100 pcmcia: honor saved flags in yenta_socket's I365_CSCINT register Instead of overwriting the I365_CSCINT register, save the old value and merely change the bits we care about. Part 1 of a series to allow the ISA irq to be used for Cardbus devices if the socket's PCI irq is unusable. [li...@dominikbrodowski.net: split up the original patch, commit message] Signed-off-by: Jens Kuenzer jens.kuen...@fpga.homeip.net Signed-off-by: Dominik Brodowski li...@dominikbrodowski.net so after fussing around with this commit, and yenta_socket.c I come up with something, that does get my cards powered up, and all good(hopefully). Anyways please have a look, if you need me to test something different let me know. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/pcmcia/yenta_socket.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c index 83ace27..7d6f43b 100644 --- a/drivers/pcmcia/yenta_socket.c +++ b/drivers/pcmcia/yenta_socket.c @@ -989,7 +989,7 @@ static int yenta_probe_cb_irq(struct yenta_socket *socket) } /* generate interrupt, wait */ - reg = exca_readb(socket, I365_CSCINT); + reg = exca_readb(socket, I365_CSCINT | I365_CSC_ANY); exca_writeb(socket, I365_CSCINT, reg | I365_CSC_STSCHG); cb_writel(socket, CB_SOCKET_EVENT, -1); cb_writel(socket, CB_SOCKET_MASK, CB_CSTSMASK); -- 1.6.5.2.180.gc5b3e ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Regarding Instalation of powertop
‘show_acpi_power_line’: display.c:193: error: ‘acpi_power_window’ undeclared (first use in this function) display.c: In function ‘show_wakeups’: display.c:211: error: ‘wakeup_window’ undeclared (first use in this function) display.c:219: error: ‘A_BOLD’ undeclared (first use in this function) display.c: In function ‘show_timerstats’: display.c:227: error: ‘timerstat_window’ undeclared (first use in this function) display.c:235: error: ‘A_BOLD’ undeclared (first use in this function) display.c: In function ‘show_suggestion’: display.c:258: error: ‘suggestion_window’ undeclared (first use in this function) make: *** [display.o] Error 1 ___ Power mailing list Power@bughost.org http://www.bughost.org/mailman/listinfo/power you need: libncurses-dev headers installed display.c:32:21: error: ncurses.h: No such file or directory Justin P. Mattock ___ Power mailing list Power@bughost.org http://www.bughost.org/mailman/listinfo/power
Re: r128 on freebsd powerpc will not work
On 04/25/2010 11:28 PM, Super Biscuit wrote: --- On *Mon, 4/26/10, Justin P. Mattock /justinmatt...@gmail.com/* wrote: From: Justin P. Mattock justinmatt...@gmail.com Subject: Re: r128 on freebsd powerpc will not work To: xorg@lists.freedesktop.org Date: Monday, April 26, 2010, 5:50 AM On 04/25/2010 09:12 PM, Super Biscuit wrote: http://omploader.org/vNGExZA /root/xorg.conf.new http://omploader.org/vNGExZQ I have the r128 drivers but they don't seem to be loading. I added AllowEmptyInput . Any other information, let me know. Thanks. if you can post your Xorg.0.log so people can see what might be going on. (if you get a black screen, then remote debug for the log). Justin P. Mattock ___ xorg@lists.freedesktop.org /mc/compose?to=x...@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg The links are to the xorg log. I am not able to post from the machine I need help with. So, I am giving you pastebin and ompload. I will forward the mail from the freebsd-ppc list so that you and others can go through the links and see what progress I have tried. Please click on the link to see the file. http://omploader.org/vNGEyOQ this is with startx -- -logverbose 9 -logfile /var/log/Xorg.0.log first thing I see: Parse error on line 6 of section ServerLayout in file /etc/X11/xorg.conf AllowEmptyInput is not a valid keyword in this section. seems you have it set wrong in xorg.conf my xorg.conf has that entry like this: Section ServerFlags Option AllowEmptyInput off EndSection second issue that I see is this: r...@dynode.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC powerpc you shouldn't start the xserver as root(vary unsafe, and also might be causing issues). hope this helps. Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fw: Re: Update:Xorg build and performance.
On 04/26/2010 12:33 AM, Alex Deucher wrote: On Mon, Apr 26, 2010 at 3:20 AM, Justin P. Mattock justinmatt...@gmail.com wrote: On 04/25/2010 11:30 PM, Super Biscuit wrote: Please read all of this. --- On *Sun, 4/25/10, Super Biscuit /super_bisq...@yahoo.com/* wrote: From: Super Biscuitsuper_bisq...@yahoo.com Subject: Re: Update:Xorg build and performance. To: Nathan Whitehornnwhiteh...@freebsd.org Cc: freebsd-...@freebsd.org Date: Sunday, April 25, 2010, 10:38 PM --- On *Sun, 4/25/10, Nathan Whitehorn /nwhiteh...@freebsd.org/* wrote: From: Nathan Whitehornnwhiteh...@freebsd.org Subject: Re: Update:Xorg build and performance. To: Super Biscuitsuper_bisq...@yahoo.com Cc: freebsd-...@freebsd.org Date: Sunday, April 25, 2010, 10:23 PM On 04/25/10 16:40, Super Biscuit wrote: --- On *Sun, 4/25/10, Nathan Whitehorn /nwhiteh...@freebsd.org/* wrote: From: Nathan Whitehornnwhiteh...@freebsd.org Subject: Re: Update:Xorg build and performance. To: Super Biscuitsuper_bisq...@yahoo.com Date: Sunday, April 25, 2010, 9:21 PM On 04/25/10 16:06, Super Biscuit wrote: --- On *Sun, 4/25/10, Nathan Whitehorn /nwhiteh...@freebsd.org/* wrote: From: Nathan Whitehornnwhiteh...@freebsd.org Subject: Re: Update:Xorg build and performance. To: Super Biscuitsuper_bisq...@yahoo.com Date: Sunday, April 25, 2010, 8:38 PM On 04/25/10 15:16, Super Biscuit wrote: --- On *Sun, 4/25/10, Nathan Whitehorn /nwhiteh...@freebsd.org/* wrote: From: Nathan Whitehornnwhiteh...@freebsd.org Subject: Re: Update:Xorg build and performance. To: Super Biscuitsuper_bisq...@yahoo.com Date: Sunday, April 25, 2010, 6:53 PM Super Biscuit wrote: --- On *Sun, 4/25/10, Nathan Whitehorn /nwhiteh...@freebsd.org/* wrote: From: Nathan Whitehornnwhiteh...@freebsd.org Subject: Re: Update:Xorg build and performance. To: Super Biscuitsuper_bisq...@yahoo.com Cc: Garrett Cooperyanef...@gmail.com, freebsd-...@freebsd.org Date: Sunday, April 25, 2010, 3:09 PM Super Biscuit wrote: --- On Sat, 4/24/10, Garrett Cooper yanef...@gmail.com /mc/compose?to=yanef...@gmail.com wrote: From: Garrett Cooperyanef...@gmail.com /mc/compose?to=yanef...@gmail.com Subject: Re: Update:Xorg build and performance. To: Super Biscuitsuper_bisq...@yahoo.com /mc/compose?to=super_bisq...@yahoo.com Date: Saturday, April 24, 2010, 10:12 AM On Sat, Apr 24, 2010 at 2:57 AM, Super Biscuit super_bisq...@yahoo.com /mc/compose?to=super_bisq...@yahoo.com wrote: --- On Fri, 4/23/10, Olivier Gautherot oliv...@gautherot.net /mc/compose?to=oliv...@gautherot.net wrote: From: Olivier Gautherotoliv...@gautherot.net /mc/compose?to=oliv...@gautherot.net Subject: Re: Update:Xorg build and performance. To: Super Biscuitsuper_bisq...@yahoo.com /mc/compose?to=super_bisq...@yahoo.com Cc: Nathan Whitehornnwhiteh...@freebsd.org /mc/compose?to=nwhiteh...@freebsd.org, freebsd-...@freebsd.org /mc/compose?to=freebsd-...@freebsd.org Date: Friday, April 23, 2010, 8:06 PM Hi, On Fri, Apr 23, 2010 at 3:55 PM, Super Biscuit super_bisq...@yahoo.com /mc/compose?to=super_bisq...@yahoo.com wrote: Xorg still does not start. No screens found I added then removed the fbdev. Will I need to compile Xorg without fbdev? The file xorg.conf is non existent on my system
Re: r128 on freebsd powerpc will not work
On 04/26/2010 12:35 AM, Super Biscuit wrote: --- On *Mon, 4/26/10, Justin P. Mattock /justinmatt...@gmail.com/* wrote: From: Justin P. Mattock justinmatt...@gmail.com Subject: Re: r128 on freebsd powerpc will not work To: Super Biscuit super_bisq...@yahoo.com Cc: xorg@lists.freedesktop.org Date: Monday, April 26, 2010, 7:10 AM On 04/25/2010 11:28 PM, Super Biscuit wrote: --- On *Mon, 4/26/10, Justin P. Mattock /justinmatt...@gmail.com /mc/compose?to=justinmatt...@gmail.com/* wrote: From: Justin P. Mattock justinmatt...@gmail.com /mc/compose?to=justinmatt...@gmail.com Subject: Re: r128 on freebsd powerpc will not work To: xorg@lists.freedesktop.org /mc/compose?to=x...@lists.freedesktop.org Date: Monday, April 26, 2010, 5:50 AM On 04/25/2010 09:12 PM, Super Biscuit wrote: http://omploader.org/vNGExZA /root/xorg.conf.new http://omploader.org/vNGExZQ I have the r128 drivers but they don't seem to be loading. I added AllowEmptyInput . Any other information, let me know. Thanks. if you can post your Xorg.0.log so people can see what might be going on. (if you get a black screen, then remote debug for the log). Justin P. Mattock ___ xorg@lists.freedesktop.org /mc/compose?to=x...@lists.freedesktop.org /mc/compose?to=x...@lists.freedesktop.org /mc/compose?to=x...@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg The links are to the xorg log. I am not able to post from the machine I need help with. So, I am giving you pastebin and ompload. I will forward the mail from the freebsd-ppc list so that you and others can go through the links and see what progress I have tried. Please click on the link to see the file. http://omploader.org/vNGEyOQ this is with startx -- -logverbose 9 -logfile /var/log/Xorg.0.log first thing I see: Parse error on line 6 of section ServerLayout in file /etc/X11/xorg.conf AllowEmptyInput is not a valid keyword in this section. seems you have it set wrong in xorg.conf my xorg.conf has that entry like this: Section ServerFlags Option AllowEmptyInput off EndSection second issue that I see is this: r...@dynode.isc.freebsd.org /mc/compose?to=r...@dynode.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC powerpc you shouldn't start the xserver as root(vary unsafe, and also might be causing issues). hope this helps. Justin P. Mattock That part r...@blahblah will result if you type uname -a from the terminal on any FreeBSD machine. It's the path to the kernel. Okay. I adjusted the option and I removed the default depth section. It works and freezes. are you able to remotly login t the machine and grab the log files?(before it freezes). I prefer to use ohci1394_dma=early Justin . Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: r128 on freebsd powerpc will not work
On 04/25/2010 09:12 PM, Super Biscuit wrote: http://omploader.org/vNGExZA /root/xorg.conf.new http://omploader.org/vNGExZQ I have the r128 drivers but they don't seem to be loading. I added AllowEmptyInput . Any other information, let me know. Thanks. if you can post your Xorg.0.log so people can see what might be going on. (if you get a black screen, then remote debug for the log). Justin P. Mattock ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error
On 04/18/2010 10:35 PM, Ben Gamari wrote: On Sun, 18 Apr 2010 21:19:19 -0700, Justin Mattockjustinmatt...@gmail.com wrote: so far I've compiled most of the system (glibc,Xserver,etc..) and not really anything has crashed and burned except for the kernel: You are using a pre-release compiler. It should be no surprise that it chokes on the kernel. You should do as the compiler said and report this to the gcc folks. - Ben I couldn't resist..(had to play), anyways I looked through the reports but didn't see anything that was familiar. so I went and created an entry: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791 Justin P. Mattock
Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error
On 04/18/2010 11:57 PM, Jie Zhang wrote: On 04/19/2010 02:43 PM, Justin P. Mattock wrote: I couldn't resist..(had to play), anyways I looked through the reports but didn't see anything that was familiar. so I went and created an entry: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791 Thanks. Please add a preprocessed source file so people can reproduce your issue. as for the preprocessed source file, not that yet skilled at code.(one day) I added my .config, and the CFLAGS I used for building gcc. In regards to 4.6.0 everything seems o.k. i.g. glibc builds with no errors all of the xserver no errors, even firefox builds.. seems the kernel was the only real problem I ran into(which isn't really a problem given this version of gcc is experimental). maybe something todo with building modules (but could be wrong). Justin P. Mattock
Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error
On 04/19/2010 02:17 PM, Jonathan Wakely wrote: On 19 April 2010 08:20, Justin P. Mattock wrote: On 04/18/2010 11:57 PM, Jie Zhang wrote: On 04/19/2010 02:43 PM, Justin P. Mattock wrote: I couldn't resist..(had to play), anyways I looked through the reports but didn't see anything that was familiar. so I went and created an entry: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791 Thanks. Please add a preprocessed source file so people can reproduce your issue. as for the preprocessed source file, not that yet skilled at code.(one day) See the how to report link on the gcc front page: http://gcc.gnu.org/bugs/ It's not hard. the info from jie, worked, as well as: make kernel/rtmutex.i (from joe perches) Justin P. Mattock
Re: [PATCH] Cosmetic:Partially remove deprecated __initcall() and change to
On 03/21/2010 05:33 PM, Randy Dunlap wrote: On 03/19/10 16:24, Justin P. Mattock wrote: On 03/19/2010 03:56 PM, Randy Dunlap wrote: On 03/19/10 12:51, Justin P. Mattock wrote: After doing some things on a small issue, I noticed through web surfing, that there were patches submitted pertaining that __initcall is deprecated, and device_initcall should be used. Where was this discussion? Do you have any pointers to it? The best info on this is scripts/checkpatch.pl line #2664 when I found this I just did a quick search of __initcall (which gives hits here and there) https://patchwork.kernel.org/patch/23344/ (also found others at around 2008 or so) Thanks. IMO there should be something in the kernel source tree that says explicitly that __initcall is deprecated and should be replaced by usingwhatever should be used. That's missing. agree.. I should of searched the source tree for something that says deprecated and so forth before doing anything(the checkpatch.pl was something I noticed down the line but doesn't say deprecated(say's explicitly). I don't see any mention of __initcall being deprecated in Linus' mainline git tree, or in linux-next, or in mmotm. Where are those patches? I don't know(I'm out of the social pipeline when it comes to Linux news, and updates).. like in the explanation part of the patch I was looking into something else, then ran into this, so as a break(from what I was originally doing) decided to do this and submit. So as a change of subject(since what I was looking at was frustrating me),I decided to grep the whole tree and make the change(partially). Currently I'm running this patch on my system, kernel compiles without any errors or warnings.(thought there would be a speed increase but didn't see much(if any)). No, __initcall(x) is just a shorthand version of typing device_initcall(x). They do the same thing. yep, that's what I found out as well(reason for the cosmetic in the subject line). Biggest problem I have though is testing this on other hardware types (I only have a macbook,and an iMac). So please if you have the access to other arch/hardware types please test. Now what I mean by partially is the __initcall function is still there, so(if any) userspace apps/libs depend on this it's there so they dont break and/or any other subsystem, that needs time to make the changes. The only thing that might be affected is building out-of-tree drivers, but those are easy to fix. alright..main concern is making sure things don't break in the kernel(even though things do). I can have a go at the header files, submit then if it's something people agree they want to do, then they can go from there(if not it's fine as well). Note: the remaining files that still have __initcall in them are: (according to grep) arch/um/include/shared/init.h include/linux/init.h scripts/checkpatch.pl either I or somebody else, can change this(although a bit concerned about breaking things). Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- In any case I'll leave this to you guys to decide. The patch is in cyberspace now, so if/when this ever is decided it's there(patch), then can be used then. Justin P. Mattock -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [Uclinux-dist-devel] [PATCH] Cosmetic:Partially remove deprecated __initcall() and change to
On 03/21/2010 05:33 PM, Randy Dunlap wrote: On 03/19/10 16:24, Justin P. Mattock wrote: On 03/19/2010 03:56 PM, Randy Dunlap wrote: On 03/19/10 12:51, Justin P. Mattock wrote: After doing some things on a small issue, I noticed through web surfing, that there were patches submitted pertaining that __initcall is deprecated, and device_initcall should be used. Where was this discussion? Do you have any pointers to it? The best info on this is scripts/checkpatch.pl line #2664 when I found this I just did a quick search of __initcall (which gives hits here and there) https://patchwork.kernel.org/patch/23344/ (also found others at around 2008 or so) Thanks. IMO there should be something in the kernel source tree that says explicitly that __initcall is deprecated and should be replaced by usingwhatever should be used. That's missing. agree.. I should of searched the source tree for something that says deprecated and so forth before doing anything(the checkpatch.pl was something I noticed down the line but doesn't say deprecated(say's explicitly). I don't see any mention of __initcall being deprecated in Linus' mainline git tree, or in linux-next, or in mmotm. Where are those patches? I don't know(I'm out of the social pipeline when it comes to Linux news, and updates).. like in the explanation part of the patch I was looking into something else, then ran into this, so as a break(from what I was originally doing) decided to do this and submit. So as a change of subject(since what I was looking at was frustrating me),I decided to grep the whole tree and make the change(partially). Currently I'm running this patch on my system, kernel compiles without any errors or warnings.(thought there would be a speed increase but didn't see much(if any)). No, __initcall(x) is just a shorthand version of typing device_initcall(x). They do the same thing. yep, that's what I found out as well(reason for the cosmetic in the subject line). Biggest problem I have though is testing this on other hardware types (I only have a macbook,and an iMac). So please if you have the access to other arch/hardware types please test. Now what I mean by partially is the __initcall function is still there, so(if any) userspace apps/libs depend on this it's there so they dont break and/or any other subsystem, that needs time to make the changes. The only thing that might be affected is building out-of-tree drivers, but those are easy to fix. alright..main concern is making sure things don't break in the kernel(even though things do). I can have a go at the header files, submit then if it's something people agree they want to do, then they can go from there(if not it's fine as well). Note: the remaining files that still have __initcall in them are: (according to grep) arch/um/include/shared/init.h include/linux/init.h scripts/checkpatch.pl either I or somebody else, can change this(although a bit concerned about breaking things). Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- In any case I'll leave this to you guys to decide. The patch is in cyberspace now, so if/when this ever is decided it's there(patch), then can be used then. Justin P. Mattock ___ Uclinux-dist-devel mailing list Uclinux-dist-devel@blackfin.uclinux.org https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
Re: [git pull] drm request 3
On 03/05/2010 09:42 AM, Jeff Garzik wrote: On 03/05/2010 10:17 AM, Daniel Stone wrote: On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. Maybe the lesson to be learned from all this is, 'if the developers don't want something merged because they're not ready and forsee huge problems in the future, actually listen to them instead of blindly ramming it in regardless'? But maybe that's just me. That particular horse left the barn when Fedora shipped nouveau in a stable release, not when Linus merged it into his tree. Jeff -- 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/ stopped me in my tracks i.g. in order to install using the livecd requires brain surgery. (for me that's fine, but for an average business person/s forget it). Justin P. Mattock -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Who is using NSS in their projects?
On 03/03/2010 10:45 AM, Gen Kanai wrote: On 3/3/10 10:31 AM, Jean-Marc Desperrier wrote: davidwboswell wrote: I maintain a list of applications that use Mozilla technologies in their projects and wanted to add more examples of projects that use NSS. You obviously forgot to include Google Chrome in the list !! ;-) The full list is here: (and Chrome is listed as using NSS, NPAPI, NSPR) https://developer.mozilla.org/En/List_of_Mozilla-Based_Applications Gen ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security there's also glibc that uses this stuff Justin P. Mattock ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
[PATCH] This fixes an error with compiling the xserver with SELinux enabled.
): undefined reference to `freecon'
xselinux_label.c:(.text+0x334): undefined reference to `freecon'
../../Xext/.libs/libXext.a(xselinux_label.o): In function `SELinuxEventToSID':
xselinux_label.c:(.text+0x3be): undefined reference to `avc_compute_create'
xselinux_label.c:(.text+0x404): undefined reference to `selabel_lookup_raw'
xselinux_label.c:(.text+0x416): undefined reference to `avc_context_to_sid_raw'
xselinux_label.c:(.text+0x423): undefined reference to `freecon'
xselinux_label.c:(.text+0x4a3): undefined reference to `freecon'
../../Xext/.libs/libXext.a(xselinux_label.o): In function `SELinuxAtomToSID':
xselinux_label.c:(.text+0x5b8): undefined reference to `selabel_lookup_raw'
xselinux_label.c:(.text+0x5d0): undefined reference to `avc_context_to_sid_raw'
xselinux_label.c:(.text+0x5de): undefined reference to `freecon'
xselinux_label.c:(.text+0x623): undefined reference to `selabel_lookup_raw'
xselinux_label.c:(.text+0x641): undefined reference to `freecon'
../../Xext/.libs/libXext.a(xselinux_label.o): In function
`SELinuxPropertyToSID':
xselinux_label.c:(.text+0x6e5): undefined reference to `avc_compute_create'
xselinux_label.c:(.text+0x725): undefined reference to `avc_compute_member'
../../Xext/.libs/libXext.a(xselinux_label.o): In function
`SELinuxSelectionToSID':
xselinux_label.c:(.text+0x7e3): undefined reference to `avc_compute_member'
collect2: ld returned 1 exit status
make[3]: *** [Xvfb] Error 1
make[3]: Leaving directory `/home/kernel/xserver/xserver/hw/vfb'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/kernel/xserver/xserver/hw/vfb'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/kernel/xserver/xserver/hw'
make: *** [all-recursive] Error 1
Posted here:
http://www.pubbs.net/xorg/201002/61107/
Reported-by: Harald Braumann ha...@unheit.net
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index b9c7574..8713673 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1431,7 +1431,7 @@ PKG_CHECK_MODULES([XSERVERLIBS], [$REQUIRED_LIBS])
#
XSERVER_CFLAGS=${XSERVER_CFLAGS} ${XSERVERCFLAGS_CFLAGS}
XSERVER_LIBS=$DIX_LIB $CONFIG_LIB $MI_LIB $OS_LIB
-XSERVER_SYS_LIBS=${XSERVERLIBS_LIBS} ${SYS_LIBS} ${LIBS}
+XSERVER_SYS_LIBS=${XSERVERLIBS_LIBS} ${SYS_LIBS} ${LIBS} ${SELINUX_LIBS}
AC_SUBST([XSERVER_LIBS])
AC_SUBST([XSERVER_SYS_LIBS])
--
1.6.5.GIT
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: FTBFS with selinux enabled
On 02/25/2010 04:40 PM, Eamon Walsh wrote:
On 02/25/2010 06:31 PM, Harald Braumann wrote:
Hi,
xserver fails to build, if selinux is enabled (git master as of today).
Affected are all the servers, except xfree86 (hw/{dmx,kdrive,vfb,xnest},
didn't test quartz and xwin). The problem seems to be, that the linker
flag for selinux is missing. If I add -lselinux to *_LDADD in the
Makefiles, it works. xfree86 works, because $SELINUX_LIBS is added
to XORG_SYS_LIBS in configure.ac, if selinux is enabled.
Shouldn't the same be done for the other *_SYS_LIBS variables in
configure.ac? Or amidoinitwrong?
OK, I can reproduce this, thanks for the report.
I think the solution is to add SELINUX_LIBS to XSERVER_SYS_LIBS.
Everything should pick it up then.
glad you posted this.. I was building the protocol headers
as I saw this.
Anyways I posted a patch that gets xserver to compile
hopefully It's correct with the info from both of you guys.
let me know if there's more needed.
Justin P. mattock
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0
On 02/21/2010 01:42 PM, Rafael J. Wysocki wrote: This message has been generated automatically as a part of a report of regressions introduced between 2.6.31 and 2.6.32. The following bug entry is on the current list of known regressions introduced between 2.6.31 and 2.6.32. Please verify if it still should be listed and let the tracking team know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14487 Subject : PANIC: early exception 08 rip 246:10 error 810251b5 cr2 0 Submitter : Justin P. Mattockjustinmatt...@gmail.com Date: 2009-10-23 16:45 (122 days old) References : http://lkml.org/lkml/2009/10/23/252 Handled-By : Jan Beulichjbeul...@novell.com -- 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/ yeah still here.. worst is I'm able to see this with suse11.2 as well as with my custom system. so please leave open. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe kernel-testers in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Running rc.d programs under a different user
On 02/06/10 22:11, Charles Solar wrote:
LFS is working great, and I can safely say I know much more about linux
then I did before going through the book, so thanks to all those who
contributed.
I am wrapping up my fileserver built from LFS SVN 2010-01-09 and I am
trying to find a way to run a daemon process as a different user.
In the book we only used the apps config file to specify a different
user, ex, svn, proftpd. But I want to run Deluge under a different user
and it does not have a config option for this. So I am wondering if
there is some way I am 'supposed' to setup the init script to do this.
I am trying to avoid installing any more unnecessary programs like
daemon and start-stop-daemon so any advice is appreciated.
Basically I want to mimic the provided example init scripts from here
http://dev.deluge-torrent.org/wiki/UserGuide/InitScript
This is what I am using at the moment
#!/bin/sh
# Deluge daemon startup
. /etc/sysconfig/rc
. $rc_functions
case $1 in
start)
boot_mesg Starting deluged service...
loadproc -p /var/run/deluged.pid /usr/sbin/deluged -c
/etc/deluge/ -p 58840 -l /var/log/deluged.log
RETVAL=$?
if [ $RETVAL -eq 0 ] ; then
boot_mesg Starting deluge web ui...
loadproc -p /var/run/webluge.pid
/usr/sbin/deluge-web -f -c /etc/deluge/ -l /var/log/webluged.log
fi
;;
stop)
boot_mesg Stopping deluged service...
killproc /usr/sbin/deluged
boot_mesg Stopping deluge web ui...
killproc /usr/sbin/deluge-web
;;
restart)
$0 stop
sleep 1
$0 start
;;
status)
statusproc /usr/bin/deluged
;;
*)
echo Usage: $0 {start|stop|restart|status}
exit 1
;;
esac
I checked out the functions library and did not see anything jump out at me.
Thanks
not sure..
first is you probably should post this on
blfs or something(so people don't bi*ch
and complain), but as for different user
tough to say I would test/try setting the user as root
maybe or something(but if this daemon checks /etc/group*shadow
for the user logging in then things might be trick).
hope this helps.
Justin P. Mattock
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0
On 02/07/10 16:28, Rafael J. Wysocki wrote: This message has been generated automatically as a part of a report of regressions introduced between 2.6.31 and 2.6.32. The following bug entry is on the current list of known regressions introduced between 2.6.31 and 2.6.32. Please verify if it still should be listed and let the tracking team know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14487 Subject : PANIC: early exception 08 rip 246:10 error 810251b5 cr2 0 Submitter : Justin P. Mattockjustinmatt...@gmail.com Date: 2009-10-23 16:45 (108 days old) References : http://lkml.org/lkml/2009/10/23/252 Handled-By : Jan Beulichjbeul...@novell.com Patch : http://patchwork.kernel.org/patch/68719/ the patch attached to the bug report makes my machine boot up with out a Panic, and allows me to do remote debugging via ohci1394_dma. I did see a call trace as I was debugging which might be related to having one system using the patch, and the other not. but still need to look at that. (only saw this once out of numerous boots (could be a rarity)). Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe kernel-testers in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
