RE: minor device number request for /dev/kvm (kernel-based virtual machine)
> > If it does not increase memory usage, then possibly: > > > > __register_chrdev_region(major, 0, (~0U) & MINORMASK, name); > > or (1< clear > > > > > > I'm more worried about something in the chardev bowels not supporting > >8bit minors well. > I was under the impression that large minors was supported for misc. Skimming the code that does not seem to be the case. Can someone comment? Torben - 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: lanana: Add major/minor entries for PPC QE UART devices
> We are making a very complicated problem > out of nothing. This hasn't caused any problems > in the past, and changing the existing names and > minors will cause problems for everyone today. > > Just leave it alone, fix up the documentation, > and have the driver print some warning if it > allocates more than 4 UARTs. > Dan has a point here. Now I clearly can't comment on how bad 8 is needed, but since this has been like this for a while, I'll have to assume 4 is covering most cases. Moving things to a different range _will_ be much worse for distro maintainers than driver developers. And I bet the latter is going to be minor work as things has been like this for a while. But we can still allocate 4 more at a different minor that distro's can _choose_ to use. Consider it an enhancement to the 4 we have had in the past. Torben - 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: lanana: Add major/minor entries for PPC QE UART devices
We are making a very complicated problem out of nothing. This hasn't caused any problems in the past, and changing the existing names and minors will cause problems for everyone today. Just leave it alone, fix up the documentation, and have the driver print some warning if it allocates more than 4 UARTs. Dan has a point here. Now I clearly can't comment on how bad 8 is needed, but since this has been like this for a while, I'll have to assume 4 is covering most cases. Moving things to a different range _will_ be much worse for distro maintainers than driver developers. And I bet the latter is going to be minor work as things has been like this for a while. But we can still allocate 4 more at a different minor that distro's can _choose_ to use. Consider it an enhancement to the 4 we have had in the past. Torben - 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: lanana: Add major/minor entries for PPC QE UART devices
> > Mathiasen, Torben wrote: > > > Assuming QE has 4 entries, I would expect CPM to be the same. But we > > need verification of that. If it needs 6, we are in more trouble. > > The QE can have up to 8, actually, but I'm willing to limit the driver > to 4. Its your choice if you want to limit it to 4 or have it moved into a different minor range. I can live with both. Thanks, Torben - 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: lanana: Add major/minor entries for PPC QE UART devices
> Mathiasen, Torben wrote: > > > > Got around looking at this one. I'm fine with this approach, but the > > CPM5 fix looks wrong. Shouldn't it be: > > > > 49 = /dev/ttyCPM3 PPC CPM (SCC or SMC) - port 3 > > > > instead? > > > > Well, how many CPM devices can exist? If there are really 6 ports > possible, they need minors up to 51. > > Also, if QE really is just CPM v3, and they share the same minors, why > change the name? > Assuming QE has 4 entries, I would expect CPM to be the same. But we need verification of that. If it needs 6, we are in more trouble. Torben - 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: lanana: Add major/minor entries for PPC QE UART devices
> --- devices-2.6+.txt 2007-02-22 13:37:18.0 -0600 > +++ devices-2.6+.new 2007-02-22 13:42:50.0 -0600 > @@ -2770,7 +2770,10 @@ >45 = /dev/ttyMM1 Marvell MPSC - port 1 >46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0 > ... > - 47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5 > + 49 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5 > + 46 = /dev/ttyQE0 PPC QE (UCC) - port 0 > + ... > + 49 = /dev/ttyQE3 PPC QE (UCC) - port 3 >50 = /dev/ttyIOC0 Altix serial card > ... >81 = /dev/ttyIOC31 Altix serial card > Got around looking at this one. I'm fine with this approach, but the CPM5 fix looks wrong. Shouldn't it be: 49 = /dev/ttyCPM3 PPC CPM (SCC or SMC) - port 3 instead? Thx, Torben - 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: lanana: Add major/minor entries for PPC QE UART devices
--- devices-2.6+.txt 2007-02-22 13:37:18.0 -0600 +++ devices-2.6+.new 2007-02-22 13:42:50.0 -0600 @@ -2770,7 +2770,10 @@ 45 = /dev/ttyMM1 Marvell MPSC - port 1 46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0 ... - 47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5 + 49 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5 + 46 = /dev/ttyQE0 PPC QE (UCC) - port 0 + ... + 49 = /dev/ttyQE3 PPC QE (UCC) - port 3 50 = /dev/ttyIOC0 Altix serial card ... 81 = /dev/ttyIOC31 Altix serial card Got around looking at this one. I'm fine with this approach, but the CPM5 fix looks wrong. Shouldn't it be: 49 = /dev/ttyCPM3 PPC CPM (SCC or SMC) - port 3 instead? Thx, Torben - 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: lanana: Add major/minor entries for PPC QE UART devices
Mathiasen, Torben wrote: Got around looking at this one. I'm fine with this approach, but the CPM5 fix looks wrong. Shouldn't it be: 49 = /dev/ttyCPM3 PPC CPM (SCC or SMC) - port 3 instead? Well, how many CPM devices can exist? If there are really 6 ports possible, they need minors up to 51. Also, if QE really is just CPM v3, and they share the same minors, why change the name? Assuming QE has 4 entries, I would expect CPM to be the same. But we need verification of that. If it needs 6, we are in more trouble. Torben - 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: lanana: Add major/minor entries for PPC QE UART devices
Mathiasen, Torben wrote: Assuming QE has 4 entries, I would expect CPM to be the same. But we need verification of that. If it needs 6, we are in more trouble. The QE can have up to 8, actually, but I'm willing to limit the driver to 4. Its your choice if you want to limit it to 4 or have it moved into a different minor range. I can live with both. Thanks, Torben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] New updated devices.txt - LANANA
> On Dec 1 2006 11:30, Torben Mathiasen wrote: > >Here's the updated version with additonal spelling fixes. > > > >Please use this one instead of the one that was sent 2 days ago. > > And here's a style update (have one free line between each, > and a few tabs). Applies _on top_ of yours. > Thanks, looks good. Please apply this as well. Torben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] New updated devices.txt - LANANA
On Dec 1 2006 11:30, Torben Mathiasen wrote: Here's the updated version with additonal spelling fixes. Please use this one instead of the one that was sent 2 days ago. And here's a style update (have one free line between each, and a few tabs). Applies _on top_ of yours. Thanks, looks good. Please apply this as well. Torben - 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] devices.txt - LANANA merge
> > +258 block ROM/Flash read-only translation layer > > + 0 = /dev/blockrom0First ROM card's > translation layer interface > > + 1 = /dev/blockrom0Second ROM card's > translation layer interface > ^^^ > > Shouldn't here be '1', ie, /dev/blockrom1 ? > Good catch. I also just added another patch fixing spelling on lanana.org. I'll let this email circulate until tomorrow and then send another patch if nothing else comes in. Thanks, Torben - 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] devices.txt - LANANA merge
+258 block ROM/Flash read-only translation layer + 0 = /dev/blockrom0First ROM card's translation layer interface + 1 = /dev/blockrom0Second ROM card's translation layer interface ^^^ Shouldn't here be '1', ie, /dev/blockrom1 ? Good catch. I also just added another patch fixing spelling on lanana.org. I'll let this email circulate until tomorrow and then send another patch if nothing else comes in. Thanks, Torben - 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: Probable endianess problem in TLAN driver
Paulo, Thanks for the update/patch. Sorry I missed your first email, bu I've been way too busy with other stuff the last couple of months. There's a lot of endianess issues in the tlan driver, but none really bothered fixing them. No one really assumed the tlan adapters would be used on bigendian machines. Well, let me say, you're probaly the first ;-). Now, I have pile of updates/issues for the tlan driver I need to check up on. Hopefully I'll have some sparetime within a reasonable future to address this. BTW. The project page on compaq.com is the "new" tlan site. Thanks, Torben Mathiasen - 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: Probable endianess problem in TLAN driver
Paulo, Thanks for the update/patch. Sorry I missed your first email, bu I've been way too busy with other stuff the last couple of months. There's a lot of endianess issues in the tlan driver, but none really bothered fixing them. No one really assumed the tlan adapters would be used on bigendian machines. Well, let me say, you're probaly the first ;-). Now, I have pile of updates/issues for the tlan driver I need to check up on. Hopefully I'll have some sparetime within a reasonable future to address this. BTW. The project page on compaq.com is the new tlan site. Thanks, Torben Mathiasen - 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: Alpha SCSI error on 2.4.0-test11
Its probaly due to the semaphore changes that went in to test11 by Richard Henderson. scsi_wait_req will grab one on entry. Did test10 work for you on Alpha? Regards, Torben Mathiasen > -Original Message- > From: Rival, Frank > Sent: 30. november 2000 21:37 > To: Ezolt, Phillip > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > Estabrook, Jay; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: Alpha SCSI error on 2.4.0-test11 > > > Hi Phil, > > Phillip Ezolt wrote: > > > Hi All, > > > > Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata > (Digital Personal WorkStation 600au). > > > > When starting up, we get a machine check after initialing > the qlogic SCSI code. > > > > Using the Alpha kgdb, we figured out that the code is dying > in scsi_wait_request(). > > Wow, I'm impressed! I didn't realize that kgdb worked on > Alpha...Were > you using the remote kgdb? (You can answer me offline to save > bandwidth.) This would be a _huge_ help in trying to figure > out why my > Wildfire^WGS160 is crashing with the DISCONTIGMEM code that I > stole from > Jay and have been hacking on. > > Speaking of that system, it has two QLogic adapters in it > (both 1040Bs, > like the Miata), and they are working just fine under 2.4.0-test11 > (obviously, without my changes ;). It looks like it's probably the > platform code that's busted. I can't remember...are those Pyxis or > CIA? Anyway, could this have something to do with the PCI & > PCI bridge > work that Richard and Ivan just submitted? > > - Pete > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Alpha SCSI error on 2.4.0-test11
Its probaly due to the semaphore changes that went in to test11 by Richard Henderson. scsi_wait_req will grab one on entry. Did test10 work for you on Alpha? Regards, Torben Mathiasen -Original Message- From: Rival, Frank Sent: 30. november 2000 21:37 To: Ezolt, Phillip Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Estabrook, Jay; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Alpha SCSI error on 2.4.0-test11 Hi Phil, Phillip Ezolt wrote: Hi All, Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal WorkStation 600au). When starting up, we get a machine check after initialing the qlogic SCSI code. Using the Alpha kgdb, we figured out that the code is dying in scsi_wait_request(). Wow, I'm impressed! I didn't realize that kgdb worked on Alpha...Were you using the remote kgdb? (You can answer me offline to save bandwidth.) This would be a _huge_ help in trying to figure out why my Wildfire^WGS160 is crashing with the DISCONTIGMEM code that I stole from Jay and have been hacking on. Speaking of that system, it has two QLogic adapters in it (both 1040Bs, like the Miata), and they are working just fine under 2.4.0-test11 (obviously, without my changes ;). It looks like it's probably the platform code that's busted. I can't remember...are those Pyxis or CIA? Anyway, could this have something to do with the PCI PCI bridge work that Richard and Ivan just submitted? - Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
