Re: iproute/iptables best?

[bert hubert]

On Wed, Apr 13, 2005 at 11:35:12PM -0400, Gene Heskett wrote:
> How can we make the reply to an action go back out through the route 
> it came in on?  As it exists, queries, ssh sessions etc coming in 
> thru a vpn from one router are being replied to on the default 
> gateways card that hits the other network.

Sometimes Linux can't (and shouldn't) figure out the "right" interface. In
this case, you need policy routing:

http://lartc.org/howto/lartc.rpdb.multiple-links.html
http://lartc.org/howto/lartc.rpdb.html

Good luck!

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 encrypted swsusp 1/3] core functionality

[Pavel Machek]

Hi!

> > > > > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > > > > When the swap runs over dmcrypt all writes including those from
> > > > > swsusp are encrypted.
> > > > 
> > > > Andreas is right. They are encrypted in swap, but they should not be
> > > > there at all. And they are encrypted by key that is still available
> > > > after resume. Bad.
> > > 
> > > The dmcrypt swap can only be unlocked by the user with a passphrase,
> > > which is analogous to how you unlock your ssh private key stored
> > > on the disk using a passphrase.
> > 
> > Once more:
> > 
> > Andreas' implementation destroys the key during resume.
> 
> This solution is all wrong.
> 
> If you want security of the suspend image while "suspended", encrypt
> with dm-crypt. If you want security of the swap image after resume,
> zero out the portion of swap used. If you want both, do both.

I want security of the swap image, and "just zeroing" is hard to do in
failed suspend case, see previous discussion.

Andreas, do you think you could write nice, long, FAQ entries so that
we don't have to go through this discussion over and over?

Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: SLEEP_ON_BKLCHECK

[Arjan van de Ven]

On Thu, 2005-04-14 at 09:42 +0900, tsuchiya yoshihiro wrote:
> Hi,
> In Fedora Core3, interruptible_sleep_on() checks if the system is
> lock_kernel()'ed
> by SLEEP_ON_BKLCHECK. Same thing is done in RedHatEL4.
> Also I found a patch including SLEEP_ON_BKLCHECK was posted before,
> but is not included in 2.6.11.
> Why SLEEP_ON_BKLCHECK checks lock_kernel ?

Because you really need to hold the BKL when you call sleep_on() family
of APIs, otherwise you have a very big race.

Also note that you in your code really should not call any of the
sleep_on() family of functions at all! It is a very very deprecated and
defective API

Can you give the URL to the code where you use this in?
(it is GPL code, right?)

Greetings,
Arjan van de Ven


signature.asc
Description: This is a digitally signed message part

Re: initrd support in 2.6 kernels

[Bernhard Schauer]

> checking if image is initramfs...it isn't (ungzip failed); looks like an 
> initrd
> Freeing initrd memory: 32768K

Hi!

Have you gzipped your initrd image? (if yes, the ungzip failed would be
a problem... btw. initramfs is a smarter way to perform the same) 

regards

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

Angebot

[Euro Transfer]

Sehr geehrte Damen und Herren, 



unser Sonderangebot ist an allen , die neue Klienten 

gewinnen möchten, den Kundenkreis erweitern sowie 

erfolgreiche Werbeaktionen durchführen wollen, gerichtet !!!





Wir bieten Ihnen Datenbanken mit E-Mail-Adressen nicht nur deutscher 

sondern auch britischer, oesterreichischer und anderer Unternehmen an, 

die Hunderttausende von Einträgen enthalten. 

Die Datenbanken sind nach Branchen und Subbranchen gegliedert. 

Der Versand von Angeboten per E-Mail ist eine der preisgünstigsten, 

wirkungsvollsten und schnellsten Werbeformen, dank derer Sie neue 

Käufer für Ihre Produkte und Dienstleistungen gewinnen können. 

Die speziell für unsere Kunden erstellte Software -FastMailing 

2.1.1 ermöglicht den Massenversand von Angeboten. 

Dank dieser Versandmethode sind Sie imstande innerhalb von wenigen Stunden

hunderttausende von Empfängern mit Ihrem Angebot bekanntmachen!

Besuchen Sie unsere Webseite - http://www.eurotransfer.co.uk und überzeugen 

Sie sich selbst.  Speziell für Sie haben wir attraktive Preispakete 

vorbereitet. Unser Sonderangebot ist zeitlich begrenzt weil dauert nur bis zum 

29 April!  Verpassen Sie es nicht! 



Weitere Informationen erhalten Sie unter: [EMAIL PROTECTED]



http://www.eurotransfer.co.uk

oder 

http://www.eurotransfer-de.info





Mit Erfolgswünschen verbleibt  

Ihr EuroTransfer - Team 











Falls Sie kein Interesse an Produkten der Firma EuroTransfer haben, und 

möchten keine weitere Informationen über sie bekommen, klicken Sie nur 

an den Link: http://www.eurotransfer.co.uk/unsubscribe.php - wo Sie 

Ihre E-mail Adresse aus unserer Datenbank löschen können.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-fbdev-devel] [PATCH] print an explanation why i810 fb doesn't come up

[Antonino A. Daplas]

On Monday 28 March 2005 20:30, Denis Vlasenko wrote:
> I've spent silly amonunt of time trying to use i810 fb on my new spiffy
> flat panel. This patch will hopefully help other poor souls.
>
> Patch also fixes module parameter comments.

Thanks, should help.

Tony


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

Feriado em Campos - linux-kernel@vger.kernel.org

[Feriado]

Campos do Jordão nesse Feriado! Ainda da tempo!
Recém construida, privacidade, conforto  e estilo de vida.
A melhor opção para famílias de bom gosto. Alugue nessa temporada!

Visite: http://www.casaemcampos.net

Direto com o Proprietário
Dúvidas pelo email: [EMAIL PROTECTED]







Você recebeu essa mensagem pelo email linux-kernel@vger.kernel.org

Para ser removido de futuros correios, por favor, envie email para
[EMAIL PROTECTED], com o assunto REMOVER. Obrigado.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: hard lockup on nx5000 laptop with 2.6.11+hack and FC2's 2.6.10-1.770_FC2

[Yu, Luming]

Do you have acpi enabled?  
If the problem just happend with acpi enabled, please
try latest acpi patch through testing latest mm tree, If it still doesn't 
work, please file a bug on www.kernel.org

Thanks,
Luming

On Thursday 07 April 2005 09:42, Ben Greear wrote:
> Several wierd things with my laptop since I upgraded from 2.6.9+hack,
> which works beautifully.
>
> 1)  With 2.6.11+hack, compiled for the Pentium-M, the system
>freezes at or soon after I close the LCD screen.  Out of curiosity,
>I tried the FN - [F4] combination, which I believe should try to flip
>the video output to the external monitor port (I have nothing plugged in
> there). This immediately made the machine starting counting memory, and it
> turns out it had completely erased the BIOS settings to defaults and set
> the date back to Jan 4 of this year!
>
> 2) With 2.6.10-1.770_FC2 I totally froze the system when I tried to
>'ifup eth0'.  eth0 is BCM5705M (b44 driver)
>
> 3) When it freezes, the machine gets really hot, and the fan does not
> increase in speed like it normally does.  I am not sure if this means
> anything, but I thought I'd share it.
>
> For now, I'm back at 2.6.9+hack, but I'm willing to try the newer kernels
> if someone has a suggestion or needs more debugging.
>
> Install is:  FC2, mostly up-to-date when I was having these problems, fully
>   up-to-date now.
>
> cpu:
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 13
> model name  : Intel(R) Pentium(R) M processor 1.50GHz
> stepping: 6
> cpu MHz : 1495.769
> cache size  : 2048 KB
> fdiv_bug: no
> hlt_bug : no
> f00f_bug: no
> coma_bug: no
> fpu : yes
> fpu_exception   : yes
> cpuid level : 2
> wp  : yes
> flags   : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov
> pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2 bogomips:
> 2965.50
>
>
> lspci of this system:
> 00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02)
> 00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control
> Registers (rev 02) 00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH
> Configuration Process Registers (rev 02) 00:02.0 VGA compatible controller:
> Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display
> controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02)
> 00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 01)
> 00:1d.1 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #2 (rev 01)
> 00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 01)
> 00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller
> (rev 01) 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 81)
> 00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01)
> 00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage
> Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corp.
> 82801DB (ICH4) AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corp.
> 82801DB (ICH4) AC'97 Modem Controller (rev 01) 01:04.0 Ethernet controller:
> Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) 01:06.0 CardBus
> bridge: Texas Instruments PCI7420 CardBus Controller 01:06.1 CardBus
> bridge: Texas Instruments PCI7420 CardBus Controller 01:06.3 Unknown mass
> storage controller: Texas Instruments PCI7420 Flash Media Controller
> 01:0d.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000
> Controller (PHY/Link) 01:0e.0 Ethernet controller: Broadcom Corporation
> BCM5705M 10/100/1000Base T (rev 02)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Raul Miller]

> > What compels you to agree with an EULA?

On Wed, Apr 13, 2005 at 06:54:29PM -0700, David Schwartz wrote:
>   If you do not agree with the EULA, you cannot and do not acquire
> lawful possession of the work.

What about cases where you pay for the software before you're allowed
to see the EULA?

-- 
Raul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.4.30 Oops when connecting external USB hard drive

[Willy Tarreau]

You may try to unload the ehci-hcd driver and load only uhci and check if
it still happens. I guess from the trace that the problem lies in the ehci
driver itself.

Regards,
willy

On Tue, Apr 12, 2005 at 07:39:11PM +0200, Kiniger wrote:
> Pls see the hand-copied decoded backtrace.
> 
> It happens when I connect a Seagate 160 GB external USB
> hard disk. (I dont have access to this particular drive
> just now  but under Windows I have seen it  as an ST3316002 3A
> USB Device) - Oops happens reliably just after I plug the
> drive in.
> 
> When connecting a Maxtor USB disk there is no Oops however.
> 
> Kernel is 2.4.30-pre4 (same as 2.4.30) with the
> TNG NTFS patches from Anton Altaparmakov but it is not
> in use when it happens. There are no hotplug, automount etc.
> scripts on this system.
> 
> suggestions from the USB experts are welcome.
> 
> Greetings,
> Karl
> 
> ksymoops 2.4.11 on i686 2.6.10-1.770_FC3.  Options used
>  -v vmlinux (specified)
>  -k ksyms.out (specified)
>  -l modules.out (specified)
>  -o /lib/modules/2.4.30-rc4 (specified)
>  -m System.map (specified)
> 
> Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
> Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
> Error (pclose_local): find_objects pclose failed 0x100
> Warning (compare_ksyms_lsmod): module Module is in lsmod but not in ksyms, 
> probably no symbols exported
> Warning (map_ksym_to_module): cannot match loaded module ext3 to a unique 
> module object.  Trace may not be reliable.
> Oops: 
> CPU:0
> EIP:0010:[]Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010207
> eax:    ebx: eed8c200  ecx: ee9f9100  edx: 
> esi: 00010011   edi: ee9ae2e0  ebp: ee9f9100  esp: c029fe98
> ds: 0018   es: 0018  ss: 0018
> Process swapper (pid: 0, stackpage=c029f000)
> Stack: ee9f7180 eed8c200 f00890e3 eed8c200 ee9f9100 2e9f7180 00018148 ee9f914c
>01d8c200  0001 0001 ee9f914c ee9f7120  
>dd9f9100 17f8 f008b3fb eed8c200 ee9f9100 c029ff8c  ee9f6bfc
> Call Trace:[] [] [] [] 
> []
>   [] [] [] [] [] 
> []
>   [] []
> Code: 8b 40 48 39 c8 75 f7 8b 01 89 02 8b 41 48 89 42 48 8b 83 00
> 
> 
> >>EIP; f0089d42 <[ehci-hcd]start_unlink_async+32/e0>   <=
> 
> >>ebx; eed8c200 <_end+2ea8f728/2fd10588>
> >>ecx; ee9f9100 <_end+2e6fc628/2fd10588>
> >>edi; ee9ae2e0 <_end+2e6b1808/2fd10588>
> >>ebp; ee9f9100 <_end+2e6fc628/2fd10588>
> >>esp; c029fe98 
> 
> Trace; f00890e3 <[ehci-hcd]qh_completions+1f3/2d0>
> Trace; f008b3fb <[ehci-hcd]scan_periodic+1cb/230>
> Trace; f008bcdc <[ehci-hcd]ehci_work+4c/d0>
> Trace; f0049d4a <[usbcore]hcd_irq+2a/60>
> Trace; c010a5d5 
> Trace; c010a754 
> Trace; c010cc78 
> Trace; c0110018 
> Trace; c0106fb3 
> Trace; c0114c9c 
> Trace; c0114b60 
> Trace; c0107042 
> Trace; c0105000 <_stext+0/0>
> 
> Code;  f0089d42 <[ehci-hcd]start_unlink_async+32/e0>
>  <_EIP>:
> Code;  f0089d42 <[ehci-hcd]start_unlink_async+32/e0>   <=
>0:   8b 40 48  mov0x48(%eax),%eax   <=
> Code;  f0089d45 <[ehci-hcd]start_unlink_async+35/e0>
>3:   39 c8 cmp%ecx,%eax
> Code;  f0089d47 <[ehci-hcd]start_unlink_async+37/e0>
>5:   75 f7 jnefffe <_EIP+0xfffe>
> Code;  f0089d49 <[ehci-hcd]start_unlink_async+39/e0>
>7:   8b 01 mov(%ecx),%eax
> Code;  f0089d4b <[ehci-hcd]start_unlink_async+3b/e0>
>9:   89 02 mov%eax,(%edx)
> Code;  f0089d4d <[ehci-hcd]start_unlink_async+3d/e0>
>b:   8b 41 48  mov0x48(%ecx),%eax
> Code;  f0089d50 <[ehci-hcd]start_unlink_async+40/e0>
>e:   89 42 48  mov%eax,0x48(%edx)
> Code;  f0089d53 <[ehci-hcd]start_unlink_async+43/e0>
>   11:   8b 83 00 00 00 00 mov0x0(%ebx),%eax
> 
>  <0>Kernel panic: Aiee, killing interrupt handler!
> 
> 2 warnings and 3 errors issued.  Results may not be reliable.
> 
> lspci output:
> 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM 
> Controller/Host-Hub Interface (rev 03)
> 00:02.0 VGA compatible controller: Intel Corporation 
> 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)
> 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM 
> (ICH4/ICH4-L/ICH4-M) USB UHCI Controller  (rev 01)
> 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM 
> (ICH4/ICH4-L/ICH4-M) USB UHCI Controller  (rev 01)
> 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI 
> Controller (rev 01)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81)
> 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface 
> Bridge (rev 01)
> 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 
> 01)
> 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus 
> Controller (rev 01)
> 00:1f.5 Multimedia audio controller: Intel Co

[Long OT] Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Kyle Moffett]

This thread should probably get moved off-list soon, it's like
beating the dead horse long after its flesh has decayed and its
bones disintegrated to dust.
On Apr 13, 2005, at 21:54, David Schwartz wrote:
On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote:
Yes, the GPL can give you rights you wouldn't otherwise have. A
EULA can take away rights you would otherwise have.

What compels you to agree with an EULA?
If you do not agree with the EULA, you cannot and do not acquire lawful
possession of the work.
Of course, one could always assert the following:
  1) I went to a store
  2) I found a box
  3) I went to the cash register
  4) I gave money to the cashier for the box
  5) I took the box home
  6) I opened the box and took out the contents
Now, to the end user, the above is the same procedure for purchasing a
box of cereal or a piece of software, therefore the restrictions are the
same.  I'm not allowed to distribute the copyrightable materials, which
for a cereal box is the images on the box, and for a CD is the digital
data stored therein.  Other than that, I can take a hammer and smash my
CD/cereal, I can make a dozen copies of the CD/box-art and mount them
on the wall or burn them, both of which are symbolic speech.  I can make
backup copies of my cereal box-art/CD too.
At what point of the above did I agree to any license?  As far as I
know, a license (IE: contract) is not valid for a product unless made at
the point-of-sale, before exchanging money.  This is especially valid
since almost all computer retailers refuse refunds for opened software.
When you have to open the box to see the license, that's bad, but when,
as I've seen far too many times, you have to break the seal and insert
the CD to even _see_ the license, it cannot be valid.
The only real point of most of the EULAs is to protect the owners
copyright, which is implicitly protected in any case.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r  
!y?(-)
--END GEEK CODE BLOCK--

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

pcmcia/cardbus issue

[Benjamin Herrenschmidt]

Hi !

I'm occasionally getting "pcmcia: voltage interrogation timed out" error
when inserting a cardbus card on TI1510 based laptops here. I haven't
yet reproduced on other models. This happens with 2.6.12-rc2. The card
isn't detected right after insertion, then about 10 seconds later, it is
detected and this message appears in dmesg. It doesn't seem to be 100%
reproduceable but I'm not entirely sure at the moment.

When this happens, removing the card results in a "DANGER" message about
not beeing able to remove power from the port.

I didn't reproduce on a TI1410 based machine.

Any clue ?

Ben.


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

iproute/iptables best?

[Gene Heskett]

Scenario:

1 machine, two net cards, two networks

How can we make the reply to an action go back out through the route 
it came in on?  As it exists, queries, ssh sessions etc coming in 
thru a vpn from one router are being replied to on the default 
gateways card that hits the other network.

Is iptables the best tool, or is iproute2 the best tool to do this?

Pointers to good docs etc appreciated.  Thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: security issue: hard disk lock

[Mark Lord]

hdparm-6.0 is currently winding through release channels,
and includes support for freezing/managing the security status.
Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ANNOUNCE] git-pasky-0.3

[bd]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Xavier Bestel wrote:
> Le mercredi 13 avril 2005 Ã 10:25 +0100, David Woodhouse a Ãcrit :
> 
>>On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote:
>>
>>>Theoretically, you are never supposed to share your index if you work
>>>in fully git environment. 
>>
>>Maybe -- if we are prepared to propagate the BK myth that network
>>bandwidth and disk space are free. 
> 
> 
> On a related note, maybe kernel.org should host .torrent files (and
> serve them) for the kernel git repository. That would ease the pain.

Bittorrent does not lend itself well to frequently-changing files or
collections thereof - each time the git repository ip updated, a new
metadata file would need to be created, and distributed, and you'd lose
all the seeds who don't bother to get the new one every time it changes.
Moreover, I imagine some clients would have problems with more than 900
or so files due to open file limits.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1-ecc0.1.6 (GNU/Linux)

iQIVAwUBQl2lsXhF4rlE0/81AQMEZA/+MtAwhLVBGbjIGMG4911/Q4tL+RZCni2Z
9wCM2/1Acca7CUeYJOX3bFqx/HMlVyzTN/DFyz7oQbngNrcOFaO4xqHwDT9iVpUB
x1fE2Ct1BXOOnAQEzjEoogKrjWuYiy2tkcsFNMFoef0qV9U8olwwtUgXG8+dOQSZ
gEPocjFmEJLMxhNxdnigW2R1KWgJ0IoFmpIWxDUnpQGBg/dfVxtI4EQhR7FgZwch
O9faPyMdHEct7WW4S8ysMcwGUyRg8J/nlgt413P66PSp9IJ5u8t/gUc0vVcDR0Bl
QNO5Hf2kGe/tILYNMJOtQX8sGcKHC4mZJMsNlhs5Y0+GsD9/9JGj3lv69SM+kv92
5S3ePfArzNvnuoCCxS1iC+s1HZ8fyYXAPx6pVA3cs0/+QGv0LjeSZOCBWmh8vrl1
SD4MF6TPy4mdF1corQE1o8bCc/VP0cTnwBvyF6BpZeP9nipgrzLxM1PPTtDjyUDG
B3VocEsieTyyzfl3hXJxGqFL3Txt6EbRU4AwYitONbTU5zMaQuEY4xBD+UWQJgAO
K8rMXqONSoORWrZVuRyrTmFr/z6zq00BpwQy7BbHuwEXHSPvc/e4UHtk8wNYyY13
LAi2jgMGmGckwucauqZY5Y3mDaOh2m9+0x8hIvvnmLPQC91cVsuerKiKYzjYJ4/4
qsnhjobIq1s=
=ZiJ1
-END PGP SIGNATURE-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sched: fix sched domain degenerate

[Siddha, Suresh B]

Appended patch makes sched domain degenerate really work.

For example, now NUMA domain really gets removed on a non-NUMA system.

Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>


--- linux-2.6.12-rc2-mm3/kernel/sched.c 2005-04-13 11:15:00.942609504 -0700
+++ linux-mc/kernel/sched.c 2005-04-13 10:44:37.400829992 -0700
@@ -4777,7 +4777,7 @@ static int __devinit sd_parent_degenerat
/* WAKE_BALANCE is a subset of WAKE_AFFINE */
if (cflags & SD_WAKE_AFFINE)
pflags &= ~SD_WAKE_BALANCE;
-   if ((~sd->flags) & parent->flags)
+   if (~cflags & pflags)
return 0;
 
return 1;
--- linux-2.6.12-rc2-mm3/include/linux/topology.h   2005-04-11 
23:08:30.843108376 -0700
+++ linux-mc/include/linux/topology.h   2005-04-13 11:14:44.591095312 -0700
@@ -97,6 +97,7 @@
.flags  = SD_LOAD_BALANCE   \
| SD_BALANCE_NEWIDLE\
| SD_BALANCE_EXEC   \
+   | SD_BALANCE_FORK   \
| SD_WAKE_AFFINE\
| SD_WAKE_IDLE  \
| SD_SHARE_CPUPOWER,\
@@ -128,6 +129,7 @@
.flags  = SD_LOAD_BALANCE   \
| SD_BALANCE_NEWIDLE\
| SD_BALANCE_EXEC   \
+   | SD_BALANCE_FORK   \
| SD_WAKE_AFFINE,   \
.last_balance   = jiffies,  \
.balance_interval   = 1,\
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] X86_64: no legacy HPET fix

[Venkatesh Pallipadi]

This adds another timer combination of PIT/HPET to go with
HPET/HPET, HPET/TSC and PIT/TSC!
This system that has HPET and doesn't have Legacy support, does it support
routing HPET interrupts through IOAPIC in standard routing option? If yes,
then I think adding support to route HPET interrupts in a non-legacy way
(using IRQs other than IRQ 0) is another option here. I looked at that 
when adding initial HPET support on i386, but dropped that idea after looking
at all the changes required and also due to the reason that all HPET capable
systems I had also had Legacy Support.


Some comments on the patch inlined below..

On Tue, Apr 12, 2005 at 07:43:16PM -0700, john stultz wrote:
> 
> Its likely a similar patch will be necessary for i386.
Yes. Pretty much similar change will be required in i386 as well..

> linux-2.6.12-rc2_hpet-nolegacy-fix_A0
> =
> diff -Nru a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
> --- a/arch/x86_64/kernel/time.c   2005-04-12 19:31:50 -07:00
> +++ b/arch/x86_64/kernel/time.c   2005-04-12 19:31:50 -07:00
> @@ -373,8 +374,10 @@
>  
>   write_seqlock(&xtime_lock);
>  
> - if (vxtime.hpet_address) {
> - offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
> + if (vxtime.hpet_address)
> + offset = hpet_readl(HPET_COUNTER);
> +
> + if (hpet_use_timer) {
>   delay = hpet_readl(HPET_COUNTER) - offset;

Probably this has to change to use HPET_T0_CMP for offset, when hpet_use_timer.
Otherwise we will always have delay close to zero in case of hpet_use_timer,
which is a change in behaviour.

>   } else {
>   spin_lock(&i8253_lock);
> @@ -732,7 +735,7 @@
>   struct hpet_datahd;
>   unsigned intntimer;
>  
> - if (!vxtime.hpet_address)
> + if (!hpet_use_timer)
>return -1;

We may need to do some initialization here even in case of !hpet_use_timer.
Like reserving particular HPET timer for timer use. Otherwise, someone
else (/dev/hpet) can overwrite the counter. I think we just need to skip 
setting the interupts part.


Thanks,
Venki
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Why system call need to copy the date from the userspace before using it

[David Schwartz]

> Catalin Marinas wrote:

> >Tomko <[EMAIL PROTECTED]> wrote:

> >>Inside the system call , the kernel often copy the data by calling
> >>copy_from_user() rather than just using strcpy(), is it because the
> >>memory mapping in kenel space is different from user space?

> >No, it is because this function checks whether the access to the user
> >space address is OK. There are situations when it can also sleep (page
> >not present).

> what u means "OK"?  kernel space should have right to access any memory
> address , can u expained in details what u means "OK"?

Kernel space does have the right to access any memory but user space
doesn't, so the kernel can't just take an address from user space and use
it. Consider:

int i=open("/dev/null", O_RDWR);
write(i, NULL, 4);

Are you seriously suggesting the kernel should just read from address 
zero
because a user-space program asked it to?

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Why system call need to copy the date from the userspace before using it

[Tomko]

Catalin Marinas wrote:
Tomko <[EMAIL PROTECTED]> wrote:
 

Inside the system call , the kernel often copy the data by calling
copy_from_user() rather than just using strcpy(), is it because the
memory mapping in kenel space is different from user space?
   

No, it is because this function checks whether the access to the user
space address is OK. There are situations when it can also sleep (page
not present).
 

what u means "OK"?  kernel space should have right to access any memory 
address , can u expained in details what u means "OK"?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2 - 2.6.11.7] x25 : Selective subaddress matching with call user data

[Shaun Pereira]

Hi
This is the first (independent of the second) patch of two that I am
working on with x25 on linux (tested with xot on a cisco router).
Details are as follows.

Current state of module:
A server using the current implementation (2.6.11.7) of the x25 module will 
accept 
a call request/ incoming call packet at the listening x.25 address, from all 
callers
to that address, as long as NO call user data is present in the packet header.

If the server needs to choose to accept a particular call request/ incoming 
call 
packet arriving at its listening x25 address, then the kernel has to allow a 
match of 
call user data present in the call request packet with its own. This is required
when multiple servers listen at the same x25 address and device interface. The
kernel currently matches ALL call user data, if present.

Current Changes:
This patch is a follow up to the patch submitted previously by Andrew Hendry, 
and
allows the user to selectively control the number of octets of call user data 
in the 
call request packet, that the kernel will match. By default no call user data 
is matched, even if call user data is present. To allow call user data 
matching, 
a  cudmatchlength > 0 has to be passed into the kernel after which the passed 
number of octets will be matched. Otherwise the kernel behavior is exactly as 
the original implementation.

This patch also ensures that as is normally the case, no call user data will
be present in the Call accepted / call connected packet sent back to the 
caller. 

Future Changes on next patch:
There are cases however when call user data may be present in the call accepted
packet. According to the X.25 recommendation (ITU-T 10/96) section 5.2.3.2 
call user data may be present in the call accepted packet provided the fast 
select
facility is used. My next patch will include this fast select utility and the 
ability
to send up to 128 octets call user data in the call accepted packet provided the
fast select facility is used. I am currently testing this, again with xot on 
linux 
and cisco. 
Regards
Shaun

Signed-off-by: Shaun Pereira <[EMAIL PROTECTED]>

diff -uprN -X dontdiff linux-2.6.11.7-vanilla/include/linux/x25.h 
linux-2.6.11.7/include/linux/x25.h
--- linux-2.6.11.7-vanilla/include/linux/x25.h  2005-04-08 04:58:01.0 
+1000
+++ linux-2.6.11.7/include/linux/x25.h  2005-04-14 09:07:43.0 +1000
@@ -4,6 +4,8 @@
  * History
  * mar/20/00   Daniela Squassoni Disabling/enabling of facilities 
  *   negotiation.
+ * apr/02/05   Shaun Pereira Selective sub address matching with
+ * call user data
  */
 
 #ifndefX25_KERNEL_H
@@ -16,6 +18,7 @@
 #defineSIOCX25GCALLUSERDATA(SIOCPROTOPRIVATE + 4)
 #defineSIOCX25SCALLUSERDATA(SIOCPROTOPRIVATE + 5)
 #defineSIOCX25GCAUSEDIAG   (SIOCPROTOPRIVATE + 6)
+#define SIOCX25SCUDMATCHLEN(SIOCPROTOPRIVATE + 7)
 
 /*
  * Values for {get,set}sockopt.
@@ -109,4 +112,11 @@ struct x25_causediag {
unsigned char   diagnostic;
 };
 
+/*
+ * Further optional call user data match length selection
+ */
+struct x25_subaddr {
+   unsigned int cudmatchlength;
+};
+
 #endif
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/include/net/x25.h 
linux-2.6.11.7/include/net/x25.h
--- linux-2.6.11.7-vanilla/include/net/x25.h2005-04-08 04:57:45.0 
+1000
+++ linux-2.6.11.7/include/net/x25.h2005-04-14 09:07:43.0 +1000
@@ -132,7 +132,7 @@ struct x25_neigh {
 struct x25_opt {
struct x25_address  source_addr, dest_addr;
struct x25_neigh*neighbour;
-   unsigned intlci;
+   unsigned intlci, cudmatchlength;
unsigned char   state, condition, qbitincl, intflag;
unsigned short  vs, vr, va, vl;
unsigned long   t2, t21, t22, t23;
@@ -238,7 +238,6 @@ extern int  x25_validate_nr(struct sock 
 extern void x25_write_internal(struct sock *, int);
 extern int  x25_decode(struct sock *, struct sk_buff *, int *, int *, int *, 
int *, int *);
 extern void x25_disconnect(struct sock *, int, unsigned char, unsigned char);
-extern int x25_check_calluserdata(struct x25_calluserdata *,struct 
x25_calluserdata *);
 
 /* x25_timer.c */
 extern void x25_start_heartbeat(struct sock *);
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/net/x25/af_x25.c 
linux-2.6.11.7/net/x25/af_x25.c
--- linux-2.6.11.7-vanilla/net/x25/af_x25.c 2005-04-08 04:58:30.0 
+1000
+++ linux-2.6.11.7/net/x25/af_x25.c 2005-04-14 09:18:36.0 +1000
@@ -29,6 +29,7 @@
  * 2000-11-14  Henner EisenClosing datalink from NETDEV_GOING_DOWN
  * 2002-10-06  Arnaldo C. Melo Get rid of cli/sti, move proc stuff to
  * x25_proc.c, using seq_file
+ * 2005-04-02  Shaun Pereira   Selective sub address matching with 
call user data
  */
 
 #include 
@@ -219,7 +220

RE: non-free firmware in kernel modules, aggregation and unclearcopyright notice.

[David Schwartz]

> It seems to me, that to be consistent with the argument you seem to be
> presenting concerning binary data in GPLd code, that you also need to be
> demanding the "source" hardware design for binary register values.
>
> Why not consider the binary firmware in the same category as binary
> register programming information?  You poke these magic bytes into these
> memory locations and it works.
>
> Where do you draw the lines between "write this byte to set the input
> gate here and the output gate to there" and "write this byte sequence to
> send the input byte through this loop, into this buffer, add it to the
> last byte entered, and output it over there"?

You draw the line at the source code, the preferred form of the work for
the purpose of making modifications to it. See GPL section 3. Firmware is an
executable work.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[David Schwartz]

> On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote:
> > Yes, the GPL can give you rights you wouldn't otherwise have. A
> > EULA can take away rights you would otherwise have.

> What compels you to agree with an EULA?

If you do not agree with the EULA, you cannot and do not acquire lawful
possession of the work.

> > In the few court cases that have directly addresses shrink-wrap and
> > click-wrap type agreements, I've seen them consistently upheld. However,
> > this is not relevent to the GPL issue at all because the GPL
> > can only give
> > you rights you wouldn't otherwise have, it cannot take away any rights.

> The GPL offers you certain rights if you agree to be bound by certain
> conditions.

Right, and normally the way you become bound by the GPL is if you do
something that you could not acquire the right to do any other way. That's
why GPL issues frequently hinge on whether you could not acquire the right
any other way. Possible other ways include first sale and fair use.

> You are not compelled to agree to those conditions, but those who do
> not gain no rights from the GPL.

Right, again, that's why it's important to look at whether they could 
have
acquired the rights any other way.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[David Schwartz]

>  >Would you agree that compiling and linking a program that
>  >uses a library creates a derivative work of that library?

> No. Compiling and linking are mechanical,
> non-intellectually-novel acts. At most, you have a collective
> work where the real intellectually-novel work was to select
> what goes into the collective.

Compiling and linking are mechanical, but unless you want to argue that 
the
result is not a single work, it clearly creates a derivative work of all the
things linked. The creativity is not in the linking itself but in the
creation of the individual works such that they can be linked together.

>  >Wouldn't you agree that this is the normal form of use of a
>  >library?  And doesn't first sale give you the right to normal
>  >use of a work you have legally acquired?
>
> Yes. And yes, if you buy a copy of the library, yes (but
> notice: not if you downloaded it for free from the Net).

There is no legal distinction. Your rights come not from the fact that 
you
paid money for the work but simply from the fact that you acquired it
legally. Again, the reductio ad absurdum is the guy who drops copies of his
poem from an airplane and then demands royalities from everyone who reads
it. If you legally acquired it, you get the bundle of rights under first
sale.

>  >There are many ways you can lawfully create a derivative work
>  >without explicit permission of the copyright holder. One
>
> No. The copyright law states that the copyright owner has the
> monopolistic right to create derivative works.

Yes, but this doesn't restrict first sale or fair use. You cannot use a
library without creating a derivative work, so if first sale grants you
rights to use, it automatically grants you the right to do anything
necessary for use.

>  >clear case is when you lawfully possess the work, there is no
>  >EULA or shrink-wrap agreement, and you need to produce a
>  >derivative work to use the work in the ordinary fashion.

> No... Try writing a book with Harry Potter as your main
> character and JKR's lawyers will be at your door soon.

Sometimes I wonder if you are reading what I said or not. I said "you 
need
to produce a derivative work to use the work in the ordinary fashion" and
you say "No" and follow with an example where you clearly *don't* need to
produce a derivative work to use the work in the ordinary fashion.

>  >This is, by the way, the FSF's own position. It's not
>  >something I'm making up or guessing at.
>
> Please send us some pointers to this statements for the FSF.

Read any of Eben Moglen's posts.

>  >"The license does not require anyone to accept it in order to
>  >acquire, install, use, inspect, or even experimentally modify
>  >GPL'd software. All of those activities are either forbidden
>
> Wrong again. GPL, section 0, para 1: "Activities other than
> copying, distribution, and *modification* are not covered by
> this License". Emphasis mine.

You are free to disagree with the FSF's interpretation of the GPL, but 
you
are not free to misrepresent the FSF's interpreration.

>  >or controlled by proprietary software firms, so they require
>  >you to accept a license, including contractual provisions
>  >outside the reach of copyright, before you can use their
>  >works.  The free software movement thinks all those
>  >activities are rights, which all users ought to have; we
>  >don't even want to cover those activities by license."
>
> Except for the modification part, which *is* the scope of
> regular, Berne-convention-molded copyrights law.

Feel free to disagree with the FSF about the meaning of the GPL, but it 
is
the FSF's position that you can modify a GPL'd work without agreeing to the
GPL.

>  >Now we draw different conclusions based on this, but we agree
>  >on this. You do not need to agree to the GPL to create
>  >derivative works.
>
> No, we disagree on this too.

I don't know who "we" is, but I agree with the FSF.

>  >>If you will keep your copy and registration # of windows,
>  >>yes, you *must* wipe out the machine before selling it.
>  >
>  >
>  >Since there is no copy or registration number of a GPL'd work
>  >to keep, this actually argues the reverse of what I said. If
>  >I legally acquire ten copies of Windows, I can perform normal
>  >use on those ten copies and then transfer those copies to
>  >someone else.

> This is not the point: you still would have to wipe your ten
> computers clean if you want to sell the ten copies you have.

Right. You cannot increase the number of copies.

> In the GPL'd case, if you disregard the terms of the license,
> you can still keep, use, etc. You can *not* copy it,
> distribute it, or modify it tough.

You can, so long as you don't increase the number of copies. This is a
right under first sale.

>  >>So, no, when you get a WinXP CD from Microsoft, you have
>  >>absolutely *no* rights to create derivative works. If a
>  >>person creates a 

[GIT PATCH] scsi updates for 2.6.12-rc2

[James Bottomley]

This is a small set of bugfixes for 2.6.12-rc2 ... you asked me to try
git, so I did (I actually updated my bk backport script simply to export
from a BK tree to a git tree).  For the time being, I plan to keep the
scsi changes in BK, but I'll export them for you to try merging

The patch (against kernel-test.git) is here

rsync://www.parisc-linux.org/~jejb/scsi-rc-fixes-2.6.git

So let's see if you can apply it ;-)

The shortlog (ok, generated by BK) is

Andreas Herrmann:
  o zfcp: convert to compat_ioctl

Douglas Gilbert:
  o sg.c: update

James Bottomley:
  o updates for CFQ oops fix
  o finally fix 53c700 to use the generic iomem infrastructure

Jens Axboe:
  o fix NMI lockup with CFQ scheduler

And the diffstat (generated from git) is:

 drivers/block/ll_rw_blk.c|9 +
 drivers/s390/scsi/zfcp_aux.c |   34 ++-
 drivers/scsi/53c700.c|3 
 drivers/scsi/53c700.h|  192 
 drivers/scsi/Kconfig |   10 --
 drivers/scsi/NCR_D700.c  |5 -
 drivers/scsi/lasi700.c   |1 
 drivers/scsi/scsi_lib.c  |6 -
 drivers/scsi/scsi_scan.c |1 
 drivers/scsi/scsi_sysfs.c|3 
 drivers/scsi/sg.c|  203 +++
 drivers/scsi/sim710.c|5 -
 include/linux/blkdev.h   |5 -
 include/scsi/scsi_device.h   |2 
 14 files changed, 191 insertions(+), 288 deletions(-)

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

[Derek Cheung]

OK, hope this patch can satisfy everyone :-)

The following is the diffstat of the enclosed patch file:

 drivers/i2c/busses/Kconfig   |   10 
 drivers/i2c/busses/Makefile  |1 
 drivers/i2c/busses/i2c-mcf5282.c |  414
+++
 drivers/i2c/busses/i2c-mcf5282.h |   46 
 include/asm-m68knommu/m528xsim.h |   42 +++
 5 files changed, 513 insertions(+)

I did:

a) remove all trailing spaces in the files
b) re-align the switch statement
c) change a return statement
d) change some white space intents to TABs
e) insert a break for the I2C_SMBUS_PROC_CALL, thanks for spotting it
f) fix the mcf5282lite wording in Kconfig

I did not:

g) use the ioremap. This is because Coldfire is a CPU without MMU and
there is no difference between virtual and physical memory. In fact, the
ioremap routine in the m68knommu is simply a stub routine that returns
the input address argument for compatibility reason. Also, all other
Coldfire CPU include files such as the m5307sim.h uses the volatile
declaration method. 
So, I hope this is acceptable to the Linux kernel maintainers

Please let me know if there is any question.

Regards
Derek


-Original Message-
From: Greg KH [mailto:[EMAIL PROTECTED] 
Sent: April 11, 2005 4:03 PM
To: Derek Cheung
Cc: 'Randy.Dunlap'; 'Andrew Morton'; Linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

On Sun, Apr 10, 2005 at 12:47:42PM -0400, Derek Cheung wrote:
> Enclosed please find the updated patch that incorporates changes for
all
> the comments I received.

You did not cc: the sensors mailing list, nor fix all of the coding
style issues.

> The volatile declaration in the m528xsim.h is needed because the
> declaration refers to the ColdFire 5282 register mapping.

Shouldn't you be calling ioremap, and not directly accessing a specific
register location through a pointer?  That's how all other arches do
this.

thanks,

greg k-h


linux_patch_submit3
Description: Binary data

Re: [PATCH encrypted swsusp 1/3] core functionality

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> The dmcrypt swap can only be unlocked by the user with a passphrase,
> which is analogous to how you unlock your ssh private key stored
> on the disk using a passphrase.

We talk about the unlocked system getting hacked. However I am not why the
hacker would head for the swap if he can as well read the ram.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 encrypted swsusp 1/3] core functionality

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> The ssh keys are *encrypted* in the swap when dmcrypt is used.
> When the swap runs over dmcrypt all writes including those from
> swsusp are encrypted.

The problem is that after an resume the running system has access to the
swap, because the key is recoverd. And the left over hybernation data in the
swap can be read by the running kernel because the swap key is restored.
This is not an attack against a notebook in hybernaion, but an attack
against a running system with non-wiped bybernation leftovers - not critical
to me but an possible point of interest.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2-mm3

[Andrew Morton]

Ed Tomlinson <[EMAIL PROTECTED]> wrote:
>
> On Wednesday 13 April 2005 20:20, Andrew Morton wrote:
>  > Ed Tomlinson <[EMAIL PROTECTED]> wrote:
>  > >
>  > > > Don't think so - it works OK here.  Checked the .config?  Does the 
> serial
>  > >  > port work if you do `echo foo > /dev/ttyS0'?  ACPI?
>  > > 
>  > >  Turned out it was some old ups software that got reactivated on the box 
> displaying the
>  > >  console - was a pain to disable it
>  > 
>  > OK.
>  > 
>  > >  In any case, when the box reboots there are not any messages.  Any 
> ideas on what debug
>  > >  options to enable or suggestions on how we can figure out the cause of 
> the reboots.
>  > 
>  > There were a few problems in the task switching area - maybe that.
> 
>  These hit arch/i386.  Are they going to help on an x86_64 box?

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

Linux Audio Conference 2005 Live Audio/Video streams

[Joern Nettingsmeier]

hi everyone!

for those interested in linux audio development, the linux audio 
conference 2005 (http://lac.zkm.de) at the center for arts and media in 
karlsruhe/germany will be streamed live in both vorbis and theora formats.

the conference takes place from april 21 - 24, with lectures and 
workshops from 11:00 to 18:00 UTC+2 every day and concerts in the evenings.

i would like to invite you to join us, either in person (attendance to 
the conference is free) or remotely over the internet.

for remote participants of the conference, there is a chat room #lac2005 
on irc.freenode.net. a chat operator will be present in the auditorium 
in karlsruhe and will relay your questions to the lecturer and the local 
audience. papers and slides will be made available for download in 
advance if possible.

information about the streams and how to watch them is at 
http://lac2005.zkm.de.

huge kudos to the icecast, ogg, vorbis and theora developers and 
communites for their code and expertise!


kind regards,
jörn nettingsmeier
on behalf of the linux audio community

feel free to forward this message to interested parties.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Fortuna

[Matt Mackall]

On Wed, Apr 13, 2005 at 08:26:47PM -0400, Jean-Luc Cooke wrote:
> On Wed, Apr 13, 2005 at 05:09:39PM -0700, Matt Mackall wrote:
> > On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
> > > Ahh.  Thanks Herbert.
> > > 
> > > Matt,
> > > 
> > > Any insight on how to test syn cookies and the other network stuff in
> > > random.c?  My patch is attached, but I havn't tested that part yet.
> > 
> > For starters, this is not against anything like a current random.c. A
> > great number of cleanups have been done.
> 
> You caught me.  :)
> 
> Last I proposed Fortuna for /dev/random it nearly got me drawn and quarterd.

It still might. Ted and I are as yet unconvince that the Fortuna
approach is superior. While it may have some good properties, it lacks
some that random.c has, particularly robustness in the face of failure
of crypto primitives.

> So I've left it as a kenrel config option, leaving the current random.c
> alone.  I thought this was a way to make everyone happy.

Duplicated code rarely does that.

At any rate, you ought to review the changes (there've been 40+
patches recently). There are a number of bug fixes in there and quite
a bit of cleanup. Syncookies in particular no longer live in random.c.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] PC300 pci_enable_device fix

[Marcelo Tosatti]

On Wed, Apr 13, 2005 at 03:02:43PM -0700, Ashok Raj wrote:
> On Wed, Apr 13, 2005 at 02:31:43PM -0700, Bjorn Helgaas wrote:
> > 
> >Call pci_enable_device() before looking at IRQ and resources.
> >The driver requires this fix or the "pci=routeirq" workaround
> >on 2.6.10 and later kernels.
> 
> 
> the failure cases dont seem to worry about pci_disable_device()?
> 
> in err_release_ram: etc?

Yep the failure paths were wrong before, but Bjorn's patch moves 
pci_enable_device() way up to the beginning of the function. 

The failure path's err_release_ram etc. wont touch the resources
without pci_enable_pci(), with the fix.

> >Reported and tested by Artur Lipowski.
> > 
> >Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
> > 
> >= drivers/net/wan/pc300_drv.c 1.24 vs edited =
> >--- 1.24/drivers/net/wan/pc300_drv.c2004-12-29 12:25:16 -07:00
> >+++ edited/drivers/net/wan/pc300_drv.c  2005-04-13 13:35:21 -06:00
> >@@ -3439,6 +3439,9 @@
> > #endif
> >}
> > 
> >+   if ((err = pci_enable_device(pdev)) != 0)
> >+   return err;
> >+
> >card = (pc300_t *) kmalloc(sizeof(pc300_t), GFP_KERNEL);
> >if (card == NULL) {
> >printk("PC300 found at RAM 0x%08lx, "
> >@@ -3526,9 +3529,6 @@
> >err = -ENODEV;
> >goto err_release_ram;
> >}
> >-
> >-   if ((err = pci_enable_device(pdev)) != 0)
> >-   goto err_release_sca;
> > 
> >  card->hw.plxbase   =   ioremap(card->hw.plxphys,
> >card->hw.plxsize);
> >  card->hw.rambase   =   ioremap(card->hw.ramphys,
> >card->hw.alloc_ramsize);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

SLEEP_ON_BKLCHECK

[tsuchiya yoshihiro]

Hi,
(BIn Fedora Core3, interruptible_sleep_on() checks if the system is
(Block_kernel()'ed
(Bby SLEEP_ON_BKLCHECK. Same thing is done in RedHatEL4.
(BAlso I found a patch including SLEEP_ON_BKLCHECK was posted before,
(Bbut is not included in 2.6.11.
(BWhy SLEEP_ON_BKLCHECK checks lock_kernel ? Lock_kernel shoud be held
(Bduring sleep_on_timeout? And I also wonder why 2.6.11 does not check it.
(B
(BThank you,
(BPlease CC me because I am not subscribing this list.
(BYoshi Tsuchiya
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.12-rc2-mm3

[Ed Tomlinson]

On Wednesday 13 April 2005 20:20, Andrew Morton wrote:
> Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> >
> > > Don't think so - it works OK here.  Checked the .config?  Does the serial
> >  > port work if you do `echo foo > /dev/ttyS0'?  ACPI?
> > 
> >  Turned out it was some old ups software that got reactivated on the box 
> > displaying the
> >  console - was a pain to disable it
> 
> OK.
> 
> >  In any case, when the box reboots there are not any messages.  Any ideas 
> > on what debug
> >  options to enable or suggestions on how we can figure out the cause of the 
> > reboots.
> 
> There were a few problems in the task switching area - maybe that.

These hit arch/i386.  Are they going to help on an x86_64 box?

Ed 
 
> From: Ingo Molnar <[EMAIL PROTECTED]>
> 
> delay the reloading of segment registers into switch_mm(), so that if
> the LDT size changes we dont get a (silent) fault and a zeroed selector
> register upon reloading.
> 
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
> 
>  25-akpm/arch/i386/kernel/process.c |   10 +-
>  25-akpm/include/asm-i386/mmu_context.h |7 +++
>  2 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff -puN arch/i386/kernel/process.c~sched-unlocked-context-switches-fix 
> arch/i386/kernel/process.c
> --- 25/arch/i386/kernel/process.c~sched-unlocked-context-switches-fix 
> 2005-04-12 03:43:07.254363568 -0700
> +++ 25-akpm/arch/i386/kernel/process.c2005-04-12 03:43:07.259362808 
> -0700
> @@ -653,12 +653,12 @@ struct task_struct fastcall * __switch_t
>   asm volatile("mov %%gs,%0":"=m" (prev->gs));
>  
>   /*
> -  * Restore %fs and %gs if needed.
> +  * Clear selectors if needed:
>*/
> - if (unlikely(prev->fs | prev->gs | next->fs | next->gs)) {
> - loadsegment(fs, next->fs);
> - loadsegment(gs, next->gs);
> - }
> +if (unlikely((prev->fs | prev->gs) && !(next->fs | next->gs))) {
> +loadsegment(fs, next->fs);
> +loadsegment(gs, next->gs);
> +}
>  
>   /*
>* Now maybe reload the debug registers
> diff -puN include/asm-i386/mmu_context.h~sched-unlocked-context-switches-fix 
> include/asm-i386/mmu_context.h
> --- 25/include/asm-i386/mmu_context.h~sched-unlocked-context-switches-fix 
> 2005-04-12 03:43:07.256363264 -0700
> +++ 25-akpm/include/asm-i386/mmu_context.h2005-04-12 03:43:07.260362656 
> -0700
> @@ -61,6 +61,13 @@ static inline void switch_mm(struct mm_s
>   }
>   }
>  #endif
> + /*
> +  * Now that we've switched the LDT, load segments:
> +  */
> + if (unlikely(current->thread.fs | current->thread.gs)) {
> + loadsegment(fs, current->thread.fs);
> + loadsegment(gs, current->thread.gs);
> + }
>  }
>  
>  #define deactivate_mm(tsk, mm) \
> _
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 encrypted swsusp 1/3] core functionality

[Matt Mackall]

On Thu, Apr 14, 2005 at 01:46:02AM +0200, Pavel Machek wrote:
> On ??t 14-04-05 09:39:04, Herbert Xu wrote:
> > On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
> > >
> > > > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > > > When the swap runs over dmcrypt all writes including those from
> > > > swsusp are encrypted.
> > > 
> > > Andreas is right. They are encrypted in swap, but they should not be
> > > there at all. And they are encrypted by key that is still available
> > > after resume. Bad.
> > 
> > The dmcrypt swap can only be unlocked by the user with a passphrase,
> > which is analogous to how you unlock your ssh private key stored
> > on the disk using a passphrase.
> 
> Once more:
> 
> Andreas' implementation destroys the key during resume.

This solution is all wrong.

If you want security of the suspend image while "suspended", encrypt
with dm-crypt. If you want security of the swap image after resume,
zero out the portion of swap used. If you want both, do both.

You could even just zero out those regions which were mlocked at
suspend. If it wasn't mlocked, it might be on swap already anyway.

Re-implementing dm-crypt for this purpose is ridiculous.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ppc64: improve g5 sound headphone mute

[Andrea Arcangeli]

On Wed, Apr 13, 2005 at 09:23:02PM +1000, Benjamin Herrenschmidt wrote:
> Hi !
> 
> This patch fixes a couple more issues with the management of the GPIOs
> dealing with headphone and line out mute on the G5. It should fix the
> remaining problems of people not getting any sound out of the headphone
> jack.

It works great here with all patches applied, thanks!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fortuna

[Jean-Luc Cooke]

On Wed, Apr 13, 2005 at 05:09:39PM -0700, Matt Mackall wrote:
> On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
> > Ahh.  Thanks Herbert.
> > 
> > Matt,
> > 
> > Any insight on how to test syn cookies and the other network stuff in
> > random.c?  My patch is attached, but I havn't tested that part yet.
> 
> For starters, this is not against anything like a current random.c. A
> great number of cleanups have been done.

You caught me.  :)

Last I proposed Fortuna for /dev/random it nearly got me drawn and quarterd.
So I've left it as a kenrel config option, leaving the current random.c
alone.  I thought this was a way to make everyone happy.

JLC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2-mm3

[Andrew Morton]

Ed Tomlinson <[EMAIL PROTECTED]> wrote:
>
> > Don't think so - it works OK here.  Checked the .config?  Does the serial
>  > port work if you do `echo foo > /dev/ttyS0'?  ACPI?
> 
>  Turned out it was some old ups software that got reactivated on the box 
> displaying the
>  console - was a pain to disable it

OK.

>  In any case, when the box reboots there are not any messages.  Any ideas on 
> what debug
>  options to enable or suggestions on how we can figure out the cause of the 
> reboots.

There were a few problems in the task switching area - maybe that.




From: Ingo Molnar <[EMAIL PROTECTED]>

delay the reloading of segment registers into switch_mm(), so that if
the LDT size changes we dont get a (silent) fault and a zeroed selector
register upon reloading.

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 25-akpm/arch/i386/kernel/process.c |   10 +-
 25-akpm/include/asm-i386/mmu_context.h |7 +++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff -puN arch/i386/kernel/process.c~sched-unlocked-context-switches-fix 
arch/i386/kernel/process.c
--- 25/arch/i386/kernel/process.c~sched-unlocked-context-switches-fix   
2005-04-12 03:43:07.254363568 -0700
+++ 25-akpm/arch/i386/kernel/process.c  2005-04-12 03:43:07.259362808 -0700
@@ -653,12 +653,12 @@ struct task_struct fastcall * __switch_t
asm volatile("mov %%gs,%0":"=m" (prev->gs));
 
/*
-* Restore %fs and %gs if needed.
+* Clear selectors if needed:
 */
-   if (unlikely(prev->fs | prev->gs | next->fs | next->gs)) {
-   loadsegment(fs, next->fs);
-   loadsegment(gs, next->gs);
-   }
+if (unlikely((prev->fs | prev->gs) && !(next->fs | next->gs))) {
+loadsegment(fs, next->fs);
+loadsegment(gs, next->gs);
+}
 
/*
 * Now maybe reload the debug registers
diff -puN include/asm-i386/mmu_context.h~sched-unlocked-context-switches-fix 
include/asm-i386/mmu_context.h
--- 25/include/asm-i386/mmu_context.h~sched-unlocked-context-switches-fix   
2005-04-12 03:43:07.256363264 -0700
+++ 25-akpm/include/asm-i386/mmu_context.h  2005-04-12 03:43:07.260362656 
-0700
@@ -61,6 +61,13 @@ static inline void switch_mm(struct mm_s
}
}
 #endif
+   /*
+* Now that we've switched the LDT, load segments:
+*/
+   if (unlikely(current->thread.fs | current->thread.gs)) {
+   loadsegment(fs, current->thread.fs);
+   loadsegment(gs, current->thread.gs);
+   }
 }
 
 #define deactivate_mm(tsk, mm) \
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: CDR read problems with 2.6.11?

[Bradley Reed]

On Thu, 14 Apr 2005 02:03:07 +0200
"Bernd Schubert" <[EMAIL PROTECTED]> wrote:

> I have seen exactly the same on my fathers computer and could solve this
> by not starting the udftools. Didn't have the time to digg further into
> this... 
> Can you confirm thats really a udf problem? Just run
> "/etc/init.d/udftools stop" or the similar for your distribution and try
> mounting again.
> 

I am not running udftools. In fact it isn't even installed (not part of
Slackware 10.1).  I'm trying to burn an iso9660 on a CDR using cdrecord.

There seems to be issues with CD burning under 2.6.11. I make an iso, and I
burn it to CDR with 2.6.11 and again with 2.4.28 on the same laptop/same DVD
+RW drive. The disk burnt under 2.4 is fine, md5sums all ok, can be read
under both kernels. The disk burnt under 2.6.11 burns without error from
cdrecord/k3b/etc, but afterwards is not readable under 2.6.11. It is readable
under 2.4.28, but the md5sums are not 100% correct, basically making 2.6.11
useless for making backups to CDR.

Brad

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2-mm3

[Ed Tomlinson]

On Tuesday 12 April 2005 07:39, Andrew Morton wrote:
> Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> >
> > On Monday 11 April 2005 04:25, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> > > 
> > > 
> > > - The anticipatory I/O scheduler has always been fairly useless with SCSI
> > >   disks which perform tagged command queueing.  There's a patch here from 
> > > Jens
> > >   which is designed to fix that up by constraining the number of requests
> > >   which we'll leave pending in the device.
> > > 
> > >   The depth currently defaults to 1.  Tunable in
> > >   /sys/block/hdX/queue/iosched/queue_depth
> > > 
> > >   This patch hasn't been performance tested at all yet.  If you think it 
> > > is
> > >   misbehaving (the usual symptom is processes stuck in D state) then 
> > > please
> > >   report it, then boot with `elevator=cfq' or `elevator=deadline' to work
> > >   around it.
> > > 
> > > - More CPU scheduler work.  I hope someone is testing this stuff.
> > 
> > Something is not quite right here.  I built rc2-mm3 and booted (uni 
> > processor, amd64, preempt on).  
> > mm3 lasted about 30 mins before locking up with a dead keyboard.  I had mm2 
> > reboot a few times
> > over the last couple of days too.  
> > 
> > 11-mm3 uptime of 2 weeks+
> > 12-rc2-mm2 reboots once every couple of days
> > 12-rc2-mm3 locked up within 30 mins using X using kmail/bogofilter
> 
> Unpleasant.  Serial console would be nice ;)
> 
> > My serial console does not seem to want to work.  Has anything changed with 
> > this support?
> > 
> 
> Don't think so - it works OK here.  Checked the .config?  Does the serial
> port work if you do `echo foo > /dev/ttyS0'?  ACPI?

Turned out it was some old ups software that got reactivated on the box 
displaying the
console - was a pain to disable it

In any case, when the box reboots there are not any messages.  Any ideas on 
what debug
options to enable or suggestions on how we can figure out the cause of the 
reboots.

TIA,
Ed Tomlinson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: more git updates..

[Matt Mackall]

On Thu, Apr 14, 2005 at 01:42:11AM +0200, Krzysztof Halasa wrote:
> Matt Mackall <[EMAIL PROTECTED]> writes:
> 
> > Now if you can assume that blobs never change and are never deleted,
> > you can simply append them all onto a log, and then index them with a
> > separate file containing an htree of (sha1, offset, length) or the
> > like.
> 
> That mean a problem with rsync, though.

I believe 200k inodes is a problem for rsync too. But we can simply
grab the remote htree, do a tree compare, find the ranges of the
remote file we need, sort and merge the ranges, and then pull them.
That will surely trounce rsync.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Fortuna

[Matt Mackall]

On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
> Ahh.  Thanks Herbert.
> 
> Matt,
> 
> Any insight on how to test syn cookies and the other network stuff in
> random.c?  My patch is attached, but I havn't tested that part yet.

For starters, this is not against anything like a current random.c. A
great number of cleanups have been done.

Syncookies are perhaps best tested with printk of the cookie
ingredients in the generation and check steps.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2 6/10] tg3: use new TG3_FLG2_5750_PLUS flag

[John W. Linville]

Replace a number of two-way if statements checking for 5750, and/or
5752 to reference the newly-defined TG3_FLG2_5750_PLUS flag instead.

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---

 drivers/net/tg3.c |   38 +-
 1 files changed, 13 insertions(+), 25 deletions(-)

--- bcm5752-support/drivers/net/tg3.c.orig  2005-04-08 17:57:50.096149244 
-0400
+++ bcm5752-support/drivers/net/tg3.c   2005-04-08 17:57:10.716485067 -0400
@@ -1067,8 +1067,7 @@ static int tg3_set_power_state(struct tg
mac_mode = MAC_MODE_PORT_MODE_TBI;
}
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 &&
-   GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752)
+   if (!(tp->tg3_flags2 & TG3_FLG2_5750_PLUS))
tw32(MAC_LED_CTRL, tp->led_ctrl);
 
if (((power_caps & PCI_PM_CAP_PME_D3cold) &&
@@ -3967,8 +3966,7 @@ static int tg3_chip_reset(struct tg3 *tp
tg3_read_mem(tp, NIC_SRAM_DATA_CFG, &nic_cfg);
if (nic_cfg & NIC_SRAM_DATA_CFG_ASF_ENABLE) {
tp->tg3_flags |= TG3_FLAG_ENABLE_ASF;
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 
||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
+   if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS)
tp->tg3_flags2 |= TG3_FLG2_ASF_NEW_HANDSHAKE;
}
}
@@ -5042,8 +5040,7 @@ static int tg3_reset_hw(struct tg3 *tp)
tw32(GRC_MISC_CFG, val);
 
/* Initialize MBUF/DESC pool. */
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) {
+   if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) {
/* Do nothing.  */
} else if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) {
tw32(BUFMGR_MB_POOL_ADDR, NIC_SRAM_MBUF_POOL_BASE);
@@ -7032,8 +7029,7 @@ static void __devinit tg3_get_nvram_info
tw32(NVRAM_CFG1, nvcfg1);
}
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) {
+   if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) {
switch (nvcfg1 & NVRAM_CFG1_VENDOR_MASK) {
case FLASH_VENDOR_ATMEL_FLASH_BUFFERED:
tp->nvram_jedecnum = JEDEC_ATMEL;
@@ -7098,8 +7094,7 @@ static void __devinit tg3_nvram_init(str
GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701) {
tp->tg3_flags |= TG3_FLAG_NVRAM;
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) {
+   if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) {
u32 nvaccess = tr32(NVRAM_ACCESS);
 
tw32(NVRAM_ACCESS, nvaccess | ACCESS_ENABLE);
@@ -7108,8 +7103,7 @@ static void __devinit tg3_nvram_init(str
tg3_get_nvram_info(tp);
tg3_get_nvram_size(tp);
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) {
+   if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) {
u32 nvaccess = tr32(NVRAM_ACCESS);
 
tw32(NVRAM_ACCESS, nvaccess & ~ACCESS_ENABLE);
@@ -7202,8 +7196,7 @@ static int tg3_nvram_read(struct tg3 *tp
 
tg3_nvram_lock(tp);
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) {
+   if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) {
u32 nvaccess = tr32(NVRAM_ACCESS);
 
tw32_f(NVRAM_ACCESS, nvaccess | ACCESS_ENABLE);
@@ -7218,8 +7211,7 @@ static int tg3_nvram_read(struct tg3 *tp
 
tg3_nvram_unlock(tp);
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) {
+   if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) {
u32 nvaccess = tr32(NVRAM_ACCESS);
 
tw32_f(NVRAM_ACCESS, nvaccess & ~ACCESS_ENABLE);
@@ -7447,8 +7439,7 @@ static int tg3_nvram_write_block(struct 
 
tg3_nvram_lock(tp);
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) {
+   if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) {
u32 nvaccess = tr32(NVRAM_ACCESS);
 
tw32(NVRAM_ACCESS, nvaccess | ACCESS_ENABLE);
@@ -7473,8 +7464,7 @@ static int tg3_nvram_write_block(struct 
grc_mode = tr32(GRC_MODE);
tw32(GRC_MODE, grc_mode & ~GRC_MODE_NVRAM_WR_ENABLE);
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 |

[patch 2.6.12-rc2 1/10] tg3: add basic bcm5752 support

[John W. Linville]

Track-down all references to ASIC_REV_5750 and mirror them with
references to the newly defined ASIC_REV_5752.

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---

 drivers/net/tg3.c |   63 --
 1 files changed, 42 insertions(+), 21 deletions(-)

--- bcm5752-support/drivers/net/tg3.c.orig  2005-04-08 17:28:59.660670261 
-0400
+++ bcm5752-support/drivers/net/tg3.c   2005-04-08 17:29:05.039934450 -0400
@@ -86,7 +86,8 @@
 #define TG3_MIN_MTU60
 #define TG3_MAX_MTU(tp)\
((GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 && \
- GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750) ? 9000 : 1500)
+ GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 && \
+ GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) ? 9000 : 1500)
 
 /* These numbers seem to be hard coded in the NIC firmware somehow.
  * You can't change the ring sizes, but you can change where you place
@@ -861,7 +862,8 @@ out:
/* Cannot do read-modify-write on 5401 */
tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x4c20);
} else if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 &&
-  GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750) {
+  GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 &&
+  GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) {
u32 phy_reg;
 
/* Set bit 14 with read-modify-write to preserve other bits */
@@ -874,7 +876,8 @@ out:
 * jumbo frames transmission.
 */
if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 &&
-   GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750) {
+   GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 &&
+   GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) {
u32 phy_reg;
 
if (!tg3_readphy(tp, MII_TG3_EXT_CTRL, &phy_reg))
@@ -1068,7 +1071,8 @@ static int tg3_set_power_state(struct tg
mac_mode = MAC_MODE_PORT_MODE_TBI;
}
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750)
+   if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 &&
+   GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752)
tw32(MAC_LED_CTRL, tp->led_ctrl);
 
if (((power_caps & PCI_PM_CAP_PME_D3cold) &&
@@ -3967,7 +3971,8 @@ static int tg3_chip_reset(struct tg3 *tp
tg3_read_mem(tp, NIC_SRAM_DATA_CFG, &nic_cfg);
if (nic_cfg & NIC_SRAM_DATA_CFG_ASF_ENABLE) {
tp->tg3_flags |= TG3_FLAG_ENABLE_ASF;
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750)
+   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 
||
+   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
tp->tg3_flags2 |= TG3_FLG2_ASF_NEW_HANDSHAKE;
}
}
@@ -5041,7 +5046,8 @@ static int tg3_reset_hw(struct tg3 *tp)
tw32(GRC_MISC_CFG, val);
 
/* Initialize MBUF/DESC pool. */
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) {
+   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
+   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) {
/* Do nothing.  */
} else if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) {
tw32(BUFMGR_MB_POOL_ADDR, NIC_SRAM_MBUF_POOL_BASE);
@@ -5240,7 +5246,8 @@ static int tg3_reset_hw(struct tg3 *tp)
rdmac_mode |= RDMAC_MODE_SPLIT_ENABLE;
if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 &&
 tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) ||
-   (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750)) {
+   (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
+GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)) {
if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE &&
(tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 ||
 tp->pci_chip_rev_id == CHIPREV_ID_5705_A2)) {
@@ -5355,7 +5362,8 @@ static int tg3_reset_hw(struct tg3 *tp)
 
if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 &&
 tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) {
+   (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
+GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)) {
if ((tp->tg3_flags & TG3_FLG2_TSO_CAPABLE) &&
(tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 ||
 tp->pci_chip_rev_id == CHIPREV_ID_5705_A2)) {
@@ -7028,7 +7036,8 @@ static void __devinit tg3_get_nvram_info
tw32(NVRAM_CFG1, nvcfg1);
}
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) {
+   if (GET_ASIC_REV(tp->

[patch 2.6.12-rc2 7/10] tg3: more use of TG3_FLG2_5705_PLUS flag

[John W. Linville]

Rewrite of a couple of troublesome multi-way if statements to use
TG3_FLG2_5705_PLUS flag.

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---

 drivers/net/tg3.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

--- bcm5752-support/drivers/net/tg3.c.orig  2005-04-08 18:00:31.886220435 
-0400
+++ bcm5752-support/drivers/net/tg3.c   2005-04-08 18:08:55.969298725 -0400
@@ -5237,10 +5237,8 @@ static int tg3_reset_hw(struct tg3 *tp)
  RDMAC_MODE_LNGREAD_ENAB);
if (tp->tg3_flags & TG3_FLAG_SPLIT_MODE)
rdmac_mode |= RDMAC_MODE_SPLIT_ENABLE;
-   if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 &&
-tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) ||
-   (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)) {
+   if ((tp->tg3_flags2 & TG3_FLG2_5705_PLUS) &&
+tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) {
if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE &&
(tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 ||
 tp->pci_chip_rev_id == CHIPREV_ID_5705_A2)) {
@@ -5353,10 +5351,8 @@ static int tg3_reset_hw(struct tg3 *tp)
   WDMAC_MODE_FIFOURUN_ENAB | WDMAC_MODE_FIFOOREAD_ENAB |
   WDMAC_MODE_LNGREAD_ENAB);
 
-   if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 &&
-tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) ||
-   (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)) {
+   if ((tp->tg3_flags2 & TG3_FLG2_5705_PLUS) &&
+tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) {
if ((tp->tg3_flags & TG3_FLG2_TSO_CAPABLE) &&
(tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 ||
 tp->pci_chip_rev_id == CHIPREV_ID_5705_A2)) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: CDR read problems with 2.6.11?

[Bernd Schubert]

[...]
> 
> [EMAIL PROTECTED]:~[1009]# mount /mnt/cdrom
> mount: wrong fs type, bad option, bad superblock on /dev/cdrom,
>missing codepage or other error
>In some cases useful info is found in syslog - try
>dmesg | tail  or so
>

[...]

> The drive is a NEC DVD+RW ND-5100A
> 
> Any suggestions on why I can't read (or burn correctly) the disks with 2.6.11?
>

I have seen exactly the same on my fathers computer and could solve this
by not starting the udftools. Didn't have the time to digg further into
this... 
Can you confirm thats really a udf problem? Just run
"/etc/init.d/udftools stop" or the similar for your distribution and try
mounting again.

Cheers,
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2 3/10] tg3: add bcm5752 entry to pci_ids.h

[John W. Linville]

Add proper entry for bcm5752 PCI ID to pci_ids.h, and use it in tg3.

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
I did this separately in case patches like this (i.e. new PCI IDs)
need to come from more "official" sources.

 drivers/net/tg3.c   |2 +-
 include/linux/pci_ids.h |1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

--- bcm5752-support/drivers/net/tg3.c.orig  2005-04-08 17:35:34.834372048 
-0400
+++ bcm5752-support/drivers/net/tg3.c   2005-04-08 17:34:42.536563710 -0400
@@ -206,7 +206,7 @@ static struct pci_device_id tg3_pci_tbl[
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5751F,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
-   { PCI_VENDOR_ID_BROADCOM, 0x1600, /* TIGON3_5752 */
+   { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5752,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5753,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
--- bcm5752-support/include/linux/pci_ids.h.orig2005-04-08 
17:30:45.655140363 -0400
+++ bcm5752-support/include/linux/pci_ids.h 2005-04-08 17:31:52.965883217 
-0400
@@ -2065,6 +2065,7 @@
 #define PCI_DEVICE_ID_AFAVLAB_P030 0x2182
 
 #define PCI_VENDOR_ID_BROADCOM 0x14e4
+#define PCI_DEVICE_ID_TIGON3_5752  0x1600
 #define PCI_DEVICE_ID_TIGON3_5700  0x1644
 #define PCI_DEVICE_ID_TIGON3_5701  0x1645
 #define PCI_DEVICE_ID_TIGON3_5702  0x1646
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2 8/10] tg3: use TG3_FLG2_57{05,50}_PLUS flags in tg3_get_invariants

[John W. Linville]

Rewrite checks in tg3_get_invariants to use TG3_FLG2_5705_PLUS and
TG3_FLG2_5750_PLUS flags.

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---

 drivers/net/tg3.c |7 ++-
 1 files changed, 2 insertions(+), 5 deletions(-)

--- bcm5752-support/drivers/net/tg3.c.orig  2005-04-08 18:11:46.207874683 
-0400
+++ bcm5752-support/drivers/net/tg3.c   2005-04-08 18:11:36.696183379 -0400
@@ -7937,8 +7937,7 @@ static int __devinit tg3_get_invariants(
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
tp->tg3_flags2 |= TG3_FLG2_5750_PLUS;
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
+   if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS)
tp->tg3_flags2 |= TG3_FLG2_HW_TSO;
 
if (pci_find_capability(tp->pdev, PCI_CAP_ID_EXP) != 0)
@@ -8068,9 +8067,7 @@ static int __devinit tg3_get_invariants(
if (tp->pci_chip_rev_id == CHIPREV_ID_5704_A0)
tp->tg3_flags2 |= TG3_FLG2_PHY_5704_A0_BUG;
 
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
+   if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)
tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG;
 
/* Only 5701 and later support tagged irq status mode.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2 10/10] tg3: add support for bcm5752 rev a1

[John W. Linville]

Replace existing ASIC_REV_5752 definition with ASIC_REV_5752_A0,
and add definition for ASIC_REV_5752_A1. Then, add ASIC_REV_5752_A1
to check for setting TG3_FLG2_5750_PLUS in tg3_get_invariants.

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---

 drivers/net/tg3.c |3 ++-
 drivers/net/tg3.h |5 -
 2 files changed, 6 insertions(+), 2 deletions(-)

--- bcm5752-support/drivers/net/tg3.c.orig  2005-04-12 14:19:06.302429500 
-0400
+++ bcm5752-support/drivers/net/tg3.c   2005-04-12 14:17:50.963846711 -0400
@@ -7929,7 +7929,8 @@ static int __devinit tg3_get_invariants(
tp->pci_bist = (cacheline_sz_reg >> 24) & 0xff;
 
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
+   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752_A0 ||
+   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752_A1)
tp->tg3_flags2 |= TG3_FLG2_5750_PLUS;
 
if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) ||
--- bcm5752-support/drivers/net/tg3.h.orig  2005-04-12 14:19:06.288431435 
-0400
+++ bcm5752-support/drivers/net/tg3.h   2005-04-12 14:17:50.981844223 -0400
@@ -125,6 +125,8 @@
 #define  CHIPREV_ID_5750_A0 0x4000
 #define  CHIPREV_ID_5750_A1 0x4001
 #define  CHIPREV_ID_5750_A3 0x4003
+#define  CHIPREV_ID_5752_A0 0x5000
+#define  CHIPREV_ID_5752_A1 0x6001
 #define  GET_ASIC_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 12)
 #define   ASIC_REV_5700 0x07
 #define   ASIC_REV_5701 0x00
@@ -132,7 +134,8 @@
 #define   ASIC_REV_5704 0x02
 #define   ASIC_REV_5705 0x03
 #define   ASIC_REV_5750 0x04
-#define   ASIC_REV_5752 0x05
+#define   ASIC_REV_5752_A0  0x05
+#define   ASIC_REV_5752_A1  0x06
 #define  GET_CHIP_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 8)
 #define   CHIPREV_5700_AX   0x70
 #define   CHIPREV_5700_BX   0x71
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 encrypted swsusp 1/3] core functionality

[Pavel Machek]

On Ät 14-04-05 09:39:04, Herbert Xu wrote:
> On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
> >
> > > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > > When the swap runs over dmcrypt all writes including those from
> > > swsusp are encrypted.
> > 
> > Andreas is right. They are encrypted in swap, but they should not be
> > there at all. And they are encrypted by key that is still available
> > after resume. Bad.
> 
> The dmcrypt swap can only be unlocked by the user with a passphrase,
> which is analogous to how you unlock your ssh private key stored
> on the disk using a passphrase.

Once more:

Andreas' implementation destroys the key during resume.

dm-crypt does not even know resume happened, so it can't destroy
key. (And it would also render system useless).

Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2 2/10] tg3: add bcm5752 to tg3_pci_tbl

[John W. Linville]

Add hard-coded definition of bcm5752 PCI ID to tg3_pci_tbl.

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
Next patch will change entry to use pci_ids.h-based definition.

 drivers/net/tg3.c |2 ++
 1 files changed, 2 insertions(+)

--- bcm5752-support/drivers/net/tg3.c.orig  2005-04-08 17:30:08.886197282 
-0400
+++ bcm5752-support/drivers/net/tg3.c   2005-04-08 17:30:17.113065813 -0400
@@ -206,6 +206,8 @@ static struct pci_device_id tg3_pci_tbl[
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5751F,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
+   { PCI_VENDOR_ID_BROADCOM, 0x1600, /* TIGON3_5752 */
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5753,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5753M,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2 5/10] tg3: define TG3_FLG2_5750_PLUS flag

[John W. Linville]

Define TG3_FLG2_5750_PLUS flag and set it in tg3_get_invariants for
ASIC_REV_5750 or ASIC_REV_5752.

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---

 drivers/net/tg3.c |4 
 drivers/net/tg3.h |1 +
 2 files changed, 5 insertions(+)

--- bcm5752-support/drivers/net/tg3.c.orig  2005-04-08 17:47:31.186930125 
-0400
+++ bcm5752-support/drivers/net/tg3.c   2005-04-08 17:47:16.409928291 -0400
@@ -7951,6 +7951,10 @@ static int __devinit tg3_get_invariants(
 
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
+   tp->tg3_flags2 |= TG3_FLG2_5750_PLUS;
+
+   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
+   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
tp->tg3_flags2 |= TG3_FLG2_HW_TSO;
 
if (pci_find_capability(tp->pdev, PCI_CAP_ID_EXP) != 0)
--- bcm5752-support/drivers/net/tg3.h.orig  2005-04-08 17:47:35.536341972 
-0400
+++ bcm5752-support/drivers/net/tg3.h   2005-04-08 17:44:48.578234813 -0400
@@ -2101,6 +2101,7 @@ struct tg3 {
 #define TG3_FLG2_HW_TSO0x0001
 #define TG3_FLG2_SERDES_PREEMPHASIS0x0002
 #define TG3_FLG2_5705_PLUS 0x0004
+#define TG3_FLG2_5750_PLUS 0x0008
 
u32 split_mode_max_reqs;
 #define SPLIT_MODE_5704_MAX_REQ3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2 0/10] add bcm5752 support plus some cleanup to tg3

[John W. Linville]

Add support to tg3 for bcm5752 hardware.  Also clean-up a lot
of multi-way if statements and replace them with checks of flags
representing classes of tg3 hardware.

Patches to follow...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2 9/10] tg3: check TG3_FLG2_5750_PLUS flag to set TG3_FLG2_5705_PLUS flag

[John W. Linville]

Use check of TG3_FLG2_5750_PLUS in tg3_get_invariants to set
TG3_FLG2_5705_PLUS flag.

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---

 drivers/net/tg3.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

--- bcm5752-support/drivers/net/tg3.c.orig  2005-04-08 18:13:24.632333096 
-0400
+++ bcm5752-support/drivers/net/tg3.c   2005-04-08 18:13:19.559031079 -0400
@@ -7928,15 +7928,14 @@ static int __devinit tg3_get_invariants(
tp->pci_hdr_type = (cacheline_sz_reg >> 16) & 0xff;
tp->pci_bist = (cacheline_sz_reg >> 24) & 0xff;
 
-   if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) ||
-   (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) ||
-   (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752))
-   tp->tg3_flags2 |= TG3_FLG2_5705_PLUS;
-
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
tp->tg3_flags2 |= TG3_FLG2_5750_PLUS;
 
+   if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) ||
+   (tp->tg3_flags2 & TG3_FLG2_5750_PLUS))
+   tp->tg3_flags2 |= TG3_FLG2_5705_PLUS;
+
if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS)
tp->tg3_flags2 |= TG3_FLG2_HW_TSO;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2 4/10] tg3: use TG3_FLG2_5705_PLUS instead of multi-way if's

[John W. Linville]

Replace a number of three-way if statements checking for 5705, 5750,
and 5752 to reference the equivalent TG3_FLG2_5705_PLUS flag instead.

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---

 drivers/net/tg3.c |   16 
 1 files changed, 4 insertions(+), 12 deletions(-)

--- bcm5752-support/drivers/net/tg3.c.orig  2005-04-08 17:42:28.059553796 
-0400
+++ bcm5752-support/drivers/net/tg3.c   2005-04-08 17:42:16.584131525 -0400
@@ -85,9 +85,7 @@
 /* hardware minimum and maximum for a single frame's data payload */
 #define TG3_MIN_MTU60
 #define TG3_MAX_MTU(tp)\
-   ((GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 && \
- GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 && \
- GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) ? 9000 : 1500)
+   (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS) ? 9000 : 1500)
 
 /* These numbers seem to be hard coded in the NIC firmware somehow.
  * You can't change the ring sizes, but you can change where you place
@@ -863,9 +861,7 @@ out:
if ((tp->phy_id & PHY_ID_MASK) == PHY_ID_BCM5401) {
/* Cannot do read-modify-write on 5401 */
tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x4c20);
-   } else if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 &&
-  GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 &&
-  GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) {
+   } else if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) {
u32 phy_reg;
 
/* Set bit 14 with read-modify-write to preserve other bits */
@@ -877,9 +873,7 @@ out:
/* Set phy register 0x10 bit 0 to high fifo elasticity to support
 * jumbo frames transmission.
 */
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 &&
-   GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 &&
-   GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) {
+   if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) {
u32 phy_reg;
 
if (!tg3_readphy(tp, MII_TG3_EXT_CTRL, &phy_reg))
@@ -8483,9 +8477,7 @@ static int __devinit tg3_test_dma(struct
/* DMA read watermark not used on PCIE */
tp->dma_rwctrl |= 0x0018;
} else if (!(tp->tg3_flags & TG3_FLAG_PCIX_MODE)) {
-   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
-   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
+   if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)
tp->dma_rwctrl |= 0x003f;
else
tp->dma_rwctrl |= 0x003f000f;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: more git updates..

[Krzysztof Halasa]

Matt Mackall <[EMAIL PROTECTED]> writes:

> Now if you can assume that blobs never change and are never deleted,
> you can simply append them all onto a log, and then index them with a
> separate file containing an htree of (sha1, offset, length) or the
> like.

That mean a problem with rsync, though.

BTW: I think the bandwidth increase compared to bkcvs isn't that obvious.
After a file is modified with git, it has to be transmitted (plus
small additional things.
If a file is modified with bkcvs, it has to be transmitted (the whole
RCS file) as well.

Only the initial rsync would be much smaller with bkcvs.
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 encrypted swsusp 1/3] core functionality

[Herbert Xu]

On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
>
> > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > When the swap runs over dmcrypt all writes including those from
> > swsusp are encrypted.
> 
> Andreas is right. They are encrypted in swap, but they should not be
> there at all. And they are encrypted by key that is still available
> after resume. Bad.

The dmcrypt swap can only be unlocked by the user with a passphrase,
which is analogous to how you unlock your ssh private key stored
on the disk using a passphrase.

So I don't see the problem.

> First version simply overwrote suspend image in swap with zeros. This
> is more clever way to do same thing.

This version looks to me like a custom implementation of dmcrypt that
lives inside swsusp which ends up being either less secure than simply
using dmcrypt due to the lack of a passphrase, or it's going to involve
more hacks to get a passphrase from the user at resume time.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

CDR read problems with 2.6.11?

[Bradley Reed]

I am running 2.6.11 with -ac4 and
realtime-preempt-2.6.11-final-V0.7.40-00 patches. Up to now, no
complaints, great job everyone.

Today I burnt two data backup CDs onto CD-R (I used k3b if it
matters) and the burn went 100% fine. No errors, I can read the
disks on other computers or on this one if I reboot into a different
kernel (2.4.28 for instance). Unfortunately I cannot read them from
the kernel I burned them with. [1]

mount yields:

[EMAIL PROTECTED]:~[1009]# mount /mnt/cdrom
mount: wrong fs type, bad option, bad superblock on /dev/cdrom,
   missing codepage or other error
   In some cases useful info is found in syslog - try
   dmesg | tail  or so
   
dmesg shows:

hda: irq timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ATAPI reset complete
hda: irq timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: ATAPI reset complete
hda: tray open
end_request: I/O error, dev hda, sector 64
isofs_fill_super: bread failed, dev=hda, iso_blknum=16, block=16
hda: irq timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: ATAPI reset complete

Obviously the tray is NOT open, but the other errors don't mean much
to me.

The drive is a NEC DVD+RW ND-5100A

Any suggestions on why I can't read (or burn correctly) the disks with 2.6.11?

Brad

[1] Actually although they mount and I can ls them under 2.4.28, not all the
files seem to be complete. The last few tarballs seem to be incomplete.
Earlier ones in the ls listing seem fine. Strange.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 encrypted swsusp 1/3] core functionality

[Pavel Machek]

On Ät 14-04-05 09:10:44, Herbert Xu wrote:
> On Thu, Apr 14, 2005 at 12:29:36AM +0200, Andreas Steinmetz wrote:
> >
> > > Why is that? In the case of swap over dmcrypt, swsusp never reads/writes
> > > the disk directly.  All operations are done through dmcrypt.
> > > 
> > > The user has to enter a password before the system can be resumed.
> > 
> > Think of it the following way: user suspend and later resumes. During
> > suspend some mlocked memory e.g. from ssh-agent gets dumped to swap.
> > Some days later the system gets broken in from a remote place.
> > Unfortunately the ssh keys are still on swap (assuming that ssh-agent is
> > not running then) and can be recovered by the intruder. The intruder can
> 
> The ssh keys are *encrypted* in the swap when dmcrypt is used.
> When the swap runs over dmcrypt all writes including those from
> swsusp are encrypted.

Andreas is right. They are encrypted in swap, but they should not be
there at all. And they are encrypted by key that is still available
after resume. Bad.

First version simply overwrote suspend image in swap with zeros. This
is more clever way to do same thing.

Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.6.11] Take control of PCI Master Abort Mode

[Dave Jones]

On Wed, Apr 13, 2005 at 07:00:06PM -0400, Ross Biro wrote:

 > > If you take a look at quirks.c and DMI options you will see we have quite 
 > > a lot
 > > of workarounds for various hardware bug. Just imagine there were
 > > CONFIG options for all of this. It would be a big mess!
 > 
 >  The config option is for distro maintainers to use to set a policy
 > for their particular distribution.  The boot line option is for end
 > users to adjust it.  Last I heard, most distro makers compile their
 > own kernels and select options appropriately.  I really don't think
 > it's too much to ask an end user to adjust their grub.conf or
 > lilo.conf file to work around a bug in their hardware, especially
 > since their is *no way* to work around the bug in all cases with out
 > user intervention.

The thing is, most users won't have a clue about this option,
and that is a good thing. They just want stuff to work, not have
to poke random bits and pieces.

 > As I said before, the quirks routines cannot handle it since there is
 > no way to know what the correct setting is unless you know what
 > application is going to be run and what the users tolerance to
 > particular problems is.  In a perfect world, master abort mode would
 > always be set to on, but that is not practical in the real world.  If
 > you are suggesting that something in the quirks file stop the boot and
 > ask the user some questions about how they intend to use the system
 > and what their tolerance for certain types of errors is, then I think
 > you are suggesting an even bigger mess.

You don't need to ask the user anything (they won't know the answers anyway)
You already mentioned that E1000's cause this problem, so you have the
basis for the beginning of a blacklist.  A patch to explicitly enable
this feature in -mm for a while will probably shake out most of the
common problematic hardware pretty quickly.

 > Someone creating a dstro for enterprise use would most likely compile
 > the kernel with master abort mode enabled to prevent silent data loss.
 >  Someone building the system for desktop use would choose either
 > default or disabled, to prevent spurious error messages, or hardware
 > lock ups. 

So its ok for enterprise use to spew error msgs and have hardware lockups ?
See the problem with setting it either on/off ? We need to take
additional factors into consideration, or we're left with something
thats essentially useless.
 
 > If users report problems that look like they are caused by
 > the master abort mode setting, a tech support person could easily ask
 > the end user to add a boot time command line option to see if the
 > problem goes away.  The end user would then have the *option* of
 > adjusting the config file, or just using the boot time option.

A lock-up could be caused by any number of problems, and I'll put money
on even the best support guys not knowing about this option 6 months
after it got merged. Obscure toggles for esoteric features like this
get forgotten about quickly. It's more likely the support bod would
chase down other avenues before ever hitting upon this.

 > I would aggree with you if it were not for the fact that the correct
 > setting of this bit is really a judgement call, so it must be simple
 > for anyone who needs to make the call to be able to.  The people
 > building distors will need to be able change the default setting
 > easily at compile time and the end user needs to be able to change the
 > setting at boot time or run time.

As someone who builds distro kernels I disagree.
End users need things to 'just work'. 99% of end-users don't know, or care
about quirks in their hardware.  If we start expecting the bulk of
them to have to go editing their grub/lilo/etc configs, we've lost.

 > Someone on the PCI mailing list has suggested that it is enough to let
 > the distro maintainer edit the header file and adjust the setting
 > there.  To do so would mean that many distro maintainers would have to
 > maintain an additional patch for very little reason.  Perhaps the
 > correct solution is to keep it as a config option and add a
 > CONFIG_OBSCURE so that most people don't ever see option, but the few
 > that need to can.

If we have a situation where we screw a subset of users with the
config option =y and a different subset with =n, how is this improving
the situation any over what we have today ?

Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][TRIVIAL][DOCUMENTATION] - Version clarification - support status of 3com OfficeConnect card

[Daniel Andersen]

Version 2 of the 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 is
not supported by the prism54 project. To stop confusion, the kernel
documentation should state so as 3com made a good job hiding the version
difference.
Daniel Andersen
--
--- linux/drivers/net/wireless/Kconfig.orig2005-04-14 
00:55:45.0 +0200
+++ linux/drivers/net/wireless/Kconfig2005-04-14 00:56:14.0 
+0200
@@ -323,7 +323,7 @@ config PRISM54
  For a complete list of supported cards visit .
  Here is the latest confirmed list of supported cards:

-  3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72
+  3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 (version 1)
  Allnet ALL0271 PCI Card
  Compex WL54G Cardbus Card
  Corega CG-WLCB54GT Cardbus Card
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 encrypted swsusp 1/3] core functionality

[Herbert Xu]

On Thu, Apr 14, 2005 at 12:29:36AM +0200, Andreas Steinmetz wrote:
>
> > Why is that? In the case of swap over dmcrypt, swsusp never reads/writes
> > the disk directly.  All operations are done through dmcrypt.
> > 
> > The user has to enter a password before the system can be resumed.
> 
> Think of it the following way: user suspend and later resumes. During
> suspend some mlocked memory e.g. from ssh-agent gets dumped to swap.
> Some days later the system gets broken in from a remote place.
> Unfortunately the ssh keys are still on swap (assuming that ssh-agent is
> not running then) and can be recovered by the intruder. The intruder can

The ssh keys are *encrypted* in the swap when dmcrypt is used.
When the swap runs over dmcrypt all writes including those from
swsusp are encrypted.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2-mm3] serial: update NEC VR4100 series serial support

[Yoichi Yuasa]

On Wed, 13 Apr 2005 16:02:48 +0100
Russell King <[EMAIL PROTECTED]> wrote:

> On Wed, Apr 13, 2005 at 11:18:27PM +0900, Yoichi Yuasa wrote:
> >  static struct uart_ops early_uart_ops = {
> > -   .set_termios= early_set_termios,
> > +   .set_termios= siu_set_termios,
> >  };
> 
> In this case, you don't need the early_uart_ops here - the standard
> ones will do just as well.  (.set_termios is the only method which
> the console init code will use.)

First, I tested the standerd ops. kernel was crashed.
Now, I'm using early_uart_ops.

I'll test again with standerd ops.

Thanks,

Yoichi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sched: fix active load balance

[Nick Piggin]

Siddha, Suresh B wrote:
On Wed, Apr 13, 2005 at 10:08:28PM +0200, Ingo Molnar wrote:
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:

-   for_each_domain(target_cpu, sd) {
+   for_each_domain(target_cpu, sd)
if ((sd->flags & SD_LOAD_BALANCE) &&
-   cpu_isset(busiest_cpu, sd->span)) {
-   sd = tmp;
+   cpu_isset(busiest_cpu, sd->span))
break;
-   }
-   }

Yep that was broken :(
Thanks for picking that up Suresh.
hm, the right fix i think is to do:
for_each_domain(target_cpu, tmp) {
if ((tmp->flags & SD_LOAD_BALANCE) &&
cpu_isset(busiest_cpu, tmp->span)) {
sd = tmp;
break;
}
}

Your suggestion also looks similar to my patch. You are also breaking on the 
first one.


because when balancing we want to match the widest-scope domain, not the 
first one.

We want the first domain spanning both the cpu's. That is the domain where
normal load balance failed and we restore to active load balance.
Yes, that's right.
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

[Ross Biro]

On 13 Apr 2005 20:37:25 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> \>
> > You're argument that no one can make sense of such options is totally off
> > base. Once you are having a problem, it's pretty easy to see if it's related
> 
> I dont think it is in any way help to put suche highly obscure
> things into Config. Near nobody can make any sense of it.
> 
> If you take a look at quirks.c and DMI options you will see we have quite a 
> lot
> of workarounds for various hardware bug. Just imagine there were
> CONFIG options for all of this. It would be a big mess!

 The config option is for distro maintainers to use to set a policy
for their particular distribution.  The boot line option is for end
users to adjust it.  Last I heard, most distro makers compile their
own kernels and select options appropriately.  I really don't think
it's too much to ask an end user to adjust their grub.conf or
lilo.conf file to work around a bug in their hardware, especially
since their is *no way* to work around the bug in all cases with out
user intervention.

As I said before, the quirks routines cannot handle it since there is
no way to know what the correct setting is unless you know what
application is going to be run and what the users tolerance to
particular problems is.  In a perfect world, master abort mode would
always be set to on, but that is not practical in the real world.  If
you are suggesting that something in the quirks file stop the boot and
ask the user some questions about how they intend to use the system
and what their tolerance for certain types of errors is, then I think
you are suggesting an even bigger mess.

Someone creating a dstro for enterprise use would most likely compile
the kernel with master abort mode enabled to prevent silent data loss.
 Someone building the system for desktop use would choose either
default or disabled, to prevent spurious error messages, or hardware
lock ups.  If users report problems that look like they are caused by
the master abort mode setting, a tech support person could easily ask
the end user to add a boot time command line option to see if the
problem goes away.  The end user would then have the *option* of
adjusting the config file, or just using the boot time option.

I would aggree with you if it were not for the fact that the correct
setting of this bit is really a judgement call, so it must be simple
for anyone who needs to make the call to be able to.  The people
building distors will need to be able change the default setting
easily at compile time and the end user needs to be able to change the
setting at boot time or run time.

Someone on the PCI mailing list has suggested that it is enough to let
the distro maintainer edit the header file and adjust the setting
there.  To do so would mean that many distro maintainers would have to
maintain an additional patch for very little reason.  Perhaps the
correct solution is to keep it as a config option and add a
CONFIG_OBSCURE so that most people don't ever see option, but the few
that need to can.

Ross
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Maintainers list update: linux-net -> netdev

[George Anzinger]

Horms wrote:
On Tue, Apr 12, 2005 at 12:14:56PM -0700, George Anzinger wrote:
Horms wrote:
Use netdev as the mailing list contact instead of the mostly dead
linux-net list.
~
PHRAM MTD DRIVER
@@ -1795,7 +1795,7 @@
POSIX CLOCKS and TIMERS
P:  George Anzinger
M:  george@mvista.com
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
S:  Supported
I don't really know about the rest of them, but I think this should be:
L: linux-kernel@vger.kernel.org
Least wise that is where I look...

Yes, I was wondering about that one. Here is a patch that
adds to my previous patch. Trivial to say the least. 
I can re-diff the whole thing if that is more convenient.
Looks good to me.

--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2)

[Peter Baumann]

On Wed, Apr 13, 2005 at 09:24:04PM +0200, Daniel Ritz wrote:
> On Tuesday 12 April 2005 11:09, Andrew Morton wrote:
> > Peter Baumann <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote:
> > > > Peter Baumann <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > 
> > > > > I'm hitting an annoying bug in kernel 2.6.11.5
> > > > > 
> > > > > Every time I _reboot_ (warmstart) my pc my two network cards won't get
> > > > > recognized any longer.
> > > > >
> > > > > Following error message appears on my screen:
> > > > >
> > > > > PCI: Enabling device :00:0b.0 ( -> 0003)
> > > > > ACPI: PCI interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
> > > > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> > > > > :00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers 
> > > > > LK1.1.19
> > > > > PCI: Setting latency timer of device :00:0b.0 to 64
> > > > > *** EEPROM MAC address is invalid.
> > > > > 3c59x: vortex_probe1 fails.  Returns -22
> > > > > 3c59x: probe of :00:0b.0 failed with error -22
> > > > > PCI: Enabling device :00:0d.0 ( -> 0003)
> > > > > ACPI: PCI interrupt :00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19
> > > > > :00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers 
> > > > > LK1.1.19
> > > > > PCI: Setting latency timer of device :00:0d.0 to 64
> > > > > *** EEPROM MAC address is invalid.
> > > > > 3c59x: vortex_probe1 fails.  Returns -22
> > > > > 3c59x: probe of :00:0d.0 failed with error -22
> > > > >
> > > > > This doesn't happen with older kernels (especially with 2.6.10) and so
> > > > > I've done a binary search and narrowed it down to 2.6.11-rc5 where it
> > > > > first hits me.
> > > > >
> > > > > My config, lspci output and the dmesg output of the working and 
> > > > > non-working
> > > > > version can be found at [1]
> > > > >
> > > > > Feel free to ask if any information is missing or if I am supposed to 
> > > > > try
> > > > > a patch.
> > > >
> > > > Thanks for doing the bsearch - it helps.
> > > >
> > > > There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5.
> > > >
> > > > The only PCI change I see is
> > > >
> > > > --- drivers/pci/pci.c   22 Jan 2005 03:20:37 -  1.71
> > > > +++ drivers/pci/pci.c   24 Feb 2005 18:02:37 -  1.72
> > > > @@ -268,7 +268,7 @@
> > > > return -EIO;
> > > >
> > > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc);
> > > > -   if ((pmc & PCI_PM_CAP_VER_MASK) != 2) {
> > > > +   if ((pmc & PCI_PM_CAP_VER_MASK) > 2) {
> > > > printk(KERN_DEBUG
> > > >"PCI: %s has unsupported PM cap regs version 
> > > > (%u)\n",
> > > >dev->slot_name, pmc & PCI_PM_CAP_VER_MASK);
> > > >
> > > > and you're not getting that message (are you?)
> > > >
> > > 
> > > I have still the problem described above with 2.6.12-rc2-mm2 and
> > > reverting the above patch solved it. And yes, now I get many of those
> > > 
> > > PCI: :00:0b.0 has unsupported PM cap regs version (1)
> > > PCI: :00:0d.0 has unsupported PM cap regs version (1)
> > > PCI: :00:09.0 has unsupported PM cap regs version (1)
> > > 
> > > messages.
> > > 
> > 
> > Yes, we need to work out what's going on here.
> > 
> > Daniel?
> 
> yes. i already posted a debugging patch and asked to have to dmesg output.
> but no response. Message-Id: <[EMAIL PROTECTED]>
> 
> i see two possibilities:
> - it's not really writing to the PM registers but somewhere else (or it's
>   writing some crap)
> - the device hates when somebody writes the current state again
>   (yes, there is a check for this but it's useless during boot). i have
>   a patch for this but i didn't send it until now because i really like
>   to see the debugging output first...attached anyway...
> 
> rgds
> -daniel
> 
> --
> 
> [PATCH] PCI PM: read initial state from device
> 
> the PCI PM code tries not to write to the PM registers when there is no change
> in state. this however fails when a device is initially set up. and because
> some devices are broken they hate being forced to the state they are in. fix
> it by reading the current state from the device itself. also does some other
> things:
> - support PCI PM CAP version 3 (as defined in PCI PM Interface Spec v1.2)
> - add and export the function pci_get_power_state() to get it from the device
> - pci.h defines "4" as D3cold while probe.c uses it for unknown state
> - minor cleanups
> 

[patch snipped]

I tried your patch with 2.6.12-rc2-mm3 (did not apply cleanly, I have
applied one hunk per hand) and here is a diff of the dmesg of a
working/non-working version. If I should try something else, then tell
me and I will do.

The full dmesg output can be obtained from

http://wwwcip.informatik.uni-erlangen.de/~siprbaum/kernel/2.6.12-rc2-mm3_firstboot.txt
http://wwwcip.informatik.uni-erlangen.de/~siprbaum/kernel/2.6.12-rc2-mm3_secondboot.txt

Re: [PATCH encrypted swsusp 1/3] core functionality

[Andreas Steinmetz]

Herbert Xu wrote:
> On Wed, Apr 13, 2005 at 02:59:28PM +0200, Andreas Steinmetz wrote:
> 
>>Herbert Xu wrote:
>>
>>>What's wrong with using swap over dmcrypt + initramfs? People have
>>>already used that to do encrypted swsusp.
>>
>>Nothing. The problem is the fact that after resume there is then
>>unencrypted(*) data on disk that should never have been there, e.g.
>>dm-crypt keys, ssh keys, ...
> 
> 
> Why is that? In the case of swap over dmcrypt, swsusp never reads/writes
> the disk directly.  All operations are done through dmcrypt.
> 
> The user has to enter a password before the system can be resumed.

Think of it the following way: user suspend and later resumes. During
suspend some mlocked memory e.g. from ssh-agent gets dumped to swap.
Some days later the system gets broken in from a remote place.
Unfortunately the ssh keys are still on swap (assuming that ssh-agent is
not running then) and can be recovered by the intruder. The intruder can
then gain access to other sites with the data recovered from the earlier
suspend.

You see, it is not a matter of having encrypted swap, what matters here
is what suspend needs to write to swap and this can be stuff that does
not belong there so it needs to be erased after resume. And the easiest
way to do this is to encrypt the suspend image with a temporary key that
gets cleared on resume.

If you don't resume mkswap will also clear the key though i have to
admit that there's a small window then in which the key and data are
still accessible.
-- 
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] PC300 pci_enable_device fix

[Ashok Raj]

On Wed, Apr 13, 2005 at 02:31:43PM -0700, Bjorn Helgaas wrote:
> 
>Call pci_enable_device() before looking at IRQ and resources.
>The driver requires this fix or the "pci=routeirq" workaround
>on 2.6.10 and later kernels.


the failure cases dont seem to worry about pci_disable_device()?

in err_release_ram: etc?

> 
>Reported and tested by Artur Lipowski.
> 
>Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
> 
>= drivers/net/wan/pc300_drv.c 1.24 vs edited =
>--- 1.24/drivers/net/wan/pc300_drv.c2004-12-29 12:25:16 -07:00
>+++ edited/drivers/net/wan/pc300_drv.c  2005-04-13 13:35:21 -06:00
>@@ -3439,6 +3439,9 @@
> #endif
>}
> 
>+   if ((err = pci_enable_device(pdev)) != 0)
>+   return err;
>+
>card = (pc300_t *) kmalloc(sizeof(pc300_t), GFP_KERNEL);
>if (card == NULL) {
>printk("PC300 found at RAM 0x%08lx, "
>@@ -3526,9 +3529,6 @@
>err = -ENODEV;
>goto err_release_ram;
>}
>-
>-   if ((err = pci_enable_device(pdev)) != 0)
>-   goto err_release_sca;
> 
>  card->hw.plxbase   =   ioremap(card->hw.plxphys,
>card->hw.plxsize);
>  card->hw.rambase   =   ioremap(card->hw.ramphys,
>card->hw.alloc_ramsize);
> 
>-
>To   unsubscribe   from   this   list:   send  the  line  "unsubscribe
>linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at  [1]http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  [2]http://www.tux.org/lkml/
> 
> References
> 
>1. http://vger.kernel.org/majordomo-info.html
>2. http://www.tux.org/lkml/

-- 
Cheers,
Ashok Raj
- Open Source Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [OSS] Add CXT48 to modem black list in ac97

[SuD (Alex)]

Herbert Xu wrote:
BTW Alex, if you have the time please determine whether ALSA
works properly on your machine.
 

Yes, alsa works, it's what i'm using now.
About how alsa detects the hardware, i have been reading some sources
and didn't get the whole point, but some facts:
- In intel8x0.c:
   In snd_intel8x0_probe() there is a call to snd_intel8x0_mixer().
   In that function it does: ac97.scaps = AC97_SCAP_SKIP_MODEM;
- In intel8x0.c:
   In snd_intel8x0m_probe() there is a call to snd_intel8x0_mixer().
   In that function it does: ac97.scaps = AC97_SCAP_SKIP_AUDIO;
- After that is done, in ac97_codec.c:
   http://lxr.linux.no/source/sound/pci/ac97/ac97_codec.c#L1921
   It checks for _SKIP_ variables and probes for soundcard (checking a 
mixer register) and modem (checking modem_id).

As a result, if i insert "snd-intel8x0" it will detect a soundcard (pci 
0:0:1f.5), but if insert instead
"snd-intel8x0M" it will detect a modem (pci 0:0:1f.6).
If a modem is detected i get errors like: "MC'97 0 converters and GPIO 
not ready (0x1)", and not sure how to test it.
If i load both modules only the first will work. The second will give an 
probe error -13 (EACCES?), because it has been marked as audio device, 
but also marked as _SKIP_AUDIO (ac97_codec.c:1862), or viceversa.

PS: And i finally subscribed to the list, thanks for your patience.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

weird X problem - priority inversion?

[Lee Revell]

I am having a problem with the RT preempt kernels where xscreensaver
will cause the X server to consume excessive CPU, starving other
processes.  This should not happen as xscreensaver runs at the highest
nice value.  It seems that there's some kind of priority inversion
happening between the high prio X server and low prio xscreensaver.

This seems like an X problem to me, but could the kernel be involved?

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] PC300 pci_enable_device fix

[Bjorn Helgaas]

Call pci_enable_device() before looking at IRQ and resources.
The driver requires this fix or the "pci=routeirq" workaround
on 2.6.10 and later kernels.

Reported and tested by Artur Lipowski.

Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>

= drivers/net/wan/pc300_drv.c 1.24 vs edited =
--- 1.24/drivers/net/wan/pc300_drv.c2004-12-29 12:25:16 -07:00
+++ edited/drivers/net/wan/pc300_drv.c  2005-04-13 13:35:21 -06:00
@@ -3439,6 +3439,9 @@
 #endif
}
 
+   if ((err = pci_enable_device(pdev)) != 0)
+   return err;
+
card = (pc300_t *) kmalloc(sizeof(pc300_t), GFP_KERNEL);
if (card == NULL) {
printk("PC300 found at RAM 0x%08lx, "
@@ -3526,9 +3529,6 @@
err = -ENODEV;
goto err_release_ram;
}
-
-   if ((err = pci_enable_device(pdev)) != 0)
-   goto err_release_sca;
 
card->hw.plxbase = ioremap(card->hw.plxphys, card->hw.plxsize);
card->hw.rambase = ioremap(card->hw.ramphys, card->hw.alloc_ramsize);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 encrypted swsusp 1/3] core functionality

[Herbert Xu]

On Wed, Apr 13, 2005 at 02:59:28PM +0200, Andreas Steinmetz wrote:
> Herbert Xu wrote:
> > What's wrong with using swap over dmcrypt + initramfs? People have
> > already used that to do encrypted swsusp.
> 
> Nothing. The problem is the fact that after resume there is then
> unencrypted(*) data on disk that should never have been there, e.g.
> dm-crypt keys, ssh keys, ...

Why is that? In the case of swap over dmcrypt, swsusp never reads/writes
the disk directly.  All operations are done through dmcrypt.

The user has to enter a password before the system can be resumed.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.4] "Fix" introduced in 2.4.27pre2 for bluetooth hci_usb race causes kernel hang

[Marcel Holtmann]

Hi Tomas,

> > > I have noticed a problem with a race condition fix introduced in
> > > 2.4.27-pre2 that causes the kernel to hang when disconnecting a
> > > Bluetooth USB dongle or doing 'hciconfig hci0 down'. No message is
> > > printed, the kernel just doesn't respond anymore.
> > > 
> > > Seen in Changelog:
> > > Marcel Holtmann:
> > >   o [Bluetooth] Fix race in RX complete routine of the USB drivers
> > > 
> > > Reversing the following patch to hci_usb_rx_complete() makes 2.4.27-pre2
> > > up until 2.4.30 happy and does not hang when removing the dongle
> > > anymore. (bfusb.c has the same patch applied)
> > > 
> > > 2.6.11.7 does not show the same problem, but has similar code to the
> > > "fixed" (that hangs) code in 2.4, so the real problem is probably
> > > somewhere else.
> > 
> > does the attached patch makes any difference?
> 
> It works just fine with pristine 2.4.30 and this patch. No deadlocks
> anymore.

if this works then we should do the same change in the bfusb driver. A
patch that fixes both drivers is attached.

Regards

Marcel

= drivers/bluetooth/bfusb.c 1.3 vs edited =
--- 1.3/drivers/bluetooth/bfusb.c   2004-04-16 14:01:40 +02:00
+++ edited/drivers/bluetooth/bfusb.c2005-04-13 12:49:55 +02:00
@@ -470,11 +470,10 @@
return 0;
 
write_lock_irqsave(&bfusb->lock, flags);
+   write_unlock_irqrestore(&bfusb->lock, flags);
 
bfusb_unlink_urbs(bfusb);
bfusb_flush(hdev);
-
-   write_unlock_irqrestore(&bfusb->lock, flags);
 
MOD_DEC_USE_COUNT;
 
= drivers/bluetooth/hci_usb.c 1.23 vs edited =
--- 1.23/drivers/bluetooth/hci_usb.c2004-07-31 13:02:43 +02:00
+++ edited/drivers/bluetooth/hci_usb.c  2005-04-09 15:37:12 +02:00
@@ -398,12 +398,12 @@
 
BT_DBG("%s", hdev->name);
 
+   /* Synchronize with completion handlers */
write_lock_irqsave(&husb->completion_lock, flags);
-   
+   write_unlock_irqrestore(&husb->completion_lock, flags);
+
hci_usb_unlink_urbs(husb);
hci_usb_flush(hdev);
-
-   write_unlock_irqrestore(&husb->completion_lock, flags);
 
MOD_DEC_USE_COUNT;
return 0;

Re: DVD writer and IDE support...

[aeriksson]

> On Wed, Apr 13, 2005 at 09:07:56PM +0200, [EMAIL PROTECTED] wrote:
> growisofs -Z /dev/hdc -J -R /path/to/dir/with/less/than/4.5GB/of/files
> 
> That should do it.  To do scsi I suspect it would be /dev/sg0 or
> /dev/scd0.  I haven't actually tried burning in scsi emulation mode with
> these drives.
> 
Nope. No go. The kernel log getsb these 4 lines:
Apr 13 22:08:30 tippex SCSI error : <0 0 0 0> return code = 0x802
Apr 13 22:08:30 tippex sr0: Current: sense key: Medium Error
Apr 13 22:08:36 tippex SCSI error : <0 0 0 0> return code = 0x802
Apr 13 22:08:36 tippex sr0: Current: sense key: Medium Error

and the application bails out with:
:-[ [EMAIL PROTECTED] failed with SK=5h/ASC=30h/ACQ=05h]: Wrong medium type
:-( media is not formatted or unsupported.
:-( write failed: Wrong medium type

This is with a fresh from the box DVD-RW. Do I need to 'format' the
thing before writing to it? This is getting tricky... Are these kind
of errors normally indicative of lack of support or a faulty unit?
I have no windows around to test it with the shipped nero-cd :-(

/Anders


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

Further copy_from_user() discussion.

[Vadim Lobanov]

Hi,

Interested by the recent discussions concerning the copy_from_user()
function, I browsed the 2.6.11.7 kernel source, and came up with a few
questions.

1. Is there any particular reason why __copy_from_user_ll() is currently
EXPORT_SYMBOL()ed for i386? At least none of the in-tree modules
currently seem to use it, and __copy_from_user() seems like what most
would want anyway. If __copy_from_user_ll() is unexported, it looks like
we can eliminate the BUG_ON() statement within it.

2. Would it be possible to eliminate the might_sleep() call in
copy_from_user()? It seems that, very soon after, the __copy_from_user()
macro does another might_sleep(), with very few instructions in between.
But there might be some trick here that I'm missing.

Please enlighten. :-)

-Vadim Lobanov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Re: more git updates..

[Matt Mackall]

On Tue, Apr 12, 2005 at 06:10:27PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 13 Apr 2005, Andrea Arcangeli wrote:
> > 
> > I wasn't suggesting to use CVS. I meant that for a newly developed SCM,
> > the CVS/SCCS format as storage may be more appealing than the current
> > git format.
> 
> Go wild. I did mine in six days, and you've been whining about other 
> peoples SCM's for three years.

I wrote a hack to do efficient delta storage with O(1) seeks for
lookup and append last week, I believe it's been integrated into the
latest Bazaar-NG. I expect it'll give better compression and
performance than BK. Of course it ends up being O(revisions) for
modifications or insertions (but that is probably a non-issue for the
SCM models we're looking at).

The git model is obviously very different, but I worry about the slop
space implied. With 200k file revision and an average of 2k slop per
file, that's 400MB of slop, or almost the size of an equivalent delta
compressed kernel repo.

Now if you can assume that blobs never change and are never deleted,
you can simply append them all onto a log, and then index them with a
separate file containing an htree of (sha1, offset, length) or the
like. Since the key is already a strong hash, this is an excellent
match and avoids rehashing in the kernel's directory lookup. And it'll
save an inode, a directory entry, and about half a data block per
entry. "Open" will also be cheaper as there's no per-revision inode to
grab.

I could hack on this if you think it fits with the git model,
otherwise I'll go back to my other experiments..

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] mspec driver for 2.6.12-rc2-mm3

[Christoph Hellwig]

On Tue, Apr 12, 2005 at 10:50:08AM -0400, Jes Sorensen wrote:
> +config MSPEC
> + tristate "Special Memory support"
> + select GENERIC_ALLOCATOR

should depend on IA64_GENERIC || IA64_SGI_SN2 because it's using sn2
functions like bte_copy

> +#define BTE_ZERO_BLOCK(_maddr, _len) \
> + bte_copy(0, _maddr - __IA64_UNCACHED_OFFSET, _len, BTE_WACQUIRE | 
> BTE_ZERO_FILL, NULL)

should become an line function.

> +static int fetchop_mmap(struct file *file, struct vm_area_struct *vma);
> +static int cached_mmap(struct file *file, struct vm_area_struct *vma);
> +static int uncached_mmap(struct file *file, struct vm_area_struct *vma);
> +static void mspec_open(struct vm_area_struct *vma);
> +static void mspec_close(struct vm_area_struct *vma);
> +static struct page * mspec_nopage(struct vm_area_struct *vma,
> + unsigned long address, int *unused);

please try to reorder the code to avoid forward-prototypes where easily
possible.

> +/*
> + * There is one of these structs per node. It is used to manage the mspec
> + * space that is available on the node. Current assumption is that there is
> + * only 1 mspec block of memory per node.
> + */
> +struct node_mspecs {
> + longmaddr;  /* phys addr of start of mspecs. */
> + int count;  /* Total number of mspec pages. */
> + atomic_tfree;   /* Number of pages currently free. */
> + unsigned long   bits[1];/* Bitmap for managing pages. */

Please use the bits[0] gcc extensions so all the calculations for the
variable sized array easily make sense.

> +/*
> + * One of these structures is allocated when an mspec region is mmaped. The
> + * structure is pointed to by the vma->vm_private_data field in the vma 
> struct. 
> + * This structure is used to record the addresses of the mspec pages.
> + */
> +struct vma_data {
> + atomic_trefcnt; /* Number of vmas sharing the data. */
> + spinlock_t  lock;   /* Serialize access to the vma. */
> + int count;  /* Number of pages allocated. */
> + int type;   /* Type of pages allocated. */
> + unsigned long   maddr[1];   /* Array of MSPEC addresses. */

dito

> +};
> +
> +
> +/*
> + * Memory Special statistics.
> + */
> +struct mspec_stats {
> + atomic_tmap_count;  /* Number of active mmap's */
> + atomic_tpages_in_use;   /* Number of mspec pages in use */
> + unsigned long   pages_total;/* Total number of mspec pages */
> +};
> +
> +static struct mspec_statsmspec_stats;
> +static struct node_mspecs*node_mspecs[MAX_NUMNODES];
> +
> +#define MAX_UNCACHED_GRANULES5
> +static int allocated_granules;
> +
> +struct gen_pool *mspec_pool[MAX_NUMNODES];

> +static unsigned long
> +mspec_get_new_chunk(struct gen_pool *poolp)
> +{
> + struct page *page;
> + void *tmp;
> + int status, node, i;
> + unsigned long addr;
> +
> + if (allocated_granules >= MAX_UNCACHED_GRANULES)
> + return 0;
> +
> + node = (int)poolp->private;

maybe the private data in the genpool should be an union of
void * and unsigned long so we can avoid all those casrs?

> + page = alloc_pages_node(node, GFP_KERNEL,
> + IA64_GRANULE_SHIFT-PAGE_SHIFT);

> + tmp = page_address(page);
> + memset(tmp, 0, IA64_GRANULE_SIZE);

shouldn't you just use __GFP_ZERO?

> +#if DEBUG
> + printk(KERN_INFO "pal_prefetch_visibility() returns %i on cpu %i\n",
> +status, get_cpu());
> +#endif

same dprintk comment as for genalloc.

> + vdata->lock = SPIN_LOCK_UNLOCKED;

you're supposed to use spin_lock_init() these days.

> +/*
> + * mspec_get_one_pte
> + *
> + * Return the pte for a given mm and address.
> + */
> +static __inline__ int
> +mspec_get_one_pte(struct mm_struct *mm, u64 address, pte_t **pte)
> +{
> + pgd_t *pgd;
> + pmd_t *pmd;
> + pud_t *pud;
> +
> + pgd = pgd_offset(mm, address);
> + if (pgd_present(*pgd)) {
> + pud = pud_offset(pgd, address);
> + if (pud_present(*pud)) {
> + pmd = pmd_offset(pud, address);
> + if (pmd_present(*pmd)) {
> + *pte = pte_offset_map(pmd, address);
> + if (pte_present(**pte)) {
> + return 0;
> + }
> + }
> + }
> + }
> +
> + return -1;
> +}

> + spin_lock(&vdata->lock);
> +
> + index = (address - vma->vm_start) >> PAGE_SHIFT;
> + if (vdata->maddr[index] == 0) {
> + vdata->count++;
> + maddr = mspec_alloc_page(numa_node_id(), vdata->type);

this looks like a page allocation under spinlock.

> + /*
> +  * The kernel requires a page structure to be returned upon
> +  * success, but there are no page structures fo

Re: [Crosspost] GNU/Linux userland?

[John Lenz]

On 04/13/05 14:40:31, Oliver Korpilla wrote:
Hello!
I wondered if there is a project or setup that does allow me to build a  
GNU/Linux userland including kernel, build environment, basic tools with  
a single script just as you can in NetBSD (build.sh) or FreeBSD (make  
world).

You might also look at www.openembedded.org  It has support for cross  
compiling, and with one command can build an entire userland.  Not sure if  
it is exactly a fit for what you want to do, but it seems very close.

John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sched: fix active load balance

[Siddha, Suresh B]

On Wed, Apr 13, 2005 at 10:08:28PM +0200, Ingo Molnar wrote:
> 
> * Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> 
> > -   for_each_domain(target_cpu, sd) {
> > +   for_each_domain(target_cpu, sd)
> > if ((sd->flags & SD_LOAD_BALANCE) &&
> > -   cpu_isset(busiest_cpu, sd->span)) {
> > -   sd = tmp;
> > +   cpu_isset(busiest_cpu, sd->span))
> > break;
> > -   }
> > -   }
> 
> hm, the right fix i think is to do:
> 
>   for_each_domain(target_cpu, tmp) {
>   if ((tmp->flags & SD_LOAD_BALANCE) &&
>   cpu_isset(busiest_cpu, tmp->span)) {
>   sd = tmp;
>   break;
>   }
>   }

Your suggestion also looks similar to my patch. You are also breaking on the 
first one.

> because when balancing we want to match the widest-scope domain, not the 
> first one.

We want the first domain spanning both the cpu's. That is the domain where
normal load balance failed and we restore to active load balance.

thanks,
suresh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sched: fix active load balance

[Ingo Molnar]

* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:

> - for_each_domain(target_cpu, sd) {
> + for_each_domain(target_cpu, sd)
>   if ((sd->flags & SD_LOAD_BALANCE) &&
> - cpu_isset(busiest_cpu, sd->span)) {
> - sd = tmp;
> + cpu_isset(busiest_cpu, sd->span))
>   break;
> - }
> - }

hm, the right fix i think is to do:

for_each_domain(target_cpu, tmp) {
if ((tmp->flags & SD_LOAD_BALANCE) &&
cpu_isset(busiest_cpu, tmp->span)) {
sd = tmp;
break;
}
}

because when balancing we want to match the widest-scope domain, not the 
first one. The s/tmp/sd thing was a typo i suspect.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2-mm3

[Ingo Molnar]

* Stas Sergeev <[EMAIL PROTECTED]> wrote:

> Hi Ingo.
> 
> I have some programs that crash
> in 2.6.12-rc2-mm3. After seeing this:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.1/1091.html

does the patch below fix the problem for you? (already in Andrew's tree, 
should be in the next -mm patch)

Ingo

--

delay the reloading of segment registers into switch_mm(), so that if
the LDT size changes we dont get a (silent) fault and a zeroed selector
register upon reloading.

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>

--- linux/arch/i386/kernel/process.c.orig
+++ linux/arch/i386/kernel/process.c
@@ -612,12 +612,12 @@ struct task_struct fastcall * __switch_t
asm volatile("movl %%gs,%0":"=m" (*(int *)&prev->gs));
 
/*
-* Restore %fs and %gs if needed.
+* Clear selectors if needed:
 */
-   if (unlikely(prev->fs | prev->gs | next->fs | next->gs)) {
-   loadsegment(fs, next->fs);
-   loadsegment(gs, next->gs);
-   }
+if (unlikely((prev->fs | prev->gs) && !(next->fs | next->gs))) {
+loadsegment(fs, next->fs);
+loadsegment(gs, next->gs);
+}
 
/*
 * Now maybe reload the debug registers
--- linux/include/asm-i386/mmu_context.h.orig
+++ linux/include/asm-i386/mmu_context.h
@@ -61,6 +61,13 @@ static inline void switch_mm(struct mm_s
}
}
 #endif
+   /*
+* Now that we've switched the LDT, load segments:
+*/
+   if (unlikely(current->thread.fs | current->thread.gs)) {
+   loadsegment(fs, current->thread.fs);
+   loadsegment(gs, current->thread.gs);
+   }
 }
 
 #define deactivate_mm(tsk, mm) \

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: New SCM and commit list

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> On Mon, 11 Apr 2005, Greg KH wrote:
> > 
> > I have a feeling that the kernel.org mirror system is just going to
> > _love_ us using it to store temporary git trees :)
> 
> I don't think kernel.org mirrors the private home directories, so it you
> do _temporary_ trees, just make them readable in your private home
> directory rather than in /pub/linux/kernel/people. For people with 
> kernel.org accounts, we can use that as the "bkbits.net" thing.
> 
> For really public hosting, we need to find some other approach. 
> 

It's also pretty trivial to set up an additional /pub hierarchy, like
the current /pub/scm, which is up to individual mirrors to pick up or
not to pick up.  We only require /pub/linux and /pub/software to be
mirrored.

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

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote:
> > > This is different. They are not giving the source at all. The licence
> > > for those object files _has_ to be different. _They_ want it to be
> > > different.
> > 
> > Sure, but in this case, the binary firmware blob is also a binary without
> > sources. If they really did write said firmware directly as it is, then they
> > should say so, but this is contrary to everyone's expectation, and a 
> > dangerous
> > precedent to set.
> 
> You should realize that any author can publish his work in the form he
> likes. He's not bound to "everyone's expectation". I see no danger in
> that.

I think there may be some limitation of using the GPL as licence in this case
though, as such behavior may limit its value, and the GPL itself is by no
means free software.

Friendly,

Sven Luther

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ds1337 4/4

[Ladislav Michl]

On Wed, Apr 13, 2005 at 08:02:53PM +0100, James Chapman wrote:
> Ladislav Michl wrote:
[snip]
> >Patch bellow remove ds1337_do_command function and things needed by it.
> >I think device should be identified by bus and address as Jean said.
> >Please let me know if that fits your needs.
> 
> I think you misunderstood what I meant by "remove the 'id' thing" 
> (probably my fault). ds1337_do_command() is needed by ppc7d so don't 
> remove it. I meant remove the id parameter from the call and change the 
> ds1337 driver to support only one instance of the device.

No it is not your fault. I understood it perfectly but removed this
function because you should find your RTC on i2c bus then then do
something like:

if (rtc_client)
rtc_client->driver->command(rtc_client, cmd, data);
else
return -ENODEV;

and that should be done outside driver.

I do not think it is good idea to limit your driver to support only one
instance, because it is unecessary and there could exist some NUMA system
which could have one such RTC per node.

> >I'm assuming that you want to use drivers/char/genrtc.c to access ds1337
> >from userspace, but in arch/ppc/platforms/radstone_ppc7d.c 
> >ppc_md.get_rtc_time used by genrtc via get_rtc_time in asm-ppc/rtc.h
> >is set to NULL (same for set_rtc_time) and I didn't find where (if)
> >ds1337 registers to ppc_md.get_rtc_time.
> 
> For ppc at least, it's the platform code that hooks up get_rtc_time().
> Last time I looked in -mm, get_rtc_time() and set_rtc_time() were being 
> set up in ppc7d to use this driver. I won't be able to check until the 
> end of the week so please bear with me.

No problem, no patches will probably go in until SCM saga gets resolved :)

> >Functions in asm-ppc/rtc.h also do magic with tm_mon and tm_year
> >so this driver doesn't need to handle epoch separately and doesn't need
> >to be aware that tm_mon starts from zero...
> 
> I don't understand. What code in ds1337 is unneeded?

It's not about unneeded code. Other RTC drivers returns tm_year in range
0..199 and tm_mon in range 0..11. Your driver does it different way,
because it hooks directly to [gs]et_rtc_time functions.

I'm not sure what is right solution here. Personaly I'd make time format
compatible with other RTC drivers and do such tweaks in arch code when
calling command function.

[snip]
> >Remove nowhere referenced ds1337_do_command function. Apply after ds1337
> >patches 1-3.
> 
> Please don't apply this patch. I will modify the ds1337_do_command() API 
> to remove the "id" parameter and fixup ppc7d platform accordingly.

See above...

Best regards,
ladis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: pty_chars_in_buffer NULL pointer (kernel oops)

[Jason Baron]

On Sun, 27 Feb 2005, Linus Torvalds wrote:

> 
> 
> On Sun, 27 Feb 2005, Marcelo Tosatti wrote:
> > 
> > Alan, Linus, what correction to the which the above thread discusses has 
> > been deployed? 
> 
> This is the hacky "hide the problem" patch that is in my current tree (and 
> was discussed in the original thread some time ago).
> 
> It's in no way "correct", in that the race hasn't actually gone away by 
> this patch, but the patch makes it unimportant. We may end up calling a 
> stale line discipline, which is still very wrong, but it so happens that 
> we don't much care in practice.
> 
> I think that in a 2.4.x tree there are some theoretical SMP races with
> module unloading etc (which the 2.6.x code doesn't have because module
> unload stops the other CPU's - maybe that part got backported to 2.4.x?), 
> but quite frankly, I suspect that even in 2.4.x they are entirely 
> theoretical and impossible to actually hit.
> 
> And again, in theory some line discipline might do something strange in
> it's "chars_in_buffer" routine that would be problematic. In practice
> that's just not the case: the "chars_in_buffer()" routine might return a
> bogus _value_ for a stale line discipline thing, but none of them seem to
> follow any pointers that might have become invalid (and in fact, most
> ldiscs don't even have that function).
> 
> So while this patch is wrogn in theory, it does have the advantage of
> being (a) very safe minimal patch and (b) fixing the problem in practice
> with no performance downside.
> 
> I still feel a bit guilty about it, though.
> 
>   Linus
> 
> ---
> # This is a BitKeeper generated diff -Nru style patch.
> #
> # ChangeSet
> #   2005/02/25 19:39:39-08:00 [EMAIL PROTECTED] 
> #   Fix possible pty line discipline race.
> #   
> #   This ain't pretty. Real fix under discussion.
> # 
> # drivers/char/pty.c
> #   2005/02/25 19:39:32-08:00 [EMAIL PROTECTED] +4 -2
> #   Fix possible pty line discipline race.
> #   
> #   This ain't pretty. Real fix under discussion.
> # 
> diff -Nru a/drivers/char/pty.c b/drivers/char/pty.c
> --- a/drivers/char/pty.c  2005-02-27 11:31:57 -08:00
> +++ b/drivers/char/pty.c  2005-02-27 11:31:57 -08:00
> @@ -149,13 +149,15 @@
>  static int pty_chars_in_buffer(struct tty_struct *tty)
>  {
>   struct tty_struct *to = tty->link;
> + ssize_t (*chars_in_buffer)(struct tty_struct *);
>   int count;
>  
> - if (!to || !to->ldisc.chars_in_buffer)
> + /* We should get the line discipline lock for "tty->link" */
> + if (!to || !(chars_in_buffer = to->ldisc.chars_in_buffer))
>   return 0;
>  
>   /* The ldisc must report 0 if no characters available to be read */
> - count = to->ldisc.chars_in_buffer(to);
> + count = chars_in_buffer(to);
>  
>   if (tty->driver->subtype == PTY_TYPE_SLAVE) return count;
>  
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

hi,

I've implented another approach to this issue, based on some previous 
suggestions. The idea is to lock both sides of a ptmx/pty pair during line 
discipline changing. As previously discussed this has the advantage of 
being on a less often used path, as opposed to locking the ptmx/pty pair 
on read/write/poll paths.

The patch below, takes both ldisc locks in either order b/c the locks are 
both taken under the same spinlock(). I thought about locking the ptmx/pty 
separately, such as master always first but that introduces a 3 way 
deadlock. For example, process 1 does a blocking read on the slave side. 
Then, process 2 does an ldisc change on the slave side, which acquires the 
master ldisc lock but not the slave's. Finally, process 3 does a write 
which blocks on the process 2's ldisc reference. 

This patch does introduce some changes in semantics. For example, a line 
discipline change on side 'a' of a ptmx/pty pair, will now wait for a 
read/write to complete on the other side, or side 'b'. The current 
behavior is to simply wait for any read/writes on only side 'a', not both 
sides 'a' and 'b'. I think this behavior makes sense, but i wanted to 
point it out.

I've tested the patch with a bunch of read/write/poll while changing the  
line discipline out from underneath.

This patch obviates the need for the above "hide the problem" patch. 

thanks,

-Jason

--- linux/drivers/char/tty_io.c.bak
+++ linux/drivers/char/tty_io.c
@@ -458,21 +458,19 @@ static void tty_ldisc_enable(struct tty_
  
 static int tty_set_ldisc(struct tty_struct *tty, int ldisc)
 {
-   int retval = 0;
-   struct  tty_ldisc o_ldisc;
+   int retval = 0;
+   struct tty_ldisc o_ldisc;
char buf[64];
int work;
unsigned long flags;
struct tty_ldisc *ld;
+   struct tty_struct *o_tty;
 
if ((ldisc < N_T

Re: DVD writer and IDE support...

[Lennart Sorensen]

On Wed, Apr 13, 2005 at 09:07:56PM +0200, [EMAIL PROTECTED] wrote:
> It's with 2.6.11.7

Probably close to the 2.6.11 kernel I run on Debian-pure64/sarge.

> Dunno yet. What's the fastest way to dump a file to a (fs on) a blank 
> 4.7 GB DVD RW? As I said this is not my home turf so I have to read 
> up on the commands to use (I guess I'm not dd'ing an iso image to 
> /dev/hdc...)

growisofs -Z /dev/hdc -J -R /path/to/dir/with/less/than/4.5GB/of/files

That should do it.  To do scsi I suspect it would be /dev/sg0 or
/dev/scd0.  I haven't actually tried burning in scsi emulation mode with
these drives.

growisofs is part of dvd+rw-tools.  It will autoformat the disc if
needed.

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

Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

[Andrew Morton]

Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> OK, I'm by no means an expert on this, but Libor and I looked at
> rmap.c a little more, and there is code:
> 
>   if ((vma->vm_flags & (VM_LOCKED|VM_RESERVED)) ||
>   ptep_clear_flush_young(vma, address, pte)) {
>   ret = SWAP_FAIL;
>   goto out_unmap;
>   }
> 
> before the check
> 
>   if (PageSwapCache(page) &&
>   page_count(page) != page_mapcount(page) + 2) {
>   ret = SWAP_FAIL;
>   goto out_unmap;
>   }
> 
> If userspace allocates some memory but doesn't touch it aside from
> passing the address in to the kernel, which does get_user_pages(), the
> PTE will be young in that first test, right?

If get_user_pages() was called with write=1, get_user_pages() will fault in
a real page and yes, I guess it'll be pte_young.

If get_user_pages() was called with write=0, get_user_pages() will fault
in a mapping of the zero page and we'd never get this far.

> Does that mean that
> the userspace mapping will be cleared and userspace will get a
> different physical page if it faults that address back in? 
>

We won't try to unmap a page's ptes until that page has file-or-swapcache
backing.

If the pte is then cleared, a subsequent minor fault will reestablish the
mapping to the same physical page.  A major fault cannot happen because the
page was pinned by get_user_pages().

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: read failed EINVAL with O_DIRECT flag

[Randy.Dunlap]

On Wed, 13 Apr 2005 15:15:47 +0200 Yves Crespin wrote:

| 
|  >| How can I obtains an buffer alignement from a "user program" ?
|  >
|  >I actually left that as an exercise (after I did it at home
|  >last night).  Did you read the hint (below)?
| 
| Well ... either with malloc() and alignement or posix_memalign(),
| read() still failed!
| My read buffer is in user space, so it's copy to kernel space.
| Inside the read() call, it's the kernel buffer which must be aligned?

No, it's the userspace buffer.  However...
the check below isn't even reached for ext3 filesystems in
Linux 2.4.  I.e., 2.4 does not support O_DIRECT for ext3fs.
mount a partition as -t ext2 and your (modified) program
works fine.  Or use 2.6.current...

Sorry to mislead you somewhat, although you do still need
the buffer alignment fixes.


|  >| >In fs/buffer.c, it wants the buffer & the length (size) to be aligned:
|  >| >
|  >| >function: brw_kiovec()
|  >| >
|  >| >/*
|  >| > * First, do some alignment and validity checks
|  >| > */
|  >| >for (i = 0; i < nr; i++) {
|  >| >iobuf = iovec[i];
|  >| >if ((iobuf->offset & (size-1)) ||
|  >| >(iobuf->length & (size-1)))
|  >| >return -EINVAL;
|  >| >if (!iobuf->nr_pages)
|  >| >panic("brw_kiovec: iobuf not initialised");
|  >| >}
|  >| >
|  >| >so in your program, malloc() the buf [pointer] (larger than needed)
|  >| >and then align it to a page boundary and pass that aligned pointer
|  >| >to read().


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

Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2)

[Daniel Ritz]

On Tuesday 12 April 2005 11:09, Andrew Morton wrote:
> Peter Baumann <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote:
> > > Peter Baumann <[EMAIL PROTECTED]> wrote:
> > > >
> > > > 
> > > > I'm hitting an annoying bug in kernel 2.6.11.5
> > > > 
> > > > Every time I _reboot_ (warmstart) my pc my two network cards won't get
> > > > recognized any longer.
> > > >
> > > > Following error message appears on my screen:
> > > >
> > > > PCI: Enabling device :00:0b.0 ( -> 0003)
> > > > ACPI: PCI interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
> > > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> > > > :00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19
> > > > PCI: Setting latency timer of device :00:0b.0 to 64
> > > > *** EEPROM MAC address is invalid.
> > > > 3c59x: vortex_probe1 fails.  Returns -22
> > > > 3c59x: probe of :00:0b.0 failed with error -22
> > > > PCI: Enabling device :00:0d.0 ( -> 0003)
> > > > ACPI: PCI interrupt :00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19
> > > > :00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19
> > > > PCI: Setting latency timer of device :00:0d.0 to 64
> > > > *** EEPROM MAC address is invalid.
> > > > 3c59x: vortex_probe1 fails.  Returns -22
> > > > 3c59x: probe of :00:0d.0 failed with error -22
> > > >
> > > > This doesn't happen with older kernels (especially with 2.6.10) and so
> > > > I've done a binary search and narrowed it down to 2.6.11-rc5 where it
> > > > first hits me.
> > > >
> > > > My config, lspci output and the dmesg output of the working and 
> > > > non-working
> > > > version can be found at [1]
> > > >
> > > > Feel free to ask if any information is missing or if I am supposed to 
> > > > try
> > > > a patch.
> > >
> > > Thanks for doing the bsearch - it helps.
> > >
> > > There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5.
> > >
> > > The only PCI change I see is
> > >
> > > --- drivers/pci/pci.c   22 Jan 2005 03:20:37 -  1.71
> > > +++ drivers/pci/pci.c   24 Feb 2005 18:02:37 -  1.72
> > > @@ -268,7 +268,7 @@
> > > return -EIO;
> > >
> > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc);
> > > -   if ((pmc & PCI_PM_CAP_VER_MASK) != 2) {
> > > +   if ((pmc & PCI_PM_CAP_VER_MASK) > 2) {
> > > printk(KERN_DEBUG
> > >"PCI: %s has unsupported PM cap regs version 
> > > (%u)\n",
> > >dev->slot_name, pmc & PCI_PM_CAP_VER_MASK);
> > >
> > > and you're not getting that message (are you?)
> > >
> > 
> > I have still the problem described above with 2.6.12-rc2-mm2 and
> > reverting the above patch solved it. And yes, now I get many of those
> > 
> > PCI: :00:0b.0 has unsupported PM cap regs version (1)
> > PCI: :00:0d.0 has unsupported PM cap regs version (1)
> > PCI: :00:09.0 has unsupported PM cap regs version (1)
> > 
> > messages.
> > 
> 
> Yes, we need to work out what's going on here.
> 
> Daniel?

yes. i already posted a debugging patch and asked to have to dmesg output.
but no response. Message-Id: <[EMAIL PROTECTED]>

i see two possibilities:
- it's not really writing to the PM registers but somewhere else (or it's
  writing some crap)
- the device hates when somebody writes the current state again
  (yes, there is a check for this but it's useless during boot). i have
  a patch for this but i didn't send it until now because i really like
  to see the debugging output first...attached anyway...

rgds
-daniel

--

[PATCH] PCI PM: read initial state from device

the PCI PM code tries not to write to the PM registers when there is no change
in state. this however fails when a device is initially set up. and because
some devices are broken they hate being forced to the state they are in. fix
it by reading the current state from the device itself. also does some other
things:
- support PCI PM CAP version 3 (as defined in PCI PM Interface Spec v1.2)
- add and export the function pci_get_power_state() to get it from the device
- pci.h defines "4" as D3cold while probe.c uses it for unknown state
- minor cleanups

--- 1.151/include/linux/pci.h   2005-02-03 19:08:22 +01:00
+++ edited/include/linux/pci.h  2005-04-09 00:49:42 +02:00
@@ -501,6 +501,7 @@
 #define PCI_D2 ((pci_power_t __force) 2)
 #define PCI_D3hot  ((pci_power_t __force) 3)
 #define PCI_D3cold ((pci_power_t __force) 4)
+#define PCI_UNKNOWN((pci_power_t __force) 5)
 
 /*
  * The pci_dev structure is used to describe PCI devices.
@@ -822,6 +823,7 @@
 /* Power management related routines */
 int pci_save_state(struct pci_dev *dev);
 int pci_restore_state(struct pci_dev *dev);
+pci_power_t pci_get_power_state(struct pci_dev *dev);
 int pci_set_power_state(struct pci_dev *dev, pci_power_t state);
 pci_power_t pci_choose_state(struct pci_dev *dev, pm_message_t state);
 int pci_enable_wak

Re: [ANNOUNCE] git-pasky-0.3

[H. Peter Anvin]

Russell King wrote:
Nothing much - I don't particularly care about them.  I thought someone
might object to using htonl/ntohl directly.
Why would they?
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [ANNOUNCE] git-pasky-0.3

[Russell King]

On Wed, Apr 13, 2005 at 09:13:39PM +0200, Petr Baudis wrote:
> Dear diary, on Wed, Apr 13, 2005 at 09:03:07PM CEST, I got a letter
> where Russell King <[EMAIL PROTECTED]> told me that...
> > On Wed, Apr 13, 2005 at 10:35:21AM +0100, Russell King wrote:
> > > I tried this today, applied my patch for BE<->LE conversions and
> > > glibc-2.2 compatibility (attached, still requires cleaning though),
> > > and then tried git pull.  Umm, whoops.
> > 
> > Here's an updated patch which allows me to work with a BE-based
> > cache.  I've just used this to grab and checkout sparse.git.
> > 
> > Note: it also fixes my glibc-2.2 build problem with the nsec
> > stat64 structures (see read-cache.c).
> > 
> > --- cache.h
> > +++ cache.h Wed Apr 13 11:23:39 2005
> > @@ -14,6 +14,12 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +#define cpu_to_beuint(x)   (htonl(x))
> > +#define beuint_to_cpu(x)   (ntohl(x))
> > +#define cpu_to_beushort(x) (htons(x))
> > +#define beushort_to_cpu(x) (ntohs(x))
> > +
> >  /*
> >   * Basic data structures for the directory cache
> >   *
> 
> What do the wrapper macros gain us?

Nothing much - I don't particularly care about them.  I thought someone
might object to using htonl/ntohl directly.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Why system call need to copy the date from the userspace before using it

[Richard B. Johnson]

On Wed, 13 Apr 2005, Theodore Ts'o wrote:
On Wed, Apr 13, 2005 at 08:40:05AM -0400, Richard B. Johnson wrote:
The kernel does NOT have to copy data from user-space before
using it.
Incorrect.  It must, or the kernel code in question is by definition
buggy.
What? Explain why a memory-mapped buffer can't be DMAed directly?
In fact, user-mode pointers are valid in kernel-space
when the kernel is performing a function on behalf of the user-
mode code.
On some architectures, this is true.  But not all architectures, and
not in all circumstances.  For example, even on the x86 architecture,
in the 4G/4G mode, a user-mode pointer is *not* valid when kernel code
is running.  You must use copy_to_user()/copy_from_user().  Simply
dereferencing a user-mode pointer is a BUG.  It might work sometimes,
on some architectures, but not everywhere.  Therefore, for correctly
written kernel code, you must not do it.
You apparently didn't even bother to read my explanation why the
copy/to/from user was necessary unless the buffer(s) were memory-
mapped, marked reserved, and set to no-cache. In that case
you can DMA directly to/from user-space. Perhaps you just wanted
to argue?
		- Ted
Again, as long as you can guarantee that the RAM you are using
is reserved so the kernel won't use it for paged RAM, and as
long as it's accessible in both user-mode and kernel-mode,
which means memory-mapped, either the kernel or the user can
use it as it sees fit. If it can't, the kernel is buggy. In
fact, there is no way the kernel could prevent it from being
used in this manner. Since, by definition, the kernel
will leave reserved memory alone, and memory-mapped space
will not fault, there is no way for the kernel to even know
how it is being accessed.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] FUSE permission modell (Was: fuse review bits)

[Miklos Szeredi]

> > > Yet, the results from stat() don't distinguish the number spaces,
> > > and "ls" doesn't map the numbers to names properly in the wrong
> > > space.
> > 
> > Well you can use "ls -n".  It's up to the tools to present the
> > information you want in the way you want it.  If a tool can't do that,
> > tough, but you are not worse off than if the information is not
> > available _at_all_.
> 
> Well, how do you currently provide access to the information that's
> not presentable through stat()?

Obviously I don't.  However that's hardly an argument for providing
even less information.

And stat() btw pretty much covers what information there is to present
for network filesystems and archives, since there _is_ a real
filesystem where the information originated from (though sometimes
it's not a UNIX type of filesystem, in which case there has to be some
mapping of the info).

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Re: [ANNOUNCE] git-pasky-0.3

[Petr Baudis]

Dear diary, on Wed, Apr 13, 2005 at 09:03:07PM CEST, I got a letter
where Russell King <[EMAIL PROTECTED]> told me that...
> On Wed, Apr 13, 2005 at 10:35:21AM +0100, Russell King wrote:
> > I tried this today, applied my patch for BE<->LE conversions and
> > glibc-2.2 compatibility (attached, still requires cleaning though),
> > and then tried git pull.  Umm, whoops.
> 
> Here's an updated patch which allows me to work with a BE-based
> cache.  I've just used this to grab and checkout sparse.git.
> 
> Note: it also fixes my glibc-2.2 build problem with the nsec
> stat64 structures (see read-cache.c).
> 
> --- cache.h
> +++ cache.h   Wed Apr 13 11:23:39 2005
> @@ -14,6 +14,12 @@
>  #include 
>  #include 
>  
> +#include 
> +#define cpu_to_beuint(x) (htonl(x))
> +#define beuint_to_cpu(x) (ntohl(x))
> +#define cpu_to_beushort(x)   (htons(x))
> +#define beushort_to_cpu(x)   (ntohs(x))
> +
>  /*
>   * Basic data structures for the directory cache
>   *

What do the wrapper macros gain us?

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

[Roland Dreier]

OK, I'm by no means an expert on this, but Libor and I looked at
rmap.c a little more, and there is code:

if ((vma->vm_flags & (VM_LOCKED|VM_RESERVED)) ||
ptep_clear_flush_young(vma, address, pte)) {
ret = SWAP_FAIL;
goto out_unmap;
}

before the check

if (PageSwapCache(page) &&
page_count(page) != page_mapcount(page) + 2) {
ret = SWAP_FAIL;
goto out_unmap;
}

If userspace allocates some memory but doesn't touch it aside from
passing the address in to the kernel, which does get_user_pages(), the
PTE will be young in that first test, right?  Does that mean that
the userspace mapping will be cleared and userspace will get a
different physical page if it faults that address back in?

 - R.


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

Re: DVD writer and IDE support...

[aeriksson]

> On Wed, Apr 13, 2005 at 08:14:21PM +0200, [EMAIL PROTECTED] wrote:

> 
> Well it does look odd that it loads with one and not the other.  Which
> kernel is this with?
> 
It's with 2.6.11.7

> Does writing CDs and DVDs actually work using ide-scsi?  Does it work
> using ide-cd?

Dunno yet. What's the fastest way to dump a file to a (fs on) a blank 
4.7 GB DVD RW? As I said this is not my home turf so I have to read 
up on the commands to use (I guess I'm not dd'ing an iso image to 
/dev/hdc...)

> 
> Len Sorensen
> 
Thanks for helping out.

/Anders

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sched: fix active load balance

[Siddha, Suresh B]

Recent changes to active load balance (sched2-fix-smt-scheduling-problems.patch
in -mm) is not resulting in any task movement from busiest to target_cpu.
Attached patch(ontop of -mm) fixes this issue.

Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-mm3/kernel/sched.c 2005-04-11 23:08:30.875103512 -0700
+++ linux/kernel/sched.c2005-04-13 10:44:37.400829992 -0700
@@ -2131,7 +2131,7 @@
  */
 static void active_load_balance(runqueue_t *busiest_rq, int busiest_cpu)
 {
-   struct sched_domain *tmp = NULL, *sd;
+   struct sched_domain *sd;
runqueue_t *target_rq;
int target_cpu = busiest_rq->push_cpu;
 
@@ -2152,13 +2152,10 @@
double_lock_balance(busiest_rq, target_rq);
 
/* Search for an sd spanning us and the target CPU. */
-   for_each_domain(target_cpu, sd) {
+   for_each_domain(target_cpu, sd)
if ((sd->flags & SD_LOAD_BALANCE) &&
-   cpu_isset(busiest_cpu, sd->span)) {
-   sd = tmp;
+   cpu_isset(busiest_cpu, sd->span))
break;
-   }
-   }
 
if (unlikely(sd == NULL))
goto out;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ANNOUNCE] git-pasky-0.3

[Russell King]

On Wed, Apr 13, 2005 at 10:35:21AM +0100, Russell King wrote:
> I tried this today, applied my patch for BE<->LE conversions and
> glibc-2.2 compatibility (attached, still requires cleaning though),
> and then tried git pull.  Umm, whoops.

Here's an updated patch which allows me to work with a BE-based
cache.  I've just used this to grab and checkout sparse.git.

Note: it also fixes my glibc-2.2 build problem with the nsec
stat64 structures (see read-cache.c).

--- cache.h
+++ cache.h Wed Apr 13 11:23:39 2005
@@ -14,6 +14,12 @@
 #include 
 #include 
 
+#include 
+#define cpu_to_beuint(x)   (htonl(x))
+#define beuint_to_cpu(x)   (ntohl(x))
+#define cpu_to_beushort(x) (htons(x))
+#define beushort_to_cpu(x) (ntohs(x))
+
 /*
  * Basic data structures for the directory cache
  *
@@ -67,7 +73,7 @@
 #define DEFAULT_DB_ENVIRONMENT ".git/objects"
 
 #define cache_entry_size(len) ((offsetof(struct cache_entry,name) + (len) + 8) 
& ~7)
-#define ce_size(ce) cache_entry_size((ce)->namelen)
+#define ce_size(ce) cache_entry_size(beushort_to_cpu((ce)->namelen))
 
 #define alloc_nr(x) (((x)+16)*3/2)
 
--- checkout-cache.c
+++ checkout-cache.cWed Apr 13 19:52:08 2005
@@ -77,7 +77,7 @@
return error("checkout-cache: unable to read sha1 file of %s 
(%s)",
ce->name, sha1_to_hex(ce->sha1));
}
-   fd = create_file(ce->name, ce->st_mode);
+   fd = create_file(ce->name, beuint_to_cpu(ce->st_mode));
if (fd < 0) {
free(new);
return error("checkout-cache: unable to create %s (%s)",
--- read-cache.c
+++ read-cache.cWed Apr 13 19:37:00 2005
@@ -271,27 +271,34 @@
/* nsec seems unreliable - not all filesystems support it, so
 * as long as it is in the inode cache you get right nsec
 * but after it gets flushed, you get zero nsec. */
-   if (ce->mtime.sec  != (unsigned int)st->st_mtim.tv_sec
+#if 0
+   if (beuint_to_cpu(ce->mtime.sec)  != (unsigned int)st->st_mtim.tv_sec
 #ifdef NSEC
-   || ce->mtime.nsec != (unsigned int)st->st_mtim.tv_nsec
+   || beuint_to_cpu(ce->mtime.nsec) != (unsigned 
int)st->st_mtim.tv_nsec
 #endif
)
changed |= MTIME_CHANGED;
-   if (ce->ctime.sec  != (unsigned int)st->st_ctim.tv_sec
+   if (beuint_to_cpu(ce->ctime.sec)  != (unsigned int)st->st_ctim.tv_sec
 #ifdef NSEC
-   || ce->ctime.nsec != (unsigned int)st->st_ctim.tv_nsec
+   || beuint_to_cpu(ce->ctime.nsec) != (unsigned 
int)st->st_ctim.tv_nsec
 #endif
)
changed |= CTIME_CHANGED;
-   if (ce->st_uid != (unsigned int)st->st_uid ||
-   ce->st_gid != (unsigned int)st->st_gid)
+#else
+   if (beuint_to_cpu(ce->mtime.sec)  != (unsigned int)st->st_mtime)
+   changed |= MTIME_CHANGED;
+   if (beuint_to_cpu(ce->ctime.sec)  != (unsigned int)st->st_ctime)
+   changed |= CTIME_CHANGED;
+#endif
+   if (beuint_to_cpu(ce->st_uid) != (unsigned int)st->st_uid ||
+   beuint_to_cpu(ce->st_gid) != (unsigned int)st->st_gid)
changed |= OWNER_CHANGED;
-   if (ce->st_mode != (unsigned int)st->st_mode)
+   if (beuint_to_cpu(ce->st_mode) != (unsigned int)st->st_mode)
changed |= MODE_CHANGED;
-   if (ce->st_dev != (unsigned int)st->st_dev ||
-   ce->st_ino != (unsigned int)st->st_ino)
+   if (beuint_to_cpu(ce->st_dev) != (unsigned int)st->st_dev ||
+   beuint_to_cpu(ce->st_ino) != (unsigned int)st->st_ino)
changed |= INODE_CHANGED;
-   if (ce->st_size != (unsigned int)st->st_size)
+   if (beuint_to_cpu(ce->st_size) != (unsigned int)st->st_size)
changed |= DATA_CHANGED;
return changed;
 }
@@ -320,7 +327,7 @@
while (last > first) {
int next = (last + first) >> 1;
struct cache_entry *ce = active_cache[next];
-   int cmp = cache_name_compare(name, namelen, ce->name, 
ce->namelen);
+   int cmp = cache_name_compare(name, namelen, ce->name, 
beushort_to_cpu(ce->namelen));
if (!cmp)
return next;
if (cmp < 0) {
@@ -347,7 +354,7 @@
 {
int pos;
 
-   pos = cache_name_pos(ce->name, ce->namelen);
+   pos = cache_name_pos(ce->name, beushort_to_cpu(ce->namelen));
 
/* existing match? Just replace it */
if (pos >= 0) {
@@ -378,9 +385,9 @@
SHA_CTX c;
unsigned char sha1[20];
 
-   if (hdr->signature != CACHE_SIGNATURE)
+   if (hdr->signature != cpu_to_beuint(CACHE_SIGNATURE))
return error("bad signature");
-   if (hdr->version != 1)
+   if (hdr->version != cpu_to_beuint(1))
return error("bad version");
SHA1_Init(&c);
SHA1_Update(&c, hdr, offsetof(struct cache_header, sha1));
@@ -428,12 +435,12 @@
if (verify_hdr(hdr, size) < 0)
goto unma

Re: [PATCH] ds1337 4/4

[James Chapman]

Ladislav Michl wrote:
On Tue, Apr 12, 2005 at 07:10:55PM +0100, James Chapman wrote:
[snip]
It is used by the Radstone ppc7d platform, arch/ppc/radstone_ppc7d.c
but wasn't added until very recently (2.6.12-rc2 I think).
To be honest, I meant to remove the 'id' thing before submitting the
driver. There's no need to support more than one of these devices.
Patch bellow remove ds1337_do_command function and things needed by it.
I think device should be identified by bus and address as Jean said.
Please let me know if that fits your needs.
I think you misunderstood what I meant by "remove the 'id' thing" 
(probably my fault). ds1337_do_command() is needed by ppc7d so don't 
remove it. I meant remove the id parameter from the call and change the 
ds1337 driver to support only one instance of the device.

I'm assuming that you want to use drivers/char/genrtc.c to access ds1337
from userspace, but in arch/ppc/platforms/radstone_ppc7d.c 
ppc_md.get_rtc_time used by genrtc via get_rtc_time in asm-ppc/rtc.h
is set to NULL (same for set_rtc_time) and I didn't find where (if)
ds1337 registers to ppc_md.get_rtc_time.
For ppc at least, it's the platform code that hooks up get_rtc_time().
Last time I looked in -mm, get_rtc_time() and set_rtc_time() were being 
set up in ppc7d to use this driver. I won't be able to check until the 
end of the week so please bear with me.

Functions in asm-ppc/rtc.h also do magic with tm_mon and tm_year
so this driver doesn't need to handle epoch separately and doesn't need
to be aware that tm_mon starts from zero...
I don't understand. What code in ds1337 is unneeded?
m68k, mips and parisc does the same in asm/rtc.h unlike arm, so I this
driver probably won't work for me without some tweaks to arm code.
[snip]
Back to the issue, some random thoughts summarizing my opinion:
[snip]
3* Having the driver write an arbitrary non-0 value to the register
should not be done unless the system has been identified. I have no idea
how your system can be identified (DMI?), but if it can't, then I'd
better see the register ignored altogether.
My board is OMAP (ARM core) based and there are ARM specific functions
(if (machine_is_xxx()) do_something(); ), but it is not what you want to
see in generic driver. It may be possible to use platform_data to pass
information to driver, but I do not like this idea.
So, if we use entry in sysfs, then only root can write it and root is
allowed to do weird things. Device itself refuses any action until high
four bits are 0xa. If that is still not enough I just found this patch
http://groups-beta.google.com/group/fa.linux.kernel/msg/06e0368f86c8f824
so you can use configfs to explicitly create "charge" entry. (
* I'm considering that an overkill
* I'm not sure if it can be easily done with configfs)
I'd add config option (disabled by default) for "charge" entry, if you
feel it is too dangerous. However I think that people should be a bit
responsible for their actions and not writing any randoms values to any
random files in /sys :)
4* Remember that you can always write a simple C tool relying on the
i2c-dev interface to do the job. The advantage of this approach is that
you can put big fat warnings and request user confirmation before any
action.
This makes sense. Ladislav, would this work for you? I guess we'd still
add code to the ds1337 driver to detect ds1339 in order to ensure that
this tool could not modify register 0 of a ds1337 by accident?

Yes, that would definitely work for me and I'm fine with that in case
proposal above would be rejected.
Ok. Jean, what do you think? Do we really want a "charge" sysfs entry? I 
don't have a strong opinion on this.

Remove nowhere referenced ds1337_do_command function. Apply after ds1337
patches 1-3.
Please don't apply this patch. I will modify the ds1337_do_command() API 
to remove the "id" parameter and fixup ppc7d platform accordingly.

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

Re: Add pcibus_to_node

[Andi Kleen]

On Tue, Apr 12, 2005 at 02:16:17PM -0700, Christoph Lameter wrote:
> Define pcibus_to_node to be able to figure out which NUMA node contains a
> given PCI device. This defines pcibus_to_node(bus) in
> include/linux/topology.h and adjusts the macros for i386 and x86_64 that
> already provided a way to determine the cpumask of a pci device.
> 
> x86_64 was changed to not build an array of cpumasks anymore. Instead an
> array of nodes is build which can be used to generate the cpumask via
> node_to_cpumask.

Ok from my side.

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