Re: [Soekris] net6501: Timer problems with Debian, no HPET support detected
Peter Neubauer wrote: > Linux depends on an ACPI BIOS to provide configuration for the HPET. The > net6501 does not support ACPI, so Linux does not use the HPET. Great news on the patch. What is the reason for not having ACPI ? Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] net5501: Sandisk extreme CF 32 GB does not work
AG wrote: > I ordered a Sundisk Ultra 16 GB CF-Card. This take the net5501. > I have installed Linux (Debian squeeze) with grub. I have no problems to > boot from the CF-Card > with grub. Can you please post your BIOS bootup output (for the Sundisk Ultra 16 Gb card). Like you did for the 32Gb card at the start of this thread. Also can you confirm the exact number of sectors it reports, maybe "cat /proc/partition*" output will do. From your post at the start of this thread, your 32Gb reported: Pri Mas SanDisk SDCFX-032G _ Your other smaller CF card (that worked) reports: Pri Mas SAMSUNG CF/ATA LBA 994-16-32 254 Mbyte From my thread "Debian5/GRUB installation problems" around Aug-2010. Pri Mas SanDisk SDCFH-016G LBA Xlt 1024--63 15638 Mbyte My investigation revealed that GRUB worked fine, so long as my /boot partition was kept small (meaning I had about 7754 Kb). This was too small to be useful (and other bootloaders are not an option for me due to the requirement to remote upgrade a kernel and have remote downgrade and fallback ability by making use of hardware watchdog). I always claimed that the lack of the number of heads in the BIOS output above should be explained and that I think some calculation in the BIOS might be getting messed up when it needed to convert CHS to LBA. I never did get any answer from a couple of phone calls (to the US), a couple of emails (the Soekris HQ) and some detailed information posted into this mailing-list. The only way to prove this bug seemed to be to modify GRUB to add a new command that will load any arbitrary sector from the disk and hexdump it (and/or report any BIOS related errors, and also verify it is really reading data from the disk by pre-filing the buffer with a known byte-pattern and verifying two reads of on the same sector returned the same data). Alas; I never found time to add/implement that new GRUB command so see what happened when I tried to access the sector about 16Mb into the disk. So I think this claim about even larger disks at 32Gb might point to issues with CHS to LBA geometry calculations, especially since you don't even get any kind of size data. It is also interesting that the model number of my card is not too different from yours. I hope for a comBIOS 1.33d fix! or open-source version to allow the customer to investigate/fix fully. Maybe 6501 would have USB support by now and Soekris profits increase due to BIOS development being more about marshaling patches and picking/testing the best than waiting for the limited in-house developer capacity to finally churn out a new version. Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
[Soekris] net6505-xx Intel CPU models ?
Are these the CPU models ?and we know the EM64T support listed at ark.intel.com is not correct with the parts provided as people have reported that EM64T is available. http://ark.intel.com/compare/52493,52491,52497 There are a few other kinds (at 1.0GHz clock) and also a "T" suffix series across the clock ranges. ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] net6501 running 64bit mode
Aragon Gouveia wrote: > | By Kyle Brantley > Do you (or anyone) think there are any advantages to running 64 bit on > a device like this? Seems like a waste of memory to me... The main cost is that increased memory footprint for the same workload. The cost of loading a 64bit value to/from memory is the same as a 32bit value and the cache lines are larger than a single value. If you are a Linux user then check out x32-abi http://sites.google.com/site/x32abi/home this would be ideal, keep the CPU in 64bit mode but the memory model is still 32bit and revise the ABI to be more efficient. This requires the entire user space to be rebuilt on top of gcc/binutils/kernel support. Maybe there are references on the information website pointing to a whole distribution built with it. Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] comBIOS ver. 1.33 sees wrong disk size
Thanks for your reply. Landon Curt Noll wrote: > Here is what fdisk says about one of our cf drives: > > Disk /dev/sda: 16.4 GB, 16391208960 bytes > 255 heads, 63 sectors/track, 1992 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x0003cd75 > > On that system the /boot partition is about 25 cylinders long. > > Device BootStart End Blocks Id > System > /dev/sda1 * 1 25 194560 > 83 > Linux Partition 1 does not end on cylinder boundary. > /dev/sda2 25 199315809537 > 5 Extended > /dev/sda5 19061993700416 82 > Linux swap / Solaris > /dev/sda6 25 190615109120 > 83 Linux > I can do the same but need to make sure all the data is within that first 8Mb then everything is fine. > The debian installer build the 1st partition to a non-cylinder size. > We have manually built a CF with the 1st partition exactly 25 cylinders > and that worked as well. It should not matter since the cylinder > concept in a CF card is what it is worth. :-) It does matter if the boot loader opts to use CHS geometry (when making BIOS calls) for loading sectors and the BIOS translates the CHS to LBA incorrectly (since the CF cards only know LBA at their electrical interface) to give to the card, when the cylinder number is greater than zero. Even if it gets this calculation out by a tiny amount it is enough to cause boot failure. This implies the number of heads issue (about it not being reported on bootup like it is for HDD or even smaller CF cards). This is my guess at the problem. From the lack of number of heads shown during bootup. You are the first to have reported to the list the same kind. I should try a downgrade to comBIOS 1.33 myself (as you report it works for you). Also upgrade to current debian and newer grub (as mine will be a few years old now). Thanks, Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] comBIOS ver. 1.33 sees wrong disk size
Landon Curt Noll wrote: > For what it is worth: We have had not problem booting form SanDisk Extreme > III CF 16 GB cards with a 200 MByte boot partition at the start of the card. > > Our only boot problem is when we have BOTH of these solid state devices > installed: > > SanDisk Extreme III CF card 16 GB > OWC Mercury Extreme Pro SSD 240 GB > > AND the Soekris net5501 is cold booting (when the power has been off for > about 35 seconds or more). > > ... but that is more likely a power / power supply related issue.<<== Still > unresolved I'm afraid. ;-( > > chongo (Landon Curt Noll) /\oo/\ Interested to know what operating system ? Which file system ? and the size of the data that needs to be loaded to bootup. If I presume a Unix kernel is around 2Mb, then if you copy this 5 times and setup individual boot selection, then ensure each one can boot without hanging/error. For me.. as long as every block is within the first track the OS will load up (appearing like everything is fine). Every block for me includes: MBR (obviously) File system superblock Inode information/tables Root and Sub directory blocks Data of the kernel image The file system can be larger, but proving the boot loader never touches the data outside the first 8Mb it will boot fine for me. I don't have any experience with SSD and Soekris. This problematic setup is a SanDisk CF 16 GB with a large 2.5" HDD (maybe 340/500Gb). I can boot up from the HDD fine (obeying the usual 24bit LBA rules). The CF seems to obey 16bit LBA rules. I suspect a mathematical error which may be a quirk of the specific size of my CF card. I am also using comBIOS 1.33c not 1.33. Maybe I should try a downgrade ? It has been suggested to investigate the problem more fully to help debug/fix directly or even to suggest an alternative BIOS to use. I think Soren's concerns regarding making the BIOS open-source are completely unfounded. Who is expecting Soekris Engineering to co-ordinate some open-source singing-all-dancing version of BIOS, I certainly am not. All Soekris Engineering needs to provide and support is a "reference BIOS" that is open-source to boot the devices. If someone wants to fork/maintain/provide an alternative somewhere on the internet, then so be it. But Soekris never needs to install or support this alternative BIOS on their equipment. With the correct kind of licensing Soekris can be assured that it could pick and choose changes from such a fork for use within their own reference BIOS (comBIOS). I would be very happy with that kind of solution. Worst case scenario: an owner has the option to solving a problem themselves. Best case scenario: Soekris Engineering can reduce the budget it spends on BIOS fixes after the initial release. The major work of getting a net platform/hardware would still rest with Soekris getting a reference implementation out the door. A small eco-system appears for supporting features best done in firmware/BIOS. Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] comBIOS ver. 1.33 sees wrong disk size
Landon Curt Noll wrote: > On our net5501-70 we have installed both a: > > SanDisk Extreme III CF card 16 GB > OWC Mercury Extreme Pro SSD 240 GB > > When the Soekris net5501-70 powers on, the net5501 displays on the console port: > > comBIOS ver. 1.33 20070103 Copyright (C) 2000-2007 Soekris Engineering. > > net5501 > > 0512 Mbyte MemoryCPU Geode LX 500 Mhz > > Pri Mas SanDisk SDCFX3-16384LBA Xlt 1024--63 16007 Mbyte > Pri Sla OWC Mercury Extreme Pro SSD LBA Xlt 1024-255-63 134 Gbyte I opened up a thread about 5501 a while ago, exactly the same thing. SanDisk 16M CF card the 5501 is unable to boot from it (with a 1st partition larger than around 8Mb). The tell tale sign is the "Pri Mas SanDisk SDCFX3-16384 LBA Xlt 1024--63 16007 Mbyte" Note the "1024--63" I believe there should be a number of heads in between the dashes. Someone explain why it is missing! Looks like a bug, smells like a bug I have never been able to get the SanDisk 16Mb CF card to be bootable, if any part of the bootup data is outside the _FIRST_ _TRACK_ of the remapped geometry. I included the exact calculations in my multiple emails to this list (please search archives around "[Soekris] Debian5/GRUB installation problems" around Mar-2010). I think the limit was around 8Mb. So Landon, try making the file system (or partition) less than say 255*63=16065(sectors; the sectors in 1 track) 16065(sectors) - 1(sector for MBR) = 16064(sectors) 16064(sectors) / 2 = 8032 Kb of data (@ 512byte sectors) So make your 1st boot partition less than 8032Kb in total length, see if you can bootup now. You might want to make it a little smaller to allow for alignment/rounding of partition tools etc... I think you will be able to bootup now. But 8MB is not a useful size use to allow for fallback/replacement kernels :( Soren Kristensen wrote: > Joel Jaeggli wrote: >> On Jul 5, 2011, at 7:49 AM, der Mouse wrote: >>> I assume there's a 28-bit >>> block number field somewhere or some such, but that's just guessing.) >> >> yes 28bit addressing was supplanted by 48bit lba, but not here clearly. > > Yes, the Soekris comBIOS is currently limited to 28 bit LBA, only a > problem if the boot partition is located higher than the limit. > But while I'm working on the comBIOS anyway I will try to find time to > implement 48 bit LBA for older boards too, it's not really that > complicated I am not sure it is a 28bit v 48bit problem. Even under 28bit addressing it should be possible to boot from a larger part of the disk than 8Mb. The bug in comBIOS 1.33c is more chronic than this. Again please note the "1024--63" in the bootup info, please explain why thre is no number in the middle. I think if you fix that, then yes... it should be possible to bootup from anywhere within the first 28bit addressing. But right now... you can only boot up from the first track, which is 8Mb which is more like 17bit LBA! So please if you get some time please look into the smaller problem then as a nice to have feature look at 48bit LBA. Thanks, Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] net6501 pci-e lanes question
soek...@custodes.info wrote: > > On Jun 6, 2011, at 12:19 AM, Bob Vaughan wrote: > >> Please do not send HTML email to public mailing lists. Maybe the original poster (Bob) meant to say: Please do not send HTML-only email to public mailing lists. This to me is the thing not to do. I am not making a claim that the email Bob is referring to did this, but I can say I'd happily /ignore mailing-list posters who send HTML-only content to mailing-lists. There is a difference between sending a MIME email: * that has 2 parts "related" (a part that is plain text and the other part HTML) and * an email that has a single part (HTML only) Anyhow MIME for the most part does not cause a problem with a non-MIME client (if you can find one) since the plain text part is almost always first and still readable through the MIME boundary markers and part headers. ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] net5501 lockup when sending alot of trafic between two NIC's
Andrey Safonov wrote: > via-rhine kernel module in 2.6.34.1 have race condition somewhere in > logic of interrupt handling :) > I've changed a little bit the driver code and now it works fine for me > but I'm still working on this driver optimization :) Thumbs up from here as well. Maybe you could take a moment to describe the problem to the list here in terms of data or I/O access from bottom half interrupt handlers. Quoting variable names and such. Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] net5501 lockup when sending alot of trafic between two NIC's
David Burgess wrote: > On Fri, Jul 30, 2010 at 9:24 AM, Darryl Miles > wrote: > >> I don't understand the relevance of your citation as an argument against >> anything I've said. What is your understanding of the mechanism I described >> and what is your understanding of section (9.2.2) in relation to that ? > > After reading the wiki page and re-reading section 9.2.2 I don't see > anything to suggest that the tbf is intentionally delaying packets. In > fact, my understanding (and experience) is that by using it to shorten > your egress queue you will actually see reduced latency and improved > interactivity on a congested interface. Okay following the same steps: Wiki: "If fewer than n tokens are available, no tokens are removed from the bucket, and the packet is considered to be non-conformant." Wiki (discussing what to do with non-conformant packets): "They may be enqueued for subsequent transmission when sufficient tokens have accumulated in the bucket." Wiki (going back up top): "A token is added to the bucket every 1 / r seconds." So (staying with the wiki page) for arguments sake "r" maybe 102400 (meaning 102400 tokens per second). Tokens directly correlate to 1:1 for "tokens" to "bytes of network data" (again for argument sake, as per wiki info). So this means that if enqueuing takes place then after you have exhausted your burst volume, your network throughput drops to 102400 bytes/second. Note that tokens are only charged (subtracted from the pool in the bucket) when a packets leaves the outbound interface queue to be committed to the wire. Nothing is charged for being sat in an interface queue, the point of the queue is to hold the packets until they can be sent. This is the principal of what TBF is doing in the kernel. > While tbf is constantly filling a bucket of tokens, the tokens > themselves are not packets. A packet leaving the interface in question > is matched to a token, if available, then queued for transmission. At > this point the packet is out of the control of tbf. Although you can > create a long (and therefore laggy) queue through tbf, any latency > introduced as a result is not the express purpose of the qdisc. At > least that's my undertanding. A token is an accounting unit (re "tokens are not packets"). 1 token relates to some amount of data. In the case of the wiki article the example is 1 token means 1 byte of network data. Usually the unit of network data is raw data that includes IP header overhead and all OSI layers above in the packet. It may not include the whole ethernet frame header since that is not added until the last moment during committal to the wire. It doesn't quite work as you describe. The "packet leaving the interface" is the last thing to happen (I read this to mean, packets end up on the wire), but you talk about it first... then talk about token matching. You don't seem to talk in terms that inside the kernel (when TC is enabled) multiple queues exist. Sure there is a "network device driver outbound queue" (one per interface) and anything that makes it into this queue will be shoved onto the wire ASAP. It is the job of the network interface's device driver to do that all day long (shove packets from this queue on the wire ASAP). But you fail to talk in terms that other packet queues that exist inside TC that are logically separate to each device driver outbound packet queue (but are still associated with an interface). Everytime the LARTC documentation uses the term QDISC it is talking about this logical queues concept. The txqueue that you see in ifconfig, you can think of this as being a logical queue that is separate from the "network device driver outbound queue". The "network device driver outbound queue" is largely unseen by tooling and is more a device driver private queue to get work done. QDISC can be a simple single extra queue or in more complex scenarios can be a hierarchical queue structure (parent/children), the hierarchy exists to allow a single packet to be accounted for by multiple nodes in the queue structure and also allow for complex accounting situations to lend-out/borrow-from tokens with neighboring ancestry. These complex scenarios are not necessary for TBF support. In the case of TBF think of it as an extra queue inside the TBF itself, that only exists when TBF is enabled. This is also the same queue that the Wiki page references in my quote above (when it queues to hold it for later transmission). So as you can understand from this the packet(s) remain in control of the TBF and until the necessary tokens can be charged (subtracted from the bucket) it will not be allowed to pass. When it is allowed to pass, the TBF removes the packet
Re: [Soekris] net5501 lockup when sending alot of trafic between two NIC's
David Burgess wrote: > On Wed, Jul 28, 2010 at 2:50 PM, Darryl Miles > wrote: >> TBF works by deliberately >> delaying the packets as they pass through the device by tiny amounts >> this makes the sender and receiver think the maximum throughput across >> the network is lower than it really is. > > Well, no. At least not according to http://lartc.org/lartc.html > (9.2.2). It should however serve the troubleshooting purpose you > mentioned, just not by the mechanism that you described, at least not > to my understanding. I don't understand the relevance of your citation as an argument against anything I've said. What is your understanding of the mechanism I described and what is your understanding of section (9.2.2) in relation to that ? I can find nothing in 9.2.2 that contradicts anything I have said so far. While section 9.2.2 goes into the specifics of how TBF is implemented in Linux, it doesn't explain what its purpose is; nor does section 9.2.2 explain what the observable effect at the sender/receiver is. It is somewhat presumed by LARTC that a user wishing to enable those advanced kernel features is familiar with the terminology and purpose. Maybe the wiki page http://en.wikipedia.org/wiki/Token_bucket would be more useful at explaining the general concept in the context of using it to "rate limit" throughput so that the router device is never stressed. Which is the topic of this thread. Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] net5501 lockup when sending alot of trafic between two NIC's
Bjarke Istrup Pedersen wrote: > Indeed, I know it can. > > What I'm trying to figure out is how I can get something useful out of > it when it crashes, so I can track the problem down. (I'm kind of > hoping it is a software issue) > Any ideas? (I'm running Linux 2.6.34.1 on it) Can you remove the "bridging" and make it routable ? It is possible (unlikely) that the bridging code can somehow starve the kernel of resources (be it memory, spare CPU power, out of interrupt handler). What is your interface tx queue length ? Maybe turn it down to 25 packets "/sbin/ifconfig eth0 txqueuelen 25" (or less). The idea of this is to make it start to drop packets BEFORE the system/kernel gets into trouble, dropped packets should show up in the interface statistical counters (so if it remains zero under high load keep turning it down). The connection being bridged will automatically react and recover and lower the throughput. Are you able to knock something up to monitor /proc/interrupts also /proc/meminfo maybe even /proc/schedstat (I'm not sure myself how to interpret that one) also interface statistical counters. Sync values to disk to disk to provide some kind of graph. The other aspect is overheating (and other instablity effects), maybe just removing the case lid would be enough to provide additional cooling. Doing a memtest (to check for bad bit patterns). Although well engineered it doesn't work forever. Linux does support traffic shaping via such things are Token Bucket Filters (TBF) and although it may sound kind of strange to enable something that consumes an additional amount of CPU time when the problem maybe CPU starvation. However the goal here is to maintain a stable system by providing rate limiting.TBF works by deliberately delaying the packets as they pass through the device by tiny amounts this makes the sender and receiver think the maximum throughput across the network is lower than it really is. Also take a look for some Intel Pro/100 Dual-Port (82559 based PCI-X cards). They are literally being thrown away on ebay as all enterprises uses 1000bT now and all consumers devices have then on motherboard, they are PCI-X (have 64bit/66MHz extra finger which will fit/overhang net5501 with just milli-metres to spare) and sometimes come in multipacks boxes of 5 for $25 total (yes that is $5 each). Google the Part Code: PILA8472C3PAK5. That is what I have been able to pickup. They don't have a huge internal buffer but are "Bus-Master" capable. Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] Compatible hardware on 5501
Arun Khan wrote: > On Tue, Jul 13, 2010 at 12:58 PM, Andrew Thomas > wrote: >> I run Transcend 4G with no problems at all - but the 8G isn't even >> recognised by the BIOS (1.33c). Ah maybe the limit is lower. I never tried with an 8G but I did compute the theoretical maximum size at which the problem start to affect bootup. SSD maybe measured in GB (power of 1000) not GiB (power of 1024). Has anyone been able to install an alternative BIOS on the 5501 with any success. This problem stopped us pushing a 5501 into service since the prototype couldn't be made to work. So another hardware solution was found for our datacentre management requirements. Maybe if you (Andrew Thomas) have a spare moment, can you put in the 4Gb and the 8Gb and cut'n'paste the bootup storage probe info. This is to confirm the display looks just like mine where the card is seen and model number known but the CHS geometry has does not display any value for one of the elements. I guess the LBA to CHS management arithmetic goes a bit wrong. > I recently bought a Net5501 with a bracket for a SATA 2.5" disk. > Does the above post imply that the Net5501 BIOS may not be able to see > the entire hard disk e.g. I am planning to install a 160GB hard disk. Confirmed that HDDs of much larger capacities 100Gb .. 250Gb++ have work ok for me. ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] Compatible hardware on 5501
Christophe CRIER wrote: > Thanks to all for your answers ... > > I have another hardware question. > I want to use transcend CF card 8Go or 16Go in 5501 box, is there any > 'contraindication' about this card ? While SanDisk maybe a good brand, I wouldn't go for anything larger than 8Gb. While it is meant to work in theory I believe there to be a comBIOS bug that may prevent at least one well known operating system from booting correctly. The card I have is a: SanDisk SDCFH-016G This does not work on the comBIOS 'c' revision, which I believe to still be the latest. See my previous threads in this mailing-list archive on the exact problem, my guess is that the BIOS computes an invalid geometry, probably due to overflow or zero/negative value in arithmetic. I have it on understanding from others that smaller cards work fine. Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] DSL modem recommendations?
Martin Johnson wrote: > - Draytek Vigor 120 ADSL modem. Good and stable, even on my marginal DSL > line, and seems to support all the latest DSL standards. I concur. The Draytek is a standalone media converter (supporting ADSL2+ and 10/100bT ethernet), have used it in the UK with ISPs that: * Are based on BTs wholesale service and require PPPoE to access WAN. * Are based on LLU (local loop unbundling initiative in the UK) and uses the Vigor 110/120/1x0 in "bridged" mode, i.e. there is no PPPoE in use. My only gripe with the unit is that it doesn't support baby-jumbo ethernet packets (allowing 1500(payload bytes) + 14(mac/pid bytes) + 2 (CRC bytes) plus the 4 or so bytes of PPPoE overhead). I'm sure the Ethernet controller they have on board can do it, so it is a firmware issue and a basic lack of understanding by the designers about this issue. The reason for this request is that the PPPoE (when PPPoE is being used requires extra few bytes of overhead to a traditional ethernet frame, this means the effective MTU is reduced and you end up with issues around packet fragmentation, TCP MSS clamping and other such nonsense. I use the draytek's telnet based management, I'm not sure the units I have support HTTP (since I have model 110 not 120), since there are only about a dozen options I can set and only about 5 that ever need changing (if at all!) For the record, I'm not aware of any other media converter on the market that "gets it" either; when it comes to this baby-jumbo ethernet packets over 100bT issue and PPPoE. So excuse my rant on that point here. Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] net5501 gets an ip but doesn't continue over pxe
Tarek Kilani wrote: > Hi People, > I'm new to this community and to mailing lists, so if there is something > that I missed let me know. > I have used the nice tutorial of > http://webfolder.wirelessleiden.nl/www.ultradesic.com/index98e4.html?section=45 > where I have reached to the part where I enter "boot f0", and I get: > > NSC DP83815/DP83816 Fast Ethernet UNDI, v1.03 > > Copyright (C) 2002, 2003 National Semiconductor Corporation > All rights reserved. > > Pre-boot eXecution Environment PXE-2.0 (build 082) > Copyright (C) 1997-2000 Intel Corporation > > > CLIENT MAC ADDR: 00 00 24 C3 5E 50 > CLIENT IP: 192.168.1.4 MASK: 255.255.255.0 DHCP IP: 192.168.1.10 > > ==END=== Using tcpdump from the IP 192.168.1.10 would be your best friend here, particularly like: tcpdump \( broadcast or host 192.168.1.4 \) and \( udp port bootpc or udp port tftp \) For me this gives: 17:14:52.434969 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:24:e8:93:8c, length: 548 17:14:53.001228 IP 172.16.32.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 300 17:14:55.450458 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:24:e8:93:8c, length: 548 17:14:55.496648 IP 172.16.32.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 300 17:14:55.645053 IP 172.16.32.209.2070 > 172.16.32.2.tftp: 42 RRQ "X86PC/pxelinux/pxelinux.0" octet tsize 0 17:14:55.696081 IP 172.16.32.209.2071 > 172.16.32.2.tftp: 47 RRQ "X86PC/pxelinux/pxelinux.0" octet blksize 1456 17:15:01.948645 IP 172.16.32.209.57089 > 172.16.32.2.tftp: 78 RRQ "X86PC/pxelinux/pxelinux.cfg/01-00-00-24-e8-93-8c" oct 17:15:01.987275 IP 172.16.32.209.57090 > 172.16.32.2.tftp: 53 RRQ "X86PC/pxelinux/menu.c32" octet tsize 0 blksize 1440 17:15:02.46 IP 172.16.32.209.57091 > 172.16.32.2.tftp: 78 RRQ "X86PC/pxelinux/pxelinux.cfg/01-00-00-24-e8-93-8c" oct Intel UNDI, PXE-2.0 (build 082) Copyright (C) 1997,1998,1999 Intel Corporation VIA Rhine III Management Adapter v2.43 (2005/12/15) CLIENT MAC ADDR: 00 00 24 e8 93 8C CLIENT IP: 172.16.32.209 MASK: 255.255.255.0 DHCP IP: 172.16.32.2 GATEWAY IP: 172.16.32.1 Do you have a TFTP server running on the server at 192.168.1.10 (or you can configure to an alternative IP via some DHCP options in the DHCP response that is being given out) ? For me I have ISC dhcpd with the configuration directives (and booting syslinux http://syslinux.zytor.com/wiki/index.php/PXELINUX ): server-identifier 172.16.32.2; server-name TYR; next-server 172.16.32.2; filename "X86PC/pxelinux/pxelinux.0"; This instructs PXE the next file to load over TFTP and then execute is "X86PC/pxelinux/pxelinux.0" I'm sure there are *BSD related notes on how to setup PXE to install *BSD. Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] Debian5/GRUB installation problems
Andrew Thomas wrote: > 1.33c gave me the option to boot from a CF card - as it would with 1.33. I'm not sure I understand your response. The only storage I have installed is the CF card. I have it working providing I make the /boot partition fit on the first cylinder (the imaginary first cylinder when you convert to CHS geometry). So there is no doubt that plain 1.33 supports a CF card for booting. The only background reading I can find is that 1.33b/1.33c were produced in response to some issues/workaround with hardware production. Which might explain why no release notes since only those affected need to upgrade ? Nowhere has it been stated that any fixes/changes have been made in 1.33c that affect this particular problem. Infact I should ask, does anybody have a > 8Gb Compact Flash with GRUB working without the 1 cylinder restriction ? The 8Gb limit comes from the C/H/S geometry returned by comBIOS for my flash being 1946 cylinders, 255 heads, 63, sectors. This is larger than the 1024 cylinder limit. That limit for the C/H/S range of 0/0/1 to 1023/254/63 is 1024*255*63 sectors or 8225280 KiB or 8032.5 MiB or 7.8442 GiB or 8.422 Gb. So as flash maybe rated in Gb not GiB it needs to be larger than 8 Gb to be relevant. I do not have smaller CF cards to test and see what C/H/S geometry net5501 returns for say a 4Gb or 2Gb or 1Gb flash card. It is possible due to that geometry choice the particular bug I am being hit with does not show itself. Also does comBIOS 1.33 (and later versions) provide these BIOS interfaces : [INT 0x13 AH=0x41 BX=0x55aa] is used by GRUB for LBA mode check, it expects a return of [Carry flag reset, BX=0xaa55] on return to indicate LBA mode is supported (i.e. function AH=0x42 is supported for LBA mode). [INT 0x13 AH=0x42 various other registers used] is used by GRUB for LBA read sectors from disk into memory. Thanks, Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] Debian5/GRUB installation problems
Bob Gustafson wrote: > What bios version are you running? 133c ? > > On Mon, 2010-03-08 at 21:06 +0000, Darryl Miles wrote: >> AMuse wrote: >>> Darryl: I had many, many problems with Grub under Debian 5 on the >>> net5501. Although there are a series of complicated steps you can take >>> to get it running (sometimes) , LILO works fine out of the box. No "1.33" is what I see, the release notes do not explain what is in the 1.33c so therefore I can not make an informed choice about upgrading. My sources of reference are: http://wiki.soekris.info/Known_bugs http://www.soekris.com/downloads.htm http://www.soekris.com/software/changelog.txt ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] Debian5/GRUB installation problems
AMuse wrote: > Darryl: I had many, many problems with Grub under Debian 5 on the > net5501. Although there are a series of complicated steps you can take > to get it running (sometimes) , LILO works fine out of the box. > > I recommend you just install LILO as your boot loader if you want to use > Deb5 on net5501 - it'll work fine and save you a lot of headache. Thanks for your reply. I'm a little hesitant to go back to LILO (and go back on over 10 years progress) since the remote upgrades might become an issue as LILO is much fragile. My gut feeling is that there is a translation bug, possibly due to the large 16Gb SanDisk card I am using inside of comBIOS, it calls to load a block and it is simply accessing garbage. GRUB seems to work fine with both Debian and Fedora modern ext3 filesystems that have extra options, such as signed_directory_hash, resize_inode and on large paritions of this side, so this is why I'm not pointing the finger at GRUB this minute. So I can only think it is some kind of comBIOS bug. The data it is requesting or the data that is being returned isn't the expected data for that block. What is the licensing that comBIOS is distributed under ? is this available for peer review. It should be easy enough to make GRUB have a "dumpblock " or it emit, "lba, top(4 bytes), tail(4 bytes) and checksum" of each sector it loads. Then have another tool hunt for that block and prove it is not loading the correct one. For me it does seem that it is able to access the: * Start of the medium (partition table, LBA block 0) * Start of the partition (ext3 superblock, LBA block 63) * The root directory (which is at filesys block 512, see below for working, LBA block 1087=(512*2)+63) It does not seem to be able to access * filesys block 84481 (/grub directory contents), LBA block 169025=(84481*2+63), which is approx 10.52 cylinders in old money Maybe I can craft my kernel image and initrd to fit within the first cylinder using to prove that it will boot providing I do not cross a cylinder boundary for any data access necessary for GRUB. Maybe I can just shrink my partition below 16065-63 sectors. Yes I can report when I did this (shrink my /boot so its less than 1 cylinder) my net5501 boots up fine. The commands I used: mkdir /tmp/saved/boot cp -av /boot/* /tmp/saved/boot/ umount /boot # 8001 Kb is under the 1 cylinder limit: # # (63 sectors * 255 heads) minus 63 sectors, divide by 2 # working... # 63 sectors * 255 heads = the reported geometry giving the sectors per cylinder # minus 63 sectors = the space of the partition table and MBR # divide 2 = convert sectors to Kb blocks for mkfs.ext2 block-size /sbin/mkfs.ext2 -m 0 -L boot -t ext2 -O ^resize_inode,^sparse_super,^large_file,^ext_attr /dev/sda1 8001 /bin/mount -t ext2 -w /dev/sda1 /boot mkdir /boot/grub cp /tmp/saved/boot/grub/menu.lst /boot/grub/ cp /tmp/saved/boot/bzImage-2.6.33 /boot/grub/ cp /tmp/saved/boot/initrd.img-2.6.33 /boot/grub/ # This puts stage1/1.5/2 back into /boot/grub /usr/sbin/grub-install --no-floppy --force-lba --recheck --debug hd0 Obviously is painful having a 7754 Kb (of usable space) /boot partition, since I can't do upgrades / failover kernels now. Regards, Darryl WORKING: # fdisk -l Disk /dev/sda: 16.0 GB, 16013942784 bytes 255 heads, 63 sectors/track, 1946 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000760fd Device Boot Start End Blocks Id System /dev/sda1 * 1 16 128488+ 83 Linux /dev/sda2 17 502 3903795 83 Linux /dev/sda3 503185310851907+ 83 Linux /dev/sda418541946 747022+ 82 Linux swap / Solaris Disk /dev/sda: 16.0 GB, 16013942784 bytes 255 heads, 63 sectors/track, 1946 cylinders, total 31277232 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x000760fd Device Boot Start End Blocks Id System /dev/sda1 * 63 257039 128488+ 83 Linux /dev/sda2 257040 8064629 3903795 83 Linux /dev/sda3 80646302976844410851907+ 83 Linux /dev/sda42976844531262489 747022+ 82 Linux swap / Solaris Disk /dev/sda: 255 heads, 63 sectors, 1946 cylinders Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID 1 80 1 10 254 63 15 63 256977 83 2 00 0 1 16 254 63 501 2570407807590 83 3 00 0 1 502 254 63 10238064630 21703815 83 4 00 254 63 1023 254 63 1023 297684451494045 82 # /sbin/dumpe2fs /dev/sda1 Filesystem volume name: boot Last mounted on: Filesystem UUID: d4a683fb-c688-4cf7-9075-4eb22a375e73 Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super Filesystem flags:
Re: [Soekris] Seagate Barracuda 750G SATA not working on net5501
Henrik /KaarPoSoft wrote: > In case anybody else runs into this issue: > > The above was observed with the disk being "internally" powered by the > net5501, and the net5501 being powered by an external 12V 1.5A power supply. > > When powering the net5501 with a 12V 3A power supply (drive still > "internally powered"), the drive is still not recognized after power-on. > However, after a subsequent "reset" button press or BIOS reboot command, > the drive is recognized and it is possible to boot from it. > This behavior seems consistent, and the drive seems to work - I did two > kernel compilations with no problem. Can you increase the comBIOS Ctrl-P "BootDelay" option to the maximum 16 seconds ? Does that make any kind of difference ? http://wiki.soekris.info/What_do_all_those_BIOS_settings_do%3F Come to think about it, it does a storage bus scan before the BootDelay kicks in (as it print the device information at the top), so maybe an additional parameter should be added to comBIOS to delay the storage scan after power on, with 0 being the default (meaning no delay) and upto 15 seconds the maximum. Which will count down or need an explicit Ctrl-C to abort early (rather than any-key since people tend to press and to make something happen and that shouldn't interrupt it). Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
[Soekris] VLAN 802.1q support by hardware National Semicondutor DP83816 chipset (with Linux kernel driver) ?
Can anyone confirm if the Ethernet ports and "National Semicondutor DP83816" chipset driver allow for: * Each port operating independently (so eth0 through eth3 on Linux with net5501, then an additional 4 ethernet interfaces eth4 through eth7 if the lan1641 is installed) ? * That the VLAN 801q kernel driver is fully supported on each ethernet interface. This allows for VLAN tagging of packets so the installed OS can act as a multihomed router from a single ethernet interface. Also is the standard Linux kernel driver for these ethernet cards the recommended driver to use ? i.e. it fully support plug-in-plag of the PCI bus allowing for auto-discovery on bootup with the specific hardware design of all soekris products ? Thanks, Darryl ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
