Re: NPF on domU - more clarity required
jnem...@cue.bc.ca (John Nemeth) writes: I understood what you meant, I was just thinking about the complexity of dealing with everything. BTW, pvgrub doesn't use PV ops. It sits in dom0 and uses regular filesystem ops to extract stuff from the domU's disk. That sounds like a mixup. pygrub - copies kernel/initrd from the domU image using regular file operations to a temporary place, and then just starts a VM from that. pvgrub - a VM is started with pvgrub as kernel which then chainloads kernel/initrd inside the VM. It is actually a version of grub that uses PV operations.
Re: NPF on domU - more clarity required
On Sun, Dec 28, 2014 at 2:40 AM, Greg Troxel g...@ir.bbn.com wrote: John Nemeth jnem...@cue.bc.ca writes: On Dec 27, 10:56am, Greg Troxel wrote: One option would be to turn /boot into something that works like pvgrub. This shouldn't actually be that hard. This is something that I added to the project list a while ago: http://wiki.netbsd.org/projects/project/xenboot/ Of course, this would require convincing the VPS operator to use it. True, but convincing someone to write it and use it is far harder... I think just extending the ufs code in pygrub to understand changes since Solaris might be relatively straightforward. http://xenbits.xensource.com/hg/xen-unstable.hg/file/bca284f67702/tools/libfsimage/ufs/fsys_ufs.c (There are also plans that pygrub should run on NetBSD rump kernel, at which point using the actual NetBSD ffs driver might be possible, but thats away off). Justin
Re: compact flash in pcmcia slot
Hi. Actually no pcmcia cards worked on this machine. Tried wi(4) and ne(4) also. So after talking with Michael van Elst on IRCnet I found pr #32327 and #32328. Adding options RBUS_IO_BASE=0xa00 options RBUS_IO_SIZE=0x0ff made everything work as it should. Having these (commented out) in amd64 and i386 GENERIC would have simplified this enormously. With a suitable comment ofc. Something like # Uncomment if pcmcia cards do not attach #options RBUS_IO_BASE=0xa00 #options RBUS_IO_SIZE=0x0ff Thoughts? /herdware --- On Sat, 12/27/14, Björn Johannesson rherdw...@yahoo.com wrote: From: Björn Johannesson rherdw...@yahoo.com Subject: compact flash in pcmcia slot To: netbsd-users@netbsd.org Date: Saturday, December 27, 2014, 10:57 PM Hi. So I have this Thinkpad T61 with netbsd-7 on it. I put a cf-card in a pcmcia adapter for hpcarm/hpcsh use. However it did not probe it correctly, it did however in another Thinkpad (A31). Both running netbsd-7 kernels. I enabled PCMCIADEBUG and PCMCIACISDEBUG in a GENERIC kernel and this is the output. pcmcia0: CIS version PCMCIA 2.0 or 2.1 pcmcia0: CIS info: SanDisk, SDP, 5/3 0.6 pcmcia0: Manufacturer code 0x45, product 0x401 pcmcia0: function 0: fixed disk(ata), ccr addr 200 mask f pcmcia0: function 0, config table entry 0: memory card; irq mask 0; memspace 0-7ff; maxtwins 1; mwait_required rdybsy_active powerdown pcmcia0: function 0, config table entry 1: I/O card; irq mask ; iomask 4, iospace 0-f; memspace 0-7ff; maxtwins 1; rdybsy_active io8 io16 irqshare irqpulse irqlevel powerdown pcmcia0: function 0, config table entry 2: I/O card; irq mask 4000; iomask a, iospace 1f0-1f7 3f6-3f7; memspace 0-7ff; maxtwins 1; rdybsy_active io8 io16 irqshare irqpulse irqlevel powerdown pcmcia0: function 0, config table entry 3: I/O card; irq mask 4000; iomask a, iospace 170-177 376-377; memspace 0-7ff; maxtwins 1; rdybsy_active io8 io16 irqshare irqpulse irqlevel powerdown pcmcia0: function 0, config table entry 7: I/O card; irq mask 4000; iomask a, iospace 170-177 376-377; memspace 0-7ff; maxtwins 1; rdybsy_active io8 io16 irqshare irqpulse irqlevel powerdown wdc2 at pcmcia0 function 0: SanDisk, SDP, 5/3 0.6 wdc2: i/o mapped mode atabus2 at wdc2 channel 0 As you can see no wd(4) device is ever attached to atabus2, it is however attached in the A31... Both are running netbsd-7 GENERIC kernels. What can be wrong? I just found the charger for my Jornada 720 and Jornada 690 and wanted to try nebsd-7 on them. This is why I needed to use the compact flash to pcmcia adapter. FWIW, the 720 (hpcarm) is totally fubar and the 690 (hpcsh) seems to work fine with netbsd-7. /herdware
Re: compact flash in pcmcia slot
Having these (commented out) in amd64 and i386 GENERIC would have simplified this enormously. With a suitable comment ofc. Something like # Uncomment if pcmcia cards do not attach #options RBUS_IO_BASE=0xa00 #options RBUS_IO_SIZE=0x0ff I can see your point, but if every workaround were present, the config file would get unwieldy. Also, see cardbus(4) and pcmcia(4). Similar issues are documented (based on Thinkpad 600 and 600E!). pgpujGTRpOTP9.pgp Description: PGP signature
Re: compact flash in pcmcia slot
On 28 December 2014 at 16:48, Greg Troxel g...@ir.bbn.com wrote:
Having these (commented out) in amd64 and i386 GENERIC would have
simplified this
enormously. With a suitable comment ofc. Something like
# Uncomment if pcmcia cards do not attach
#options RBUS_IO_BASE=0xa00
#options RBUS_IO_SIZE=0x0ff
I can see your point, but if every workaround were present, the config
file would get unwieldy.
Also, see cardbus(4) and pcmcia(4). Similar issues are documented
(based on Thinkpad 600 and 600E!).
Would it make sense to have a known set of overrides for
RBUS_IO_BASE and PCIC_ISA_ALLOC_IOBASE? Even if it is keyed by something
like machdep.dmi.system-{vendor,product,version} or similar, it would be
nice to be able to get it right automatically in a few more cases.
Alternatively is it possible to map it and poke it to see if its working,
then switch to a fallback address if not?
Re: compact flash in pcmcia slot
David Brownlee a...@absd.org writes:
Would it make sense to have a known set of overrides for
RBUS_IO_BASE and PCIC_ISA_ALLOC_IOBASE? Even if it is keyed by something
like machdep.dmi.system-{vendor,product,version} or similar, it would be
nice to be able to get it right automatically in a few more cases.
Definitely, or better yet code to guess the values at boot time.
Alternatively is it possible to map it and poke it to see if its working,
then switch to a fallback address if not?
Probably, but the trick is to check the slot without a device.
pgpjCfswn_Btw.pgp
Description: PGP signature
Re: compact flash in pcmcia slot
Björn Johannesson rherdw...@yahoo.com writes: Also, see cardbus(4) and pcmcia(4). Similar issues are documented (based on Thinkpad 600 and 600E!). Yes. However RBUS_IO_BASE and RBUS_IO_SIZE are not documented anywhere as far as I can see. Only RBUS_MIN_START. So it should go in man/man4/cardbus.4 ? Probably. If you want to read the code and send a patch, I'll apply it (or explain why not). pgp_cjbUDv8aF.pgp Description: PGP signature
Re: viaide1: channel 0: reset failed for drive 0
On Tue, Dec 23, 2014 at 01:41:33PM -0700, Stephen Fisher wrote: On Sun, Dec 21, 2014 at 02:29:47PM -0500, Greg Troxel wrote: Scan the FreeBSD driver's CVS history, to see if you can find a commit that looks relevant. Will do. I'll compare FreeBSD's driver to NetBSD's as well. I studied the NetBSD viaide driver for a while and even tried changing the code a little bit (skip checking for BSY flag for example) and it still didn't work. The reset failed. The BSY flag never cleared. Something just didn't seem right, so I looked at FreeBSD's code, but it looks totally different because of the CAM sub-system that they use now. I wasn't certain if it was NetBSD's viaide or the wdc driver at fault, but then I had an idea to disable viaide and let the pciide driver take over, and it works! wd0 was found right away and I've installed the system now. Does that mean that wdc probably isn't at fault and I should focus on the viaide driver?
Re: viaide1: channel 0: reset failed for drive 0
On Dec 28, 6:03pm, Stephen Fisher wrote: } On Tue, Dec 23, 2014 at 01:41:33PM -0700, Stephen Fisher wrote: } On Sun, Dec 21, 2014 at 02:29:47PM -0500, Greg Troxel wrote: } } Scan the FreeBSD driver's CVS history, to see if you can find a } commit that looks relevant. } } Will do. I'll compare FreeBSD's driver to NetBSD's as well. } } I studied the NetBSD viaide driver for a while and even tried changing } the code a little bit (skip checking for BSY flag for example) and it } still didn't work. The reset failed. The BSY flag never cleared. } Something just didn't seem right, so I looked at FreeBSD's code, but it } looks totally different because of the CAM sub-system that they use now. } I wasn't certain if it was NetBSD's viaide or the wdc driver at fault, } but then I had an idea to disable viaide and let the pciide driver take } over, and it works! wd0 was found right away and I've installed the } system now. Does that mean that wdc probably isn't at fault and I } should focus on the viaide driver? I've noticed the issue with ahcisata with an Intel chipset. I think other's have noticed the problem as well. Now, this doesn't mean that there isn't a problem with viaide as stuff tends to get copied between different drivers, but it might be a good idea to look for commonality. One significant thing that stands out is that when you switched to pciide you stopped doing DMA. This may or may not be relevent. }-- End of excerpt from Stephen Fisher
