from:"Andreas Steinmetz"

Jan Engelhardt wrote:
> Do you really need clamping? It's a hack, since TCP should do MSS negotiation
> itself. (Of course it may happen that some routers are broken.) But usually 
> not
> for incoming packets.

You never know when you hit ICMP blackholes, broken routers and other
evil things. Better safe than sorry so clamping is the way to go for me.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mss to pmtu clamping partially broken?

Patrick McHardy wrote:
> Its possible that one of your ISPs is doing clamping. You could
> check on ppp0 if thats the case. Or maybe for some reason the
> PMTU value for the internal host is smaller than 1500. You can
> check that by doing "ip route get ".
> 
> 

Oh well, thew fun with ISPs. Same provider, clamping on one line but not
the other. This is fun :-(

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mss to pmtu clamping partially broken?

Patrick McHardy wrote:
 Its possible that one of your ISPs is doing clamping. You could
 check on ppp0 if thats the case. Or maybe for some reason the
 PMTU value for the internal host is smaller than 1500. You can
 check that by doing ip route get internal host.
 
 

Oh well, thew fun with ISPs. Same provider, clamping on one line but not
the other. This is fun :-(

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mss to pmtu clamping partially broken?

Jan Engelhardt wrote:
 Do you really need clamping? It's a hack, since TCP should do MSS negotiation
 itself. (Of course it may happen that some routers are broken.) But usually 
 not
 for incoming packets.

You never know when you hit ICMP blackholes, broken routers and other
evil things. Better safe than sorry so clamping is the way to go for me.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mss to pmtu clamping partially broken?

Patrick McHardy wrote:
> Andreas Steinmetz wrote:
>> Patrick McHardy wrote:
>>
>>> - assuming you have ethernet internally, the PMTU from your router
>>> to the internal hosts is 1500, so it won't do any clamping.
>>>
>>
>> Yep, internal PMTU is 1500, still the incoming packets are clamped to
>> 1452 on the one line and not clamped on the other.
>>
>>
>>> Does that explain it?
>>>
>>> A useful thing for TCPMSS for routers would be to clamp to the
>>> minimum of the PMTU of both directions. But thats not supported
>>> so far.
>>>
>>
>> I wonder, as somteimes it gets clamped. If it would never have been
>> clamped I wouldn't have asked.
> 
> 
> Its possible that one of your ISPs is doing clamping. You could

This would be fun as it is the same ISP for both lines. I'll check next
week as the lines are located 40km away.

> check on ppp0 if thats the case. Or maybe for some reason the
> PMTU value for the internal host is smaller than 1500. You can
> check that by doing "ip route get ".
> 

No. Unmodified internal network in both test cases.

> 


-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mss to pmtu clamping partially broken?

Patrick McHardy wrote:
> Andreas Steinmetz wrote:
>> Patrick McHardy wrote:
>>
>>> Andreas Steinmetz wrote:
>>>
>>>> [...]
>>>> The tcpdump on the client shows that the mss of the incoming syn reply
>>>> packet is *NOT* clamped to the ppp interface mtu.
>>>
>>> You forgot to mention *how* you're clamping the MSS. Using
>>> TCPMSS? Do you have a rule for incoming packets?
>>>
>>
>> The relevant iptables commands I do use for masquerading and clamping are:
>>
>> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
>> iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \
>>  --clamp-mss-to-pmtu
> 
> 
> Two things here:
> 
> - tcpdumps on ppp0 will show unclamped packets since they haven't
> been forwarded yet
> 

That is true, I know this.

> - assuming you have ethernet internally, the PMTU from your router
> to the internal hosts is 1500, so it won't do any clamping.
> 

Yep, internal PMTU is 1500, still the incoming packets are clamped to
1452 on the one line and not clamped on the other.

> Does that explain it?
> 
> A useful thing for TCPMSS for routers would be to clamp to the
> minimum of the PMTU of both directions. But thats not supported
> so far.
> 

I wonder, as somteimes it gets clamped. If it would never have been
clamped I wouldn't have asked.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mss to pmtu clamping partially broken?

Patrick McHardy wrote:
> Andreas Steinmetz wrote:
>> There seems to be a problem with mss to pmtu clamping for incoming syn
>> packets on reply to an outgoing connection on a ppp interface. The mss
>> of the outgoing syn packets is always always clamped to the pmtu, I did
>> check this with a target host I do have access to. The incoming syn
>> reply to such a packet, however, is mss clamped only sometimes and this
>> seems to depend on the DSL line used.
>>
>> The kernels tested were 2.6.20.1, 2.6.20.3 and 2.6.22rc6.
>>
>> Test setup: Two DSL lines, otherwise identical setup (same masquerading
>> linux gateway, same DSL account, same DSL modem, same DSL line provider,
>> same target host, request from and tcpdump on the same client).
>>
>> Linux Client<->Masquerading Linux Gateway<->DSL Modem<->DSL Line<->...
>>
>> DSL line 1, working:
>>
>> 22:26:39.319281 IP (tos 0x0, ttl  64, id 22377, offset 0, flags [DF],
>> length: 48
>> ) 192.168.0.253.1164 > 64.34.165.170.80: S [tcp sum ok]
>> 1465827859:1465827859(0)
>>  win 5840 
>> 22:26:39.459314 IP (tos 0x0, ttl  51, id 0, offset 0, flags [DF],
>> length: 48) 64
>> .34.165.170.80 > 192.168.0.253.1164: S [tcp sum ok]
>> 3667852791:3667852791(0) ack
>>  1465827860 win 5840 
>>
>> The tcpdump on the client shows that the mss of the incoming syn reply
>> packet is clamped to the ppp interface mtu.
>>
>> DSL line 2, not working:
>>
>> 22:03:57.725998 IP (tos 0x0, ttl  64, id 55984, offset 0, flags [DF],
>> length: 48
>> ) 192.168.0.253.1600 > 64.34.165.170.80: S [tcp sum ok]
>> 36968258:36968258(0) win
>>  5840 
>> 22:03:57.866966 IP (tos 0x0, ttl  51, id 0, offset 0, flags [DF],
>> length: 48) 64
>> .34.165.170.80 > 192.168.0.253.1600: S [tcp sum ok]
>> 2226854208:2226854208(0) ack
>>  36968259 win 5840 
>>
>> The tcpdump on the client shows that the mss of the incoming syn reply
>> packet is *NOT* clamped to the ppp interface mtu.
> 
> 
> You forgot to mention *how* you're clamping the MSS. Using
> TCPMSS? Do you have a rule for incoming packets?
> 

The relevant iptables commands I do use for masquerading and clamping are:

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \
--clamp-mss-to-pmtu

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mss to pmtu clamping partially broken?

There seems to be a problem with mss to pmtu clamping for incoming syn
packets on reply to an outgoing connection on a ppp interface. The mss
of the outgoing syn packets is always always clamped to the pmtu, I did
check this with a target host I do have access to. The incoming syn
reply to such a packet, however, is mss clamped only sometimes and this
seems to depend on the DSL line used.

The kernels tested were 2.6.20.1, 2.6.20.3 and 2.6.22rc6.

Test setup: Two DSL lines, otherwise identical setup (same masquerading
linux gateway, same DSL account, same DSL modem, same DSL line provider,
same target host, request from and tcpdump on the same client).

Linux Client<->Masquerading Linux Gateway<->DSL Modem<->DSL Line<->...

DSL line 1, working:

22:26:39.319281 IP (tos 0x0, ttl  64, id 22377, offset 0, flags [DF],
length: 48
) 192.168.0.253.1164 > 64.34.165.170.80: S [tcp sum ok]
1465827859:1465827859(0)
 win 5840 
22:26:39.459314 IP (tos 0x0, ttl  51, id 0, offset 0, flags [DF],
length: 48) 64
.34.165.170.80 > 192.168.0.253.1164: S [tcp sum ok]
3667852791:3667852791(0) ack
 1465827860 win 5840 

The tcpdump on the client shows that the mss of the incoming syn reply
packet is clamped to the ppp interface mtu.

DSL line 2, not working:

22:03:57.725998 IP (tos 0x0, ttl  64, id 55984, offset 0, flags [DF],
length: 48
) 192.168.0.253.1600 > 64.34.165.170.80: S [tcp sum ok]
36968258:36968258(0) win
 5840 
22:03:57.866966 IP (tos 0x0, ttl  51, id 0, offset 0, flags [DF],
length: 48) 64
.34.165.170.80 > 192.168.0.253.1600: S [tcp sum ok]
2226854208:2226854208(0) ack
 36968259 win 5840 

The tcpdump on the client shows that the mss of the incoming syn reply
packet is *NOT* clamped to the ppp interface mtu.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mss to pmtu clamping partially broken?

There seems to be a problem with mss to pmtu clamping for incoming syn
packets on reply to an outgoing connection on a ppp interface. The mss
of the outgoing syn packets is always always clamped to the pmtu, I did
check this with a target host I do have access to. The incoming syn
reply to such a packet, however, is mss clamped only sometimes and this
seems to depend on the DSL line used.

The kernels tested were 2.6.20.1, 2.6.20.3 and 2.6.22rc6.

Test setup: Two DSL lines, otherwise identical setup (same masquerading
linux gateway, same DSL account, same DSL modem, same DSL line provider,
same target host, request from and tcpdump on the same client).

Linux Client-Masquerading Linux Gateway-DSL Modem-DSL Line-...

DSL line 1, working:

22:26:39.319281 IP (tos 0x0, ttl  64, id 22377, offset 0, flags [DF],
length: 48
) 192.168.0.253.1164  64.34.165.170.80: S [tcp sum ok]
1465827859:1465827859(0)
 win 5840 mss 1460,nop,nop,sackOK
22:26:39.459314 IP (tos 0x0, ttl  51, id 0, offset 0, flags [DF],
length: 48) 64
.34.165.170.80  192.168.0.253.1164: S [tcp sum ok]
3667852791:3667852791(0) ack
 1465827860 win 5840 mss 1452,nop,nop,sackOK

The tcpdump on the client shows that the mss of the incoming syn reply
packet is clamped to the ppp interface mtu.

DSL line 2, not working:

22:03:57.725998 IP (tos 0x0, ttl  64, id 55984, offset 0, flags [DF],
length: 48
) 192.168.0.253.1600  64.34.165.170.80: S [tcp sum ok]
36968258:36968258(0) win
 5840 mss 1460,nop,nop,sackOK
22:03:57.866966 IP (tos 0x0, ttl  51, id 0, offset 0, flags [DF],
length: 48) 64
.34.165.170.80  192.168.0.253.1600: S [tcp sum ok]
2226854208:2226854208(0) ack
 36968259 win 5840 mss 1460,nop,nop,sackOK

The tcpdump on the client shows that the mss of the incoming syn reply
packet is *NOT* clamped to the ppp interface mtu.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mss to pmtu clamping partially broken?

Patrick McHardy wrote:
 Andreas Steinmetz wrote:
 Patrick McHardy wrote:

 Andreas Steinmetz wrote:

 [...]
 The tcpdump on the client shows that the mss of the incoming syn reply
 packet is *NOT* clamped to the ppp interface mtu.

 You forgot to mention *how* you're clamping the MSS. Using
 TCPMSS? Do you have a rule for incoming packets?


 The relevant iptables commands I do use for masquerading and clamping are:

 iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
 iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \
  --clamp-mss-to-pmtu
 
 
 Two things here:
 
 - tcpdumps on ppp0 will show unclamped packets since they haven't
 been forwarded yet
 

That is true, I know this.

 - assuming you have ethernet internally, the PMTU from your router
 to the internal hosts is 1500, so it won't do any clamping.
 

Yep, internal PMTU is 1500, still the incoming packets are clamped to
1452 on the one line and not clamped on the other.

 Does that explain it?
 
 A useful thing for TCPMSS for routers would be to clamp to the
 minimum of the PMTU of both directions. But thats not supported
 so far.
 

I wonder, as somteimes it gets clamped. If it would never have been
clamped I wouldn't have asked.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mss to pmtu clamping partially broken?

Patrick McHardy wrote:
 Andreas Steinmetz wrote:
 Patrick McHardy wrote:

 - assuming you have ethernet internally, the PMTU from your router
 to the internal hosts is 1500, so it won't do any clamping.


 Yep, internal PMTU is 1500, still the incoming packets are clamped to
 1452 on the one line and not clamped on the other.


 Does that explain it?

 A useful thing for TCPMSS for routers would be to clamp to the
 minimum of the PMTU of both directions. But thats not supported
 so far.


 I wonder, as somteimes it gets clamped. If it would never have been
 clamped I wouldn't have asked.
 
 
 Its possible that one of your ISPs is doing clamping. You could

This would be fun as it is the same ISP for both lines. I'll check next
week as the lines are located 40km away.

 check on ppp0 if thats the case. Or maybe for some reason the
 PMTU value for the internal host is smaller than 1500. You can
 check that by doing ip route get internal host.
 

No. Unmodified internal network in both test cases.

 


-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mss to pmtu clamping partially broken?

Patrick McHardy wrote:
 Andreas Steinmetz wrote:
 There seems to be a problem with mss to pmtu clamping for incoming syn
 packets on reply to an outgoing connection on a ppp interface. The mss
 of the outgoing syn packets is always always clamped to the pmtu, I did
 check this with a target host I do have access to. The incoming syn
 reply to such a packet, however, is mss clamped only sometimes and this
 seems to depend on the DSL line used.

 The kernels tested were 2.6.20.1, 2.6.20.3 and 2.6.22rc6.

 Test setup: Two DSL lines, otherwise identical setup (same masquerading
 linux gateway, same DSL account, same DSL modem, same DSL line provider,
 same target host, request from and tcpdump on the same client).

 Linux Client-Masquerading Linux Gateway-DSL Modem-DSL Line-...

 DSL line 1, working:

 22:26:39.319281 IP (tos 0x0, ttl  64, id 22377, offset 0, flags [DF],
 length: 48
 ) 192.168.0.253.1164  64.34.165.170.80: S [tcp sum ok]
 1465827859:1465827859(0)
  win 5840 mss 1460,nop,nop,sackOK
 22:26:39.459314 IP (tos 0x0, ttl  51, id 0, offset 0, flags [DF],
 length: 48) 64
 .34.165.170.80  192.168.0.253.1164: S [tcp sum ok]
 3667852791:3667852791(0) ack
  1465827860 win 5840 mss 1452,nop,nop,sackOK

 The tcpdump on the client shows that the mss of the incoming syn reply
 packet is clamped to the ppp interface mtu.

 DSL line 2, not working:

 22:03:57.725998 IP (tos 0x0, ttl  64, id 55984, offset 0, flags [DF],
 length: 48
 ) 192.168.0.253.1600  64.34.165.170.80: S [tcp sum ok]
 36968258:36968258(0) win
  5840 mss 1460,nop,nop,sackOK
 22:03:57.866966 IP (tos 0x0, ttl  51, id 0, offset 0, flags [DF],
 length: 48) 64
 .34.165.170.80  192.168.0.253.1600: S [tcp sum ok]
 2226854208:2226854208(0) ack
  36968259 win 5840 mss 1460,nop,nop,sackOK

 The tcpdump on the client shows that the mss of the incoming syn reply
 packet is *NOT* clamped to the ppp interface mtu.
 
 
 You forgot to mention *how* you're clamping the MSS. Using
 TCPMSS? Do you have a rule for incoming packets?
 

The relevant iptables commands I do use for masquerading and clamping are:

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \
--clamp-mss-to-pmtu

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

Andrew Morton wrote:
> On Tue, 20 Mar 2007 00:25:02 +0100
> Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
> 
>> Mike Christie wrote:
>>> Mike Christie wrote:
>>>> James Bottomley wrote:
>>>>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
>>>>>>> I can't even say if the tapes are written correctly as I can't read them
>>>>>>> (one does not reboot production machines back to 2.4.x just to try to
>>>>>>> read a backup tape - I don't have 2.6.x older than 2.6.20 on these
>>>>>>> machines).
>>>>>> Could you try this patch
>>>>>> http://marc.info/?l=linux-scsi=116464965414878=2
>>>>>> I thought st was modified to not send offsets in the last elements but
>>>>>> it looks like it wasn't.
>>>>> Actually, there are two patches in the email referred to.  If the
>>>>> analysis that we're passing NULL to mempool_free is correct, it should
>>>>> be the second one that fixes the problem (the one that checks
>>>>> bio->bi_io_vec before freeing it).  Which would mean we have a
>>>>> nr_vecs==0 bio generated by the tar somehow.
>>>>>
>>>> I think we might only need the first patch if the problem is similar to
>>>> what the lsi guys were seeing. I thought the problem is that we are not
>>>> estimating how large the transfer is correctly because we do not take
>>>> into account offsets at the end. This results in nr_vecs being zero when
>>>> it should be a valid value. I thought Kai's patch:
>>>> http://bugzilla.kernel.org/show_bug.cgi?id=7919
>>>> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=9abe16c670bd3d4ab5519257514f9f291383d104
>>>> fixed the problem on st's side,
>>> Oh, I noticed that the subject for the mail references 2.6.30.3 and the
>>> patch for st in the bugzilla did not make into 2.6.20 and is not in .3.
>>> Could we try the st patch in the bugzilla first?
>> Ok, the st patch from bugzilla solves the problem (tested on both
>> affected machines).
> 
> 
> If you're referring to the below patch then it's already in mainline, and
> has been for a month.
> 

Yes, that's the patch I'm referring to.

> Have you tested 2.6.21-rc4?  If not, please do so.
> 

Sorry, this is not possible on these machines. They are production
servers and every problem on them that cannot be easily solved via
remote access is a 40km (one way) drive in the middle of the night.

> Perhaps we should merge this into 2.6.20.x?
> 

I would suggest so.

> 
> 
> commit 9abe16c670bd3d4ab5519257514f9f291383d104
> Author: Kai Makisara <[EMAIL PROTECTED]>
> Date:   Sat Feb 3 13:21:29 2007 +0200
> 
> [SCSI] st: fix Tape dies if wrong block size used, bug 7919
> 
> On Thu, 1 Feb 2007, Andrew Morton wrote:
> > On Thu, 1 Feb 2007 15:34:29 -0800
> > [EMAIL PROTECTED] wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=7919
> > >
> > >Summary: Tape dies if wrong block size used
> > > Kernel Version: 2.6.20-rc5
> > > Status: NEW
> > >   Severity: normal
> > >  Owner: [EMAIL PROTECTED]
> > >  Submitter: [EMAIL PROTECTED]
> > >
> > >
> > > Most recent kernel where this bug did *NOT* occur: 2.6.17.14
> > >
> > > Other Kernels Tested and Results:
> > >
> > > OK 2.6.15.7
> > > OK 2.6.16.37
> > > OK 2.6.17.14
> > > BAD 2.6.18.6
> > > BAD 2.6.18-1.2869.fc6
> > > BAD 2.6.19.2 +
> > > BAD 2.6.20-rc5
> > >
> > > NOTE: 2.6.18-1.2869.fc6 is a Fedora modified kernel, all others are 
> from kernel.org
> > >
> ...
> > > Steps to reproduce:
> > > Get a Adaptec AHA-2940U/UW/D / AIC-7881U card and a tape drive,
> > > install a recent kernel
> > > set the tape block size - mt setblk 4096
> > > read from or write to tape using wrong block size - tar -b 7 -cvf 
> /dev/tape foo
> > >
> Write does not trigger this bug because the driver refuses in fixed block
> mode writes that are not a multiple of the block size. Read does trigger
> it in my system.
> 
> The bug is not associated with any specific HBA. st tries to do direct i/o
> in fixed block mode with reads that are

Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache_free

Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
> 
> This changes kmem_cache_free() to deal with NULL objects passed to it. The 
> current behavior is inconsistent with kfree() so there are callers 
> passing NULL to kmem_cache_free().
> 
> Andreas, can you please confirm this fixes the oops you reported on 
> linux-scsi?
> 

Didn't test this as Mike Christie pointed me to a working fix for the st
driver.

> Cc: Andreas Steinmetz <[EMAIL PROTECTED]>
> Cc: Christoph Lameter <[EMAIL PROTECTED]>
> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
> ---
>  mm/slab.c |5 +
>  1 file changed, 5 insertions(+)
> 
> Index: 2.6/mm/slab.c
> ===
> --- 2.6.orig/mm/slab.c2007-03-19 10:18:52.0 +0200
> +++ 2.6/mm/slab.c 2007-03-19 10:19:42.0 +0200
> @@ -3741,6 +3741,8 @@ EXPORT_SYMBOL(__kmalloc);
>   * @cachep: The cache the allocation was from.
>   * @objp: The previously allocated object.
>   *
> + * If @objp is NULL, no operation is performed.
> + *
>   * Free an object which was previously allocated from this
>   * cache.
>   */
> @@ -3748,6 +3750,9 @@ void kmem_cache_free(struct kmem_cache *
>  {
>   unsigned long flags;
>  
> + if (unlikely(!objp))
> + return;
> +
>   BUG_ON(virt_to_cache(objp) != cachep);
>  
>   local_irq_save(flags);


-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.20.3 NFS: BUG at fs/nfs/pagelist.c:339

Got this from a nfs booted 2.6.20.3 x86 system (complete diskless boot):

BUG: at fs/nfs/pagelist.c:339 nfs_scan_dirty()
 [] nfs_scan_dirty+0x17e/0x18a
 [] generic_writepages+0x224/0x2b6
 [] nfs_wait_on_requests_locked+0x80/0x8e
 [] nfs_sync_mapping_wait+0x9d/0x14b
 [] __link_path_walk+0x854/0x943
 [] nfs_sync_mapping_range+0x97/0xb6
 [] nfs_getattr+0x3a/0x96
 [] nfs_getattr+0x0/0x96
 [] vfs_getattr+0x21/0x30
 [] vfs_lstat_fd+0x2b/0x3d
 [] free_pgtables+0x7e/0x8a
 [] sys_lstat64+0xf/0x23
 [] remove_vma+0x36/0x3b
 [] remove_vma_list+0x40/0x4a
 [] do_munmap+0xf3/0xff
 [] sys_munmap+0x30/0x35
 [] syscall_call+0x7/0xb
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

Mike Christie wrote:
> James Bottomley wrote:
>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
>>>> I can't even say if the tapes are written correctly as I can't read them
>>>> (one does not reboot production machines back to 2.4.x just to try to
>>>> read a backup tape - I don't have 2.6.x older than 2.6.20 on these
>>>> machines).
>>> Could you try this patch
>>> http://marc.info/?l=linux-scsi=116464965414878=2
>>> I thought st was modified to not send offsets in the last elements but
>>> it looks like it wasn't.
>> Actually, there are two patches in the email referred to.  If the
>> analysis that we're passing NULL to mempool_free is correct, it should
>> be the second one that fixes the problem (the one that checks
>> bio->bi_io_vec before freeing it).  Which would mean we have a
>> nr_vecs==0 bio generated by the tar somehow.
>>
> 
> I think we might only need the first patch if the problem is similar to
> what the lsi guys were seeing. I thought the problem is that we are not
> estimating how large the transfer is correctly because we do not take
> into account offsets at the end. This results in nr_vecs being zero when
> it should be a valid value. I thought Kai's patch:
> http://bugzilla.kernel.org/show_bug.cgi?id=7919
> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=9abe16c670bd3d4ab5519257514f9f291383d104
> fixed the problem on st's side, but I guess not so you are probably right.
> 
> Here is a patch that dumps the sgl we are getting from st so we can see
> for sure what we are getting and can decide if we need the first patch,
> second patch or both.
> 

Here's the patch output:

sg length 6 offset 0
sg length 12 offset 0
sg length 4096 offset 0
sg length 4096 offset 0
sg length 2048 offset 0

Please note (as replied in the other mail) that the bugzilla patch
solves the problem.
> 
> 
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 5f95570..81005aa 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -306,6 +306,10 @@ static int scsi_req_map_sg(struct reques
>   struct bio *bio = NULL;
>   int i, err, nr_vecs = 0;
>  
> + for (i = 0; i < nsegs; i++)
> + printk(KERN_INFO "sg length %u offset %u\n", sgl[i].length,
> + sgl[i].offset);
> +
>   for (i = 0; i < nsegs; i++) {
>   page = sgl[i].page;
>   off = sgl[i].offset;


-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

Mike Christie wrote:
> Mike Christie wrote:
>> James Bottomley wrote:
>>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
>>>>> I can't even say if the tapes are written correctly as I can't read them
>>>>> (one does not reboot production machines back to 2.4.x just to try to
>>>>> read a backup tape - I don't have 2.6.x older than 2.6.20 on these
>>>>> machines).
>>>> Could you try this patch
>>>> http://marc.info/?l=linux-scsi=116464965414878=2
>>>> I thought st was modified to not send offsets in the last elements but
>>>> it looks like it wasn't.
>>> Actually, there are two patches in the email referred to.  If the
>>> analysis that we're passing NULL to mempool_free is correct, it should
>>> be the second one that fixes the problem (the one that checks
>>> bio->bi_io_vec before freeing it).  Which would mean we have a
>>> nr_vecs==0 bio generated by the tar somehow.
>>>
>> I think we might only need the first patch if the problem is similar to
>> what the lsi guys were seeing. I thought the problem is that we are not
>> estimating how large the transfer is correctly because we do not take
>> into account offsets at the end. This results in nr_vecs being zero when
>> it should be a valid value. I thought Kai's patch:
>> http://bugzilla.kernel.org/show_bug.cgi?id=7919
>> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=9abe16c670bd3d4ab5519257514f9f291383d104
>> fixed the problem on st's side,
> 
> Oh, I noticed that the subject for the mail references 2.6.30.3 and the
> patch for st in the bugzilla did not make into 2.6.20 and is not in .3.
> Could we try the st patch in the bugzilla first?

Ok, the st patch from bugzilla solves the problem (tested on both
affected machines).
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

Mike Christie wrote:
 James Bottomley wrote:
 On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
 I can't even say if the tapes are written correctly as I can't read them
 (one does not reboot production machines back to 2.4.x just to try to
 read a backup tape - I don't have 2.6.x older than 2.6.20 on these
 machines).
 Could you try this patch
 http://marc.info/?l=linux-scsim=116464965414878w=2
 I thought st was modified to not send offsets in the last elements but
 it looks like it wasn't.
 Actually, there are two patches in the email referred to.  If the
 analysis that we're passing NULL to mempool_free is correct, it should
 be the second one that fixes the problem (the one that checks
 bio-bi_io_vec before freeing it).  Which would mean we have a
 nr_vecs==0 bio generated by the tar somehow.

 
 I think we might only need the first patch if the problem is similar to
 what the lsi guys were seeing. I thought the problem is that we are not
 estimating how large the transfer is correctly because we do not take
 into account offsets at the end. This results in nr_vecs being zero when
 it should be a valid value. I thought Kai's patch:
 http://bugzilla.kernel.org/show_bug.cgi?id=7919
 http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=9abe16c670bd3d4ab5519257514f9f291383d104
 fixed the problem on st's side, but I guess not so you are probably right.
 
 Here is a patch that dumps the sgl we are getting from st so we can see
 for sure what we are getting and can decide if we need the first patch,
 second patch or both.
 

Here's the patch output:

sg length 6 offset 0
sg length 12 offset 0
sg length 4096 offset 0
sg length 4096 offset 0
sg length 2048 offset 0

Please note (as replied in the other mail) that the bugzilla patch
solves the problem.
 
 
 
 diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
 index 5f95570..81005aa 100644
 --- a/drivers/scsi/scsi_lib.c
 +++ b/drivers/scsi/scsi_lib.c
 @@ -306,6 +306,10 @@ static int scsi_req_map_sg(struct reques
   struct bio *bio = NULL;
   int i, err, nr_vecs = 0;
  
 + for (i = 0; i  nsegs; i++)
 + printk(KERN_INFO sg length %u offset %u\n, sgl[i].length,
 + sgl[i].offset);
 +
   for (i = 0; i  nsegs; i++) {
   page = sgl[i].page;
   off = sgl[i].offset;


-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

Mike Christie wrote:
Mike Christie wrote:
James Bottomley wrote:
On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
I can't even say if the tapes are written correctly as I can't read them
(one does not reboot production machines back to 2.4.x just to try to
read a backup tape - I don't have 2.6.x older than 2.6.20 on these
machines).
Could you try this patch
http://marc.info/?l=linux-scsim=116464965414878w=2
I thought st was modified to not send offsets in the last elements but
it looks like it wasn't.
Actually, there are two patches in the email referred to. If the
analysis that we're passing NULL to mempool_free is correct, it should
be the second one that fixes the problem (the one that checks
bio-bi_io_vec before freeing it). Which would mean we have a
nr_vecs==0 bio generated by the tar somehow.

Oh, I noticed that the subject for the mail references 2.6.30.3 and the
patch for st in the bugzilla did not make into 2.6.20 and is not in .3.
Could we try the st patch in the bugzilla first?

Ok, the st patch from bugzilla solves the problem (tested on both
affected machines).
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

2.6.20.3 NFS: BUG at fs/nfs/pagelist.c:339

Got this from a nfs booted 2.6.20.3 x86 system (complete diskless boot):

BUG: at fs/nfs/pagelist.c:339 nfs_scan_dirty()
 [c017b1cc] nfs_scan_dirty+0x17e/0x18a
 [c013407a] generic_writepages+0x224/0x2b6
 [c017e116] nfs_wait_on_requests_locked+0x80/0x8e
 [c017f56f] nfs_sync_mapping_wait+0x9d/0x14b
 [c014d0df] __link_path_walk+0x854/0x943
 [c017f72e] nfs_sync_mapping_range+0x97/0xb6
 [c01783e2] nfs_getattr+0x3a/0x96
 [c01783a8] nfs_getattr+0x0/0x96
 [c014942a] vfs_getattr+0x21/0x30
 [c01494b2] vfs_lstat_fd+0x2b/0x3d
 [c0138684] free_pgtables+0x7e/0x8a
 [c0149a7f] sys_lstat64+0xf/0x23
 [c013b082] remove_vma+0x36/0x3b
 [c013c3c2] remove_vma_list+0x40/0x4a
 [c013c6d2] do_munmap+0xf3/0xff
 [c013c70e] sys_munmap+0x30/0x35
 [c0102b40] syscall_call+0x7/0xb
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache_free

Pekka J Enberg wrote:
 From: Pekka Enberg [EMAIL PROTECTED]
 
 This changes kmem_cache_free() to deal with NULL objects passed to it. The 
 current behavior is inconsistent with kfree() so there are callers 
 passing NULL to kmem_cache_free().
 
 Andreas, can you please confirm this fixes the oops you reported on 
 linux-scsi?
 

Didn't test this as Mike Christie pointed me to a working fix for the st
driver.

 Cc: Andreas Steinmetz [EMAIL PROTECTED]
 Cc: Christoph Lameter [EMAIL PROTECTED]
 Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
 ---
  mm/slab.c |5 +
  1 file changed, 5 insertions(+)
 
 Index: 2.6/mm/slab.c
 ===
 --- 2.6.orig/mm/slab.c2007-03-19 10:18:52.0 +0200
 +++ 2.6/mm/slab.c 2007-03-19 10:19:42.0 +0200
 @@ -3741,6 +3741,8 @@ EXPORT_SYMBOL(__kmalloc);
   * @cachep: The cache the allocation was from.
   * @objp: The previously allocated object.
   *
 + * If @objp is NULL, no operation is performed.
 + *
   * Free an object which was previously allocated from this
   * cache.
   */
 @@ -3748,6 +3750,9 @@ void kmem_cache_free(struct kmem_cache *
  {
   unsigned long flags;
  
 + if (unlikely(!objp))
 + return;
 +
   BUG_ON(virt_to_cache(objp) != cachep);
  
   local_irq_save(flags);


-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

Andrew Morton wrote:
On Tue, 20 Mar 2007 00:25:02 +0100
Andreas Steinmetz [EMAIL PROTECTED] wrote:

I think we might only need the first patch if the problem is similar to
what the lsi guys were seeing. I thought the problem is that we are not
estimating how large the transfer is correctly because we do not take
into account offsets at the end. This results in nr_vecs being zero when
it should be a valid value. I thought Kai's patch:
http://bugzilla.kernel.org/show_bug.cgi?id=7919
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=9abe16c670bd3d4ab5519257514f9f291383d104
fixed the problem on st's side,
Oh, I noticed that the subject for the mail references 2.6.30.3 and the
patch for st in the bugzilla did not make into 2.6.20 and is not in .3.
Could we try the st patch in the bugzilla first?
Ok, the st patch from bugzilla solves the problem (tested on both
affected machines).

If you're referring to the below patch then it's already in mainline, and
has been for a month.

Yes, that's the patch I'm referring to.

Have you tested 2.6.21-rc4? If not, please do so.

Sorry, this is not possible on these machines. They are production
servers and every problem on them that cannot be easily solved via
remote access is a 40km (one way) drive in the middle of the night.

Perhaps we should merge this into 2.6.20.x?

I would suggest so.

commit 9abe16c670bd3d4ab5519257514f9f291383d104
Author: Kai Makisara [EMAIL PROTECTED]
Date: Sat Feb 3 13:21:29 2007 +0200

[SCSI] st: fix Tape dies if wrong block size used, bug 7919

On Thu, 1 Feb 2007, Andrew Morton wrote:
On Thu, 1 Feb 2007 15:34:29 -0800
[EMAIL PROTECTED] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=7919

Summary: Tape dies if wrong block size used
Kernel Version: 2.6.20-rc5
Status: NEW
Severity: normal
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL PROTECTED]

Most recent kernel where this bug did *NOT* occur: 2.6.17.14

Other Kernels Tested and Results:

OK 2.6.15.7
OK 2.6.16.37
OK 2.6.17.14
BAD 2.6.18.6
BAD 2.6.18-1.2869.fc6
BAD 2.6.19.2 +
BAD 2.6.20-rc5

NOTE: 2.6.18-1.2869.fc6 is a Fedora modified kernel, all others are
from kernel.org

...
Steps to reproduce:
Get a Adaptec AHA-2940U/UW/D / AIC-7881U card and a tape drive,
install a recent kernel
set the tape block size - mt setblk 4096
read from or write to tape using wrong block size - tar -b 7 -cvf
/dev/tape foo

Write does not trigger this bug because the driver refuses in fixed block
mode writes that are not a multiple of the block size. Read does trigger
it in my system.

The bug is not associated with any specific HBA. st tries to do direct i/o
in fixed block mode with reads that are not a multiple of tape block size.

The patch in this message fixes the st problem by switching to using the
driver buffer up to the next close of the device file in fixed block mode
if the user asks for a read like this.

I don't know why the bug has surfaced only after 2.6.17 although the st
problem is old. There may be another bug in the block subsystem and this
patch works around it. However, the patch fixes a problem in st and in
this way it is a valid fix.

This patch may also fix the bug 7900.

The patch compiles and is lightly tested.

Signed-off-by: Kai Makisara [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]

diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
index e016e09..fba8b20 100644
--- a/drivers/scsi/st.c
+++ b/drivers/scsi/st.c
@@ -9,7 +9,7 @@
Steve Hirsch, Andreas Koppenhofer, Michael Leodolter, Eyal Lebedinsky,
Michael Schaefer, Jorg Weule, and Eric Youngdale.

2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-18 Thread Andreas Steinmetz

As posted to lkml and linux-scsi on 2007-03-15 without reply, see
http://marc.info/?l=linux-kernel=117395128412313=2 for original post:

It is not so nice when one can write backup tapes but the tapes cannot
be read. I don't know if memory management or the st driver is the
culprit, but this is a not so nice situation.

I can't even say if the tapes are written correctly as I can't read them
(one does not reboot production machines back to 2.4.x just to try to
read a backup tape - I don't have 2.6.x older than 2.6.20 on these
machines).
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-18 Thread Andreas Steinmetz

As posted to lkml and linux-scsi on 2007-03-15 without reply, see
http://marc.info/?l=linux-kernelm=117395128412313w=2 for original post:

It is not so nice when one can write backup tapes but the tapes cannot
be read. I don't know if memory management or the st driver is the
culprit, but this is a not so nice situation.

I can't even say if the tapes are written correctly as I can't read them
(one does not reboot production machines back to 2.4.x just to try to
read a backup tape - I don't have 2.6.x older than 2.6.20 on these
machines).
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.3: kswapd page allocation failure

Mariusz Kozlowski wrote:
> Hello, 
> 
>> Got the following from dmesg of one of my servers last night (happened
>> during nightly backup over network):
>>
>> kswapd0: page allocation failure. order:3, mode:0x20
> 
>   Take a look at this:
> 
> http://lkml.org/lkml/2007/3/15/90
> 
> Regards,
> 
>   Mariusz Kozlowski

Thanks, I'll test "echo 16384 > /proc/sys/vm/min_free_kbytes" and see
what happens.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.20.3: kswapd page allocation failure

 [] wake_up_bit+0xb/0x16
 [] dispose_list+0x88/0xa4
 [] prune_icache+0x136/0x148
 [] shrink_icache_memory+0x14/0x2b
 [] shrink_slab+0x135/0x18e
 [] balance_pgdat+0x1e6/0x2eb
 [] kswapd+0xf5/0xf7
 [] autoremove_wake_function+0x0/0x33
 [] __wake_up_common+0x35/0x56
 [] autoremove_wake_function+0x0/0x33
 [] kswapd+0x0/0xf7
 [] kthread+0x72/0x97
 [] kthread+0x0/0x97
 [] kernel_thread_helper+0x7/0x10
 ===
Mem-info:
DMA per-cpu:
CPU0: Hot: hi:0, btch:   1 usd:   0   Cold: hi:0, btch:   1
usd:   0
Normal per-cpu:
CPU0: Hot: hi:  186, btch:  31 usd: 143   Cold: hi:   62, btch:  15
usd:   2
HighMem per-cpu:
CPU0: Hot: hi:   42, btch:   7 usd:  40   Cold: hi:   14, btch:   3
usd:   2
Active:171834 inactive:59703 dirty:846 writeback:0 unstable:0 free:2311
slab:20911 mapped:4658 pagetables:765
DMA free:3536kB min:68kB low:84kB high:100kB active:5152kB
inactive:1232kB present:16256kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 873 1000
Normal free:5448kB min:3744kB low:4680kB high:5616kB active:569208kB
inactive:228308kB present:894080kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 1015
HighMem free:260kB min:128kB low:264kB high:400kB active:112976kB
inactive:9272kB present:129988kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 40*4kB 36*8kB 15*16kB 1*32kB 0*64kB 0*128kB 1*256kB 1*512kB
0*1024kB 1*2048kB 0*4096kB = 3536kB
Normal: 152*4kB 491*8kB 45*16kB 0*32kB 1*64kB 1*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 5448kB
HighMem: 1*4kB 18*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 260kB
Swap cache: add 132, delete 132, find 0/0, race 0+0
Free swap  = 16064704kB
Total swap = 16064704kB
Free swap:   16064704kB
262128 pages of RAM
32752 pages of HIGHMEM
3672 reserved pages
82110 pages shared
0 pages swap cached
846 pages dirty
0 pages writeback
4658 pages mapped
20911 pages slab
765 pages pagetables

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.20.3: kswapd page allocation failure

:59703 dirty:846 writeback:0 unstable:0 free:2311
slab:20911 mapped:4658 pagetables:765
DMA free:3536kB min:68kB low:84kB high:100kB active:5152kB
inactive:1232kB present:16256kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 873 1000
Normal free:5448kB min:3744kB low:4680kB high:5616kB active:569208kB
inactive:228308kB present:894080kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 1015
HighMem free:260kB min:128kB low:264kB high:400kB active:112976kB
inactive:9272kB present:129988kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 40*4kB 36*8kB 15*16kB 1*32kB 0*64kB 0*128kB 1*256kB 1*512kB
0*1024kB 1*2048kB 0*4096kB = 3536kB
Normal: 152*4kB 491*8kB 45*16kB 0*32kB 1*64kB 1*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 5448kB
HighMem: 1*4kB 18*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 260kB
Swap cache: add 132, delete 132, find 0/0, race 0+0
Free swap  = 16064704kB
Total swap = 16064704kB
Free swap:   16064704kB
262128 pages of RAM
32752 pages of HIGHMEM
3672 reserved pages
82110 pages shared
0 pages swap cached
846 pages dirty
0 pages writeback
4658 pages mapped
20911 pages slab
765 pages pagetables

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.3: kswapd page allocation failure

Mariusz Kozlowski wrote:
 Hello, 
 
 Got the following from dmesg of one of my servers last night (happened
 during nightly backup over network):

 kswapd0: page allocation failure. order:3, mode:0x20
 
   Take a look at this:
 
 http://lkml.org/lkml/2007/3/15/90
 
 Regards,
 
   Mariusz Kozlowski

Thanks, I'll test echo 16384  /proc/sys/vm/min_free_kbytes and see
what happens.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.20.3: kernel BUG at mm/slab.c:597

2007-03-15 Thread Andreas Steinmetz

Got the following on executing "tar tpf /dev/st0l" on two different
systems (x86):

kernel BUG at mm/slab.c:597!
invalid opcode:  [#1]
Modules linked in: sg st sym53c8xx netconsole tg3 e1000
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.20.3-luna #1)
EIP is at kmem_cache_free+0x29/0x5a
eax: c180   ebx: f0ae12c0   ecx: c18f73c0   edx: c180
esi: c1919de0   edi:    ebp: 1000   esp: f1fe7e14
ds: 007b   es: 007b   ss: 0068
Process tar (pid: 17153, ti=f1fe6000 task=f7106a70 task.ti=f1fe6000)
Stack: f0ae12c0 c1919de0 ffea c0137f97  f0ae12c0 c1919e20
c0168d45
   f0ae12c0 1000 c0168fb9 c02a77e3 1000  

    c17bb6e0 1000  f1b38be8 0003 f54ac050
c1b9d6e8
Call Trace:
 [] mempool_free+0x48/0x4c
 [] bio_free+0x21/0x2c
 [] bio_put+0x22/0x23
 [] scsi_req_map_sg+0x150/0x19b
 [] scsi_execute_async+0x96/0x175
 [] st_do_scsi+0x14d/0x19f [st]
 [] st_sleep_done+0x0/0x35 [st]
 [] read_tape+0x11d/0x3ad [st]
 [] st_read+0x1d7/0x2d6 [st]
 [] vfs_read+0x8a/0x12f
 [] sys_read+0x41/0x67
 [] syscall_call+0x7/0xb
 ===
Code: 5f c3 57 89 c1 89 d7 8d 92 00 00 00 40 56 c1 ea 0c 53 c1 e2 05 03
15 40 5d
 5a c0 8b 02 f6 c4 40 74 03 8b 52 0c 8b 02 a8 80 75 04 <0f> 0b eb fe 39
4a 18 74
 04 0f 0b eb fe 9c 5e fa 8b 19 8b 03 3b
EIP: [] kmem_cache_free+0x29/0x5a SS:ESP 0068:f1fe7e14
 BUG: at drivers/scsi/st.c:2516 st_int_ioctl()
 [] st_int_ioctl+0x64/0x999 [st]
 [] st_flush+0x253/0x26d [st]
 [] dput+0x22/0x112
 [] filp_close+0x32/0x54
 [] close_files+0x46/0x55
 [] put_files_struct+0x14/0x3c
 [] do_exit+0x1c6/0x314
 [] die+0x197/0x19f
 [] do_trap+0x76/0xa2
 [] do_invalid_op+0x0/0x99
 [] do_invalid_op+0x90/0x99
 [] kmem_cache_free+0x29/0x5a
 [] wait_for_completion+0x69/0x93
 [] default_wake_function+0x0/0xc
 [] mempool_alloc+0x28/0xa4
 [] blk_alloc_request+0x3c/0x5d
 [] error_code+0x74/0x7c
 [] kmem_cache_free+0x29/0x5a
 [] mempool_free+0x48/0x4c
 [] bio_free+0x21/0x2c
 [] bio_put+0x22/0x23
 [] scsi_req_map_sg+0x150/0x19b
 [] scsi_execute_async+0x96/0x175
 [] st_do_scsi+0x14d/0x19f [st]
 [] st_sleep_done+0x0/0x35 [st]
 [] read_tape+0x11d/0x3ad [st]
 [] st_read+0x1d7/0x2d6 [st]
 [] vfs_read+0x8a/0x12f
 [] sys_read+0x41/0x67
 [] syscall_call+0x7/0xb
 ===
[ cut here ]
kernel BUG at mm/slab.c:597!
invalid opcode:  [#2]
Modules linked in: sg st sym53c8xx netconsole tg3 e1000
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.20.3-luna #1)
EIP is at kmem_cache_free+0x29/0x5a
eax: c180   ebx: f0ae1cc0   ecx: c18f73c0   edx: c180
esi: c1919de0   edi:    ebp: 1000   esp: f1fe7afc
ds: 007b   es: 007b   ss: 0068
Process tar (pid: 17153, ti=f1fe6000 task=f7106a70 task.ti=f1fe6000)
Stack: f0ae1cc0 c1919de0 ffea c0137f97  f0ae1cc0 c1919e20
c0168d45
   f0ae1cc0 1000 c0168fb9 c02a77e3 1000  

    c17bb6e0 1000  f1b38be8 0003 f54ac050
c1b9d298
Call Trace:
 [] mempool_free+0x48/0x4c
 [] bio_free+0x21/0x2c
 [] bio_put+0x22/0x23
 [] scsi_req_map_sg+0x150/0x19b
 [] scsi_execute_async+0x96/0x175
 [] st_do_scsi+0x14d/0x19f [st]
 [] st_sleep_done+0x0/0x35 [st]
 [] st_int_ioctl+0x63b/0x999 [st]
 [] st_flush+0x253/0x26d [st]
 [] dput+0x22/0x112
 [] filp_close+0x32/0x54
 [] close_files+0x46/0x55
 [] put_files_struct+0x14/0x3c
 [] do_exit+0x1c6/0x314
 [] die+0x197/0x19f
 [] do_trap+0x76/0xa2
 [] do_invalid_op+0x0/0x99
 [] do_invalid_op+0x90/0x99
 [] kmem_cache_free+0x29/0x5a
 [] wait_for_completion+0x69/0x93
 [] default_wake_function+0x0/0xc
 [] mempool_alloc+0x28/0xa4
 [] blk_alloc_request+0x3c/0x5d
 [] error_code+0x74/0x7c
 [] kmem_cache_free+0x29/0x5a
 [] mempool_free+0x48/0x4c
 [] bio_free+0x21/0x2c
 [] bio_put+0x22/0x23
 [] scsi_req_map_sg+0x150/0x19b
 [] scsi_execute_async+0x96/0x175
 [] st_do_scsi+0x14d/0x19f [st]
 [] st_sleep_done+0x0/0x35 [st]
 [] read_tape+0x11d/0x3ad [st]
 [] st_read+0x1d7/0x2d6 [st]
 [] vfs_read+0x8a/0x12f
 [] sys_read+0x41/0x67
 [] syscall_call+0x7/0xb
 ===
Code: 5f c3 57 89 c1 89 d7 8d 92 00 00 00 40 56 c1 ea 0c 53 c1 e2 05 03
15 40 5d
 5a c0 8b 02 f6 c4 40 74 03 8b 52 0c 8b 02 a8 80 75 04 <0f> 0b eb fe 39
4a 18 74
 04 0f 0b eb fe 9c 5e fa 8b 19 8b 03 3b
EIP: [] kmem_cache_free+0x29/0x5a SS:ESP 0068:f1fe7afc
 <1>Fixing recursive fault but reboot is needed!

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.20.3: kernel BUG at mm/slab.c:597

2007-03-15 Thread Andreas Steinmetz

/0x5a SS:ESP 0068:f1fe7afc
 1Fixing recursive fault but reboot is needed!

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent and not-so problems with tifm_sd driver - one more

2007-02-12 Thread Andreas Steinmetz

Brad Campbell wrote:
> Alex, it's still hit and miss getting this card detected. I had to
> insert/remove the card over 10 times with random driver load/unloads
> until it created the device entries..

And for me it's still worse, no matter what I try with 2.6.20:

speedy:~ # find /sys/devices | grep tifm
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/mmc_host:mmc0
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/driver
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/bus
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/subsystem
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/power
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/power/wakeup
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/uevent

speedy:~ # find /sys/block | grep mmc
speedy:~ #

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent and not-so problems with tifm_sd driver - one more

2007-02-12 Thread Andreas Steinmetz

Brad Campbell wrote:
 Alex, it's still hit and miss getting this card detected. I had to
 insert/remove the card over 10 times with random driver load/unloads
 until it created the device entries..

And for me it's still worse, no matter what I try with 2.6.20:

speedy:~ # find /sys/devices | grep tifm
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/mmc_host:mmc0
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/driver
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/bus
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/subsystem
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/power
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/power/wakeup
/sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/uevent

speedy:~ # find /sys/block | grep mmc
speedy:~ #

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.20] tifm_7xx1/mmc not working

2007-02-09 Thread Andreas Steinmetz

Alex Dubov wrote:
> I'm aware that there are some weird problems with a 2.6.20. I'm currently 
> looking into it.
> 
> Besides, I wonder, are tifm and sdhci play nicely together? And then, we do 
> know that suspend is
> totally broken in the older versions of the driver. So it may be desirable to 
> make a test with
> sdhci unloaded and machine freshly rebooted (not resumed).
> 

I tried exactly as described (fresh cold boot, sdhci never loaded), but
the described problem remains. If there is anything I can do to help to
trace this problem let me know.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.20] tifm_7xx1/mmc not working

2007-02-09 Thread Andreas Steinmetz

Alex Dubov wrote:
 I'm aware that there are some weird problems with a 2.6.20. I'm currently 
 looking into it.
 
 Besides, I wonder, are tifm and sdhci play nicely together? And then, we do 
 know that suspend is
 totally broken in the older versions of the driver. So it may be desirable to 
 make a test with
 sdhci unloaded and machine freshly rebooted (not resumed).
 

I tried exactly as described (fresh cold boot, sdhci never loaded), but
the described problem remains. If there is anything I can do to help to
trace this problem let me know.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6.20] tifm_7xx1/mmc not working

Hi,
I do have a problem with tifm_7xx1 and 2.6.20. First of all, the device
is working with 2.6.18.2 and the out of tree tifm-0.6 release. In this
case except for the first card insertion after suspend/reboot I do get
the following messages:

tifm_7xx1: sd card detected in socket 3
mmcblk0: mmc0:7d7f SD01G 1006080KiB
 mmcblk0: p1

With 2.6.20, however, I always do get only the following which is the
same as for 2.6.18.2 on first card insert after reboot/suspend:

tifm_7xx1: sd card detected in socket 3

Am I doing something wrong here or is there a problem?

Relevant modules loaded with 2.6.20:

mmc_block   7944  0
tifm_sd10824  0
tifm_7xx1   7296  0
sdhci  17548  0
tifm_core   7960  2 tifm_sd,tifm_7xx1
mmc_core   24096  3 mmc_block,tifm_sd,sdhci

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6.20] net/ieee80211/ieee80211_crypt_tkip.c spams kernel message buffer

net/ieee80211/ieee80211_crypt_tkip.c outputs tons of these which didn't
happen with 2.6.18.2 (only one or two of these after enabling the
ipw2200 with the kill switch):

TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e560
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e574
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e588
printk: 18 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e59b
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e5af
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e5c3
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e5d7
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e5eb
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e5ff
printk: 16 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e612
printk: 17 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e626

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6.20] tifm_7xx1/mmc not working

Hi,
I do have a problem with tifm_7xx1 and 2.6.20. First of all, the device
is working with 2.6.18.2 and the out of tree tifm-0.6 release. In this
case except for the first card insertion after suspend/reboot I do get
the following messages:

tifm_7xx1: sd card detected in socket 3
mmcblk0: mmc0:7d7f SD01G 1006080KiB
 mmcblk0: p1

With 2.6.20, however, I always do get only the following which is the
same as for 2.6.18.2 on first card insert after reboot/suspend:

tifm_7xx1: sd card detected in socket 3

Am I doing something wrong here or is there a problem?

Relevant modules loaded with 2.6.20:

mmc_block   7944  0
tifm_sd10824  0
tifm_7xx1   7296  0
sdhci  17548  0
tifm_core   7960  2 tifm_sd,tifm_7xx1
mmc_core   24096  3 mmc_block,tifm_sd,sdhci

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6.20] net/ieee80211/ieee80211_crypt_tkip.c spams kernel message buffer

net/ieee80211/ieee80211_crypt_tkip.c outputs tons of these which didn't
happen with 2.6.18.2 (only one or two of these after enabling the
ipw2200 with the kill switch):

TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e560
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e574
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e588
printk: 18 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e59b
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e5af
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e5c3
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e5d7
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e5eb
printk: 19 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e5ff
printk: 16 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e612
printk: 17 messages suppressed.
TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200
received TSC 0002e626

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: oops in VMWARE vmnet, on 2.6.12.x

2005-08-09 Thread Andreas Steinmetz

Grzegorz Piotr Jaskiewicz wrote:
> I know that in general no one here is interested in vmware affairs, but in 
> hope that VMware folks are reading this list too, here's the oops:
> It's the newest vmware5 for linux from vmware.com

ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-update93.tar.gz

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: oops in VMWARE vmnet, on 2.6.12.x

2005-08-09 Thread Andreas Steinmetz

Grzegorz Piotr Jaskiewicz wrote:
 I know that in general no one here is interested in vmware affairs, but in 
 hope that VMware folks are reading this list too, here's the oops:
 It's the newest vmware5 for linux from vmware.com

ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-update93.tar.gz

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Wireless support

Lee Revell wrote:
> On Mon, 2005-08-08 at 20:13 +0200, Andreas Steinmetz wrote:
> 
>>I gave up on my laptop's built in Inprocomm IPN 2220 quite some time ago
>>(one more reason not to like Cisco). In the rare cases I do really need
>>wlan there is http://zd1211.sourceforge.net/
> 
> 
> Any idea how much hardware is out there that needs ndiswrapper to work?

No real idea but an educated guess: too much...

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Wireless support

Arjan van de Ven wrote:
> On Mon, 2005-08-08 at 13:48 -0400, Lee Revell wrote:
> 
>>On Mon, 2005-08-08 at 09:31 +0300, Denis Vlasenko wrote:
>>
>>>On Monday 08 August 2005 03:39, Alejandro Bonilla Beeche wrote:
>>>
>>>>On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote:
>>>>
>>>>>Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS)
>>>>>supported?
>>>>
>>>>Normally, linksys doesn't care much about Linux and they won't even
>>>>release info for a driver. Yeah, they have some open info for the WRT's
>>>>but the adapters are normally usable with ndiswrapper or Linuxant
>>>>driver.
>>>
>>>The more I read this, the more I think about usefulness of blacklisting
>>>ndiswrapper.
>>
>>What's your reasoning?  The technical aspect of the argument is obvious
>>(incompatible with 4K stacks) but the political side seems insolvable.
>>Wouldn't this leave thousands of users with non working hardware?\
> 
> 
> arguably it doesn't really work with ndiswrapper either; only most of
> the time (due to windows having a 12kb stack)... and it's effectively a
> binary only kernel module.
> 
> it also provides a discentive for vendors to provide real linux
> drivers
> 

Oh well,
I gave up on my laptop's built in Inprocomm IPN 2220 quite some time ago
(one more reason not to like Cisco). In the rare cases I do really need
wlan there is http://zd1211.sourceforge.net/

You can get it to work on x86_64. It currently has no wpa but I don't
care, IPSec is a proven solution. The code looks ugly but time will show
how it evolves. And about 40 EUR for the Longshine LCS-8170 802.11b/g
and Bluetooth 1.2 combo adapter isn't really expensive. The only
drawback is that it is another piece of external hardware to carry
around as well as some more laptop built in crap.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Wireless support

Arjan van de Ven wrote:
 On Mon, 2005-08-08 at 13:48 -0400, Lee Revell wrote:
 
On Mon, 2005-08-08 at 09:31 +0300, Denis Vlasenko wrote:

On Monday 08 August 2005 03:39, Alejandro Bonilla Beeche wrote:

On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote:

Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS)
supported?

Normally, linksys doesn't care much about Linux and they won't even
release info for a driver. Yeah, they have some open info for the WRT's
but the adapters are normally usable with ndiswrapper or Linuxant
driver.

The more I read this, the more I think about usefulness of blacklisting
ndiswrapper.

What's your reasoning?  The technical aspect of the argument is obvious
(incompatible with 4K stacks) but the political side seems insolvable.
Wouldn't this leave thousands of users with non working hardware?\
 
 
 arguably it doesn't really work with ndiswrapper either; only most of
 the time (due to windows having a 12kb stack)... and it's effectively a
 binary only kernel module.
 
 it also provides a discentive for vendors to provide real linux
 drivers
 

Oh well,
I gave up on my laptop's built in Inprocomm IPN 2220 quite some time ago
(one more reason not to like Cisco). In the rare cases I do really need
wlan there is http://zd1211.sourceforge.net/

You can get it to work on x86_64. It currently has no wpa but I don't
care, IPSec is a proven solution. The code looks ugly but time will show
how it evolves. And about 40 EUR for the Longshine LCS-8170 802.11b/g
and Bluetooth 1.2 combo adapter isn't really expensive. The only
drawback is that it is another piece of external hardware to carry
around as well as some more laptop built in crap.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Wireless support

Lee Revell wrote:
 On Mon, 2005-08-08 at 20:13 +0200, Andreas Steinmetz wrote:
 
I gave up on my laptop's built in Inprocomm IPN 2220 quite some time ago
(one more reason not to like Cisco). In the rare cases I do really need
wlan there is http://zd1211.sourceforge.net/
 
 
 Any idea how much hardware is out there that needs ndiswrapper to work?

No real idea but an educated guess: too much...

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc4: yenta_socket and swsusp

2005-08-07 Thread Andreas Steinmetz

Andrew Morton wrote:
> OK so we have one solid regression there.  Are the other problems also new
> since 2.6.11?
> 
> Could you please retest 2.6.13-rc6 when it's out and if problems remain,
> raise a bugzilla.kernel.org entry so we can keep track of the problem? 
> Thanks.

After retesting with 2.6.13-rc6 quite some of the problems are gone.
There are, however, still problems:

1. It is necessary to do the following or suspend will hang:

   cardctl eject
   killproc cardmgr
   remove all pcmcia modules

   In 2.6.11 it was sufficient to call 'cardctl eject'. I'll create a
   bug report.

2. The attached script can produce all sorts of pcmcia related
   problems if it is modified where stated - the attached version
   seems to work without problems if not modified. Do you want
   a bug report filed for this, too?
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]


pcmcia.sh
Description: Bourne shell script

Re: 2.6.13-rc4: yenta_socket and swsusp

2005-08-07 Thread Andreas Steinmetz

Andrew Morton wrote:
 OK so we have one solid regression there.  Are the other problems also new
 since 2.6.11?
 
 Could you please retest 2.6.13-rc6 when it's out and if problems remain,
 raise a bugzilla.kernel.org entry so we can keep track of the problem? 
 Thanks.

After retesting with 2.6.13-rc6 quite some of the problems are gone.
There are, however, still problems:

1. It is necessary to do the following or suspend will hang:

   cardctl eject
   killproc cardmgr
   remove all pcmcia modules

   In 2.6.11 it was sufficient to call 'cardctl eject'. I'll create a
   bug report.

2. The attached script can produce all sorts of pcmcia related
   problems if it is modified where stated - the attached version
   seems to work without problems if not modified. Do you want
   a bug report filed for this, too?
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]


pcmcia.sh
Description: Bourne shell script

Re: amd64-agp vs. swsusp

2005-08-06 Thread Andreas Steinmetz

Cal Peake wrote:
> On Fri, 5 Aug 2005, Andreas Steinmetz wrote:
> 
> 
>>AFAIK it works when agp is built into the kernel. You will get problems
>>when it is built as a module. In the module case you may want to try if
>>loading the module before resuming helps.
> 
> 
> Strange. I've had it built as a module from day one and never had a 
> problem resuming.

I guess it depends on what the BIOS does.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: amd64-agp vs. swsusp

2005-08-06 Thread Andreas Steinmetz

Cal Peake wrote:
 On Fri, 5 Aug 2005, Andreas Steinmetz wrote:
 
 
AFAIK it works when agp is built into the kernel. You will get problems
when it is built as a module. In the module case you may want to try if
loading the module before resuming helps.
 
 
 Strange. I've had it built as a module from day one and never had a 
 problem resuming.

I guess it depends on what the BIOS does.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: amd64-agp vs. swsusp

2005-08-05 Thread Andreas Steinmetz

Cal Peake wrote:
> On Thu, 4 Aug 2005, Andrew Morton wrote:
> 
> 
>>Michal Schmidt <[EMAIL PROTECTED]> wrote:
>>
>>>Does resuming from swsuspend work for anyone with amd64-agp loaded?
>>
>>It would seem not ;)
> 
> 
> Must have missed the OP. Yes I can resume fine from swsusp with amd64-agp.
> 
> System is an Averatec 3270 (Mobile Sempron(K8)).
> 
> Not that this helps at all other than confirming it is possible ;)
> 
> -cp
> 

AFAIK it works when agp is built into the kernel. You will get problems
when it is built as a module. In the module case you may want to try if
loading the module before resuming helps.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: amd64-agp vs. swsusp

2005-08-05 Thread Andreas Steinmetz

Cal Peake wrote:
 On Thu, 4 Aug 2005, Andrew Morton wrote:
 
 
Michal Schmidt [EMAIL PROTECTED] wrote:

Does resuming from swsuspend work for anyone with amd64-agp loaded?

It would seem not ;)
 
 
 Must have missed the OP. Yes I can resume fine from swsusp with amd64-agp.
 
 System is an Averatec 3270 (Mobile Sempron(K8)).
 
 Not that this helps at all other than confirming it is possible ;)
 
 -cp
 

AFAIK it works when agp is built into the kernel. You will get problems
when it is built as a module. In the module case you may want to try if
loading the module before resuming helps.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13-rc4-git4: bluetooth oops on pcmcia shutdown

The attached bluetooth oops can be reliably reproduced on my x86_64
laptop. It happens when hciattach is still running while a sequence of
"cardctl eject" and then "killproc /sbin/cardmgr" is executed.
Though this seems to point to preempt I could manage to cause similar
oopses on non-preemptible kernels a while ago.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
Unable to handle kernel NULL pointer dereference at 0014 RIP: 
{uart_flush_buffer+43}
PGD 0 
Oops: 0002 [1] PREEMPT 
CPU 0 
Modules linked in: hci_usb serial_cs pcmcia yenta_socket rsrc_nonstatic 
pcmcia_core ehci_hcd uhci_hcd parport_pc parport snd_via82xx_modem snd_seq_oss 
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss hfc_usb ipaq usbhid pl2303 
usbserial usb_storage snd_via82xx gameport sd_mod snd_ac97_codec snd_pcm 
snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device hisax isdn 
nls_iso8859_15 nls_cp850 ip_conntrack_ftp ipt_state ip_conntrack ipt_ULOG 
iptable_filter ipt_REJECT ip_tables nfsd exportfs lockd sunrpc autofs4 cifs sbp2
Pid: 2995, comm: hciattach Not tainted 2.6.13-rc4-git4-gringo
RIP: 0010:[] {uart_flush_buffer+43}
RSP: 0018:81001c0b9b68  EFLAGS: 00010013
RAX:  RBX: 810002208c80 RCX: 81001e6d3018
RDX:  RSI: 81001c0b9b58 RDI: 0001
RBP: 81001e6d3000 R08: 81003f01ce98 R09: 0001
R10:  R11: 0246 R12: 81003d76ba80
R13: 8052e6c0 R14:  R15: 
FS:  2af3edb0() GS:8061c800() knlGS:556d16b0
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 0014 CR3: 1b1a2000 CR4: 06e0
Process hciattach (pid: 2995, threadinfo 81001c0b8000, task 
81001f94f4a0)
Stack: 0292 81003db82200 81001e6d3000 803567ac 
    81003db82200 81002614ac00 803567e4 
   8052e6c0 80356931 
Call Trace:{hci_uart_flush+92} 
{hci_uart_close+20}
   {hci_uart_tty_close+49} 
{release_dev+1805}
   {free_hot_cold_page+239} 
{free_pgd_range+1078}
   {_atomic_dec_and_lock+38} {dput+35}
   {tty_release+17} {__fput+178}
   {filp_close+110} 
{put_files_struct+115}
   {do_exit+522} {__dequeue_signal+501}
   {do_group_exit+269} 
{get_signal_to_deliver+1515}
   {do_signal+159} {thread_return+0}
   {thread_return+220} 
{lock_timer_base+49}
   {del_timer+104} 
{schedule_timeout+156}
   {process_timeout+0} 
{sysret_signal+28}
   {ptregscall_common+103} 

Code: c7 40 14 00 00 00 00 c7 40 10 00 00 00 00 ff 34 24 9d bf 01 
RIP {uart_flush_buffer+43} RSP 
CR2: 0014
 <1>Fixing recursive fault but reboot is needed!
scheduling while atomic: hciattach/0x0001/2995

Call Trace:{schedule+122} {do_exit+246}
   {do_unblank_screen+21} 
{do_page_fault+1807}
   {error_exit+0} {uart_flush_buffer+43}
   {uart_flush_buffer+39} 
{hci_uart_flush+92}
   {hci_uart_close+20} 
{hci_uart_tty_close+49}
   {release_dev+1805} 
{free_hot_cold_page+239}
   {free_pgd_range+1078} 
{_atomic_dec_and_lock+38}
   {dput+35} {tty_release+17}
   {__fput+178} {filp_close+110}
   {put_files_struct+115} {do_exit+522}
   {__dequeue_signal+501} 
{do_group_exit+269}
   {get_signal_to_deliver+1515} 
{do_signal+159}
   {thread_return+0} {thread_return+220}
   {lock_timer_base+49} {del_timer+104}
   {schedule_timeout+156} 
{process_timeout+0}
   {sysret_signal+28} 
{ptregscall_common+103}

2.6.13-rc4: yenta_socket and swsusp

[now sending to lkml as sending to the pcmcia list without being
subscribed seems to go to /dev/null]

I do have problems with yenta_socket on my x86_64 laptop which appear
when using swsusp (suspend to disk mode).

1. When I do not access any pcmcia device from initrd during boot
   I have to terminate cardmgr, otherwise suspend to disk hangs.
   For 2.6.11 it was sufficient to call 'cardctl eject'.

2. When I have to access a pcmcia device from initrd during boot
   (there's required crypto keys stored on a pcmcia flash disk)
   and I do not unload yenta_socket prior to suspend the laptop
   spontaneously reboots or just hangs on resume when swsusp has
   finished loading.

3. If I do not unload the pcmcia modules prior to suspend with
   rmmod -w unloading yenta_socket fails.

4. If I do unload the pcmcia modules in a loop with rmmod -w
   but no delay between unloading the modules it happens from
   time to time that yenta_socket unloading hangs with a use
   count of 2 when there is definitely no more user of the module.
   A delay of 50 msec after unload of each pcmcia module seems
   to cure this.

5. If I insert yenta_socket within the first few seconds after resume
   the laptop spontaneously reboots. A 5 second delay seems to cure
   this most of the time.

BTW:
Did I read this right? PCMCIA control ioctl (needed for pcmcia-cs
[cardmgr, cardctl]) scheduled for removal in november *this* year? So a
3 month warning for everybody is sufficient? Probably only one kernel
release? So much for sufficient backwards compatability. Especially as
the tools stated to be required aren't even released as of today (hint:
module-init-tools 3.2). Grrr.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13-rc4: yenta_socket and swsusp

[now sending to lkml as sending to the pcmcia list without being
subscribed seems to go to /dev/null]

I do have problems with yenta_socket on my x86_64 laptop which appear
when using swsusp (suspend to disk mode).

1. When I do not access any pcmcia device from initrd during boot
   I have to terminate cardmgr, otherwise suspend to disk hangs.
   For 2.6.11 it was sufficient to call 'cardctl eject'.

2. When I have to access a pcmcia device from initrd during boot
   (there's required crypto keys stored on a pcmcia flash disk)
   and I do not unload yenta_socket prior to suspend the laptop
   spontaneously reboots or just hangs on resume when swsusp has
   finished loading.

3. If I do not unload the pcmcia modules prior to suspend with
   rmmod -w unloading yenta_socket fails.

4. If I do unload the pcmcia modules in a loop with rmmod -w
   but no delay between unloading the modules it happens from
   time to time that yenta_socket unloading hangs with a use
   count of 2 when there is definitely no more user of the module.
   A delay of 50 msec after unload of each pcmcia module seems
   to cure this.

5. If I insert yenta_socket within the first few seconds after resume
   the laptop spontaneously reboots. A 5 second delay seems to cure
   this most of the time.

BTW:
Did I read this right? PCMCIA control ioctl (needed for pcmcia-cs
[cardmgr, cardctl]) scheduled for removal in november *this* year? So a
3 month warning for everybody is sufficient? Probably only one kernel
release? So much for sufficient backwards compatability. Especially as
the tools stated to be required aren't even released as of today (hint:
module-init-tools 3.2). Grrr.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13-rc4-git4: bluetooth oops on pcmcia shutdown

The attached bluetooth oops can be reliably reproduced on my x86_64
laptop. It happens when hciattach is still running while a sequence of
cardctl eject and then killproc /sbin/cardmgr is executed.
Though this seems to point to preempt I could manage to cause similar
oopses on non-preemptible kernels a while ago.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
Unable to handle kernel NULL pointer dereference at 0014 RIP: 
802cc1fb{uart_flush_buffer+43}
PGD 0 
Oops: 0002 [1] PREEMPT 
CPU 0 
Modules linked in: hci_usb serial_cs pcmcia yenta_socket rsrc_nonstatic 
pcmcia_core ehci_hcd uhci_hcd parport_pc parport snd_via82xx_modem snd_seq_oss 
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss hfc_usb ipaq usbhid pl2303 
usbserial usb_storage snd_via82xx gameport sd_mod snd_ac97_codec snd_pcm 
snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device hisax isdn 
nls_iso8859_15 nls_cp850 ip_conntrack_ftp ipt_state ip_conntrack ipt_ULOG 
iptable_filter ipt_REJECT ip_tables nfsd exportfs lockd sunrpc autofs4 cifs sbp2
Pid: 2995, comm: hciattach Not tainted 2.6.13-rc4-git4-gringo
RIP: 0010:[802cc1fb] 802cc1fb{uart_flush_buffer+43}
RSP: 0018:81001c0b9b68  EFLAGS: 00010013
RAX:  RBX: 810002208c80 RCX: 81001e6d3018
RDX:  RSI: 81001c0b9b58 RDI: 0001
RBP: 81001e6d3000 R08: 81003f01ce98 R09: 0001
R10:  R11: 0246 R12: 81003d76ba80
R13: 8052e6c0 R14:  R15: 
FS:  2af3edb0() GS:8061c800() knlGS:556d16b0
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 0014 CR3: 1b1a2000 CR4: 06e0
Process hciattach (pid: 2995, threadinfo 81001c0b8000, task 
81001f94f4a0)
Stack: 0292 81003db82200 81001e6d3000 803567ac 
    81003db82200 81002614ac00 803567e4 
   8052e6c0 80356931 
Call Trace:803567ac{hci_uart_flush+92} 
803567e4{hci_uart_close+20}
   80356931{hci_uart_tty_close+49} 
802b108d{release_dev+1805}
   80159a7f{free_hot_cold_page+239} 
80163876{free_pgd_range+1078}
   802617f6{_atomic_dec_and_lock+38} 8018f863{dput+35}
   802b1191{tty_release+17} 80177642{__fput+178}
   80175cbe{filp_close+110} 
80132813{put_files_struct+115}
   801331da{do_exit+522} 8013b745{__dequeue_signal+501}
   80133dad{do_group_exit+269} 
8013d8eb{get_signal_to_deliver+1515}
   8010ce9f{do_signal+159} 80408174{thread_return+0}
   80408250{thread_return+220} 
80139b31{lock_timer_base+49}
   80139be8{del_timer+104} 
80408f6c{schedule_timeout+156}
   8013a7c0{process_timeout+0} 
8010db2f{sysret_signal+28}
   8010de17{ptregscall_common+103} 

Code: c7 40 14 00 00 00 00 c7 40 10 00 00 00 00 ff 34 24 9d bf 01 
RIP 802cc1fb{uart_flush_buffer+43} RSP 81001c0b9b68
CR2: 0014
 1Fixing recursive fault but reboot is needed!
scheduling while atomic: hciattach/0x0001/2995

Call Trace:80407caa{schedule+122} 801330c6{do_exit+246}
   802bf5c5{do_unblank_screen+21} 
8011d95f{do_page_fault+1807}
   8010e399{error_exit+0} 802cc1fb{uart_flush_buffer+43}
   802cc1f7{uart_flush_buffer+39} 
803567ac{hci_uart_flush+92}
   803567e4{hci_uart_close+20} 
80356931{hci_uart_tty_close+49}
   802b108d{release_dev+1805} 
80159a7f{free_hot_cold_page+239}
   80163876{free_pgd_range+1078} 
802617f6{_atomic_dec_and_lock+38}
   8018f863{dput+35} 802b1191{tty_release+17}
   80177642{__fput+178} 80175cbe{filp_close+110}
   80132813{put_files_struct+115} 801331da{do_exit+522}
   8013b745{__dequeue_signal+501} 
80133dad{do_group_exit+269}
   8013d8eb{get_signal_to_deliver+1515} 
8010ce9f{do_signal+159}
   80408174{thread_return+0} 80408250{thread_return+220}
   80139b31{lock_timer_base+49} 80139be8{del_timer+104}
   80408f6c{schedule_timeout+156} 
8013a7c0{process_timeout+0}
   8010db2f{sysret_signal+28} 
8010de17{ptregscall_common+103}

Re: revert yenta free_irq on suspend

Dave Jones wrote:
> On Mon, Aug 01, 2005 at 02:00:16AM +0200, Andreas Steinmetz wrote:
> 
>  > gringo:~ # fdisk -l /dev/hda
>  > 
>  > Disk /dev/hda: 80.0 GB, 80026361856 bytes
>  > 255 heads, 63 sectors/track, 9729 cylinders
>  > Units = cylinders of 16065 * 512 = 8225280 bytes
>  > 
>  >Device Boot   Start  End  Blocks   Id  System
>  > /dev/hda11  244 1959898+  83  Linux
>  > /dev/hda2  245  488 1959930   82  Linux swap / Solaris
>  > /dev/hda3  489  732 1959930   82  Linux swap / Solaris
>  > /dev/hda4  733 972972268402+   5  Extended
>  > /dev/hda5  733  976 1959898+  82  Linux swap / Solaris
>  > /dev/hda6  977 972970308441   88  Linux plaintext (*)
>  > 
>  > (*) dm-crypt :-)
> 
> Your swap partitions are outside of your lv's.

Right, then this could be the problem you encountered. However the swap
partitions are set up with dm-crypt including the partition I do resume
from so I'm using device mapper to resume which is quite close to LVM.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: revert yenta free_irq on suspend

Dave Jones wrote:
> On Sun, Jul 31, 2005 at 01:03:56AM -0400, Brown, Len wrote:
> 
>  > But that believe would be total fantasy -- supsend/resume is not
>  > working on a large number of machines, and no distro is currently
>  > able to support it.  (I'm talking about S3 suspend to RAM primarily,
>  > suspend to disk is less interesting -- though Red Hat doesn't
>  > even support _that_)
> 
> After the 'swsusp works just fine' lovefest at OLS, I spent a little
> while playing with the current in-tree swsusp implementation last week.
> 
> The outcome: I'm no more enthusiastic about enabling this in Red Hat
> kernels than I ever was before.  It seems to have real issues with LVM
> setups (which is default on Red Hat/Fedora installs these days).
> After convincing it where to suspend/resume from by feeding it
> the major/minor of my swap partition, it did actually seem
> to suspend. And resume (though it did spew lots of 'sleeping whilst
> atomic warnings, but thats trivial compared to whats coming up next).
> 
> I rebooted, and fsck found all sorts of damage on my / partition.
> After spending 30 minutes pressing 'y', to fix things up, it failed
> to boot after lots of files were missing.
> Why it wrote anything to completely different lv to where I told it
> (and yes, I did get the major:minor right) I have no idea, but
> as it stands, it definitly isn't production-ready.
> 
> I'll look into it again sometime soon, but not until after I've
> reinstalled my laptop.  (I'm just thankful I had the sense not to
> try this whilst I was at OLS).

Hmm,
I'm using swsusp on my x86_64 laptop with lvm and dm-crypt. Works just
fine except for nasty spontaneous reboots from time to time caused by
yenta_socket (I do get these since I started to access my pcmcia flash
disk from initrd to retrieve the dm-crypt swap key). It does work since
at least 2.6.11 up to 2.6.13-rc4 and if the yenta_socket caused
spontaneous reboots after resume could be fixed I'd call it production
ready.

gringo:~ # fdisk -l /dev/hda

Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot   Start  End  Blocks   Id  System
/dev/hda11  244 1959898+  83  Linux
/dev/hda2  245  488 1959930   82  Linux swap / Solaris
/dev/hda3  489  732 1959930   82  Linux swap / Solaris
/dev/hda4  733 972972268402+   5  Extended
/dev/hda5  733  976 1959898+  82  Linux swap / Solaris
/dev/hda6  977 972970308441   88  Linux plaintext (*)

(*) dm-crypt :-)

gringo:~ # vgdisplay
  --- Volume group ---
  VG Name   rootvg
  System ID
  Formatlvm2
  Metadata Areas1
  Metadata Sequence No  27
  VG Access read/write
  VG Status resizable
  MAX LV0
  Cur LV8
  Open LV   8
  Max PV0
  Cur PV1
  Act PV1
  VG Size   67.05 GB
  PE Size   4.00 MB
  Total PE  17165
  Alloc PE / Size   14464 / 56.50 GB
  Free  PE / Size   2701 / 10.55 GB
  VG UUID   oHluq0-H5Nd-90dU-psLn-ygNT-u4GJ-D8aJhG

All filesystems are ext3 as I did have nasty experiences with reiserfs
on lvm+raid on another 2.6 system without ever using swsusp there.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc4-mm1

Andrew Morton wrote:
> Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
> 
>>Andrew Morton wrote:
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
>>
>> Andrew,
>> the good news is I can access pcmcia devices with rc4-mm1 which I
>> couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least
>> one more problem with yenta_socket. Please see the attached dmesg output
>> and look for:
>>
>> Badness in __release_resource at kernel/resource.c:184
>>
>> This happens when accessing pcmcia from an initrd to read keys from a
>> pcmcia flash disk and removing the pcmcia modules afterwards.
> 
> 
> hm, OK.  That's brought to us by the below -mm-only debugging patch.  Maybe
> we should add more stuff to it to idenfify the child resources?
> 

Well, could be. Unfortunately I have zero knowledge in this area of the
kernel. Maybe Dominik can help?

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc4-mm1

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/

Andrew,
the good news is I can access pcmcia devices with rc4-mm1 which I
couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least
one more problem with yenta_socket. Please see the attached dmesg output
and look for:

Badness in __release_resource at kernel/resource.c:184

This happens when accessing pcmcia from an initrd to read keys from a
pcmcia flash disk and removing the pcmcia modules afterwards.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
Bootdata ok (command line is BOOT_IMAGE=2.6.13rc4mm hdb=none hdc=cdrom hdd=none 
elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off root=/dev/ram0 
init=/linuxrc rw)
Linux version 2.6.13-rc4-mm1-gringo ([EMAIL PROTECTED]) (gcc version 3.4.4) #1 
PREEMPT Sun Jul 31 15:11:12 CEST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f800 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000d8000 - 0010 (reserved)
 BIOS-e820: 0010 - 3ff7 (usable)
 BIOS-e820: 3ff7 - 3ff7a000 (ACPI data)
 BIOS-e820: 3ff7a000 - 3ff8 (ACPI NVS)
 BIOS-e820: 3ff8 - 4000 (reserved)
 BIOS-e820: fffe - 0001 (reserved)
ACPI: RSDP (v000 PTLTD ) @ 0x000f6a60
ACPI: RSDT (v001 PTLTDRSDT   0x0604  LTP 0x) @ 
0x3ff73fde
ACPI: FADT (v002 AMDK8  PTLTW0x0604 PTL_ 0x000f4240) @ 
0x3ff79e56
ACPI: SSDT (v001 PTLTD  POWERNOW 0x0604  LTP 0x0001) @ 
0x3ff79eda
ACPI: MADT (v001 PTLTD   APIC   0x0604  LTP 0x) @ 
0x3ff79fb0
ACPI: DSDT (v001  VIA   PTL_ACPI 0x0604 MSFT 0x010e) @ 
0x
On node 0 totalpages: 262000
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 257904 pages, LIFO batch:31
  HighMem zone: 0 pages, LIFO batch:1
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 4000 (gap: 4000:bffe)
Built 1 zonelists
Initializing CPU#0
Kernel command line: BOOT_IMAGE=2.6.13rc4mm hdb=none hdc=cdrom hdd=none 
elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off root=/dev/ram0 
init=/linuxrc rw
ide_setup: hdb=none
ide_setup: hdc=cdrom
ide_setup: hdd=none
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 3.579545 MHz PM timer.
time.c: Detected 1801.073 MHz processor.
time.c: Using PIT/TSC based timekeeping.
Console: colour VGA+ 80x50
time.c: Lost 3 timer tick(s)! rip start_kernel+0xfd/0x1f0)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1023708k/1048000k available (3160k kernel code, 23596k reserved, 1340k 
data, 176k init)
Calibrating delay using timer specific routine.. 3606.48 BogoMIPS (lpj=1803241)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
mtrr: v2.0 (20020519)
CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 0a
time.c: Lost 85 timer tick(s)! rip acpi_os_write_port+0x1a/0x38)
Using local APIC timer interrupts.
Detected 12.507 MHz APIC timer.
time.c: Lost 56 timer tick(s)! rip setup_boot_APIC_clock+0x112/0x120)
testing NMI watchdog ... OK.
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
softlockup thread 0 started up.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20050408
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] segment is 0
Boot video device is :01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled.
ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled.
ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled.
ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled.
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10
ACPI: PCI Interrupt L

Re: 2.6.13-rc4-mm1

Andrew Morton wrote:
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/

Andrew,
the good news is I can access pcmcia devices with rc4-mm1 which I
couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least
one more problem with yenta_socket. Please see the attached dmesg output
and look for:

Badness in __release_resource at kernel/resource.c:184

This happens when accessing pcmcia from an initrd to read keys from a
pcmcia flash disk and removing the pcmcia modules afterwards.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
Bootdata ok (command line is BOOT_IMAGE=2.6.13rc4mm hdb=none hdc=cdrom hdd=none 
elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off root=/dev/ram0 
init=/linuxrc rw)
Linux version 2.6.13-rc4-mm1-gringo ([EMAIL PROTECTED]) (gcc version 3.4.4) #1 
PREEMPT Sun Jul 31 15:11:12 CEST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f800 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000d8000 - 0010 (reserved)
 BIOS-e820: 0010 - 3ff7 (usable)
 BIOS-e820: 3ff7 - 3ff7a000 (ACPI data)
 BIOS-e820: 3ff7a000 - 3ff8 (ACPI NVS)
 BIOS-e820: 3ff8 - 4000 (reserved)
 BIOS-e820: fffe - 0001 (reserved)
ACPI: RSDP (v000 PTLTD ) @ 0x000f6a60
ACPI: RSDT (v001 PTLTDRSDT   0x0604  LTP 0x) @ 
0x3ff73fde
ACPI: FADT (v002 AMDK8  PTLTW0x0604 PTL_ 0x000f4240) @ 
0x3ff79e56
ACPI: SSDT (v001 PTLTD  POWERNOW 0x0604  LTP 0x0001) @ 
0x3ff79eda
ACPI: MADT (v001 PTLTD   APIC   0x0604  LTP 0x) @ 
0x3ff79fb0
ACPI: DSDT (v001  VIA   PTL_ACPI 0x0604 MSFT 0x010e) @ 
0x
On node 0 totalpages: 262000
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 257904 pages, LIFO batch:31
  HighMem zone: 0 pages, LIFO batch:1
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 4000 (gap: 4000:bffe)
Built 1 zonelists
Initializing CPU#0
Kernel command line: BOOT_IMAGE=2.6.13rc4mm hdb=none hdc=cdrom hdd=none 
elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off root=/dev/ram0 
init=/linuxrc rw
ide_setup: hdb=none
ide_setup: hdc=cdrom
ide_setup: hdd=none
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 3.579545 MHz PM timer.
time.c: Detected 1801.073 MHz processor.
time.c: Using PIT/TSC based timekeeping.
Console: colour VGA+ 80x50
time.c: Lost 3 timer tick(s)! rip start_kernel+0xfd/0x1f0)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1023708k/1048000k available (3160k kernel code, 23596k reserved, 1340k 
data, 176k init)
Calibrating delay using timer specific routine.. 3606.48 BogoMIPS (lpj=1803241)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
mtrr: v2.0 (20020519)
CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 0a
time.c: Lost 85 timer tick(s)! rip acpi_os_write_port+0x1a/0x38)
Using local APIC timer interrupts.
Detected 12.507 MHz APIC timer.
time.c: Lost 56 timer tick(s)! rip setup_boot_APIC_clock+0x112/0x120)
testing NMI watchdog ... OK.
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
softlockup thread 0 started up.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20050408
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] segment is 0
Boot video device is :01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled.
ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled.
ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled.
ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled.
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10
ACPI: PCI Interrupt Link

Re: 2.6.13-rc4-mm1

Andrew Morton wrote:
 Andreas Steinmetz [EMAIL PROTECTED] wrote:
 
Andrew Morton wrote:
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/

 Andrew,
 the good news is I can access pcmcia devices with rc4-mm1 which I
 couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least
 one more problem with yenta_socket. Please see the attached dmesg output
 and look for:

 Badness in __release_resource at kernel/resource.c:184

 This happens when accessing pcmcia from an initrd to read keys from a
 pcmcia flash disk and removing the pcmcia modules afterwards.
 
 
 hm, OK.  That's brought to us by the below -mm-only debugging patch.  Maybe
 we should add more stuff to it to idenfify the child resources?
 

Well, could be. Unfortunately I have zero knowledge in this area of the
kernel. Maybe Dominik can help?

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: revert yenta free_irq on suspend

Dave Jones wrote:
 On Sun, Jul 31, 2005 at 01:03:56AM -0400, Brown, Len wrote:
 
   But that believe would be total fantasy -- supsend/resume is not
   working on a large number of machines, and no distro is currently
   able to support it.  (I'm talking about S3 suspend to RAM primarily,
   suspend to disk is less interesting -- though Red Hat doesn't
   even support _that_)
 
 After the 'swsusp works just fine' lovefest at OLS, I spent a little
 while playing with the current in-tree swsusp implementation last week.
 
 The outcome: I'm no more enthusiastic about enabling this in Red Hat
 kernels than I ever was before.  It seems to have real issues with LVM
 setups (which is default on Red Hat/Fedora installs these days).
 After convincing it where to suspend/resume from by feeding it
 the major/minor of my swap partition, it did actually seem
 to suspend. And resume (though it did spew lots of 'sleeping whilst
 atomic warnings, but thats trivial compared to whats coming up next).
 
 I rebooted, and fsck found all sorts of damage on my / partition.
 After spending 30 minutes pressing 'y', to fix things up, it failed
 to boot after lots of files were missing.
 Why it wrote anything to completely different lv to where I told it
 (and yes, I did get the major:minor right) I have no idea, but
 as it stands, it definitly isn't production-ready.
 
 I'll look into it again sometime soon, but not until after I've
 reinstalled my laptop.  (I'm just thankful I had the sense not to
 try this whilst I was at OLS).

Hmm,
I'm using swsusp on my x86_64 laptop with lvm and dm-crypt. Works just
fine except for nasty spontaneous reboots from time to time caused by
yenta_socket (I do get these since I started to access my pcmcia flash
disk from initrd to retrieve the dm-crypt swap key). It does work since
at least 2.6.11 up to 2.6.13-rc4 and if the yenta_socket caused
spontaneous reboots after resume could be fixed I'd call it production
ready.

gringo:~ # fdisk -l /dev/hda

Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot   Start  End  Blocks   Id  System
/dev/hda11  244 1959898+  83  Linux
/dev/hda2  245  488 1959930   82  Linux swap / Solaris
/dev/hda3  489  732 1959930   82  Linux swap / Solaris
/dev/hda4  733 972972268402+   5  Extended
/dev/hda5  733  976 1959898+  82  Linux swap / Solaris
/dev/hda6  977 972970308441   88  Linux plaintext (*)

(*) dm-crypt :-)

gringo:~ # vgdisplay
  --- Volume group ---
  VG Name   rootvg
  System ID
  Formatlvm2
  Metadata Areas1
  Metadata Sequence No  27
  VG Access read/write
  VG Status resizable
  MAX LV0
  Cur LV8
  Open LV   8
  Max PV0
  Cur PV1
  Act PV1
  VG Size   67.05 GB
  PE Size   4.00 MB
  Total PE  17165
  Alloc PE / Size   14464 / 56.50 GB
  Free  PE / Size   2701 / 10.55 GB
  VG UUID   oHluq0-H5Nd-90dU-psLn-ygNT-u4GJ-D8aJhG

All filesystems are ext3 as I did have nasty experiences with reiserfs
on lvm+raid on another 2.6 system without ever using swsusp there.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: revert yenta free_irq on suspend

Dave Jones wrote:
 On Mon, Aug 01, 2005 at 02:00:16AM +0200, Andreas Steinmetz wrote:
 
   gringo:~ # fdisk -l /dev/hda
   
   Disk /dev/hda: 80.0 GB, 80026361856 bytes
   255 heads, 63 sectors/track, 9729 cylinders
   Units = cylinders of 16065 * 512 = 8225280 bytes
   
  Device Boot   Start  End  Blocks   Id  System
   /dev/hda11  244 1959898+  83  Linux
   /dev/hda2  245  488 1959930   82  Linux swap / Solaris
   /dev/hda3  489  732 1959930   82  Linux swap / Solaris
   /dev/hda4  733 972972268402+   5  Extended
   /dev/hda5  733  976 1959898+  82  Linux swap / Solaris
   /dev/hda6  977 972970308441   88  Linux plaintext (*)
   
   (*) dm-crypt :-)
 
 Your swap partitions are outside of your lv's.

Right, then this could be the problem you encountered. However the swap
partitions are set up with dm-crypt including the partition I do resume
from so I'm using device mapper to resume which is quite close to LVM.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] swsusp with dm-crypt mini howto

2005-07-30 Thread Andreas Steinmetz

Pavel Machek wrote:
> It looks good. Perhaps it should go into
> Documentation/power/swsusp-dmcrypt.txt? Could you write you copyright
> and GPL in there, sign it off, and cc: it to linux-kernel?
>   Pavel

The attached patch contains a mini howto for using dm-crypt together
with swsusp.

Signed-off-by: Andreas Steinmetz <[EMAIL PROTECTED]>
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
--- linux.orig/Documentation/power/swsusp-dmcrypt.txt   2003-09-24 
00:19:32.0 +0200
+++ linux/Documentation/power/swsusp-dmcrypt.txt2005-07-30 
19:03:56.0 +0200
@@ -0,0 +1,138 @@
+Author: Andreas Steinmetz <[EMAIL PROTECTED]>
+
+
+How to use dm-crypt and swsusp together:
+
+
+Some prerequisites:
+You know how dm-crypt works. If not, visit the following web page:
+http://www.saout.de/misc/dm-crypt/
+You have read Documentation/power/swsusp.txt and understand it.
+You did read Documentation/initrd.txt and know how an initrd works.
+You know how to create or how to modify an initrd.
+
+Now your system is properly set up, your disk is encrypted except for
+the swap device(s) and the boot partition which may contain a mini
+system for crypto setup and/or rescue purposes. You may even have
+an initrd that does your current crypto setup already.
+
+At this point you want to encrypt your swap, too. Still you want to
+be able to suspend using swsusp. This, however, means that you
+have to be able to either enter a passphrase or that you read
+the key(s) from an external device like a pcmcia flash disk
+or an usb stick prior to resume. So you need an initrd, that sets
+up dm-crypt and then asks swsusp to resume from the encrypted
+swap device.
+
+The most important thing is that you set up dm-crypt in such
+a way that the swap device you suspend to/resume from has
+always the same major/minor within the initrd as well as
+within your running system. The easiest way to achieve this is
+to always set up this swap device first with dmsetup, so that
+it will always look like the following:
+
+brw---  1 root root 254, 0 Jul 28 13:37 /dev/mapper/swap0
+
+Now set up your kernel to use /dev/mapper/swap0 as the default
+resume partition, so your kernel .config contains:
+
+CONFIG_PM_STD_PARTITION="/dev/mapper/swap0"
+
+Prepare your boot loader to use the initrd you will create or
+modify. For lilo the simplest setup looks like the following
+lines:
+
+image=/boot/vmlinuz
+initrd=/boot/initrd.gz
+label=linux
+append="root=/dev/ram0 init=/linuxrc rw"
+
+Finally you need to create or modify your initrd. Lets assume
+you create an initrd that reads the required dm-crypt setup
+from a pcmcia flash disk card. The card is formatted with an ext2
+fs which resides on /dev/hde1 when the card is inserted. The
+card contains at least the encrypted swap setup in a file
+named "swapkey". /etc/fstab of your initrd contains something
+like the following:
+
+/dev/hda1   /mntext3  ro0 0
+none/proc   proc  defaults,noatime,nodiratime   0 0
+none/syssysfs defaults,noatime,nodiratime   0 0
+
+/dev/hda1 contains an unencrypted mini system that sets up all
+of your crypto devices, again by reading the setup from the
+pcmcia flash disk. What follows now is a /linuxrc for your
+initrd that allows you to resume from encrypted swap and that
+continues boot with your mini system on /dev/hda1 if resume
+does not happen:
+
+#!/bin/sh
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+mount /proc
+mount /sys
+mapped=0
+noresume=`grep -c noresume /proc/cmdline`
+if [ "$*" != "" ]
+then
+  noresume=1
+fi
+dmesg -n 1
+/sbin/cardmgr -q
+for i in 1 2 3 4 5 6 7 8 9 0
+do
+  if [ -f /proc/ide/hde/media ]
+  then
+usleep 50
+mount -t ext2 -o ro /dev/hde1 /mnt
+if [ -f /mnt/swapkey ]
+then
+  dmsetup create swap0 /mnt/swapkey > /dev/null 2>&1 && mapped=1
+fi
+umount /mnt
+break
+  fi
+  usleep 50
+done
+killproc /sbin/cardmgr
+dmesg -n 6
+if [ $mapped = 1 ]
+then
+  if [ $noresume != 0 ]
+  then
+mkswap /dev/mapper/swap0 > /dev/null 2>&1
+  fi
+  echo 254:0 > /sys/power/resume
+  dmsetup remove swap0
+fi
+umount /sys
+mount /mnt
+umount /proc
+cd /mnt
+pivot_root . mnt
+mount /proc
+umount -l /mnt
+umount /proc
+exec chroot . /sbin/init $* < dev/console > dev/console 2>&1
+
+Please don't mind the weird loop above, busybox's msh doesn't know
+the let statement. Now, what is happening in the script?
+First we have to decide if we want to try to resume, or not.
+We will not resume if booting with "noresume" or any parameters
+for init like "single" or "emergency" as boot parameters.
+
+Then we need to set up dmcrypt with the setup data from the
+pcmcia flash disk. If this succeeds we need t

[PATCH] swsusp with dm-crypt mini howto

2005-07-30 Thread Andreas Steinmetz

Pavel Machek wrote:
 It looks good. Perhaps it should go into
 Documentation/power/swsusp-dmcrypt.txt? Could you write you copyright
 and GPL in there, sign it off, and cc: it to linux-kernel?
   Pavel

The attached patch contains a mini howto for using dm-crypt together
with swsusp.

Signed-off-by: Andreas Steinmetz [EMAIL PROTECTED]
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
--- linux.orig/Documentation/power/swsusp-dmcrypt.txt   2003-09-24 
00:19:32.0 +0200
+++ linux/Documentation/power/swsusp-dmcrypt.txt2005-07-30 
19:03:56.0 +0200
@@ -0,0 +1,138 @@
+Author: Andreas Steinmetz [EMAIL PROTECTED]
+
+
+How to use dm-crypt and swsusp together:
+
+
+Some prerequisites:
+You know how dm-crypt works. If not, visit the following web page:
+http://www.saout.de/misc/dm-crypt/
+You have read Documentation/power/swsusp.txt and understand it.
+You did read Documentation/initrd.txt and know how an initrd works.
+You know how to create or how to modify an initrd.
+
+Now your system is properly set up, your disk is encrypted except for
+the swap device(s) and the boot partition which may contain a mini
+system for crypto setup and/or rescue purposes. You may even have
+an initrd that does your current crypto setup already.
+
+At this point you want to encrypt your swap, too. Still you want to
+be able to suspend using swsusp. This, however, means that you
+have to be able to either enter a passphrase or that you read
+the key(s) from an external device like a pcmcia flash disk
+or an usb stick prior to resume. So you need an initrd, that sets
+up dm-crypt and then asks swsusp to resume from the encrypted
+swap device.
+
+The most important thing is that you set up dm-crypt in such
+a way that the swap device you suspend to/resume from has
+always the same major/minor within the initrd as well as
+within your running system. The easiest way to achieve this is
+to always set up this swap device first with dmsetup, so that
+it will always look like the following:
+
+brw---  1 root root 254, 0 Jul 28 13:37 /dev/mapper/swap0
+
+Now set up your kernel to use /dev/mapper/swap0 as the default
+resume partition, so your kernel .config contains:
+
+CONFIG_PM_STD_PARTITION=/dev/mapper/swap0
+
+Prepare your boot loader to use the initrd you will create or
+modify. For lilo the simplest setup looks like the following
+lines:
+
+image=/boot/vmlinuz
+initrd=/boot/initrd.gz
+label=linux
+append=root=/dev/ram0 init=/linuxrc rw
+
+Finally you need to create or modify your initrd. Lets assume
+you create an initrd that reads the required dm-crypt setup
+from a pcmcia flash disk card. The card is formatted with an ext2
+fs which resides on /dev/hde1 when the card is inserted. The
+card contains at least the encrypted swap setup in a file
+named swapkey. /etc/fstab of your initrd contains something
+like the following:
+
+/dev/hda1   /mntext3  ro0 0
+none/proc   proc  defaults,noatime,nodiratime   0 0
+none/syssysfs defaults,noatime,nodiratime   0 0
+
+/dev/hda1 contains an unencrypted mini system that sets up all
+of your crypto devices, again by reading the setup from the
+pcmcia flash disk. What follows now is a /linuxrc for your
+initrd that allows you to resume from encrypted swap and that
+continues boot with your mini system on /dev/hda1 if resume
+does not happen:
+
+#!/bin/sh
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+mount /proc
+mount /sys
+mapped=0
+noresume=`grep -c noresume /proc/cmdline`
+if [ $* !=  ]
+then
+  noresume=1
+fi
+dmesg -n 1
+/sbin/cardmgr -q
+for i in 1 2 3 4 5 6 7 8 9 0
+do
+  if [ -f /proc/ide/hde/media ]
+  then
+usleep 50
+mount -t ext2 -o ro /dev/hde1 /mnt
+if [ -f /mnt/swapkey ]
+then
+  dmsetup create swap0 /mnt/swapkey  /dev/null 21  mapped=1
+fi
+umount /mnt
+break
+  fi
+  usleep 50
+done
+killproc /sbin/cardmgr
+dmesg -n 6
+if [ $mapped = 1 ]
+then
+  if [ $noresume != 0 ]
+  then
+mkswap /dev/mapper/swap0  /dev/null 21
+  fi
+  echo 254:0  /sys/power/resume
+  dmsetup remove swap0
+fi
+umount /sys
+mount /mnt
+umount /proc
+cd /mnt
+pivot_root . mnt
+mount /proc
+umount -l /mnt
+umount /proc
+exec chroot . /sbin/init $*  dev/console  dev/console 21
+
+Please don't mind the weird loop above, busybox's msh doesn't know
+the let statement. Now, what is happening in the script?
+First we have to decide if we want to try to resume, or not.
+We will not resume if booting with noresume or any parameters
+for init like single or emergency as boot parameters.
+
+Then we need to set up dmcrypt with the setup data from the
+pcmcia flash disk. If this succeeds we need to reset the swap
+device if we don't want to resume. The line echo 254:0  /sys/power/resume
+then attempts to resume from the first device mapper device.
+Note that it is important to set

Re: [swsusp] encrypt suspend data for

[EMAIL PROTECTED] wrote:
> HI! IF I TEACH YOU HO TO DO RESUME FROM INITRD, WILL YOU TEST IT AND PROPERLY 
> DOCUMENT? :-) --P

My Pleasure!
I can test on x86_64 and I am willing to document.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [swsusp] encrypt suspend data for easy wiping

Pavel Machek wrote:
> Hi!
> 
> 
>>>>2) An attacker breaks into your machine remotely while you're using
>>>>it. He has access to all your RAM, which if you're actually using it,
>>>>very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
>>>>are saved on suspend. Further, he can trivially capture your
>>>>keystrokes and thus capture any keys you use from that point forward.
>>>>This patch gets us very close to nothing.
>>>>
>>>>3) An attacker steals your unsuspended laptop. He has access to all
>>>>your RAM, which in all likelihood includes your IPSEC, dm_crypt, and
>>>>ssh-agent keys. Odds are good that he invokes swsusp by closing the
>>>>laptop. This patch gets us very close to nothing.
>>>>
>>>>4) You suspend your laptop between typing your GPG key password and
>>>>hitting enter, thus leaving your password in memory when it would
>>>>otherwise be cleared. Then you resume your laptop and hit enter, thus
>>>>clearing the password from RAM but leaving it on the suspend
>>>>partition. Then an attacker steals your machine (without re-suspending
>>>>it!) and manages to recover the swsusp image which contains the
>>>
>>>Why without resuspending it? Position of critical data in swap is
>>>pretty much random. 
>>
>>Typical swap partition sizes are about the same as RAM sizes. So the
>>odds of any given thing in a previous suspend getting overwritten by
>>the next one are high.
> 
> 
> Well, if you suspend with 100MB of RAM used, then keep suspending half
> a year with only 50MB of RAM used, you'll have that half-year-old data
> in there.
> 
> 
>>>What I'm worried is: attacker steals your laptop after you were using
>>>swsusp for half a year. Now your swap partition contains random pieces
>>>of GPG keys you were using for last half a year. That's bad.
>>
>>And it's incredibly unlikely. Suspending while a supposedly
>>short-lived key is in RAM should be rare. Surviving on disk after half
>>a year of swapping and suspending should be negligible probability.
> 
> 
> Disagreed.
> 
> 
>>It's not worth even thinking about when we have real suspended laptops
>>getting stolen every day in REAL LIFE. Anyone who cares about your
>>highly contrived case also cares about 1000 times more about the real
>>life case of the stolen laptop. Otherwise they're fooling themselves.
>>
>>This code is bad. It attacks a very rare problem, gives its users (and
>>apparently its authors) a false sense of security, reimplements
>>dm_crypt functionality apparently without much attention to the
>>subtleties of block device encryption and without serious review, and
>>it stands in the way of doing things right.
> 
> 
> Think about current code as really quick disk wiping method. Now, if
> you feel that we are giving false sense of security... we should
> not. Perhaps option should be renamed to CONFIG_SWSUSP_WIPE. Patches
> would certainly be accepted and I believe Andreas is going to cook
> some when he gets back online :-). I'd like to keep it there, because
> it enables us to do it properly in future. Contrary to what you think,
> I believe this is going to be part of a solution.

Matt,
this is really supposed to do wiping, nothing else. Maybe the reference
to crypto may confuse a bit, but then crypto is the best way to wipe.
The documentation I did send to Pavel some time ago for swsusp.txt does
contain a big fat warning about that and starts with:

--
Q: What is this 'Encrypt suspend image' for?

A: First of all: it is not a replacement for dm-crypt encrypted swap.
It cannot protect your computer while it is suspended. Instead it does
protect from leaking sensitive data after resume from suspend.
--

I'm still dreaming of using dm-crypt for encrypted swap on the one hand
and wiping on resume from suspend on the other working together which
would mean:

You have an initrd that either prompts for a key or retrieves a key from
an attached hardware device (pcmcia, usb, ...). The key is used for
dmsetup to enable the encrypted swap partition. swsusp then resumes from
the encrypted swap partition and wipes the suspend image.

Unfortunately, as of 2.6.13rc3 I don't see any chance for this to work
(excerpt from init/main.c):

do_basic_setup();

if (sys_access((const char __user *) "/init", 0) == 0)
execute_command = "/init";
else
prepare_namespace();

do_basic_setup calls do_initcalls and swsusp is using late_initcall().
prepare_namespace calls initrd_load and friends. So there is currently
no chance to use an initrd to setup any crypto key.

This is really the missing link here.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [swsusp] encrypt suspend data for easy wiping

Pavel Machek wrote:
 Hi!
 
 
2) An attacker breaks into your machine remotely while you're using
it. He has access to all your RAM, which if you're actually using it,
very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
are saved on suspend. Further, he can trivially capture your
keystrokes and thus capture any keys you use from that point forward.
This patch gets us very close to nothing.

3) An attacker steals your unsuspended laptop. He has access to all
your RAM, which in all likelihood includes your IPSEC, dm_crypt, and
ssh-agent keys. Odds are good that he invokes swsusp by closing the
laptop. This patch gets us very close to nothing.

4) You suspend your laptop between typing your GPG key password and
hitting enter, thus leaving your password in memory when it would
otherwise be cleared. Then you resume your laptop and hit enter, thus
clearing the password from RAM but leaving it on the suspend
partition. Then an attacker steals your machine (without re-suspending
it!) and manages to recover the swsusp image which contains the

Why without resuspending it? Position of critical data in swap is
pretty much random. 

Typical swap partition sizes are about the same as RAM sizes. So the
odds of any given thing in a previous suspend getting overwritten by
the next one are high.
 
 
 Well, if you suspend with 100MB of RAM used, then keep suspending half
 a year with only 50MB of RAM used, you'll have that half-year-old data
 in there.
 
 
What I'm worried is: attacker steals your laptop after you were using
swsusp for half a year. Now your swap partition contains random pieces
of GPG keys you were using for last half a year. That's bad.

And it's incredibly unlikely. Suspending while a supposedly
short-lived key is in RAM should be rare. Surviving on disk after half
a year of swapping and suspending should be negligible probability.
 
 
 Disagreed.
 
 
It's not worth even thinking about when we have real suspended laptops
getting stolen every day in REAL LIFE. Anyone who cares about your
highly contrived case also cares about 1000 times more about the real
life case of the stolen laptop. Otherwise they're fooling themselves.

This code is bad. It attacks a very rare problem, gives its users (and
apparently its authors) a false sense of security, reimplements
dm_crypt functionality apparently without much attention to the
subtleties of block device encryption and without serious review, and
it stands in the way of doing things right.
 
 
 Think about current code as really quick disk wiping method. Now, if
 you feel that we are giving false sense of security... we should
 not. Perhaps option should be renamed to CONFIG_SWSUSP_WIPE. Patches
 would certainly be accepted and I believe Andreas is going to cook
 some when he gets back online :-). I'd like to keep it there, because
 it enables us to do it properly in future. Contrary to what you think,
 I believe this is going to be part of a solution.

Matt,
this is really supposed to do wiping, nothing else. Maybe the reference
to crypto may confuse a bit, but then crypto is the best way to wipe.
The documentation I did send to Pavel some time ago for swsusp.txt does
contain a big fat warning about that and starts with:

--
Q: What is this 'Encrypt suspend image' for?

A: First of all: it is not a replacement for dm-crypt encrypted swap.
It cannot protect your computer while it is suspended. Instead it does
protect from leaking sensitive data after resume from suspend.
--

I'm still dreaming of using dm-crypt for encrypted swap on the one hand
and wiping on resume from suspend on the other working together which
would mean:

You have an initrd that either prompts for a key or retrieves a key from
an attached hardware device (pcmcia, usb, ...). The key is used for
dmsetup to enable the encrypted swap partition. swsusp then resumes from
the encrypted swap partition and wipes the suspend image.

Unfortunately, as of 2.6.13rc3 I don't see any chance for this to work
(excerpt from init/main.c):

do_basic_setup();

if (sys_access((const char __user *) /init, 0) == 0)
execute_command = /init;
else
prepare_namespace();

do_basic_setup calls do_initcalls and swsusp is using late_initcall().
prepare_namespace calls initrd_load and friends. So there is currently
no chance to use an initrd to setup any crypto key.

This is really the missing link here.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [swsusp] encrypt suspend data for

[EMAIL PROTECTED] wrote:
 HI! IF I TEACH YOU HO TO DO RESUME FROM INITRD, WILL YOU TEST IT AND PROPERLY 
 DOCUMENT? :-) --P

My Pleasure!
I can test on x86_64 and I am willing to document.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken

Lee Revell wrote:
> On Sat, 2005-07-23 at 13:42 +0200, Andreas Steinmetz wrote:
> 
>>RLIMIT_RTPRIO is supposed to grant non privileged users the right to use
>>SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the
>>RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by
>>audio users.
>>
>>Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt
>>from sched_setscheduler below:
> 
> 
> Please provide the Signed-Off-By line.  Also I have cc'ed Matt Mackall,
> the original author of the patch.

Sorry, I do forget this all the time...

Signed-off-by: Andreas Steinmetz <[EMAIL PROTECTED]>
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken

RLIMIT_RTPRIO is supposed to grant non privileged users the right to use
SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the
RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by
audio users.

Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt
from sched_setscheduler below:

/*
 * Allow unprivileged RT tasks to decrease priority:
 */
if (!capable(CAP_SYS_NICE)) {
/* can't change policy */
if (policy != p->policy)
return -EPERM;

After the above unconditional test which causes sched_setscheduler to
fail with no regard to the RLIMIT_RTPRIO value the following check is made:

   /* can't increase priority */
if (policy != SCHED_NORMAL &&
param->sched_priority > p->rt_priority &&
param->sched_priority >
p->signal->rlim[RLIMIT_RTPRIO].rlim_cur)
return -EPERM;

Thus I do believe that the RLIMIT_RTPRIO value must be taken into
account for the policy check, especially as the RLIMIT_RTPRIO limit is
of no use without this change.

The attached patch fixes this problem. I would appreciate it if the fix
would make it into 2.6.13.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
--- linux.orig/kernel/sched.c   2005-07-22 19:45:05.0 +0200
+++ linux/kernel/sched.c2005-07-22 19:45:42.0 +0200
@@ -3528,7 +3528,8 @@
 */
if (!capable(CAP_SYS_NICE)) {
/* can't change policy */
-   if (policy != p->policy)
+   if (policy != p->policy &&
+   !p->signal->rlim[RLIMIT_RTPRIO].rlim_cur)
return -EPERM;
/* can't increase priority */
if (policy != SCHED_NORMAL &&

[PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken

RLIMIT_RTPRIO is supposed to grant non privileged users the right to use
SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the
RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by
audio users.

Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt
from sched_setscheduler below:

/*
 * Allow unprivileged RT tasks to decrease priority:
 */
if (!capable(CAP_SYS_NICE)) {
/* can't change policy */
if (policy != p-policy)
return -EPERM;

After the above unconditional test which causes sched_setscheduler to
fail with no regard to the RLIMIT_RTPRIO value the following check is made:

   /* can't increase priority */
if (policy != SCHED_NORMAL 
param-sched_priority  p-rt_priority 
param-sched_priority 
p-signal-rlim[RLIMIT_RTPRIO].rlim_cur)
return -EPERM;

Thus I do believe that the RLIMIT_RTPRIO value must be taken into
account for the policy check, especially as the RLIMIT_RTPRIO limit is
of no use without this change.

The attached patch fixes this problem. I would appreciate it if the fix
would make it into 2.6.13.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
--- linux.orig/kernel/sched.c   2005-07-22 19:45:05.0 +0200
+++ linux/kernel/sched.c2005-07-22 19:45:42.0 +0200
@@ -3528,7 +3528,8 @@
 */
if (!capable(CAP_SYS_NICE)) {
/* can't change policy */
-   if (policy != p-policy)
+   if (policy != p-policy 
+   !p-signal-rlim[RLIMIT_RTPRIO].rlim_cur)
return -EPERM;
/* can't increase priority */
if (policy != SCHED_NORMAL

Re: [PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken

Lee Revell wrote:
 On Sat, 2005-07-23 at 13:42 +0200, Andreas Steinmetz wrote:
 
RLIMIT_RTPRIO is supposed to grant non privileged users the right to use
SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the
RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by
audio users.

Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt
from sched_setscheduler below:
 
 
 Please provide the Signed-Off-By line.  Also I have cc'ed Matt Mackall,
 the original author of the patch.

Sorry, I do forget this all the time...

Signed-off-by: Andreas Steinmetz [EMAIL PROTECTED]
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: amd64-agp vs. swsusp

2005-07-19 Thread Andreas Steinmetz

Michal Schmidt wrote:
> Hello,
> 
> Does resuming from swsuspend work for anyone with amd64-agp loaded?
> 
> On my system when I suspend with amd64-agp loaded, I get a spontaneous
> reboot on resume. It reboots immediately after reading the saved image
> from disk.
> This is 100% reproducible.
> 
> Athlon 64 FX-53, Asus A8V Deluxe, Linux 2.6.13-rc3-mm1.

AMD Athlon(tm) 64 Processor 3000+, Acer Aspire

Linux gringo 2.6.13-rc3-gringo #36 Sun Jul 17 15:57:17 CEST 2005 x86_64
unknown unknown GNU/Linux

CONFIG_AGP=y
CONFIG_AGP_AMD64=y

swsusp works for me. Could it be mm, agp as a module or some speciality
of your hardware?
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: amd64-agp vs. swsusp

2005-07-19 Thread Andreas Steinmetz

Michal Schmidt wrote:
 Hello,
 
 Does resuming from swsuspend work for anyone with amd64-agp loaded?
 
 On my system when I suspend with amd64-agp loaded, I get a spontaneous
 reboot on resume. It reboots immediately after reading the saved image
 from disk.
 This is 100% reproducible.
 
 Athlon 64 FX-53, Asus A8V Deluxe, Linux 2.6.13-rc3-mm1.

AMD Athlon(tm) 64 Processor 3000+, Acer Aspire

Linux gringo 2.6.13-rc3-gringo #36 Sun Jul 17 15:57:17 CEST 2005 x86_64
unknown unknown GNU/Linux

CONFIG_AGP=y
CONFIG_AGP_AMD64=y

swsusp works for me. Could it be mm, agp as a module or some speciality
of your hardware?
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [swsusp] encrypt suspend data for easy wiping

Andrew Morton wrote:
> Pavel Machek <[EMAIL PROTECTED]> wrote:
> 
>>To prevent data gathering from swap after resume you can encrypt the
>>suspend image with a temporary key that is deleted on resume. Note
>>that the temporary key is stored unencrypted on disk while the system
>>is suspended... still it means that saved data are wiped from disk
>>during resume by simply overwritting the key.
> 
[snip]
> err, no.  Please find a way to reduce the ifdeffery.

Andrew,
the attached patches are acked by Pavel and signed off by me. They apply
against 2.6.13-rc3 as well as 2.6.13-rc3-mm1 (with offsets) and are
tested against both kernels. Please consider for inclusion (Pavel
suggested that I could ask).

Note:
For 64 bit systems to work you need the following crypto fix for both
kernels stated above:
http://marc.theaimsgroup.com/?l=linux-kernel=112160294820624=2
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.13-rc3.orig/kernel/power/Kconfig  2005-07-17 16:03:26.0 
+0200
+++ linux-2.6.13-rc3/kernel/power/Kconfig   2005-07-17 10:40:48.0 
+0200
@@ -72,6 +72,18 @@
  suspended image to. It will simply pick the first available swap 
  device.
 
+config SWSUSP_ENCRYPT
+   bool "Encrypt suspend image"
+   depends on SOFTWARE_SUSPEND && CRYPTO=y && (CRYPTO_AES=y || 
CRYPTO_AES_586=y || CRYPTO_AES_X86_64=y)
+   default ""
+   ---help---
+ To prevent data gathering from swap after resume you can encrypt
+ the suspend image with a temporary key that is deleted on
+ resume.
+
+ Note that the temporary key is stored unencrypted on disk while the
+ system is suspended.
+
 config SUSPEND_SMP
bool
depends on HOTPLUG_CPU && X86 && PM
--- linux-2.6.13-rc3.orig/kernel/power/swsusp.c 2005-07-17 16:03:26.0 
+0200
+++ linux-2.6.13-rc3/kernel/power/swsusp.c  2005-07-17 16:09:09.00000 
+0200
@@ -31,6 +31,9 @@
  * Alex Badea <[EMAIL PROTECTED]>:
  * Fixed runaway init
  *
+ * Andreas Steinmetz <[EMAIL PROTECTED]>:
+ * Added encrypted suspend option
+ *
  * More state savers are welcome. Especially for the scsi layer...
  *
  * For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -71,8 +74,16 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+
 #include "power.h"
 
+#define CIPHER "aes"
+#define MAXKEY 32
+#define MAXIV  32
+
 /* References to section boundaries */
 extern const void __nosave_begin, __nosave_end;
 
@@ -103,7 +114,8 @@
 #define SWSUSP_SIG "S1SUSPEND"
 
 static struct swsusp_header {
-   char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
+   char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+   u8 key_iv[MAXKEY+MAXIV];
swp_entry_t swsusp_info;
charorig_sig[10];
charsig[10];
@@ -129,6 +141,131 @@
 static unsigned short swapfile_used[MAX_SWAPFILES];
 static unsigned short root_swap;
 
+static int write_page(unsigned long addr, swp_entry_t * loc);
+static int bio_read_page(pgoff_t page_off, void * page);
+
+static u8 key_iv[MAXKEY+MAXIV];
+
+#ifdef CONFIG_SWSUSP_ENCRYPT
+
+static int crypto_init(int mode, void **mem)
+{
+   int error = 0;
+   int len;
+   char *modemsg;
+   struct crypto_tfm *tfm;
+
+   modemsg = mode ? "suspend not possible" : "resume not possible";
+
+   tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+   if(!tfm) {
+   printk(KERN_ERR "swsusp: no tfm, %s\n", modemsg);
+   error = -EINVAL;
+   goto out;
+   }
+
+   if(MAXKEY < crypto_tfm_alg_min_keysize(tfm)) {
+   printk(KERN_ERR "swsusp: key buffer too small, %s\n", modemsg);
+   error = -ENOKEY;
+   goto fail;
+   }
+
+   if (mode)
+   get_random_bytes(key_iv, MAXKEY+MAXIV);
+
+   len = crypto_tfm_alg_max_keysize(tfm);
+   if (len > MAXKEY)
+   len = MAXKEY;
+
+   if (crypto_cipher_setkey(tfm, key_iv, len)) {
+   printk(KERN_ERR "swsusp: key setup failure, %s\n", modemsg);
+   error = -EKEYREJECTED;
+   goto fail;
+   }
+
+   len = crypto_tfm_alg_ivsize(tfm);
+
+   if (MAXIV < len) {
+   printk(KERN_ERR "swsusp: iv buffer too small, %s\n", modemsg);
+   error = -EOVERFLOW;
+   goto fail;
+   }
+
+   crypto_cipher_set_iv(tfm, key_iv+MAXKEY, len);
+
+   *mem=(void *)tfm;
+
+   goto out;
+
+fail:  crypto_free_tfm(tfm);
+out:   return error;
+}
+
+static __inline__ void crypto_exit(void *mem)
+{
+   crypto_free_tfm((struct crypto_tfm *)mem);
+}
+
+static __inline__ int crypto_write(struct pbe *p, void *mem)
+{
+   int error = 0;
+

2.6.13rc3: crypto horribly broken on all 64bit archs

from include/linux/kernel.h:

#define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))

from crypto/cipher.c:

unsigned int alignmask = ...
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int alignmask = ...
u8 *tmp = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int align;
addr = ALIGN(addr, align);
addr += ALIGN(tfm->__crt_alg->cra_ctxsize, align);

The compiler first does ~((a)-1)) and then expands the unsigned int to
unsigned long for the & operation. So we end up with only the lower 32
bits of the address. Who did smoke what to do this? Patch attached.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]

--- linux.orig/crypto/cipher.c  2005-07-17 13:35:15.0 +0200
+++ linux/crypto/cipher.c   2005-07-17 14:04:00.0 +0200
@@ -41,7 +41,7 @@
   struct scatter_walk *in,
   struct scatter_walk *out, unsigned int bsize)
 {
-   unsigned int alignmask = crypto_tfm_alg_alignmask(desc->tfm);
+   unsigned long alignmask = crypto_tfm_alg_alignmask(desc->tfm);
u8 buffer[bsize * 2 + alignmask];
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
u8 *dst = src + bsize;
@@ -160,7 +160,7 @@
  unsigned int nbytes)
 {
struct crypto_tfm *tfm = desc->tfm;
-   unsigned int alignmask = crypto_tfm_alg_alignmask(tfm);
+   unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
u8 *iv = desc->info;
 
if (unlikely(((unsigned long)iv & alignmask))) {
@@ -424,7 +424,7 @@
}

if (ops->cit_mode == CRYPTO_TFM_MODE_CBC) {
-   unsigned int align;
+   unsigned long align;
unsigned long addr;

switch (crypto_tfm_alg_blocksize(tfm)) {

2.6.13rc3: crypto horribly broken on all 64bit archs

from include/linux/kernel.h:

#define ALIGN(x,a) (((x)+(a)-1)~((a)-1))

from crypto/cipher.c:

unsigned int alignmask = ...
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int alignmask = ...
u8 *tmp = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int align;
addr = ALIGN(addr, align);
addr += ALIGN(tfm-__crt_alg-cra_ctxsize, align);

The compiler first does ~((a)-1)) and then expands the unsigned int to
unsigned long for the  operation. So we end up with only the lower 32
bits of the address. Who did smoke what to do this? Patch attached.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]

--- linux.orig/crypto/cipher.c  2005-07-17 13:35:15.0 +0200
+++ linux/crypto/cipher.c   2005-07-17 14:04:00.0 +0200
@@ -41,7 +41,7 @@
   struct scatter_walk *in,
   struct scatter_walk *out, unsigned int bsize)
 {
-   unsigned int alignmask = crypto_tfm_alg_alignmask(desc-tfm);
+   unsigned long alignmask = crypto_tfm_alg_alignmask(desc-tfm);
u8 buffer[bsize * 2 + alignmask];
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
u8 *dst = src + bsize;
@@ -160,7 +160,7 @@
  unsigned int nbytes)
 {
struct crypto_tfm *tfm = desc-tfm;
-   unsigned int alignmask = crypto_tfm_alg_alignmask(tfm);
+   unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
u8 *iv = desc-info;
 
if (unlikely(((unsigned long)iv  alignmask))) {
@@ -424,7 +424,7 @@
}

if (ops-cit_mode == CRYPTO_TFM_MODE_CBC) {
-   unsigned int align;
+   unsigned long align;
unsigned long addr;

switch (crypto_tfm_alg_blocksize(tfm)) {

Re: [swsusp] encrypt suspend data for easy wiping

Andrew Morton wrote:
 Pavel Machek [EMAIL PROTECTED] wrote:
 
To prevent data gathering from swap after resume you can encrypt the
suspend image with a temporary key that is deleted on resume. Note
that the temporary key is stored unencrypted on disk while the system
is suspended... still it means that saved data are wiped from disk
during resume by simply overwritting the key.
 
[snip]
 err, no.  Please find a way to reduce the ifdeffery.

Andrew,
the attached patches are acked by Pavel and signed off by me. They apply
against 2.6.13-rc3 as well as 2.6.13-rc3-mm1 (with offsets) and are
tested against both kernels. Please consider for inclusion (Pavel
suggested that I could ask).

Note:
For 64 bit systems to work you need the following crypto fix for both
kernels stated above:
http://marc.theaimsgroup.com/?l=linux-kernelm=112160294820624w=2
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.13-rc3.orig/kernel/power/Kconfig  2005-07-17 16:03:26.0 
+0200
+++ linux-2.6.13-rc3/kernel/power/Kconfig   2005-07-17 10:40:48.0 
+0200
@@ -72,6 +72,18 @@
  suspended image to. It will simply pick the first available swap 
  device.
 
+config SWSUSP_ENCRYPT
+   bool Encrypt suspend image
+   depends on SOFTWARE_SUSPEND  CRYPTO=y  (CRYPTO_AES=y || 
CRYPTO_AES_586=y || CRYPTO_AES_X86_64=y)
+   default 
+   ---help---
+ To prevent data gathering from swap after resume you can encrypt
+ the suspend image with a temporary key that is deleted on
+ resume.
+
+ Note that the temporary key is stored unencrypted on disk while the
+ system is suspended.
+
 config SUSPEND_SMP
bool
depends on HOTPLUG_CPU  X86  PM
--- linux-2.6.13-rc3.orig/kernel/power/swsusp.c 2005-07-17 16:03:26.0 
+0200
+++ linux-2.6.13-rc3/kernel/power/swsusp.c  2005-07-17 16:09:09.0 
+0200
@@ -31,6 +31,9 @@
  * Alex Badea [EMAIL PROTECTED]:
  * Fixed runaway init
  *
+ * Andreas Steinmetz [EMAIL PROTECTED]:
+ * Added encrypted suspend option
+ *
  * More state savers are welcome. Especially for the scsi layer...
  *
  * For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -71,8 +74,16 @@
 #include asm/tlbflush.h
 #include asm/io.h
 
+#include linux/random.h
+#include linux/crypto.h
+#include asm/scatterlist.h
+
 #include power.h
 
+#define CIPHER aes
+#define MAXKEY 32
+#define MAXIV  32
+
 /* References to section boundaries */
 extern const void __nosave_begin, __nosave_end;
 
@@ -103,7 +114,8 @@
 #define SWSUSP_SIG S1SUSPEND
 
 static struct swsusp_header {
-   char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
+   char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+   u8 key_iv[MAXKEY+MAXIV];
swp_entry_t swsusp_info;
charorig_sig[10];
charsig[10];
@@ -129,6 +141,131 @@
 static unsigned short swapfile_used[MAX_SWAPFILES];
 static unsigned short root_swap;
 
+static int write_page(unsigned long addr, swp_entry_t * loc);
+static int bio_read_page(pgoff_t page_off, void * page);
+
+static u8 key_iv[MAXKEY+MAXIV];
+
+#ifdef CONFIG_SWSUSP_ENCRYPT
+
+static int crypto_init(int mode, void **mem)
+{
+   int error = 0;
+   int len;
+   char *modemsg;
+   struct crypto_tfm *tfm;
+
+   modemsg = mode ? suspend not possible : resume not possible;
+
+   tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+   if(!tfm) {
+   printk(KERN_ERR swsusp: no tfm, %s\n, modemsg);
+   error = -EINVAL;
+   goto out;
+   }
+
+   if(MAXKEY  crypto_tfm_alg_min_keysize(tfm)) {
+   printk(KERN_ERR swsusp: key buffer too small, %s\n, modemsg);
+   error = -ENOKEY;
+   goto fail;
+   }
+
+   if (mode)
+   get_random_bytes(key_iv, MAXKEY+MAXIV);
+
+   len = crypto_tfm_alg_max_keysize(tfm);
+   if (len  MAXKEY)
+   len = MAXKEY;
+
+   if (crypto_cipher_setkey(tfm, key_iv, len)) {
+   printk(KERN_ERR swsusp: key setup failure, %s\n, modemsg);
+   error = -EKEYREJECTED;
+   goto fail;
+   }
+
+   len = crypto_tfm_alg_ivsize(tfm);
+
+   if (MAXIV  len) {
+   printk(KERN_ERR swsusp: iv buffer too small, %s\n, modemsg);
+   error = -EOVERFLOW;
+   goto fail;
+   }
+
+   crypto_cipher_set_iv(tfm, key_iv+MAXKEY, len);
+
+   *mem=(void *)tfm;
+
+   goto out;
+
+fail:  crypto_free_tfm(tfm);
+out:   return error;
+}
+
+static __inline__ void crypto_exit(void *mem)
+{
+   crypto_free_tfm((struct crypto_tfm *)mem);
+}
+
+static __inline__ int crypto_write(struct pbe *p, void *mem)
+{
+   int error = 0;
+   struct scatterlist src, dst;
+
+   src.page   = virt_to_page(p-address);
+   src.offset = 0;
+   src.length = PAGE_SIZE;
+   dst.page   = virt_to_page((void *)swsusp_header

Re: [PATCH 1/3] crypto: do not open-code be<->cpu

2005-04-22 Thread Andreas Steinmetz

Denis Vlasenko wrote:
> Patch replaces numerous be<->cpu and le<->cpu
> conversions in crypto. Per lkml comments,
> it is done with macros:
> 
> block[i] = load_be64(ptr,i);
> store_be64(out,i, block[i]);
> 
> where i is an index: load_be64 will load i'th
> big-endian value pointed by ptr (typically a char*).
> Same for store.
> 
> This results in smaller and cleaner code.
> 
> Patch also adds BYTEn(x) macros for extracting n'th byte from
> u32 and u64 memory operand. Currently used experssions like
> ((K >> 40) & 0xff) are not optimal (gcc will load entire word
> and then shift and/or mask it).
> 
> Macros can be conditionally defined for different arches
> for performance. Ones from this patch are found to be best
> for i386.
> 
> BYTEn macros are used only by next patches.

Not good if you use a crypto private header as long as there's arch and
device specific crypto which is left out cold this way.

I'd suggest either some header in include/linux or, in my opinion
better, open a crypto related include directory as include/crypto. The
latter would make sense as there probably will be algorithm specific
headers when the arch and driver specific versions will be harmonized,
thus these headers need to be globally available to crypto sources but
otherwise would pollute the common include directory.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] crypto: do not open-code be-cpu

2005-04-22 Thread Andreas Steinmetz

Denis Vlasenko wrote:
 Patch replaces numerous be-cpu and le-cpu
 conversions in crypto. Per lkml comments,
 it is done with macros:
 
 block[i] = load_be64(ptr,i);
 store_be64(out,i, block[i]);
 
 where i is an index: load_be64 will load i'th
 big-endian value pointed by ptr (typically a char*).
 Same for store.
 
 This results in smaller and cleaner code.
 
 Patch also adds BYTEn(x) macros for extracting n'th byte from
 u32 and u64 memory operand. Currently used experssions like
 ((K  40)  0xff) are not optimal (gcc will load entire word
 and then shift and/or mask it).
 
 Macros can be conditionally defined for different arches
 for performance. Ones from this patch are found to be best
 for i386.
 
 BYTEn macros are used only by next patches.

Not good if you use a crypto private header as long as there's arch and
device specific crypto which is left out cold this way.

I'd suggest either some header in include/linux or, in my opinion
better, open a crypto related include directory as include/crypto. The
latter would make sense as there probably will be algorithm specific
headers when the arch and driver specific versions will be harmonized,
thus these headers need to be globally available to crypto sources but
otherwise would pollute the common include directory.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3: various swsusp problems

Pavel Machek wrote:
> Hi!
> Are they new or were they in -rc2, too?

Some further backtracking:

The nic problem is already present in 2.6.12-rc1.
The pcmcia hang problem is not present in 2.6.12-rc1.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3: various swsusp problems

Pavel Machek wrote:
> Hi!
> 
> 
>>there's some problems with swsusp in 2.6.12-rc3 (x86_64):
> 
> 
> Are they new or were they in -rc2, too?
> 

Fixed the rc2/rc3 IDE Oops myself today that prevented me to test rc2
earlier. It seems the IDE maintainer is currently not very responsive
and I didn't have sufficient spare time to look into this before today :-(

Yes, all problems are already in rc2.

> 
>>1. Is it necessary to print the following message during regular boot?
>>   swsusp: Suspend partition has wrong signature?
>>   It is a bit annoying and I believe it will confuse some swsusp
>>   users.
> 
> 
> Hmm, feel free to provide a patch. (I need something to try git on :-).

I'll have a look over the weekend.

> 
> 
>>2. PCMCIA related hangs during swsusp.
>>   swsusp hangs after freeing memory when either cardmgr is running
>>   or pcmcia cards are *physically* inserted. It is insufficient
>>   to do a 'cardctl eject' the cards must be removed, too, for
>>   swsusp not to hang. I do suspect some problem with the
>>   'pccardd' kernel threads.
> 
> 
> Did it work with any older kernel? Which driver is it? yenta?

2.6.11.2 works ok and, yes, its yenta. Some excerpt from lspci:

00:0b.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
00:0b.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller

> 
> 
>>3. Sometimes during the search for the suspend hang reason the system
>>   went during suspend into a lightshow of:
>>   eth0: Too much work at interrupt!
>>   and some line that ends in:
>>   release_console_sem+0x13d/0x1c0)
>>   The start of the line is not readable as it just flickers by in
>>   the eth0 message limbo. NIC is a built in RTL-8169 Gigabit Ethernet
>>   (rev 10). Oh, no chance for a serial console capture as there's no
>>   built in serial device in this laptop.
> 
> 
> How repeatable is that? Will NIC work okay if you rmmod/insmod its driver?
>   Pavel

Happens with a probability of about 10% to 20%. I did comment out the
'Too much work...' printk in r8169.c which results in the following
effect: no more message from the network driver (expected), no other
printk related to release_console_sem or anything else unusal, but write
to disk in the case the problem seems to happen is suddenly quite slow
and suspend eventually succeeds.
As the nic driver is built into the kernel insmod/rmmod currently won't
do:-) Nevertheless there doesn't seem to be any strange behaviour after
resume though I didn't really try to use the nic then.
There is, however, definitely no such problem with the nic in 2.6.11.2.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3: various swsusp problems

Hi Pavel,
there's some problems with swsusp in 2.6.12-rc3 (x86_64):

1. Is it necessary to print the following message during regular boot?
   swsusp: Suspend partition has wrong signature?
   It is a bit annoying and I believe it will confuse some swsusp
   users.

2. PCMCIA related hangs during swsusp.
   swsusp hangs after freeing memory when either cardmgr is running
   or pcmcia cards are *physically* inserted. It is insufficient
   to do a 'cardctl eject' the cards must be removed, too, for
   swsusp not to hang. I do suspect some problem with the
   'pccardd' kernel threads.

3. Sometimes during the search for the suspend hang reason the system
   went during suspend into a lightshow of:
   eth0: Too much work at interrupt!
   and some line that ends in:
   release_console_sem+0x13d/0x1c0)
   The start of the line is not readable as it just flickers by in
   the eth0 message limbo. NIC is a built in RTL-8169 Gigabit Ethernet
   (rev 10). Oh, no chance for a serial console capture as there's no
   built in serial device in this laptop.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3: Oops on IDE flash disk eject

The following patch fixes the Oops though I don't know if this is the
correct solution.

--- linux-2.6.12-rc3/drivers/ide/ide.c.ast
+++ linux-2.6.12-rc3/drivers/ide/ide.c
@@ -2082,7 +2082,8 @@
 static int ide_drive_remove(struct device * dev)
 {
ide_drive_t * drive = container_of(dev,ide_drive_t,gendev);
-   DRIVER(drive)->cleanup(drive);
+   if(DRIVER(drive))
+   DRIVER(drive)->cleanup(drive);
return 0;
 }


-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3: Oops on IDE flash disk eject

As already reported to lkml and IDE maintainer for 2.6.12-rc2:

Oops on 'cardctl eject' of an IDE flash disk (Pretec ATA Flash 16MB).
2.6.11.2 works fine.

System:
Linux (none) 2.6.12-rc3-gringo #1 Thu Apr 21 15:45:08 CEST 2005 x86_64
unknown unknown GNU/Linux

Kernel messages from startup to and including Oops as well as config are
attached.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
Bootdata ok (command line is BOOT_IMAGE=2.6.12rc2 ro root=301 hdb=none 
hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off 
init=/bin/bash)
Linux version 2.6.12-rc3-gringo ([EMAIL PROTECTED]) (gcc version 3.4.3) #1 Thu 
Apr 21 15:45:08 CEST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f800 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000d8000 - 0010 (reserved)
 BIOS-e820: 0010 - 3ff7 (usable)
 BIOS-e820: 3ff7 - 3ff7a000 (ACPI data)
 BIOS-e820: 3ff7a000 - 3ff8 (ACPI NVS)
 BIOS-e820: 3ff8 - 4000 (reserved)
 BIOS-e820: fffe - 0001 (reserved)
ACPI: RSDP (v000 PTLTD ) @ 0x000f6a60
ACPI: RSDT (v001 PTLTDRSDT   0x0604  LTP 0x) @ 
0x3ff73fde
ACPI: FADT (v002 AMDK8  PTLTW0x0604 PTL_ 0x000f4240) @ 
0x3ff79e56
ACPI: SSDT (v001 PTLTD  POWERNOW 0x0604  LTP 0x0001) @ 
0x3ff79eda
ACPI: MADT (v001 PTLTD   APIC   0x0604  LTP 0x) @ 
0x3ff79fb0
ACPI: DSDT (v001  VIA   PTL_ACPI 0x0604 MSFT 0x010e) @ 
0x
On node 0 totalpages: 262000
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 257904 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 4000 (gap: 4000:bffe)
Built 1 zonelists
Kernel command line: BOOT_IMAGE=2.6.12rc2 ro root=301 hdb=none hdc=cdrom 
hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off 
init=/bin/bash console=tty0
ide_setup: hdb=none
ide_setup: hdc=cdrom
ide_setup: hdd=none
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 1801.076 MHz processor.
time.c: Using PIT/TSC based timekeeping.
Console: colour VGA+ 80x50
time.c: Lost 3 timer tick(s)! rip vfs_caches_init_early+0x0/0xa0)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1024468k/1048000k available (2958k kernel code, 22832k reserved, 1639k 
data, 164k init)
Calibrating delay loop... 3547.13 BogoMIPS (lpj=1773568)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 0a
time.c: Lost 86 timer tick(s)! rip acpi_os_write_port+0x1a/0x36)
Using local APIC NMI watchdog using perfctr0
Using local APIC timer interrupts.
Detected 12.507 MHz APIC timer.
time.c: Lost 55 timer tick(s)! rip setup_boot_APIC_clock+0x112/0x120)
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050309
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
PCI: Via IRQ fixup
Boot video device is :01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled.
ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled.
ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled.
ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled.
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *10 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: Embedded Controller [EC] (gpe 11)
time.c: Lost 8 timer tick(s)! rip acpi_os_write_port+0x1a/0x36)
time.c: Lost 8 timer tick(s)! rip acpi_os_write_port+0x1a/0x36)
Linux Plug and Play Support v0.97 (c) Adam Belay

Re: Linux 2.6.12-rc3

Compile error on x86_64:

  CC [M]  drivers/usb/image/microtek.o
drivers/usb/image/microtek.c: In function `mts_scsi_abort':
drivers/usb/image/microtek.c:338: error: `FAILURE' undeclared (first use
in this function)
drivers/usb/image/microtek.c:338: error: (Each undeclared identifier is
reported only once
drivers/usb/image/microtek.c:338: error: for each function it appears in.)
make[3]: *** [drivers/usb/image/microtek.o] Error 1
make[2]: *** [drivers/usb/image] Error 2
make[1]: *** [drivers/usb] Error 2
make: *** [drivers] Error 2

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Need AES benchmark on Intel 64 bit

Hi,
can anybody help out? I don't have access to Intel 64 bit CPUs and need
some microbenchmark results on Intel 64 bit. Usage guide for the
attached archive:

'ref' contains the current generic AES implementation
'new' contains the 64 bit AES assembler implementation

Do 'make' in both directories and run the resulting 'aes' on an
otherwise idle system without any cpufreq (speedstep) stuff active.
Preferrably do multiple runs to assert that the results are usable (a
few ticks difference between runs are ok).

The microbenchmark is set up to produce somewhat real life results with
hot caches, thus the same data block is processed all the time.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]


microbench.tgz
Description: application/tar-gz

Need AES benchmark on Intel 64 bit

Hi,
can anybody help out? I don't have access to Intel 64 bit CPUs and need
some microbenchmark results on Intel 64 bit. Usage guide for the
attached archive:

'ref' contains the current generic AES implementation
'new' contains the 64 bit AES assembler implementation

Do 'make' in both directories and run the resulting 'aes' on an
otherwise idle system without any cpufreq (speedstep) stuff active.
Preferrably do multiple runs to assert that the results are usable (a
few ticks difference between runs are ok).

The microbenchmark is set up to produce somewhat real life results with
hot caches, thus the same data block is processed all the time.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]


microbench.tgz
Description: application/tar-gz

Re: Linux 2.6.12-rc3

Compile error on x86_64:

  CC [M]  drivers/usb/image/microtek.o
drivers/usb/image/microtek.c: In function `mts_scsi_abort':
drivers/usb/image/microtek.c:338: error: `FAILURE' undeclared (first use
in this function)
drivers/usb/image/microtek.c:338: error: (Each undeclared identifier is
reported only once
drivers/usb/image/microtek.c:338: error: for each function it appears in.)
make[3]: *** [drivers/usb/image/microtek.o] Error 1
make[2]: *** [drivers/usb/image] Error 2
make[1]: *** [drivers/usb] Error 2
make: *** [drivers] Error 2

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3: Oops on IDE flash disk eject

As already reported to lkml and IDE maintainer for 2.6.12-rc2:

Oops on 'cardctl eject' of an IDE flash disk (Pretec ATA Flash 16MB).
2.6.11.2 works fine.

System:
Linux (none) 2.6.12-rc3-gringo #1 Thu Apr 21 15:45:08 CEST 2005 x86_64
unknown unknown GNU/Linux

Kernel messages from startup to and including Oops as well as config are
attached.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
Bootdata ok (command line is BOOT_IMAGE=2.6.12rc2 ro root=301 hdb=none 
hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off 
init=/bin/bash)
Linux version 2.6.12-rc3-gringo ([EMAIL PROTECTED]) (gcc version 3.4.3) #1 Thu 
Apr 21 15:45:08 CEST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f800 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000d8000 - 0010 (reserved)
 BIOS-e820: 0010 - 3ff7 (usable)
 BIOS-e820: 3ff7 - 3ff7a000 (ACPI data)
 BIOS-e820: 3ff7a000 - 3ff8 (ACPI NVS)
 BIOS-e820: 3ff8 - 4000 (reserved)
 BIOS-e820: fffe - 0001 (reserved)
ACPI: RSDP (v000 PTLTD ) @ 0x000f6a60
ACPI: RSDT (v001 PTLTDRSDT   0x0604  LTP 0x) @ 
0x3ff73fde
ACPI: FADT (v002 AMDK8  PTLTW0x0604 PTL_ 0x000f4240) @ 
0x3ff79e56
ACPI: SSDT (v001 PTLTD  POWERNOW 0x0604  LTP 0x0001) @ 
0x3ff79eda
ACPI: MADT (v001 PTLTD   APIC   0x0604  LTP 0x) @ 
0x3ff79fb0
ACPI: DSDT (v001  VIA   PTL_ACPI 0x0604 MSFT 0x010e) @ 
0x
On node 0 totalpages: 262000
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 257904 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 4000 (gap: 4000:bffe)
Built 1 zonelists
Kernel command line: BOOT_IMAGE=2.6.12rc2 ro root=301 hdb=none hdc=cdrom 
hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off 
init=/bin/bash console=tty0
ide_setup: hdb=none
ide_setup: hdc=cdrom
ide_setup: hdd=none
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 1801.076 MHz processor.
time.c: Using PIT/TSC based timekeeping.
Console: colour VGA+ 80x50
time.c: Lost 3 timer tick(s)! rip vfs_caches_init_early+0x0/0xa0)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1024468k/1048000k available (2958k kernel code, 22832k reserved, 1639k 
data, 164k init)
Calibrating delay loop... 3547.13 BogoMIPS (lpj=1773568)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 0a
time.c: Lost 86 timer tick(s)! rip acpi_os_write_port+0x1a/0x36)
Using local APIC NMI watchdog using perfctr0
Using local APIC timer interrupts.
Detected 12.507 MHz APIC timer.
time.c: Lost 55 timer tick(s)! rip setup_boot_APIC_clock+0x112/0x120)
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050309
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
PCI: Via IRQ fixup
Boot video device is :01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled.
ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled.
ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled.
ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled.
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *10 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: Embedded Controller [EC] (gpe 11)
time.c: Lost 8 timer tick(s)! rip acpi_os_write_port+0x1a/0x36)
time.c: Lost 8 timer tick(s)! rip acpi_os_write_port+0x1a/0x36)
Linux Plug and Play Support v0.97 (c) Adam Belay

Re: Linux 2.6.12-rc3: Oops on IDE flash disk eject

The following patch fixes the Oops though I don't know if this is the
correct solution.

--- linux-2.6.12-rc3/drivers/ide/ide.c.ast
+++ linux-2.6.12-rc3/drivers/ide/ide.c
@@ -2082,7 +2082,8 @@
 static int ide_drive_remove(struct device * dev)
 {
ide_drive_t * drive = container_of(dev,ide_drive_t,gendev);
-   DRIVER(drive)-cleanup(drive);
+   if(DRIVER(drive))
+   DRIVER(drive)-cleanup(drive);
return 0;
 }


-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3: various swsusp problems

Hi Pavel,
there's some problems with swsusp in 2.6.12-rc3 (x86_64):

1. Is it necessary to print the following message during regular boot?
   swsusp: Suspend partition has wrong signature?
   It is a bit annoying and I believe it will confuse some swsusp
   users.

2. PCMCIA related hangs during swsusp.
   swsusp hangs after freeing memory when either cardmgr is running
   or pcmcia cards are *physically* inserted. It is insufficient
   to do a 'cardctl eject' the cards must be removed, too, for
   swsusp not to hang. I do suspect some problem with the
   'pccardd' kernel threads.

3. Sometimes during the search for the suspend hang reason the system
   went during suspend into a lightshow of:
   eth0: Too much work at interrupt!
   and some line that ends in:
   release_console_sem+0x13d/0x1c0)
   The start of the line is not readable as it just flickers by in
   the eth0 message limbo. NIC is a built in RTL-8169 Gigabit Ethernet
   (rev 10). Oh, no chance for a serial console capture as there's no
   built in serial device in this laptop.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3: various swsusp problems

Pavel Machek wrote:
 Hi!
 
 
there's some problems with swsusp in 2.6.12-rc3 (x86_64):
 
 
 Are they new or were they in -rc2, too?
 

Fixed the rc2/rc3 IDE Oops myself today that prevented me to test rc2
earlier. It seems the IDE maintainer is currently not very responsive
and I didn't have sufficient spare time to look into this before today :-(

Yes, all problems are already in rc2.

 
1. Is it necessary to print the following message during regular boot?
   swsusp: Suspend partition has wrong signature?
   It is a bit annoying and I believe it will confuse some swsusp
   users.
 
 
 Hmm, feel free to provide a patch. (I need something to try git on :-).

I'll have a look over the weekend.

 
 
2. PCMCIA related hangs during swsusp.
   swsusp hangs after freeing memory when either cardmgr is running
   or pcmcia cards are *physically* inserted. It is insufficient
   to do a 'cardctl eject' the cards must be removed, too, for
   swsusp not to hang. I do suspect some problem with the
   'pccardd' kernel threads.
 
 
 Did it work with any older kernel? Which driver is it? yenta?

2.6.11.2 works ok and, yes, its yenta. Some excerpt from lspci:

00:0b.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
00:0b.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller

 
 
3. Sometimes during the search for the suspend hang reason the system
   went during suspend into a lightshow of:
   eth0: Too much work at interrupt!
   and some line that ends in:
   release_console_sem+0x13d/0x1c0)
   The start of the line is not readable as it just flickers by in
   the eth0 message limbo. NIC is a built in RTL-8169 Gigabit Ethernet
   (rev 10). Oh, no chance for a serial console capture as there's no
   built in serial device in this laptop.
 
 
 How repeatable is that? Will NIC work okay if you rmmod/insmod its driver?
   Pavel

Happens with a probability of about 10% to 20%. I did comment out the
'Too much work...' printk in r8169.c which results in the following
effect: no more message from the network driver (expected), no other
printk related to release_console_sem or anything else unusal, but write
to disk in the case the problem seems to happen is suddenly quite slow
and suspend eventually succeeds.
As the nic driver is built into the kernel insmod/rmmod currently won't
do:-) Nevertheless there doesn't seem to be any strange behaviour after
resume though I didn't really try to use the nic then.
There is, however, definitely no such problem with the nic in 2.6.11.2.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3: various swsusp problems

Pavel Machek wrote:
 Hi!
 Are they new or were they in -rc2, too?

Some further backtracking:

The nic problem is already present in 2.6.12-rc1.
The pcmcia hang problem is not present in 2.6.12-rc1.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 2/4] AES assembler implementation for x86_64

Denis Vlasenko wrote:
> On Monday 18 April 2005 12:01, Andreas Steinmetz wrote:
> 
>>Denis Vlasenko wrote:
>>
>>>On Sunday 17 April 2005 22:20, Andreas Steinmetz wrote:
>>>
>>>
>>>>The attached patch contains Gladman's in-kernel code for key schedule
>>>>and table generation modified to fit to my assembler implementation,
>>>>-- 
>>>>Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
>>>
>>>
>>>Patch contains a mix of several coding styles:
>>> 
>>>+/*
>>>+ * #define byte(x, nr) ((unsigned char)((x) >> (nr*8))) 
>>>+ */
>>>+inline static u8
>>>+byte(const u32 x, const unsigned n)
>>>+{
>>>+   return x >> (n << 3);
>>>+}
>>>
>>>what does const do here?
>>
>>Taken 'as is' from current kernel sources, i,e, crypto/aes.c
> 
> 
> "It's a cut-n-paste" is not a good argument here. You
> are adding a _new file_ with your patch, it's okay to clean
> it up while doing this. IOW: do not dup the mess.
> 
> OTOH, if _exactly the same file_ exist in i384 arch, then
> you should not duplicate it at all. Find a way to use one file
> for both arches.
> 
> Note that this is only my view, I can be wrong.
> --
> vda
> 

I'll wait for Herbert Xu's review and his opinion on this.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 0/4] AES assembler implementation for x86_64

Jörn Engel wrote:
> On Mon, 18 April 2005 03:50:32 -0400, James Morris wrote:
> 
>>Please cc Herbert Xu on kernel crypto patches, he's the frontline 
>>maintainer of it now.
> 
> 
> Care to sign off this patch (or create a similar one)?

No problem, will do after the review by Herbert Xu is done (I guess
there will be some changes required).

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 0/4] AES assembler implementation for x86_64

Andi Kleen wrote:
> On what CPUs did you benchmark? I suppose results will vary a lot
> between AMD and Intel x86-64 CPUs.

AMD. I don't have any Intel around.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 0/4] AES assembler implementation for x86_64