Re: [Qemu-devel] QEMU/pc and scsi disks
Paul Brook wrote: On Thursday 01 March 2007 17:26, Laurent Vivier wrote: Hi, As I'm a newcomer, I don't know the story about qemu/pc and scsi disks, but I propose a little patch to make SCSI disks visible. See previous discussion about how the disk options need to be fixed properly. Sorry, I didn't find it, but now I've found it. Apart from anything else your patch completely ignores non-x86 targets. This patch was just to validate my approach... and it seems bad :-P There's also no reason to limit to 7 disks, and we should support scsi cdroms. The reason for 7 is the number of available id on the scsi bus. Of course, we could manage several bus. To add cdroms support, we can add parameters -scd0, -scd1, ... Thank you for your comments. Laurent -- - [EMAIL PROTECTED] -- Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke signature.asc Description: OpenPGP digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU/pc and scsi disks
Laurent Vivier wrote: Paul Brook wrote: On Thursday 01 March 2007 17:26, Laurent Vivier wrote: Hi, As I'm a newcomer, I don't know the story about qemu/pc and scsi disks, but I propose a little patch to make SCSI disks visible. See previous discussion about how the disk options need to be fixed properly. Sorry, I didn't find it, but now I've found it. Apart from anything else your patch completely ignores non-x86 targets. This patch was just to validate my approach... and it seems bad :-P There's also no reason to limit to 7 disks, and we should support scsi cdroms. The reason for 7 is the number of available id on the scsi bus. For wide scsi it is 15. Of course, we could manage several bus. To add cdroms support, we can add parameters -scd0, -scd1, ... This gets unwieldy quickly. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Access to qemu-monitor on Solaris/Sparc host
Was doing some testing on a sparc host, and found an interesting situation. Code is 0.9.0-CVS, and I start qemu on my Ultra 60 (guest is windows 98se). When I hit ctrl-alt-2, I don't get the monitor. I've added some debugging to sdl.c, to try and figure out what is going on. Hitting ctrl-alt-2, I see the following kbd_put_keyboard events kbd_put_keycode(29) # ctrl kbd_put_keycode(56) # alt kbd_put_keycode(3) # 2 kbd_put_keycode(131)# 2 | 0x80 The following key combinations get me interesting places (Unfortunately my debugging didn't generate any specifics for these key combinations yet) ctrl-alt-F1goes to serial0 console ctrl-alt-F2goes to parallel console ctrl-alt-AGAIN goes back to the graphical screen from serial0 or parallel0 (Again is at the top of the second column of keys on the left side of a sun keyboard) However, if I run the client in a VNC session, I have no problem getting to the qemu monitor/console. Thoughts? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
re: [Qemu-devel] problem adding usb device
stracing qemu showed, that the corresponding device file in /proc could not be opened. A pcscd already grepped it. After stopping pcscd the smartcard was available to the client. Norbert Wegener my host operating system is ubuntu. I have an usb smartcard reader attached. qemu version is 0.9.0. qemu monitor shows me: info usbhost Device 2.2, speed 12Mb/s Class 00: USB device 046d:c042, USB Gaming Mouse Device 1.5, speed 12 Mb/s Class 00: USB device 08e6:3437, USB SmratCard Reader When I want to make this reader available to the client system using usb_add host:08e6:3437 I get the Could not add USB device 'host:08e6:3437 In the controlling terminal, where I started qemu, at the saem time I get: usb_host: device already grabbed Nevertheless, info usb show nothing.Sad ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU/pc and scsi disks
There's also no reason to limit to 7 disks, and we should support scsi cdroms. The reason for 7 is the number of available id on the scsi bus. For wide scsi it is 15. I wouldn't bet on wide scsi working. For PCI based systems you can add more host adapters to get more devices. I haven't actually tested this, but it should work. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get 1280x1024 display from guest running Xorg?
On Wednesday 21 Feb 2007, Ben Taylor wrote: Robin Atwood [EMAIL PROTECTED] wrote: This has been driving me mad! I have just installed Solaris 10 under Qemu and specified the Xorg server to be used. I created xorg.conf with xorgconfig and X started fine at 1024x768 using the Cirrus driver. When I edited xorg.conf to specify a 1280x1024 display, the Xorg.0.log file showed no mode. You may have to define HorizSync and VertRefresh in the xorg.conf file. I have a nexenta alpha 6 with updates that just comes up in 1280x800 by setting the HorizSync value in the xorg.conf. Now, I have both Win XP and Plan 9 running at 1280x1024, so I booted up XP and poked around the Display/Settings dialog and determined XP was running the display at 1280x1024 at 43Hz interlaced and 16 bit colour. So you also need to define DefaultDepth in the xorg.conf file. So, using the handy http://xtiming.sourceforge.net site, I generated a mode line like XP's and added it to the xorg.conf file. X refused the interlaced mode so I tried an uninterlaced one at 43Hz. That kind of worked but only rendered half the screen! Everything else I tried got rejected as bad mode... Since the virtual monitor doesn't specify EDID, it is unlikely to be able to handle resolutions over the basic ones. I know that a while ago (maybe 18 months) I was able to get something like 1156x864 out of the adapter with early versions of Solaris express. . So does someone have a magic modeline or xorg.conf to get Xorg going in a guest at high-res? There's another guy on the Linux-under-Qemu forum with the same problem hosting Ubuntu. I am using qemu 0.9, FWIW. Probably a combination of HorizSync/VertRefresh in the monitor section, DefaultDepth in the Screen section, and a mode line, you might get what you want. Solved it, and it was so simple! There is a qemu CLI option -std-vga which causes an enhanced Bochs VGA adaptor to be emulated. So, specify that when you boot, use the VESA driver in xorg.conf and the default 1280x1024 mode now works. From the man page: -std-vga Simulate a standard VGA card with Bochs VBE extensions (default is Cirrus Logic GD5446 PCI VGA). If your guest OS supports the VESA 2.0 VBE extensions (e.g. Windows XP) and if you want to use high resolution modes (= 1280x1024x16) then you should use this option. I think this is a recent update because I recall looking at this option and deciding it was not what I needed. Or, I am going blind... Cheers... -Robin. -- -- Robin Atwood. Ship me somewheres east of Suez, where the best is like the worst, Where there ain't no Ten Commandments an' a man can raise a thirst from Mandalay by Rudyard Kipling -- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] (no subject)
Hey guys thanks for a great product. I don't know if its been documented already but I was able to install windows xp on qemu with a HP Laptop Restore disk. I did need my key from the bottom. I hope this meets the EULA . My laptop did die last year and I have been wondering what I could do with that extra copy. Will Qemu boot a .iso file like ubuntu? Thank___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU/pc and scsi disks
Paul Brook wrote: There's also no reason to limit to 7 disks, and we should support scsi cdroms. The reason for 7 is the number of available id on the scsi bus. For wide scsi it is 15. I wouldn't bet on wide scsi working. For PCI based systems you can add more host adapters to get more devices. I haven't actually tested this, but it should work. I think most people agree that we need a config file. I haven't seen any comments on my config file patch though. So, any comments on that patch? Any requirements on a format? Regards, Anthony Liguori Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] pcnet32 driver change, please test
Hello All,
I changed the pcnet32 driver to get rid of bitfields in its
implementation, now it works also on big endian host systems.
I tested only the 32 bit mode which is used by MIPS/Malta, and
I'm not sure if it still works in Lance mode (as e.g. used on SPARC).
So please test if it still works.
Thiemo
Index: qemu-cvs/hw/pcnet.c
===
--- qemu-cvs.orig/hw/pcnet.c
+++ qemu-cvs/hw/pcnet.c
@@ -77,14 +77,6 @@
void *dma_opaque;
};
-/* XXX: using bitfields for target memory structures is almost surely
- not portable, so it should be suppressed ASAP */
-#ifdef __GNUC__
-#define PACKED_FIELD(A) A __attribute__ ((packed))
-#else
-#error FixMe
-#endif
-
struct qemu_ether_header {
uint8_t ether_dhost[6];
uint8_t ether_shost[6];
@@ -183,223 +175,291 @@
};
struct pcnet_TMD {
-struct {
-unsigned tbadr:32;
-} tmd0;
-struct {
-unsigned PACKED_FIELD(bcnt:12), PACKED_FIELD(ones:4),
PACKED_FIELD(res:7), PACKED_FIELD(bpe:1);
-unsigned PACKED_FIELD(enp:1), PACKED_FIELD(stp:1),
PACKED_FIELD(def:1), PACKED_FIELD(one:1);
-unsigned PACKED_FIELD(ltint:1), PACKED_FIELD(nofcs:1),
PACKED_FIELD(err:1), PACKED_FIELD(own:1);
-} tmd1;
-struct {
-unsigned PACKED_FIELD(trc:4), PACKED_FIELD(res:12);
-unsigned PACKED_FIELD(tdr:10), PACKED_FIELD(rtry:1),
PACKED_FIELD(lcar:1);
-unsigned PACKED_FIELD(lcol:1), PACKED_FIELD(exdef:1),
PACKED_FIELD(uflo:1), PACKED_FIELD(buff:1);
-} tmd2;
-struct {
-unsigned res:32;
-} tmd3;
+uint32_t tbadr;
+int16_t length;
+int16_t status;
+uint32_t misc;
+uint32_t res;
};
+#define TMDL_BCNT_MASK 0x0fff
+#define TMDL_BCNT_SH0
+#define TMDL_ONES_MASK 0xf000
+#define TMDL_ONES_SH12
+
+#define TMDS_BPE_MASK 0x0080
+#define TMDS_BPE_SH 7
+#define TMDS_ENP_MASK 0x0100
+#define TMDS_ENP_SH 8
+#define TMDS_STP_MASK 0x0200
+#define TMDS_STP_SH 9
+#define TMDS_DEF_MASK 0x0400
+#define TMDS_DEF_SH 10
+#define TMDS_ONE_MASK 0x0800
+#define TMDS_ONE_SH 11
+#define TMDS_LTINT_MASK 0x1000
+#define TMDS_LTINT_SH 12
+#define TMDS_NOFCS_MASK 0x2000
+#define TMDS_NOFCS_SH 13
+#define TMDS_ERR_MASK 0x4000
+#define TMDS_ERR_SH 14
+#define TMDS_OWN_MASK 0x8000
+#define TMDS_OWN_SH 15
+
+#define TMDM_TRC_MASK 0x000f
+#define TMDM_TRC_SH 0
+#define TMDM_TDR_MASK 0x03ff
+#define TMDM_TDR_SH 16
+#define TMDM_RTRY_MASK 0x0400
+#define TMDM_RTRY_SH26
+#define TMDM_LCAR_MASK 0x0800
+#define TMDM_LCAR_SH27
+#define TMDM_LCOL_MASK 0x1000
+#define TMDM_LCOL_SH28
+#define TMDM_EXDEF_MASK 0x2000
+#define TMDM_EXDEF_SH 29
+#define TMDM_UFLO_MASK 0x4000
+#define TMDM_UFLO_SH30
+#define TMDM_BUFF_MASK 0x8000
+#define TMDM_BUFF_SH31
+
struct pcnet_RMD {
-struct {
-unsigned rbadr:32;
-} rmd0;
-struct {
-unsigned PACKED_FIELD(bcnt:12), PACKED_FIELD(ones:4),
PACKED_FIELD(res:4);
-unsigned PACKED_FIELD(bam:1), PACKED_FIELD(lafm:1),
PACKED_FIELD(pam:1), PACKED_FIELD(bpe:1);
-unsigned PACKED_FIELD(enp:1), PACKED_FIELD(stp:1),
PACKED_FIELD(buff:1), PACKED_FIELD(crc:1);
-unsigned PACKED_FIELD(oflo:1), PACKED_FIELD(fram:1),
PACKED_FIELD(err:1), PACKED_FIELD(own:1);
-} rmd1;
-struct {
-unsigned PACKED_FIELD(mcnt:12), PACKED_FIELD(zeros:4);
-unsigned PACKED_FIELD(rpc:8), PACKED_FIELD(rcc:8);
-} rmd2;
-struct {
-unsigned res:32;
-} rmd3;
+uint32_t rbadr;
+int16_t buf_length;
+int16_t status;
+uint32_t msg_length;
+uint32_t res;
};
+#define RMDL_BCNT_MASK 0x0fff
+#define RMDL_BCNT_SH0
+#define RMDL_ONES_MASK 0xf000
+#define RMDL_ONES_SH12
+
+#define RMDS_BAM_MASK 0x0010
+#define RMDS_BAM_SH 4
+#define RMDS_LFAM_MASK 0x0020
+#define RMDS_LFAM_SH5
+#define RMDS_PAM_MASK 0x0040
+#define RMDS_PAM_SH 6
+#define RMDS_BPE_MASK 0x0080
+#define RMDS_BPE_SH 7
+#define RMDS_ENP_MASK 0x0100
+#define RMDS_ENP_SH 8
+#define RMDS_STP_MASK 0x0200
+#define RMDS_STP_SH 9
+#define RMDS_BUFF_MASK 0x0400
+#define RMDS_BUFF_SH10
+#define RMDS_CRC_MASK 0x0800
+#define RMDS_CRC_SH 11
+#define RMDS_OFLO_MASK 0x1000
+#define RMDS_OFLO_SH12
+#define RMDS_FRAM_MASK 0x2000
+#define RMDS_FRAM_SH13
+#define RMDS_ERR_MASK 0x4000
+#define RMDS_ERR_SH 14
+#define RMDS_OWN_MASK 0x8000
+#define RMDS_OWN_SH 15
+
+#define RMDM_MCNT_MASK 0x0fff
+#define RMDM_MCNT_SH0
+#define RMDM_ZEROS_MASK 0xf000
+#define RMDM_ZEROS_SH 12
+#define RMDM_RPC_MASK 0x00ff
+#define RMDM_RPC_SH 16
+#define RMDM_RCC_MASK 0xff00
+#define RMDM_RCC_SH 24
+
+#define SET_FIELD(regp, name, field, value) \
+ (*(regp) = (*(regp) ~(name ## _ ## field ## _MASK)) \
+ | ((value) name ## _ ## field ## _SH))
+
+#define
[Qemu-devel] qemu/hw mips_malta.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/02 20:36:23 Modified files: hw : mips_malta.c Log message: Fix wrong interrupt number for the second serial interface. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemur1=1.13r2=1.14 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
Thiemo Seufer wrote:
Hello All,
I changed the pcnet32 driver to get rid of bitfields in its
implementation, now it works also on big endian host systems.
I tested only the 32 bit mode which is used by MIPS/Malta, and
I'm not sure if it still works in Lance mode (as e.g. used on SPARC).
So please test if it still works.
I forgot to delete a line of debug output, updated.
Thiemo
Index: qemu-work/hw/pcnet.c
===
--- qemu-work.orig/hw/pcnet.c 2007-03-01 21:15:54.0 +
+++ qemu-work/hw/pcnet.c2007-03-02 20:13:42.0 +
@@ -77,14 +77,6 @@
void *dma_opaque;
};
-/* XXX: using bitfields for target memory structures is almost surely
- not portable, so it should be suppressed ASAP */
-#ifdef __GNUC__
-#define PACKED_FIELD(A) A __attribute__ ((packed))
-#else
-#error FixMe
-#endif
-
struct qemu_ether_header {
uint8_t ether_dhost[6];
uint8_t ether_shost[6];
@@ -183,223 +175,291 @@
};
struct pcnet_TMD {
-struct {
-unsigned tbadr:32;
-} tmd0;
-struct {
-unsigned PACKED_FIELD(bcnt:12), PACKED_FIELD(ones:4),
PACKED_FIELD(res:7), PACKED_FIELD(bpe:1);
-unsigned PACKED_FIELD(enp:1), PACKED_FIELD(stp:1),
PACKED_FIELD(def:1), PACKED_FIELD(one:1);
-unsigned PACKED_FIELD(ltint:1), PACKED_FIELD(nofcs:1),
PACKED_FIELD(err:1), PACKED_FIELD(own:1);
-} tmd1;
-struct {
-unsigned PACKED_FIELD(trc:4), PACKED_FIELD(res:12);
-unsigned PACKED_FIELD(tdr:10), PACKED_FIELD(rtry:1),
PACKED_FIELD(lcar:1);
-unsigned PACKED_FIELD(lcol:1), PACKED_FIELD(exdef:1),
PACKED_FIELD(uflo:1), PACKED_FIELD(buff:1);
-} tmd2;
-struct {
-unsigned res:32;
-} tmd3;
+uint32_t tbadr;
+int16_t length;
+int16_t status;
+uint32_t misc;
+uint32_t res;
};
+#define TMDL_BCNT_MASK 0x0fff
+#define TMDL_BCNT_SH0
+#define TMDL_ONES_MASK 0xf000
+#define TMDL_ONES_SH12
+
+#define TMDS_BPE_MASK 0x0080
+#define TMDS_BPE_SH 7
+#define TMDS_ENP_MASK 0x0100
+#define TMDS_ENP_SH 8
+#define TMDS_STP_MASK 0x0200
+#define TMDS_STP_SH 9
+#define TMDS_DEF_MASK 0x0400
+#define TMDS_DEF_SH 10
+#define TMDS_ONE_MASK 0x0800
+#define TMDS_ONE_SH 11
+#define TMDS_LTINT_MASK 0x1000
+#define TMDS_LTINT_SH 12
+#define TMDS_NOFCS_MASK 0x2000
+#define TMDS_NOFCS_SH 13
+#define TMDS_ERR_MASK 0x4000
+#define TMDS_ERR_SH 14
+#define TMDS_OWN_MASK 0x8000
+#define TMDS_OWN_SH 15
+
+#define TMDM_TRC_MASK 0x000f
+#define TMDM_TRC_SH 0
+#define TMDM_TDR_MASK 0x03ff
+#define TMDM_TDR_SH 16
+#define TMDM_RTRY_MASK 0x0400
+#define TMDM_RTRY_SH26
+#define TMDM_LCAR_MASK 0x0800
+#define TMDM_LCAR_SH27
+#define TMDM_LCOL_MASK 0x1000
+#define TMDM_LCOL_SH28
+#define TMDM_EXDEF_MASK 0x2000
+#define TMDM_EXDEF_SH 29
+#define TMDM_UFLO_MASK 0x4000
+#define TMDM_UFLO_SH30
+#define TMDM_BUFF_MASK 0x8000
+#define TMDM_BUFF_SH31
+
struct pcnet_RMD {
-struct {
-unsigned rbadr:32;
-} rmd0;
-struct {
-unsigned PACKED_FIELD(bcnt:12), PACKED_FIELD(ones:4),
PACKED_FIELD(res:4);
-unsigned PACKED_FIELD(bam:1), PACKED_FIELD(lafm:1),
PACKED_FIELD(pam:1), PACKED_FIELD(bpe:1);
-unsigned PACKED_FIELD(enp:1), PACKED_FIELD(stp:1),
PACKED_FIELD(buff:1), PACKED_FIELD(crc:1);
-unsigned PACKED_FIELD(oflo:1), PACKED_FIELD(fram:1),
PACKED_FIELD(err:1), PACKED_FIELD(own:1);
-} rmd1;
-struct {
-unsigned PACKED_FIELD(mcnt:12), PACKED_FIELD(zeros:4);
-unsigned PACKED_FIELD(rpc:8), PACKED_FIELD(rcc:8);
-} rmd2;
-struct {
-unsigned res:32;
-} rmd3;
+uint32_t rbadr;
+int16_t buf_length;
+int16_t status;
+uint32_t msg_length;
+uint32_t res;
};
+#define RMDL_BCNT_MASK 0x0fff
+#define RMDL_BCNT_SH0
+#define RMDL_ONES_MASK 0xf000
+#define RMDL_ONES_SH12
+
+#define RMDS_BAM_MASK 0x0010
+#define RMDS_BAM_SH 4
+#define RMDS_LFAM_MASK 0x0020
+#define RMDS_LFAM_SH5
+#define RMDS_PAM_MASK 0x0040
+#define RMDS_PAM_SH 6
+#define RMDS_BPE_MASK 0x0080
+#define RMDS_BPE_SH 7
+#define RMDS_ENP_MASK 0x0100
+#define RMDS_ENP_SH 8
+#define RMDS_STP_MASK 0x0200
+#define RMDS_STP_SH 9
+#define RMDS_BUFF_MASK 0x0400
+#define RMDS_BUFF_SH10
+#define RMDS_CRC_MASK 0x0800
+#define RMDS_CRC_SH 11
+#define RMDS_OFLO_MASK 0x1000
+#define RMDS_OFLO_SH12
+#define RMDS_FRAM_MASK 0x2000
+#define RMDS_FRAM_SH13
+#define RMDS_ERR_MASK 0x4000
+#define RMDS_ERR_SH 14
+#define RMDS_OWN_MASK 0x8000
+#define RMDS_OWN_SH 15
+
+#define RMDM_MCNT_MASK 0x0fff
+#define RMDM_MCNT_SH0
+#define RMDM_ZEROS_MASK 0xf000
+#define RMDM_ZEROS_SH 12
+#define RMDM_RPC_MASK 0x00ff
+#define RMDM_RPC_SH 16
+#define RMDM_RCC_MASK 0xff00
+#define RMDM_RCC_SH 24
+
+#define
[Qemu-devel] PATCH: darwin-user syscalls
Handling extra signals in syscall.c/syscalls.h. Patch is attached. Thanks, Ilya Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather qemu_0.9.0_darwin-user_signal.patch Description: 2083588519-qemu_0.9.0_darwin-user_signal.patch ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
On Fri, Mar 02, 2007 at 08:09:49PM +, Thiemo Seufer wrote:
Hello All,
I changed the pcnet32 driver to get rid of bitfields in its
implementation, now it works also on big endian host systems.
I find this curious... C99 (6.7.2.1) says the allocation order of
bit-fields within a unit (high-order to low-order or low-order to
high-order) is implementation defined. I can't see any requirement
for this, so is it just convention that bitfields on big endian systems
start from the most significant bit, and those on little endian systems
start from the least significant bit? (My thinking is that endianness
usually refers to byte ordering and not so much bit ordering.)
I ask this because I'd seen some code of the form:
#ifdef WORDS_BIGENDIAN
typedef struct { int b7:1; int b6:1; int b5:1; int b4:1;
int b3:1; int b2:1; int b1:1; int b0:1; } foo;
#else
typedef struct { int b0:1; int b1:1; int b2:1; int b3:1;
int b4:1; int b5:1; int b6:1; int b7:1; } foo;
#endif
and I had assumed that this was sheer nonsense...
I tested only the 32 bit mode which is used by MIPS/Malta, and
I'm not sure if it still works in Lance mode (as e.g. used on SPARC).
So please test if it still works.
I've tried this patch with a SPARC target running Etch, with an i386 host.
No problems so far.
(FWIW, I have noticed one bug, but it's *not* a problem with this patch.
In the Sarge installer, I see Error while running 'modprobe -v sunlance'.
ISTR that if I use the netinstall iso and persist with the installation,
Lance works after the reboot. This problem doesn't seem to affect Etch.)
Thanks,
--
Stuart Brady
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
Thiemo Seufer wrote: Thiemo Seufer wrote: Hello All, I changed the pcnet32 driver to get rid of bitfields in its implementation, now it works also on big endian host systems. I tested only the 32 bit mode which is used by MIPS/Malta, and I'm not sure if it still works in Lance mode (as e.g. used on SPARC). So please test if it still works. I forgot to delete a line of debug output, updated. It seems that you made some unnecessary changes (why did you changed the code in pcnet_init ?). Regards, Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
In message: [EMAIL PROTECTED] Stuart Brady [EMAIL PROTECTED] writes: : On Fri, Mar 02, 2007 at 08:09:49PM +, Thiemo Seufer wrote: : Hello All, : : I changed the pcnet32 driver to get rid of bitfields in its : implementation, now it works also on big endian host systems. : : I find this curious... C99 (6.7.2.1) says the allocation order of : bit-fields within a unit (high-order to low-order or low-order to : high-order) is implementation defined. I can't see any requirement : for this, so is it just convention that bitfields on big endian systems : start from the most significant bit, and those on little endian systems : start from the least significant bit? (My thinking is that endianness : usually refers to byte ordering and not so much bit ordering.) This is a convention that goes back a very long ways. It was this way in the mid 1980's, and has remained true through today. I've personally observed this to be the case on many different MIPS compilers, ARM compilers and SPARC compilers over the years. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
: I find this curious... C99 (6.7.2.1) says the allocation order of : bit-fields within a unit (high-order to low-order or low-order to : high-order) is implementation defined. I can't see any requirement : for this, so is it just convention that bitfields on big endian systems : start from the most significant bit, and those on little endian systems : start from the least significant bit? (My thinking is that endianness : usually refers to byte ordering and not so much bit ordering.) This is a convention that goes back a very long ways. It was this way in the mid 1980's, and has remained true through today. I've personally observed this to be the case on many different MIPS compilers, ARM compilers and SPARC compilers over the years. I'm fairly sure I've seen targets that use other bitfield orderings, though I can't remember offhand what they were. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
In message: [EMAIL PROTECTED] Paul Brook [EMAIL PROTECTED] writes: : : I find this curious... C99 (6.7.2.1) says the allocation order of : : bit-fields within a unit (high-order to low-order or low-order to : : high-order) is implementation defined. I can't see any requirement : : for this, so is it just convention that bitfields on big endian systems : : start from the most significant bit, and those on little endian systems : : start from the least significant bit? (My thinking is that endianness : : usually refers to byte ordering and not so much bit ordering.) : : This is a convention that goes back a very long ways. It was this way : in the mid 1980's, and has remained true through today. I've : personally observed this to be the case on many different MIPS : compilers, ARM compilers and SPARC compilers over the years. : : I'm fairly sure I've seen targets that use other bitfield orderings, though I : can't remember offhand what they were. None of them are supported by FreeBSD and/or NetBSD... Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
