I am using two UDPCast cds (one sender, one receiver) to boot two Intel MacBooks in an
attempt to clone one to the other.
Ok, it didn't exactly work out 100%
Turns out when I boot my custom UDPCast cds, the SATA Disk Driver and the Marvell Yukon
Network chipset in the MacBook fight with each other for IRQ assignment, and UDPCast
finally just turns one IRQ off. IRQ 10.
Meanwhile, I attached an external Microsoft USB 105-Key Keyboard to a MacBook to see if
UDPCast would work with it and it did. But the "repeated ghost keystrokes" are
still happening that plague the internal MacBook keyboard. So it seems that UDPCast is
not playing well with the USB Controller in the MacBooks. It's not the keyboard.
It's the controller. If I can identify the USB controller manufacturer, I might be
able to insert the proper USB kernel module at boottime and finally be able to type into
UDPCast after it boots. That would make it easier to guide through the menu-driven system
that UDPCast uses in default-mode. It would also let me read the system boot log with the
limited shell that I call up.
So as for my experiment, both MacBooks boot up into a state that is ready-to-go, but they
can't see each other on the network. This is most likely due to the IRQ conflict
I'm getting from the SATA drive vs. the Network chipset.
Network ports do light up on the switch I'm using, but the two computers won't see
each other.
I've even tried two different switches in case one had some kind of internal circuit
that blocked Multicast Packet Storms or something...
Has anyone tried UDPCast cloning of Intel-based MacBooks?
Show replies by date
I have found a solution to this problem, but it involved using the latest PLD Linux Rescue
CD.
Transfers of an 80Gb hard drive partitioned into EFI, HFS, and NTFS work rather flawlessly
from one Intel MacBook to many.
One small annoyance: I am having excessive re-xmits, most likely due to an improper kernel
module (sky2) or some setting in eth0. I have managed to reduce the re-xmit rate to about
6% from 50% using --nosync on the targets. However, this is still unacceptable, as the
throughput degrades slowly during the multicast transfer.
Nevertheless, PLD Linux Rescue CD seems to support the Apple USB Keyboard as well as
internal Gigabit Ethernet chip.
-----Original Message-----
From: Humberto J. Varela
Sent: Thu 4/12/2007 7:56 PM
To: udpcast(a)udpcast.linux.lu
Subject: Intel Macbook
I am using two UDPCast cds (one sender, one receiver) to boot two Intel MacBooks in an
attempt to clone one to the other.
Ok, it didn't exactly work out 100%
Turns out when I boot my custom UDPCast cds, the SATA Disk Driver and the Marvell Yukon
Network chipset in the MacBook fight with each other for IRQ assignment, and UDPCast
finally just turns one IRQ off. IRQ 10.
Meanwhile, I attached an external Microsoft USB 105-Key Keyboard to a MacBook to see if
UDPCast would work with it and it did. But the "repeated ghost keystrokes" are
still happening that plague the internal MacBook keyboard. So it seems that UDPCast is
not playing well with the USB Controller in the MacBooks. It's not the keyboard.
It's the controller. If I can identify the USB controller manufacturer, I might be
able to insert the proper USB kernel module at boottime and finally be able to type into
UDPCast after it boots. That would make it easier to guide through the menu-driven system
that UDPCast uses in default-mode. It would also let me read the system boot log with the
limited shell that I call up.
So as for my experiment, both MacBooks boot up into a state that is ready-to-go, but they
can't see each other on the network. This is most likely due to the IRQ conflict
I'm getting from the SATA drive vs. the Network chipset.
Network ports do light up on the switch I'm using, but the two computers won't see
each other.
I've even tried two different switches in case one had some kind of internal circuit
that blocked Multicast Packet Storms or something...
Has anyone tried UDPCast cloning of Intel-based MacBooks?